Skip to content
Home > Office Life: Post 3 – Users and User Management

Office Life: Post 3 – Users and User Management

Active Directory
Reading Time: 5 minutes

From the very late 1990’s up until the time I retired, I worked in an office. I chose a different career path that involved sitting in front of a computer doing things with other computers and servers for the British Healthcare system: the NHS.


Post 2 covered Windows update, network security and user device security

This post covers the user account aspect of an IT department’s work in the NHS. User account management, the auditors and the IT department’s living nightmare: sysadmins.


Account security

When I started my IT career in 1999, my first experience with user account management was with Novell’s NDS (Novell Directory Service) which was integrated with Microsoft’s NT4 servers. The users logged on to Windows, but the driver behind it all was Novell Netware.

When we did our first merger with another Trust, we had the opportunity to upgrade our domain server to the new (at the time) Windows 2000 server, the first server to incorporate Microsoft’s Active Directory, as we (almost) know it today.

Microsoft’s Active Directory is what we used from then onwards. Sadly, Novell disappeared after a few years which was a shame – the Novell Directory Service was a far better system than Microsoft’s, in my opinion. But the monolithic giant won (as usual).

Prior to the big merger with the Hospitals Trust, we had our two domains (at the time), with our 3,000 or so users. Post merger, we were presented with another 12,500 users across two domains. There was some merging of domains to be done.

Fast forward

Let’s skip forward a bit and ignore the long Sisyphean task it was to get users (who don’t like to change) over onto a new central, single domain. Migrating all the user accounts, all of the computer accounts. The servers, the printers, the clinical equipment (all of it) all had to be moved. There were instructional videos, lots of communications and a whole lot of disruption. As we ran our own email service with our own SMTP address space, that had to be moved too. And the users were told that their old email addresses won’t work, but they have new ones [insert smiley face here].

It took a minute or two for that migration to happen, but eventually it did. (I might do a post on that at some point, as I’ve done a few of those!)

In the meantime, there was the question of IT department permissions.

The administrators

I’ll be the first to admit that earlier on in my IT career, if you worked in IT support, then your named logon account was also your administration account. It meant that if you logged in to a desktop PC as your username, you could install software and suchlike, as befits a domain admin. For servers, there was only one username that we all used: Administrator. That was the default administrator account for the domain and it was the full Domain Administrator.

The bit that I’m admitting to is that it’s really, REALLY bad practise to do that!

From around 2002 onwards, we made ourselves individual admin accounts that were separate from our user accounts. Our user accounts became standard accounts and we used our admin accounts to log into servers and disabled the default Administrator account, changed the password for a really long one (then locked that in the safe).

That in itself took some doing (and some time), as services were installed for software that used the Administrator account for their credentials. They all had to be changed for bespoke admin accounts.

A bit later on (it was a big bit, to be honest) we made the password changes more frequent for the admin accounts and used Group Managed Service Accounts for the software service accounts (not without its problems!).


User account management

When we set the users up with their new accounts, we migrated the old ones and transferred their old passwords along with it. That was when we discovered that the password policy was quite poor! I think it was a six character minimum and you could (if you rang the service desk) ask for it to be fixed for ever (which many people – unbeknownst to us) did.

We discovered that people were sharing accounts. Clinic receptionists for example would all use the same username and password. They protested long and hard against that change, as it had always been the same. Ever since they started.

We pointed that out to our management. They took that to the Trust Board, who decreed that every user, regardless of what role they had in the county, would have to have a user account. That added about 6,000 accounts to our AD. Sigh

We set up some user account management software. That meant the department head, when getting replacement or new staff, could fill out a form, send it to the service desk and get the new account made before the new user started. That only worked for about 50% of the time because a) the department head didn’t have enough time to fill out the form or b) they didn’t know they could do that and c) HR never mentioned that.

Speaking of HR. They were supposed to tell us when users were leaving. Or transferring departments. Of course, they never did. We ended up with users still having access to their old file systems (for their previous job) users that had left (but the account was still active) or new users turning up on the doorstep saying that they couldn’t login. Later on, when we appointed a data protection manager, he could often be seen with his head in his hands.

At the time, this went pretty much unnoticed, until we started being audited by external auditors.


The Auditors

I don’t know why it was, but we always dreaded the arrival of the auditors. I don’t know if every NHS Trust in the country was audited, but I sure know we were! They looked at things like account security, backup procedures and network security and would produce a large document containing various passes (or fails), areas of improvement, recommendations etc.

I would love to say that everything was addressed to the letter – but of course it wasn’t. Why? Money.

We did what we could, identified the critical bits and fixed them. One thing it did do – and it did it quite well – was to highlight those critical bits and give us (the IT department) leverage to fix them. A good example of this was the amount of users who had fixed passwords (meaning they were never set to change). We did a lot of work around both that (and password complexity), that put us in a much better position by the time the next audit happened. Not perfect, but closer.

And that was how it went. Picking bits off the audit list until they became acceptable.


Sysadmins

The downside of the Hospitals Trust model of departments owning their own servers was that they would insist that a certain person, or persons within their department had administrative rights over their server.

These users – generally called sysadmins (system administrators) were supposed to be able to work on the software that was installed on the server and that was it. Unfortunately, most software manufacturers (at the time, anyway) didn’t support any kind of delegated administration, claiming that it wouldn’t work with their software.

So, after much shouting and gnashing of teeth from the department head at our management, we were instructed (in no uncertain terms) that we should make certain users administrators of the servers and grant them the local administrator rights.

It took us a while to figure out quite how we could do that safely, without granting the sysadmin account rights over anything they shouldn’t have. But with prudent use of Group Policy, Organizational Units and local policy settings, we mostly got the sysadmins to the point at which they could administer “their” server, but not do too much harm to it.

Despite a lot of arguing, we would not allow VMWare access for them, so snapshots and any VMWare settings had to be done by us (I’m not sure if that’s still the case!).

The worst they could do (and they would do it often) was accidentally shut down the server. That was generally OK, as it was probably in a maintenance window and we could reboot it remotely with no problem.


Summary

  • Active Directory for the win (or not).
  • Users don’t like change: migrating domains.
  • IT Administrators.
  • Account management is a nightmare in a large domain.
  • Sysadmins are the bane of the IT department.

What we’ve covered so far…

(Post 1) How an IT Department is Financed in the NHS

(Post 2) Windows Updates
(Post 2) Network security
(Post 2) User device security

(Post 3) Account security
(Post 3) The administrators
(Post 3) User account management
(Post 3) The auditors
(Post 3) Sysadmins