1- INTRODUCTION(windows domains)
Why Active Directory?
Picture yourself administering a small business network with only five computers and
five employees. In such a tiny network, you will probably be able to configure each
computer separately without a problem. You will manually log into each computer,
create users for whoever will use them, and make specific configurations for each
employee's accounts. If a user's computer stops working, you will probably go to their
place and fix the computer on-site.
While this sounds like a very relaxed lifestyle, let's suppose your business suddenly
grows and now has 157 computers and 320 different users located across four
different offices. Would you still be able to manage each computer as a separate
entity, manually configure policies for each of the users across the network and
provide on-site support for everyone? The answer is most likely no.
Windows domain is a group of users and computers under the administration of a
given business.
The main idea behind a domain is to centralize 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).
The main advantages of having a configured Windows domain are:
• Centralized identity management: All users across the network can be
configured from Active Directory with minimum effort.
• Managing security policies: You can configure security policies directly from
Active Directory and apply them to users and computers across the network as
needed.
• 2- ACTIVE DIRECTORY
The core of any Windows Domain is the Active Directory Domain Service (AD DS).
This service acts as a catalogue that holds the information of all of 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 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.
Users can be used to represent two types of entities:
• People: users will generally represent persons in your organization that need
to access the network, like employees.
• Services: users to be used by services like 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 account name is the computer's name followed by a dollar sign. For
example, a machine named DC01 will have a machine account called DC01$DC01$.
Security Groups
Groups can have both users and machines as members. If needed, groups can include
other groups as well.
Several groups are created by default in a domain that can be used to grant specific
privileges to users. As an example, here are some of the most important groups in a
domain:
ACTIVE DIRECTORY USERS AND COMPUTERS
To configure users, groups or machines in Active Directory, we need to log in to the
Domain Controller and run "Active Directory Users and Computers" from the start
menu :
This will open up a window where you can see the hierarchy of users, computers and
groups that exist in the domain.
These objects are organized in Organizational Units (OUs) which are container
objects that allow you to classify users and machines. OUs are mainly used to define sets of
users with similar policing requirements.
EX: The people in the Sales department of your organization are likely to have a different set of policies
applied than the people in IT, for example. Keep in mind that a user can only be a part of a single OU at
a time.
If you open any OUs, you can see the users they contain and perform simple tasks like
creating, deleting or modifying them as needed. You can also reset passwords if
needed
there are other default containers apart from the THM OU. These containers are
created by Windows automatically and contain the following:
• Built-in: 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 apply to a domain-wide context.
• Managed Service Accounts: Holds accounts used by services in your Windows
domain.
Security Groups vs OUs:
• OUs are handy for applying policies to users and computers, which include
specific configurations that pertain 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 sense to try to apply two different sets
of policies to a single user.
• Security Groups, on the other hand, 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.
3-Managing user in ACTIVE DIRECTORY:
Deleting existing (ou):
If you try to right-click and delete the OU, you will get the following error:
OUs are protected against accidental deletion To delete the OU, we need to enable
the Advanced Features in the View menu:
This will show you some additional containers and enable you to disable the
accidental deletion protection. To do so, right-click the OU and go to Properties. You
will find a checkbox in the Object tab to disable the protection:
DELEGATION
One of the nice things you can do in AD is to give specific users some control over some OUs.
This process is known as delegation and allows you to grant users specific privileges to
perform advanced tasks on OUs without needing a Domain Administrator to step in.
EX: granting the IT support the privileges to reset other low-privilege users' passwords.
we will delegate control over the Sales OU to Phillip. To delegate control over an OU, you can
right-click it and select Delegate Control:
This should open a new window where you will first be asked for the users to whom you want
to delegate control:
Note: To avoid mistyping the user's name, write "phillip" and click the Check Names button.
Windows will autocomplete the user for you.
Click OK, and on the next step, select the following option:
Click next a couple of times, and now Phillip should be able to reset passwords for any
user in the sales department.
4-managing computers in ACTIVE DIRECTORY
all the machines that join a domain (except for the DCs) will be put in the container
called "Computers". If we check our DC, we will see that some devices are already
there:
We can see some servers, some laptops and some PCs corresponding to the users in
our network. Having all of our devices there is not the best idea since it's very likely
that you want different policies for your servers and the machines that regular users
use on a daily basis.
While there is no golden rule on how to organize your machines, an excellent starting
point is segregating devices according to their use. In general, you'd expect to see
devices divided into at least the three following categories:
1. 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.
2. 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.
3. 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.
5-group policies
we have organised users and computers in OUs just for
the sake of it, but the main idea behind this is to be able
to deploy different policies for each OU individually. That
way, we can push different configurations and security
baselines to users depending on their department.
To configure GPOs, you can use the Group Policy Management tool, available from
the start menu:
The first thing you will see when opening it is your complete OU hierarchy, as defined
before. 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. As an
example, you can see there are some already existing GPOs in your machine:
Let's change the minimum password length policy to require users to have at least 10
characters in their passwords. To do this, right-click the GPO and select Edit:
This will open a new window where we can navigate and edit all the available
configurations. To change the minimum password length, go to (Computer
Configurations -> Policies -> Windows Setting -> Security Settings -> Account
Policies -> Password Policy) and change the required policy value:
If more information on any of the policies is needed, you can double-click them and
read the Explain tab on each of them:
GPO distribution
GPOs are distributed to the network via a network share called SYSVOL, which is stored
in the DC. All users in a domain should typically have access to this share over the
network to sync their GPOs periodically. The SYSVOL share points by default to the
C:\Windows\SYSVOL\sysvol\ directory on each of the DCs in our network.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
If you want to force any particular computer to sync its GPOs immediately, you can
always run the following command on the desired computer:
PS C:\> gpupdate /force
Questions and answers:
When using Windows domains, all credentials are stored in the Domain Controllers.
Whenever a user tries to authenticate to a service using domain credentials, the
service will need to ask the Domain Controller to verify if they are correct. Two
protocols can be used for network authentication in windows domains:
• Kerberos: Used by any recent version of Windows. This is the default protocol
in any recent domain.
• NetNTLM: Legacy authentication protocol kept for compatibility purposes.
1-Kerberos authentication process:
1. The user sends their username and a timestamp encrypted using a key derived
from their password to the Key Distribution Center (KDC), a service usually
installed on the 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 may sound a bit weird, but it 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.
Notice 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 part 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.
2. 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 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.
3. 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.
2-NTLM AUTHENTICATION process.
• 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 verification.
• 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.
*-Note: The described process applies when using a domain account. If a local account
is used, the server can verify the response to the challenge itself without requiring
interaction with the domain controller since it has the password hash stored locally on
its SAM.
7-Trees, Forests and Trusts
TREES:
Imagine, for example, that suddenly your company expands to a new country. The
new country has different laws and regulations that require you to update your GPOs
to comply. In addition, you now have IT people in both countries, and each IT team
needs to manage the resources that correspond to each country without interfering
with the other team. While you could create a complex OU structure and use
delegations to achieve this, having a huge AD structure might be hard to manage and
prone to human errors.
Luckily for us, Active Directory supports integrating 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 ( thm.local in our example), those domains
can be joined into a Tree.
If our thm.local domain was split into two subdomains for UK and US branches, you
could build 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
respective DCs, but not other branches' DCs. Policies can also be configured
independently for each domain in the tree.
A new security group needs to be introduced when talking about trees and forests.
The Enterprise Admins group will grant a user administrative privileges over all of an
enterprise's domains. Each domain would still have its Domain Admins with
administrator privileges over their single domains and the Enterprise Admins who can
control everything in the enterprise.
Forests
The domains you manage can also be configured in different namespaces. Suppose
your company continues growing and eventually acquires another company called
MHT Inc. When both companies merge, you will probably have different domain trees
for each company, each managed by its own IT department. The union of several trees
with different namespaces into the same network is known as a forest.
Trust Relationships:
Having multiple domains organized in trees and forest allows you to have a nice
compartmentalized network in terms of management and resources. But at a certain
point, a user at THM UK might need to access a shared file in one of MHT ASIA servers.
For this to happen, domains arranged in trees and forests are joined together by trust
relationships.
In simple terms, having a trust relationship between domains allows you to authorise
a user from domain THM UK to access resources from domain MHT EU.
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 authorized to access resources on AAA:
The direction of the one-way trust relationship is contrary to that of the access
direction. Two-way trust relationships can also be made to allow both domains to mutually
authorize users from the other. By default, joining several domains under a tree or a forest will form a
two-way trust relationship.
