All posts by Peter Pereira

How to seamlessly domain join Amazon EC2 instances to a single AWS Managed Microsoft AD Directory from multiple accounts and VPCs

Post Syndicated from Peter Pereira original https://aws.amazon.com/blogs/security/how-to-domain-join-amazon-ec2-instances-aws-managed-microsoft-ad-directory-multiple-accounts-vpcs/

You can now share a single AWS Directory Service for Microsoft Active Directory (also known as an AWS Managed Microsoft AD) with multiple AWS accounts within an AWS Region. This capability makes it easier and more cost-effective for you to manage directory-aware workloads from a single directory across accounts and Amazon Virtual Private Clouds (Amazon VPC). Instead of needing to manually domain join your Amazon Elastic Compute Cloud instances (EC2 instances) or create one directory per account and VPC, you can use your directory from any AWS account and from any VPC within an AWS Region.

In this post, I show you how to launch two EC2 instances, each in a separate Amazon VPC within the same AWS account (the directory consumer account), and then seamlessly domain-join both instances to a directory in another account (the directory owner account). You’ll accomplish this in four steps:

  1. Create an AWS Managed Microsoft AD directory.
  2. Establish networking connectivity between VPCs.
  3. Share the directory with the directory consumer account.
  4. Launch Amazon EC2 instances and seamlessly domain join to the directory.

Solution architecture

The following diagram shows the steps you’ll follow to use a single AWS Managed Microsoft AD in multiple accounts. Note that when you complete Step 3, AWS Microsoft Managed AD will create a shared directory in the directory consumer account. The shared directory contains the metadata that enables the EC2 seamless domain join to locate the directory in the directory owner account. Note that there are additional charges for directory sharing.
 

Figure 1: Architecture diagram showing directory sharing

Figure 1: Architecture diagram showing directory sharing

Step 1: Create an AWS Microsoft AD directory

First, follow the steps to create an AWS Microsoft AD directory in your directory owner AWS Account and Amazon VPC. In the examples I use throughout this post, my domain name is example.com, but remember to replace this with your own domain name.

When you create your directory, you’ll have the option in Step 3: Choose VPC and subnets to choose the subnets in which to deploy your domain controllers. AWS Microsoft AD ensures that you select subnets from different Availability Zones. In my example, I have no subnet preference, so I choose No Preference from the Subnets drop-down list.
 

Figure 2: Selecting Subnet preference

Figure 2: Selecting Subnet preference

Select Next to review your configuration, and then select Create directory. It can take 20-45 minutes for the directory creation process to finish. While AWS Managed Microsoft AD creates the directory, you can move on to the next step.

Step 2: Establish networking connectivity between VPCs

To domain join your Amazon EC2 instances to your directory, you need to establish networking connectivity between the VPCs. There are multiple methods of establishing networking connectivity between two VPCs. In this post, I’ll show you how to use Amazon VPC peering by performing the following steps:

  1. Create one VPC peering connection between the directory owner VPC-0 and directory consumer VPC-1, then create another connection between the directory owner VPC-0 and directory consumer VPC-2. For reference, here are my own VPC details:

    VPC CIDR block
    Directory owner VPC-0 172.31.0.0/16
    Directory consumer VPC-1 10.0.0.0/16
    Directory consumer VPC-2 10.100.0.0/16
  2. Enable traffic routing between the peered VPCs by adding a route to your VPC route table that points to the VPC peering connection to route traffic to the other VPC in the peering connection. I’ve configured my directory owner VPC-0 route table by adding the following VPC peering connections:

    Destination Target
    172.31.0.0/16 Local
    10.0.0.0/16 pcx-0
    10.100.0.0/16 pcx-1
  3. Configure each of the directory consumer VPC route tables by adding the peering connection with the directory owner VPC-0. If you want, you can also create and attach an Internet Gateway to your directory consumer VPCs. This enables the instances in the directory consumer VPCs to communicate with the AWS System Manager (SSM) agent that performs the domain join. Here are my directory consumer VPC route table configurations:
    VPC-1 route table:

    Destination Target
    10.0.0.0/16 Local
    172.31.0.0/16 pcx-0
    0.0.0.0/0 igw-0

    VPC-2 route table:

    Destination Target
    10.100.10.10/16 Local
    172.31.0.0/16 pcx-1
    0.0.0.0/0 igw-1
  4. Next, configure your directory consumer VPCs’ security group to enable outbound traffic by adding the Active Directory protocols and ports to the outbound rules table.

Step 3: Share the directory with the directory consumer account

Now that your networking is in place, you must make your directory visible to the directory consumer account. You can accomplish this by sharing your directory with the directory consumer account. Directory sharing works at the account level, which also makes the directory visible to all VPCs within the directory consumer account.

AWS Managed Microsoft AD provides two directory sharing methods: AWS Organizations and Handshake:

  • AWS Organizations makes it easier to share the directory within your organization because you can browse and validate the directory consumer accounts. To use this option, your organization must have all features enabled, and your directory must be in the organization master account. This method of sharing simplifies your setup because it doesn’t require the directory consumer accounts to accept your directory sharing request.
  • Handshake enables directory sharing when you aren’t using AWS Organizations. The handshake method requires the directory consumer account to accept the directory sharing request.

In my example, I’ll walk you through the steps to use AWS Organizations to share a directory:

  1. Open the AWS Management Console, then select Directory Service and select the directory you want to share (in my case, example.com). Select the Actions button, and then the Share directory option.
  2. Select Share this directory with AWS accounts inside your organization, then choose the Enable Access to AWS Organizations button. This allows your AWS account to list all accounts in your Organizations in the AWS Directory Service console.
  3. Select your directory consumer account (in my example, Consumer Example) from the Organization accounts browser, then select the Add button.
     
    Figure 3: Select the account and then select "Add"

    Figure 3: Select the account and then select “Add”

  4. You should now be able to see your directory consumer account in the Selected Accounts table. Select the Share button to share your directory with that account:
     
    Figure 4: Selected accounts and the "Share" button

    Figure 4: Selected accounts and the “Share” button

    To share your directory with multiple directory consumer accounts, you can repeat steps 3 and 4 for each account.

    When you’re finished sharing, AWS Managed Microsoft AD will create a shared directory in each directory consumer account. The shared directory contains the metadata to locate the directory in the directory owner account. Each shared directory has a unique identifier (Shared directory ID). After you’ve shared your directory, you can find your shared directory IDs in the Scale & Share tab in the AWS Directory Service console. In my example, AWS Managed Microsoft AD created the shared directory ID d-90673f8d56 in the Consumer Example account:
     

    Figure 5: Confirmation notification about successful sharing

    Figure 5: Confirmation notification about successful sharing

    You can see the shared directory details in your directory consumer account by opening the AWS Management Console, choosing Directory Service, selecting the Directories shared with me option in the left menu, and then choosing the appropriate Shared directory ID link:
     

    Figure 6: Shared account details example

    Figure 6: Shared account details example

Step 4: Launch Amazon EC2 instances and seamlessly domain join to the directory

Now that you’ve established the networking between your VPCs and shared the directory, you’re ready to launch EC2 instances in your directory consumer VPCs and seamlessly domain join to your directory. In my example, I use the Amazon EC2 console but you can also use AWS Systems Manager.

Follow the prompts of the Amazon EC2 launch instance wizard to select a Windows server instance type. When you reach Step 3: Configure Instance Details, select the shared directory that locates your domain in the directory owner account. (I’ve chosen d-926726739b, which will locate the domain example.com.) Then select the textEC2DomainJoin IAM role. Choose the Review and Launch button, and then the Launch button on the following screen.
 

Figure 7: The "Review and Launch" button

Figure 7: The “Review and Launch” button

Now that you’ve joined your Amazon EC2 instance to the domain, you can log into your instance using a Remote Desktop Protocol (RDP) client with the credentials from your AD user account.

You can then install and run AD-aware workloads such as Microsoft SharePoint on the instance, and the application will use your directory. To launch your second instance, just repeat Step 4: Launch Amazon EC2 instances and seamlessly domain join to the directory, selecting the VPC-2 instead of VPC-1. This makes it easier and quicker for you to deploy and manage EC2 instances using the credentials from a single AWS Managed Microsoft AD directory across multiple accounts and VPCs.

Summary

In this blog post, I demonstrate how to seamlessly domain join Amazon EC2 instances from multiple accounts and VPCs to a single AWS Managed Microsoft AD directory. By sharing the directory with multiple accounts, you can simplify the management and deployment of directory-aware workloads on Amazon EC2 instances. This eliminates the need to manually domain join the instances or create one directory per account and VPC. In addition, with AWS Managed Microsoft AD and AWS Systems Manager, you can automate your Amazon EC2 deployments and seamlessly domain join to your single directory from any account and VPC without the need to write PowerShell code using AWS Command Line Interface or application programming interfaces.

To learn more about AWS Directory Service, see the AWS Directory Service home page. If you have questions, post them on the Directory Service forum.

Want more AWS Security news? Follow us on Twitter.

Peter Pereira

Peter is a Senior Technical Product Manager working on AWS Directory Service. He enjoys the customer obsession culture at Amazon because it relates with his previous experience of managing IT in multiple industries, including engineering, manufacturing, and education. Outside work he is the “Dad Master Grill” and loves to spend time with his family. He holds an MBA from BYU and an undergraduate degree from the University of State of Santa Catarina.

How AWS Managed Microsoft AD Helps to Simplify the Deployment and Improve the Security of Active Directory–Integrated .NET Applications

Post Syndicated from Peter Pereira original https://aws.amazon.com/blogs/security/how-aws-managed-microsoft-ad-helps-to-simplify-the-deployment-and-improve-the-security-of-active-directory-integrated-net-applications/

Companies using .NET applications to access sensitive user information, such as employee salary, Social Security Number, and credit card information, need an easy and secure way to manage access for users and applications.

For example, let’s say that your company has a .NET payroll application. You want your Human Resources (HR) team to manage and update the payroll data for all the employees in your company. You also want your employees to be able to see their own payroll information in the application. To meet these requirements in a user-friendly and secure way, you want to manage access to the .NET application by using your existing Microsoft Active Directory identities. This enables you to provide users with single sign-on (SSO) access to the .NET application and to manage permissions using Active Directory groups. You also want the .NET application to authenticate itself to access the database, and to limit access to the data in the database based on the identity of the application user.

Microsoft Active Directory supports these requirements through group Managed Service Accounts (gMSAs) and Kerberos constrained delegation (KCD). AWS Directory Service for Microsoft Active Directory, also known as AWS Managed Microsoft AD, enables you to manage gMSAs and KCD through your administrative account, helping you to migrate and develop .NET applications that need these native Active Directory features.

In this blog post, I give an overview of how to use AWS Managed Microsoft AD to manage gMSAs and KCD and demonstrate how you can configure a gMSA and KCD in six steps for a .NET application:

  1. Create your AWS Managed Microsoft AD.
  2. Create your Amazon RDS for SQL Server database.
  3. Create a gMSA for your .NET application.
  4. Deploy your .NET application.
  5. Configure your .NET application to use the gMSA.
  6. Configure KCD for your .NET application.

Solution overview

The following diagram shows the components of a .NET application that uses Amazon RDS for SQL Server with a gMSA and KCD. The diagram also illustrates authentication and access and is numbered to show the six key steps required to use a gMSA and KCD. To deploy this solution, the AWS Managed Microsoft AD directory must be in the same Amazon Virtual Private Cloud (VPC) as RDS for SQL Server. For this example, my company name is Example Corp., and my directory uses the domain name, example.com.

Diagram showing the components of a .NET application that uses Amazon RDS for SQL Server with a gMSA and KCD

Deploy the solution

The following six steps (numbered to correlate with the preceding diagram) walk you through configuring and using a gMSA and KCD.

1. Create your AWS Managed Microsoft AD directory

Using the Directory Service console, create your AWS Managed Microsoft AD directory in your Amazon VPC. In my example, my domain name is example.com.

Image of creating an AWS Managed Microsoft AD directory in an Amazon VPC

2. Create your Amazon RDS for SQL Server database

Using the RDS console, create your Amazon RDS for SQL Server database instance in the same Amazon VPC where your directory is running, and enable Windows Authentication. To enable Windows Authentication, select your directory in the Microsoft SQL Server Windows Authentication section in the Configure Advanced Settings step of the database creation workflow (see the following screenshot).

In my example, I create my Amazon RDS for SQL Server db-example database, and enable Windows Authentication to allow my db-example database to authenticate against my example.com directory.

Screenshot of configuring advanced settings

3. Create a gMSA for your .NET application

Now that you have deployed your directory, database, and application, you can create a gMSA for your .NET application.

To perform the next steps, you must install the Active Directory administration tools on a Windows server that is joined to your AWS Managed Microsoft AD directory domain. If you do not have a Windows server joined to your directory domain, you can deploy a new Amazon EC2 for Microsoft Windows Server instance and join it to your directory domain.

To create a gMSA for your .NET application:

  1. Log on to the instance on which you installed the Active Directory administration tools by using a user that is a member of the Admins security group or the Managed Service Accounts Admins security group in your organizational unit (OU). For my example, I use the Admin user in the example OU.

Screenshot of logging on to the instance on which you installed the Active Directory administration tools

  1. Identify which .NET application servers (hosts) will run your .NET application. Create a new security group in your OU and add your .NET application servers as members of this new group. This allows a group of application servers to use a single gMSA, instead of creating one gMSA for each server. In my example, I create a group, App_server_grp, in my example OU. I also add Appserver1, which is my .NET application server computer name, as a member of this new group.

Screenshot of creating a new security group

  1. Create a gMSA in your directory by running Windows PowerShell from the Start menu. The basic syntax to create the gMSA at the Windows PowerShell command prompt follows.
    PS C:\Users\admin> New-ADServiceAccount -name [gMSAname] -DNSHostName [domainname] -PrincipalsAllowedToRetrieveManagedPassword [AppServersSecurityGroup] -TrustedForDelegation $truedn <Enter>

    In my example, the gMSAname is gMSAexample, the DNSHostName is example.com, and the PrincipalsAllowedToRetrieveManagedPassword is the recently created security group, App_server_grp.

    PS C:\Users\admin> New-ADServiceAccount -name gMSAexample -DNSHostName example.com -PrincipalsAllowedToRetrieveManagedPassword App_server_grp -TrustedForDelegation $truedn <Enter>

    To confirm you created the gMSA, you can run the Get-ADServiceAccount command from the PowerShell command prompt.

    PS C:\Users\admin> Get-ADServiceAccount gMSAexample <Enter>
    
    DistinguishedName : CN=gMSAexample,CN=Managed Service Accounts,DC=example,DC=com
    Enabled           : True
    Name              : gMSAexample
    ObjectClass       : msDS-GroupManagedServiceAccount
    ObjectGUID        : 24d8b68d-36d5-4dc3-b0a9-edbbb5dc8a5b
    SamAccountName    : gMSAexample$
    SID               : S-1-5-21-2100421304-991410377-951759617-1603
    UserPrincipalName :

    You also can confirm you created the gMSA by opening the Active Directory Users and Computers utility located in your Administrative Tools folder, expand the domain (example.com in my case), and expand the Managed Service Accounts folder.
    Screenshot of confirming the creation of the gMSA

4. Deploy your .NET application

Deploy your .NET application on IIS on Amazon EC2 for Windows Server instances. For this step, I assume you are the application’s expert and already know how to deploy it. Make sure that all of your instances are joined to your directory.

5. Configure your .NET application to use the gMSA

You can configure your .NET application to use the gMSA to enforce strong password security policy and ensure password rotation of your service account. This helps to improve the security and simplify the management of your .NET application. Configure your .NET application in two steps:

  1. Grant to gMSA the required permissions to run your .NET application in the respective application folders. This is a critical step because when you change the application pool identity account to use gMSA, downtime can occur if the gMSA does not have the application’s required permissions. Therefore, make sure you first test the configurations in your development and test environments.
  2. Configure your application pool identity on IIS to use the gMSA as the service account. When you configure a gMSA as the service account, you include the $ at the end of the gMSA name. You do not need to provide a password because AWS Managed Microsoft AD automatically creates and rotates the password. In my example, my service account is gMSAexample$, as shown in the following screenshot.

Screenshot of configuring application pool identity

You have completed all the steps to use gMSA to create and rotate your .NET application service account password! Now, you will configure KCD for your .NET application.

6. Configure KCD for your .NET application

You now are ready to allow your .NET application to have access to other services by using the user identity’s permissions instead of the application service account’s permissions. Note that KCD and gMSA are independent features, which means you do not have to create a gMSA to use KCD. For this example, I am using both features to show how you can use them together. To configure a regular service account such as a user or local built-in account, see the Kerberos constrained delegation with ASP.NET blog post on MSDN.

In my example, my goal is to delegate to the gMSAexample account the ability to enforce the user’s permissions to my db-example SQL Server database, instead of the gMSAexample account’s permissions. For this, I have to update the msDS-AllowedToDelegateTo gMSA attribute. The value for this attribute is the service principal name (SPN) of the service instance that you are targeting, which in this case is the db-example Amazon RDS for SQL Server database.

The SPN format for the msDS-AllowedToDelegateTo attribute is a combination of the service class, the Kerberos authentication endpoint, and the port number. The Amazon RDS for SQL Server Kerberos authentication endpoint format is [database_name].[domain_name]. The value for my msDS-AllowedToDelegateTo attribute is MSSQLSvc/db-example.example.com:1433, where MSSQLSvc and 1433 are the SQL Server Database service class and port number standards, respectively.

Follow these steps to perform the msDS-AllowedToDelegateTo gMSA attribute configuration:

  1. Log on to your Active Directory management instance with a user identity that is a member of the Kerberos Delegation Admins security group. In this case, I will use admin.
  2. Open the Active Directory Users and Groups utility located in your Administrative Tools folder, choose View, and then choose Advanced Features.
  3. Expand your domain name (example.com in this example), and then choose the Managed Service Accounts security group. Right-click the gMSA account for the application pool you want to enable for Kerberos delegation, choose Properties, and choose the Attribute Editor tab.
  4. Search for the msDS-AllowedToDelegateTo attribute on the Attribute Editor tab and choose Edit.
  5. Enter the MSSQLSvc/db-example.example.com:1433 value and choose Add.
    Screenshot of entering the value of the multi-valued string
  6. Choose OK and Apply, and your KCD configuration is complete.

Congratulations! At this point, your application is using a gMSA rather than an embedded static user identity and password, and the application is able to access SQL Server using the identity of the application user. The gMSA eliminates the need for you to rotate the application’s password manually, and it allows you to better scope permissions for the application. When you use KCD, you can enforce access to your database consistently based on user identities at the database level, which prevents improper access that might otherwise occur because of an application error.

Summary

In this blog post, I demonstrated how to simplify the deployment and improve the security of your .NET application by using a group Managed Service Account and Kerberos constrained delegation with your AWS Managed Microsoft AD directory. I also outlined the main steps to get your .NET environment up and running on a managed Active Directory and SQL Server infrastructure. This approach will make it easier for you to build new .NET applications in the AWS Cloud or migrate existing ones in a more secure way.

For additional information about using group Managed Service Accounts and Kerberos constrained delegation with your AWS Managed Microsoft AD directory, see the AWS Directory Service documentation.

To learn more about AWS Directory Service, see the AWS Directory Service home page. If you have questions about this post or its solution, start a new thread on the Directory Service forum.

– Peter

Introducing AWS Directory Service for Microsoft Active Directory (Standard Edition)

Post Syndicated from Peter Pereira original https://aws.amazon.com/blogs/security/introducing-aws-directory-service-for-microsoft-active-directory-standard-edition/

Today, AWS introduced AWS Directory Service for Microsoft Active Directory (Standard Edition), also known as AWS Microsoft AD (Standard Edition), which is managed Microsoft Active Directory (AD) that is performance optimized for small and midsize businesses. AWS Microsoft AD (Standard Edition) offers you a highly available and cost-effective primary directory in the AWS Cloud that you can use to manage users, groups, and computers. It enables you to join Amazon EC2 instances to your domain easily and supports many AWS and third-party applications and services. It also can support most of the common use cases of small and midsize businesses. When you use AWS Microsoft AD (Standard Edition) as your primary directory, you can manage access and provide single sign-on (SSO) to cloud applications such as Microsoft Office 365. If you have an existing Microsoft AD directory, you can also use AWS Microsoft AD (Standard Edition) as a resource forest that contains primarily computers and groups, allowing you to migrate your AD-aware applications to the AWS Cloud while using existing on-premises AD credentials.

In this blog post, I help you get started by answering three main questions about AWS Microsoft AD (Standard Edition):

  1. What do I get?
  2. How can I use it?
  3. What are the key features?

After answering these questions, I show how you can get started with creating and using your own AWS Microsoft AD (Standard Edition) directory.

1. What do I get?

When you create an AWS Microsoft AD (Standard Edition) directory, AWS deploys two Microsoft AD domain controllers powered by Microsoft Windows Server 2012 R2 in your Amazon Virtual Private Cloud (VPC). To help deliver high availability, the domain controllers run in different Availability Zones in the AWS Region of your choice.

As a managed service, AWS Microsoft AD (Standard Edition) configures directory replication, automates daily snapshots, and handles all patching and software updates. In addition, AWS Microsoft AD (Standard Edition) monitors and automatically recovers domain controllers in the event of a failure.

AWS Microsoft AD (Standard Edition) has been optimized as a primary directory for small and midsize businesses with the capacity to support approximately 5,000 employees. With 1 GB of directory object storage, AWS Microsoft AD (Standard Edition) has the capacity to store 30,000 or more total directory objects (users, groups, and computers). AWS Microsoft AD (Standard Edition) also gives you the option to add domain controllers to meet the specific performance demands of your applications. You also can use AWS Microsoft AD (Standard Edition) as a resource forest with a trust relationship to your on-premises directory.

2. How can I use it?

With AWS Microsoft AD (Standard Edition), you can share a single directory for multiple use cases. For example, you can share a directory to authenticate and authorize access for .NET applications, Amazon RDS for SQL Server with Windows Authentication enabled, and Amazon Chime for messaging and video conferencing.

The following diagram shows some of the use cases for your AWS Microsoft AD (Standard Edition) directory, including the ability to grant your users access to external cloud applications and allow your on-premises AD users to manage and have access to resources in the AWS Cloud. Click the diagram to see a larger version.

Diagram showing some ways you can use AWS Microsoft AD (Standard Edition)--click the diagram to see a larger version

Use case 1: Sign in to AWS applications and services with AD credentials

You can enable multiple AWS applications and services such as the AWS Management Console, Amazon WorkSpaces, and Amazon RDS for SQL Server to use your AWS Microsoft AD (Standard Edition) directory. When you enable an AWS application or service in your directory, your users can access the application or service with their AD credentials.

For example, you can enable your users to sign in to the AWS Management Console with their AD credentials. To do this, you enable the AWS Management Console as an application in your directory, and then assign your AD users and groups to IAM roles. When your users sign in to the AWS Management Console, they assume an IAM role to manage AWS resources. This makes it easy for you to grant your users access to the AWS Management Console without needing to configure and manage a separate SAML infrastructure.

Use case 2: Manage Amazon EC2 instances

Using familiar AD administration tools, you can apply AD Group Policy objects (GPOs) to centrally manage your Amazon EC2 for Windows or Linux instances by joining your instances to your AWS Microsoft AD (Standard Edition) domain.

In addition, your users can sign in to your instances with their AD credentials. This eliminates the need to use individual instance credentials or distribute private key (PEM) files. This makes it easier for you to instantly grant or revoke access to users by using AD user administration tools you already use.

Use case 3: Provide directory services to your AD-aware workloads

AWS Microsoft AD (Standard Edition) is an actual Microsoft AD that enables you to run traditional AD-aware workloads such as Remote Desktop Licensing Manager, Microsoft SharePoint, and Microsoft SQL Server Always On in the AWS Cloud. AWS Microsoft AD (Standard Edition) also helps you to simplify and improve the security of AD-integrated .NET applications by using group Managed Service Accounts (gMSAs) and Kerberos constrained delegation (KCD).

Use case 4: SSO to Office 365 and other cloud applications

You can use AWS Microsoft AD (Standard Edition) to provide SSO for cloud applications. You can use Azure AD Connect to synchronize your users into Azure AD, and then use Active Directory Federation Services (AD FS) so that your users can access Microsoft Office 365 and other SAML 2.0 cloud applications by using their AD credentials.

Use case 5: Extend your on-premises AD to the AWS Cloud

If you already have an AD infrastructure and want to use it when migrating AD-aware workloads to the AWS Cloud, AWS Microsoft AD (Standard Edition) can help. You can use AD trusts to connect AWS Microsoft AD (Standard Edition) to your existing AD. This means your users can access AD-aware and AWS applications with their on-premises AD credentials, without needing you to synchronize users, groups, or passwords.

For example, your users can sign in to the AWS Management Console and Amazon WorkSpaces by using their existing AD user names and passwords. Also, when you use AD-aware applications such as SharePoint with AWS Microsoft AD (Standard Edition), your logged-in Windows users can access these applications without needing to enter credentials again.

3. What are the key features?

AWS Microsoft AD (Standard Edition) includes the features detailed in this section.

Extend your AD schema

With AWS Microsoft AD, you can run customized AD-integrated applications that require changes to your directory schema, which defines the structures of your directory. The schema is composed of object classes such as user objects, which contain attributes such as user names. AWS Microsoft AD lets you extend the schema by adding new AD attributes or object classes that are not present in the core AD attributes and classes.

For example, if you have a human resources application that uses employee badge color to assign specific benefits, you can extend the schema to include a badge color attribute in the user object class of your directory. To learn more, see How to Move More Custom Applications to the AWS Cloud with AWS Directory Service.

Create user-specific password policies

With user-specific password policies, you can apply specific restrictions and account lockout policies to different types of users in your AWS Microsoft AD (Standard Edition) domain. For example, you can enforce strong passwords and frequent password change policies for administrators, and use less-restrictive policies with moderate account lockout policies for general users.

Add domain controllers

You can increase the performance and redundancy of your directory by adding domain controllers. This can help improve application performance by enabling directory clients to load-balance their requests across a larger number of domain controllers.

Encrypt directory traffic

You can use AWS Microsoft AD (Standard Edition) to encrypt Lightweight Directory Access Protocol (LDAP) communication between your applications and your directory. By enabling LDAP over Secure Sockets Layer (SSL)/Transport Layer Security (TLS), also called LDAPS, you encrypt your LDAP communications end to end. This helps you to protect sensitive information you keep in your directory when it is accessed over untrusted networks.

Improve the security of signing in to AWS services by using multi-factor authentication (MFA)

You can improve the security of signing in to AWS services, such as Amazon WorkSpaces and Amazon QuickSight, by enabling MFA in your AWS Microsoft AD (Standard Edition) directory. With MFA, your users must enter a one-time passcode (OTP) in addition to their AD user names and passwords to access AWS applications and services you enable in AWS Microsoft AD (Standard Edition).

Get started

To get started, use the Directory Service console to create your first directory with just a few clicks. If you have not used Directory Service before, you may be eligible for a 30-day limited free trial.

Summary

In this blog post, I explained what AWS Microsoft AD (Standard Edition) is and how you can use it. With a single directory, you can address many use cases for your business, making it easier to migrate and run your AD-aware workloads in the AWS Cloud, provide access to AWS applications and services, and connect to other cloud applications. To learn more about AWS Microsoft AD, see the Directory Service home page.

If you have comments about this post, submit them in the “Comments” section below. If you have questions about this blog post, start a new thread on the Directory Service forum.

– Peter

How to Increase the Redundancy and Performance of Your AWS Directory Service for Microsoft AD Directory by Adding Domain Controllers

Post Syndicated from Peter Pereira original https://aws.amazon.com/blogs/security/how-to-increase-the-redundancy-and-performance-of-your-aws-directory-service-for-microsoft-ad-directory-by-adding-domain-controllers/

You can now increase the redundancy and performance of your AWS Directory Service for Microsoft Active Directory (Enterprise Edition), also known as AWS Microsoft AD, directory by deploying additional domain controllers. Adding domain controllers increases redundancy, resulting in even greater resilience and higher availability. This new capability enables you to have at least two domain controllers operating, even if an Availability Zone were to be temporarily unavailable. The additional domain controllers also improve the performance of your applications by enabling directory clients to load-balance their requests across a larger number of domain controllers. For example, AWS Microsoft AD enables you to use larger fleets of Amazon EC2 instances to run .NET applications that perform frequent user attribute lookups.

AWS Microsoft AD is a highly available, managed Active Directory built on actual Microsoft Windows Server 2012 R2 in the AWS Cloud. When you create your AWS Microsoft AD directory, AWS deploys two domain controllers that are exclusively yours in separate Availability Zones for high availability. Now, you can deploy additional domain controllers easily via the Directory Service console or API, by specifying the total number of domain controllers that you want.

AWS Microsoft AD distributes the additional domain controllers across the Availability Zones and subnets within the Amazon VPC where your directory is running. AWS deploys the domain controllers, configures them to replicate directory changes, monitors for and repairs any issues, performs daily snapshots, and updates the domain controllers with patches. This reduces the effort and complexity of creating and managing your own domain controllers in the AWS Cloud.

In this blog post, I create an AWS Microsoft AD directory with two domain controllers in each Availability Zone. This ensures that I always have at least two domain controllers operating, even if an entire Availability Zone were to be temporarily unavailable. To accomplish this, first I create an AWS Microsoft AD directory with one domain controller per Availability Zone, and then I deploy one additional domain controller per Availability Zone.

Solution architecture

The following diagram shows how AWS Microsoft AD deploys all the domain controllers in this solution after you complete Steps 1 and 2. In Step 1, AWS Microsoft AD deploys the two required domain controllers across multiple Availability Zones and subnets in an Amazon VPC. In Step 2, AWS Microsoft AD deploys one additional domain controller per Availability Zone and subnet.

Solution diagram

Step 1: Create an AWS Microsoft AD directory

First, I create an AWS Microsoft AD directory in an Amazon VPC. I can add domain controllers only after AWS Microsoft AD configures my first two required domain controllers. In my example, my domain name is example.com.

When I create my directory, I must choose the VPC in which to deploy my directory (as shown in the following screenshot). Optionally, I can choose the subnets in which to deploy my domain controllers, and AWS Microsoft AD ensures I select subnets from different Availability Zones. In this case, I have no subnet preference, so I choose No Preference from the Subnets drop-down list. In this configuration, AWS Microsoft AD selects subnets from two different Availability Zones to deploy the directory.

Screenshot of choosing the VPC in which to create the directory

I then choose Next Step to review my configuration, and then choose Create Microsoft AD. It takes approximately 40 minutes for my domain controllers to be created. I can check the status from the AWS Directory Service console, and when the status is Active, I can add my two additional domain controllers to the directory.

Step 2: Deploy two more domain controllers in the directory

Now that I have created an AWS Microsoft AD directory and it is active, I can deploy two additional domain controllers in the directory. AWS Microsoft AD enables me to add domain controllers through the Directory Service console or API. In this post, I use the console.

To deploy two more domain controllers in the directory:

  1. I open the AWS Management Console, choose Directory Service, and then choose the Microsoft AD Directory ID. In my example, my recently created directory is example.com, as shown in the following screenshot.Screenshot of choosing the Directory ID
  2. I choose the Domain controllers tab next. Here I can see the two domain controllers that AWS Microsoft AD created for me in Step 1. It also shows the Availability Zones and subnets in which AWS Microsoft AD deployed the domain controllers.Screenshot showing the domain controllers, Availability Zones, and subnets
  3. I then choose Modify on the Domain controllers tab. I specify the total number of domain controllers I want by choosing the subtract and add buttons. In my example, I want four domain controllers in total for my directory.Screenshot showing how to specify the total number of domain controllers
  4. I choose Apply. AWS Microsoft AD deploys the two additional domain controllers and distributes them evenly across the Availability Zones and subnets in my Amazon VPC. Within a few seconds, I can see the Availability Zones and subnets in which AWS Microsoft AD deployed my two additional domain controllers with a status of Creating (see the following screenshot). While AWS Microsoft AD deploys the additional domain controllers, my directory continues to operate by using the active domain controllers—with no disruption of service.
    Screenshot of two additional domain controllers with a status of "Creating"
  5. When AWS Microsoft AD completes the deployment steps, all domain controllers are in Active status and available for use by my applications. As a result, I have improved the redundancy and performance of my directory.

Note: After deploying additional domain controllers, I can reduce the number of domain controllers by repeating the modification steps with a lower number of total domain controllers. Unless a directory is deleted, AWS Microsoft AD does not allow fewer than two domain controllers per directory in order to deliver fault tolerance and high availability.

Summary

In this blog post, I demonstrated how to deploy additional domain controllers in your AWS Microsoft AD directory. By adding domain controllers, you increase the redundancy and performance of your directory, which makes it easier for you to migrate and run mission-critical Active Directory–integrated workloads in the AWS Cloud without having to deploy and maintain your own AD infrastructure.

To learn more about AWS Directory Service, see the AWS Directory Service home page. If you have questions, post them on the Directory Service forum.

– Peter

How to Enable Multi-Factor Authentication for AWS Services by Using AWS Microsoft AD and On-Premises Credentials

Post Syndicated from Peter Pereira original https://aws.amazon.com/blogs/security/how-to-enable-multi-factor-authentication-for-amazon-workspaces-and-amazon-quicksight-by-using-microsoft-ad-and-on-premises-credentials/

You can now enable multi-factor authentication (MFA) for users of AWS services such as Amazon WorkSpaces and Amazon QuickSight and their on-premises credentials by using your AWS Directory Service for Microsoft Active Directory (Enterprise Edition) directory, also known as AWS Microsoft AD. MFA adds an extra layer of protection to a user name and password (the first “factor”) by requiring users to enter an authentication code (the second factor), which has been provided by your virtual or hardware MFA solution. These factors together provide additional security by preventing access to AWS services, unless users supply a valid MFA code.

To enable MFA for AWS services such as Amazon WorkSpaces and QuickSight, a key requirement is an MFA solution that is a Remote Authentication Dial-In User Service (RADIUS) server or a plugin to a RADIUS server already implemented in your on-premises infrastructure. RADIUS is an industry-standard client/server protocol that provides authentication, authorization, and accounting management to enable users to connect network services. The RADIUS server connects to your on-premises AD to authenticate and authorize users. For the purposes of this blog post, I will use “RADIUS/MFA” to refer to your on-premises RADIUS and MFA authentication solution.

In this blog post, I show how to enable MFA for your Amazon WorkSpaces users in two steps: 1) Configure your RADIUS/MFA server to accept Microsoft AD requests, and 2) configure your Microsoft AD directory to enable MFA.

Getting started

The solution in this blog post assumes that you already have the following components running:

  1. An active Microsoft AD directory
  2. An on-premises AD
  3. A trust relationship between your Microsoft AD and on-premises AD directories

To learn more about how to set up Microsoft AD and create trust relationships to enable Amazon WorkSpaces users to use AD on-premises credentials, see Now Available: Simplified Configuration of Trust Relationship in the AWS Directory Service Console.

Solution overview

The following network diagram shows the components you must have running to enable RADIUS/MFA for Amazon WorkSpaces. The left side in the diagram (covered in Step 1 below) represents your corporate data center with your on-premises AD connected to your RADIUS/MFA infrastructure that will provide the RADIUS user authentication. The right side (covered in Step 2 below) shows your Microsoft AD directory in the AWS Cloud connected to your on-premises AD via trust relationship, and the Amazon WorkSpaces joined to your Microsoft AD directory that will require the MFA code when you configure your environment by following Step 1 and Step 2.
Network diagram

Step 1 – Configure your RADIUS/MFA server to accept Microsoft AD requests

The following steps show you how to configure your RADIUS/MFA server to accept requests from your Microsoft AD directory.

  1. Obtain the Microsoft AD domain controller (DC) IP addresses to configure your RADIUS/MFA server:
    1. Open the AWS Management Console, choose Directory Service, and then choose your Microsoft AD Directory ID link.
      Screenshot of choosing Microsoft AD Directory ID link
    2. On the Directory details page, you will see the two DC IP addresses for your Microsoft AD directory (shown in the following screenshot as DNS Address). Your Microsoft AD DCs are the RADIUS clients to your RADIUS/MFA server.
      Screenshot of the two DC IP addresses for your Microsoft AD directory
  2. Configure your RADIUS/MFA server to add the RADIUS clients. If your RADIUS/MFA server supports DNS addresses, you will need to create only one RADIUS client configuration. Otherwise, you must create one RADIUS client configuration for each Microsoft AD DC, using the DC IP addresses you obtained in Step 1:
    1. Open your RADIUS client configuration screen in your RADIUS/MFA solution.
    2. Create one RADIUS client configuration for each Microsoft AD DC. The following are the common parameters (your RADIUS/MFA server may vary):
      • Address (DNS or IP): Type the DNS address of your Microsoft AD directory or the IP address of your Microsoft AD DC you obtained in Step 1.
      • Port number: You might need to configure the port number of your RADIUS/MFA server on which your RADIUS/MFA server accepts RADIUS client connections. The standard RADIUS port is 1812.
      • Shared secret: Type or generate a shared secret that will be used by the RADIUS/MFA server to connect with RADIUS clients.
      • Protocol: You might need to configure the authentication protocol between the Microsoft AD DCs and the RADIUS/MFA server. Supported protocols are PAP, CHAP MS-CHAPv1, and MS-CHAPv2. MS-CHAPv2 is recommended because it provides the strongest security of the three options.
      • Application name: This may be optional in some RADIUS/MFA servers and usually identifies the application in messages or reports.
    3. Configure your on-premises network to allow inbound traffic from the RADIUS clients (Microsoft AD DCs IP addresses) to your RADIUS/MFA server port, defined in Step 1.
    4. Add a rule to the Amazon security group of your Microsoft AD directory to allow inbound traffic from the RADIUS/MFA server IP address and port number defined previously.

Step 2 – Configure your Microsoft AD directory to enable MFA

The final step is to configure your Microsoft AD directory to enable MFA. When you enable MFA, Amazon WorkSpaces that are enabled in your Microsoft AD directory will require the user to enter an MFA code along with their user name and password.

To enable MFA in your Microsoft AD directory:

  1. Open the AWS Management Console, choose Directory Service, and then choose your Microsoft AD Directory ID link.
  2. Choose the Multi-Factor authentication tab and you will see what the following screenshot shows.
    Screenshot of Multi-Factor authentication tab
  3. Enter the following values to configure your RADIUS/MFA server to connect to your Microsoft AD directory:
    • Enable Multi-Factor Authentication: Select this check box to enable MFA configuration input settings fields.
    • RADIUS server IP address(es): Enter the IP addresses of your RADIUS/MFA server. You can enter multiple IP addresses, if you have more than one RADIUS/MFA server, by separating them with a comma (for example, 192.0.0.0, 192.0.0.12). Alternatively, you can use a DNS name for your RADIUS server when using AWS CLI.
    • Port: Enter the port number of your RADIUS/MFA server that you set in Step 1B.
    • Shared secret code: Enter the same shared secret you created in your RADIUS/MFA server in Step 1B.
    • Confirm shared secret code: Reenter your shared secret code.
    • Protocol: Select the authentication protocol between the Microsoft AD DCs and the RADIUS/MFA server. Supported protocols are PAP, CHAP MS-CHAPv1, and MS-CHAPv2. I recommend MS-CHAPv2 because it provides the strongest security of the three options.
    • Server timeout (in seconds): Enter the amount of time to wait for the RADIUS/MFA server to respond to authentication requests. If the RADIUS/MFA server does not respond in time, authentication will be retried (see Max retries). This value must be from 1 to 20.
    • Max retries: Specify the number of times that communication with the RADIUS/MFA server is attempted before failing. This must be a value from 0 to 10.
  4. Choose Update directory to update the RADIUS/MFA settings for your directory. The update process will take less than two minutes to complete. When the RADIUS/MFA Status changes to Completed, Amazon WorkSpaces will automatically prompt users to enter their user name and password from the on-premises AD, as well as an MFA code at next sign-in.
    1. If you receive a Failed status after choosing the Update directory button, check the following three most common errors (if you make a change to the configuration, choose Update to apply the changes):
      1. A mismatch between the shared key provided in the RADIUS/MFA server and Microsoft AD configurations.
      2. Network connectivity issues between your Microsoft AD and RADIUS/MFA server, because the on-premises network infrastructure or Amazon security groups are not properly set.
      3. The authentication protocol configured in Microsoft AD does not match or is not supported by the RADIUS/MFA server.

Summary

In this blog post, I provided a solution overview and walked through the two main steps to provide an extra layer of protection for Amazon WorkSpaces by enabling RADIUS/MFA by using Microsoft AD. Because users will be required to provide an MFA code (and have a virtual or hardware MFA device) immediately after you complete the configuration in Step 2, be sure you test this implementation in a test/development environment before deploying it in production.

You can also configure the MFA settings for Microsoft AD using the Directory Service APIs. To learn more about AWS Directory Service, see the AWS Directory Service home page. If you have questions, please post them on the Directory Service forum.

– Peter

How to Add More Application Support to Your Microsoft AD Directory by Extending the Schema

Post Syndicated from Peter Pereira original https://aws.amazon.com/blogs/security/how-to-add-more-application-support-to-your-microsoft-ad-directory-by-extending-the-schema/

Some Active Directory (AD) integrated applications require custom changes to the directory schema. Today, we have added the ability for an administrator to extend the schema of AWS Directory Service for Microsoft Active Directory (Enterprise Edition), also known as Microsoft AD. Specifically, you can modify the AD schema and enable many more applications. This feature also allows you to add new attributes and object classes to your AD that your application requires and that are not present in the core AD classes and attributes. Finally, it allows you to rename and disable attributes you create.

To update your schema, you upload a compatible Lightweight Directory Access Protocol Data Interchange Format (LDIF) file through the Directory Service console or AWS SDK. LDIF is a standard for formatted text designed to exchange data and update schemas for Lightweight Directory Access Protocol (LDAP) servers such as AD. Applications that require elevated permissions, such as Enterprise or Domain Admins, might not be supported.

In this blog post, I explain schema attributes and classes, and I give an overview of LDIF files and formatting. I then walk through a use case, which adds a new attribute to the computer class object that stores the Amazon EC2 instance identifier for my EC2 instances that are joined to my Microsoft AD domain, in three main steps:

  1. Create an LDIF file.
  2. Import an LDIF file.
  3. Validate schema updates.

I also show how to add a value to the new attribute.

Schema concepts

Schemas define the structures of directories and are composed of object classes that contain attributes, which can be uniquely referenced by an object identifier. Before you can modify a schema, it is useful to know how schemas are defined. This section covers important concepts you need to know about AD schemas. If you are already familiar with AD schemas and LDIF files, feel free to skip ahead. Note: All links in this section go to the Microsoft Developer Network (MSDN) website.

Schema classes: Each schema class, similar to a table in a database, has several properties, such as objectClassCategory, that define the class category. Go to Characteristics of Object Classes to see the complete list of classes’ characteristics, and learn more about how to create a new class at Defining a New Class.

Schema attributes: Each schema attribute, which is similar to a field in a database, has several properties that define its characteristics. For example, the property used by LDAP clients to read and write the attribute is the IDAPDDisplayName property, which must be unique across all attributes and classes. Characteristics of Attributes has a complete list of attribute characteristics; you can find additional guidance for creating a new attribute on Defining a New Attribute.

Schema linked attributes: Some attributes are linked between two classes with forward and back links. For example, when you add a user to a group, AD creates a forward link to the group, and AD adds a back link from the group to the user. A unique linkID must be generated when creating an attribute that will be linked.

Object identifier (OID): Each class and attribute must have an OID that is unique for all your objects. Software vendors must obtain their own unique OID to ensure uniqueness to avoid conflicts when more than one application uses the same attribute for different purposes. To ensure uniqueness, you can obtain a root OID from an ISO Name Registration Authority. Alternatively, you can obtain a base OID from Microsoft. To learn more about OIDs and how to obtain them, go to Object Identifiers.

LDIF files and formatting

LDIF files are formatted text files that you can use to modify objects and schemas in an LDAP directory such as AD. LDIF files contain instructions to define classes and attributes for objects that are stored in the directory. An instruction to define a class or an attribute is composed of multiple lines, each specifying a different property of the class or attribute. The format for LDIF files is an Internet Engineering Task Force (IETF) standard defined in Request for Comments (RFC) 2849.

To modify the schema in your Microsoft AD directory, you must first obtain or create an LDIF file. You must also have permissions to modify any objects held within the organizational unit (OU) that your Microsoft AD administrative account is delegated to control. You can also obtain an LDIF file by exporting one from a preexisting directory. Often, software manufacturers will provide a pre-created LDIF file with their products. When you have your LDIF file, you submit the LDIF file to extend the existing schema.

LDAP directories do not read the LDIF file. Rather, a program (for example, Ldifde.exe) interprets the LDIF file. The program converts the LDIF instructions into a sequence of LDAP commands that it sends to the directory, using the LDAP protocol. In the case of Microsoft AD, the LDIF file is submitted through the Directory Service console or AWS SDK; you do not have permissions to make modifications to the schema directly from an LDAP tool or application running in your Amazon VPC.

Important: Schema modifications are a critical operation, and you must perform them with extreme caution. LDIF file errors can break your applications! To recover from an error, you can only apply another modification to disable changes you made, or restore your entire directory to a previous state, which results in directory down time. Carefully plan, approve, and test all schema changes in a test environment first. Please review the AWS Shared Responsibility Model.

Whether you create an LDIF file from the ground up, export an LDIF file from another AD schema, or use an LDIF file supplied by your software vendor, you must understand a few key LDIF file formatting rules. In all cases, you must be familiar with the standards to modify the file when required. For example, each modification in an LDIF file is preceded by a distinguished name (DN) that uniquely identifies the object you are changing in the schema. The DNs in your LDIF file must exactly match the DNs of your directory. If you import an LDIF from a different directory, the DNs must be edited throughout the LDIF file. See the LDIF formatting rules in the Extending Your Microsoft AD Schema.

AD operates from a directory schema stored in a cache that is filled from the directory stored on disk. AD refreshes the cache every 5 minutes, and when schema changes are made, they are applied only to the directory stored on disk. If you need the schema changes stored on disk to take effect immediately, you must issue a command to update the schema cache after making each change.

How to extend your Microsoft AD directory schema

In the remainder of this blog post, I show how to extend your Microsoft AD directory schema by adding a new attribute to the computer object class to store the EC2 instance identifier. This walkthrough follows three main steps: 1) Create an LDIF file, 2) import an LDIF file, and 3) Validate schema updates. For this demonstration, my company name is Example, Inc., and my directory uses the domain name, example.com.

Step 1: Create an LDIF file

To create your own LDIF file:

  1. Define your new schema attribute.
  2. Define your new schema object class.
  3. Create the LDIF file.

A. Define your new schema attribute

In this example, the new attribute is named EC2InstanceID. To make my attribute name unique within the schema, I add example- as a prefix. The prefix and name act as a form of documentation about the creator and purpose of an object when an administrator is browsing the directory schema. In this case, the common name (CN) and IDAPDisplayName are the same: example-EC2InstanceID. To define your own prefix for your schema changes, you can use your DNS, an acronym, or another string that is unique to your company. For now, I am defining my attribute and property values that I will use later when I create the LDIF file in Step 3.

The following table shows the complete set of properties for creating my new attribute. To learn more details about attributes and properties, go to Defining a New Attribute and System Checks and Restrictions Imposed on Schema Additions and Modifications.

Property Property Value for My Attribute Description
CN example-EC2InstanceID Attribute common name
lDAPDisplayName example-EC2InstanceID Name used by LDAP clients
adminDisplayName example-EC2InstanceID Name used by admin tools
attributeSyntax 2.5.5.12 OID for string (Unicode)
oMSyntax 64 oMSyntax for string (Unicode)
objectClass top,attributeSchema Is instance of this objectClass
attributeID 1.2.840.113556.8000.9999.2.1 The OID for this attribute
isSingleValued TRUE Attribute has unique value
searchFlags 1 Attribute is indexed for search
isMemberOfPartialAttributeSet TRUE Replicated to the global catalog

Note: Because this attribute does not have an oMSyntax of 127, an oMObjectClass is not called for, in this example.

B. Define your new schema object class

AD comes with a core schema that defines objects used by the Windows operating system and many AD-integrated applications. You should not modify core schema definitions for AD, also called Category 1 objects. Instead, you should create a new auxiliary class and add the new attributes to this new auxiliary class. Then, add the attributes defined in the new auxiliary class to the core class to extend the schema so that the directory remains compatible with applications that depend on the core schema.

In my example, my goal is to add the example-EC2InstanceID attribute to the Computer class. To do so, I create a new auxiliary class named example-Computer and add the example-EC2InstanceID attribute to this new auxiliary class. Later, I will add the example-EC2InstanceID attribute defined in the example-Computer auxiliary class to the Computer core class. For now, I define only the example-Computer class that I will translate into LDIF instructions in Step 3.

The following table shows the complete set of properties for creating my new auxiliary class. To learn more details about classes and properties, go to Defining a New Class.

Property Property Value for My New Auxiliary Class Description
Cn example-Computer Class Common Name
lDAPDisplayName example-Computer Name used by LDA Clients
adminDisplayName example-Computer Name used by admin tools
governsID 1.2.840.113556.8000.9999.1.1 The OID for the auxiliary class
mayContain example-EC2InstanceID Class optionally contains this attribute
possSuperiors organizationalUnit, container This auxiliary class can be a child of organizationalUnit or container
objectClassCategory 3 Auxiliary class

C. Create the LDIF file

Now that I have defined my new example-EC2InstanceID attribute and example-Computer auxiliary class, it is time to put everything together in a single LDIF file. The sequence of LDIF instructions to extend the schema in my example is:

  1. Define the example-EC2InstanceID.
  2. Update the schema cache.
  3. Define the example-Computer auxiliary class.
  4. Update schema cache.
  5. Add the attributes defined in the example-Computer auxiliary class to the Computer.
  6. Update schema cache.

For each new instruction in the LDIF file, you must define the distinguished name (DN) as the first line of the instruction. The DN identifies an AD object within the AD object’s tree and must contain the domain components for your directory. In my example, the domain components for my directory are DC=example,DC=com.

The DN also must contain the common name (CN) of the AD object. The first CN entry is the attribute or class name. Next, you must use CN=Schema,CN=Configuration. This CN ensures that you can extend the AD schema. As mentioned before, you cannot add or modify AD objects’ content.

Remember: If you are creating a new file, using a file created by an application provider, or using a file exported from another domain, you must update the DNs throughout the LDIF file to match your directory’s naming conventions. The general format for a DN follows.

dn: CN=[attribute or class name],CN=Schema,CN=Configuration,DC=[domain_name]

In my example, the DN for my new attribute example-EC2InstanceID follows.

dn: CN=example-EC2InstanceID,CN=Schema,CN=Configuration,DC=example,DC=com

I create an LDIF file by using the instructions for the six previously named steps to define and add my new attribute to the AD schema. I name my LDIF file schema_EC2InstanceID.ldif, which is available for download. If you want to perform a test with the file, don’t forget to change the dn entries to specify your own domain name. The following is the code of the LDIF file.

# 1 – Define the example-EC2InstanceID attribute

dn: CN=example-EC2InstanceID,CN=Schema,CN=Configuration,DC=example,DC=com
changetype: add
objectClass: top
objectClass: attributeSchema
cn: example-EC2InstanceID
attributeID: 1.2.840.113556.1.8000.9999.2.1
attributeSyntax: 2.5.5.12
isSingleValued: TRUE
adminDisplayName: example-EC2InstanceID
adminDescription: EC2 Instance ID
oMSyntax: 64
searchFlags: 1
lDAPDisplayName: example-EC2InstanceID
systemOnly: FALSE

# 2 – Update the schema cache

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

# 3 – Define the example-Computer auxiliary class

dn: CN=example-Computer,CN=Schema,CN=Configuration,DC=example,DC=com
changetype: add
objectClass: top
objectClass: classSchema
cn: example-Computer
governsID: 1.2.840.113556.1.8000.9999.1.1
mayContain: example-EC2InstanceID
rDNAttID: cn
adminDisplayName: example-Computer
adminDescription:  Example Computer Class
objectClassCategory: 3
lDAPDisplayName: example-Computer
name: example-Computer
systemOnly: FALSE

# 4 – Update the schema cache

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

# 5 – Add the attributes defined in the example-Computer auxiliary class to the

# Computer class

dn: CN=Computer,CN=Schema,CN=Configuration,DC=example,DC=com
changetype: modify
add: auxiliaryClass
auxiliaryClass: example-Computer
-

# 6 – Update the schema cache

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1

Step 2: Import an LDIF file

After carefully reviewing and saving my LDIF file, I am now ready to upload it and apply it to my directory:

  1. Open the AWS Management Console, choose Directory Service, and then choose your Microsoft AD Directory ID link (as shown in the following screenshot).
    Screenshot of choosing the Directory ID
  2. Choose the Schema extensions tab. Here you can see a history of all the schema modification attempts made to the directory with the Start Time, End Time, and Description of the update provided by you, and the Status.
    Screenshot of "Schema extensions" tab
  1. Choose Upload and update schema to upload your LDIF file.
  2. On the Upload LDIF file and update schema page, choose Browse to choose your LDIF file. Type a description for this schema update to document why you updated your schema, and choose Update Schema.
    Screenshot of "Update LDIF file and update schema" window

When you choose Update Schema, Microsoft AD performs an initial syntax validation of your LDIF file.

Note: The most common syntax validation error is failing to update the DNs in your LDIF file to match your directory’s naming conventions.

After the initial LDIF file syntax validation, three actions are performed automatically:

  1. Microsoft AD creates a snapshot. The snapshot allows you to restore your directory just in case you face any issues in your application after updating the schema. The creation of the snapshot takes approximately 40 minutes. If you have reached your manual snapshot limit, Microsoft AD will prompt you to delete one of your manual snapshots before continuing.
  2. Your LDIF file is applied against your directory to a domain controller in isolation. Microsoft AD selects one of your DCs to be the schema master. It removes that DC from directory replication and applies your LDIF file using Ldifde.exe. This operation usually takes less than a minute.
  3. The schema updates are replicated to all domain controllers. After successfully applying your LDIF file against your domain controller in isolation, the modified DC is added back into replication, and the schema updates are replicated to all domain controllers.

While these steps are in progress, your directory is available to respond to application and user requests. However, you cannot perform directory maintenance operations such as creating trusts or adding IP routes. You can monitor the progress in the schema update history, as shown in the next screenshot.

Note: If any errors occur during the update, you receive a detailed error message and, when possible, a line number to show where the error occurred in your LDIF file. If an error occurs, your Microsoft AD schema will remain unmodified.

Screenshot showing snapshot being created

Step 3: Validate the schema updates

The last step is to validate if your schema updates have been applied to your directory. This is a key step before you migrate or update any application that relies on the schema updates. You can accomplish this by using a variety of different LDAP tools, or by writing a test tool that issues appropriate LDAP commands. I will show you two ways to accomplish this: by using the AD Schema Snap-in and Windows PowerShell.

To verify if the schema updates are present, you must run AD tools from a computer that is joined to your Microsoft AD domain. This can be a Windows server running in your on-premises network, with access to your Amazon Virtual Private Cloud (VPC) through a Virtual Private Network (VPN) connection. You also can perform this on an Amazon EC2 Windows instance (see Joining a Domain Using the Amazon EC2 Launch Wizard).

To use the AD Schema Snap-in:

  1. Install the AD Schema Snap-In by following this procedure.
  2. Open the Microsoft Management Console (MMC) and expand the Active Directory Schema tree for your directory. You should be able to see your classes and attributes. The following screenshot shows the example-EC2InstanceID attribute.
    Screenshot showing the example-EC2InstanceID attribute

If you prefer to use Windows PowerShell, you can use it to see if your schema update was applied to your directory by using the Get-ADObject cmdlet. The following code shows the syntax of my example.

# New attribute EC2InstanceID
PS C:\> get-adobject -Identity 'CN= EC2InstanceID,CN=Schema,CN=Configuration,DC=example,DC=com' -Properties * <Enter>

adminDescription: EC2 instance ID
adminDisplayName: example-EC2InstanceID
attributeID     : 1.2.840.113556.1.8000.9999.2.1
attributeSyntax : 2.5.5.12
CanonicalName   : example.com/Configuration/Schema/example-EC2InstanceID
CN              : example-EC2InstanceID
...

# New auxiliary class example-computer
PS C:\> get-adobject -Identity 'CN=example-Computer,CN=Schema,CN=Configuration,DC=example,DC=com' -Properties * <Enter>

adminDescription: example computer class
adminDisplayName: example-Computer
CanonicalName   : example.com/Configuration/Schema/example-Computer
CN              : example-Computer
...

# New auxiliary class example-computer added to the computer class
PS C:\> get-adobject -Identity 'CN=computer,CN=Schema,CN=Configuration,DC=example,DC=com' -Properties auxiliaryClass | select -ExpandProperty auxiliaryClass <Enter>

example-Computer
ipHost

Optional: Add a value to the new attribute

Now that you have created a new attribute, let’s add a new value to the attribute of a computer in your Microsoft AD directory. Open Windows PowerShell and set the new attribute with the following command.

PS C:\> set-adcomputer -Identity <computer name> -add @{example-EC2InstanceID = '<EC2 instance ID>'}

Now, validate if the added EC2InstanceID value to a computer object in the previous command is present in your Microsoft AD directory:

PS C:\> get-adcomputer -Identity <computer name> –Property example-EC2InstanceID

DistinguishedName     : CN=<computer name>,OU=Computers,DC=example,DC=com
DNSHostName           : <computer name>.example.com
Enabled               : True
example-EC2InstanceID : <EC2 instance ID>
Name                  : <computer name>
ObjectClass           : computer
ObjectGUID            : e7c2f596-4f8c-4084-a124-6fc6babaf3c8
SamAccountName        : <computer name>
SID                   : S-1-5-21-3794764471-3203795520-307520662-1104

Summary

In this blog post, I provided an overview of the key concepts, terms, and steps involved in extending a Microsoft AD schema, including how to format your LDIF file and how to apply your LDIF file against your Microsoft AD directory using the Directory Service console. Even if you are importing the LDIF file from another domain or application, these steps are important to understanding the potential impact on your directory. Extending the schema is a critical operation. Do not apply any schema update in your production environment without testing it with your application in a dev/test environment first.

For additional information about schema extensions, how to create LDIF files, and common errors, see the AWS Directory Service documentation.

To learn more about AWS Directory Service, see the AWS Directory Service home page. If you have questions, post them on the Directory Service forum.

– Peter