locked
External trust and SSPi error RRS feed

  • Question

  • Hi All,

    we have an external trust between domain A and B.  Users from Domain B are trying to access via SQL Studio manager an SQL 2005 server in domain A and receive the dreaded sspi error cannot generate context I have reviewed the standard doc that most people are referred to when trying to diagnose the error but no joy.  

    What complicates this even more is the same user from an old workstation can authenticate and access the server yet from another machine the user cannot access the server.  I have checked group policies etc all is identical.

    When I run a network trace I can see that the workstation that fails to connect the user does not attempt to fail back to NTLM as it should (this being an external trust) but the workstation that does connect the user negotiates the authentication via DCERPC.

    Why would the workstation not fail back to NTLM?

    Any help much appreciated.

    Thanks

    Tuesday, January 15, 2013 11:14 AM

Answers

All replies

  • Do not create external trusts when using NTLM blocking security policy settings. Alternatively, do not enable NTLM blocking settings in an environment that uses or plans to use external trusts.

    Trust utilities allow an administrator to create and validate external trusts on NTLM blocked domains

    _______________________________________________________________________________________________________

    This article details known logon issues that can occur for users of computers with one of the operating systems listed below when attempting to join a trusted domain using external NTLM trusts.

    Error: The security database on the server does not have a computer account for this workstation trust relationship


    Best regards Biswajit Biswas Disclaimer: This posting is provided "AS IS" with no warranties or guarantees , and confers no rights. MCP 2003,MCSA 2003, MCSA:M 2003, CCNA, MCTS, Enterprise Admin, MCC,Technet Wiki Ninja





    • Edited by bshwjt Tuesday, January 15, 2013 12:32 PM
    Tuesday, January 15, 2013 11:22 AM
  • Thanks for the reply.  I'm not sure what you mean though as we do not block NTLM if we did none of the users could authenticate on any workstation
    Tuesday, January 15, 2013 12:43 PM
  • System services NTLM fallback with computer identity

    When connecting to computers running versions of Windows earlier than Windows Vista or Windows Server 2008, services running as Local System and using SPNEGO (Negotiate) that revert to NTLM use the computer identity. In Windows 7, if you are connecting to a computer running Windows Server 2008 or Windows Vista, then a system service uses either the computer identity or a NULL session. When connecting with a NULL session, a system-generated session key is created, which provides no protection but allows applications to sign and encrypt data without errors. When connecting with the computer identity, both signing and encryption is supported in order to provide data protection.

    You can configure the Network security: Allow Local System to use computer identity for NTLM security policy setting to allow Local System services that use Negotiate to use the computer identity when reverting to NTLM authentication.

    If you do not configure this policy setting, services running as Local System that use the default credentials and a NULL session revert to NTLM authentication for Windows operating systems earlier than Windows Vista or Windows Server 2008. This might cause some authentication requests between Windows operating systems to fail and display an error.

    http://technet.microsoft.com/en-us/library/dd566199(v=ws.10).aspx

    How to check the NTLM version for Logon Agent compatibility?

    NTLM authentication version 1 and version 2

    How to enable NTLM 2 authentication

    or

    Could you build the forest trust & try! 


    Best regards Biswajit Biswas Disclaimer: This posting is provided "AS IS" with no warranties or guarantees , and confers no rights. MCP 2003,MCSA 2003, MCSA:M 2003, CCNA, MCTS, Enterprise Admin, MCC, Technet Wiki Ninja



    • Edited by bshwjt Tuesday, January 15, 2013 12:59 PM
    Tuesday, January 15, 2013 12:48 PM
  • External forest trusts only support NTLM, so there is nothing to fall back onto, since Kerberos isn't even used.  What it sounds like to me is it isn't even trying to authenticate to the domain only authenticate to the local box.  When you specify the credentials are you sure you are using domain name\user id or user name@domain.com?

    -- 
    Paul Bergson
    MVP - Directory Services
    MCITP: Enterprise Administrator
    MCTS, MCT, MCSE, MCSA, Security+, BS CSci
    2008, Vista, 2003, 2000 (Early Achiever), NT4
    http://www.pbbergs.com    Twitter @pbbergs
    http://blogs.dirteam.com/blogs/paulbergson

    Please no e-mails, any questions should be posted in the NewsGroup. This posting is provided "AS IS" with no warranties, and confers no rights.

    Tuesday, January 15, 2013 1:03 PM
  • The user logs in to a workstation that is part of the user domain and runs an application that access a resource in domain A.  authentication is transparent nowhere to enter credentials.  My understanding is the upn wont work with an external trust and it should be the resource server that redirects the request for authentication to it's local domain DC which in turn contacts a DC in the user domain, but why it goes no further I don't know
    Tuesday, January 15, 2013 8:02 PM
  • looking at the network traces again today the workstation that fails doesn't even attempt to connect via rpc for some reason it just terminates the session I can now see it failing back to NTLM but thats as far as it goes it doesnt try to establish an rpc connection.  Any ideas how I try to diagnose this one?
    Wednesday, January 16, 2013 10:15 PM
  • As previously stated External forest trusts only support NTLM not kerberos. Kerberos is used only when external trust is created and validated.

    By default "External Trust" authentication is used only NTLM so there is no failback. There is different version is vailable in 2003 and 2008 so check the version number if that can help you.

    The Netlogon service, among other things, takes care of passing NTLM authentication requests to a domain controller that can handle them, and receiving them on that domain controller to be handled.  Since the Netlogon service runs within the Lsass.exe process the authentication is ultimately handled by Lsass.exe.  Within that process are threads, which can be thought of as the little workers that run the code.  For NTLM authentication specifically there is a set number of threads which will handle that request and answer.  The setting which governs how many threads can be used for that is called MaxConcurrentApi.  The defaults are typically 1 for this, meaning that there is one thread to hand off, receive and process these requests.  Updated: NTLM and MaxConcurrentApi Concerns

    _______________________________________________________________________________________________________

    NTLM Blocking and You: Application Analysis and Auditing Methodologies in Windows 7

    NTLM authentication failed

    Is this horse dead yet: NTLM Bottlenecks and the RPC runtime

    Purging Old NT Security Protocols

    I would recommend, if possible create the forest trust.

    In addition,

    Kerberos Authentication Over An External Trust – Is It Possible?


    Best regards Biswajit Biswas Disclaimer: This posting is provided "AS IS" with no warranties or guarantees , and confers no rights. MCP 2003,MCSA 2003, MCSA:M 2003, CCNA, MCTS, Enterprise Admin, MCC, Technet Wiki Ninja



    • Edited by bshwjt Thursday, January 17, 2013 9:18 AM
    • Marked as answer by Cicely Feng Tuesday, January 22, 2013 1:38 AM
    Thursday, January 17, 2013 4:32 AM
  • Have you seen it?  Updated: NTLM and MaxConcurrentApi Concerns & Could you please let us know the current situation?

    Thanks

    Biswajit

    MCC,Technet Wiki Ninja


    Best regards Biswajit Biswas Disclaimer: This posting is provided "AS IS" with no warranties or guarantees , and confers no rights. MCP 2003,MCSA 2003, MCSA:M 2003, CCNA, MCTS, Enterprise Admin

    Friday, January 18, 2013 5:36 AM