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.

Changing LDAP Suffix

Of course when building an LDAP it's best practice to choose wisely and carefully your LDAP structure to minimize any ugly rework later. This is a no brainer. But, I've been working on setting up a demo test system for TFIM. And, as I am not a web developer I'm going to use the demo apps that come with Tivoli Federated Identity Manager 6.1. But this Federation demo assumes that there are specific configurations done in your LDAP first.

Now, I already had a working TAMeB system with TDS and WAS, etc.... So I wanted to use what I had to minimize the work in setting up TFIM. I built another TAMeB environment to act as my partner site as well. Installing TFIM and creating the Federation domain was no problem. Even creating the Federation agreements and exporting both sides was straight forward. But when it came to configuring TAM for TFIM I ran into an unforeseen snag at the point where this program wants to configure for the demo apps:

tam:/opt/IBM/FIM/tools/tamcfg # java -jar ./tfimcfg.jar -action tamconfig -cfgfile /opt/pdweb/etc/webseald-default.conf

...
Press 1 for Next, 2 for Previous, 3 to Repeat, C to Cancel: 1
Perform configuration for demo application (y/n): y
Checking for DN cn=elain,o=identityprovider,dc=com.
FBTTAC062E Error checking for the DN cn=elain,o=identityprovider,dc=com in the user registry:
HPDMG0761W The entry referred to by the Distinguished Name (DN) must be a person entry.

You may need to create this registry entry manually or use the itfim-pre-install-tool.jar to create it for you.
Press 1 to Repeat, 2 for Previous, C to Cancel:

So, I really didn't consider that the demo apps for TFIM would be relying on specific users to exist in TAM/LDAP and even a specific LDAP structure. This is sort of lame. I need these demo apps for my testing, yet I'm forced to have a specific set of users and LDAP design. Annoying.

I set to work making the necessary changes to my LDAP, however one problem was that my suffix was already dc=ca,dc=com and the LDAP will not allow me to create a new object for the demo "o=identityprovider,dc=com". This means I need a new suffix at dc=com which the LDAP will not allow since a suffix already exists containing dc=com. No worries, I figure I'll just do a db2ldif and export my users and groups, etc... (TAM is using these already), then blow out the LDAP, delete the existing suffix and create a new one "dc=com", then just add the "dc=ca" domain under the suffix and finally do a ldif2db.

This all worked right up until I realized that the ACLs do not go back into the LDAP. The db2ldif utility will capture the ACLs and they will be right there in your LDIF file, but for some reason when you use the ldif2db these ACLs do not go back into the LDAP. Additionally I tried a bulkload with the -A and still no ACLs. I know that I must be missing something. Rather than spend a lot of time troubleshooting this I ended up configuring the ACLs for TAM manually on my "dc=com" object so that I could get back to business. If anyone knows what I may have missed, feel free to let me know.

Regards

Which product version do you have?

The Tivoli security products contain several components and middleware making it sometimes difficult to know exactly what versions and fix packs you are at for all of the pieces. Also, you may only need this information once in a while maybe for troubleshooting a problem or planning some upgrade or change to the environment. So you ask, "what was that command again to determine the version of TIM, TAM, WAS, TDI, etc...? And as usual for every piece of the puzzle the commands or procedure for determining the versions and fix packs are different. Then, finding this information on the IBM Support site or the Information Center for some pieces is difficult. You would think that for each product the first chapter of the Problem Determination Guide would start with "How to determine your product version and fix pack level". NOT!

I'm simply listing here the results of my hour and 1/2 of internet searches here to hopefully save time when I need this info again. There are by the way some very good IBM Wiki sites for this info. I've listed some below. It's crazy though that these Wiki's did not show up in my searches of the IBM Support site.

Check Version Info for TDS 5.2

http://www-01.ibm.com/support/docview.wss?rs=767&context=SSVJJU&q1=version&uid=swg21268258&loc=en_US&cs=utf-8&lang=en

Example:

rpm –qa | grep ldap
rpm –qa | grep db2
rpm –qa | grep gsk
ls –l /usr/ldap/bin
ibmslapd -V

If the Web Administration Tool is installed and configured please collect the output of:
ls -l /usr/ldap/idstools/IDSWebApp.war

Check for version info for TDS 6.0

http://www-01.ibm.com/support/docview.wss?rs=767&context=SSVJJU&q1=version&uid=swg21268261&loc=en_US&cs=utf-8&lang=en

Example:

rpm -qa | grep -i ldap
rpm -qa | grep -i db2
rpm -qa | grep -i gsk
ibmslapd -V
idsilist -a

If the Web Administration Tool is installed and configured collect the output from:
./opt/ibm/ldap/V6.0/idstools/deploy_IDSWebApp.sh -v

Check for version info for TDS 6.1

http://www-01.ibm.com/support/docview.wss?rs=767&context=SSVJJU&q1=version&uid=swg21268263&loc=en_US&cs=utf-8&lang=en

Example:

/opt/ibm/ldap/V6.1/bin/idsversion
rpm -qa | grep -i gsk
idsilist -a

If you are using DB2 v9.1 or higher issue the following command:
/usr/local/bin/db2ls

Otherwise issue:
rpm -qa | grep -i db2

If the Web Administration Tool is installed and configured, please collect the following:
/opt/IBM/ldap/V6.1/idstools/deploy_IDSWebApp -v

Check version of the TDS Web Admin Tool (Any version)

http://www-01.ibm.com/support/docview.wss?rs=767&context=SSVJJU&q1=version&uid=swg21320615&loc=en_US&cs=utf-8&lang=en

Check for Version of WebSphere

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

Example:

versionInfo.sh in the app_server_root\bin directory.

Check for version info for TAMeB

http://www.ibm.com/software/info/testinfo.jsp?uid=IC000043

Example:

pdversion

Check for version info for TIM

http://www.ibm.com/developerworks/wikis/display/tivoliim/Determining+Product+Fixpack+Levels

From the TIM Admin Console, open the "About" page

Example:

Server name: secperf12
Version: 5.0.0.3
Build number: 200809241018
Maintenance level: IF0014
Build date: September 24 2008
Build time: 10:18:08 GMT-05:00

Check for version info for GSKit

http://www.ibm.com/developerworks/wikis/display/tivoliim/Determining+IBM+GSKit+Fixpack+Level

Check for version info for TDI 6.0

http://www.ibm.com/developerworks/wikis/display/tivoliim/Determining+IBM+Tivoli+Directory+Integrator+Fixpack+Level

Check for version info for TDI 6.1

http://www-01.ibm.com/support/docview.wss?uid=swg21302983

Example:

Unix/Linux -
1) cd /usr/ibm/common/acsi/bin
2) //source the setenv.sh
. /var/ibm/common/acsi/setenv.sh
3) //run the listIU.sh
./listIU.sh | grep -i tdiserversiu


Check for version info for TIM Agents

http://www-01.ibm.com/support/docview.wss?rs=644&context=SSTFWV&dc=DA420&dc=DA480&dc=DA490&dc=DA430&dc=DA410&dc=DB600&dc=DA400&dc=D600&dc=D700&d

c=DB520&dc=DB510&dc=DA500&dc=DA470&dc=DA4A20&dc=DA460&dc=DA440&dc=DB550&dc=DB560&dc=DB700&dc=DB530&dc=DA4A10&dc=DA4A30&dc=DB540&q1=version&uid=s

wg21140454&loc=en_US&cs=utf-8&lang=en

Example:

Run agentCfg -> Configuration Settings

INFO: ssl.disable.url.hostname.verification.CWPKI0027I

From what I can tell there can be a number of reasons you might get this error during TAM Configuration or unconfiguration. In my case I made a small mistake while in a hurry and also because in my test lab, I don't take as much care as I would typically take as with a production system. I did not unconfigure Web Portal Manager before removing WAS. This should not be a big deal, but apparently it is.

I'm preparing my TAM Test Lab to also support TFIM. In doing this I upgraded my TAMeB components to 6.1 FP002. But, also I chose to replace the WAS 6.1 server with a WAS 6.1 ND because I plan to do some other clustering stuff as well.

The TAMeB upgrade and patches worked fine. Afterwords, TAM, pdadmin, WPM was all fine. But after manually removing WAS 6.1 and installing WAS 6.1 ND, WPM was hosed. To install WPM, I simply installed it using the GUI installer as I have done before only this time WPM did not show up in the ISC as it should even though the installation said it was successful. So, I then realized that when I had removed WAS and installed WAS ND, I had never unconfigured WPM.

Attempting to unconfigure Web Portal Manager using pdconfig or amwpmconfig resulted in this:

Tivoli Access Manager administrator ID: [sec_master]:
Tivoli Access Manager administrator password:******** *java.lang.IllegalStateException: HPDAZ0602E Corrupted file: Insufficient information to contact a Policy Server.

Then I realized the JRTE needed to be reconfigured for the new WAS 6.1 ND so I ran through the JRTE configuration again for my latest Java 5 location and for the WAS 6.1 ND JRE. Then the next problem was this:

Enter the IBM WebSphere Application Server or Deployment Manager
installation full path [/opt/IBM/WebSphere/AppServer]:
Policy server host name [tam]:
Tivoli Access Manager policy server port number [7135]:
Enter the Access Manager policy server domain [Default]:
Tivoli Access Manager administrator ID: [sec_master]:
Tivoli Access Manager administrator password:******** *Enter the hostname of the IBM WebSphere Application Server
or Deployment Manager[tam]:
Enter the SOAP Admin port number of the WebSphere
Application Server or Deployment Manager [8880]:
Is WebSphere security enabled (y/n) [n]?
Unconfiguration of:
Access Manager Web Portal Manager
is in progress. This might take several minutes.

Jun 1, 2009 10:58:47 PM com.ibm.ws.ssl.config.SSLConfigManager
INFO: ssl.disable.url.hostname.verification.CWPKI0027I
java.lang.NullPointerException
at com.tivoli.pd.jwpmcfg.WPMConfigure.unconfig(WPMConfigure.java:572)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at com.tivoli.pd.jwpmcfg.WPMConfigWrapper.unconfig(WPMConfigWrapper.java:325)
at com.tivoli.pd.jwpmcfg.AMwpmcfg.interactUnCfg(AMwpmcfg.java:447)
at com.tivoli.pd.jwpmcfg.AMwpmcfg.main(AMwpmcfg.java:271)

So after scratching my head enough times and poking around I discovered that all I needed to do was delete /opt/PolicyDirector/etc/amwpmcfg.properties. This allowed me to reconfigure the Web Portal Manager using pdconfig and now Web Portal Manager shows up properly in the Integrated Solutions Console as it should. So I only lost 4 hours messing around with this silly issue. Just goes to show how a simple mistake can cost you 1/2 day of work.

Cheers!

LDAP: error code 52 - Unavailable

OK, There may be numerous reasons for this error, but of course TDS just doesn't come right out and explain it for you. This was a weird one in my case because I was simply trying to delete a password policy which I had no problems creating just moments ago. I was trying a quick and dirty test which turned into several hours of troubleshooting in the midst of my other duties.

Well I tried to delete this password policy using the TDS Web Admin Tool and this is what resulted:

GLPWSA124E Failed to delete the password policy object.

Then I attempted to use my trusty LDAP Browser/Editor and different error, but same result:

10:19:52 PM: Failed to delete entry cn=pwPolicy1, CN=IBMPOLICIES
Root error: [LDAP: error code 52 - Unavailable]

So, just for kicks I enabled trace logging:

ldtrc on

I restarted the server and attempted to delete my password policy again. Here's what showed up in the log:

137:23:14:33 T115510160 Delete operation for DN CN=PWPOLICY1,CN=IBMPOLICIES requested by CN=ROOT.
137:23:14:33 T115510160 select_backend: g_backends=0x9928310, dn=CN=PWPOLICY1,CN=IBMPOLICIES
137:23:14:33 T115510160 select_backend: selected CN=IBMPOLICIES
137:23:14:33 T115510160 subtreeDn=CN=IBMPOLICIES
137:23:14:33 T115510160 The update is not from a supplier.
137:23:14:33 T115510160 send_ldap_result2: err=10 matched=[] text=[]
137:23:14:33 T115510160 WriteToSocket: Sending msg to client

So, I'm thinking "who cares if the update is from a supplier or not?" This got me thinking about a replication issue. Now when I built my replicas for this test lab, I did not configure replication for CN=IBMPOLICIES. At the time I had no desire to replicate these.

In looking at this further I see that the replication topology is all hosed for CN=IBMPOLICIES.

Peer 1:









Peer 2:









So, then how to clean this mess up? I found a handy tech note on the IBM Support Web Site. I know this was referenced by the good folks at L2 Support who put on an STE a while back. It just took me a while to relate the fact that I couldn't delete this simple password policy to a replication issue. Anyhow, the tech note:

http://www-01.ibm.com/support/docview.wss?rs=767&context=SSVJJU&q1=cn%3dibmpolicies&uid=swg21226577&loc=en_US&cs=utf-8&lang=en

For some things there may not be a technology solution for..

This recent example in New Jersey about a "clerical error" which led to sending peoples names and SSN #s to the wrong place --> http://www.nj.com/news/index.ssf/2009/05/3k_unemployed_nj_residents_may.html is one of those examples where people just have to have a better system of doing things even if it does not involve a computer or software solution. I mean maybe it comes down to having more conscientious people working in those positions that handle sensitive information. This was a clerical error so I'm trying to imagine a handful of hard working individuals manually stuffing envelopes with the wrong reports to the wrong companies and wondering how did their managers articulate what reports go into what envelopes? Or was it blatantly obvious which reports go in which envelopes and the people stuffing them were just oblivious to what they were doing?

Someone very close to me works in one of our illustrious social organizations in the Peoples Republic of New York and I hear stories all the time about the lackadaisical attitudes, complaining, and just general acceptance of mediocrity in the workplace. Managers sometimes hiding in their offices making no improvements to processes or efficiencies rewarding peoples laziness with overtime hours because people do not understand the meaning of hustling on the job.

Sometimes all it takes is for people to care enough about what they do to avoid these mistakes. I make no claim to understand the work environment of the folks at the NJ Department of Labor and Workforce Development, after all when humans are involved there certainly can be error and there may not necessarily be a technology solution for it.

Who's Identity Information is safe anymore? Probably no ones.

I reading up on the latest security breaches and stumbled onto this web site which has recorded hundreds of known security breaches since 2005. Check it out here:

http://www.privacyrights.org/ar/ChronDataBreaches.htm

It's amazing how many different ways your personal identity information could be compromised. So much of this can be prevented with the proper security measures. I don't know if the number incidents is rising or not, but it seems the same vulnerabilities continue to be exploited, lost equipment, compromised web sites, internal users' mishandling of data.

There is a link to another great web site full of the latest statistical information about breaches which I find very interesting:

http://datalossdb.org/

Protecting peoples' identities is an ongoing battle which most security professionals recognize must be fought on many fronts. There's not too much you can do about an employee whom you place trust to not misuse data, but you can certainly implement good auditing tools which security managers can use to help keep the honest people honest. Then of course there is always human error. Well, again even though people make mistakes there are some safeguards that can be put in place to prevent people from doing stupid things like inadvertently sending out mail with peoples SSNs on the labels. As for the missing or stolen equipment, well there's some great disk encryption solutions out there.

Makes you think twice about giving any company or government your information doesn't it?