At last IBM went all in and bought a full featured Single Sign-On product (see Encentuate) that it can now call its own instead of the OEM arrangement with Passlogix. Now we wont have to play this game where we call IBM for support and when they can't figure it out they go to Passlogix for a fix and maybe the problem gets resolved and maybe it doesn't. IBM has top notch tech support in my experience and while they have some great people fielding the current TAM ESSO calls, I think the new deal will make things much better.
As for the features and functions of the new TAM ESSO product (call it version 7), well from what I have seen in the past the Encentuate product has the goods, Web, Host Based, Java, and Client Server support, but one thing stands out for sure and that is the reporting built-in. I've heard from a number of customer who want to know who accessed what and when, etc... with respect to their users of SSO and there are some decent reports built-in to the Encentuate product that was lacking in the TAM ESSO 6 (Passlogix) product. I am working on getting my hands on the new stuff asap so I can kick the tires a bit. Maybe I'm a little strange, but I get excited when it's time to learn something new.
So what about the folks using the original TAM ESSO (Passlogix)? Certainly IBM has a strategy to migrate to the new stuff. I'll be getting some of those details very soon.
Press Release
Woo hoo, something fresh to blog about!
Thursday, March 13, 2008
Wednesday, December 12, 2007
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!
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.
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.
Thursday, December 6, 2007
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.
Tuesday, November 20, 2007
Another cool Tivoli dude!
I always try to make a point to mention some people I meet every now and then because the network of Tivoli security folks does not appear to be very large. And in this case it just goes to show it really is a small world out there. I recently created a few PMR's to troubleshoot some issues I was having with TAM eSSO. By luck my level 2 support guy assigned to the call was a former Buffalonian!
Sey Gan lived right in North Amherst for about 12 years and landed a job with IBM Tivoli some time ago. And lucky for me he is a darn good TAM eSSO guy working level 2 tech support. Sey gave me some great tips and helped me work through a few problems. It's always nice to have good tech support from IBM, but it's even nicer when you discover they are from your own neck of the woods too. Of course I'm sure Sey is very much enjoying the nicer weather out in Costa Mesa, CA. But hey, we in Buffalo don't have forest fires and we certainly don't have any shortage of fresh water! Even better you can still get a pint of beer here for under $3.00.
Sey Gan lived right in North Amherst for about 12 years and landed a job with IBM Tivoli some time ago. And lucky for me he is a darn good TAM eSSO guy working level 2 tech support. Sey gave me some great tips and helped me work through a few problems. It's always nice to have good tech support from IBM, but it's even nicer when you discover they are from your own neck of the woods too. Of course I'm sure Sey is very much enjoying the nicer weather out in Costa Mesa, CA. But hey, we in Buffalo don't have forest fires and we certainly don't have any shortage of fresh water! Even better you can still get a pint of beer here for under $3.00.
DPRA url's
I downloaded the latest version of the Desktop Password Reset Adapter from IBM just the other day. It's version 6.00 Rollup D. First of all since when are they starting to use this "rollup" terminology? When you install this code, the web pages for the DPRA Management console say 6.0.04 or something to that effect. Even the base code which today is 6.0.05 suddenly is now referred to as Rollup E. WTF?
Well, lets get to the real point of this post... The documentation. I noticed that still the DPRA Client Install Guide has one of the URLs wrong on page 9. The first time I installed this a while back this drove me crazy. I finally noticed on the actual web service in IIS that there was no such file enrollments.aspx. The file name is enrolluser.aspx. Come on guys, can you at least fix the inaccuracies in this documentation already??? And why would they list the URLs in a different order than that in which the client software asks for them? Luckily after I had figured this out the first time I made notes for later.
Anyhow here is what is on page 9:
Here is what the URLs need to be in the order the client asks for them:
http://host/vgoselfservicereset/resetclient/checkenrollment.aspx
http://host/vgoselfservicereset/resetclient/checkforceenrollment.aspx
http://host/vgoselfservicereset/enrollmentclient/enrolluser.aspx
http://host/vgoselfservicereset/resetclient/default.aspx
http://host/vgoselfservicereset/resetclient/checkstatus.aspx
Well, lets get to the real point of this post... The documentation. I noticed that still the DPRA Client Install Guide has one of the URLs wrong on page 9. The first time I installed this a while back this drove me crazy. I finally noticed on the actual web service in IIS that there was no such file enrollments.aspx. The file name is enrolluser.aspx. Come on guys, can you at least fix the inaccuracies in this documentation already??? And why would they list the URLs in a different order than that in which the client software asks for them? Luckily after I had figured this out the first time I made notes for later.
Anyhow here is what is on page 9:
Here is what the URLs need to be in the order the client asks for them:
http://host/vgoselfservicereset/resetclient/checkenrollment.aspx
http://host/vgoselfservicereset/resetclient/checkforceenrollment.aspx
http://host/vgoselfservicereset/enrollmentclient/enrolluser.aspx
http://host/vgoselfservicereset/resetclient/default.aspx
http://host/vgoselfservicereset/resetclient/checkstatus.aspx
Subscribe to:
Posts (Atom)