Tuesday, May 19, 2009

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.

Friday, May 15, 2009

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?