We have a server hosting a webservice (we’ll call this the Sending Webservice) that takes documents/pdfs, etc. and uploads them to a specific site collection in SharePoint. On the SharePoint WFE, there is also a custom webservice (we’ll call this the Receiving Webservice) running in the same app pool as the hosted SharePoint site collection that receives the authentication, connection and then uploads the document into the document library.
This is where the fun begins. Our security department is running the domain controllers on Server 2003. OOTB Server 2003 comes with an ancient credentialing capability called LanMan or Lan Manager. I am no security guru, but I’ll explain it’s purpose as best I can.
From my understanding, the Lan Manager attaches a hash to every account that has a password tied to it within active directory. This hash could be used by applications to pass an encrypted password through to A.D. and obtain a successful authentication. The encryption methods this hash could handle were for both LM and NTLMv1 (version 1) encryption. Both versions were incredibly weak and easy to hack if someone was sniffing the network traffic watching for this handshake. LM and NTLMv1 have also been retired for over 10 years. You do not need to fear if you are running domain controllers with Server 2008 or greater as Lan Manager is all but gone from this environment now. But by default, Lan Manager and the LM authentication is enabled when running Active Directory in Server 2003. However, you can easily disable these.
Back to the story. Our security department decided to do several things to increase security. Change the user ids to unrecognizable letter and number combonations and force all passwords to 15 characters with all the standard character requirements that would go with it. They didn’t mention Lan Man had already been disabled the week earlier. Now here is the catch…once the Lan Manager was disabled, the hash remained tied to the account. So the service account that was using an “LM” or “LMNTv1” encryption hash still worked just fine. But once a password or ID on the account was changed, the hash that was originally tied to the account in Active Directory dropped off and the account failed to authenticate with these encryption methods.
A good test to see if this is ever the case in another situation, change the service account to an ID that did not have the password changed after Lan Man was disabled. If it’s a “Lan Man” issue, the account will work just fine. Then change the password and expect to see the functionality break again.
As we had already recieved the updated account credentials and they were not working, we reverted the account back to the original service account login ID, display name and password credentials just to make sure we wern’t missing anything on the code side that was holding the credentials somewhere we did not realize…but even with the reverted credentials it was failing.
When we look at the log files, it gives the error that the credentials supplied were invalid. That’s pretty much it. This did not anser the really important questions. Such as, “what is requesting the credential (AD or SharePoint)? What is sending the credential (recieving or sending webservices)? And who is saying it is denied (SharePoint or AD)?” Now, we know the account worked just fine if you used the account via the front end of SharePoint so we know it is not end user error. You could log into a site just fine. But using the Sending wservice caused the problem. Is SharePoint recieving a hashed password and rejecting it automatically? or was was it capturing the authentication and sending it re-encrypted to Active Directory and then AD was denying it because of that or was SharePoint simply passing the authentication through (sending on whatever it recieves).
A lot of questions that we couldn’t answer without some help. So, we got our Network guru on a call and he started to watch the traffic coming from and going out from the SharePoint WFE server (I believe with a program called NetMon). We triggered the Sending webservice. There we saw the credential go to the WFE and pass on to the domain controller. Then the DC rejection packet. Both the Sharepoint server and the AD server rejected the credential.
This answered, who was doing the rejecting (both SharePoint and AD). Which also means that the credentials were not geting reencrypted by the SharePoint server since SharePoint itself was rejecting the credential.
After many hours trying to isolate the issue, we learned that there was another Sending webservice that was using this custom SharePoint Receiving webservice and it was working just fine. :-/
So in the end, when an account is requesting to get authenticated to SharePoint, SharePoint does nothing but try to authenticate it itself. And if it cannot, SP will pass on the credentials (as it received them) to Active Directory for authentication. AD says yeay or nay, and sends that answer back to SharePoint. SharePoint then simply allows or denies based on that response from AD.
Below is a depiction of the the path security takes:
1) Client pc requests action from the hosted webservice.
2) Webservice passes it’s service account credentials to the custom webservice hosted on the SharePoint server.
3) SharePoint receives credentials and attempts to authenticate the account itself. If it cannot, it passes on the credentials to the Domain Controller for authentication within Active Directory (AD).
4) AD approves/denies credential and sends response back to SharePoint WFE requester.
5) SharePoint notifies original sender of the response.
The Credentialing Process