Active Directory
Windows Domains
A Windows domain is a group of users and computers under the administration of a given business. The main idea behind a domain is to centralise the administration of common components of a Windows computer network in a single repository called Active Directory (AD). The server that runs the Active Directory services is known as a Domain Controller (DC).
Active Directory Domain Service (AD DS)
This service acts as a catalogue that holds the information of all the objects that exist on your network. Amongst the many objects supported by AD, we have users, groups, machines, printers, shares, and many others.
Users
Users are one of the most common object types in Active Directory. Users are one of the objects known as security principals, meaning that they can be authenticated by the domain and can be assigned privileges over resources like files or printers. You could also say that a security principal is an object that can act upon resources in the network.
Users can be used to represent two types of entities:
People: users will generally represent persons in an organization that need access to the network.
Services: users can be used by services such as IIS or MSSQL. Every single service requires a user to run, but service users are different from regular users as they will only have the privileges needed to run their specific service.
Machines
Machines are another type of object within Active Directory; for every computer that joins the Active Directory domain, a machine object will be created. Machines are also considered "security principals" and are assigned an account just as any regular user. This account has somewhat limited rights within the domain itself.
The machine accounts themselves are local administrators on the assigned computer, they are generally not supposed to be accessed by anyone except the computer itself, but as with any other account, if you have the password, you can log in with it.
Machine account passwords are automatically rotated out and are generally comprised of 120 random characters
Generally you can expect to see devices divided into at least the three follwing categories:
Workstations
Workstations are one of the most common devices within an Active Directory domain. Each user in the domain will likely be logging into a workstation. This is the device they will use to do their work or normal browsing activities. These devices should never have a privileged user signed into them.
Servers
Servers are the second most common device within an Active Directory domain. Servers are generally used to provide services to users or other servers.
Domain Controllers
Domain Controllers are the third most common device within an Active Directory domain. Domain Controllers allow you to manage the Active Directory Domain. These devices are often deemed the most sensitive devices within the network as they contain hashed passwords for all user accounts within the environment.
Security Groups
You can define user groups to assign access rights to files or other resources to entire groups instead of single users. This allows for better manageability as you can add users toan existing group, and they will automatically inherit all of the group's privileges. Security groups are also considered security principals and, therefore can have privileges over resources on the network.
Groups can have both users and machines as members. If needed, groups can include other groups as well.
Default Security Groups:
Domain Admins: Users of this group have administrative privileges over the entire domain. By default, they can administer any computer on the domain, including the DCs.
Server Operators: Users in this group can administer Domain Controllers. They cannot change any administrative group memberships.
Backup Operators: Users in this group are allowed to access any file, ignoring their permissions. They are used to perform backups of data on computers.
Account Operators: Users in this group can create or modify other accounts in the domain.
Domain Users: Includes all existing user accounts in the domain.
Domain Computers: Includes all existing computers in the domain.
Domain Controllers: Includes all existing DCs on the domain.
Full list of default security groups:
Organizational Units (OUs)
Organizations Units are container objects that allow you to classify users and machines. OUs are mainly used to define sets of users with similar policing requirements. An object can only be a part of a single OU at a time
Default Containers
Builtin: Contains default groups available to any Windows host
Computers: Any machine joining the network will be put here by default. You can move them if needed.
Domain Controllers: Default OU that contains the DCs in your network
Users: Default users and groups that appy to a domain-wide context
Managed Service Acconts: Holds accounts used by services in your Windows domain
OUs vs Security Groups
OUs are handy for applying policies to users and computers, which include specific configurations that pretain to sets of users depending on their particular role in the enterprise. Remember, a user can only be a member of a single OU at a time as it wouldn't make send to try to apply two sets of policies to a single user.
Security Groups are used to grant permissions over resources. For example, you will use groups if you want to allow some users to access a shared folder or network printer. A user can be a part of many groups, which is needed to grant access to multiple resources.
Group Policy
Windows manages group permissions and policies through Group Policy Objects (GPO). GPOs are simply a collection of settings that can be applied to OUs. GPOs can contain policies aimed at either users or computers, allowing you to set a baseline of specific machines and identities.
To configure GPOs, you can use the Group Policy Management tool in the start menu:
To configure Group Policies, you first create a GPO under Group Policy Objects and then link it to the OU where you want the policies to apply.
In the above image, there are 3 GPOs that have been created. the Default Domain Policy and RDP Policy are linked to the thm.local domain as a whole, and the Default Domain Controllers Policy is linked to the Domain Controllers OU only. Any GPO will apply to the linked OU and any sub-OUs under it.
GPOs are distributed to the network via a network share called SYSVOL, which is stored in the DC. The SYSVOL share points by default to the C:\Windows\SYSVOL\sysvol\ directory on each of the DCs in our netowkr.
Once a change has been made to any GPOs, it might take up to 2 hours for computers to catch up. If you need to force a synch of GPOs immediately, you can run the following command:
Authentication in Active Directory
When using Windows domains, all credentials are stored in the Domain Controllers. Whenever a user tries to authenticate to service using domain credentials, the service will need to ask to Domain Controller to verify if they are correct. Two protocols can be used for network authentication in Windows domains:
Kerberos: Used by modern versions of Windows. This is the default protocol in recent domains.
NetNTLM: Legacy authentication protocol kept for backwards compatibility.
While NetNTLM should be considered obsolute, most networks will still have both procols enabled.
Kerberos Authentication
Kerberos authentication is the default authentication protocol for recent versions of Windows. Users who log into a service using Kerberos will be assigned tickets. Tickets are proof of previous authentication. Users with tickets can present them to a service to demonstrate that they have already authenticated into the network before and are therefore enabled to use it.
When Kerberos is used for authentication, the following process happens:
The user sends their username and a timestamp encrypted using a key derived from their password to the Key Distrobution Center (KDC), a service usually installed on a Domain Controller in charge of creating Kerberos tickets on the network.
The KDC will create and send back a Ticket Granting Ticket(TGT), which will allow the user to request additional tickets to access specific services. The need for a ticket to get more tickets allows users to request service tickets without passing their credentials every time they want to connect to a service. Along with the TGT, a Session Key is given to the user, which they will need to generate the following requests.
Note that the TGT is encrypted using the krbtgt account's password hash, and therefore the user can't access its contents. It is essential to know that the encrypted TGT includes a copy of the Session Key as parts of its contents, and the KDC has no need to store the Session Key as it can recover a copy by decrypting the TGT if needed.
When a user wants to connect to a service on the network like a share, website, or database, they will use their TGT to ask the KDC for a Ticket Granting Service (TGS). TGS are tickets that allow connection only to the specific service they were created for. To request a TGS, the user will send their username and a timestamp encrypted using the Session Key, along with the TGT and a Service Principal Name (SPN), which indicates the service and the server name we intend to access.
As a result, the KDC will send us a TGS along with a Service Session Key, which we will need to authenticate to the service we want to access. The TGS is encrypted using a key derived from the Service Owner Hash. The Service Owner is the user or machine account that the service runs under. The TGS contains a copy of the Service Session Key on its encrypted contents so that the Service Owner can access it by decrypting the TGS.
The TGS can then be sent to the desired service to authenticate and establish a connection. The service will use its configured account's password hash to decrypt the TGS and validate the Service Session Key.
NetNTLM Authentication
NetNTLM works using a challenge-response mechanism.
The client sends an authentication request to the server they want to access
The server generates a random number and sends it as a challenge to the client
The client combines their NTLM password hash with the challenge (and other known data) to generate a response to the challenge and sends it back to the server for verifications
The server forwards the challenge and the response to the Domain Controller for verification.
The domain controller uses the challenge to recalculate the response and compares it to the original response sent by the client. If they both match, the client is authenticated; otherwise, access is denied. The authentication result is sent back to the server.
The server forwards the authentication result to the client.
The user's password (or hash) is never transmitted through the network for security.
Trees, Forests, and Trusts
Trees
Active Directory supports the integration of multiple domains so that you can partition your network into units that can be managed independently. If you have two domains that share the same namespace, those domains can be joined into a Tree.
For example, if a domain thm.local was split into two subdomains for UK and US branches, you could be a tree with a root domain of thm.local and two subdomains called uk.thm.local and us.thm.local, each with its AD, computers, and users.
This partitioned structure gives us better control over who can access what in the domain. The IT people from the UK will have their own DC that manages the UK resources only. For example, a UK user would not be able to manage US users. In that way, the Domain Administrators of each branch will have complete control over their respecting DCs, but not other branches' DCs.
When dealing with Trees and Forests in AD, a new security group is introduced called the Enterprise Admins group. This group will grant a user administrative privileges over all of an Enterprise's domains. Each domain will still have its Domain Admins with administrator privileges over their single domains, and the Enterprise Admins who can control everything in the enterprise.
Forests
Domains can also be configured in different namespaces. The union of multiple trees with different namespaces into the same network is known as a forest.
Trust Relationships
Having multiple domains organised in trees and forests allows you to have a compartmentalised network in terms of management and resources. If a user from one domain requires access to a resource on a separate domain in the forest, the domains in the trees and forests must be joined together by a trust relationship.
The simplest trust relationship that can be established is a one-way trust relationship. In a one-way trust, if Domain AAA trusts Domain BBB, this means that a user on BBB can be authorised to access resources on AAA:
Two-way trust relationships can also be made to allow both domains to mutually authorise users from each other. By default, joining severals domains under a tree or forest will form a two-way trust relationship.
Managing AD with PowerShell
Password Change
Force Password Change on Next Logon
Last updated