- Version: sonarqube-10.8.1.101195
- Deployed: From Zip
- Goal: LDAP integration via Kerberos V5 / GSSAPI
- Tried: validated LDAP Bind CN with with succesfull LDAP search
- Tried: Setting the Kerberos principal using the -Dsun.security.krb5.principal= Java additional option
- Tried: using custom JAAS confiuration file and with valid keytab specification -Djava.security.auth.login.config=jaas.conf
When specifyig the valid CN for the Bind technical user the following error is displayed:
Caused by: sun.security.krb5.KrbException: Client not found in Kerberos database (6)
at java.security.jgss/sun.security.krb5.KrbAsRep.<init>(Unknown Source)
at java.security.jgss/sun.security.krb5.KrbAsReqBuilder.send(Unknown Source)
at java.security.jgss/sun.security.krb5.KrbAsReqBuilder.action(Unknown Source)
... 120 common frames omitted
Caused by: sun.security.krb5.Asn1Exception: Identifier doesn't match expected value (906)
at java.security.jgss/sun.security.krb5.internal.KDCRep.init(Unknown Source)
at java.security.jgss/sun.security.krb5.internal.ASRep.init(Unknown Source)
at java.security.jgss/sun.security.krb5.internal.ASRep.<init>(Unknown Source)
Obserations are:
- JAAS configuration is not honored when provided via -Djava.security.auth.login.config
- When lda.binDn is used with Bind DN the error persists
- Based on LDAP plug-in code posted at: sonar-ldap/sonar-ldap-plugin/src/main/java/org/sonar/plugins/ldap/LdapContextFactory.java at master · SonarSource/sonar-ldap · GitHub
Used the user id instead:
Using the user id passes the principal to the Kerberos and principal error is resolved.
The observation is:
- the bindDn is documented as a need for distinguished LDAP entry and needed for the binding
- Kerberos expects a user id not a DN and having to use the username for the bindDn is not fully documented and it is enforced by the current implementation of LDAP integration
- To get a success combination: the ldap.binDn set the the distinguished name and the Java Property -Dsun.security.krb5.principal have to be specified together
The request is point to documentation that explains the reasoning to have the binDn having to be the Kerberos principal and not the LDAP distinguished name.
Please advise.