• smpolicysrv -publish <name of XML file>
• smpolicysrv -stats

where <name of XML file> is the file where you want to export the Policy Server statistics.

The publish command kicks out the following data:

• Policy Servers
• Policy/Key Stores
• User Directories
• Agents
• Custom Modules

while the stats command exports a subset of that data into the smps.log file.

The Policy Server Administration Guide contains the following details:

Note: On Windows systems, do not run the smpolicysrv command from a remote desktop or Terminal Services window. The smpolicysrv command depends on inter-process communications that do not work if you run the smpolicysrv process from a remote desktop or Terminal Services window

Important! Before running a SiteMinder utility or executable on Windows Server 2008, open the command line window with administrator permissions. Open the command line window this way, even if your account has administrator privileges. For more information, see the release notes for your SiteMinder component.

However, this does not seem to work.  Since the Policy Server service by default is running as System, you get the message “The specified server is not currently running” when trying to run the command.  You can start the service as a different user, but that was not the direction I wanted to take.  So, the next step was to try and get a CMD window which was running as System so that I could execute the command.  After trying various methods (runas, using “at” to launch a CMD window, etc.) those failed to produce the result I need.  Changes in Windows 2008 prevented some of the hacks that worked in previous versions of the OS.

The answer was to use psexec from Sysinternals (now Microsoft) which allows you to run things from the command line as system. The tool is part of the PsTools suite at the following URL:

http://technet.microsoft.com/en-us/sysinternals/bb896649

Once psexec was installed in a directory in the Windows PATH, I completed the following steps to publish the Policy Server statistics:

1. Open regedit and set the HKEY_LOCAL_MACHINE\SOFTWARE\Netegrity\SiteMinder\CurrentVersion\Publish key to the file location and name for the XML file
2. Open a CMD prompt (I used the one is C:\Windows\SysWOW64\cmd.exe (right-click and select Run as administrator)
3. Enter the following command: psexec -s “<SiteMinder Home>\bin\smpolicysrv” “-publish”

where <SiteMinder Home> is the install location of the Policy Server.  You will now get the published XML file at the location and name specified in step 1 above.

• The SAML 2.0 Debugger lets you decode a SAML message encoded with the HTTP-POST or HTTP-REDIRECT encoding
• The Base64 Decoder allows you to decode Base64-encoded text strings
• The URL Encoder/Decoder let you take strings and either URL encode or decode them
• The Online XML Digital Signature Verifier allows you to verify the signature on SAML assertions

Update - This was also brought to my attention: SAML Tracer for Firefox

Since this also comes up, here are the steps I use to create a self-signed certificate with OpenSSL for use with SiteMinder for Federation. The certificate can be used to sign SAML assertions during testing (or I cheat sometimes and using it in production since I can create a certificate with an extended expiration date). I am not an OpenSSL expert, but these steps seem to do the trick (be sure to substitute your desired values):

Generate Private Key and Cert:

> openssl req -x509 -days 3650 -newkey rsa:1024 -keyout saml_key.pem -out saml_cert.pem

Enter PEM Passphrase:  password
Verify Passphrase:  password
Country:  US
State:  Massachusetts
Locality:  Framingham
Organization Name: CoreBlox
Organizational Unit Name: SiteMinder Team
Common Name: ps.coreblox.com
Email Address: siteminder@coreblox.com

Convert Private Key PCKS8 DER Encoding:

> openssl pkcs8 -topk8 -inform PEM -outform DER -in saml_key.pem -out saml_key.pkcs8

Enter Passphrase:  password
Enter Encryption Password:  password
Verify Encryption Password: password

Create SiteMinder Key Database (if you haven’t done this already):

> smkeytool.bat -createDB -password password -importDefaultCACerts

Import Certs into Key Database:

> smkeytool.bat -addPrivKey -alias defaultEnterprisePrivateKey  -certfile saml_cert.pem -keyfile saml_key.pkcs8 -password password

Validate certs imported correcly:

> smkeytool.bat -listCerts -alias defaultEnterprisePrivateKey

I hope this is helpful.  If you have any tricks or sites you use, please post them in the comments.

• CA Solutions for Secure Web Business Enablement
• Jim Thorstad Covers the New SiteMinder Agent for IIS
• Radiant Logic Webinar – Evolve Your SiteMinder Portal Through Virtualization (Note: contains shameless self-promotion)
• Using ArcotOTP

Have you come across any other useful videos?  If so, post the links in the comments below.

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_MACHINE\SOFTWARE\Netegrity\SiteMinder\CurrentVersion\Ds\
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]

The SiteMinder R12 WAM UI has the ability to use an External Admin Store, which means that when an Administrator logs into the UI, the credentials are checked against an external LDAP directory or database.  Back in SiteMinder 6, this was configured on an individual basis; for each Administrator, you could select whether to use the internal store, or use one of the configured User Directories.  Now it is all or nothing.  Once you “flip the switch” by configuring the External Admin Store, your “legacy” internal admins can no longer login to the UI.

When you switch to External, you select a “Super User”.

This is the equivalent of the “SiteMinder” Super User in the internal store, he has full rights.  Also, once you flip the switch, every user under that root (LDAP) or in that table (DB) can login to the UI.  But until the Super User (or some other admin who has the ability to delegate rights) configures rights for that user, they will be able to see and do almost nothing in the UI.

The info above is covered pretty well in the SiteMinder documentation.  But here’s a tidbit that is not covered…

Sometimes we get the question:

“How can I switch my External User Store to a different LDAP or DB than the one I originally configured?”

Answer:  You can’t.  You have to revert back to the Internal Store, and start over.

Which leads us to:

“How do I revert back to the Internal Admin Store?”

The most common reasons are:

A) The directory that I am using as my External Admin Store is being decommissioned.
B) We have decided to use a different directory now as our External Admin Store.
C) When I setup the External Admin Store, I selected the wrong attribute for the Disabled Field.  *(see detail below)

There is no simple click to revert to the Internal Store.
Here are the steps:

1. Stop the WAM UI
2. On the harddrive of the UI machine, navigate to:   administrative_ui_home/CA/SiteMinder/adminui/server/default/data
3. Delete the entire /derby directory
4. Start the WAM UI

DONE.

NOTE:  you do NOT have to reregister the WAM UI with the policy server.

You should now be able to login as “SiteMinder” or any other admin you had created in your Internal Admin Store.  You will also notice that the “Configure Administrative Authentication” link in the WAM UI is back again, so you can go through the process again.

*For a little detail on (C) above:
We get this problem most often when someone doesn’t realize that the Disabled field must be an attribute that is NOT used by any other applications.  Quite often someone will try to put an attribute in there that is used internally by the LDAP or DB to disable users.  For instance, people try to use “UserAccountControl” in AD.  The Disabled field for SiteMinder must be an unused attribute.  When the Administrator tries to login to the WAM UI, this attribute is checked.  If it’s value is blank or 0, the user logs in ok.  If it is anything else, the user is sent to the logoff page.

My wife & I began subscribing to the MetroWest Daily News back in 2002. At the time they published in the afternoons, so it was the paper I read when I’d get home from work in the evening. When we moved from Framingham to Westborough back in 2008, we opted to keep subscribing to the MetroWest even though it’s Framingham-centric paper and there are probably better candidates for local news. As everyone knows, I’m a craft beer geek and always look forward to Norman Miller‘s Beer Nut columns on Wednesdays. If you’re reading this and wondering why we subscribe to a physical newspaper in the Internet age, well, I’m not going to convince you why it’s worth it. Suffice it to say we like the routine of knowing there’s morning news in our driveway, and we also enjoy supporting quality reporting by paying that subscription fee. Of course, the subscription fee also funds the delivery of the paper. Which leads me to my story…

We enjoyed reliable delivery service for most of the 8 years we subscribed. Then, a couple months ago, our regular delivery person was replaced. It’s still unclear to me whether it was just a new person from the existing delivery service or an entirely new delivery service. Apparently the MetroWest Daily News farms the delivery part out to a 3rd party, which I’m sure is much cheaper for them in the long run.  We knew the carrier had changed on that first morning when our newspaper wasn’t there (we later discovered it in our neighbor’s driveway). The next day we didn’t get any paper at all and it wasn’t in our neighbor’s driveway either. In the days that followed we had some days where we got the paper, some where we got the wrong paper, and some with no paper at all. I grew accustomed to calling the MetroWest’s Circulation Dept to report the problem. Within a couple of weeks I had their phone menu options memorized because I had dialed in so frequently (side note- why does one option say “to have your paper REdelivered, press..”? How can a paper be redelivered if it wasn’t delivered in the first place??). It was not going well.

After several days of issues a MetroWest manager called the house to apologize. He gave us his direct dial line to call if we had further issues, and he even called on some days to check and made sure we got the paper. This was the GOOD side of dealing with the problem. Unfortunately there was a BAD side too. The delivery service itself called our house a couple of times. They were rude, abrupt, and apparently suspicious of our motives. On one call they implied that we were inventing the issues (did I miss the announcement that one can use accumulated newspaper credits toward their kids’ college savings plans?). On another day when the service had already “redelivered” the paper because they’d missed the morning delivery, a 2nd driver showed up to give us a 2nd copy. When I politely explained that we’d already gotten the paper, the driver commanded in an annoyed voice “just keep it because I don’t want to have to come back out here.”

I’m guessing we had at least ten days of newspaper delivery issues over the course of 6-8 weeks. We’re

not high-maintenance people, but our patience was wearing thin. Eventually we decided “1 more strike and they’re out”. That final strike happened last week when I went outside and found no MetroWest Daily News. I was tired of calling their circulation desk at least once a week, and I didn’t understand why our service went from excellent to miserable so quickly. I made the final call to the subscription desk to cancel. When the woman I spoke with politely asked why, I made things very clear: “I love your newspaper, your staff has been great to deal with, but your delivery service has been awful lately.” She immediately saw my list of calls and was very sympathetic. A manager is supposed to call us at some point, no doubt to regain our business. At this point I don’t see that happening.

Here’s what I learned from this whole saga:

1. Don’t take excellent service for granted. We always sent tips to our old carrier, but I would have sent more had I realized how much aggravation his reliability saved me.
2. If you outsource any aspect of your business to partners, choose wisely. Partners share as much responsibility for representing your business as your employees do. Chances are your clients/customers won’t make the distinction between a full-time employee and a partner when something goes wrong. More often than not, your business will pay for your partners’ mistakes. If you don’t believe me, just ask the MetroWest Daily News.
3. If you or your company resells or performs a service on behalf of another entity, you should strive to represent them in the best possible light. This will help to differentiate you from other partners. If you end up making a poor impression, you risk costing them money. Go the extra mile and you’ll be recognized and appreciated.

At CoreBlox we’ve been fortunate to be part of some productive strategic partnerships. I think a big part of that success comes from taking the lessons we learn as individual consumers and applying them to our business. This experience with my local newspaper has reminded me that when it comes to partnerships, there’s no substitute for reliability and professionalism.

– Newspaper photo courtesy of DRB62 on Flickr

– Handshake photo courtesy of aroberts on Flickr

Error: No registration on File

I’m one to usually skim through documentation and like to just start installing software, especially when it comes to something that I’m already familiar with. As it turns out, SiteMinder WAM R12 requires additional steps in order to complete the installation and configuration of the Policy Server. After a number of failed attempts, I finally walked through the SiteMinder WAM R12 online documentation and figured that I was missing a few steps so I thought I’d pen it here to save others some trouble.

The title of this blog post pertains to the error you get when you try to launch the SiteMinder R12 Administrative UI and try to log in using the Siteminder user. As it turns out, it basically means that the Admin UI managed to contact the Policy Server and verify that it is allowed (trust) to act as the Admin UI. The Policy Server does a check and finds no trusted relationship between the two and returns the “No registration on File” error.

The normal route to resolve this issue is to run the XPSClient command (see Quick Guide to installing SiteMinder WAM R12) to register the client (this is done on the Policy Server machine). However, if you didn’t install the Policy Server properly, you will run into issues, which will result in the same error message.

A good indicator that your Policy Server is incorrectly configured is to look at the output when running the XPSRegClient command to reg:

As you can see in the output above, the command executed failed to register the client. If you attempt to log in using the SiteMinder Admin UI Client after running this command, you’ll get the “No Registration Found on File” error. This error is also logged in the smps.log file.

SiteMinder 6.x

For those with previous SiteMinder experience, you probably know the general steps in installing a new instance SiteMinder Policy and get the Policy Store up and running in a few minutes. In a nutshell, this were the basic steps:

1. Configure the Schema for the Policy Store
   1. For LDAP stores:    run smldapsetup ldgen & ldmod <schema.ldif>
   2. For SQL:      execute SQL queries with the specific sql files provided in the /db/sql folder
2. Set the super user(siteminder) using smreg to establish the password.
3. Import the base objects in the smpolicy.smdif file with the ‘smobjimport’ command smpolicy.smdif file
4. Restart the Policy Server and verify from the smps.log that SiteMinder has successfully started.
5. You’re done at this point and can launch the SiteMinder Admin UI or if you didn’t opt to configure the SiteMinder UI with an existing web server during the install, you would run the smps-config script.

SiteMinder R12

Here is the new way of installing and configuring the SiteMinder R12 Policy Server

1. Configure the Schema for the Policy Store
   1. For LDAP Stores:
      1. Run smldapsetup ldgen & ldmod <schema.ldif>
      2. Run smldapsetup ldmod /xps/db/<ldap directory type.ldif> <- This is NEW & a REQUIRED step.
         1. IMPORTANT: This is the step to extend the current schema to include the XPS objects.
         2. NOTE: For some directories (ADAM, AD), you will need to modify the ldif file to specify the root (eg dc=coreblox,dc=com) or the guid (eg B34F9AA5-C669-48E4-B8CF-DF3F5E9EFD20). The guid replacement is the value of the root of the ADAM directory that contains the cn=Configuration object.
   2. For SQL Stores:
      1. Run the sql query (Oracle/MSSQL) located in the /siteminder/db/SQL directory against the designated database instance.
      2. Run the SQLServer.sql or Oracle.sql script located in the /siteminder/xps/db directory to create the XPS objects. <-This is NEW & a REQUIRED Step.
2. Set the super user(siteminder) using smreg to establish the password.
3. Import the base objects in the smpolicy.smdif file with the ‘smobjimport’ command smpolicy.smdif file
4. Import the SiteMinder Policy Store Data Definitions  <- This is NEW and a REQUIRED step
   1. According to the documentation, the sequence in which you execute the steps are important. It warns that not following the sequence will result in a failure to import other objects.
   2. The executable that is used to run the import is XPSDDInstall its located in the siteminder\bin directory.
   3. The data defintion files are located in the siteminder\xps\dd directory
   4. Here is the sequence that needs to be executed:
      1. XPSDDinstall SmObjects.xdd
      2. XPSDDinstall  EPMObjects.xdd
      3. XPSDDinstall  SecCat.xdd
      4. XPSDDinstall  FssSmObjects.xdd
5. Restart the Policy Server and verify from the smps.log that SiteMinder has successfully started.
6. Proceed to installing the SiteMinder Administration UI component or run the XPSRegClient to register a new SiteMinder UI client if you already have installed the SiteMinder Administration UI client.

Logs:

Example of a successful Client registration:

Here are errors in the smps.log that indicates that you failed to import the XPS objects into the SiteMinder Policy store. See the steps above on how to rectify it

I hope you find this article useful and as usual, please don’t hesitate to let us know if you’ve got any questions, comments or tips!

For those of you who are not aware, R12 allows you to install SiteMinder Administration UI ‘clients’ that can exist on remote servers separate from the Policy Server instance. We’ll be installing everything on the same machine for this tutorial.

Just keep in mind that that you might need to run a client command utility called XPSRegClient to create a trusted relationship between the Administration UI client and the Policy Server when launched for the first time. The most common error that you’ll get is the “no registration on file” message when attempting to log into the Administration UI. See the ‘tips’ section for when you need to run this utility.

The goal of this mini-tutorial is to guide you through how to set up SiteMinder in a Windows environment using ADAM as a policy store (you should be able to use any other supported policy stores) and using built-in application server that ships with the installer – all on the same machine. This is especially useful for those that do not have time to comb through the installer guide.

NOTE: This tutorial should be applicable to the other installers available for Solaris, Linux, HP-UX and AIX.

1. Make sure you have JRE/JDK 1.5 (I’d recommend the most recent JRE/JDK 1.5 version to stay on the safe side) installed on the system that you are about to install SiteMinder on. This is a requirement for the SiteMinder Policy Server.

2. Go to http://support.ca.com and download the following installers:

a. CA SiteMinder Policy Server r12.0 SP2 for Windows-32-(ESD only)

b. Administrative UI Prerequisite Installer for Windows-32-(ESD only)

c. CA SiteMinder Administrative UI r12.0 SP2 for Windows-32-(ESD Only)

3. Configure a new ADAM instance (follow steps 1 through 4 in the Configuring ADAM as a SiteMinder Policy Store guide)

4. Unzip the CA SiteMinder Policy Server r12.0 SP2 for Windows-32 installer and run it.

5. Install SiteMinder R12 SP2. The installation should be straightforward.

a. Just make sure you choose the option to initialize the instance.

b. In the “Create SM Key Database”, it wouldn’t hurt to choose to import the default CA certificates (Certificate Authority).

6. Unzip the Administrative UI Prerequisite Installer for Windows-32 and CA SiteMinder Administrative UI r12.0 SP2 for Windows-32 installer into the same directory.

NOTE: This is important because the Administrative UI prerequisite installer requires the layout.properties file from the Administrative UI installer and if it does not find it, it will abort the installation by indicating that it was unable to find the layout.properties file.

7. Run the adminui-pre-req-12.0-sp2-win32.exe installer.

8. The only options you’ll have to specify is the location of the installation and the server and port number for the Administrative UI to exist on.

9. Once you’ve completed, the prerequisite installer will kick off the ca-adminui-12.0sp2-win32.exe installer automatically. If not, run it.

10. There is no additional configuration parameters to be entered during this install and might take a while to install as it compiles and configures the UI components on the application server.

11. Once completed, the installer will attempt to launch a browser and display the SiteMinder Administrative login:

Note: Under the covers, this step starts the application server and registers the SiteMinder Administration UI with the Policy Server.

12. Use SiteMinder as the username and enter the super-user password that you specified during the SiteMinder Policy server installation. Leave the ‘server’ blank as it will default to using the local server and port (unless you have specified otherwise)

13. And you’re done! You should be able to proceed with importing your SiteMinder 6.x policies and viewing them in the new Administration UI.

Tips:

If the time difference between the time you installed the Policy Server and the time you installed the Administration UI is greater than 24 hours, you might need to run the following command if you see this error when trying to login to the Administration UI for the first time:

c:\CA\Siteminder\bin>XPSRegClient siteminder -adminui-setup -t 1440 -r 5 -cp -l c:/logs/ -e c:/logs/error.log –vT

• (run XPSRegClient.exe without any parameters to get the catalog of option).

• The parameter ‘siteminder’ refers directly to the super-user

• You’ll be prompted to enter a passphrase, use the super-user password

This step is necessary to create a trusted relationship between the client and the policy server.

-Team CoreBlox

[photo credit: optical_illusion @ Flickr]

Are you interested? Do you know someone else who might be? Please help us spread the word via Facebook, LinkedIn, Twitter, good ol’ fashioned e-mail, or word of mouth! No recruiters please.