Active Directory: Global Groups; Universal Groups and User Logon

If you are struggling to understand Global Catalog Servers (GCS); Universal Security Groups; and Group Replication, it may help to think about what is actually happening during the user logon process and why.

When a User logs onto a Microsoft Domain Network, two things need to happen. The Logon Service has to:

  1. Verify the User Credentials (Username and Password)
  2. Determine which “Security Groups” the user is a member of (this establishes the permissions they have on the network)

For the purposes of this exercise, it is the second part of the process that we are interested in.

Obtaining a list of Security Groups is an essential part of the user’s “Access Token”. The access token is generated on the fly each time the user logs onto the network. It acts as a security pass for the duration of the session. So, when the user attempts to access a resource (anywhere within the forest), the operating system compares the permissions on the user access token with the security permissions on the resource (such as a file share) in order to determine if access can be granted.

In accordance with best practices, User Accounts should only be added to Global Security Groups within their Own (Local) Domain. Global Security Groups can then be added to Universal Security Groups in order to grant permissions to resources in other Domains throughout the Forest.

The membership list of Global Groups for the user’s “Local” Domain are replicated to every Domain Controller within that Domain ONLY. So, it is a relatively easy task for the DC that is processing the logon to query its own copy of the Active Directory Database and obtain a list of all Global Groups to which that user is a member. Users cannot be members of Global Groups within other Domains, so finding those is not an issue. So far, so good.

Note: The “Access Token” includes a FULL list of all the security groups that particular user is a member of, plus all of the security groups that those groups are themselves a member of. For instance, if the user is a direct member of “G_Sales”, and “G_Sales” is in turn a member of “G_Contracts”, then BOTH groups will be individually listed on the Access Token. This is very important to remember!

That just leaves us with the task of determining which Universal Groups the user is a member of. Remember, Universal Groups grant permissions to resources within another domain in the forest.

Universal Groups membership is not stored within the database of the Local Domain, so the DC cannot simply query its own Active Directory Database – remember a DC only knows about objects within its own Domain.

Universal Groups “live” in the Forest, and their membership lists are stored on a special type of Domain Controller called a Global Catalog Server. There must be at least one Global Catalog Server (GCS) within each Forest – the very first Domain Controller within the Forest is automatically designated the role of GCS. So, the DC processing the user logon must be able to contact a GCS within the Forest to find out which Universal Groups the User is also a member of.

Note: if a GCS cannot be found, the logon process will Fail!

When all of the Group Membership information has been gathered, the “Access Token” will be generated and issued to the user account.

Access Token for “DomainA.User A”
Group Membership List:

Hopefully, you can now see why it is important that ALL security groups are listed within the Access Token (even if membership is indirectly a result of “G_Sales” being a member of “G_Contracts”). If ALL Security Groups were not listed within the Access Token, the User would be denied access to “G_Contracts” and “U_Sales” resources, and would only be able to access “G_Sales” resources.


Windows Server Core 2008 R2

Microsoft Windows Server Core 2008 R2 is a “cut down” version of Server 2008 R2 – it was first introduced in Windows Server 2008. Unlike the full version, Server Core ONLY supports the following Roles / Services:

  • Active Directory Domain Service
  • Active Directory Certificate Service
  • DHCP Server
  • DNS Server
  • File Server (installed by default)
  • Hyper-V Server
  • Print Services
  • Streaming Media Server
  • Web Server (IIS)

Implementation Scenarios
If you wish to implement an additional DHCP Server on the Network (or an additional Domain Controller), “Server Core” may be worth considering – as it would not be necessary to deploy the full blown version of Windows Server (although the licensing requirements remain the same). Server Core has such a small resource footprint, it is ideally suited to running as a Virtual Server within Hyper-V.

Benefits of Server Core
Since no unnecessary services are installed, the benefits are: Simpler Management; Reduced Attack Surface; Reduced System Requirements.

Select “Server Core” from any Windows Server 2008 R2 installation disk. It is not possible to “upgrade” from other Versions \ Editions of Windows Server (with the exception of an earlier version of Server Core itself).

There is no GUI, so everything must be managed from the Command Line; RSAT (Remote Server Administration Tools); Windows Power Shell or Windows Server Manager. In addition, there are some inbuilt utilities to help with Server Configuration:

  • SCONFIG (new in R2)
  • DISM (Deployment Image Servicing and Management)

Server Configuration (SCONFIG)
Type “sconfig” from the command prompt to load the Server Configuration Utility.

  • Change Domain / Workgroup
  • Change Computer Name
  • Add a Local Administrator
  • Configure Remote Management: Enable MMC Remote Management Firewall Exception; Enable Windows PowerShell; Allow Server Manager Remote Management (Requires PowerShell); View Firewall Settings
  • Configure Windows Update (Manual or Automatic)
  • Download and Install Updates
  • Enable / Disable Remote Desktop (Disabled by Default)
  • Configure Network Settings (Static or DHCP)
  • Configure Date and Time
  • Log Off
  • Restart / Shutdown Server

Listing Server Roles (OCLIST)
To generate a list of available services, type: oclist.

Installing Server Roles (OCSETUP)
Use “ocsetup” to add / remove server roles. When doing so, it is often useful to open up an additional command prompt window (type “start” at the command prompt). The basic syntax is “ocsetup <role-name>”, where “role name” is one of the following:

  • DNS-Server-Core-Role (DNS Server Role)
  • DHCPServerCore (DHCP Server Role)
  • FRS-Infrastructure (File Replication Service)
  • DFSN-Server (Distributed File System Replication)
  • DFSR-Infrastructure-ServerEdition (DFS Replication)
  • ServerForNFS-Base (Network File System Server Service)
  • ClientForNFS-Base (Network File System Client Service)
  • Microsoft-Hyper-V (Hyper –V)
  • Printing-ServerCore-Role (Print Server)
  • Printing-LPDPrintService (Line Printer Daemon)
  • DirectoryServices-ADAM-ServerCore (Active Directory Lightweight Directory Services)
  • MediaServer (Streaming Media Services)
  • IIS-WebServerRole (IIS Web Server)

Installing Active Directory (DCPROMO) 
To install Active Directory, run “dcpromo /unattend:<unattendfile>”. Note: an “unattend” file must be used, it is not possible to run “dcpromo” interactively on Server Core.

Uninstalling Server Roles (OCSETUP) 
To uninstall a server role, the basic syntax is “ocsetup <role-name> /uninstall”.

Additional Server Features (OCSETUP)
Server Core permits certain Server “features” to be installed. Use “ocsetup” to add / remove “features”. When doing so, it is often useful to open up an additional command prompt window (type “start” at the command prompt). The basic syntax is “ocsetup <feature name>”, where “feature name” is one of the following:

  • FailoverCluster-Core (Failover Clustering)
  • NetworkLoadBalancingHeadlessServer (Network Load Balancing)
  • MultipathIo (Multipath IO)
  • Microsoft-Windows-RemovableStorageManagementCore (Removable Storage)
  • BitLocker (BitLocker Drive Encryption)
  • SUACore (Subsystem for UNIX-based applications)
  • WindowsServerBackup (Windows Server Backup)
  • SNMP-SC (Simple Network Management Protocol)
  • WINS-SC (Windows Internet Name Service)
  • TelnetClient (Telnet client)
  • (NetFx3-ServerCore) .NET FRamework

Uninstalling Server Features (OCSETUP)
To uninstall a server role, the basic syntax is “ocsetup <feature name> /uninstall”.

DISM (Deployment Image Servicing and Management)
DISM offers an alternative method for installing / uninstalling Roles and Features. The general syntax is: dism /online /enable-feature /featurename:<Name of Feature>