windowskerberos

InitializeSecurityContext (Kerberos) in cross domain forest

I am trying to call the Windows system API InitializeSecurityContext (Kerberos) in a cross domain forest environment, unfortunately get a failure result. Here is my environment setup:

Test Scenarios

  1. admin@cloud.com remote logon CNPVGVB1UT731 and try to access service ldap/CNPVGVB1UT726.cloud.com/cloud.com, I can call this function and get a token successfully.
SECURITY_STATUS sResult = InitializeSecurityContext(
                &hCredential,                               
                isFirstCall ? NULL : &m_contextHandle,       
                "ldap/CNPVGVB1UT726.cloud.com/cloud.com",                  
                get_context_attribute(contextAttributeFlags),
                0,                                           
                SECURITY_NATIVE_DREP,                        
                isFirstCall? NULL:&inBuffDesc,               
                0,                                           
                &m_contextHandle,                            
                &outBuffDesc,                                
                &m_contextAttributes,                        
                &tsLifeSpan                                  
                );
  1. admin@cloud.com remote logon CNPVGVB1UT731 and try to access service ldap/CNPVGVB1CLD05.customer.com/customer.com, this time I can not get the token successfully, an error is shown up "SSPI InitializeSecurityContext error 0x80090311L"
SECURITY_STATUS sResult = InitializeSecurityContext(
                &hCredential,                               
                isFirstCall ? NULL : &m_contextHandle,       
                "ldap/CNPVGVB1CLD05.customer.com/customer.com",                  
                get_context_attribute(contextAttributeFlags),
                0,                                           
                SECURITY_NATIVE_DREP,                        
                isFirstCall? NULL:&inBuffDesc,               
                0,                                           
                &m_contextHandle,                            
                &outBuffDesc,                                
                &m_contextAttributes,                        
                &tsLifeSpan                                  
                );

I checked the kerberos package in Wireshark, I think there is something wrong about the kerberos requests, for my understanding the second TGS-REQ should be sent to the KDC of customer.com (10.58.117.105) not the KDC of cloud.com (10.58.117.63)

enter image description here

  1. manager@customer.com remote logon CNPVGVB1UT731 and try to access service ldap/CNPVGVB1UT726.cloud.com/cloud.com, this time I still get an error "SSPI InitializeSecurityContext error 0x80090311L", further more, I get nothing in my Wireshark, I don't know why there is no kerberos package in this test case

I am not sure if scenario 2 and scenario 3 is supported by this function InitializeSecurityContext, or is there any configuration I am missing or wrong? Any comments and help is appreciated and thanks in advance.

Addition information:

I think my domain trust setup is correct, because I write a java demo program that use admin@cloud.com to access ldap/CNPVGVB1CLD05.customer.com/customer.com, it works fine, my Wireshark capture shows all the kerberos packages are following the kerberos cross-realm authentication flow enter image description here

Supplement

I tried another scenario that create another AD (child.cloud.com) which is a sub domain of cloud.com, and use admin@cloud to access the ldap service (spn: ldap/CNPVGVB1CLD26.child.cloud.com/child.cloud.com) of child.cloud.com, I could get a successful token.

Solution

  • 0x80090311L error code reason:

    SEC_E_NO_AUTHENTICATING_AUTHORITY 0x80090311L The function failed. No authority could be contacted for authentication. This could be due to the following conditions: The domain name of the authenticating party is incorrect. The domain is unavailable. The trust relationship has failed.

    Ref: https://learn.microsoft.com/en-us/windows/win32/secauthn/acceptsecuritycontext--general

    Action List might be as follows:

    Check AD Trust Status from each domain using get-ADTrust | fl * powershell command. The older commands nltest and nedtdom may also be used for getting trust status.

    If all are OK test to access a share (e. from customer.com DC run \DC1.cloud.com\netlogon and vice-versa) from each other domain's DC. While accesing other domain's DC shares you may check Kerberos tickets with klist command.

    If file share access is normal from both sides only LDAP access is problematic then there may be issues with LDAP Windows Security Updates which introduces new configuration items and requirements for LDAP.

    Ref: https://support.microsoft.com/en-us/topic/2020-2023-and-2024-ldap-channel-binding-and-ldap-signing-requirements-for-windows-kb4520412-ef185fb8-00f7-167d-744c-f299a66fc00a