CA SiteMinder comes out of the box ready to deal with all of the most common LDAP objectclasses. But if you extend your LDAP schema and create a custom objectclass for your users and/or groups, then depending on what you are putting in your policies, SiteMinder may fail on the authorization attempt. Or you might not even be able to find your custom object in the UI when trying to add it to your policies. This can be resolved, but it’s not covered in the SiteMinder documentation. So let’s dig in a little… There are 2 sections here: First, teach SiteMinder how to handle the new objectclass during authorization. Second, make sure the UI can find those objects so that you can add them to your policies.
NOTE: All of the registry keys I mention below are in the same path: HKEY_LOCAL_MACHINESOFTWARENetegritySiteMinderCurrentVersionDs If your policy server is on UNIX, navigate to /siteminder/registry/, open the sm.registry file, and find the /Ds section.
Section I: Teach SiteMinder how to handle the new objectclass during authorization:
In my last SiteMinder-->LDAP article, How SiteMinder Interacts with LDAP, I covered the different “types” of authorization. In this article, we are going to discuss type 1 (person/user) and type 2 (group) since these are the most common things to be extended upon in LDAP. Let’s start with a review of the registry key that controls this: PolicyResolution
Notice that anything that logically seems like a person is a type 1. inetOrgPerson, organizationalPerson, person, residentialPerson, and User.
So, as you would assume, if you’ve created a new objectclass for your individual users, you need to:
- Create a new DWORD under this registry folder
- Name it whatever the name of your custom user objectclass is
- Give it a value of 1.
You’ve just told SiteMinder that any time it sees the CBCustomPerson objectclass in a policy, treat it just like an inetOrgPerson or a User.
Now let’s move on to groups, which is slightly more complicated. Again, notice from the pic above that anything that logically seems like a group is a type 2. Group, groupOfNames, groupOfUniqueNames.
Just as with the users, you’d do the same thing, but with a 2 instead.
- Create a new DWORD under this registry folder
- Name it whatever the name of your custom group objectclass is
- Give it a value of 2.
You’ve just told SiteMinder that any time it sees the CBCustomGroup objectclass in a policy, treat it just like a Group, or groupOfNames. What does it mean to “treat it just like a Group”? Reference my last SiteMinder-->LDAP article again. It means to check whether the user who is trying to authorize is a “member” or “uniquemember” of that group object.
Then, to tell SiteMinder that there is a new group style objectclass in the mix, you need to add it to the GroupClassFilters registry key.
So during authorization, which does it look for, member or uniquemember? This requires one more step. The answer to that question lies in the LdapMatchUserDN registry key.
You can see that for a Group, SiteMinder is going to look for member. For a groupOfNames/groupOfUniqueNames, SiteMinder is going to look for uniqueMember.
So you need to create a new string entry here, that has a name of your custom group objectclass, and the value tells SiteMinder how your custom group holds its users. In other words, when you add a user to a custom group object, does he go in as a member or a uniquemember? In the pic below I have told SiteMinder that my custom group holds its users as members.
That covers the logic that SiteMinder will use for authorization. Now we need to cover the UI part.
Section II: Make sure the UI can find the custom objectclass:
How do we add that user or group into a policy? Will the UI find that user or group if we do a lookup?
The items that automatically get populated to the screen when you click the Add Members button (Add/Remove Users button in the 6x UI) are all of the objectclasses listed in the ClassFilters registry key (again, see my last SiteMinder-->LDAP article for details). So if you want your custom objectclass objects to show up there, add it to that list.
Here you can see that my custom group showed up in the list without doing any searches, and it recognizes the objectclass.
Normally, you would want to put group type objectclasses in the ClassFilters key so that they all show up as soon as you click Add Members. But you wouldn’t want to do this for user type objectclasses, since there are probably thousands of users in your LDAP, you don’t want the UI trying to populate all of them to that initial window.
Which brings us to lookups…
When you click the “Go” button above, SiteMinder sends a search to the directory for (uid=joncustomguy), but it qualifies it, with all of the objectclasses that are in the PolicyClassFilters registry key.
By default the search sent to the LDAP would look like: (&(uid=joncustomguy)(|(objectclass=organizationalPerson)(objectclass=inetOrgPerson) (objectclass=organization)(objectclass=organizationalUnit)(objectclass=groupOfNames) (objectclass=groupOfUniqueNames)(objectclass=group)))
If you want your custom objectclass objects to be found when you do a lookup, then you will need to add your custom objectclass into the PolicyClassFilters list.
Now notice that the UI did find the user I was searching for, and it recognizes his objectclass.
That’s it! SiteMinder should now play nicely with your custom objectclasses. Good luck!
[Photo credit: Yoel Ben-Avraham via Flickr]