TAM ESSO in a Multi-Domain world

The typical enterprise organization today has multiple domains. It's not unusual then to find corporate Windows AD environments with two or ten or even 20 AD Domains in a forest especially for global companies who have been through several acquisitions. I have even seen one company with upwards of 60 AD Domains in their forest.

So, how does one best implement TAM ESSO in this type of environment?

One of my goals is to journal some of these best practices in the coming months. It's unfortunate, but there really is not white paper, red paper, or red book describing best practices in a multi-domain environment with this product. It's fairly new to the IBM fold so I believe the documentation is "on it's way". IBM has a pretty good track record for integrating its products and in my experience support from IBM is first class, but I will be the first to complain when stuff ain't right.

Some things you have to consider:

If you will use AD for your TAM ESSO Repository, where is the schema master?

Is the schema master in the same domain as the user domain?

Where in the organizational structure do you intend to store the SSOConfig container for templates? Will users have access to read this container?

If you are deploying DPRA where will you choose to store the service account for the DPRA web service? How about the Password Reset account? Keep in mind the reset acocunt must be able to see all the users. What if you have users in different domains?

Every company is set up a little different when it comes to directory design and I've seen many variations in security policies as well so there is no one size fits all approach to deploying any of the IBM security products let alone TAM ESSO, but there are some common approaches we can take.

First of all, the Windows AD design will be somewhat of a guide. Users need read access to the OU where you are storing their templates. So this pretty much guarantees that you will need to at least create an OU in each user Domain in which you will store templates.

Next, consider whether to use one solution file (the xml file which stores all your template objects in the console) or multiple solution files. It may help to use a different solution file for each domain. This may depend upon how many admins will be administering these templates and whether people in different domains will be using different applications. This can sometimes be the case in some global companies or companies that run different divisions as different AD domains.

Remember that when doing the steps to extend the AD schema, you must choose the schema master. This is often in the forest root domain. Some companies have no users in that domain except for the forest admins.

Replication schedule is a factor. If you extend the schema in the forest root domain, you may have to wait some time before the schema change reaches all the DC's in the child domains. Further more as you start building templates and synchronizing them to various AD domains, keep in mind that it may be a while before these templates replicate with all the other DCs in that domain. So users will not see those templates in the TAM agent for a while.

I'll follow this post up later as I flush out more detail. Maybe over time I will have journaled enough for somewhat of a best practices document.

Cheers!

Just a follow-up from my last post regarding Win2K schema extension

So after running through this again the process of extending the Windows 2000 AD schema for TAM ESSO is a bit more quirky than I thought. It certainly works and the TAM ESSO product functions as designed afterwards, but you have to jump through one hoop first:

From the TAM ESSO Admin Console click Repository -> Extend Schema

Next, choose Microsoft Active Directory as the Repository Type














Click OK

















You will see this error message. Notice that the error occurs after the line "Adding Attributes". If you click Close and then go and view the AD Schema with MMC you will notice that just the 5 new v-Go attributes were created. The classes were not.

Note: If you choose "Microsoft ADAM" in this step instead of "Microsoft Active Directory" the operation will fail with an entirely different error and neither attributes nor classes will be added to the AD Schema.

Now, go back again and click Repository -> Extend Schema

This time choose Microsoft ADAM as the type.














Click OK

















This time you will see that the operation was successful. Now if you view the AD Schema with MMC you will see that now not only do the 5 v-Go attributes exist, but also the 4 v-Go classes. Any further operation proceeds as normal.

Even though there are not too many organizations out there still using Windows 2000, there are still some. I'm not sure what IBM's road map is for continuing to support Windows 2000, however currently they claim to support it with SP4.

When extending Win2K AD Schema choose ADAM

Believe it or not some companies are still using Windows 2000 out there. I had an issue the other day trying to extend the AD Schema for TAM ESSO and it failed trying to add the v-Go classes. Attributes were added just fine, but the classes would not get added to AD and all I got was a meaningless error message. Choosing ADAM as the Repository Type seems to work fine. I know that choosing Microsoft Active Directory as the Repository Type works for Windows 2003. Maybe it's just a Win2K thing. Hey whatever works.

Slight miss with Rollup E Fixpack 2

I noticed the other day when I was troubleshooting a sync problem between the TAM ESSO Agent and AD that Fixpack 2 does not update syncmgr.dll. In other words if you run the MSP to install this fix pack it will miss syncmgr.dll. I guess it's probably best to apply these fix packs manually. In case you don't already know this Rollup E is version 6.0.05.