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:
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:
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.
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:
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:
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?
Any of you Identity Management professionals out there probably know where I'm going with this. How many times have you been in design discussions with a customer and just cringed at what they were trying to do? Do you tell the customer they are crazy? Or do you suck it up and do your best to just make something work? Sometimes you don't have a choice, but one thing I've learned is that it is very important to make the key stakeholders understand that we may be able to teach that bear to dance, but it ain't going to be pretty and the bear might not like it very much.
Some people are convinced that if you can write code then you should not really have many boundaries. True, that if it's software and the APIs are available you can do just about anything. But that doesn't always mean it should be done.
Identity Management projects induce much change in an organization. Sometimes folks have a tendency to look for a way to code around having to ask someone to accept a change in their routine or what they know. This doesn't always work.
People, when rolling out an Identity and Access Management solution get ready to make a few changes in your life. New Identity? For sure. New Logon ID? Perhaps. New password? Likely. Single Sign On? Sure, but hopefully your not trying to make a bear dance. :-)
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:
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:
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.
I sort of feel like I've neglected a child or something. The past year has been so overwhelmingly busy that I have failed to keep this blog up to date in any meaningful way. I hope to change that this year as I continue on this path doing Tivoli Security.
Anyhow, besides a siginficant amount of traveling over most of 2008 and the beginning of 2009, I had also embarked on a major home construction project. It seems my whole life is about projects even at home. So just in case someone thinks that I have been sitting on my duff and not posting things to my blog here is a small glimps into my home project:
First off just to provide a prospective, I was involved in a fairly complex TIM/TAM/TFIM project on the East coast for all of 2008 and the first part of 2009. So, I would often leave my home in Buffalo on Monday morning and travel back home on Thursday night or Friday. Practically every weekend and any week nights I had available in 2008 were spent finishing my basement.
The kids were in need of some rec space. Living in the North you tend to spend several months in hibernation so finishing the basement was essential to providing a little more space for the kids to be kids. On top of that I desparately needed an office. It's been too long that my filing cabinets had been stored in my walk in closet off our master bedroom. Then my wife was also getting fed up with me camping out at our dining room table to do my work. Picture two lap tops, two external hard drives, power stripss laying across the dining room floor and papers strewn across the dining room table. Of course all of those Tivoli lab guides and classroom materials and CDs laying around doesn't help either.
So, I finished my basement and in all this took about 10 months between February 2008 and December 2008. I still have some trim work and doors to do and of course we will have to furnish it now. Feel free to view my pictures on Flickr:
