Benefits of using Active Directory
A few years ago, I was working on an Active Directory restructuring project for a world-famous pharmaceutical company. According to the company policies, I had to travel to their headquarters to perform the project tasks. On the day of my visit, I walked into the company's reception area. After I explained who I was and why I was there, the receptionist handed me a form to fill in. The form included questions such as name, phone number, the duration of the visit, and which department I was visiting. Once I had completed the form, I handed it over to the receptionist, and she had to make a few calls to verify whether my visit was expected, and then confirm my access to different buildings with the respective department managers.
Then, she produced a magnetic card with my details on it and handed it over to me. She instructed me how to use it and which buildings I was allowed into.
The following diagram outlines this process:
Figure 1.2: Process of entering physical headquarters
When we think about this process, we find that it contains the functions of a directory service:
- The form that the receptionist handed over to me contained certain questions to help her understand who I was. They were predefined questions, and I had to answer them in order to register my information in their system. Similar to this form, in a directory service, we have to provide values for specific attributes.
- Once I had submitted the form, she didn't hand over the magnetic card right away. She made a few calls to verify my identity, and also to confirm which buildings I would have access to. Then, my details were registered on the system, and it generated a magnetic card that had my photo and a barcode. With that, I became a part of their system, and that particular card was my unique identity within their organization. There would be no other visitor with the same barcode and identification number at the same time. Similarly, in a directory service, each identity is unique. If I needed to get access to buildings, I needed to tap the card at the entrance.
- Could I use my name or any other card to get through? No! The locking system of the building doors only recognized me if I presented the correct card. So, having a unique identity in their system was not enough; I needed to present it in the correct way to get the required access. Likewise, in an identity infrastructure, you need to validate your identity according to the method that the system has defined. It can be a username and password, a certificate, biometric information, and so on.
- I went to another building and tried to tap the card. Even when I used it correctly, the doors wouldn't open. The guard in the building asked for my card to check. Once I handed it over, he scanned it with a barcode reader and checked some information on his computer screen. Then he informed me that I was not allowed into that building, and he guided me to the correct building. This means that my information can be accessed from any building through their system in order to verify my identity and access permissions. In a similar way, in a directory, identities are saved in a central repository. This data can be accessed and verified from any system or person who has the authority.
- When I used the card in the correct buildings, it allowed me in. In the system, it first verified my identity and then checked whether I was authorized to work in that facility. If I was authorized, the system allowed access; if not, it rejected my request to enter.
- When I entered or left the building, I did not have to record my time. But the managers in that department knew how many hours I had worked, as my check-in and check-out times had been recorded in the system every time I tapped the card at the entrance or exit. These points collected the data, and the managers could review the information at any time. Similarly, as identities are unique in a directory, it helps to identify who has done what in a system in a given period (based on authentication and authorization data).
This system acted as an authentication and authorization system. It used different protocols and standards to manage and protect the identities that were saved in a central database. This is the primary function of a directory service.
Every organization has its own organizational structure. The most common way is to group roles, assets, and responsibilities into different departments; for example, sales, IT, production, and quality assurance. Apart from skills and knowledge, employers use company resources such as applications and hardware devices to reach their goals. In order to use these resources efficiently, it's important to have some kind of access control in place. The resources should be available for the required users at the required time. This is very easy if all the data about users, applications, and resources is recorded in a central repository that uses authentication and authorization in order to manage resources. These are the main characteristics of a directory service.
Different service providers have different directory services; for example, Novell directory services, the Oracle directory service, and the Red Hat directory service. However, the Microsoft Active Directory service is the most commonly used directory service in the industry.
In 1988, the ITU Telecommunication Standardization Sector (ITU-T) developed industry standards for directory services, called X.500. This was the foundation for Microsoft Active Directory services. In X.500, the Directory Access Protocol (DAP) was defined, and many alternatives were made available to enable its use with the TCP/IP networking stack. The most popular alternative was the Lightweight Directory Access Protocol (LDAP). The first version of this was released in 1993 with limited features. The University of Michigan released the first standalone LDAP daemon (slapd) server in 1995. The matured version of LDAP, LDAPv3, was released in 1997, and most vendors, including Microsoft, started developing directory services based on LDAP. Microsoft released its first Active Directory version with Windows 2000.
Centralized data repository
Active Directory stores the digital identities of users, applications, and resources in a multi-master database. This database is a file called ntds.dit
, and is based on the Joint Engine Technology (JET) database engine. The data in this database can be modified using any alternative domain controller. The Active Directory database can store almost two billion objects. Users can use the digital identities that are stored in Active Directory from anywhere in the network in order to access resources. Administrators can manage the authentication and authorization of the organizational digital identities from a centralized location. Without directory services, these digital identities would be duplicated across different systems, which would add administrative overheads to managing the data.
The replication of data
There are organizations that use a single domain controller. But when it comes to complex business requirements, such as branch offices and high availability, multiple domain controllers are required (we are going to look at domain controller placement in Chapter 11, Active Directory Services Part 01). If the digital identities are managed from a centralized system, it's important that each domain controller is aware of the changes that have been made to the Active Directory database. Say a user, Jane, in the sales department, forgets her password and asks the IT department to reset it.
In 30 minutes, she's going to be working from a branch office located in a different city. The IT administrator resets her password from the headquarters' domain controller, DC01. In order to have a successful login from the branch office, this change to the directory needs to be replicated over to the domain controller in the branch office, DC05.
Microsoft Active Directory has two types of replication. If a domain controller advertises the changes made on that particular domain controller to neighboring domain controllers, it is called outbound replication. If a domain controller accepts the changes advertised by neighboring domain controllers, it is called inbound replication. The replication connections (from who and to whom) and replication schedule can be modified based on the business requirements.
High availability
High availability is important for any business-critical system in an organization. This is also applicable to domain controllers. On other systems, in order to implement high availability, we need to make software or hardware changes. With built-in fault-tolerance capabilities, Active Directory domain controllers do not need additional changes. A multi-master database and the replication of domain controllers allow users to continue with authentication and authorization from any available domain controller at any time. The Microsoft recommendation is to run at least two domain controllers to maintain the high availability of the service.
Security
Data and identity protection are very important in modern businesses. We are living in a world where identity is the new perimeter. A significant portion of this book is focused on the features of Active Directory that can secure your digital identities from emerging threats. Active Directory allows you to use different authentication types, group policies, and workflows to protect the resources in your network. Even applications benefit from these technologies and methodologies.
Auditing capabilities
Setting up advanced security policies will not be enough to protect your digital identities. Periodic audits will help you to understand new security threats. Active Directory roles come with in-built auditing capabilities. In an Active Directory setup, there can be events related to user authentication, directory service modifications, or access violation. All these events will be recorded in the event viewer under different logs.
Single sign-on (SSO)
In an organization, there can be many different applications in use. Each of these applications may have a different authentication mechanism. It will be difficult to maintain different user credentials for authentication on different applications. Most application vendors now support integration with Active Directory for authentication. This means that with Active Directory credentials, you can authenticate on different systems and applications that are used by your organization. You will not need to keep typing your credentials in order to get access. Once you authenticate on a computer, the same session will be used to authenticate other Active Directory-integrated applications.
Schema modification
Any kind of database has its own structure, called the schema. This is also applicable to an Active Directory database. The Active Directory schema mainly contains two types of information.
- A definition of every object class in Active Directory
- A definition of every attribute in an Active Directory object
Based on the AD version, the number of object classes and the number of attributes defined in the schema can be different. By knowing the schema, you can modify or extend it. This is important for the development of Active Directory-integrated applications. Microsoft publishes Active Directory Service Interfaces (ADSI) with a set of Component Object Model (COM) interfaces, and it can be used to access Active Directory service features from different network providers. Application developers can use it to develop their application to be Active Directory-integrated and publish it to the directory. Users can search for the service through Active Directory, and applications can access Active Directory objects as required.
Querying and indexing
By maintaining a central data repository, Active Directory also allows users and applications to query objects and retrieve accurate data. If I need to find the user John's account, I do not need to know which branch he is in, or to which department he belongs. With a simple Active Directory query, I will be provided with information about the user account. In a manner similar to when we add a new object to the directory, objects will publish their attributes and make them available to users and applications for queries.
These are some of the main capabilities of the Active Directory service, and these features will be explained in detail in later chapters, including how to plan, implement, and maintain them within your identity infrastructure.