Real-life Tips on Configuring Kerberos for Authentication in Access Manager

Real-life Tips on Configuring Kerberos for Authentication in Access Manager

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.
Labels (1)

DISCLAIMER:

Some content on Community Tips & Information pages is not officially supported by Micro Focus. Please refer to our Terms of Use for more detail.
Comments
Hi

Thanks for your post. We have found the same issues and its always nice to know you not the only one out there with these problems.

R
Scenario 1 is actually a bit different than you have described. First, the value used for the search is always the UPN as it is received in the token. you can see this in the NAM log as:
amLogEntry> 2015-11-24T20:23:49Z VERBOSE NIDS Application: Performing LDAP search (&(userprincipalname=Adm@POINTBLUETECH.COM)(objectClass=User)) in context com.novell.nam.common.ldap.jndi.JNDIUserStoreSearchContext@2f294d15

The issue is that when the UPN prefix and the samAccountName differ then then windows never even sends the negotiate header. This can be confirmed in the trace.

Scenario 2 can be addressed by adding additional UPN suffixes to the Kerberos class configuration.
Regarding scenario1: In what version of NAM did you do this? When I set the User attribute to 'sAMAccountName', NAM is searching for:
(&(sAMAccoutName=@)(objectClass=User))

Since sAMAccoutName in AD doesn't contain the AD_Domain part, it never finds a hit. How did you convince NAM to remove the '@' part in the query?
HTML characters got dropped...
(&(sAMAccoutName=@)(objectClass=User))
should read
(&(sAMAccoutName=[sAMAccoutName]@[domain])(objectClass=User))
Hi,
This was back in 3.0 times, when there were these issue with kerberos, in 4.x most of them are fixed. In 3.0 you didn't have the option to set multiple UPN suffixes.
//t
Top Contributors
Version history
Revision #:
3 of 3
Last update:
‎2020-01-31 22:08
Updated by:
 
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.