locked
Windows authentication and Domain controllers RRS feed

  • Question

  • I'm curious if someone could help me with my problem.

    I have SharePoint 2010, that connects to SQL 2008. I'm using domain user account. I have enabled Windows Authentication method for my SQL 2008. In my domain is several DCs (same domain). Unfortunately, when one of my DC is rebooting, I got "Cannot generate SSPI context" error in Event-Windows Logs and of course SharePoint is not able to get any data.

    My question is, against which DC send SQL 2008 authentication request ?What if particular DC is not reachable (rebooting, down, line is down etc.) ? Does SQL keep trying against another DCs ? And is any possibility to monitor this communication ?
    Friday, May 25, 2012 8:03 PM

Answers

  • Hi Jarmila5,

    SQL Server is as a normal service using Kerberos within domain. The problem in your scenario is that SSPI (Security Support Provider Interface) fails to delegate the user security token to the server running SQL Server instance. This communication is not on SQL Server side. I agree with sean, you may involve some Active Domain specialist to look into the communications between DC and client computer with Kerberos authentication.


    Stephanie Lv

    TechNet Community Support

    • Marked as answer by Jarmila5 Thursday, May 31, 2012 6:46 PM
    Monday, May 28, 2012 3:13 AM

All replies

  • Hello,

    As far as I know this is all done at the windows OS level and SQL Server is not aware of any changes to DCs. I'm not an A/D person, but I have had to troubleshoot this a few times. I generally start by check the %LOGONSERVER% to see if anyone was working on the DC this server was connected to, normally one of our other DCs will take over requests (I'm not sure how windows/domain determines this). I would check the setup of A/D and the DCs and ask your A/D admin to double check and make sure a specific logon server isn't specified for the SQL Server box.

    1. Against which DC will SQL auth?

    AFAIK the one that you get back from %LOGONSERVER%.

    2. What if a particular DC is unreachable?

    AFAIK (though I'm not sure the exact procedure) windows attempts to talk tot he DC, when communication fails it looks up another DC if available in A/D and attempts to use that one. I could be totally wrong here.

    3. Does SQL keep trying against another DCs?

    See #2.

    4. Any possibility to monitor this connection?

    I'm sure there is but I do not know it other than to use something like wireshark. Your windows admin or A/D admin would be of more help.

    -sean


    Sean Gallardy, MCC | Blog

    Saturday, May 26, 2012 3:22 PM
  • Thank you for reply Sean. I captured communication via Wireshark and in step 18 it really starts authentication via Kerberos against DC. But before (steps 1-17), there is no significant request to question "where is DC ?". So I assume, that IP address of particular DC(s)? is/are already known by local authority, where SQL Server is running. If this is correct, then next question will be, how often is this list of available DCs refreshed? Because as you wrote, it should communicate to another DC, but in my case SQL Server communicated only with one particular DC, even next 5 DCs were available and ready to serve. Result was, that during the time, when specific DC was rebooted (let's say 2 minutes), no one was able to authenticate from SharePoint, even next 5 DCs were available. In my opinion, the fail-back does not work as we think or does not work at all :-) But as far as I know Active Directory, it should be high-available by default so I suppose, this is completely in hands of Active Directory and not SQL Server.
    Saturday, May 26, 2012 5:27 PM
  • I would suggest starting from here


    Balmukund Lakhani | Please mark solved if I've answered your question, vote for it as helpful to help other user's find a solution quicker
    --------------------------------------------------------------------------------
    This posting is provided "AS IS" with no warranties, and confers no rights.
    --------------------------------------------------------------------------------
    My Blog | Team Blog | @Twitter

    Saturday, May 26, 2012 5:41 PM
  • Already started Balmukund, thanks.
    Saturday, May 26, 2012 6:12 PM
  • Hi Jarmila5,

    SQL Server is as a normal service using Kerberos within domain. The problem in your scenario is that SSPI (Security Support Provider Interface) fails to delegate the user security token to the server running SQL Server instance. This communication is not on SQL Server side. I agree with sean, you may involve some Active Domain specialist to look into the communications between DC and client computer with Kerberos authentication.


    Stephanie Lv

    TechNet Community Support

    • Marked as answer by Jarmila5 Thursday, May 31, 2012 6:46 PM
    Monday, May 28, 2012 3:13 AM