Windows API InitializeSecurityContext throws 0x80090311 error in a cross domain env

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, admin@cloud.com of domain cloud.com. manager@customer.com 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 admin@cloud.com and manager@customer.com

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                                  

                );

2. 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)

3. 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? Do I do it wrong about InitializeSecurityContext? If I am wrong, what I should do for scenario 2 and scenario 3? 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

Answer 1

Get answer on StackOverflow