Friday, July 6, 2012

the active directory login that wasn't

One of those things that frustrates me at work is not having enough time to go through the systems, simply because my job scope doesn't require me to understand the internal mechanisms of the systems I manage, and coupled with vendors of questionable quality, many problems never get solved.

I took over an applications from a project manager (PjM) some time back, but I had never really looked into the system because it is a system that is only used in december every year. Last december I was helping her to troubleshoot problems with her system, and also cover the helpdesk tickets when she was absent. She was really stressed out the whole time because of login issues. When I tried to help by probing more into the design of the system, she told me that it's her problem, don't bother, so I didn't interfere.

She was the PjM from the very beginning of the project 4 years ago, saw it through the development, and then finally maintaining it. The vendor developer quitted after 3 years, got replaced by a 2nd developer, who left after supporting 1 december, and then replaced by a 3rd developer when took over, who also left after doing a few rounds of testing and resolving login issues. The 4th developer who took over was the one who discovered that the application wasn't using active directory (AD) login, when it was declared to be.

On hindsight, it was suspicious during the 15 min handover session I had for this system. I know it sounds crazy, but I only had 3 hours for her to handover 2 systems to me due to the short notice of handover assignments. I tried to log in the production with my AD credentials, but couldn't log in. She said it's always like that. There are a lot of login issues, so she just uses the admin account to log in. As we only had 15 min, I didn't dwell too much on the login issue.

Last december, I remembered supporting a case of a director who couldn't log in to the system. She escalated the issue, and about 5 people were activated just to help troubleshoot her login problem. We resetted her AD password countless times, and in the end, the developer deleted the account (need to raise service request to execute SQL query to delete account), then add the user back into the system, then she could log in.

And upon further recall of my memory, login issues were usually resolved by deleting the user from the database, and then adding them back into the system. For the longest time, that didn't make any sense to me. When I asked the vendor, (back then it was none of my business but I really pitied the PjM who was so stressed out by the login issues), he told me that he didn't know why, he was handed over the instruction to delete the user and add it back to resolve login issues.

The key to the mystery was that this application stored passwords in the system, and the password it stores, is the password that the user typed in the first time he accesses the system. As we need to change our AD password every 90 days, and we cannot reuse past passwords, it's no wonder why the passwords don't match, and hence face login issues every december when people use the system.

Sad is the life of that PjM. This is not the only mess I took over though. This really made me "dunno what to say", so I had to blog.

No comments:

Post a Comment