Work has been going well, at least as far as the employment part of it goes. The task list is a freaking nightmare.
I reported a week or so ago about the number of people (279) that had 'root' (administrator) access across the domain due to a programming error by my predecessor. But that's not half of it. Another 240 or so had no access whatsoever (and should have). Yet another 40 or so had non-zero duplicate login ID's ('uids' in Unix-ese). This means that any of them could write over or steal files from the other folks with whom they shared ID's.
This is all due to programming errors by my predecessor. There are just under 2000 accounts, so a little more than one in four were hopelessly screwed up.
I've also had to break in to about 40 machines because my predecessor didn't leave any password information for them and doesn't respond to (phone,email) queries. He's still at the 'Uni' (University) and somehow managed to get promoted to central IT services. Gawdd, I fear for the damage that he can do with even more access to the central infrastructure systems like payroll, purchasing, enrollment databases, etc. Most of the departmental machines (the ones I'm now caring for) have custom built scripts for performing user and system management. Those dealing with system management are as buggy as the ones managing users. It's some of the most horrid looking buggy code I've ever encountered - and I've been encountering buggy code for over half my life.
At least I'm not in danger of running out of things to fix any time soon. I'm amazed some of this stuff worked at all. In fact, most of it didn't - or just worked marginally enough that nobody ever noticed how flucked up it really was.
Oh well. Slowly but surely I'm getting all of this stuff whipped into shape.
I'm putting together a hilarious saga that I ultimately intend to submit to worsethanfailure.com...
Spent the last week analyzing the Unix systems here in the labs to get an idea of what was running on them, and also to do a security audit. First though I had to break into the boxes, as my predecessor didn't leave any system passwords. Turns out this was easy.
First thing I found on one of the systems is that the 'init' process was running under the account 'Katrina' (names have been changed to protect the innocent). Now 'init' is always owned by 'root' (the system admin account). So this means that somebody else on the system has the user id of '0', which is the administrator ID number on Unix.
As it turns out, I can change Katrina's password, since it's all stored in Windows Active Directory and exported to Unix via LDAP. So I did this and logged in as Katrina. Voila - I've got root access. Did this on several boxes to reset the root password.
Now there's no easy way to find a list of accounts, since this is all done in Windows and authentication is FM (freaking magic). So I wrote a little 'C' program to find all this info spread around the university and generate what looks like a standard Unix passwd file, which is something I understand.
Next I ran a little awk script to go through and find out if anybody else had UID '0', or administrator access. I'm glad I did this. Turns out that 279 people have administrator access. (There should be exactly 1). Now we manage accounts here for about 1800 people, so somewhere around 1 in 6 have had elevated system privileges.
These UID's were generated by a software utility my predecessor wrote to add all the Unix attributes to the Windows Directory. This utility has a lot of bugs, and this is only one of them. Duplicate UID's, non-existent home directories that never get created, no-UID (which defaults to 0), etc.
Sigh... Anyway the short story is that I've got a lot of work left to do.

Digg
Delicious
Netscape
Technorati