I was a long time Domino guy since the beginning of Notes/Domino 5.0.a. I think my first Lotusphere was in 2002. I don't think I've ever been to a more passionate geek fest than the one Lotus puts on. I recall seeing the same faces each year with the ever popular Turtle parties to kick off each 'Sphere. Lotus developed quite a cult following over the years at least while I was involved.
So a while back I let go of Lotus (around v6.x) and switched hats to Tivoli (Security that is). This year is my first Tivoli conference (See IBM Pulse 2008). So far my expectations are not all that high. For one, a number of my IBM friends from ISST are not going. Boo! Apparently the way IBM is recording the big profits this year is quite simple. They don't spend any money. Not even on new business cards. So I'm not sure I will see many familiar faces at Pulse. But hey, I'm optimistic that it will be a very valuable experience. I had the Lotusphere Conference down to a science, especially when finding the best parties for the evening. Looks like I'll have to start from scratch this year at Pulse.
Some things on my agenda:
1.) Meet the folks at SecurIT - I'm interested in any companion products to TIM
2.) Take a test or two
3.) Get through a bunch of Security Sessions - Not sure which ones yet
5.) Hopefully find some info on Encentuate - Labs, Sessions, Demos, anything
6.) Need to do some TFIM - Labs, Sessions, etc...
7.) Find some good parties
8.) Work the Showcase
9.) Learn something new - I'm open to suggestions here. Anyone know what is hot hot hot? Besides security.
10.) Buy some Tivoli gear.
Anyhow, I'm hoping this conference will be valuable and hopefully Ill meet some cool people with the same type of passion I used to meet at Lotusphere.
See you at Pulse!
Monday, May 12, 2008
Monday, March 24, 2008
Getting up to speed on the new TAM ESSO
It's been a bit slow to get access to the Encentuate product so that I can finally start working with it. Business Partners have to sign up directly with Encentuate in order to become a partner and have access to resources more quickly. Otherwise you have to wait for the IBM machine to do it's thing which can sometimes be a little sluggish.
From what I've read on Partnerworld there are some nice benefits to the new product and the acquisition as a whole:
1.) IBM owns it, therefore the buck stops at IBM. When TAM ESSO was OEM'd from Passlogix, some of the tech support issues were not great. For instance if it was a Passlogix product we had to open a PMR through IBM, then IBM Support would have to open a ticket through Passlogix. Most of the time IBM Support could solve the problem. There are some really good support people there who really knew the product well. But every now and then stuff had to go back to Passlogix and it was not always quickly resolved.
2.) Functionality seems to be more complete in the new product. For instance Encentuate has over 300 proven applications that work. Some applications were tough to get working with TAM ESSO 6 or simply didn't work.
3.) There seems to be a wider list of supported and working 2 factor devices. Physical Access cards are also supported. They even support Sonar as a convenient sign-off option and active RFID so you don't have to "tap" in or out.
4.) There options for roaming and multiple users seems to be well documented and flexible.
5.) It has won several awards for most complete end point coverage, most comprehensive session management, widest choice of 2 factor authentication, and price for value proposition.
6.) Integrates with Active Directory and LDAP, but does not require schema extension. We don't get too many AD Admins objecting to schema extension, but every now and then it does happen. It also is sometimes an issue when the IT department evaluating an SSO solution does not actually own the AD environment therefore schema extension is not an option.
7.) Reports. There are audit reports built-in which tells you who accessed what application, etc.... I have yet to see these, but I know many customers I have spoken to recently desire this ability. This is not available in TAM ESSO 6.
8.) Works with Novell Client. I had a few customers running Novell so were using Novell's client. TAM ESSO 6 does not work with Novell. The new Encentuate product does.
Now some of the things that could be considered the down side:
1.) Requires a server (running Tomcat). TAM ESSO 6 did not require it's own server since it was largely a client side application. Encentuate uses a server to keep track of users, what apps they can access, credentials, and just about everything. It looks like credential caching is typically enabled so I do not know yet how critical the server is for end users accessing their applications, but it is likely very important and could be important enough that clustering this thing will be necessary.
2.) Because this Tomcat server is required for this solution, it would not surprise me to see IBM integrate this into WebSphere. I'm looking for some direction from IBM on this. This is not necessarily a bad thing at all, but it will be interesting to see what happens.
3.) The Windows GINA is replaced. This is also not necessarily a bad thing, just a big difference from before.
4.) Possibly more complicated to implement. Now this depends on how good the training and documentation is. The added functionality of Encentuate could make installing a bit more complicated, however the original TAM ESSO product was so poorly documented in my mind that it too was more complicated than it needed to be and in some cases the documentation was just wrong.
We'll see how it goes. More on this later...
From what I've read on Partnerworld there are some nice benefits to the new product and the acquisition as a whole:
1.) IBM owns it, therefore the buck stops at IBM. When TAM ESSO was OEM'd from Passlogix, some of the tech support issues were not great. For instance if it was a Passlogix product we had to open a PMR through IBM, then IBM Support would have to open a ticket through Passlogix. Most of the time IBM Support could solve the problem. There are some really good support people there who really knew the product well. But every now and then stuff had to go back to Passlogix and it was not always quickly resolved.
2.) Functionality seems to be more complete in the new product. For instance Encentuate has over 300 proven applications that work. Some applications were tough to get working with TAM ESSO 6 or simply didn't work.
3.) There seems to be a wider list of supported and working 2 factor devices. Physical Access cards are also supported. They even support Sonar as a convenient sign-off option and active RFID so you don't have to "tap" in or out.
4.) There options for roaming and multiple users seems to be well documented and flexible.
5.) It has won several awards for most complete end point coverage, most comprehensive session management, widest choice of 2 factor authentication, and price for value proposition.
6.) Integrates with Active Directory and LDAP, but does not require schema extension. We don't get too many AD Admins objecting to schema extension, but every now and then it does happen. It also is sometimes an issue when the IT department evaluating an SSO solution does not actually own the AD environment therefore schema extension is not an option.
7.) Reports. There are audit reports built-in which tells you who accessed what application, etc.... I have yet to see these, but I know many customers I have spoken to recently desire this ability. This is not available in TAM ESSO 6.
8.) Works with Novell Client. I had a few customers running Novell so were using Novell's client. TAM ESSO 6 does not work with Novell. The new Encentuate product does.
Now some of the things that could be considered the down side:
1.) Requires a server (running Tomcat). TAM ESSO 6 did not require it's own server since it was largely a client side application. Encentuate uses a server to keep track of users, what apps they can access, credentials, and just about everything. It looks like credential caching is typically enabled so I do not know yet how critical the server is for end users accessing their applications, but it is likely very important and could be important enough that clustering this thing will be necessary.
2.) Because this Tomcat server is required for this solution, it would not surprise me to see IBM integrate this into WebSphere. I'm looking for some direction from IBM on this. This is not necessarily a bad thing at all, but it will be interesting to see what happens.
3.) The Windows GINA is replaced. This is also not necessarily a bad thing, just a big difference from before.
4.) Possibly more complicated to implement. Now this depends on how good the training and documentation is. The added functionality of Encentuate could make installing a bit more complicated, however the original TAM ESSO product was so poorly documented in my mind that it too was more complicated than it needed to be and in some cases the documentation was just wrong.
We'll see how it goes. More on this later...
Thursday, March 13, 2008
Will the real TAM ESSO please stand up?
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!
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!
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.
Subscribe to:
Posts (Atom)