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:
- Create your AWS Managed Microsoft AD.
- Create your Amazon RDS for SQL Server database.
- Create a gMSA for your .NET application.
- Deploy your .NET application.
- Configure your .NET application to use the gMSA.
- Configure KCD for your .NET application.
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,
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
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
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:
- Log on to the instance on which you installed the Active Directory administration tools by using a user that is a member of the
Adminssecurity group or the
Managed Service Accounts Adminssecurity group in your organizational unit (OU). For my example, I use the
Adminuser in the
- 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
exampleOU. I also add
Appserver1, which is my .NET application server computer name, as a member of this new group.
- 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.
In my example, the
example.com, and the
PrincipalsAllowedToRetrieveManagedPasswordis the recently created security group,
To confirm you created the gMSA, you can run the
Get-ADServiceAccountcommand from the PowerShell command prompt.
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.comin my case), and expand the Managed Service Accounts folder.
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:
- 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.
- 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.
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
1433 are the SQL Server Database service class and port number standards, respectively.
Follow these steps to perform the
msDS-AllowedToDelegateTo gMSA attribute configuration:
- Log on to your Active Directory management instance with a user identity that is a member of the
Kerberos Delegation Adminssecurity group. In this case, I will use
- Open the Active Directory Users and Groups utility located in your Administrative Tools folder, choose View, and then choose Advanced Features.
- Expand your domain name (
example.comin 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.
- Search for the
msDS-AllowedToDelegateToattribute on the Attribute Editor tab and choose Edit.
- Enter the
MSSQLSvc/db-example.example.com:1433value and choose Add.
- 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.
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.