8. Active Directory Basics
Eighth section in Complete Beginner learning path.
Introduction
A Windows domain is a group of users and computers under the administration of a business. The idea behind this is to centralise the administration of common parts of a Windows computer network in a single place called Active Directory (AD), the server that runs the AD is called a Domain Controller (DC). The main advantages of this are:
Centralised Identity Management : all users can be configured from AD.
Managing Security Policies : security policies can be configured directly from AD and applied to users across the network
Active Directory
The core of Windows domains is Active Directory Domain Service (AD DS) - this is a catalogue that holds info on all the "objects" in your network. AD supports many objects as well as users, groups, machines, printers, shares and much more.
Users : users are the most common object type in AD. Users are one of the objects known as "security principals", meaning they can be authenticated b the domain and assigned privileges over resources like files or printers. A security principal is any object which can act upon resources in the network. Users can represent two types of entity: people, services. People are persons in the organisation who need to access the network. Services like IIS or MSSQL require a user to run, but services will only have the privileges required to run their specific service.
Machines : for every computer that joins the AD domain, a machine object will be created. Machines are considered security principals and are assigned an account like regular users. The machine accounts are local admins on the assigned computer but should not be accessed by anyone except the machine. These accounts are easily identified by naming scheme, e.g. a machine named DC01 will have an account named DC01$.
Security groups : groups containing multiple users or machines that can be assigned access rights to files or other resources, rather than assigning them per user. Groups can have users and machines or even other groups in them if necessary. Several groups are built by default in a domain, some of these are:
Domain Admins
Users in here have admin over the entire domain, they can administer any computer including the DCs.
Server Operators
Can administer the DCs, cannot change any admin group memberships.
Backup Operators
Allowed to access any file, used to perform backups of data.
Account Operators
Users in here can create or modify other accounts in the domain.
Domain Users
Includes all user accounts in domain.
Domain Computers
Includes all computers in domain.
Domain Controllers
Includes all DCs on the domain.
Organizational Units (OUs) are used to classify users and machines e.g. you could have all the IT staff and machines in an OU named "IT-DEPT".
Managing Users in AD
OUs are protected by default from being deleted accidentally. To delete an OU this must first be disabled. To do this, select "View" in "Active Directory Users and Computers" and enable the "Advanced Features" option. Then right click the desired OU, choose "Properties" and then "Object", uncheck the "Protect Object from Accidental Deletion" box and apply. You are now able to delete the OU.
You can delegate permissions to OUs by right clicking an OU and selecting "Delegate Control" and then choosing a user or group. Typically this would be done with IT support groups so they can reset low-level user passwords.
The following PowerShell syntax can be used to reset a user password if you have the permissions to do so:
You can follow this up with the below syntax to ensure the user needs to change their password upon first login:
Managing Computers in AD
Generally, you would expect to have devices in AD split into three groups: workstations, servers and domain controllers. Workstations are where users do their day to day activities and should never have a privileged user signed in. Servers are used to provide services and domain controllers allow management of the AD domain.
Group Policies
Policies are managed through GPOs (Group Policy Objects), these are a collection of settings which can be applied to OUs. GPO can contain policies aimed at end users or computers.
GPOs are distributed via a share called SYSVOL which is stored in the DC. All users in domain should have access to this so they can sync GPOs periodically. The SYSVOL points by default to C:\Windows\SYSVOL\sysvol\. Any changes made to GPOs can take up to 2 hours, to force a sync you can use: gpupdate /force.
Authentication Methods
All credentials in a Windows domain are stored in the Domain Controllers. When a user authenticates to a service, it will ask the Domain Controller to verify they are correct. Two protocols can be used here; Kerberos or NetNTLM. Kerberos is used in most recent versions of Windows and is the default. NetNTLM is a legacy protocol kept for compatibility purposes.
Kerberos authentication provides users who login with tickets, these are proof that they have already authenticated in the network. Kerberos follows the below process:
User sends username and timestamp encrypted with a key derived from their password to the Key Distribution Center (KDC). The KDC creates and sends back a Ticket Granting Ticket (TGT) which allows that user to request more tickets to access certain services. This allows users to request tickets without having to login every time. A session key is also given to the user which is required to generate the following requests. The TGT is encrypted using the krbtgt accounts password hash - therefore the user cannot access its contents. The encrypted TGT holds a copy of the session key in its contents.
When a user wants to connect to a service, they use their TGT to ask the KDC for a Ticket Granting Service (TGS). TGS are tickets that allow a connection only to the service they were created for. When requesting a TGS, the user sends their username and timestamp encrypted using the session key, the TGT and a Service Principle Name (SPN) which denotes the service and server name. The result is that the KDC sends a TGS alongside a Service Session Key which authenticates the service being accessed. The TGS is encrypted using a key derived from the Service Owner Hash. The Service Owner is the user or machine account the service runs under.
The TGS can then be sent to the desired service to authenticate and establish a connection. The service uses its configured account's password hash to decrypt the TGS and validate the Service Session Key.
NetNTLM works like below:
Client sends authentication request to a service they want to access.
Server generates a random number and sends it as a challenge to client.
Client combines their NTLM hash with the challenge to generate a response.
Server forwards the challenge and response to the Domain Controller for verification.
The Domain Controller uses the challenge to recalculate its response and compares it to the original sent by the client, if both match, the client is authenticated, otherwise access is denied.
The server forwards the authentication result to the client.
Trees, Forests and Trusts
Trees : as a company grows it may end up with new laws and regulations to comply with in different countries - these may require GPO updates. IT staff in other countries will also need resources corresponding to their country without interfering with other teams. AD supports integration of multiple domains to allow network partitioning. For example, you could split domain.local into uk.domain.local and usa.domain.local. This allows the UK IT to have a DC which manages UK resource only, and USA the same. The UK users could not manage US users and vice versa. This requires a new security group; Enterprise Admins. These are users with admin rights over the entire enterprise including all sub-domains.
Forests : domains can be configured in different namespaces, for example, if a company continues to grow and acquires another company, these will eventually merge. The union of the two domain trees is known as a forest.
Trust relationships allow users from one domain to access resources on another domain. The simplest trust relationship that can be established is one-way trust. This means that if Domain A trusts Domain B then users on Domain B can be authenticated to access resources in Domain A. Two way trust relationships can also be set to allow users to be authenticated mutually.
Last updated