This document is here to provide some guidelines for Windows System Administrators on designing and implementing their Active Directory and related infrastructure.
The Institution Support Service runs an Active Directory for use by all institutions in the University. Information on this is available in the ad domain wiki. This AD can be used by whole or parts of institutions and removes the need for you to run your own AD.
It's possible the first question you should ask is "Do I need Active Directory?". The answer is probably yes if you have 10 or more Windows PCs and Users under your control and you want to effectively centrally administer them. Even for less than 10 users and PCs it may well be worth your while if you want to provide a central data store which you can backup and provide central control over the machines. Many of the terms and concepts discussed here require knowledge of Active Directory as this is not intended to teach you about Active Directory but help you implement it.
Mail firstname.lastname@example.org for more information or help on existing systems, upgrading a Windows Domain or migrating to a new Domain.
Domain Name and Design
Within Cambridge the most common Domain naming solution is either for your Domain name to match your current DNS name or be a name directly under the DNS name. It is important to remember that Active Directory names are now DNS names, you will have to implement a DNS which matches your chosen Domain name.
General guidelines for Domain Name and Design are:
- Choose a Domain name which matches your DNS name possible or choose a Domain name which is no more than one below your current DNS name. e.g. If your DNS name is CSI.CAM.AC.UK your Active Directory Domain should be CSI or use AD.CSI.CAM.AC.UK.
- Keep to a single Domain wherever possible - there are very few (if any) reasons for one institution to need more than one Active Directory.
- If part of a large department you should be aware of any other Windows Domains, don't try and take your departments Domain name as your own as it may be an existing Domain name!
There are instructions on how to configure your DNS for Active Directory within Cambridge at;
Active Directory Organisational Unit Structure
Once you have created a Domain you will need to give it some structure. This is done with OrganisationalUnits (OUs).
The actual layout of Active Directory, the Organisational Units (OU's) and where to put users and computers etc. will largely depend on what you will require from group policy. Initially it is very easy to create an OU structure based on the layout of the place you work. If you have an office, you can create an OU to represent that office and place the users, computers and printers within that location. If you have a number of separate offices with only one or two people in each then you should build the structure based on similar requirements for users and computers, i.e. do they all use a shared printer? Then to create an OU to contain that printer and all of its users would be more sensible than an OU for each office. For the users and computers, if they all require the same policies to be applied then a general OU can be created for all of them, although it's often better to separate your users and computers.
General OU guidelines are:
- Keep the depth of OUs as shallow as possible.
- Should represent structures which won't change.
- You can restrict access to AD objects to which users have no access if required.
- Group and Design in a manner that suits your needs. There is no right way to build your structure.
What Information Should I Store in AD?
The question of what information you store will greatly depend on what people want and are prepared to let you store. The more information you put in the more powerful and useful it can become. You can stick to just the minimum required, i.e. login name but you can store so much more, phone numbers location etc. which all your users can search through. Potentially it becomes a very useful searchable store of an organisations information.
Group policy and what you can do with it (pretty much anything) may well affect your OU structure.
How Group Policy impacts on your OU design should become obvious depending on your needs, if certain users require certain policies set then adjust their location accordingly, i.e. have your OU structure based on role or requirement rather then physical location, or you can use security groups to apply policies.
A list of basic Guidelines are:
- Keep the number of policies to a minimum as policy processing affects login speed and large numbers of policies can make trouble shooting very difficult.
- You should as a rule never apply policies on the Default Domain level as these policies will affect the Administrator account.
- Bear in mind the policy processing order; Local, Site, Domain, OU structure - Effects are cumulative but the last policy processed takes precidence if there is a conflict (Unless no over ride is used).
- Users who require the same settings should have the same policy applied, but they don't need to be in the same OU but it may require additional configuration to prevent users who shouldn't have a particular policy applied who are in the same OU.