Introduction
The AWS Directory Service is an Amazon Web Services product that allows an IT administrator to operate Microsoft Active Directory (AD) in the public cloud, facilitating user and group data setup and providing end-users access to AWS cloud services.
AWS Directory Service offers several options for integrating Microsoft Active Directory (AD) with other AWS services. Administrators use directories to control access to information and resources. They hold information about users, groups, and devices. Customers that wish to use existing Microsoft AD or Lightweight Directory Access Protocol (LDAP)–aware apps in the cloud can leverage AWS Directory Service's many directory options. Developers that require a directory to handle users, groups, devices, and access have the same options.
Let us now understand this AWS directory service in depth.
AWS Managed Microsoft AD
AWS Directory Service allows you to administer Microsoft Active Directory (AD). Windows Server 2012 R2 powers AWS Directory Service for Microsoft Active Directory, often known as AWS Managed Microsoft AD.
When you choose and activate this directory type, a highly available pair of domain controllers connected to your virtual private cloud is formed (VPC). The domain controllers are located in several Availability Zones in the Region of your choice. Monitoring and recovery of hosts, data replication, snapshots, and software upgrades are configured and managed automatically.
Using AWS Managed Microsoft AD, you may operate directory-aware workloads on the AWS Cloud, such as Microsoft SharePoint and custom.NET and SQL Server-based apps. You may also establish a trust connection between AWS Managed Microsoft AD in the AWS Cloud and your current on-premises Microsoft Active Directory, granting users and groups access to resources in either domain using single sign-on (SSO).
AWS Directory Service makes it simple to create and manage directories in the AWS Cloud and connect your AWS resources to an existing on-premises Microsoft Active Directory. Once your directory has been built, you may use it for a variety of purposes, including:
- Administer users and groups.
- Allow users to access applications and services with a single sign-on.
- Create and implement group policies.
- Simplify the deployment and administration of Linux and Microsoft Windows workloads in the cloud.
- AWS Managed Microsoft AD may be used to implement multi-factor authentication by connecting with your current RADIUS-based MFA infrastructure to offer an extra layer of protection when users access AWS applications.
- Connect to Amazon EC2 Linux and Windows instances securely.
Let us now look at some of the key concepts of the AWS Managed Microsoft AD.
Active Directory schema
A schema is the definition of characteristics and classes in a distributed directory, which is analogous to fields and tables in a database. Schemas are a collection of rules that govern the kind and structure of data that may be added to or stored in a database. One class that is saved in the database is the User class. The user's first name, last name, phone number, and so on are examples of User class characteristics.
Schema elements
The essential pieces used to build object definitions in the schema are attributes, classes, and objects. The following section contains information regarding schema elements that you should be aware of before beginning the process of extending your AWS Managed Microsoft AD schema.
Attributes
Each schema attribute, equivalent to a database field, has various properties that determine the attribute's features. For example, the property LDAPDisplayName is used by LDAP clients to read and write the attribute. All attributes and classes must use the same LDAPDisplayName property. See Characteristics of Attributes for a comprehensive collection of attribute characteristics on the MSDN website. See Defining a New Attribute on the MSDN website for further information on how to create a new attribute.
Classes
Classes are similar to tables in a database in that they must have multiple attributes declared. The class category, for example, is defined by the objectClassCategory. See Characteristics of Object Classes for a comprehensive list of class characteristics. See Defining a New Class for further information on building a new class.
Object identifier (OID)
Each class and attribute must have a unique OID across all your objects. To ensure uniqueness, software suppliers must establish their own OID. When many applications use the same attribute for different reasons, uniqueness prevents conflicts. A root OID can be obtained from an ISO Name Registration Authority to assure uniqueness. You may also receive a basic OID from Microsoft. See Object Identifiers on the MSDN website for further information on OIDs and how to acquire them.
Schema linked attributes
Some attributes are connected via forward and back links between two classes. Groups are the finest illustration. When you look at a group, you can see who the members are; when you look at a user, you can see which groups they belong to. Active Directory generates a forward connection to the group when you add a user to it. The user is then linked back to the group via Active Directory. When establishing a connected attribute, a unique link ID must be generated. See Linked Attributes on the MSDN website for further information.
Patching and Maintenance of AWS Directory Service
AWS Directory Service for Microsoft Active Directory, often known as AWS DS for AWS Managed Microsoft AD, is a managed service of Microsoft Active Directory Domain Services (AD DS). The system's domain controllers (DCs) run Microsoft Windows Server 2012 R2, and AWS adds software to the DCs for service management reasons. AWS patches DCs to offer new capabilities and maintain Microsoft Windows Server software up to date. Your directory is still accessible during the patching procedure.
Ensuring availability
Each directory comprises two DCs, each of which is installed in a distinct Availability Zone. You have the option of adding DCs to improve availability even more. AWS repairs your DCs sequentially, and the DC that AWS is currently patching is inaccessible throughout this period. If one or more of your DCs is momentarily unavailable, AWS delays patching until your directory has at least two working DCs. This allows you to use the other running DCs throughout the patch process, which normally takes 30 to 45 minutes per DC but can vary.
To guarantee that your applications can contact an operational DC if one or more DCs are unavailable for any reason, including patching, you should use the Windows DC finder service rather than static DC addresses.
Understanding the patching schedule
AWS uses Microsoft updates to keep the Microsoft Windows Server software on your DCs up to date. As Microsoft releases monthly Windows Server rollup patches, AWS takes every effort to test and deliver the rollup to all client DCs within three calendar weeks. Furthermore, AWS evaluates updates released by Microsoft outside of the monthly rollup based on their relevance to DCs and urgency. AWS takes every effort to test and apply security fixes that Microsoft deems as Critical or Important and that are applicable to DCs within five days.
Group Managed Service Accounts
With Windows Server 2012, Microsoft offered a new approach for administrators to manage service accounts known as group Managed Service Accounts (gMSAs). Service administrators no longer had to manually handle password synchronization across service instances when using gMSAs. Instead, an administrator might
simply build a gMSA in Active Directory and then configure many service instances to use that single gMSA.
To enable users in AWS Managed Microsoft AD to establish gMSAs, add their accounts to the AWS Delegated Managed Service Account Administrators security group. The Admin account is a member of this group by default. Group Managed Service Accounts Overview on the Microsoft TechNet website contains more information about gMSAs.
Kerberos Constrained Delegation
Windows Server has a feature called Kerberos constrained delegation. This feature allows service administrators to set and enforce application trust boundaries by restricting the scope in which application services can act on behalf of a user. This is important for configuring which front-end service accounts can delegate to certain backend services.
Kerberos restricted delegation also limits your gMSA from connecting to any and all services on behalf of your Active Directory users, preventing unscrupulous developers from abusing the system.
Consider the case of user smith, who connects to an HR application. You want the SQL Server to use the database permissions set by Smith. However, SQL Server initiates the database connection by default using the service account credentials, which apply hr-app-permissions services rather than Smith's set rights. You must enable the HR payroll application to connect to the SQL Server database using Smith's credentials. To do so, activate Kerberos constrained delegation on your AWS Managed Microsoft AD directory for the hr-app-service service account. When smith signs in, Active Directory generates a Kerberos ticket, which Windows employs when Smith seeks to access other network services.
Kerberos delegation allows the hr-app-service account to reuse the smith Kerberos ticket when accessing the database, allowing Smith permissions to be applied when the database connection is opened.
To provide users in AWS Managed Microsoft AD authorization to implement Kerberos constrained delegation and add their accounts to the AWS Delegated Kerberos Delegation Administrators security group. The Admin account is automatically a member of this group. Read the Microsoft TechNet website's Kerberos Constrained Delegation Overview for additional information on Kerberos constrained delegation.