AD Security & Administration – righting the right rights

NOTE: This post is in the process of being updated due to being used in a presentation. Please let me know if there’s anything that you believe requires updating by leaving a comment, sending me an email or poking me on Twitter!

(Before I launch in, try saying the title three times fast…sorry, couldn’t help myself :P)

So, we recently had Microsoft come to assist us with our Microsoft infrastructure, including discussing our AD and how to best secure it.

Seriously. Scary. Stuff.

But also extremely useful and helpful – because there’s a large amount of information regarding best-practice that I can share without breaching any confidentiality clauses or exposing myself or my organisation to attack. This is information that sysadmins should have if they run an AD of any kind – doesn’t matter how many users, doesn’t matter how many servers, this is all relevant and valuable.

There are a few obvious ones I left out, but also a few obvious ones I left in – mainly because while they’re obvious, I keep seeing organisations and sysadmins who get them wrong!

You need four different accounts

Sucks, but it’s the truth. If you’re a domain administrator, you technically need four accounts. What are they for? Well, I’ll tell you:

• Standard account – this is the normal boring everyday account you use to logon to your PC, surf the internet, check your email etc. The one you’ll use for all your normal day-to-day activities. No special privs, no special rights, just the same as everyone else
• Desktop admin account – good chance that as an admin, you’re going to want to install some software on your machine, possible change your power settings or remote into your PC from home. For that, you’ll need a desktop administrative account. The account has local admin rights over your PC, and possibly other PC’s, in order for you to perform administrative-y things on them like installing software, installing hardware, changing settings.
• Server admin account – this is the account you’ll probably use the most. This account has administrative rights to your servers, lets you perform tasks in AD, modify your group policies, deploy updates from your WSUS server, modify your SCCM & SCOM configurations. This account is *only* used on servers.
• Domain admin account – the big-mama of all of your accounts, the account you use ONLY if you need to perform schema updates, or major changes (like FSMO role shifts, addition of DC’s etc.) to your domain. This account should only be used for things that honest-to-goodness require a Domain Admin. No, that doesn’t include logging on to that standard server to clear some temp files, or to check on a service.

No passwords in GPP’s – EVER

This should be pretty simple, but I’m still surprised by how many people do it. Storing any password using GPP is dangerous, primarily because it’s easy to get access to it because it’s stored in a central location that all PC’s on the domain have access to. It’s like putting a password on a post-it note, then scanning it and sending it to everyone to access “just in case”.

Well, no, it’s not quite that bad. I know a number of you will be saying “But it’s encrypted!”. Yes. Yes it is. But that encryption mechanism has been made public (due to some exceedingly screwy US laws that mean Microsoft has to disclose the encryption key) and the encryption key is the same for every AD. Which means, if you’re smart enough (and there is *always* one user who’s smart enough) you can get access to the group policy XML files, get the encrypted password and decrypt it using the key provided by Microsoft. I’ve done this to test. It’s frighteningly easy.

So please – don’t put your passwords in your GPP’s. In fact, don’t put your passwords into anything group policy related, because it’s all either clear-text (in the case of scripts) or encrypted in such a way that someone can easily unencrypt it.

Domain admins don’t login to PC’s – EVER

This is a no brainer, surely. Domain administrators shouldn’t login to their standard desktops using their domain admin accounts. This is the machine that is most likely to be infected with something, especially as most admins don’t adhere to their own policies and have local administrative rights using their standard account.

Seriously, the number of admins out there I know who do this is staggering and scary. This is one of those “slap someone up the back of the head” moments. Don’t do this.

Passwords – don’t use the same one!

Again, another no-brainer, but I know of a number of admins who do this – they have these distinct accounts (outlined above) and then they go and use the SAME DAMN PASSWORD on all the accounts >.<

That, right there…serious face-palm moment.

Using the same password is exceedingly stupid, primarily because it means that if someone gains access to one account, it’s relatively simple for them to access all your other accounts – especially if your organisation has a distinct naming convention.

It’s not that hard to come up with some decent passwords, so please – for the love of all you hold holy, use different passwords.

Randomise your local admin passwords – and if you can’t, prevent remote logon

This one’s a bit tough to do, especially in a large organisation, but in a small shop it’s relatively simple. Randomise the password you use on your local PC’s so that if one is compromised, they don’t have access to every single PC.

This gets unwieldy in larger environments, so rather than randomising (which would suck if you had more than, say, 50 machines to manage) you need to prevent local accounts from being able to remotely logon. This is a group policy that Microsoft recommends as part of their SCM baseline.

Keep accounts out of your admin groups

This one is pretty obvious as well – to try and limit the scope of a compromised account, keep accounts out of the groups that can do damage. Yes, users are going to have to be Domain Admins – but they don’t need to be Schema Admins or Enterprise Admins, so aim to keep those groups empty. I mean literally empty – no users in there at all.

This is just good practice, it’s Microsoft recommended and it’s just common sense – least privilege and all that.

Have an ‘Admin’ workstation and a ‘User’ workstation

This is a tough one – I think it would be interesting to see how many workplaces would implement this, when presented with this pros and cons.

Pretty much, this means have two workstations – one to do all your day to day random shit, read email, surf the web, write up documents etc. etc. The other is to be used for administrative purposes only. This workstation is special – it gets updates as soon as they hit, it’s in it’s own special OU of protectiveness with super-duper secure GPO’s applied to it. This is the only workstation *in the world* (you read that in Jeremy Clarkson’s voice, didn’t you? I know you did…) that you can login to with your admin credentials. Because this box is *only* used for admin stuff.

Passwords – use longer passwords with longer change times

This one is also a tough one, because companies and organisations are so used to being told by their security team (who aren’t keeping up with the times, by the way) that they need to make sure their users are changing their passwords frequently. I wrote about this recently (my password & security blog post) and I honestly think they’re wrong. When you make someone change their password every 30 days, they’re just going to get fed up with it and either make it incredibly insecure (by just changing a number or a letter on the end) or by writing it down, which in turn makes it insecure (post-it notes are not a secure method of storing passwords >.<).

Microsoft is ahead of the curve here and understand this, so they recommend having a longer minimum password – 14 characters actually – and a longer time between forced password changes. Again, this seems a bit scary, but if you go and read my password post you’ll see just how simple it is to come up with a long password.

For many sysadmins, these are wishlist items that, as much as they’d *love* to implement them, some organisations won’t permit it, mainly due to the fact that there’s too much over head involved. That’s where sysadmins need to show them the risks involved and how much it can cost them – bottom-line, they’re interested in $$$, so it needs to be shown that implementing these can protect them from losing their hard-earned cash and reputation.