Symantec SiteMinder

This is a common question in Single Sign-On space.

I would highly recommend setting up the use case and test it yourself because nothing is better than seeing the behavior in your familiar setup.

In my case, I am using AD as userstore.

It has the following users which the CN is the same.

Yes, if you have AD as userstore, it would be advisable to use samaccountname to search the user.

But for demonstration purpose, I will be searching "CN" value so it can return 2 UserDN as below.

UserStore is configured as below.

I created a generic realm/rule/policy to protect /MultipleUserDN/ resource.

Above is a "CN=user1,OU=People,DC=sso,DC=lab" being authenticated.

Above is for "CN=user1,CN=Users,DC=sso,DC=lab".

So, depending on which user's password you enter, that maching user will be authenticated.

Next question is... what happens if user1 enters wrong password that does not match either of the users.

The user is not authenticated. It doesn't look too bad, right?

NO!

Let's move into the complicated and problematic use case.

What if you have password policies to lock out the user if they submit wrong password for 3 consecutive times?

Now that I have your attention, let's look at the smps.log before we go further.

#1. Initially I logged in as "CN=user1,OU=People,DC=sso,DC=lab"

#2. Then login as "CN=user1,OU=Users,DC=sso,DC=lab"

#3. Lastly, I logged in with wrong password that does not match either users.

For #1, although 2 UserDNs were returned, because the first userDN("CN=user1,OU=People,DC=sso,DC=lab") was able to successfully BIND with the password, the next userDN was not tried.

As a result, in the smps.log you do not see "Error 49" for any user.

** The order of which UserDN returns first cannot be expected. It may be different on every request.

For #2, this time the first UserDN(This time it was "CN=user1,OU=People,DC=sso,DC=lab") did not successfully BIND using the password so it logs "Error 49" and continue to try with the next UserDN.

As a result, in the smps.log, you will see "Error 49" for "CN=user1,OU=People,DC=sso,DC=lab"

For #3, regardless of in which order the 2 UserDNs were returned, they all failed to BIND.

As a result, you will see "Error 49" for both users.

Let's see what happens when you have password policy.

Following password policy is created.

As you can see that this only applies to "CN=User1"

AD has its native password policy but SiteMinder password policy will trigger first because AD is not configured to lock out users due to incorrect passwords.

I will perform the same test above.

#1. First UserDN("CN=User1,OU=People,DC=sso,DC=lab") was able to BIND successfully so there was no "Error 49".

As a result, password policy does not update any failed login attempt.

#2. First UserDN("CN=User1,OU=People,DC=sso,DC=lab") fails to BIND so "Error 49" is logged.

Next UserDN("CN=user1,CN=Users,DC=sso,DC=lab") was able to BIND.

As a result, "CN=User1,OU=People,DC=sso,DC=lab" will have invalid login count raised.

You can see from above smtracedefault.log (using authentication_trace.template) that both users get "Have 1 Password Policies to apply" message.

But only the first UserDN gets "Incrementing Failed Login Attempts Counter" message.

Now you can imaging what will happen when the "CN=user1,CN=Users,DC=sso,DC=lab" successfully authenticates several times exceeding the password policy.

As you can see from above, "CN=user1,OU=People,DC=sso,DC=lab" got locked out.

This is not a desired outcome but this is a special condition that customers should avoid in the first place.

It is not recommended to have multiple users returned during user search.

So, (CN=%s) user search in the userstore configuration is not a good thing.

If you configured the userstore to query (samaccountname=%s) then it would have returned just 1 user so this condition could have been avoided.

(You can also imagine more troublesome use cases, what if both users have SAME password??? Well, don't go there! Avoid it where you can.)

(What if both users forgot their password? Don't go there )

It is by design but even without testing this, you would be able to guess that there would be no way Policy Server can determine which user to update for failed password.

For #3, both users would have their "Failed Login Attempts Counter" increased.

As you can see from above, "CN=user1,OU=People,DC=sso,DC=lab" is already disabled.

"CN=user1,CN=Users,DC=sso,DC=lab" had "Failed Login Attempts Counter" increased.

There are some ways to avoid having multiple users being returned in case if you cannot avoid this situation.

You can use additional attributes to Authenticate in addition to the userID and Pwd.

Please refer to my previous post below.

Configuring an ALL-IN-ONE VM Image - Part 4

It has a section for "HTML using UID and EMAIL".

Instead of having users to enter the additional attribute, you can actually make it a dropdown menu.

So, instead of using "email" attribute, you can use "Department" attribute and can select their department such as "Finance" or "Sales".

That way, you should be able to search for a user and get only 1 userDN in return.

Hope this helps!