Admiral
Admiral
516 views

After upn suffix changed in AD , seems NAM kerberos SSO no longer work

Jump to solution

Hi,

My configuration is NAM 4.3.3 on Windows 2012R2. 

The IDS is configured with local authentication on AD and Kerberos.

There are several reverse proxy that use Kerberos Auth Method.

Recently, we start changing UPN in AD for some users and these users can no longer SSO to the web applications, but are required to enter username and password.

SSO is still working for other users with the legacy UPN.

I don't see any error in the IDS log and in the reverse proxy log.

Thanks

Sylvain

 

1 Solution

Accepted Solutions
Vice Admiral
Vice Admiral

I assume that previously UPN attribute was in format <sAMAccountName>@<ad domain> and now you're changing UPN format.

If you look at kerberos authentication, it happens like this (simplified):

1) User wants to access URL

2) NAM responds with HTTP/401 and requires kerberos token

3) Client asks AD DC (Kerberos distribution center) for kerberos token for NAM

4) Client sends token to NAM

5) NAM extracts user information from kerberos token

6) NAM searches user store for information extracted from kerberos token, to identify user

 

When you've configured kerberos you've also configured which AD attribute NAM should use to check kerberos token. By default this is userPrincipalName (https://www.netiq.com/documentation/access-manager-45/admin/data/b9uctt5.html#kerberosclassprop, field "User Attribute"). This is attribute NAM uses in step 6.

Problem is that user information in kerberos token is in format <sAMAccountName>@<kerberos realm> (or in Microsoft world, <sAMAccountName>@<ad domain>), not in format <userPrincipalName>.

As long as you had "legacy UPN" (format <sAMAccountName>@<ad domain>), NAM was able to match kerberos token information with attribute value. But since you have changed value of userPrincipalName to something else, NAM now cannot find respective user in AD.

So there are two solutions:

1) Do not change UPN (which is probably not possible 😊)

2) Define some other user's attribute in AD which will hold value <sAMAccountName>@<ad domain> and reconfigure Kerberos calss on NAM server

 

Kind regards

Sebastijan

 

 

 

 

View solution in original post

3 Replies
Vice Admiral
Vice Admiral

I assume that previously UPN attribute was in format <sAMAccountName>@<ad domain> and now you're changing UPN format.

If you look at kerberos authentication, it happens like this (simplified):

1) User wants to access URL

2) NAM responds with HTTP/401 and requires kerberos token

3) Client asks AD DC (Kerberos distribution center) for kerberos token for NAM

4) Client sends token to NAM

5) NAM extracts user information from kerberos token

6) NAM searches user store for information extracted from kerberos token, to identify user

 

When you've configured kerberos you've also configured which AD attribute NAM should use to check kerberos token. By default this is userPrincipalName (https://www.netiq.com/documentation/access-manager-45/admin/data/b9uctt5.html#kerberosclassprop, field "User Attribute"). This is attribute NAM uses in step 6.

Problem is that user information in kerberos token is in format <sAMAccountName>@<kerberos realm> (or in Microsoft world, <sAMAccountName>@<ad domain>), not in format <userPrincipalName>.

As long as you had "legacy UPN" (format <sAMAccountName>@<ad domain>), NAM was able to match kerberos token information with attribute value. But since you have changed value of userPrincipalName to something else, NAM now cannot find respective user in AD.

So there are two solutions:

1) Do not change UPN (which is probably not possible 😊)

2) Define some other user's attribute in AD which will hold value <sAMAccountName>@<ad domain> and reconfigure Kerberos calss on NAM server

 

Kind regards

Sebastijan

 

 

 

 

View solution in original post

Admiral
Admiral
Hi Sebastijan,
Thanks for the quick reply.
I will try the workaround by changing the authentication attribute in the kerberos classe.
Regards.
Sylvain
Admiral
Admiral

Hi Sebastijan,
Changing the attribute did not help in my configuration, but reading the documentation link you provided, I found that there is an option for additional suffix.
Adding a new suffix in the Kerberos class property seems to fix this issue.
Thanks a lot for your help.
Sylvain

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.