InitializeSecurityContext (Kerberos) in cross domain forest

Question

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:

• two domain cloud.com (IP of KDC: 10.58.117.63) and customer.com (IP of KDC: 10.58.117.105)
• two-way domain trust, means cloud.com and customer.com trust each other
• two domain users, [email protected] of domain cloud.com. [email protected] of domain customer.com
• two service principal name of ldap service, ldap/CNPVGVB1UT726.cloud.com/cloud.com in domain cloud.com, ldap/CNPVGVB1CLD05.customer.com/customer.com in domain customer.com
• one Windows machine (hostname: CNPVGVB1UT731) belongs to domain cloud.com, grant the remote logon privilege both for user [email protected] and [email protected]

Test Scenarios

1. [email protected] 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                                  
                );

2. [email protected] 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)

3. [email protected] 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 [email protected] 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

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.

Answer 1

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 DNS Server IP address setting of each Domain Controller. Each DC (DNS) server DNS IP Address should point to itself.
• In customer.com DNS Server, there should be a conditional forwarder zone pointing to DNS server of cloud.com domain DNS Server (DC IP)
• In cloud.com DNS Server, there should be a conditional forwarder zone pointing to DNS server of customer.com domain DNS Server (DC IP)
• Check name resolution from each domain so that each domain resolves other domain's DNS records. E.g. from customer.com DC ping DC1.cloud.com verifying each resolves to expected IP addresses.
• There should be no firewall rules that block AD Trust communication. Windows Server firewall also should permit AD / Trust communication if enabled Pls chk: https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/config-firewall-for-ad-domains-and-trusts

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