TAM ESSO v8.1 - Are you ready for WebSphere?

Installing a standalone TAM ESSO IMS Server took about 2 hours to install including the database. That was version 8.0. IBM released version 8.1 this past December and I spent this week going through the upgrade process to see what will be in store for folks who want to jump right into the new stuff. It didn't take the whole week to do this upgrade, however I had to take it slow so that I could capture documentation for future reference.

The big news is that TAM ESSO v8.1 requires IBM WebSphere Application Server. When I first saw this I thought "ugggh". But the reality is that you had to know this was coming and it makes sense to run IBM's single sign on solution on their own application server.

This changes a lot though. First off, deployments will take a little longer. The fact is, even with the wizard installation tools, WAS is still a big pile of software to install. You also need IBM HTTP Server. Both need to be patched once you install them and you can't even patch the software until you download the patch installer first (IBM UpdateInstaller). But Windows shops should be used to that anyhow as you need install Microsoft's update software in order to get Windows updates.

First, is the upgrade worth it? Of course. If you want the best support for your software keep on the latest and greatest. Everyone has heard the same thing on a typical tech support phone call where the support guy asks,"What version of software are you running?" and you say, "1.2". No doubt the support guy will suggest you try the latest version. Sometimes it really comes down to which version has the fewest warts? Because you know that the latest version of software will have something wrong with it, but you hope the latest has fewer warts than the older version and lets face it, which version is getting the most attention?

The new version of TAM ESSO does not look any different than the prior release as far as the end user is concerned. But when you think about it, if TAM ESSO is doing it's job, the user does not even know it is there. All the user knows is that they login to Windows, launch their applications and they are magically signed in. Not much to see there. But, for the implementer or tech support team there is plenty to be happy about in the new release.

1.) IBM has opened up the doors to more 2 factor devices. Generic smart card support – this will leverage 3rd party products for smart card life cycle management and leverage windows smart card authentication for certificate authentication. Also Serial ID Service Provider Interface (SPI) has been introduced to allow any vendor with a serial ID device to integrate with TAM ESSO. BIO-Key support has been added which will also widen the choices of 2-factor devices supported.

2.) Wider platform coverage. Windows 7 is coming and shops already starting to buy machines with Windows 7 want to be sure AccessAgent will work. While IBM does not list Windows 7 specifically in the compatibility list, Kiosk support has been added for Vista and 64-bit Windows is supported for AccessAgent although there may be some issues with certain 3rd party strong authentication devices. Word on the street is that Windows 7 will show up on the list when it is Microsoft certified.

3.) New features in AccessStudio should make profiling a little easier. The undo button is a nice option we take for granted in Word documents. I like it in AccessStudio very much. Another really nice feature that was added is the ability to take an existing trigger and convert it to a different type. To me that's a welcome new enhancement. The ability to save your profile as an image was there in version 8.0.1, but it's listed as a new feature for 8.1. I like it nonetheless so thanks IBM. Enhanced logging messages are also a big help. Any time they make improvements to this area, I'll welcome it.

4.) Firefox finally! I knew a lot of people that were really turned off by the lack of support for Firefox. At first I was a little the same way, but I got used to using both IE and Firefox anyhow for reasons that have nothing to do with SSO. I look forward to working with Firefox in profiling.

Well, I'm off to another SSO project. Stay tuned for more on this later.

AccessStudio vanishes?

Anyone who has spent any considerable amount of time profiling applications must have noticed this. Your toiling away on a profile for hours, testing some password change workflow or something and suddenly AccessStudio just disappears into thin air. And at least the first time you saw this it was probably after having made numerous changes in the state machine without saving your work right? And to top it off, trying to simply re-launch AccessStudio wont help, because there are still pieces of it running somewhere in Windows voodoo land so it will complain if you attempt to run another test session. Chalk it up to yet another reason to re-boot your Windows machine.

Sorry, I have no solution, but am looking out for one. I have seen this problem in 8.0.0 and 8.0.1 so maybe the new 8.1 version will be better. I look forward to upgrading.

TAM ESSO and support for Java

TAM ESSO supports Java applications for sure, but if you haven't deployed it yet there are a few issues which you might need to be aware of.

First, when you install AccessAgent on a computer, the installer will try and find any instances of Java on the computer and will add support for that Java. After installing AccessAgent find the directories on your computer where Java is installed and you should see the following files at these locations:

\jre\lib\accessiblity.properties
\jre\lib\ext\jaccess.jar
\jre\lib\ext\EncAwtAgent.jar

Some applications may get installed with their own Java. If the AccessAgent installer does not detect that Java then you will have problems profiling the Java application and AccessAgent will not detect the profile for SSO.

If you wish to add support for the application after AccessAgent has already been installed there is a script which you can run located here:

C:\Program Files\Encentuate>JavaSupport>

For example lets say you have a Java application called "XYZ App" installed which has its own instance of Java under its own program directory. Launch the script specifying the location of the JRE:

C:\Program Files\Encentuate\JavaSupport>JVMSupport.vbs /d C:\Program Files\XYZ App\jre

Going forward you would probably want to have AccessAgent support this Java on any machines with this application installed without having to go to all of your workstations to run this script. The JVM paths can be specified at the time you install the AccessAgent on end user machines. The SetupHlp.ini contains parameters for specifying these JVM paths. This part is clearly documented in the TAM ESSO installation and administration guides, but I'll mention it here:

SetupHelp.ini parameters:

JVMInstallationDirectories
OldJVMInstallationDirectories

AccessAgent Seems Slow?

One thing that seems relevant here is that AccessAgent can appear noticeably slower when profiling or testing with Java applications. By default AccessAgent is logging all activity at LogLevel=3. This is a pretty good level for debugging. However, normally for production you probably do not need the logging to be at this level. AccessAgent performs considerably better at LogLevel=1 or 0. So if you see issues with the profiles appearing slow especially for Java applications, you may want to go ahead and drop that LogLevel down:

HKEY_LOCAL_MACHINE\SOFTWARE\Encentuate\DeploymentOptions\

BTW, if AccessAgent seems slow, it may not be the fault of the LogLevel or TAM ESSO at all. There are other outside factors which could affect the performance of AccessAgent including some antivirus, but in most cases you will not notice any change in performance of your desktops with TAM ESSO. With all that is going on it performs excellent.

Change Listening Ports on your IMS Server

TAM ESSO IMS Server listens on ports 80 and 443 by default. Typically this is perfectly fine. However, you may have a situation in which you need to change these default ports and it is not well documented how to do this.

1.)Edit the server.xml file located at :\Encentuate\IMSServer8.x.x.x\conf

The following is an excerpt from my server.xml file. The lines to change are in bold. In my case I changed the default listening port to 89 and the redirect and connector port to 1443.

Connector
port="89"
minProcessors="5"
maxProcessors="400"
enableLookups="false"
redirectPort="1443"
acceptCount="100"
debug="0"
server="EWS/2.0"
connectionTimeout="20000"
useURIValidationHack="false"
disableUploadTimeout="true"
algorithm="IbmX509"

Connector
port="1443"
minProcessors="400"
maxProcessors="800"
enableLookups="false"
acceptCount="100"
debug="0"
scheme="https"
secure="true"
useURIValidationHack="false"
disableUploadTimeout="true"
clientAuth="false"
keystoreFile="ims/certs/keystore/ssl_keystore"
SSLImplementation="encentuate.tomcat.EncentuateSslImpl"
algorithm="IbmX509"
keyAlias="ims"
sslProtocol="SSL_TLS"
ciphers="SSL_RSA_WITH_RC4_128_MD5,SSL_RS


2.)Edit the accessAnywhere.properties file at :\Encentuate\IMSServer8.x.x.x\ims\config

Modify the port setting in the following stanza:
# The IMS Server's SSL port
IMS_SERVER_SSL_PORT=1443

3.)Restart the IMS Server for changes to take effect.

IBM's Enterprise Single Sign On - The new stuff

Well, maybe it's not really so new. IBM acquired Encentuate about a year ago. Since then they have had time to "blue wash" the product and build up the Information Center, support and all sorts of other helpful sites and documentation. Today the product looks like it is happily at home within the TAM family.











Last year when IBM first acquired Encentuate, I quickly got signed up as an Encentuate partner while IBM was working through the red tape. I was anxious to see the new stuff, because I was hoping that it would be much better than the prior software. You know how sometimes you equate newer with better? I know thats silly, but I get a kick out of new software. I got the same excitement when I first downloaded and kick started SLES 10 for the first time. I was pleasantly satisfied with my first experience with the Encentuate product. It's ease of installation and most of all the accuracy of the documentation was a welcome surprise.

Lately, I have had some time to get a much closer look at the new TAM ESSO v8. There is support for a wide array of application types including Windows, Web, Mainframe HLLAPI, Mainframe or cursor-based, TTY, Java applet, and more. It is safe to say that 80% - 85% of your applications will work with TAM ESSO right out of the box!

Implementing TAM ESSO is a cake walk compared to your typical Identity Management endeavor. Still, the most difficult part of implementing TAM ESSO or any SSO product for that matter is the odd ball applications where the single sign on product has trouble detecting the Logon window. For your project you may have 20 applications that work flawlessly with SSO, then you might have 2 applications that for what ever reason cause a problem. So while it might take 10 minutes to profile each of the 20 good applications, it could take 10 hours to profile 1 difficult application. This is a key differentiator between the different SSO products on the market and I think TAM ESSO is the best that I have seen in this regard. So then you have to look at the tool(s) that come with a product to help you profile those tough applications. Again TAM ESSO v8 shines above others with its AccessStudio.










The AccessStudio is a state engine tool which gives you control over what happens at each window event that occurs for your application. Youl literally have the ability to add your own triggers, customized xpath statements, and actions during the logon process of a given app. You can even call out some JavaScript or VBScript and the tool makes it very logical to customize the behaviour of TAM ESSO. AccessStudio even has a testing function to allow you to test the logon process with your custom profile and shows you step by step which window events are happening and what triggers aand actions during the process are taking place. This way you do not have to upload the profile to the server before you are done testing it. The cool thing about the AccessStudio is that even for a profile which requires customization, you can still use the wizard to auto-generate the profile, then simplu enable state editing of the profile to make your customizations. I think the AccessStudio tool is much more powerful than the tools we had to work with for the old product. Therefore, it might take a bit more effort to learn how to recognize all of the states and how to customize them, but the wizard built in to AccessStudio properly automatically recognizes most of your apps so that should mean quicker deployments and quicker ROI.

Some competitors of the new TAM ESSO product would say that a downside to the new TAM ESSO is that it requires a server or multiple servers. The fact is that you do need at least one server because TAM ESSO uses a RDBMS (either MS SQL, Oracle or DB2) to store policies, profiles, credentials, and report data. The old product did not require a server because it stored information in a directory (Active Directory, Novell, or LDAP) which typically already exists in most companies. I personally don't think it makes a difference. The solution can be virtualized just like anything else out there and most companies have hundreds of servers already. Having more servers typically reduces risk by not having all your eggs in one basket. Virtualization is there to allow you to reduce the need for physical hardware and make better use of the processing power that often sits idle on many physical servers. But that's not the only reason to appreciate the requirement of a server for TAM ESSO. The advantage is that you can implement TAM ESSO without any direct impact whatsoever to existing enterprise directories. The old product required schema extension to the Active Directory. While I still do not think that is a big deal (its what directories were designed to handle), some admins hesitate to extend their schema and since it affects their production system, it is something you have to plan appropriately for. Additionally, multi-forest and multi-domain AD systems presented a few challenges for how you deployed the old product. Again, I don't think that is a huge deal either, however the need for a server in the new TAM ESSO product provides another added benefit... reports. TAM ESSO v8 will gather compliance reports such as who accessed what applications, what machine were they logged into when accessing those apps, what credentials where being used, etc.... The old product provided nothing like this and if it had, the addition of a server would likely be a requirement. A typical IBM server should be able to handle 36,000 user authentications per server per hour so depending on the size of your organization a single server would do the trick. The servers can be clustered and load balanced so the solution scales very well.

Password reset is one of the common reasons companies buy a Single Sign On product like TAM ESSO. The password reset feature worked much the same way the old product worked. From the logon dialog you click reset password and right within the logon dialog itself, you are presented with challenge/response questions. If the desktop is locked, a link can be added to the locked dialog which taked you to the AccessAssistent to reset your password. One difference between the old product and the new product is that you cannot just purchase and deploy only the password reset feature. The old product allowed for licensing just the password reset because it was really a separate set of code (web application and GINA piece). The new product is licensed as one product so to do just password reset you still need to deploy the IMS server. Of course you can use just the password reset function of the new product, however you cannot just purchase that component.

Support for me is a key differentiator when purchasing a security product. I used to be an IBM, Novell, Microsoft, and others customer so quality of support is key to my choosing of any product. First, the IBM documentation for TAM ESSO v8 is fantastic compared to the old version. Maybe the Encentuate team should get the kudos for this. All I can say is that for the most part, the documentation covers a lot of ground and is pretty darned accurate. Much more understandable and logical than the old stuff I had to deal with. There are also a couple of great resources which I should point out:

The developerworks site for TAM ESSO is being monitored and the reponses are very quick and helpful. There are some folks who really know the software well regularly posting answers to questions on the site and since I don't know their names all I can say is "Thank you!" to whomever they are. The URL to the site:

http://www.ibm.com/developerworks/forums/forum.jspa?forumID=1592&start=0

The IBM OPAL web site contains over 200 profiles for applications out there. This is way cool because again part of the effort for implementation is to build these profiles. Some take minutes and some take hours so if you are deploying TAM ESSO, you may be able to take advantage of these. Why re-invent the wheel? The URL to OPAL, search for Tivoli Access Manager for Enterprise Single Sign-On:

http://www-01.ibm.com/software/brandcatalog/portal/opal

There is a great Wiki for TAM ESSO with documentation on how to build custom profiles, architecture diagrams, deployment scenarios. This is great information to help you get started with your project. Checkout the URL here:

http://www.ibm.com/developerworks/wikis/display/tivoliaccessmanagerforesso/Home

Also, don't forget to check out the information center as well. Bottom line, if I were a customer looking to choose a single sign on product I would choose IBM's new TAM ESSO over any other because it is one of the best if not the best at recognizing logon windows for any type of application, not just the typical Windows and Web apps. The support is top notch and there is a great deal of information publicly available to help you become self sufficient. If I were a customer I would hire consulting help for a short term "getting started" type of approach to help my internal staff get a jump start with help from folks who have done it before.

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...

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!

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.

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.

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

Synchronizing Global Agent Settings can break synchronization???

Just because you can do something doesn’t always mean you should. One of the Tivoli Level 2 support guys from IBM warned me that synchronizing your Global Agent Settings to the repository can lead to issues such as synchronization problems. So synchronizing can cause synchronization problems. Go figure. I guess I won’t do that then.

· Just right-click the object (vgoadminoverride in my case) and click delete

Corrupt TAM eSSO User...

"There was an error trying to load your chosen primary logon method. You may want to reinstall it in order to correct this."

I have a workstation in which 4 or 5 different users will logon to. All the users except one worked fine. The problem user would login to the Windows Domain and the above error would be displayed as soon as the TAM agent would start to load. To fix this problem I followed these steps.

1.) Logon to the Admin workstation and clean up the server side by deleting the users credential objects

· TAM eSSO Admin Console -> AD Repository -> Twist Open Users Container -> Twist Open User

· Right-click TAM eSSO object -> Delete

1.) Next, logon to the users workstation and cleanup the agent side

· Start -> Run -> %appdata%

· Delete the Passlogix folder

· Start -> Run -> Regedit

· Delete the Passlogix folder from HKEY_CURRENT_USER\Software\

· In this case it was also necessary for me to delete the folder in the %appdata%\Microsoft\Crypto\RSA folder. There is normally a single file in this folder, but since this problem had something to do with the logon method it was necessary to delete this folder as well.

3.) Finally, log off Windows and log back on. TAM eSSO should start correctly.

Helpful Tivoli Webcasts

There are some pretty good technical webcasts available on IBM's Tivoli Support site:

http://www-306.ibm.com/software/sysmgmt/products/support/supp_tech_exch.html

If you haven't already found these they are a bit helpful for those topics you are new to in the Tivoli software. Some are very broad in scope and others are fairly granular. Check these out if you haven't already. I try to visit this site a couple times per month to register for the upcomming webcasts. Whats nice about joining a live webcast is that you can ask relevant questions at that time. All the old ones are posted.

The InstallScript engine is missing from this machine...

If available, please run ISScript.msi, or contact your support personnel for further assistance.

If you are installing the TAM ESSO agent and encounter this message, then it is likely that you are using an older version of ISScript.msi than is required.

I ran into this problem recently and spent a few hours trying to install various versions of ISScript.msi. There is an informative tech note from InstallShield here:

http://consumer.installshield.com/kb.asp?id=Q108158

The problem is that if you try to install any or all of the versions mentioned in the technote you will still get the error message because InstallShield is already up to like version 12 or there abouts.

You can debug your msi by running this from the command line:

msiexec /i yourmsi.msi /l*v C:\Temp\MyMSILog.log

In the log you will see which version of isscript.msi it's trying to use. That would be the version you must install.

Since I'm using TAM ESSO 6.004 it is requiring version 11.5 of isscript.msi. I found the correct version of isscript.msi bundled with the TAM ESSO 6.004 product. You will find it in the Utility folder. The file name is isscript1150.msi.

Anybody searching for Passlogix?

OK, I have not worked with the TAM ESSO product for very long, but what seems to be quite common when deploying it is having to install, uninstall, and re-install the product a few times as you blow up your test systems trying out templates and MSI files. What is the deal with software that does not uninstall completely?

Every time you uninstall TAM ESSO, you have to go into the Registry and search all over for "passlogix" and delete all these keys manually. You would think by now that someone would get something right with this Windows OS.

Stand-Alone configuration for TAM ESSO

I recently have been doing some work with TAM ESSO. Pretty cool product from Passlogix. The idea is that if you have many applications that users have to remember names and passwords for both client/server, web apps and even terminal applications you can use TAM ESSO to manage the user credentials for each of those apps. When you login to Windows, you must also login to TAM ESSO. TAM will detect when you attempt to access an application that requires a name and password and will login for your so that you are not prompted. Administrators can build templates for all the corporate apps and deploy these templates on an Active Directory Server. AD group membership can then be used to control who has access to which templates.

One of the problems I encountered early this week was in trying to deploy the TAM ESSO client stand alone while including the templates for applications in the stand alone client. The documentation is not very clear on a lot of things including this one so I figured I would go ahead and mention what I had to do.

First I had created templates for 3 applications (Web, Client/Server, and Terminal). Next, you need to click on Global Agent Settings and if you haven't already done so, Import from Live HKLM. Next, open the End-User Experience -> Environment key and select the check box for Location of entlist.ini file. Specify the path to the file including the file name. The default is:

C:\Program Files\Passlogix\v-GO SSO\Plugin\LogonMgr\entlist.ini
















There are numerous settings that can be controlled here so make any other settings you desire to be packaged in the distributions MSI.

Next, to create the MSI click Tools -> Generate Customized MSI. Complete the fields similar to the following screen shot:



















The BASE MSI file should be stored in the location where you extracted the TAM ESSO binaries. You can store your target MSI where you prefer. Obviously if you want applications templates to be included in the MSI then you will want to add the ones necessary for your purposes. The one part that I was not aware of until working with some other TAM folks was the Global Agent Settings. This must be done in order for the application template show up in the client agent. Once you click OK, your distribution MSI is complete.

This is definitely not one of the more complex areas of working with TAM ESSO, but it was a bit annoying when the documentation did not seem to spend much time on a stand-alone implementation. For folks who just simply want to try it out to get an idea how it works, there will not necessarily be an AD server or even ADAM for that matter.h