What you’ll learn:
Active Directory authentication and authorization are security processes. These processes are necessary in any environment so that the resources of an environment are not misused by anyone. In this article, we will take a look at what is authentication and authorization in an AD environment, and how AD tackles these process. Before going further, let’s take a look at the difference between authentication and authorization.
Authentication vs authorization
Authentication and authorization are both security related processes. However, their functions are different. Authentication deals with the verification of an identity. It determines whether a person or a machine is who they say they are.
Authorization on the other hand deals with allowing access to resources for a person or a machine. Authorization determines whether a person or a machine has the permissions necessary to grant them access to certain resources in a network.
What is AD authentication?
The AD authentication system verifies the identity of any user who is trying to login to the AD network. After successful authentication, the user is allowed to access the AD network’s resources. Active Directory uses the Kerberos protocol for authentication of its users. The Kerberos authentication protocol succeeds the NTLM protocol. Kerberos authentication is far superior to NTLM authentication because Kerberos uses a stronger encryption format called symmetric key cryptography and the whole authentication process is done by a third independent entity apart from the client and the server that grants a service.
Brief history of Kerberos protocol
Kerberos protocol is a cross-platform authentication protocol. It was initially developed at the Massachusetts Institute of Technology for a project called Athena. Later, Kerberos became the backbone of authentication for Active Directory since the introduction Windows Server 2003. The protocol derives its name from the Greek mythological character Cerberus, which is a three-headed dog. This is because Kerberos protocol uses three components for the authentication process.
How AD authentication works using Kerberos
The three components for a Kerberos authentication process to work are:
- The client (The user’s system)
- The service server
- The Key Distribution Center(KDC).
The KDC has two services, which are:
- The Authentication Service(AS)
- The Ticket Granting Service(TGS)
The KDC service is installed in the domain controller.
Let’s say that John is a client who wants access to a service in server A. Here’s how the three components of Kerberos authentication function to provide AD authentication:
- Initially, when a John joins the network, a secret key is generated using the password that John created, and it shared between John’s system which is the client and the KDS.
- When John enters his user ID and password for authentication, his system generates a secret key using the password entered.
- His system then sends a plain text file with the his user ID and an authentication request to the KDC. The authentication request is time stamped. This makes sure that the probability of a replay attack is less. A replay attack is when a hacker retrieves the plain text file and sends it to the KDC masquerading as the user. However, this process takes more time than if the attack did not take place. So, if the request is time stamped, the KDC can detect the time delay in receiving the request, and it will deny it if the time delay is beyond the set threshold.
- The AS part of KDC checks whether John is present in the KDC database. If he is not present, the KDC denies the request. If he is present, the AS sends back a Ticket Granting Ticket(TGT) which is also time stamped and encrypted using the secret key that was generated with John’s password.
- Once the TGT is obtained, John’s system decrypts the TGT using the secret key generated from the password. If John entered the right password, the secret key generated by John’s system will match the secret key that the KDC used to encrypt the TGT. Thus, the TGT can be decrypted. If the TGT session time lapses, John’s system sends another request for a TGT.
- Once the TGT is decrypted, John’s system sends the TGT and a Service Principal Name(SPN) of the required service from server A to the KDC.
- This time, the TGS part of the KDC verifies the TGT with the database and then sends back an encrypted session key to access server A back to John’s system.
- John’s system then sends the Session key to Server A, which verifies the key. Once the session key is validated, John is granted permission to access the service from Server A, thus completing the AD authentication process using Kerberos protocol.
What is AD authorization?
AD authorization process is used to secure the AD resources from unauthorized access. After a user is authenticated using the AD authentication process, the resources that the user can access are also defined. This definition is done using access control lists (ACL) and access control entries (ACE). Each object in AD has an ACL associated with it that determines the users who can access the object.
Access control lists and access control entries
ACLs are tables, or simple lists, that define the trustees that have access to the object in question, and also what type of access these trustees have. A trustee may be any security principal such as user account, group account, or a logon session. Each ACL has a list of ACEs, and each ACE names a trustee and defines what type of access the trustee has for the object in question.
There are two types of ACLs, which are as follows:
- Discretionary Access Control List (DACL)- The DACL performs the function of defining the access rights of a trustee to the object in question. DACLs contain ACEs that specifies whether the trustees are granted or denied access to the object.
- System Access Control List (SACL)- The SACL performs the function of generating audit logs that specify whether a trustee was attempting to gain access to an object. It also specifies whether access was granted or denied, and if granted, what type of access was given to the trustee.
When a user tries to access an object in the AD network, the AD authorization process checks the DACL to see whether the user is mentioned, and if so, whether the user is given permission and what type of permission is given. Only if the user is given permission will the system authorize the user to access the resource. This is how user authorization works in the AD environment.
The SACL is used to track an object’s security based on how a user or group accesses the object. For example, you can audit whether a user was able to access the object using particular permission (such as Read, Write, or Full Control). Information about what to audit is kept in ACEs, which are stored within the SACL. These entries control what is audited, and contain information about the events to be logged. In doing this, records can be kept on the security of objects, and whether specific users or groups are able to successfully access them.
A DACL is a listing of ACEs for users and groups and includes information about the permissions that a user or group has to a file. The DACL controls whether a user is granted or denied access to an object. ACEs in the DACL explicitly identify individual users and groups, and the permissions granted to each. Because only users and groups identified in the DACL can access an object in Active Directory, any user or group that isn’t specified is denied access.
Active Directory places the permissions you can apply to objects into two categories: standard permissions and special permissions. Standard permissions are those that are commonly applied to objects, whereas special permissions provide additional access control.