How To: Look Up Users by UPN Instead of SamAccountName for WSTrust Password Verification

Version Affected: All

 

Overview

This article explains how to change the way the WSTrust (WS-Trust) endpoint looks up a user during password verification.

By default, when the WSTrust endpoint receives a password verification request, it removes the User Principal Name (UPN) suffix and looks up the remaining value as the SamAccountName. For example, for awood@example.com, it removes @example.com and looks up the user as SamAccountName=awood. This does not work when the UPN and SamAccountName do not correspond this way — for example, if the UPN is andrew.wood@example.com but the SamAccountName is awood, simply removing the UPN suffix is not enough to find the user.

Look Up Users by UPN Instead of SamAccountName

Depending on your environment, you may need to disable the default SamAccountName lookup so the user is instead searched for using the UPN exactly as received. This is a two-part change: update the Datastore's search filter, and edit the realm's web.config so it stops removing the UPN suffix.

1. Edit the Datastore used by the realm and update its search filter. For example, if it currently searches on SamAccountName only and you want it to check both SamAccountName and UPN, set the search filter to:

(&(objectclass=user)(|(samAccountName=%v)(userPrincipalName=%v)))

2. In the Admin Console, go to Advanced Settings > Tools > Decrypt Web.config.
3. Select the realm in question and click Decrypt.
4. Open the realm's web.config in a text editor — for example, D:\SecureAuth\SecureAuthX\Web.config.
5. Find the key:

<add key="WSTrustValidateWithSamAccountName" value="True" />

6. Change its value to False:

<add key="WSTrustValidateWithSamAccountName" value="False" />

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.