Enable Certificate-Based Authentication for Windows Admin Center Gateway Servers with AD CS

Implementing certificate-based authentication for Windows Admin Center (WAC) involves leveraging smart card login (user certificates) in Active Directory. In a production Active Directory environment, you can require administrators to authenticate with a client certificate. These are typically stored on a smart card or virtual smart card, before the administrator they can access the WAC gateway. This is achieved by using Active Directory Certificate Services (AD CS) to issue logon certificates to users and configuring Authentication Mechanism Assurance (AMA) in Active Directory to tie those certificates to a security group. WAC is then configured to allow access only to users who present the approved certificate (via membership in the special group). The result is that only users who have authenticated with a valid smart card certificate can access WAC, adding a strong second factor beyond passwords.

Before configuring certificate-based auth for WAC, ensure the following prerequisites are in place:

• Active Directory Domain: WAC and users must reside in an AD domain.
• AD CS (PKI) Deployment: An enterprise Active Directory Certificate Services Certification Authority should be installed and trusted by the domain.
• Smart Card Infrastructure: Users will need smart card devices or virtual smart cards. This could be a physical smart card + reader for each admin, or a TPM-backed virtual smart card (VSC) on their device. Each user must have a personal certificate that will be used for logon.
• Windows Admin Center: WAC should be installed in gateway mode on a domain-joined Windows Server. For production, replace the default self-signed certificate WAC generates with an SSL certificate issued by your CA that matches the WAC gateway’s DNS name.
• WAC Gateway Access Groups: Decide which AD security group(s) will be allowed as gateway users in WAC. Also create or identify a group to use for the smartcard enforcement. For example, create a group called “WAC-CertAuth-Required” (Global/Universal scope). No members will be directly added to this group. Membership will be assigned dynamically via AMA based on logon method.
• Domain Controller Certificates: Ensure your domain controllers have valid certificates for Kerberos PKINIT (Domain Controller Authentication certificates). Enterprise CAs usually auto-enroll these. This ensures DCs can accept smart card logons. Also verify DCs can reach the CRL distribution points for your CA certificates to check revocation.
• Group Policy for Smart Cards: It’s recommended to enforce certain policies: e.g., enable “Interactive logon: Require smart card” on accounts or systems if you want to prevent password logon entirely for those accounts, and enable “Smart card removal behavior: Lock workstation” on client PCs to auto-lock when a smart card is removed. Also consider enabling “Always wait for the network at computer startup and logon” to avoid cached logons interfering with AMA group assignment.

First, set up a certificate template in AD CS for your administrators’ logon certificates. You can either use the built-in Smartcard Logon template or create a dedicated one:

• Create a Dedicated Template: On your CA, open the Certificate Templates console. Duplicate the Smartcard Logon template (or the User template with adjustments) so you can customize it. Give it a name like “IT Admin Smartcard Logon”. In the template’s properties, configure the following key settings:
  • Compatibility: Ensure it’s set for at least Windows Server 2008 R2 / Windows 7 for full smart card support.
  • Cryptography: Choose a strong key length (2048 or higher) and CSP/KSP supporting your smart cards. Enable “Prompt for PIN on use” if available.
  • Subject Name: Set to “Build from this AD information” using the user’s User principal name (UPN). The UPN will be included in the certificate’s subject alternative name. This is critical as the domain controller uses the certificate’s UPN to map to the user account during logon.
  • Extensions: Under Application Policies (Extended Key Usage), ensure Smart Card Logon (OID 1.3.6.1.4.1.311.20.2.2) is present. You may also include Client Authentication (1.3.6.1.5.5.7.3.2) if users might authenticate to other services. Remove any EKUs not needed. Also, ensure “Signature and Smartcard Logon” or similar is selected as the issuance policy if relevant.
  • Security: Assign Enroll (and Read) permissions to the user group that will receive these certificates (e.g. your IT admins group), and to the enrollment agents if using one.
  • Expiration: Set an appropriate validity period (e.g. 1 or 2 years) and publish timely CRLs so expired/revoked certs are recognized.

This process will generate a unique Object Identifier (OID) for the new template (visible on the General tab or via certutil -template). Take note of this template OID, as we’ll use it for AMA mapping. (If using the built-in Smartcard Logon template, it has a default OID you can obtain similarly.)

• Publish the Template: If you created a new template, publish it on the CA (so it’s available for enrollment). In the Certificate Authority MMC, right-click Certificate Templates > New > Certificate Template to Issue, and select your template.
• Enroll Certificates to Admins: Enroll each administrator for a smart card certificate using this template. Typically, this is done by using the Certificates MMC on a client with a smart card reader:

o   Have the user insert their smart card and open certmgr.msc (or use a dedicated smart card enrollment tool if available).

o   Enroll for the “IT Admin Smartcard Logon” certificate. This will generate a private key on the card and issue the certificate to the card. The certificate should now reside in the user’s Personal store and on the card.

o   Ensure the certificate shows the correct UPN in the Subject Alternative Name and the Smart Card Logon policy in the Application Policies.

• Verify AD Trust of the Certificate: Because this is an enterprise CA, the issued certificates will automatically be trusted by Active Directory for logon (the CA’s root is in the NTAuth store). Just to be safe, confirm that the CA’s root cert is present in the NTAuthCertificates container in AD (use certutil -viewstore -enterprise NTAuth). If not, publish it using certutil -dspublish -f rootcert.cer NTAuth. This ensures domain controllers trust certificates from this CA for authentication.

At this stage, each admin user should have a valid smart card logon certificate issued by AD CS, which includes an OID identifying the template. Next, we’ll configure Active Directory to recognize this OID and link it to a security group via Authentication Mechanism Assurance.

Authentication Mechanism Assurance (AMA) is an Active Directory feature that adds a user to a security group dynamically when they log on with a certificate that contains a specific issuer policy or template OID. We will use AMA to flag users who authenticated with our smart card certificates. The plan is to map the OID of our “IT Admin Smartcard Logon” certificate template to a special security group (e.g. “WAC-CertAuth-Required”). When a user logs on with that certificate, domain controllers will automatically include this group in the user’s Kerberos token; if they log on with a password or other method, they won’t have this group.

Follow these steps to configure AMA:

1. Create a Universal Security Group: If not already created, make a new security group in AD (preferably in the Users container or a dedicated OU) named for example “WAC-CertAuth-Required”. Make it a universal group (recommended for AMA) and set scope to Security. Do not add any members to it as AMA will control membership. Also, do not use this group for any other assignments except this purpose.
2. Find the Certificate Template OID: Locate the OID of the certificate template you are using:

o   Open the properties of the certificate template in the Certificate Templates console. On the General tab note the Template OID (e.g. 1.3.6.1.4.1.311.x.x.xxxxx.xxxx…). Alternatively, use Get-CATemplate <TemplateName> in PowerShell or certutil -v -dstemplate <TemplateName> to get the OID.

o   If you used the built-in Smartcard Logon template, its OID can be found similarly (each template has a unique OID).

3. Map the OID to the Group in AD: This step requires editing the AD Configuration partition using ADSI Edit or PowerShell:

o   Open ADSI Edit (adsiedit.msc) as an enterprise admin.

o   Right-click ADSI Edit > Connect to…. Select Configuration well-known naming context.

o   Navigate to CN=Public Key Services,CN=Services,CN=Configuration,<forest DN>. Under this, find CN=OID (Object Identifiers). This container holds objects for certificate template OIDs and issuance policy OIDs.

o   Look for an object whose msPKI-Cert-Template-OID attribute matches the OID of your certificate template. The objects are often named after the template or have a GUID. You may need to inspect each until you find the matching OID value.

o   Once found, open the properties of that OID object. There will be an attribute msDS-OIDToGroupLink. This is where we link the OID to a group.

o   Copy the distinguishedName of the “WAC-CertAuth-Required” group you created (you can find it by connecting ADSI Edit to the Default naming context, locating the group, and copying the DN).

o   In the OID object’s properties, set msDS-OIDToGroupLink to the DN of your group. Apply the change.

This mapping tells AD: for any user logging in with a certificate issued from this template OID, include the specified group in their token.

A quick way to confirm the mapping is working is to try adding a member to the “WAC-CertAuth-Required” group in AD Users & Computers. It should prevent you from manually adding any members now, giving an error like “OID mapped groups cannot have members.”. This is expected as the group is now controlled by AMA.

Now AMA is configured. When a user authenticates with our smart card cert, the domain controller will evaluate the certificate, see the template OID, and if it matches the mapped OID, will add the “WAC-CertAuth-Required” group SID to the user’s Kerberos token. If the user logs on with username/password, that group will not be present.

AMA triggers only during interactive logon (or unlock) when the user actually uses the certificate to log on to Windows. It does not dynamically add/remove groups in the middle of a session. This means the user must log onto their machine with the smart card certificate to get the group.

WAC supports two identity providers for gateway access: Active Directory (default) or Microsoft Entra ID. We are using AD with an added smart card requirement. WAC provides a setting to require membership in a “smartcard authentication group” in addition to the normal user group.

Do the following on the WAC gateway server (while logged in as a WAC gateway administrator or local admin):

1. Open WAC Access Settings: In a web browser, access the Windows Admin Center portal (e.g. https://<WACServer_FQDN>). Go to the Settings (gear icon) > Access panel. Ensure “Use Active Directory” (or “Use Windows Access Control”) is selected as the identity provider, since we are using AD groups.
2. Configure Gateway Users Group(s): Under User Access, you should see an option to specify who can access the WAC gateway (“Gateway users”). By default, if no group is listed, any authenticated user can access. Add your administrators group (or groups) here to restrict WAC access to only those users. For example, add “IT Admins” or whatever AD group contains the admins that should use WAC. After adding, it will show up in the list of allowed user groups.
3. Enable Smartcard Enforcement: Still in the Access settings, look for the Smartcard authentication option when you add . WAC allows specifying an additional required group that indicates smart card usage. Add the “WAC-CertAuth-Required” (the AMA-linked group) here as the Smartcard-required group. In the WAC UI, this might be done by clicking “+ Add smartcard group” or marking one of the added groups as a smartcard group. (In some versions, you first add the group under Users, then check a box to designate it as a smartcard-enforced group.)

o   After this configuration, WAC’s effective access check becomes: a user’s AD account must be a member of at least one allowed group and must be a member of the specified smartcard group. This corresponds exactly to requiring certificate logon. According to Microsoft’s documentation: “Once you have added a smartcard-based security group, a user can only access the WAC service if they are a member of any security group AND a smartcard group included in the users list.”. In our case, that means the user must be in (for example) “IT Admins” and in “WAC-CertAuth-Required”. The latter only happens when they’ve logged on with the certificate, so effectively the user must be using their smart card.

4. Configure Gateway Administrators (if needed): If there are others who will administer the WAC gateway settings, you can also add groups/users under the Administrators tab. You can also enforce a smartcard group on administrators similarly. Typically, local Administrators on the server already have admin access to WAC by default. Make sure those accounts also use smart cards or you exclude accounts accordingly for security.
5. Save Settings: Save or apply the Access settings. The WAC gateway service may restart to apply changes.

You can verify WAC access settings via PowerShell on the WAC server. Open PowerShell and use: Get-SMEAuthorization (if available) or check the configuration file. WAC stores allowed groups and the smartcard-required group. Ensure the output lists your groups correctly. There is also a PowerShell (Set-SMEAuthorization) to configure these settings if you prefer scripting (documentation covers using -RequiredGroups and -RequiredSmartCardGroups parameters for WAC).

At this point, WAC is configured to require certificate-based authentication. The gateway will perform Windows Integrated Authentication (Kerberos/NTLM) as usual, but it will only authorize the session if the user’s token contains the smartcard group SID in addition to an allowed group SID. If the user logged in with a password, the smartcard group SID is missing and WAC will deny access (HTTP 401/403).

It’s crucial to test the setup end-to-end to determine if the configuration functions as expected.:

• Test Case 1. Password login (should be denied): Have an admin user attempt to access WAC without using their smart card. For example, the user can sign out and log on to Windows with just username/password (or disable their smart card login temporarily). Then navigate to the WAC URL. The WAC site will prompt for authentication (the browser will try Integrated Windows Auth). The user may be prompted to authenticate; if so, even entering correct AD credentials should result in access denied at the gateway. The user will see a 401 Unauthorized error from WAC after login, or WAC will keep prompting for credentials. This is expected because although the user is in the allowed admin group, they are not in the AMA smartcard group (since they logged on with a password). WAC will refuse access since the AND condition is not met. This confirms that a password-only login is insufficient.
• Test Case 2. Smart card login (should be allowed): Now have the user log off and log on to Windows using the smart card. (On the Windows login screen, they should insert the card, choose the smart card login option, and enter the PIN. This uses their certificate to authenticate to AD.) After interactive logon with the smart card, the user’s Kerberos ticket now includes the “WAC-CertAuth-Required” group, courtesy of AMA. Now access the WAC portal again (e.g. via Microsoft Edge or Chrome). The browser will perform Integrated Auth (which will use the logged-on user’s credentials/ticket). The user should be granted access to WAC this time and see the usual WAC interface. No additional prompts occur. WAC sees the user is in both required groups and permits the connection.
• Confirm Group Presence: On the user’s machine, you can run whoami /groups in a command prompt after logging in with the smart card. You should see the “WAC-CertAuth-Required” group listed in the groups. If you log in with password, that group will not be listed. This is a quick way to verify AMA is working as intended.
• WAC Logging: In the Windows Admin Center server, check the event log “Microsoft-ServerManagementExperience” (under Applications and Services Logs) for any relevant warnings or errors. When a user is denied due to not meeting group requirements, WAC will often log an event indicating the user’s identity was not authorized. This can help confirm that the smartcard requirement was the reason (versus other failures).
• Edge/Browser Behavior: If the browser pops up a Windows Security login dialog repeatedly even after using the smart card, make sure the site is in Intranet Zone or Trusted Sites so that Integrated Auth is seamless. Also ensure the user’s certificate authentication to the domain is functioning (they have a Kerberos TGT). In most cases, after a smart card desktop login, the browser should not prompt at all. It should silently use the existing Kerberos ticket.

By completing these tests, you validate that the system is correctly distinguishing certificate-based logons from password logons when gating WAC access.

Despite careful setup, you might encounter issues. Here are common problems and their solutions:

• User not being added to AMA Group: After logging on with a smart card, if whoami /groups does not show the “WAC-CertAuth-Required” group:

o   Verify the certificate was issued from the correct template (check the certificate’s details: under Details, Certificate Template Information should show your template name/OID).

o   Verify the OID mapping in ADSI Edit is correct (no typos in the DN, and it’s in the right OID object).

o   The group must be universal scope if in a multi-domain forest. If it’s global and the user/DC are in another domain, it might not be assigned. Use Universal as recommended.

o   Ensure domain functional level is 2008 R2 or higher; AMA won’t work below that.

o   If the user is logging on to a machine that is offline (no DC contact) and using cached credentials, AMA won’t apply since the DC can’t evaluate the certificate. The “Always wait for network at logon” GPO setting (Computer Configuration → System → Logon) should be enabled to force online logon. If the user must logon cached (like laptop off VPN), they won’t get the AMA group until they can contact a DC (which would then happen when they access domain resources).

o   Check the Event Log on the Domain Controller handling the logon (Security log). Look for event 4768 or 4771 around the logon time:

• • • 4771 with Failure Code 0x12 or text about “Encryption type not supported” might indicate a missing DC certificate or Kerberos settings issue.
    • Errors about “The certification authority is not trusted” or “Smartcard logon is not supported for user” indicate trust problems. Make sure the CA cert is in NTAuth and the user cert has the proper UPN.
    • If you see Event 19 in the System log on the DC (KDC event for failed smart card logon), it often gives a reason code. For example, “KDC certificate missing” or “No valid CRL” etc.

o   One quick check: run on a DC certutil -verify -urlfetch <UserCert.cer> using the exported user certificate. This will test if the DC (or whichever machine you run it on) can validate the cert chain and CRLs. Any errors here need addressing (trust chain, CRL, or missing template OID mapping).

o   If the user’s certificate does not have the Smart Card Logon EKU and you instead tried using just Client Authentication: domain controllers by default require the specific Smartcard EKU (or the new “Kerberos Authentication” EKU in newer domains). Make sure the template included the correct EKU for smart card logon, otherwise the DC may not treat it as a smart card login attempt at all.

• User can log in to WAC with password (not expected): If somehow a user was able to access WAC without using the smart card:

o   Double-check WAC’s Access settings. Perhaps the smartcard-required group wasn’t properly added. On the WAC server, run Get-SMEAcls or check the config to ensure the RequiredSmartcardGroups attribute includes the correct group SID.

o   Confirm the user’s account isn’t in that smartcard group permanently (no one should be a direct member; AMA groups should have no static members). Use ADUC or PowerShell to ensure the group has no members attribute set. If someone manually added a user to that group, then that user will bypass the need for a cert (they always have the group). Remove any unintended members. “OID mapped groups cannot have members” enforcement should prevent this, but if the mapping was wrong and not actually applied, someone might have populated the group. Fix the mapping and clear members.

o   Ensure the user didn’t somehow have the AMA group from a previous smart card logon cached. A known caveat: If a user previously logged on with a smart card and then logs off and back on with a password on the same machine without a reboot, Windows might cache the group in the token (due to an optimization). This can happen with “fast logon” or unlock scenarios. The fix is the GPO mentioned (disable fast logon). In practice, a fresh reboot + password logon should drop the group. Warn users that switching from smartcard to password login on a machine without reboot could be inconsistent. It’s safest to always use the smart card, or reboot if they must log in with password for some reason.

o   If using remote desktop to WAC server or a jump box, ensure the same certificate enforcement is considered there. If someone logs into the jump box with a password and then tries to use WAC, they’ll fail. That’s expected. They should RDP with smart card as well (RDP supports smart card logon pass-through).

• Repeated credential prompts when accessing WAC: If a user who logged in with a smart card still gets prompted for credentials in the browser:

o   Ensure the browser is configured for integrated authentication. For Internet Explorer/Edge (IE mode), the WAC URL should be in the Local Intranet zone (which usually allows automatic Windows auth). For modern Edge/Chrome, they typically automatically attempt desktop credentials, but if not, you can go to edge://settings -> Automatic profile switching or edge://flags for integrated auth, or use group policy “Integrated Windows Authentication” to allow the WAC URL. In Chrome, you can run it with –auth-server-whitelist=”wacservername.domain.com”.

o   If the browser prompts for a certificate selection (some configuration might cause the site to request client cert at TLS level), that’s not default for WAC. WAC by itself doesn’t use TLS client-cert authentication, so you shouldn’t see a certificate selection popup. If you do, perhaps you or someone configured the HTTP.sys binding on the WAC server to Require Client Certificates. That is not necessary for this solution (and would interfere, as WAC isn’t expecting to parse client certs itself). If enabled, consider disabling that requirement, as our approach uses Kerberos group membership instead. Remove any manual netsh http client cert negotiation settings unless you have a special reason.

o   Check that the user’s smart card credential was cached in Windows properly. Sometimes after a fresh logon, the first hit to a secure website might trigger a PIN prompt if the browser tries to use the certificate for TLS or something. Ensure the PIN was entered during login and is still valid (some smart cards might require PIN re-entry for signing, but usually not for Kerberos since Kerberos is already obtained at logon).

o   Lastly, confirm that the user’s Windows session indeed has the AMA group. If not, WAC will keep prompting because it sees the user in allowed group but not in smartcard group, and might treat them as unauthorized (causing the browser to prompt again). This will result in a 401. You might see the prompt come up repeatedly and then a blank page. In WAC’s log, an event or error saying the user is not authorized will confirm it. The solution is to get the AMA group in the token (log in with the card properly, fix AMA if broken).

• Smart card login fails on Windows: This is more of a PKI/AD issue than WAC issue:

o   If when inserting card at logon, you get messages like “The system could not log you on” or “No valid logon servers” or “certificate not recognized,” debug the smart card logon itself. Common causes: the user certificate is missing the UPN or has a UPN that doesn’t match the account, the CA that issued it isn’t in NTAuth or not trusted by the client or DC, or the DC’s own certificate is missing (check DC has a cert in its personal store issued by your CA for domain controller authentication).

o   On the client, when the logon fails, you can sometimes hit “Switch User -> Smart card logon” and see if it lists the certificate. If not, the card middleware might not be installed or working. If it lists it but errors after PIN, then likely an AD trust issue. Domain controller security log will have details.

• Certificate Revocation issues: If a user’s certificate was revoked or expired, obviously they won’t be able to authenticate with it. The DC will deny the smart card logon (event will indicate revoked or expired cert). The user would fall back to password (if allowed) which then won’t grant WAC access. The fix is to renew their certificate in advance. Always keep track of expiry dates and set reminders.
• Updating Certificates: When an admin gets issued a new smart card or cert (or their cert is renewed with a new OID template), ensure your AMA mapping covers it. If you created a new template (with a new OID) for any reason, you must map that OID as well. AMA can map multiple OIDs by linking them to possibly different groups. WAC only supports one smartcard group in settings, so ideally you’d keep using the same template OID for all admin certs. If a new OID is needed (say you have multiple CAs or different templates), you could map it to the same group or include multiple groups in WAC (though the UI supports one, you might workaround by nesting groups or adding multiple allowed combos). Simpler is to stick to one cert template for this purpose.
• Group Policy caching: The AMA group inclusion happens at the Kerberos TGT level. If a user logs on with smart card, gets the group, then later the group mapping is removed or changed, an existing TGT might still have the group until it expires (~10 hours by default). Clearing the Kerberos ticket (by klist purge or logoff) would remove it. Keep this in mind during changes: if you remove the mapping or change group, there could be a latency until all tickets expire or users logoff.
• Alternate access methods: If someone tries to use PowerShell Remoting (Enter-PSSession) or other tools to connect to the WAC gateway, they will still undergo the same check. Typically WAC is accessed via web, but just know the Windows auth is at play regardless of interface.

When using certificate-based authentication for WAC via this method, be aware of the following limitations or considerations:

• Domain-Joined Clients Required: This solution assumes admins are using domain-joined Windows machines for WAC access (so that their smart card logon yields a Kerberos token with the group). If an admin tries to access WAC from a non-domain system (where they can’t do a Windows integrated logon), they would be prompted for credentials. They could technically insert their smart card and select it in the browser when prompted for credentials, but that would attempt a certificate mapping at WAC which is not configured. WAC does not natively support direct client certificate mapping at the web application layer. The only supported way is via AD group as we’ve done. So in practice, non-domain or external access should be done through a secure method (e.g. VPN into domain or using Azure AD integration as mentioned). This is by design as WAC relies on Windows Authentication, not forms or client-cert web auth.
• No Native OTP/MFA Prompt: Unlike some web apps, WAC itself doesn’t have a secondary prompt for OTP or similar. The smart card enforcement leverages the Windows login. So there’s no separate UI in WAC for “insert your certificate”. It’s all transparent once set up. As such, you can’t mix password + cert in a single login to WAC as it’s one or the other via how the user logged into Windows.
• Single Smartcard Group Limit: WAC’s configuration allows only one “smartcard-required” group to be set. If you had different levels of assurance or multiple certificate profiles, you might need to create a common group that all certificate-authenticated users get. For example, if you issue different certs (say some with higher assurance), you may map multiple OIDs to the same AMA group so that any of them will satisfy the WAC check. Plan your AMA mappings accordingly (you can map multiple OIDs to one group by concatenating DNs in the msDS-OIDToGroupLink, or by having multiple template OID objects point to the same group DN).
• Auditing: Note that when users access WAC with this setup, the logon audit on the WAC server will show a normal Kerberos login by the user. There isn’t an explicit event on the WAC server saying “used certificate”. The evidence of certificate use is in the DC’s logs (Kerberos AS ticket was obtained via smart card). So, auditing wise, you might correlate that if a user accessed WAC and had the AMA group, it means they used a smart card. If auditing that is important, ensure to retain domain security logs. You could also set up a scheduled task and script to log an event on the WAC server when a user lacking the group tries to connect (e.g., monitor WAC error events for unauthorized access).