Ever wonder what LDAP calls SiteMinder is really making to your directory? After reading this post you will understand the basics behind View Contents, Authentication and Authorization, and you will be able to mimic these functions using a command line ldapsearch.  You will also know about all the connections that SiteMinder holds open to the LDAP and what those connections are used for.

First the basics on ldapsearch:

ldapsearch is always in the format:

• ldapsearch <switches such as -h, -b, etc> <search filter> <attribute(s)>

The search filter must appear after all of the switches, and is not prefixed by a switch of its own.  After that, if you do not want the entire record, you can specify what attribute(s) you do want returned.

The letters in the following pics will be used throughout the doc when illustrating how to mimic SiteMinder functions with a command line ldapsearch.

Fig. 1

Fig. 2

View Contents:

NOTE:  Clicking “View Contents” while inside a User Directory is identical to the behavior when you click the “Add/Remove” button while inside a Policy.

This function ONLY uses the Server field and the Root field, it does NOT use the LDAP User DN Lookup fields.

By default, it executes 5 ldap searches against the directory:

objectclass=organization

objectclass=organizationalunit

objectclass=group

objectclass=groupofnames

objectclass=groupofuniquenames

This is ONLY to populate the first window that comes up for View Contents.  Any other objects can be found using the binoculars, and doing a search.

To mimic “View Contents” with ldapsearch:

ldapsearch -h A -b B -D E -w F (objectclass=organization) dn

ldapsearch -h A -b B -D E -w F (objectclass=organizationalunit) dn

etc.

Fig. 3

Quite often, one or more of these searches will return a sizelimit or adminlimit exceeded error.  This error is being returned by the ldap, and could be resolved on the ldap side by increasing the limit of objects that are allowed to be returned by the Administrative user that is configured in your User Directory object.  The other solution is to stop the policy server from doing a search for that specific objectclass when you click View Contents.  In the registry of the policy server, this is found under:

HKEY_LOCAL_MACHINE\SOFTWARE\Netegrity\SiteMinder\CurrentVersion\Ds\ClassFilters.

You can safely remove any of the entries from the LDAP entry in this registry key, and then when you click View Contents, you can still find any specific item by using the binoculars.

Fig. 4

Authentication:

Authentication uses all the settings on the Directory Setup tab.  It can either be a one or two part process, depending on the presence of parentheses in the Lookup Start and End.

2 step process:

If you DO use parentheses, then SiteMinder does a search first to obtain a list of DN’s that match the search.  This is the disambiguation phase of authentication.  Any attribute can be used in the search.

Fig. 5

For instance, if in Fig. 5 you use:

Start: (uid=

End: )

Then users will need to enter the value of their uid attribute in order to be found.

If you use:

Start: (mail=

End: )

Then users will need to enter their email address in order to be found.

Whatever the user types in at the prompt will get sandwiched between the lookup start and end when doing the ldapsearch.  No matter what attribute you use, Siteminder always ends up with a list of DN’s.  If SiteMinder finds 0 objects that match, then authentication fails, an OnAuthAttempt rules will fire if you have any.

To mimic the disambiguation phase of authentication using ldapsearch: (let’s call whatever the user entered at the prompt “userentry”):

ldapsearch -h A -b B -D E -w F CuserentryD dn

Once Siteminder has a DN (or list of DN’s) it is time to attempt a BIND.  It takes the first DN, and attempts a BIND with the password entered by the user at the prompt.  If that fails, then it tries the next DN.

If all BIND attempts fail, then authentication fails, and OnAuthReject rules will fire if you have any.

1 step process:

If you DO NOT use parentheses in the lookup start and end, then it is assumed that ALL of the users who will be authenticating have IDENTICAL DN’s, except for whatever will be entered at the prompt.  There is no search executed.  Whatever the user types at the prompt will be sandwiched in between the lookup start and end, and this will be considered a valid DN to bind to the directory.

Fig. 6

In Fig. 6, if the user enters jdoe when prompted, the dn will be constructed as:

uid=jdoe,ou=users,dc=cb,dc=com

and then the BIND is issued.

If it fails, then authentication fails, and OnAuthReject rules will fire if you have any.

This is a much faster method of authentication, but is rare, as customers VERY rarely have all of their users under one container (ou) in the directory.

Authorization:

The authorization service uses none of the settings on the Directory Setup tab, other than the Server field.  Once you are in the authorization process, SiteMinder already knows the user’s DN, so there are no “user lookups” during authorization.  The authorization service is responsible for proving whether or not the DN that was handed to it has a “binding” to the object that was put into the policy.

The way that authorization proves or disproves this depends on the objectclass of the object that you add into your Policy object.  When you add something, the first thing SiteMinder does is check the objectclass, and you can see it in the window as below.

Fig. 7

This objectclass is then mapped to a “type” using the registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Netegrity\SiteMinder\CurrentVersion\Ds\PolicyResolution

Fig. 8

This “type” tells the authorization service how to accomplish the authorization of the user.  The two most common types are type 2 “Group” style authorization, and type 5 “DN” style authorization.

TYPE 2:

Type 2 means that SiteMinder will do a search through the group object to see if the user is a “member” or “uniquemember” of the group.  SiteMinder sends a “true/false” search to the directory, to see if the group has a member who matches the DN of the user who is trying to authorize:

ldapsearch -h <IP of directory> -b “cn=managers,ou=groups,dc=cb,dc=com” -D “uid=SMAdminUser,ou=admins,dc=cb,dc=com” -w <password> (uniquemember=uid=jdoe,ou=internal,dc=cb,dc=com)

A group object looks like the following:

dn: cn=managers,ou=groups,dc=cb,dc=com

objectclass: top

objectclass: groupOfUniqueNames

cn: managers

ou: groups

description: All corporate managers

uniqueMember: uid=sso,ou=internal,dc=cb,dc=com

uniqueMember: uid=jdoe,ou=internal,dc=cb,dc=com

NOTE:  this is a groupOfUniqueNames, so the members will be called “uniquemember”s.  If it was a group, or groupOfNames, the members would likely be listed as “member”s.  But the process is the same, and as you can see in fig. 8, they are all type 2.

In this case, the group only has two users in it, uid=sso and uid=jdoe.  So if you put the managers group in your policy, either of those 2 users would be able to authorize.

Special case: Active Directory

In Active Directory, when you add a user to a group, it does not just modify the group object to add the user as a member, but it also modifies the user object and lists the group(s) that he is a member of.  SiteMinder uses this to its advantage.  When dealing with AD, and using a Group in your policy, SiteMinder will query against the user object who is trying to authorize, and look at the “memberof” attributes to see if the user belongs to the group contained in the policy:

ldapsearch -h <IP of directory> -b “cn=jdoe,dc=myAD,dc=com” -D “cn=ADAdminUser,ou=admins,dc=myAD,dc=com” -w <password> (memberof=cn=administrators,dc=myAD,dc=com)

TYPE 5:

Type 5 means that SiteMinder will compare the end of the users DN to whatever is in the policy, working from right to left.  When a user is “in” an ou, it means that that ou appears in their DN.  This is a very quick process for the authorization service, because no search needs to be sent to the directory.  The string comparison is done in the authorization service itself.  So, in fig. 7, if you just had ou=users,dc=cb,dc=com in your policy, then the user:

uid=sso,ou=users,dc=cb,dc=com WOULD authorize.

And:

uid=chris,ou=support,ou=users,dc=cb,dc=com WOULD authorize.

But the user:

uid=jdoe,ou=managers,dc=cb,dc=com WOULD NOT authorize.

TYPE 1:

Type 1 means that you have put an actual “user” into your policy.  An object who has objectclass=User, or objectclass=person, or objectclass=orgperson, or objectclass=inetorgperson.

This type of authorization is very similar to TYPE 5, as the processing is done inside the authorization service, and does not go to the directory at all.  For TYPE 1, SiteMinder compares the entire DN of the user to the DN that was put into the policy.

TYPE 3:

Type 3 means that SiteMinder will check the user’s record for a certain attribute/value pair.  So in fig. 7, if you just had (l=US) in the policy, then SiteMinder would check the user’s record to see if they have that attribute/value pair.  This is another “true/false” search with a base DN that starts at the user’s record, and only matches if the attribute/value pair is present:

ldapsearch -h <IP of directory> -b uid=jdoe,ou=users,dc=cb,dc=com -D “uid=SMAdminUser,ou=admins,dc=cb,dc=com” -w <password> (l=US)

TYPE 7 (all):

Type 7 is a special case, and is an undocumented feature.  It is not even in the registry, and it simply means that EVERY authenticated user will automatically be authorized.  If you would like every user to authorize, as long as they successfully authenticated, then put the word all into the Manual Entry field, and click the Add button.

Connections:

Siteminder holds 3 connections open to each LDAP user directory.  They are as follows:

DIR: This connection is held open by the user who is configured in the “Credentials and Connections” tab of the User Directory.  The initial search for users in authentication is done over this connection, and any WRITE operations (due to Password Services) are also done over this connection.  There are a lot of questions about what permissions the Admin user needs to have, and it’s simple… if you will not be using Password Services, then the user just needs to have READ permissions to the section of the user directory where your users are (whatever you put in the Root DN of the directory).  If you will be using Password Services, then that user needs to at least have the same READ permissions, and also have WRITE permissions to the attributes in the User Attributes tab of the user directory.

USR: This connection is used by authentication to try the BINDs.  No other data is sent across this connection.  A BIND is attempted and if it works, then the user is authenticated.  The connection is left in that state, owned by the user who just bound.  When the next authentication attempt is made, the handling depends on the type of directory.  If the directory supports REBIND, then that is what is done, meaning the connection is never broken down, it is just overtaken by the new BIND.  If the directory does not support REBIND (like AD), then the connection is Unbound and then a BIND is performed with the new user.

PING: This connection is used to monitor the health of the directory.  It sends a very basic search to the directory.  If it gets a response, then the directory is considered healthy, so the Policy Server will continue to send requests there.

The search has a blank Root DN, a scope of “base”, and looks for objectclass=*.  According to LDAP spec (RFC 2251), all compliant LDAPs will return some basic info about itself and its capabilities when a query is received with those parameters:

ldapsearch -h <IP of directory> -b “” -s base objectclass=*

Tags: Active Directory, LDAP, Radiant Logic, siteminder, VDS, Virtual Directory

This entry was posted on Friday, June 26th, 2009 at 3:20 pm and is filed under Identity and Access Management. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.