Tuesday, April 9, 2013

Best practices for configuring a new Active Directory

Name Your Active Directory properly
I've written about this before. If your company website is example.com, the FQDN of the Active Directory should be in the form of ad.example.com, corp.example.com, or another third-level subdomain of the existing publicly used DNS. Avoid using example.com internally and externally. Also avoid making up a TLD like .local or .lan. During promotion of the first DC in a domain, consider setting the NetBIOS name to EXAMPLE instead of the default value, so that users see EXAMPLE\user instead of the ambiguous AD\user or CORP\user. You only get one chance to set the NETBIOS name, so consider it carefully. It's non-trivial to change.


Create alternate UPN suffixes
I always tell users to "log into everything with your email address." Creating and assigning alternate UPN suffixes that match this allows this to work seamlessly. Also, having publicly reachable top-level suffixes like @example.com instead of @ad.example.com helps make integration with Office 365, Intune, and other Azure-based cloud services from Microsoft easier. It also makes Exchange Address Policies a snap to configure when you have multiple email domains in your Exchange organization, since you can filter on UPN suffix now and match it to a sending domain.


Set PDC Emulator to sync from an external time source
The Domain Controller with the PDC Emulator role is the one true source of time for your domain. All other Domain Controllers sync their time from it, and all client machines sync their time from the domain controller that they log into. It's important that time is consistent across your enterprise. The example below will sync it from some ntp.org pools, which are very reliable. If you already have a device on your network, like a core switch, offering reliable NTP, then you can replace all of the items in the manual peer list with those devices.

w32tm /config /update /manualpeerlist:"0.pool.ntp.org,0x8 1.pool.ntp.org,0x8" /syncfromflags:MANUAL

If you're not sure which DC has the PDC Emulator role, log into one of them and run netdom query fsmo at the command prompt. It will return a list of each FSMO role and which server currently holds it.


Set DNS Server Search order correctly on network adapters for DCs:
127.0.0.1 should be in the list and should be last. Each DC in a site should use another DC from that site as the primary. If there are more than two DCs in a site with DNS installed, then one of the other DCs should be primary, the other secondary, and 127.0.0.1 should be the tertiary. For example:

DC01's IP address is 10.1.1.1
DC02's IP address is 10.1.1.2
Both are DNS servers.

DC01's network adapter should be configured so that 10.1.1.2 is the primary and 127.0.0.1 is the secondary. This prevents replication islands from occurring in specific circumstances.



Enable the AD Recycle Bin.
The AD Recycle Bin requires you to have a 2008 R2 Forest Functional Level, which means that you can never make a machine that is older than 2008 R2 into a Domain Controller. If this isn't an issue for you, then you should enable it. It allows for item-level recovery of deleted objects like user or computer accounts. It's a life saver.

Enable-ADOptionalFeature
–Identity ‘CN=Recycle Bin Feature,CN=Optional Features,CN=Directory
Service,CN=Windows NT,CN=Services,CN=Configuration,DC=ad,DC=example,DC=com’
–Scope ForestOrConfigurationSet –Target ‘ad.example.com’


Redirect newly created users and computers to a different default container
When you join a computer to a domain and there isn't a pre-existing computer account with the same name, you'll notice that it gets put into the default Computers container. Since Computers is not an OU, you can't link Group Policy to it. User accounts are placed in a similar Users container, as well. This can happen when creatings users from the Exchange Management Console, New-ADUser PowerShell cmdlet, or the good old net user command.

Redircmp.exe and redirusr.exe are used to redirect the default location for computers and users to the specified OU.

If you have an OU at the top level named "Company Resources" and a sub-OU named "Misc Computers" you could redirect the default location for new, unspecified computers to Misc Computers by running:

redircmp "OU=Misc Computers, OU=Company Resources, DC=ad, DC=example, DC=com"

This will allow you to have a basic set of Group Policies apply to these computers and users without having to link them at the domain level.

Following these guidelines should get your new AD off on the right foot and set you up for success down the road.

8 comments:

  1. What are your recommended settings for DNS forwarders?

    ReplyDelete
    Replies
    1. This depends. If you have an ISP that does NXDOMAIN hijacking and inserts "helper" search results, then I'd probably leave them using root hints, as bad as that makes me feel. If my ISP is well-behaved, then I configure forwarders to use their DNS servers.

      As long as you're pointed somewhere reliable, you're probably in good shape.

      Delete
    2. May I suggest using OpenDNS on your forwarders? Their DNS resolution is fast, and if you opt for a free account with them, you can filter a bunch of stuff at the DNS level (pornography, hacking sites, phishing sites, all kinds of stuff). I use it to take some of the burden off my UTM firewall.

      Not affiliated with them, just a very happy customer :)

      Delete
  2. Also, since we're already using example.com both internally and externally, how hard would it be to change over to "ad.example.com" internally?

    My users already see EXAMPLE\Username when they log in, and I too tell everyone to "login with their email address" whenever possible - would switching over to "ad.example.com" affect that setup in any way?

    We're a small company (11 users!), in your opinion, would this be worth the effort?

    ReplyDelete
    Replies
    1. It would require either a domain rename (only possible if you don't have Exchange 2007+ installed) or a migration to a new domain with ADMT, which would require a second set of Domain Controllers during the migration. Both require planning.

      Keep in mind that these recommendations were for new domains. If you have an already functioning environment that's set up differently and you don't have a real reason to change, then it might be a good idea to just stay put. It's non-trivial to change, but with only 11 users, if everything does break you can probably put it back together pretty quickly by hand :)

      Delete
  3. Great article, and I strongly second you, Mark!

    AD domain names ending with ".local" are a nuisance, and ".lan" might be officially used as a gTLD in the future.

    ISO Standard 3166 reserves the country codes AA, QM-QZ, XA-XZ, and ZZ as user-defined codes. These will never be used as TLD in the public Internet!

    So it is feasible to use e.g. 'company.xa' as AD name space. This additionally saves you the cost for having to register a SLD.

    ReplyDelete
    Replies
    1. But since it's not globally unique, you could be example.xa and so could another similarly named company. If this happens, you can never have a trust between the two, or have any interaction between the two internal DNS infrastructures.

      It's probably got a low probability of happening, but I'd still recommend the guaranteed-to-be-unique ad.example.com.

      Delete