3

I have a server process running on a machine KERBOS.COM and its trying to connect to a LDAP Server in IN.KERBOS.COM(Sub Realm) to sync user using GSSAPI Mechanism.

By looking at GSSLOGS we can see that
the spn its trying to authenticate belong to KERBOS.COM ldap/invr28ppqa36.in.kerbos.com@KERBOS.COM Is this any way to make it pick IN.KERBOS.COM as realm.

The default realm has to be KERBOS.COM in krb5.conf . So changing the default realm to IN.KERBOS.COM is not an option.

I am also giving it fully qualified name so there should be some way to tell it to use IN.KERBOS.COM as realm. 

env.put(Context.PROVIDER_URL, String.format("ldap://%s:%d", host, port));

Subject subject = new Subject();
subject.getPrivateCredentials().add(credential);
InitialLdapContext object  = Subject.doAs(subject, new PrivilegedExceptionAction<InitialLdapContext>() {   
  public InitialLdapContext run() throws Exception {                                
    env.put(Context.SECURITY_AUTHENTICATION, "GSSAPI");
    return new InitialLdapContext(env, null);
} });

LOGS

Subject.doAs fails by throwing an exception (Intercept from Logs are given)
Found ticket for **sysadmin@IN.KERBOS.COM to go to krbtgt/IN.KERBOS.COM@IN.KERBOS.COM**  Credentials acquireServiceCreds: obtaining service creds for **ldap/invr28ppqa36.in.kerbos.com@KERBOS.COM**
Using builtin default etypes for default_tgs_enctypes
default etypes for default_tgs_enctypes: 17 16 23 1 3.
KrbException: Fail to create credential. (63) - No service creds
    at sun.security.krb5.internal.CredentialsUtil.acquireServiceCreds(CredentialsUtil.java:301)
    at sun.security.krb5.Credentials.acquireServiceCreds(Credentials.java:442)
    at sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:641)
    at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
    at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
    at com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(GssKrb5Client.java:193)
    at com.sun.jndi.ldap.sasl.LdapSasl.saslBind(LdapSasl.java:123)
    at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:232)
    at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2740)
    at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:316)
    at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:193)
    at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:211)
    at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:154)
    at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:84)
    at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
    at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307)
    at javax.naming.InitialContext.init(InitialContext.java:242)
    at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:153)
    at (LDAPConnector.java:101)
AurA
  • 12,135
  • 7
  • 46
  • 63
Deepak Kumar
  • 161
  • 1
  • 6

1 Answers1

2

By default a Kerberos implementation will start at the KDC of the client realm, hoping that KDC can provide a cross-realm referral to the service realm. So, you have a ticket in EXAMPLE.COM, and you're going to a host called server.subdomain.example.com. Your client is supposed to go to the EXAMPLE.COM KDC. That KDC can either say that it knows how to give you a service ticket, or can give you a special referral ticket to get closer to the service; in this example you'd kind of expect it to give you a krbtgt/SUBDOMAIN.EXAMPLE.COM@EXAMPLE.COM realm. That tells your client to go to the subdomain.example.com KDC.

Apparently, your KERBOS.COM KDC doesn't know that your LDAP server is served by the IN.KERBOS.COM realm. One way you could solve things is by fixing your KDC. That's going to be dependent on what KDC software you have. Alternatively, you can edit your krb5.conf and tell your client that everything under in.kerbos.com is served by the IN.KERBOS.COM KDC. Add a section like the following to your krb5.conf:

[domain_realm]
.in.kerbos.com = IN.KERBOS.COM

See this as an example of discussing krb5.conf including domain_realm sections in Java. See RFC 6806 for technical details of how the referrals should work.

Community
  • 1
  • 1
Sam Hartman
  • 6,210
  • 3
  • 23
  • 40