The admin account still works on the wrong device

Dedicated admin workstations are available for privileged tasks. Yet the Tier-0 account can still be used on an ordinary laptop. An operating procedure describes the approved route without enforcing it technically. Even membership in Protected Users does not define a list of permitted origin devices.

Authentication Policies address that gap: when issuing a new Kerberos ticket-granting ticket, the domain controller can check whether the requesting device is approved. This article covers a limited pilot for human Tier-0 administrator accounts and dedicated Privileged Access Workstations, or PAWs. Service accounts, DC computer accounts and a complete silo architecture remain outside this change.

Separate origin, destination and logon type

The target is specific: a named pilot account receives a new Kerberos TGT only through approved admin devices. Their computer accounts belong to a tightly managed AD security group, such as T0-Approved-PAWs. Ordinary clients and general administration servers do not belong in that group.

UserAllowedToAuthenticateFrom evaluates the origin device. It is neither a list of permitted destination servers nor a grant of local or RDP logon rights. Resource permissions, user rights, firewall rules and separation between administration tiers must still be correct. A TGT obtained on an approved PAW must not be treated as permission to access arbitrary target systems.

Protected Users complements this model with its own authentication restrictions. Group membership and device restrictions are separate controls. Introduce them in separate changes so that a broken workflow can be attributed to the relevant change.

Prove the prerequisites before the pilot

The account domain needs at least Windows Server 2012 R2 domain functional level. This is a feature prerequisite, not a recommendation to run old operating systems. Use maintained, supported systems and check AD replication, DNS, time synchronization and connectivity to the relevant DCs.

Device checks require working Kerberos armoring and the necessary Dynamic Access Control support:

  • On all relevant DCs, enable KDC support for claims, compound authentication and Kerberos armoring under Computer Configuration > Policies > Administrative Templates > System > KDC. The Supported option is sufficient for this pilot; assess any existing deliberate configuration first.
  • On PAWs and controlled test devices, enable Kerberos client support for claims, compound authentication and Kerberos armoring under System > Kerberos.
  • Verify the effective GPO settings. A configured GPMC view alone proves neither policy processing nor a working authentication path.

Fail unarmored authentication requests is a broader domain decision and is not required for this limited pilot. Do not enable it incidentally. Likewise, any necessary functional-level increase belongs in a separate, prepared change.

Inventory actual administrative workflows: local PAW sign-in, RSAT, PowerShell Remoting, RDP, management portals and intermediate hosts. During remote logon, the machine requesting a new TGT may differ from the workstation initially visible to the operator. The RDP client name alone does not reliably identify the Kerberos origin path.

Prepare a small device allowlist

Start with a dedicated test account without production privileges, two approved PAWs and a separate managed negative-test device. Give that device the required Kerberos support but keep it outside the approved group. This tests missing device authorization rather than an incompatible client.

Populate the group with the verified PAW computer objects. Keep the pilot simple by avoiding nested groups. Document who can modify the group, its ACLs and the included computer objects. Anyone able to add an ordinary device to the allowlist can influence the protection boundary.

Before making changes, check whether the account already has a direct Authentication Policy or an Authentication Policy Silo assigned. Do not silently overwrite an existing assignment.

The following example reads configuration and group members only. Replace the names and DC with your approved pilot scope, and run it on a trusted admin workstation with the ActiveDirectory module.

Set-StrictMode -Version Latest
$ErrorActionPreference = 'Stop'
Import-Module ActiveDirectory

$dc = 'dc01.example.com'
$pilotUser = 't0-paw-pilot'
$pawGroup = 'T0-Approved-PAWs'

Get-ADDomain -Server $dc |
    Select-Object DNSRoot, DomainMode

Get-ADUser -Identity $pilotUser -Server $dc -Properties `
    'msDS-AssignedAuthNPolicy', 'msDS-AssignedAuthNPolicySilo' |
    Select-Object SamAccountName,
        'msDS-AssignedAuthNPolicy', 'msDS-AssignedAuthNPolicySilo'

Get-ADGroupMember -Identity $pawGroup -Server $dc |
    Select-Object Name, ObjectClass, DistinguishedName

The output proves neither effective group permissions nor working Kerberos armoring. It provides a reviewable starting inventory. Computer membership changes must replicate and reach the computer's authentication context; schedule a controlled restart of the test devices for this purpose.

Explicitly create the policy in audit mode

In Active Directory Administrative Center, open the account domain and create a policy under Authentication > Authentication Policies, for example T0-PAW-Pilot. Explicitly select Only audit policy restrictions. The ADAC dialog can default a new policy to enforcement; do not rely on an assumed default. Audit creates real AD configuration but does not yet block authentication because of this policy.

In the user settings, edit the conditions for devices from which sign-in is allowed. Select the group condition Member of any and the prepared T0-Approved-PAWs group. This means the origin computer's group membership. The editor's User label must not lead you to check an administrator group instead.

Let the graphical interface generate the security descriptor, then review the displayed condition. Do not copy an external SDDL string containing unfamiliar SIDs. Leave additional destination restrictions and TGT lifetime changes unconfigured in the first stage.

Next, explicitly assign the policy to the test user in the account's Policy section. Creating the policy or adding a PAW to a group does not activate evaluation for a user account. After replication, verify the assignment on the DCs serving the pilot.

Authentication Policy Silos can later group multiple accounts with suitable policies. A direct assignment is sufficient for this small pilot. A subsequent silo rollout must separately verify access grants, actual account assignment and enforcement state; a silo member list alone is not evidence of effectiveness.

Prove auditing with a deliberate negative test

Enable or verify the Microsoft-Windows-Authentication/AuthenticationPolicyFailures-DomainController channel on the relevant DCs, together with central forwarding. Use fresh sign-in sessions and record the test times.

  1. Approved PAW: The test account receives a new TGT. Check its issuance and the DC that actually handled the request.
  2. Unapproved test device: Sign-in may still succeed in audit mode. Expect event 305 for the failed origin condition.
  3. Review: The account, device and policy in the event must match the test. The event must also reach central monitoring.

An empty log is not acceptance evidence. It can also mean a missing assignment, an unmonitored DC or an unsuitable test path. Distinguish 305, which concerns the origin check, from 306, which concerns service-ticket restrictions. The latter is not the control configured here.

Once the control has been demonstrated, add one selected production admin account and use it only on trusted devices. Cover maintenance, shift changes and fresh sign-ins during a representative observation period. Never place production Tier-0 credentials on an ordinary workstation to conduct a negative test.

Enforce, accept and roll back precisely

Enable enforcement on the pilot policy only after resolving audit findings and testing emergency access. Repeat the positive and negative tests with the nonprivileged test account: a new TGT is issued from an approved PAW; the controlled request from the unapproved device is denied and generates 105. Then verify actual administrative tasks with the production admin account only on approved PAWs, not just the Windows sign-in screen.

The enforcement switch does not automatically revoke existing tickets or sessions. Test with fresh sessions. If a designated device fails, a second approved PAW or a separately protected emergency path must remain available.

The built-in domain Administrator with RID 500 is exempt from Authentication Policies, including when assigned to a silo. It is therefore unsuitable for a negative test. This exemption does not replace tested emergency access: account state, logon rights and other controls still apply.

The prepared rollback returns the pilot policy to audit or restores the documented previous account assignment. Allow replication and test a fresh sign-in. Do not immediately delete the policy or broadly add devices to the allowlist. Both actions complicate root-cause analysis and a controlled restart of the rollout.

Benefits of binding authentication to devices

  • The DC evaluates the approved origin, adding a control beyond local logon policy.
  • A small device allowlist makes privileged administrative paths reviewable.
  • Auditing and targeted negative tests support rollout with measurable acceptance criteria.
  • The additional control complements Protected Users, PAW hardening and logon rights without broadly expanding production permissions.

Disadvantages and technical limitations

  • Administration depends more heavily on maintained PAWs and working DC connectivity. Replacement devices need a prepared onboarding process.
  • An origin check does not attest to a PAW's integrity. A compromised approved device remains a significant risk.
  • NTLM cannot satisfy the Kerberos device condition and may fail under enforcement; event 101 is relevant. A clean 305 audit does not replace a separate assessment of NTLM dependencies.
  • LDAP simple bind, offline sign-in and existing tickets are not fully represented by this audit. Address those paths separately; device restrictions do not establish universal protection for every use of a password.
  • The control replaces neither MFA nor resource authorization, EDR or protection of policy and group administrators.

Remove common mistakes before the next wave

Typical failures include putting users rather than computers in the allowlist, leaving a policy unassigned or evaluating a membership change with an old computer authentication context. Missing DC coverage and tests that reuse existing TGTs also produce misleading results.

Another mistake is to approve every server involved in an RDP or tool failure. First establish which system is actually authenticating and whether that workflow belongs in the Tier-0 operating model. An expanding allowlist can otherwise undo the separation the project was meant to introduce.

Project checklist

  • [ ] Name the pilot accounts, PAWs, test device and accountable owner.
  • [ ] Verify functional level, replication and Kerberos support.
  • [ ] Record existing policy and silo assignments.
  • [ ] Review the computer group and rights to modify it.
  • [ ] Explicitly configure audit mode and assign the policy narrowly.
  • [ ] Prove event 305 reaches monitoring with a harmless negative test.
  • [ ] Test real admin paths and separate NTLM/LDAP dependencies.
  • [ ] Test the spare PAW, emergency access and rollback before enforcement.
  • [ ] Accept positive and negative fresh-TGT tests under enforcement.
  • [ ] Regularly review device onboarding, replacement and removal.