I think this took place in the winter of 1998 or 1999. I was a young VP of Sales at Zoomit Corporation tagging along on a final proof of concept for one of the largest heavy equipment manufacturers in the United States. We were asked to integrate the company’s telephone system, Windows NT directory (this was before Active Directory!), their mainframe system and employee database into our meta-directory product. If you ever done something like this you know that you set up your connectors to each of these systems and then spend the bulk of your time mapping individual identities across the various namespaces.
In this particular case we successfully mapped (“joined”) around 60,000 employees but we found that there were approximately 6,000 names that we couldn’t find telephone numbers for. Many of these names were listed in the mainframe and being an old “mainframer” I was suspicious that they had so many mainframe accounts with no associated telephone number. Our conclusion was that the employee database didn’t include their contractors.
When we met for the final review we presented our results and told them we found 6,000 names that were not associated with a telephone number and were not in the employee database. “Did you forget to give us access to the contractor database or was this a test of our engineers?” The company’s representatives looked at each other and finally their director said “We don’t have a contractor database. And, ah, we don’t have 6,000 contractors working here.”
It turns out that their mainframe staff never deleted or disabled any employees who left the company. Apparently, this had been going on for years. Now the obvious security problem had manifested itself when someone was re-hired and a few years later they were still able to log-on to the mainframe with their old credentials – exactly what happened in the previous true story. However, there was a very interesting side effect of the company finally deleting all those old accounts: Once the accounts were deleted from RACF - the mainframe security database – many batch jobs failed to run and the company got back some of their mainframe computing power. So here they were running gosh knows how many jobs that no one was ever bothering to look at. Amazing.
I’m on vacation next week too so I’ll see if I can troll around the memory banks for a few more oldies but goodies. In the meantime, here’s a picture of a new friend of mine down here in Manasota Key, Florida…
2 comments:
The bird looks like Milburn.
I see this a lot, too, especially in Unix directory consolidation efforts. One recent pharma job had 20,000 out of 70,000 accounts kicking around from terminated employees. They weren't even sure how to identify them as they had no idea whether they were former employee, contractor, test, or service accounts.
How to resolve this issue? Since AD is usually better managed in that terminated employee accounts are disable/removed faster, I typically have them consolidate their Unix IDs to Active Directory, which removes all dupes from the local Unix server. All leftover accounts that have a person looking gecos ("John Smith") are then considered termed accounts. Their files are archived or reassigned and their accounts deleted.
Post a Comment