This tip has to do with configuring and using Kerberos for authentication method in Access Manager in real life Active Directory environment.

Problem

After configuring Kerberos as described in Access Manager 3 Administration Guide, there are at least two scenarios when it doesn't work as it should, at least in environments where I have set them up.

Scenario 1

The user account in Active Directory has something different in the userPrincipalName attribute prefix from what is in sAMAccoutName. For example:

userPrincipalName = User1.Lastname@domain.local
sAMAccoutName = LastUser1

If this is the case, then Kerberos authentication seems to fail. The LDAP query made by Access Manager uses the sAMAccountName, as this is the name that it sees the user is logged in with.

Solution

Use sAMAccoutName instead of userprincipalname as the User Attribute in the Kerberos Class.

Scenario 2

In Active Directory there is defined Alternative UPN Suffixes field in Active Directory Domains and Trusts. For example, AD may use domain.local, and there may be an alternative UPN suffix defined, such as company.local. Users can then have this alternative suffix (such as User2.Lastname@company.local) in their userPrincipalName.

After setting the user account with the alternative suffix, Kerberos authentication for that user fails, because the suffix is wrong. The LDAP query made by Access Manager uses only the default Active Directory suffix.

Solution

Use the Identity Manager Active Directory driver to add the needed information to some other attribute in Active Directory, such as uid instead of userprincipalname. The content of the uid attribute should be the content of sAMAccoutName the Active Directory domain name. For example, this could be LastUser2@domain.local.