Forum Discussion
elastic_82555
Nimbostratus
Nimbostratuskerberos and ntlm authentication using APM
Hi,
I have setup sharepoint 2010 iApp, using NTLM authentication and it is working well(using the F5 login page), however, I now have a requirement to use kerberos authentication, as well as NTLM. In effect, if the kerberos is not present, then the NTLM should be used as the default. Another requirement, is that if a user is already logged into their windows 7 workstation, then their credentials should be silently passed to the F5 to allow kerberos authentication "transparently" without the user having to see a login page.
Currently I have read many documents, but settled on the "Access policy manager, Single Sign On configuration guide" for v11.3(HF3). This details the NTLM setup nicely and also a "client based certificate" setup using kerberos. Whilst this is instructive, it does not actually help, as my scenario does not involve client side certificates(unless I am mistaken). I have created a kerberos SSO config, and am at the stage of editing the access policy, but it is at this piont, where I seem to have a lot of choices and not much documentation. Has anyone done this already, and could offer me any pionters. As a first off, I would like to just get kerberos SSO working, then I could work on getting both NTLM and Kerberos.
any links to documentation, or even better a similar example would be extemely appreciated.
thanks
Sc0tt....
- Kevin_Stewart
Employee
Very interesting. I can't say there's any specific rule-of-thumb here, but you appear to have found an anomaly. Good catch.
Davo_T_20783The orginal question submitter is confused about the role of the APM. He implies that he is not seeking a F5 APM managed KPT but just wants kerberos SSO to carry on working with a F5 LTM load balancing virtual server in the path. Easy - forget about the APM - it's not required for this scenario - the F5 can just pass through the SPNEGO portion of the header from the client. While I can't vouch for the specifics of Sharepoint portal, the reason why he is struggling I suspect is due to DNS lookup part of the Kerberos protocol. It is a common mistake to make an application SPN based on the DNS cname of the F5 virtual server instead of using the FQDN of DNS a-record for the VIP that the F5 pool is using.
hth. David.
- Kevin_Stewart
I would only add here that for you to be able to pass SPNEGO through an LTM VIP, the FQDN the client sees - the VIP address (A or CNAME record) must match the SPN of the Keberos-enabled service behind the LTM. For example, if the client browser contacts "http://www.domain.com", and subsequently receives a 401 response from the server behind the proxy, the client browser will attempt to request a Kerberos ticket for the SPN "HTTP/www.domain.com". If by chance the KDC has a resource by that name, it'll issue that ticket to the client, which will pass the server's portion back through the proxy to the server. If the server itself does not "own" the HTTP/www.domain.com SPN, then it will not have the encryption key necessary to decrypt this token. That scenario would apply to any Kerberos-enabled environment, including SharePoint.
