Authentication issues using NTLM, SSL, and SharePoint

Question

I am currently experiencing problems with authentication on a SharePoint site. Routinely, user accounts(only one or so at a time) will be locked out and they will get 401 unauthorized errors. The SharePoint implementation is using only local user accounts, has SSL, and NTLM authentication. I am not sure of the exact network configuration (I am not the network admin) but a proxy may be involved. By the time the issue is investigated by the Network Admin, the account is working again. So intermittent as well. My questions for this are:

1.) Has anyone run into this before?

2.) Would switching to Basic Authentication resolve this? There are brief whispers of NTLM mangling in WSS when a proxy is involved.

3.) Is SSL and IWA together a bit overkill in the first place? I mean the password and login would be sent encrypted in Basic Auth with SSL anyway right? And the benefits of IWA in a non-Domain extranet seem useless to me.

Answer 1

It would be good to check IIS log files, to see if there's a pattern - are specific resources getting 401s or if it's generic.

A usual problem is certain resources could be in a server(file system) folder, and they may not be accessible to all users. These resources could be linked from specific pages alone, so the errors may be intermittent. Remember SharePoint runs requests in an impersonated context by default.

Answer 2

If it was Kerberos I would expect to see a Negotiate (or am I assuming wrong?)

Negotiate could be kerberos or ntlm. ntlm definitely means ntlm.

To confirm the authentication method used, check the first character of the authentication header. If it is a "T", it is ntlm. If it is a "Y", it is kerberos.

http://support.microsoft.com/kb/891032

Note that you can configure IIS to require NTLM, but it does not work the other way around (require kerberos). Would be nice though.

SSL is not overkill if you need to encrypt the content. Kerberos without SSL is secure enough for the authentication, but does not encrypt the content.

What do you mean by "local" accounts? You have a standalone/non-domain sharepoint server in an extranet, and the users logon with non-domain/local accounts?

Answer 3

There are a number of cases where NTLM auth gets hosed up through proxies - though I would hope that most proxies have that behavior corrected by now.

I would check to see that your WSS site is setup as a trusted site/intranet and your browser settings are such that the authentication credential is automatically passed. It would probably help if it was actually on a domain, but it sounds like that is not the case.

You could always fall back to basic auth, but be sure to use SSL if you are going that route.

Answer 4

Here's the thing. Sharepoint uses impersonation. That means you should NOT be using NTLM at all -- you should be using Kerberos. That's a very big distinction. NTLM does not mean "Integrated Windows Authentication".

So here's what you need to do. Go to the Sharepoint server under the Security event log. In there, you should see that all of your users are being authenticated using "Kerberos", not "NTLMSSP". If you see that people are being granted access using NTLM, that probably means (I'd say 80% of the time) that you need to define a Service Principal Name for Sharepoint. If you're runnning your sharepoint site under an alias, you will need to set a Service Principal Name for that alias as well, because IE7 has a bug in it where it requests tickets for the wrong SPNs intermittently.

So my three tips are:

1. Make sure you see an SPN for HTTP\MACHINENAME under the sharepoint service account in AD.
2. Make sure you see an SPN for HTTP\YOURALIAS under the sharepoint service account in AD.
3. Make sure the "Enable Integrated Windows Authentication" box is checked on all of your clients. Checking this box enables Kerberos on the Web Browser, which is a requirement.