Why does LDAP think the user already exists? This is the first time we were able to connect to AD to configure Kerberos.

[#1]

javax.naming.NameAlreadyBoundException: [LDAP: error code 68 - 00002071: UpdErr: DSID-0305038D, problem 6005 (ENTRY_EXISTS), data 0
^@]; remaining name 'cn=prodcluster-102015,ou=Hadoop,dc=corp,dc=ds,dc=client,dc=com'
        at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3082)
        at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3033)
        at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2840)
        at com.sun.jndi.ldap.LdapCtx.c_createSubcontext(LdapCtx.java:811)
        at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_createSubcontext(ComponentDirContext.java:337)
        at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.createSubcontext(PartialCompositeDirContext.java:266)
        at javax.naming.directory.InitialDirContext.createSubcontext(InitialDirContext.java:202)
        at org.apache.ambari.server.serveraction.kerberos.ADKerberosOperationHandler.createPrincipal(ADKerberosOperationHandler.java:319)

[#2 · Accepted solution]

Could you check pdErr: DSID-0305038D, problem 6005?

68LDAP_ALREADY_EXISTSIndicates that the add operation attempted to add an entry that already exists, or that the modify operation attempted to rename an entry to the name of an entry that already exists.

[#3]

Based on the error it does seem that the principal already exists. I would have the AD admin look in that OU to confirm that the user is not there.

[#4]

@terry@hortonworks.com this principal is created during the kerberos client test in the AD wizard. You can tell by the naming structure: {{cluster name}}-{{month}}{{day}}{{year}}. This is create by Ambari to test that a.) we can create principals, and b.) we can use them to successfully authenticate from a client.

I would remove this entity from the OU, double-check that the time is correct on the AmbariServer and re-try running through the wizard.

[#5]

paul@hortonworks.com The AD config was a bit tricky at the client site and one of our failed Kerborization attempts created an LDAP entry. The naming convention lined up with the above structure, so we deleted the entry and waited for the deletion to replicate. Then we gave it another shot and were successful.

[#6]

To follow up, the user was created earlier and once the AD administrator deleted it we were able to proceed. We must have had an earlier failure that did not clean up well.

This seems to indicate the Kerberos setup is not; 1) doing a check of existing users first, and 2) not attempting to do a delete existing/create again operation, instead of a create.