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!