
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
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
Accepted Solutions

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
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

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
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

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
Thanks for the quick reply.
I will try the workaround by changing the authentication attribute in the kerberos classe.
Regards.
Sylvain

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
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