• Tag Archives sharepoint 2010
  • NT Authentication Failure: Utilizing Custom Web Services External to SharePoint

    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
    NTLM Path
    Useful information:

  • Office Appliations Opening Files Twice

    This is quite short and fairly simple, but I felt it needed to be noted because it stumped me for over a day and I don’t want it to happen again…

    I found that when some users select a document to open from within a SharePoint 2010 library, it would bring the document/spreadsheet up twice. I was unable to find a viable solution for this within SharePoint. Evidently, they were using the 64-bit version of Internet Explorer. Which is incompatible with a lot of sites outside of SharePoint as well. Using the 32-bit version of I.E. seemed to resolve this issue.

  • Open Documents in Client Applications

    Recently, I had a situation where end users were trying to open Office files in the new SharePoint 2010 environment we released to them for testing. They would try to open an xlsx spreadsheet and it would try to open in the browser. We didn’t want this functionality to work so we decided to turn on the feature called “Open Documents in Client Applications by Default” at the site collection level. Which was suppose to automatically disable that functionality.


    Unfortunately, it didn’t work. I learned shortly after, that there is a setting (that enabling the said feature was suppose to take care of and didn’t switch for me)…

    I’m sure like most of you, your environment(s) have a ton of sites and within each, tons of document libraries. Going through them each and manually setting this, would be out of the question. So I took the approach of PowerShell. It had performed miracles for me in the past, no reason it wouldn’t now. Or so I hoped. I’m no PS guru by any means. So I rely on Google to help me out. After some time I came across a couple scripts that looked like viable solutions. But they failed me. After a couple days of troubleshooting, I finally came up with a solution that actually worked…

    #Get the site collection...
    $site=Get-SPSite "http://servername/sitecollection"

    #Define the list type within the sitecollection to change (SPDocumentLibrary)
    #This changes the setting for all matching list types within the sitecollection
    foreach ($list in ($web.Lists | ? {$_ -is [Microsoft.SharePoint.SPDocumentLibrary]}))

    #define the setting and the value to modify.
    #You can define as many different settings as you like
    $list.DefaultItemOpen = "PreferClient”


    I did have a situation where even after this was adjusted, a small handful of end users were still getting SharePoint to open Excel documents in the browser somehow. Their configuration was Windows 7 (both 64 & x86), IE 8 and Office 2010. I couldn't entirely isolate what the cause was of the issue, but what I do know is that these guys were always tinkering with their OS/applications/registry. So who knows what caused it. The fix below seemed to resolve it:

    On each of SP servers in the farm go to:

    1. c$program filescommon filesMicrosoft SharedWeb Server Extensions14TEMPLATEXML.
    2.  Locate the file called “serverfilesExcelServer.xml”
    3. Comment out the xlsx file extension reference
    4. Perform an IISReset on each of the servers you made the change on.