Design & Build Windows Server 2012 Active Directory

In this post, I’ll go through concepts related to configuring Windows Server 2012 domain controller and architecting the AD organisation unit structure. This is not a step by step or click here, here or here post. I’ll outline ideas which may help you to understand AD architecture and best practise design.

Static IP is a must

Don’t proceed if you haven’t assigned a static IP address to your server. Check-out my post here about how to do that in VMWare Workstation.

If you choose a dynamic IP assigned by DHCP, your domain controller is going to get a new IP address which doesn’t propagate over the network resulting in computers joined to domain no longer able to connect to domain controller. Thus, don’t overlook this requirement.

Change server name

Now is the time to give your server a meaningful name rather than sticking with the default e.g. WLG-DC1.

Configure Windows Server 2012 as domain controller

It’s all there in Server Manager to configure the server as a domain controller. No need to go through long screenshots, just follow the standard steps about “adding a role to Windows Server” from Server Manager Console.

  • Add Active Directory Domain Services (ADDS) role and its associated features – e.g. group policy management feature - from Server Manager --> Add Roles and Features (“dcpromo” has been deprecated in Server 2012).
  • Promote server to domain controller from Server Manager following installation of ADDS. Choose to:
    • Create a new AD forest. This means you’ll be creating a new AD rather than joining an existing installation
    • Install the DNS server. Unless you have a separate DNS server, select to install the DNS server along with AD.

Upon successful installation, you should see number of AD tools available under “Tools” option in Server Manager.

AD Organisational Unit (OU) design

An effective OU design will be scalable and will minimise maintenance for AD administrators e.g. definition & application of Group Policy Objects. Thus, rather than storing everything under built-in Computers or Users containers, we’ll choose a hierarchical OU design based on object type – Accounts, Computers, Servers. Beauty of this design is that like Inheritance in Software Development, you can define Group Policy for a specific kind of object e.g. Computers and apply it uniformly across all of Object’s sub-types e.g. Workstations, Servers. This means you apply Group Policy that’s common to all types of Computers and then refine the policy for each type of Computer e.g. Servers.

Overall design would be:

  • For accounts
    • Accounts --> Users
    • Accounts --> Services
    • So on...
  • For computers (I’m using “Machines” rather than “Computers” because AD comes with a default “Computers” container which I have left intact)
    • Machines --> Servers --> SharePoint
    • Machines --> Workstations --> Windows 8
    • So on...

Fire-up PowerShell ISE and run following commands to build the OU structure.

# New Organisation Unit: Accounts
New-ADOrganizationalUnit `
    -Name "Accounts" `
    -Path "dc=,dc=co,dc=nz" `
    -Description "OU for storing all types of Accounts"

##    New Organisational Unit: Accounts --> Users
New-ADOrganizationalUnit `
    -Name "Users" `
    -Path "ou=Accounts,dc=,dc=co,dc=nz" `
    -Description "OU for storing User Accounts"  

Once OUs are in place, you can execute following commands to create the service accounts.

$password = "";  
$accountPassword = $password | ConvertTo-SecureString -AsPlainText -Force
$path = "ou=Services,ou=Accounts,dc=,dc=co,dc=nz"
$accountName =  "svcSqlAdmin"
$userPrincipalName = $accountName + "@.co.nz"
#    SQL Server Admin account
New-ADUser `
    -SamAccountName $accountName `
    -UserPrincipalName $userPrincipalName `
    -Name "SQL Server Admin" `
    -DisplayName "SQL Server Admin" `
    -AccountPassword $accountPassword `
    -PasswordNeverExpires $true `
    -AccountExpirationDate $null `
    -Enabled $true `
    -Description "SQL Server Admin account" `
    -Path $path

Naming convention for AD objects

What names you choose for your servers, accounts or groups is of big significance when it comes to maintenance and long term supportability of the environment. By looking at a server name itself, you should be able to tell the environment it relates to, its location and type of server it is. Same applies to service accounts and AD groups.

Following table lists naming conventions for three different types of AD objects – Service accounts, Groups, Computers.

References

Comments

Popular posts from this blog

SharePoint 2013 Search Service Activation Error

VMWare Workstation - Assign a static IP address

Hybrid Apps using Cordova/PhoneGap: Ditch JQuery Mobile