AWS Logo
Menu

Auditing and Monitoring AD Connector Login Events

This article will show you how to audit AD Connector login events to your Amazon WorkSpaces Personal environment. This can assist with security and with root cause analysis of issues.

workspacesamazon-workspacesactive-directorydirectory-serviceeuc
Dan Garibay
Amazon Employee
Published Sep 24, 2024

Overview

Walkthrough

Prerequisites

Optional Prerequisite: Create an IAM role for SSM Fleet Manager

Create the Windows Event Collector EC2 instance

Connect to the EC2 instance

Install the Group Policy Management MMC

Enable auditing of login events

Create the Event Log Subscription

Create the Event Log Forwarding Group Policy

Testing

Rollback

Rolling back the Event Log Forwarding Group Policy

Rolling back the auditing Group Policy

Conclusion

Overview

Customers use AD Connector from AWS Directory Service as part of a complete setup to enable Amazon WorkSpaces Personal. AD Connector proxies authentication traffic to your domain controllers, enabling you to use your on-premises domain without the need to set up another AD forest and make a two way trust.
AD Connector works by selecting a domain controller with the lowest latency it can find from the available Sites and Services every 15 minutes. If that domain controller goes offline, has replication issues, or is otherwise impaired, AD Connector will be nonfunctional until the next election cycle. This will block users from logging into Amazon WorkSpaces Personal. There is not any logging showing which domain controller AD Connector is using at a given point in time. This can make tracking down the root cause of such issues challenging. There is also no built-in logging for invalid password attempts for a user.
Customers have asked us for a way to audit failed WorkSpaces login attempts. Customers have also asked us for additional ways to diagnose issues with AD Connector, such as identifying which domain controller was processing login events at a point in time when an issue occurred. This can help with root cause analysis for outages.
This post shows how you can use a combination of Windows Event Forwarding, Windows Event Collection, and Group Policy, to audit and diagnose AD Connector.
If you create a dedicated EC2 Windows instance for this purpose running on a t3.medium instance type, the cost estimate is approximately $43.80 monthly, based on us-east-1 pricing. This solution does not require a dedicated instance, but this article will use one for demonstration purposes.

Walkthrough

In this blog, you will use built-in Windows tools to collect advanced security audit logs from your domain controllers on one central logging computer. You can then review all logs in one central location.
The overview of the process will look like this:
  • You will create a new EC2 Windows instance on a t3.medium instance. This instance will be joined to the same Active Directory domain as your WorkSpaces.
  • Next, you will create a Group Policy for your domain controllers which will enable additional audit logging for login events.
  • You will create a Windows Event Log Collection Subscription on that new instance, in order to receive those advanced login events.
  • You will then use Group Policy to configure your domain controllers to forward the advanced login events to the collector server.
  • Lastly, you will intentionally generate an invalid login attempt to one of your WorkSpaces, so that you can see an example event log entry.

Prerequisites

For this walkthrough, you should have the following prerequisites:
  • A pre-existing AD Connector setup with WorkSpaces Personal.
  • Your domain needs WinRM enabled and preconfigured. The Event Log Forwarding depends on this already being in place.
  • Permissions to create a new EC2 instance, joined to your Active Directory domain.
  • Familiarity with Group Policy and Active Directory
  • Permissions to create Group Policy in your domain which will apply to domain controllers.

Optional Prerequisite: Create an IAM role for SSM Fleet Manager

This section is optional. If you are going to connect to the EC2 instance with RDP, you can skip this. This step is only required if you are going to connect with AWS Systems Manager Fleet Manager. If you already have a role that grants these permissions, you can use that, and skip this step. These steps create a role and policy with minimal permissions.
  1. From the IAM console, choose Roles, then choose Create role.
  2. On the Select trusted entity page, select AWS service. Select EC2 in the Service or use case dropdown menu. Under choose a use case for the specified service, select EC2. Then choose Next.
  3. On the Add permissions page, select Next without choosing any policies. You will create the IAM policy in a later step.
  4. On the Name, review, and create page, enter a name and description for the role. The name can be something like “SSMConnectionRole”. Optionally, add tags to the role. Select Create role.
  5. In the list of IAM roles, find the role you just created and select it.
  6. Select the Add permissions dropdown menu and choose Create inline policy.
  7. In the resulting Specify Permissions page, select the JSON tab. Delete the pre-existing contents of the JSON policy editor and replace them with the JSON below, and then choose Next.
  8. Enter a policy name, such as SSMConnectionInline, and select Create policy.
You now have an IAM role that you can attach to your EC2 Windows Event Collector instance. The role will permit you to connect to the instance with SSM Fleet Manager.

Create the Windows Event Collector EC2 instance

  1. From the EC2 console, select Instances (running) then select Launch Instances.
  2. Provide a name for your instance, such as: WindowsEventLogCollector
  3. From the Quick Start section, select Windows then select Microsoft Windows Server 2022 Base from the Amazon Machine Image (AMI) dropdown.
  4. Under Instance Type select t3.medium. If you desire, you may use a larger instance type, but the pricing example in the overview is based on t3.medium in the us-east-1 region.
  5. Key pair (login): Select a key pair you have access to or select Create a new key pair to create a new one.
  6. In the Network Settings section, use the following options:
    1. VPC: Choose the VPC for your Amazon WorkSpaces.
    2. Subnet: Choose a private subnet your WorkSpaces VPC.
    3. Auto-assign public IP: disabled
    4. Firewall (security groups): Choose the Select existing security group radio button and select an existing Security Group with default outbound rules, which permits access to the internet. The VPC default security group will work.
  7. Configure storage: Expand this to 40 GB. Encryption is optional based on your organization’s policies.
  8. Expand the Advanced Details tab.
    1. In the Domain join directory dropdown, select the AD Connector. If you have multiple unique Fully Qualified Domain Names, select the directory your WorkSpaces use.
    2. Optional: If you plan to connect to the instance with SSM Fleet Manager, you must attach an IAM role with the relevant permissions. Select the IAM instance profile drop down menu. Choose an appropriate role. This could be a pre-existing one in your account. Otherwise, it will be the one you created in the section Optional Prerequisite: Create an IAM role for SSM Fleet Manager.
  9. Select Launch instance.
The instance will take approximately 10-15 minutes to create and become accessible.

Connect to the EC2 instance

Begin by logging into your new EC2 instance with your preferred method. You can use RDP if you have access to the subnet through a VPN or Direct Connect setup. You can also use SSM Fleet Manager. To use SSM Fleet Manager:
  1. Select the instance in the EC2 console
  2. Select the “Actions” drop down menu in the top right
  3. Select Connect
  4. Select the “RDP Client” tab, and then the “Connect using Fleet Manager” radio button
  5. Select the “Fleet Manager Remote Desktop” button on the bottom.
  6. When prompted for credentials, enter them in a domain format. You can use either domain\username or username@domain.tld as the format.
Whether you use an RDP client or SSM Fleet Manager, be sure to log into the instance using your domain credentials. You will need permissions to create Group Policy in your domain. If your organization’s policies require you to log in with a non-privileged domain user, and elevate to launch specific MMCs, follow those procedures as required.

Install the Group Policy Management MMC

Now that you have connected to the instance, open an Administrator PowerShell prompt. Enter the following command:
Install-WindowsFeature -Name GPMC
This will install the Group Policy Management features.
After this command completes, enter gpmc.msc in the PowerShell window and press Enter to launch the Group Policy Management window. You will use this MMC in subsequent sections.
Do not close the PowerShell window, as you will need it in a subsequent section.

Enable auditing of login events

In this section, you will enable audit logging for accounts which is not enabled by default in Active Directory.
When you have Kerberos Authentication auditing enabled, the Security Event Logs of your Domain controllers will log 3 additional event IDs:
Using the Group Policy Management MMC – gpmc.msc – complete the following steps.
  1. In the left column, expand the Forest folder, then Domains, and then the domain name. You should see a list of your OUs.
  2. Right select the “Domain Controllers” OU. Select “Create a GPO in this domain, and Link it here…” Enter a name for your Group Policy, such as “AD Audit Logging” and press Enter.
  3. Right select your new Group Policy Object and select “Edit…”
  4. In the resulting Group Policy Management Editor window, expand Computer Configuration, Policies, Windows Settings, Security Settings, Advanced Audit Policy Configuration, Audit Policies, and then select the Account Logon section.
  5. Select “Audit Kerberos Authentication Service” in the right section, and select the Success and Failure boxes. Select OK to close the properties window.
You can now close the Group Policy Management Editor. Do not close the overall Group Policy Management MMC.

Create the Event Log Subscription

In this section, you will create the Subscription for your Event Log forwarding. This is the listener side of the equation.
  1. Open eventvwr.msc
  2. Right-select “Subscriptions” in the left column and choose “Create Subscription…”
    1. Enter a name and description, such as “AD Connector Events” and “Collects event logs related to AD Connector user login activity.”
    2. For “Destination log:” choose “Forwarded Events”.
    3. For the Subscription type and source computers section:
      1. Choose the “Source computer initiated” radio button.
      2. Choose “Select Computer Groups”
        1. In the resulting window, select “Add Domain Computers”.
        2. Type “Domain Controllers” into the box and press “Check Names”. It should underline. Press OK, and then OK a second time to close the window.
    4. Press "Select Events…”
      1. In the query filter, choose:
        1. By log: Security
        2. Under the "includes/excludes Event IDs" box, enter 4768,4771,4772
        3. Check all 5 boxes at the top as well - Critical, Warning, Verbose, Error, and Information.
      2. Select “OK” to close the query filter box.
  3. Select “OK” to finalize the Subscription Properties box.

Create the Event Log Forwarding Group Policy

In this section, you will create a Group Policy which enables Event Log Forwarding for your Kerberos and account audit events. This policy will ensure those events are forwarded to your Windows Event Log collection server. Since the events you are forwarding are written into the Security event log, it’s also necessary to expand the permissions of the NETWORK SERVICE. This is because by default, NETWORK SERVICE does not have permissions to read the Security event log. This is slightly complex to do on domain controllers, as there’s no way to modify local users and groups on a domain controller. The Group Policy you create will manage this.
Copy the below text into a text editor such as Notepad.
Server=http://REPLACEME:5985/wsman/SubscriptionManager/WEC,Refresh=60
In your pre-existing PowerShell window, run the following command. This will retrieve your computer’s full hostname and fully qualified domain name, and copy it directly into your clipboard.
[System.Net.Dns]::GetHostByName($env:computerName).HostName | clip
 Now that the computer’s hostname is on your clipboard, select REPLACEME in the text editor section, and paste in the computer’s hostname. The fully formed string should resemble this:
Server=http://EC2AMAZ-IJ1P3E1.example.com:5985/wsman/SubscriptionManager/WEC,Refresh=60
You will need this string in the below steps.
Using the Group Policy Management MMC – gpmc.msc – complete the following steps.
  1. In the left column, expand the Forest folder, then Domains, and then the domain name. You should see a list of your OUs.
  2. Right select the “Domain Controllers” OU. Select “Create a GPO in this domain, and Link it here…” Enter a name for your Group Policy, such as “AD Connector Event Log Forwarding” and press Enter.
  3. Right select your new Group Policy Object and select “Edit…”
  4. In the resulting Group Policy Management Editor window, expand Computer Configuration, Policies > Administrative Templates > Windows Components > Event Forwarding, and then select the Configure target Subscription Manager section.
  5. In the resulting window, choose the Enabled radio button. In the bottom left section, you will see SubscriptionManagers and a Show… button to the right. Select the Show… button.
  6. In the resulting Show Contents window, you will see a blank Value column. Paste the string you crafted above, into this field. Then select OK on the Show Contents and Configure target Subscription Manager windows.
  7. In the Group Policy Management Editor window, expand the Event Log Service section in the left column, and select the Security folder.
  8. In the right column, select Configure log access.
  9. In the resulting Configure log access window, select the Enabled radio button. In the “Log Access” field in the bottom left, paste the following string:
O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;NS)
You can now close the Group Policy Management Editor as well as the Group Policy Management MMC.
This string is enabling the NT AUTHORITY\NETWORK SERVICE account to read the Security event log, which it doesn’t have permissions to do by default. If you would like to see this in a more human readable format, you can use the ConvertFrom-SddlString PowerShell cmdlet (available in PowerShell 7 and beyond) to read this. Here is the output of that command:
This Group Policy will take effect within the normal intervals for Group Policy check-ins. You can use gpupdate /force in an administrative PowerShell or Command Prompt window on each domain controller to ensure this happens immediately. The default refresh interval is every 90 minutes, with a randomized offset of up to 30 minutes.

Testing

After the Group Policy has replicated to your domain controllers (or has been manually updated), your AD Connector’s Kerberos audit log events will be forwarded to the EC2 instance you created in this blog.
The log events will be visible in eventvwr.msc under the Forwarded Events section.
You can test for one of these events by logging into your WorkSpaces. The event will note whether the attempt was successful or unsuccessful. This will indicate a bad password attempt or a successful password attempt. Below is an example of a login event where an incorrect password was supplied.
A very key detail in this example is that the Network Information field is showing you an IPv4 address of 10.0.0.24. This is not the IP address of the end user’s device, where the connection attempt came from. It is the IP address of one of your two AD Connector instances.
The below event log entry lets you see two key things as a result:
  • An incorrect password attempt was made on behalf of this particular user.
  • The login attempt was processed by the domain controller EC2AMAZ-J1QL8QP.corp.example.com .
Here is an example of a successful user login.

Rollback

To remove this setup, you will simply delete the two Group Policy Objects you created. The settings in these GPOs will roll back upon deletion.

Rolling back the Event Log Forwarding Group Policy

The Event Log Forwarding Group Policy does not persist, so deleting it will be sufficient to roll it back.
Using the Group Policy Management MMC – gpmc.msc – complete the following steps.
  1. In the left console, expand Forest, Domains, and your domain Fully Qualified Domain Name. Locate the Organization Unit you identified in the previous section.
  2. In your Domain Controllers OU, you will see the AD Audit Logging GPO you created previously. Right select this and choose Delete.
You can now close the Group Policy Management Editor. Do not close the overall Group Policy Management MMC.
You can confirm that the policy rolled back with two checks.
Perform these checks after connecting to a domain controller:
  1. Open an admin PowerShell prompt
  2. Run gpupdate /force
  3. Run wevtutil gl security in order to validate that the channelAccess value has returned to its default.
    1. For reference, the default value is: O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)
  4. Now open the Event Viewer – eventvwr.msc
  5. In the left column, expand Applications and Services Logs > Microsoft > Windows > Eventlog-ForwardingPlugin and select Operational.
  6. In the right section, you should see a fresh entry for Event ID 103, showing that the subscription is unsubscribed.
This screenshot shows the default access control list values for the Security event log.
Default Security event log Access Control List values
Event log entry showing the unsubscription event.
Event log entry confirming the unsubscription event.

Rolling back the auditing Group Policy

The auditing Group Policy does not persist, so deleting it will be sufficient to roll it back.
Using the Group Policy Management MMC – gpmc.msc – complete the following steps.
  1. In the left console, expand Forest, Domains, and your domain Fully Qualified Domain Name. Locate the Organization Unit you identified in the previous section.
  2. In your Domain Controllers OU, you will see the AD Audit Logging GPO you created previously. Right select this and choose Delete.
You can now close the Group Policy Management Editor and the Group Policy Management MMC.
You can validate that the Audit Policy has changed by running a gpupdate /force on a domain controller and looking at the Security event log in the Event Viewer. You should see Event 4179, indicating an Audit Policy Change, showing the events were removed.
Event log entry showing the system audit policy was changed.
Event log entry showing the system audit policy was changed.

Conclusion

In this article, you learned how to collect Kerberos audit events relating to AWS AD Connector at scale across your Active Directory fleet. You also learned how to aggregate them on a central server, using built-in Windows features.
If you need to retrospectively understand which domain controller was processing AD Connector logins at a specific point in time, collecting these events makes this possible. This also helps you check on how many invalid login attempts are made for individual end users.
 

Any opinions in this post are those of the individual author and may not reflect the opinions of AWS.

Comments