Skip to main content

Application Server Kerberos Configuration

Client support

  • LIDS Explorer connects to project URL ending with /WebFeatureServiceSSO instead of /WebFeatureService
  • There is no extra configuration of LIDS Explorer needed

Prerequisites

  • Keytab file present on server machine (for example http-server.keytab)
  • Kerberos config file for the server - krb5.ini (for documentation, see: MIT Kerberos documentation)

Testing Prerequisites Configuration

Checking that the krb5.ini File is Correct

You can check if JVM is able to communicate with KDC server. Use the kinit program from the JDK installation. Typically it can be found here: C:\Program Files\Java\jdk1.7.0_51\bin\

Test if you can connect to the KDC server using a domain account. You must have a domain account and password. Let's say we have account some.user in the MYDOMAIN domain. Open command line and run the following command:

kinit some.user@MYDOMAIN.COM

Type a password. If everything is configured properly, you will see something like:

New ticket is stored in cache file C:\Documents and Settings\some.user\krb5cc_some.user

Checking that the Keytab File is Correct

You can check if JVM is able to communicate with KDC server using the account specified in the keytab. Use kinit program again. Open command line and run the following command:

kinit -k -t c:\sso\server.keytab HTTP/server.mydomain.com@MYDOMAIN.COM

If the keytab is correct you will see something like:

New ticket is stored in cache file C:\Documents and Settings\some.user\krb5cc server.mydomain.com

If the password in the keytab is incorrect, you will get:

Exception: krberror 24 Pre-authentication information was invalid (24) Pre-auth
entication information was invalid
KrbException: Pre-authentication information was invalid (24)
at sun.security.krb5.KrbAsRep.<init>(KrbAsRep.java:66)
at sun.security.krb5.KrbAsReq.getReply(KrbAsReq.java:486)
at sun.security.krb5.KrbAsReq.getReply(KrbAsReq.java:444)
at sun.security.krb5.internal.tools.Kinit.sendASRequest(Kinit.java:310)
at sun.security.krb5.internal.tools.Kinit.<init>(Kinit.java:259)
at sun.security.krb5.internal.tools.Kinit.main(Kinit.java:106)
Caused by: KrbException: Identifier doesn't match expected value (906)
at sun.security.krb5.internal.KDCRep.init(KDCRep.java:133)
at sun.security.krb5.internal.ASRep.init(ASRep.java:58)
at sun.security.krb5.internal.ASRep.<init>(ASRep.java:53)
at sun.security.krb5.KrbAsRep.<init>(KrbAsRep.java:50)
... 5 more

Troubleshooting

Error: 'Cannot get kdc for realm MYDOMAIN.COM'

Check that your krb5.ini is configured properly. You must have the kdc parameter correctly specified:

[realms]
MYDOMAIN. COM = {
kdc = my-kdc-server.mydomain.com:88
default_domain = mydomain.com
}

Is Client Sending NTLM Negotiate Header Instead of Kerberos?

The Negotiate header sent from the client is visible in lidsAS.log.

  • If the Authorization token begins with YII then Kerberos is used
  • If it begins with TlR then Kerberos is not used

Kerberos example:

Authorization: Negotiate YIIVDAYGKwYBE...

Not Kerberos (NTLM) example:

Authorization: Negotiate TlRMTVNTUA...

SSO Can't be Checked on the Server Directly

info

If the client application is running on the same computer as the Application server, it never communicates using Kerberos. It always uses NTLM.

Environment Properties

info

All properties can start with kerberos instead of lids.kerberos. If both are defined, the lids.kerberos property takes precedence.

PropertyTypeRequired for Kerberos authenticationDescriptionExample value
lids.kerberos.sso.enabledbooleantrue (default false)Enable Kerberos SSO authentication (default false)true
lids.kerberos.sso.principalstringtrueKerberos SSO PrincipalHTTP/server.domain@DOMAIN
lids.kerberos.sso.keytabstringtrueKerberos SSO keytab file pathC:/Software/sso/server.keytab
lids.kerberos.sso.krbconfstringfalseKerberos SSO configuration file pathC:/Windows/krb5.ini
lids.kerberos.sso.debugbooleanfalse (default false)Print Kerberos authentication debug output (default false)true