Hello! In this seventh installment of the series, we cover Security and Best Practices - considerations for production environments.

Series overview

• Chapter 1: Understanding the basics - Fundamentals of Active Directory and Kerberos/NTLM authentication
• Chapter 2: Building a domain environment - Setting up a lab environment
• Chapter 3: Joining clients and servers to the domain - Domain join in detail
• Chapter 4: Proxy servers and Integrated Windows Authentication
• Chapter 5: Browser configuration and authentication - Settings for each browser
• Chapter 6: Troubleshooting - Common problems and solutions
• [★This installment★] Chapter 7: Security and best practices - Considerations for production environments
• Chapter 8: Practical configuration examples - Integration with AI security tools

Chapter 7: Security and Best Practices

Part 7 is about bringing the authentication infrastructure built in the previous installments to a state where it can run in production.

In the first half, 7.1, we harden the entry points: how to handle Basic authentication, which is practically plaintext; how to bring the password policy in line with current recommendations; and how far to narrow administrative privileges. In the second half, 7.2, we build the mechanisms for noticing that someone has gotten in: which logs to collect, how to spot anomalies, and how to check things regularly.

Each section opens with a four-panel manga. The six characters are an auditor, an IT manager, a CISO, a developer, a help desk member, and a trainer, and all the scenes are fictional. All numbers and recommendations in the text are based on official Microsoft documentation, RFCs, and NIST publications, and the sources are listed at the end of each section.

7.1 Managing Credentials

7.1.1 Security Risks of Basic Authentication

Basic authentication has the simplest mechanism of all, and without TLS it sends the username and password in a form anyone can reverse.

The reason is that it does not encrypt the credentials. RFC 7617 specifies that the client sends the username and password joined by a colon and encoded in Base64, and it also states that the scheme is not considered secure unless used together with an external secure system such as TLS. Base64 is an encoding that anyone can reverse, not encryption.

Where the credentials get stolen

In the setup used throughout this series, traffic goes from an office PC through the proxy to external generative AI services. The place where credentials get stolen is not between the proxy and the external site, but between the PC and the proxy.

If the external site uses HTTPS, the content is encrypted. But authentication to the proxy happens in the CONNECT request, before the HTTPS tunnel is built. RFC 9110 says proxy authentication is used to check permission to establish a tunnel, and its CONNECT example includes Proxy-Authorization. The client may send the credentials after receiving the proxy's 407 response, or attach them from the very first request. Either way, if the segment between the PC and the proxy is not protected by TLS, anyone who can observe that segment sees the credentials as is.

Why Basic authentication remains, and how to keep it safely

As we saw in Part 4, when the proxy offers Negotiate, NTLM, and Basic, which one is used depends on the client's implementation and settings. Within Negotiate, Kerberos is preferred, and NTLM is chosen when Kerberos is not available. Falling back to Basic is a separate mechanism: it depends on whether the proxy offers Basic and whether the client is configured to accept it. Basic is often kept as a fallback for devices not joined to the domain and for software that does not support integrated authentication.

7.1.2 Password Management Best Practices

Over the past few years, password policy has shifted from "make it complex and change it often" to "make it long, do not force changes, and ban the ones that have leaked."

NIST and Microsoft point in the same direction. The latest version of NIST SP 800-63B requires passwords used as a single factor to be at least 15 characters, does not impose composition rules such as mixing character types, does not require periodic changes, and requires checking against lists of known compromised passwords. For Microsoft 365 accounts, Microsoft recommends a minimum of 14 characters and recommends not setting an expiration for cloud-only accounts. These are recommendations for Microsoft 365, not rules that apply directly to on-premises Active Directory, but the direction is the same.

Why the change? The more constraints people face, the more they create passwords that follow the same pattern. Microsoft explains that requirements for length, symbols, and changes tend to push passwords into predictable patterns. Attackers know the "one uppercase letter, one symbol, digits at the end" pattern well.

What you can set in the Active Directory password policy

The domain password policy lives at the following location in Group Policy. The defaults are values that have been used for a long time, not today's recommended values.

Computer Configuration
└ Windows Settings
  └ Security Settings
    └ Account Policies
      └ Password Policy

This table covers the default domain policy. Since Windows Server 2008, fine-grained password policies (PSOs) let you apply a different policy to specific groups or users, so you can, for example, require longer passwords only for administrators and service accounts. The audit in 7.2.3 checks PSOs as well.

Service accounts should not be managed by people

Accounts used by applications and services have problems that differ from those of human accounts. There are three: the service stops when the password expires, the same password stays in use for years because people fear changing it, and the password is written in plaintext in configuration files.

Windows Server has an account type for this. A group Managed Service Account (gMSA) has its password managed automatically by Windows and can be used on multiple servers. Administrators never need to know the password. It works with Windows services, scheduled tasks, and other components that support gMSA, so for some applications you need to check whether they support it.

1. 1Prepare a KDS root key (only once, the first time in the forest). In a production environment with multiple domain controllers, wait up to 10 hours after creating it for the key to replicate to all DCs before creating a gMSA
2. 2Create a security group for the computers allowed to retrieve the password (WebServers in the example) and add the computer accounts of the target servers. After adding them, restart each server or have it obtain new Kerberos tickets so the group membership takes effect
3. 3Create the gMSA. Pass New-ADServiceAccount a name, a DNS host name, and the group from step 2
4. 4Install the gMSA on the server that uses it, and set the service's "Log On" account to DOMAIN\name$ (leave the password fields empty)

# 1. KDS root key (once per forest). Create it only if none exists. With multiple DCs in production, wait 10 hours after creating it
if (-not (Get-KdsRootKey)) {
  Add-KdsRootKey -EffectiveImmediately
}

# 1'. Only to skip the 10-hour wait in a lab (a single DC). Do not run this in production
Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10))

# 2. Create the gMSA. Only computers in the WebServers group can retrieve the password
New-ADServiceAccount -Name "svc_webapp" `
  -DNSHostName "svc_webapp.example.local" `
  -PrincipalsAllowedToRetrieveManagedPassword "WebServers"

# 3. On the server that uses it
Install-ADServiceAccount -Identity "svc_webapp"
Test-ADServiceAccount -Identity "svc_webapp"   # True means it can be used

What lies beyond passwords

However well you tune the policy, a password is a secret you hand over to wherever you type it, so typing it into a fake sign-in page gets it stolen. NIST also states plainly that passwords are not phishing-resistant.

In an Active Directory environment, there are three paths toward authentication that does not rely on passwords. None of them "sends a secret." Instead, they "sign with a key held inside an authenticator" (the device's security module, a smart card, or a security key). Phishing resistance comes from two things: the private key never leaves the authenticator, and the key is bound to the legitimate relying party, so it does not respond to a fake one.

It is also worth noting how this relates to integrated Windows authentication at the proxy, the main subject of this series. Even when users sign in with Windows Hello for Business or a smart card, Kerberos ticket issuance afterward is unchanged, so Negotiate authentication at the proxy keeps working. The only thing that changes is what is presented at the first sign-in. On the other hand, if you leave the Basic authentication fallback in place, it still needs a password, which undercuts the point of going passwordless. That is why 7.1.1 recommended limiting the fallback.

7.1.3 Minimizing Administrative Privileges

Grant administrative privileges only to the extent the task requires, and only for as long as it is needed.

This is the principle Microsoft has consistently recommended for running Active Directory. Top-level groups such as Domain Admins are containers for emergencies, not for everyday work.

Why 50 people in Domain Admins is dangerous

There are two reasons.

The entry points multiply to 50. If the privileged credentials of just one of the 50 are stolen, the attacker gains a foothold to take over the entire domain. On top of that, signing in to an ordinary PC with a Domain Admins account leaves traces of the credentials on that PC, and they can be extracted if the PC is compromised. This is why Microsoft says not to sign in to less privileged systems with privileged accounts.

Mistakes spread to everything. Even a staff member who only installs printer drivers can touch Group Policy and the schema if they are in Domain Admins. When privileges exceed the scope of the job, nothing stops a mistake.

Grant rights per task (delegation)

In the manga's example, managing printers does not need Domain Admins. There are ways to grant only the scope required for each task.

Separate by tier (the Tier model)

Once delegation has narrowed rights per task, the next step is to decide which tier's credentials may be used on which tier. The Tier model that Microsoft has presented for Active Directory splits what you protect into three tiers and does not allow upper-tier credentials to be used on lower tiers.

Implementation starts with creating dedicated admin accounts and groups for each tier (for example, Tier0-Admins, Tier1-ServerAdmins, and Tier2-WorkstationAdmins). Then use user rights assignment in Group Policy so that each tier's admin accounts cannot sign in to devices and servers in lower tiers. There are five kinds of logon rights: interactive, Remote Desktop, network, logon as a service, and logon as a batch job. Decide which ones to deny based on the account's purpose and the systems it manages. If you deny all five across the board, admin accounts can no longer get into their legitimate management servers, so plan the paths to PAWs and management servers separately. Design the scope of OU delegation to match the tiers as well.

Do top-level work from a dedicated device (PAW)

Tier 0 administrators also use separate devices for their work. This is the privileged access workstation (PAW).

A PAW is the strictest device configuration, intended for roles whose compromise would have a serious impact on the organization. It has three aims: protect administrator credentials, reduce the device's attack surface, and separate the management path from everyday work. At its core is cutting email and web browsing, the main phishing routes, off from the management device. Email and the web are used with a different account on a different device.

What you can do this week

1. 1List the members of Domain Admins and Enterprise Admins (the audit script in 7.2.3 gets them for you)
2. 2Remove the accounts used for everyday work. Give administrators two accounts: one for regular use and one for administration
3. 3Replace the work of the people you removed with delegated rights on OUs, local rights on the target servers, or roles in management products
4. 4Create admin groups for each tier, and block cross-tier sign-ins with Group Policy
5. 5Provide PAWs for Tier 0 administrators

7.2 Monitoring and Logging

7.2.1 Collecting and Analyzing Authentication Logs

The sections so far were about hardening the entry points. From here on, the topic is noticing when someone has gotten in.

To notice, you need to record authentication-related events without gaps, gather them in one place, and keep them in a form people can read. In an Active Directory environment, the following four kinds of logs form the foundation.

How to collect: Windows Event Forwarding

Logs are useless if they stay on the machine where they were generated, because the logs on a compromised machine get erased. Windows has a built-in way to send logs to one place without additional products, called Windows Event Forwarding (WEF).

There are two key settings. Configure the collection service on the collector, and enable Windows Remote Management on the sending side. Each is a one-line command.

# On the collector (the receiving side), run as administrator
wecutil qc /q
winrm qc -q

# On each source (the sending side). This can also be configured in bulk with Group Policy
winrm qc -q

This is only initialization, and no events flow yet. To start forwarding, create a "source-initiated" subscription on the collector, distribute the collector's location (SubscriptionManager) to the sending side through Group Policy, confirm that the sending side has permission to read the Security log and the right audit policy, and verify that events arrive in the collector's "Forwarded Events" log.

Which events a subscription collects is specified with XPath. For example, to collect only successful logons, failed logons, and lockouts, use the following.

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
      *[System[(EventID=4624 or EventID=4625 or EventID=4740)]]
    </Select>
  </Query>
</QueryList>

# On the collector, check the list and status of the subscriptions you created
wecutil es
wecutil gr "SubscriptionName"   # Shows each source's connection status and last arrival time

How to read them: catching late-night logons

The first step in spotting anomalies in the collected logs can be a simple condition. For example, "successful interactive logons in the last 24 hours before 6 a.m. or after 10 p.m."

# List interactive logons (LogonType 2 and 10) late at night or early in the morning over the last 24 hours
New-Item -ItemType Directory -Path 'C:\\audit' -Force | Out-Null
$since = (Get-Date).AddDays(-1)
$hits = Get-WinEvent -FilterHashtable @{ LogName = 'Security'; ID = 4624; StartTime = $since } |
  Where-Object {
    $lt = $_.Properties[8].Value
    ($lt -eq 2 -or $lt -eq 10) -and ($_.TimeCreated.Hour -lt 6 -or $_.TimeCreated.Hour -ge 22)
  } |
  Select-Object TimeCreated,
    @{ N = 'User';        E = { $_.Properties[5].Value } },
    @{ N = 'Domain';      E = { $_.Properties[6].Value } },
    @{ N = 'LogonType';   E = { $_.Properties[8].Value } },
    @{ N = 'Workstation'; E = { $_.Properties[11].Value } }

$hits | Format-Table -AutoSize
$hits | Export-Csv -Path "C:\\audit\\night-logons-$(Get-Date -Format yyyyMMdd).csv" -NoTypeInformation -Encoding UTF8

7.2.2 Detecting Abnormal Access Patterns

Once the logs are collected, the next step is finding what is "different from usual."

To do that, you first need to know what "usual" is: who uses which systems, at what times, from which devices. This is called a baseline. Baselines differ by person and department, so some things slip past a single company-wide threshold.

Impossible travel

The easiest anomaly to understand is "impossible travel." Microsoft Defender for Cloud Apps defines it as activity from two geographically distant locations recorded within a time shorter than it would take to travel between them, and detects it as a sign that someone else is using the same credentials.

The idea is simple. Compute a speed from the distance between the two logon locations and the time between them, and raise an alert if it exceeds a realistic limit. Locations are derived from IP addresses at the country or region level. If you implement this yourself, logons inside the office come from private addresses that cannot be mapped to a location, so treat "the office network" as a single location, and for VPN logons use the source IP recorded in the VPN connection logs. You need to match authentication logs and VPN logs by user name and time.

What to look for in proxy logs

In this series' environment, all traffic to external generative AI services goes through the proxy. That means the proxy logs are the very record of "who sent what outside." If they are loaded into a form you can aggregate with SQL, the following three queries are a starting point (written in MySQL 8.0 syntax).

-- 1. Users whose total sent and received exceeded 1 GiB in the last hour (bytes is assumed to be the column for total sent and received)
SELECT username, SUM(bytes) AS total_bytes, COUNT(*) AS requests
FROM proxy_logs
WHERE ts > NOW() - INTERVAL 1 HOUR
GROUP BY username
HAVING SUM(bytes) > 1073741824;

-- 2. Connections to destinations not on the allow list (most frequent first). NOT IN returns nothing if the allow list contains NULL, so use NOT EXISTS
SELECT p.username, p.dst_host, COUNT(*) AS cnt
FROM proxy_logs AS p
WHERE NOT EXISTS (
  SELECT 1 FROM allowed_domains AS a WHERE a.domain = p.dst_host
)
GROUP BY p.username, p.dst_host
ORDER BY cnt DESC;

-- 3. Users who received more than 10 responses of 407 in the last 10 minutes (407 = Proxy Authentication Required)
SELECT username, COUNT(*) AS challenges
FROM proxy_logs
WHERE status_code = 407
  AND ts > NOW() - INTERVAL 10 MINUTE
GROUP BY username
HAVING COUNT(*) > 10;

The 407 in the third query is the response RFC 9110 defines as "authentication is required to use the proxy." It is not an authentication failure in itself. Even with normal authentication, the first request gets one 407 back, and the request then goes through with credentials attached. So frequent 407s mean "suspected failures," not confirmed ones. To confirm, look at the proxy's own authentication result logs (for Squid, the results of the authentication helper). The first 407 often has no user name attached, so track it by source IP or per connection.

Thresholds such as 1 GiB and 10 times are only a starting point. Collect your own baseline for 1 to 2 weeks, then reset them just outside that distribution. The destination check in the second query is an exact host name match, so decide separately whether the allow list should cover subdomains.

7.2.3 Conducting Regular Audits

Settings drift a little at a time from the day they are put in place. Someone added to Domain Admins temporarily stays there, accounts of people who have left stay enabled, a password set to never expire as an exception is forgotten. This is called "configuration drift."

The basic way to find drift and correct it is to write out the current state at fixed intervals and compare it with the target state. Once a month, check the following five items. These five are the audit items this article recommends, each mapped to what was decided in 7.1. In addition, changes to privileged group membership (event IDs 4728 / 4732 / 4756) are monitored continuously with the mechanism from 7.2.1 instead of waiting for the monthly audit, and the monthly audit serves to catch what that missed.

Doing it by hand does not last, so automate the export

Checking five items by hand every month does not last. Leave producing the lists to a script, and have people judge only the "rows that differ from the target state." The following script runs on a domain controller or a management machine with RSAT installed, and exports to CSV the lists for items 1 to 4 and the current values of the item 2 policies. Item 5 (log settings) is checked with wecutil gr from 7.2.1 and by reviewing the audit policy.

# Monthly AD audit. Export the lists to CSV (requires the ActiveDirectory module)
Import-Module ActiveDirectory
$stamp  = Get-Date -Format yyyyMM
$outDir = "C:\\audit\\$stamp"
New-Item -ItemType Directory -Path $outDir -Force | Out-Null

# 1. Privileged group members. Keep direct members (nested groups also appear as rows) and effective members with nesting expanded
#    in the same 7 columns (Export-Csv cannot append correctly unless the column structure matches)
$rows = foreach ($g in 'Domain Admins', 'Enterprise Admins', 'Schema Admins') {
  Get-ADGroupMember -Identity $g |
    Select-Object @{ N = 'Group'; E = { $g } }, @{ N = 'Kind'; E = { 'direct' } },
      objectClass, SamAccountName, Name,
      @{ N = 'Enabled'; E = { $null } }, @{ N = 'LastLogonDate'; E = { $null } }
  Get-ADGroupMember -Identity $g -Recursive |
    Where-Object { $_.objectClass -eq 'user' } |
    Get-ADUser -Properties LastLogonDate, Enabled |
    Select-Object @{ N = 'Group'; E = { $g } }, @{ N = 'Kind'; E = { 'effective' } },
      objectClass, SamAccountName, Name, Enabled, LastLogonDate
}
$rows | Export-Csv -Path "$outDir\\privileged.csv" -NoTypeInformation -Encoding UTF8

# 2. Current values of the domain password policy and the fine-grained password policies (PSOs)
Get-ADDefaultDomainPasswordPolicy |
  Export-Csv -Path "$outDir\\domain-password-policy.csv" -NoTypeInformation -Encoding UTF8
Get-ADFineGrainedPasswordPolicy -Filter * |
  Select-Object Name, Precedence, MinPasswordLength, MaxPasswordAge, ComplexityEnabled,
    @{ N = 'AppliesTo'; E = { ($_.AppliesTo | ForEach-Object { $_.ToString() }) -join '; ' } } |
  Export-Csv -Path "$outDir\\fine-grained-policy.csv" -NoTypeInformation -Encoding UTF8

# 3. Enabled users with no logon for 90 days or more. Keep rows with an empty LastLogonDate (no record) so they can be reviewed separately
$cutoff = (Get-Date).AddDays(-90)
Get-ADUser -Filter 'Enabled -eq $true' -Properties LastLogonDate |
  Where-Object { $null -eq $_.LastLogonDate -or $_.LastLogonDate -lt $cutoff } |
  Select-Object SamAccountName, Name, LastLogonDate |
  Export-Csv -Path "$outDir\\inactive-90d.csv" -NoTypeInformation -Encoding UTF8

# 4. Enabled users whose passwords never expire
Get-ADUser -Filter 'PasswordNeverExpires -eq $true -and Enabled -eq $true' -Properties PasswordLastSet |
  Select-Object SamAccountName, Name, PasswordLastSet |
  Export-Csv -Path "$outDir\\password-never-expires.csv" -NoTypeInformation -Encoding UTF8

# 5. Users created in the past 30 days
Get-ADUser -Filter * -Properties whenCreated |
  Where-Object { $_.whenCreated -gt (Get-Date).AddDays(-30) } |
  Select-Object SamAccountName, Name, whenCreated |
  Export-Csv -Path "$outDir\\created-30d.csv" -NoTypeInformation -Encoding UTF8

Get-ChildItem $outDir | Select-Object Name, Length

The purpose and rights of service accounts cannot be determined from the list of non-expiring passwords alone. Check them against the service configuration (which service on which server runs under that account) and the rights delegated on OUs and servers.

The exported CSV only becomes an audit when you diff it against last month's and record, for each changed row, "is this an approved change?" and "who will fix it?" Not stopping at producing the lists is what matters most for keeping it going.

How much log data to keep, and how

Log retention is the foundation of auditing. The retention period is determined by the regulations that apply to your industry and your contracts with business partners, so first confirm with your legal or audit department which regulations apply to your company, and write the period and its basis into your internal rules. A period with no basis, such as "one year for now," turns out to be either too short or needlessly long when it is actually demanded.

Once the period is set, the requirements for how to keep the logs are the same regardless of regulation.

If you aggregate logs on a Linux log server, leave rotation and compression to logrotate. Do not compute the tamper-detection hashes inside logrotate. Compute them in a separate job on files whose compression has finished and whose contents are final, and record them in a non-rewritable store separate from the log server. If the hashes sit in ordinary files on the same server, an intruder can rewrite both the logs and the hashes.

# /etc/logrotate.d/security-logs (handles only rotation and compression)
/var/log/security/*.log {
    daily
    # rotate is the number of rotations, not the number of days kept
    rotate 400
    compress
    delaycompress
    missingok
    notifempty
    create 0600 root root
}

Chapter summary

Security is a cycle of "prevention," "detection," and "response." Harden the entry points in 7.1 (prevention), notice drift and anomalies through the monitoring in 7.2.1 and 7.2.2 and the audits in 7.2.3 (detection), and correct what you find and feed it back into policy (response). As long as these three keep turning, your authentication infrastructure grows stronger over time instead of weaker.

Next time, in Part 8, we will turn everything so far into concrete configuration examples, and look at how to combine it with AI security tools, from small to large environments.