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.

Another Quirk with Tivoli Common Reporting...

Just thought I would mention this. The report package you download for Tivoli Common Reporting may produce an error like the following:

Error CTGTRD040E










To get around this I unzipped the report file and re-zipped it using WinRAR. For some reason TCR 1.1.1 has a problem with some zip files. Something about not liking directory names as zip file entries. Anyhow, WinRAR did the trick.

Can't find TAMeB Reports?

Just in case you are hunting and pecking for reports for TAMeB using Tivoli Common Reporting, I assume you've seen the documentation for auditing TAMeB. It's only 500+ pages. :-)

The basic idea is that you will first install Tivoli Common Reporting (integrated in the WebSphere Integrated System Console). Then you need to download the reports from the support web site. Why they don't simply include these with TAM is a mystery. Oh and good luck finding them by searching reports, or audit reports, etc.... If you search for "Operational Reports" you will find them. Go figure.

Anyhow the link to the reports:

http://www-01.ibm.com/support/docview.wss?rs=638&context=SSPREK&q1=operational+reports&uid=swg21303439&loc=en_US&cs=utf-8&lang=en

TDI 7 - Eclipse anyone?

So I think that most of us using TDI over the past few years can say mostly good things about the product. Personally it's one of my favorite tools in the Tivoli Security stack being largely a non-developer type I feel empowered when I make cool things work with it. However most people would also agree that the products implementation of Swing might be a bit off. Just weird stuff like if you have a pop up window and you hit the enter key you expect the OK button to depress. And sometimes resizing windows is a little weird. I've even had to close the tool kit and reopen it sometimes just to make things work.

All that is pretty much gone with the new TDI 7.0. Oh and I believe there is a fix pack out already. I'm just starting to play with this new version. It takes some getting used to if your not comfortable with eclipse, but I look forward to working with it.

BTW, there is a pretty cool tutorial out there you can check out:

http://sites.google.com/site/tdi7islive/

Nice job who ever took the time to do this!

Risk - ignore, accept, mitigate, insure

Tivoli security professionals are pretty much in the Risk Mitigation business. Any organization who has any identity information in house on employees, customers, or partners will at some point address the risk of losing this information. And subsequently they will ask:

"What's the chance of losing that information?"
"What's the cost to us if that information gets lost?"
"What should we do about it?"

The answers are undoubtedly, ignore the risk, accept the risk, mitigate against that risk, or just buy some extra insurance.

Organizations large and small are thinking about how important it is to deprovision accounts that are no longer needed. Doing this via e-mail is not going to work well. This is one main reason Identity Management systems exist.

These latest security breaches illustrate the headaches organizations face when they fail to ensure that their former employees are removed from accessing their IT systems:

http://datalossdb.org/incidents/2152-unauthorized-access-by-a-former-employee-exposes-names-addresses-and-social-security-numbers-of-past-and-present-employees

And this one was even more brazen by an American Express employee. Holy crap $1 million. This guy had a good job watching over the systems that hold data for many of us. I'm not sure how you prove that a laptop which is reported stolen wasn't really stolen. This dude should go to jail for a long time.

http://www.kpho.com/money/19936013/detail.html

Why hire consultants?

I have always thought of myself as a consultant. Perhaps I'm just a people pleaser, not to the extreme that I'm compulsive or anything, but that I genuinely like to help others. I can recall the days when DOS 5 was a huge deal. I was networking computers using ArcNet, LANTastic and Novell 3. A 386 DX2/66 with 4MB of RAM was smoke'n fast.

I recall some of the best advice I got from a guy named John Posey (John if your still out there thanks for all your help). He said, "Chuck, run out and buy yourself a DOS book." The past mystery of my Commodore 64 seemed silly once I read that DOS book. It was clear to me then that if one could read, one could do this technology stuff. Oh how things have gotten so complicated.

So, why should you hire consultants?

1.) Well, look I understand all you geeks out there who are highly skilled can certainly figure all this stuff out yourself. Like I just said, if you can read, you'll get there eventually. But, the bottom line is there just isn't time for everyone to know everything. Take TIM, TAMeB, TFIM, TAM ESSO, TCIM, TSOM, and the rest of the Tivoli Security products. If you want to implement any one of these or some of them, you can certainly buy the software, read the manuals and go for it. The fact is though, it doesn't always work like the manual says. So, you may have to do it a few times until its right. And that's OK. But, businesses today are more concerned with ensuring that the technology is solving business needs. They are not necessarily interested in making you an expert at installing Tivoli software. That perhaps is better left to consultants.

2.) Good consultants are in this game because they like to help people. At least that's the experience I have seen with the colleagues I work with. And the objective is to enable customers to be self sufficient in steady state maintainability of the products and solutions.

3.) We really have seen many use cases, configurations and different applications of these software products so you can save a ton of time in the planning phases of your projects by using consultants.

4.) Consultants in the security business have a lot of friends doing the same thing which can help in getting the right skills on the job. Solutions using enterprise software like Tivoli will often require many different skills. There will rarely be one guy/gal who can do it all. Although I've worked with some amazingly bright people in this business, there are usually multiple people involved in average Identity Management projects. Utilizing a good consulting group will help you succeed. For Tivoli, an IBM Business Partner is key for a couple reasons:
a.) IBM Business Partners have unique relationships with IBM which helps to deliver solutions most cost effectively.
b.) IBM Business Partners can bring versatile project management skills to your project which may involve IBM and Non-IBM products and solutions
c.) IBM Business Partners can bring low cost resources into your project as well as subcontracted IBM resources which helps to drive down the cost of your project while maintaining a strong IBM presence in the success of the project
d.) IBM Business Partners have a vested interest in seeing the IBM solution succeed.

5.) Good consultants will pass on their experience and knowledge to you. I tend to share as much as I know because I believe in educating people, I will also learn some new things. Every good project should have some time dedicated to knowledge transfer, but even when that dedicated time is not there, you will still learn a lot from a good consultant.

6.) Consultants save you time and money in the long run. Lets face it, time is money. If a project is being managed properly, there will be some realistic goals and objectives. If the goal is say 6 months from now we will have xyz product installed and configured and you already have a full time job, then how likely will you meet that goal? Hire the consultant and get the job done.