So, you have an Active Directory. It’s running alright, but you know it can be better. You don’t quite know what would make it better, but you know it can be better. But how?
Today, I’m going to show you how to configure your Active Directory network to run smoother, be more secure and more resistant to disasters which could occur.
Multiple Domain Controllers
Having multiple controllers will protect you against hardware failure in one machine, network congestion when everyone logs on in the morning, and also helps you run perform maintenance easier. For example, restarting your only domain controller to do software updates will prevent anyone doing anything on the network until it fully restarts; this isn’t good for productivity, and may cause people to loose faith in the network if it happens regularly.
The initial cost of purchasing multiple servers and multiple licenses may be high at first, but is a wise investment. Even having two controllers will significantly benefit any Active Directory network.
Strict Password Policies
Passwords are the key to your network. Even if a single user’s account is compromised, the effects can be detrimental to an organisation; the effects of this have been well reported, such as when the corporate account of a Twitter staff member was accessed, and confidential business documents leaked.
The best way to ensure password security is to apply a password security policy through Group Policy. This will ensure your user’s passwords contain a mixture of upper and lower case characters, as well as numerals. It’s also a good idea to ensure passwords are changed regularly; the Active Directory default is 100 days, but I suggest changing it to 60 days.
For extra sensitive accounts, it would be a good idea to have this set at an even lower interval. For example, Administrator accounts should be set to 30 days.
Folder Redirection, not just roaming profiles
Logon and logoff times can be dramatically improved if you avoid storing data in roaming profiles. In case you didn’t already know, roaming profiles are copied off the server and onto the local machine at logon time, and then copied back to the server at logoff. After a while profiles can grow to massive sizes, especially if you have all of your documents stored in there.
Do your network a favor, and use folder redirection to store all of the documents directly on the server, rather than in the profiles. If necessary, allow offline folders to synchronise these redirected folders (especially on laptops!); offline folder synchronisation is much more smarter than plain old roaming profiles.
Distributed File System (DFS)
Having your network shares stored on only one server is a bad idea. What if that server fails? What happens to your files? Not good!
You need to take advantage of Microsoft’s Distributed File System, which allows you to have the same network share stored on multiple servers and synchronised automatically. If one server goes down, then the other servers in the DFS cluster will take over. This system compliments the idea of Multiple Domain Controllers beautifully.
Domain Controllers never run other services
Domain controllers should be really secure machines. They are the backbone of the network; you don’t want anything compromising the security. I recommend that other services are not installed on domain controllers. Keep the web services, terminal services, update services, databases and antivirus management systems away from the domain controller servers!
I acknowledge that it can be hard to do this if you’re on a tight budget. The cheapest and safest configuration I can think of consists of three servers:
- Domain controller / file server (DFS)
- Backup Domain controller / file server (DFS)
- The Everything else server (Web, database, updates, terminal services, etc.)
If you’re struggling to get hardware for these servers, try Ebay or a e-waste recycling centre. If you’re not for profit, Donortec can help you with the software licensing.
Remote sites? Read Only Domain Controllers
Remember what I just said about Domain Controller security? Well, if you have any servers at a remote site which you don’t have direct control over the physical security, I recommend you have your remote server setup as a Read Only Domain Controller.
This means that any changes to the directory can only be made back to a non-read only domain controller (i.e. at your head office). The benefit to this is that if someone gets physical access to the server, they can’t make directory changes which could be detrimental to the entire network. If you don’t have a fast link to the main servers, it will also improve access speed for the remote site.
Enforced Client Health
It’s important to ensure your client computers meet certain security requirements. For example, should ensure your clients have anti-malware software installed. The easiest way to ensure security software installed is to have some checks performed in the machine startup scripts. Check to see if certain software is installed, and if it isn’t, then perform the install automatically.
As far as configuration of the software goes, you would want to ensure everything is in a manages environment. Using software such as Symantec Endpoint Protection or AVG Network Edition can help you establish this by providing a central management system for this software.
You could take this one step further and implement Network Access Protection. For smaller networks it may not be justified, but in larger networks of larger complexity and having larger security requirements, I highly recommend this.
Strict NTFS ACLs
You want your access control at the NTFS level, not the share level. Setting all of your permissions at the share level is just asking for trouble; it won’t help you if someone gets physical access to the drive. Have all of your users in appropriate groups, and assign access to folders and shares based on what group they are in.
Don’t give too many people too much access. In fact, don’t give anyone access to anything they don’t need. Some organisations have an Everyone drive, where everything is stored; in the majority of cases, this isn’t a brilliant idea. When was the last time someone in the promotions department needed access to the payroll? Or someone on reception needed access to confidential corporate forecasts? Not often, I’m sure.
The best policy to adopt is that each department gets access to their own department’s folder, until a case arises where they need access to another department’s files.
Also, while it may be tempting to take advantage of the Everyone security group to allow every user access to certain files, it is best not to. Instead, have a security group which encompasses all of your users. Remember, the Everyone group includes IIS users and guest accounts – you probably don’t want these accounts to have access to your files.
In Conclusion…
I’ve presented some easy (and some not so easy) ways to secure, optimise and utilise best practices in an Active Directory environment. Hopefully you can implement some of these tips, as well as find other ways to improve your network. Feel free to post any further suggestions in the comments.