The Other Book: Authentication Policies

Authentication Policies are a great addition to Active Directory Kerberos that allows you to properly engineer authentication in your environment. Not a lot has been published on how to actually use them, or why, and both the apparent lack of traction in the field and reader feedback I received for my book suggest that in this case, the question of the “why” is better answered to people who already have an understanding of the “what” and the “how”. So let’s unpack all three, and hopefully more organizations can benefit from better-engineered Kerberos in their authentication stack.

In this Chapter

What is this all about?

For over two decades, authentication and authorization in Windows were two different things, the latter fully dependent on, but not in any way intertwined with, the former. An AD administrator’s primary job used to be – and in many organizations, still is – to ensure authentication is universally available throughout the environment. In contrast, an application administrator’s job is to ensure an authenticated user is granted proper access within “their” application – which sometimes means no access at all! In that case, the preceding authentication was effectively unnecessary. This “separation of duties” has greatly contributed to Active Directory’s attack surface being what it is – credentials stolen in one place can be freely reused in another, and to steal credentials, attackers can utilize primitive techniques like authentication relay or DNS spoofing. Authentication Policies have been designed to put an end to this type of abuse.

On a very high level, Authentication Policies are about restricting

  • who can log on from where
  • what protocols can be used when doing so (or, to be more precise, whether NTLM can be used)
  • who can request service tickets to a particular service and from where

The first two requirements are not new – the logonWorkstation and logonHours attributes existed in Windows NT, and policies to restrict NTLM usage are part of Windows since Server 2008 R2. And of course, there is always the ability to disable a user account altogether, effectively preventing it from authenticating. However, these facilities are not precise or robust enough to serve as a basis for well-engineered authentication, and Kerberoasting attacks emphasized the necessity to restrict not only logon, but also service ticket requesting abilities.

Authentication Policies, introduced with Server 2012 along with other Kerberos improvements, were the answer to that. They act on the KDC, at the level of ticket issuance, so it is not about restricting logon after successful authentication, it’s about preventing authentication (or service ticket issuance) in the first place!

To decide whether a particular authentication or service ticket request should be granted, Authentication Policies work with claims. There are four types of claims that you can use in policy conditions:

  • Group memberships
  • Explicit mention of a user or computer object (which is somewhat hidden)
  • association to a certain Authentication Policy Silo
  • free claims that can be based on a value of an AD attribute (yes, you’re reading that right – you can make authentication decisions based on some attribute normally unrelated to authentication)

The last claim type was designed for another potentially exciting Server 2012 feature, Dynamic Access Control. Although hardly anyone ended up using it, you can at least give it some love by utilizing claims, where appropriate, in your AuthN Policies. To enable the creation of claims within the ticket issuance flow, both the KDC and the Kerberos Clients need to be on a certain operating system level (Server 2012 / Windows 8 or newer) and have the “Support for Claims, Compound Authentication and Kerberos Armoring” policy enabled. Since “Kerberos Armoring” is the Microsoft’s implementation of the FAST standard, I will refer to this policy as the “FAST policy” for the sake of brevity. Keep in mind that in most scenarios you will want the Kerberos Client FAST policy enabled on Domain Controllers as well!

To manage and assign AuthN Policies and Silos, you have two first-party tools at your disposal: the Active Directory PowerShell module and the Active Directory Administrative Center (ADAC). Physically, policies and silos are stored in the Configuration partition, under CN=AuthN Policies,CN=AuthN Policy Configuration,CN=Services,CN=Configuration,DC=<forest root domain> and CN=AuthN Silos,CN=AuthN Policy Configuration,CN=Services,CN=Configuration,DC=<forest root domain> respectively. This makes them forest-wide objects, and in the default permission set you need Enterprise Admin credentials to create and edit them.

What are Authentication Policy Silos?

As we just saw, associating a silo to a user or a device creates a claim which Authentication Policies can filter on to make authentication decisions. But silos have a second function: they serve as an envelope for an AuthN Policy (or a set of policies – one for users, one for gMSA, one for computers)  to link to the principals assigned to the silo. The policy from the silo will even override any policy assigned to a principal directly. Do keep in mind, however, that a policy created in ADAC will be enforced unless you change the setting, whereas a silo created in ADAC will be in Audit mode by default! This is not the last ADAC oddity we will encounter in this chapter!

A common question that is often asked by AD people trying to wrap their heads around this concept, is

Do I have to use Authentication Silos?

The answer is: absolutely not. You can build a workable AuthN Policy framework with direct policy assignments, group filters and custom claims.

Is it “Authentication Silo” or “Authentication Policy Silo”?

It is both. The official documentation and the names of the PowerShell cmdlets suggest “Authentication Policy Silo”, but the container where the silo objects are stored in AD is just named “AuthN Silos”, and the resulting AD claim is called ad://ext/AuthenticationSilo. I also prefer “Authentication Silo”, both for brevity and because the silos provide more functionality than just policy assignment. I don’t think either variant will lead to any misunderstandings, so feel free to use whichever you like more.

I, for one, will stick to “Authentication Silo” from here on out.

Silo Membership vs. Silo Access vs. Silo Assignment

When you start working with Authentication Silos, you may find yourself staring at a screen like this

and asking yourself what the difference is between “permitted accounts” and “silo-assigned accounts”. The “Add” and “Remove” buttons shown above even got their own PowerShell cmdlets: Grant-ADAuthenticationPolicySiloAccess and Revoke-ADAuthenticationPolicySiloAccess all of which result in modifying the .Members property of the [ADAuthenticationPolicySilo] object representing the silo. However, adding an account to the list does not change its authentication behaviour in any way. There is also no such “membership” functionality for individual Authentication Policies.

The difference between putting an account on the members list and actually assigning the silo becomes apparent when you start thinking about least privilege for your AuthN Policy framework. To assign a silo to an account, all you need is write permissions to the msDS-AssignedAuthNPolicySilo attribute of that account. By assigning a silo, however, you not only assign a policy to the account in question, but you also create a claim that could open up additional access permissions. To prevent this from happening without proper authorization, the msDS-AuthNPolicySiloMembers attribute of the silo is also examined during policy evaluation. That attribute must contain the DN of the account in question.

For example, the computer G22-CL02 has been assigned the silo above by an administrator permissioned to manage that computer’s object, but it’s not showing up on the list because that computer has not been added as a silo member. This will result to the silo NOT being applied to that computer!

One last thing that you might have also noticed in the above picture or in your own environment: The G22-CL01 computer object is not showing the account type, nor the assignment status. This is a limitation of the ADAC and due to the fact that the computer is in a different domain as the administrator running the current ADAC session. From the computer’s domain point of view, it’s quite the opposite:

ADAC just won’t perform any cross-domain requests in this pane! If you want to replicate this functionality in your own tooling, consider adding the msDS-AssignedAuthNPolicySilo attribute to the Global Catalog – this way, you won’t have to chase referrals but can just query data that is available forest-wide.

Scenario 1: AuthN Policies that work even without FAST!

A common misconception, found in nearly every article that’s been written about AuthN Policies is that you have to enable FAST (Kerberos Armoring) in order to “activate” the AuthN Policies functionality, and since some administrators are unsure of what else that action entails, they are holding back on the whole AuthN Policy construct. This, however, is not quite true. There is one scenario where an AuthN Policy, as soon as it gets assigned, will start influencing authentication even if FAST is disabled – namely, if the policy evaluation is guaranteed to fail!

Let’s create a simple policy that will definitely fail evaluation because we require that the computer be in a silo that does not exist in this forest. To fail evaluation of this policy, no claims are needed – the KDC knows that the referenced silo doesn’t exist and will fail the policy immediately:

As soon as we assign this policy to “Joe User”, Joe cannot authenticate anymore:

This opens up two interesting techniques where AuthN Policies can already help secure your AD environment, without even having to enable FAST on Domain Controllers, let alone on members:

  1. Protecting one-way trusts against being penetrated in the wrong direction by extracting the trust password from the trustedDomain object – just assign a policy like the one shown above to the trust user (it’s named TRUSTINGDOMAIN$, you can find the object in the Users container of the trusted domain with any tool other than ADUC or ADAC) and you’re done!
  2. Preventing users who are on leave or under investigation from authenticating without changing any other properties of their objects than the AuthN Policy assignment.

Any scenario where the policy evaluation could succeed in theory requires claim-based authentication and FAST to be functionally enabled.

Using PowerShell in this scenario

To implement the policy shown above using PowerShell, just run

$newPolicy = @{
  'Name' = 'YouShallNotPass'
  'UserAllowedToAuthenticateFrom' = 'O:SYG:SYD:(XA;OICI;CR;;;WD;(@USER.ad://ext/AuthenticationSilo == "NonExistentSilo"))'
  'ProtectFromAccidentalDeletion' = $true
  'Enforce' = $true
}
New-ADAuthenticationPolicy @newPolicy
Set-ADUser joe.user -AuthenticationPolicy 'YouShallNotPass'

The filter syntax, expressed in SDDL, is not for the faint of heart, but I can guarantee you that you will get the hang of it very quickly as you go along!

Aside: Who is the perfect Break-Glass account?

The policy created in the previous section will prevent any principal it has been assigned to from authenticating – with the notable exception of the default “Administrator” account with the RID 500! You just can’t prevent it from authenticating, short of disabling the account altogether! This makes the default Administrator your ideal Break-Glass account – which, in turn, means that you must

  • Stop using it for day-to-day administration right now.
  • Set its password to a value that is long and complex enough, but still typeable by humans – a Break-Glass account is likely to be used in a situation when copy & paste will not be possible.
  • Print that password out, put it in a sealed envelope and store it in a safe somewhere. Do your future self a favor and use a font like Courier New that makes a clear distinction between Oh and Zero, capital I and small l and so forth.
  • Repeat for each domain in each forest that you manage.

It is also a good idea to monitor for these accounts successfully logging in – this should always prompt an urgent investigation and an immediate password reset! Make no mistake: even a sanctioned use of that password must lead to changing it afterwards! Monitoring for failed logons of the RID-500 account is also a worthwhile task – if nothing else, these will reveal someone trying to reuse a password for an “Administrator” account gleaned somewhere else!

And while you’re at it, take another couple of minutes and roll your Domain Controllers’ DSRM passwords – these need to go in that envelope as well!

Scenario 2: Building an island

Imagine you have a group of computers and a bunch of users for which you would like to create an “authentication island” – only the users form the “island” must be able to log on to the “island” computers, and only to those! If you think it sounds a lot like tiering, you’re not wrong 🙂 

Building such an island is really super easy. Create an AuthN Policy “Island Policy” that has the exact same filter for user logon and computers:

Now create a silo and make sure it’s called “Island”, assign the “Island Policy” for all three categories. Assign the island computers and the island users to the silo:

Now if one of the silo users tries to log on to a computer outside the silo, they will get the same error message as Joe User above. A different error message appears when an “outsider” attempts to log on to an island computer:

“Authentication Firewall”, no less! But that’s essentially what it is.

Did you notice the identical filter for computers and users? Shouldn’t it rather be Device.AuthenticationSilo Equals “Island”? This is one of the many quirks of the AuthN policies, at least if you edit them in ADAC – “User” in this particular context means “Device”, which is why there is not option to select “Device” in this particular dialog. The users this policy applies to are sufficiently defined by assignments, be it to policy or to silo!

Aside: Another ADAC oddity

On the ADAC screenshots in the previous section, you may have noticed that I am only showing the parts of the dialog relevant to the topic at hand. This is a neat ADAC capability which may or may not exist in other tools based on Server Manager: when you open a dialog that has multiple sections, you get the “SECTIONS” dropdown on the top right which allows you to unselect section you currently do not want displayed. However, this comes with a quirk: If you leave some of the sections disabled, any subsequent opening of an AuthN Policy may display an error in the “Computer” section saying “Content cannot be displayed due to invalid data format” – and preventing you from saving any changes to the sections that are being displayed!

If you should run into this, just add all the sections back to display, and you’re back to normal.

Scenario 3: Disabling NTLM for individual users

Beside enabling or disabling authentication altogether based on claims, AuthN Policies also have the ability to either restrict authentication to Kerberos only or to also allow NTLM. You will find the related settings in the “User Sign On” section of the policy:

The “rolling NTLM secret” part is a stopgap, albeit a pretty powerful one, aimed at defeating Pass-the-Hash and NTLM hash bruteforcing in cases you still have to fall back to NTLM because of legacy systems you may have in place. It effectively introduces a per-session password that is used in lieu of the actual user password, similar to the virtual password created for accounts with SmartCard-only logon restriction.

Interestingly enough, I was never able to get rolling secrets to work, even with something as basic as accessing a Windows Server file share using its IP address in the UNC path. The investigation is still ongoing, but for now, I consider this a still unclosed gap – either in my understanding of how this actually works, or, indeed, in the product.

But even if you (or I) do get this to work, allowing NTLM in AuthN Policies is actually a little goofy – the computers that need to be accessed over the network using NTLM have to be included in the policy, effectively allowing the assigned users interactive logon to those systems. This can be amended by user rights assignments, of course, but doing so introduces another layer of complexity and hampers adoption. This is also not something the AD team could do anything about – in NTLM, it’s the resource, not the client, that submits an authentication request to the Domain Controller so the resource needs to be “in-policy” if the user is governed by an AuthN policy!

Denying NTLM, on the other hand, is very easy. All you need is an AuthN Policy with none of the NTLM boxes checked and – this is important! – a restriction for the computers the user is allowed to log on to. The restriction can be as relaxed as you like, all the way up to DOMAIN\Domain Computers, if you do not wish to impose any actual restrictions at this time. Assign the policy to a user, and that user will not be permitted to use NTLM anymore!

If you are at the beginning of your NTLM disablement journey, this could be your ticket to at least disabling NTLM for privileged identities and VIPs, without restricting it domain-wide at this early stage or putting the users into Protected Users with all the other side effects that entails.

Aside: Modifying the TGT Lifetime

The feature of AuthN Policies both the documentation and the blogosphere are talking about the most is the ability to set the TGT lifetime to an arbitrary value of 45 minutes or longer. Without policies, there is only the choice between what’s set in the Default Domain Policy (the factory-supplied value being 600 minutes, or 10 hours) and the hardcoded 240 minutes, or 4 hours, if the principal in question is a member of the Protected Users group.

I don’t have any clear scenarios that would warrant having many different TGT lifetime settings within the same domain. Here are some thoughts that may or may not influence your policy engineering:

  • For privileged accounts (think T0 isolation) that cannot go into Protected Users (computers and service accounts, for instance) setting the TGT lifetime to 240 minutes seems like a good choice. This way, all privileged principals get 4 hours TGT, whether they are in Protected Users or not, and the rest gets the domain setting,
  • If you need a longer TGT lifetime than 10 hours and for some reason are not comfortable increasing the domain setting for everyone, you’ll have to document this and adjust your KRBTGT password change regime accordingly to accommodate for those longer-living tickets.
  • If you’re aiming for a shorter TGT lifetime for a very limited group of accounts, doing it by means of Authentication Policy is totally fine. A shorter TGT lifetime for a large part of the population should prompt the discussion about just lowering the domain setting.
  • Last but not least, if you operate a large AD environment, a drastic shortening of the domain-wide TGT lifetime will lead to more Kerberos activity and increased resource consumption both by KDCs and members.

In any case, AuthN Policies are the only way to make TGT lifetime for computers and service accounts different from the domain-wide setting.

Scenario 4: Securing a legacy 3-tier application against Kerberoasting

Let’s say we have to maintain a 3-tier application (database backend – web-based middleware – web-based frontend). Because every tier must be load balanced, the database and the application pools all run with explicit AD identities, and for some reason we have to stick to legacy service accounts here – maybe the organization does not believe in gMSA, maybe the application needs the accounts to log interactively to some other component, who knows. In any case, a legacy service account is a potential Kerberoasting target, especially if it’s privileged somewhere. To make securing these principals all the more urgent, let’s assume that we need to support RC4 encryption for service tickets within this application. Microsoft patched away the default support for this in April 2026, but organizations in need of legacy behavior are still able to enable it, and the enablement is domain-wide (strictly speaking, it’s per Domain Controller, but you wouldn’t want to have different behavior between different DCs), so there you go.

Make no mistake – technically speaking, a computer account or a gMSA are also kerberoastable – however, since those objects have long and complex passwords, kerberoasting them is computationally infeasible in most cases. But this is a purely quantitative hurdle, not a qualitative one, so it may fall one day due to a technological breakthrough.

Kerberoasting has become so popular among pentesters and threat actors due to the fact that it is based on the default AD behavior of issuing a service ticket to any authenticated principal that requests it, effectively leaving it up to the targeted application to perform the necessary authorization. But a Kerberoasted account can be used anywhere, access rights permitting. In this scenario, we’ll use AuthN Policies to restrict both pre-Kerberoasting (requesting the service ticket) and post-Kerberoasting (using the cracked password to access resources in the environment). To achieve this, let’s model the legitimate usage of the three service accounts involved:

Service AccountNeeds to log on toService tickets can be requested byService tickets can be requested from
Frontend webservice
svc.app01.webfe		Frontend webserver nodes
G22-WF##		Anyone authorized to access the frontend
Frontend administrators		Any machine from where the frontend needs to be accessed or administered
Middleware webservice
svc.app01.mware		Middleware webserver nodes
G22-WM##		Frontend webservice account
Middleware administrators		Frontend webserver nodes
Middleware admin workstations
Backend database
svc.app01.sql		Database server instances (cluster nodes)
G22-DB##		Middleware webservice account
Database administrators		Middleware webserver nodes
Database admin workstations

Looks like a nice compact framework, doesn’t it? Let’s get to work! Here are the assets we need to secure:

The admin groups contain both the admin accounts and admin workstations as members. You could separate them further to target the policies even more precisely. We will not impose any limitations on the workstations from which the application’s frontend can be accessed, just on the users permitted to do so (by virtue of their membership in the APP01-Access group).

Note: Whatever you put in place to restrict who can request service tickets for a principal and from where, AuthN Policies will not help you restrict encryption protocols used in the process. This needs to be managed by setting msDS-SupportedEncryptionTypes on the service principal, the computer object(s) of the computers running the service, as well as the DefaultDomainSupportedEncTypes registry if you, for some reason, still require RC4.

Policy-based approach

Remember the question we asked earlier: Do I need to always have silos in the mix? Since the answer is no, let’s start by hardening our application by using just AuthN Policies.

The policy for the frontend service account is pretty straightforward:

The condition for service ticket issuance may look a bit goofy – why is one and the same group being listed twice? Blame it on ADAC not getting enough love from Microsoft! It becomes clearer if you open the condition for editing:

The grouping shown in the picture will be “forgotten” if you close and reopen the dialog – another ADAC quirk! You’re not getting it back, either However, if you count the parentheses, you will see that the condition wasn’t changed and the first two clauses are still grouped together! For the ultimate clarity, use PowerShell:

You do know all your groups by their SID, right? Just kidding. With complex conditions, there is no good way to maintain them visually, so you’re probably going to end up scripting them.

The policy for the middleware service looks pretty much the same, but here’s another neat trick for you: wherever you are expected to specify a condition for users or devices, you can supply actual user or computer names instead of groups in the MemberOfEach/MemberOfAny! So here, although we did put the middleware webfarm nodes in the APP01-Middleware group, we can also list them explicitly:

And of course, the policy for the SQL service account looks exactly the same, just with different groups for cluster nodes, admins, workstations and the service account (Middleware) allowed to request service tickets for SQL along with the DBAs, albeit from different device!

Silo-based approach

What could we gain from using silos in this scenario? We can certainly isolate the account logon as we did in Scenario 2 by assigning the “own” cluster nodes to the same silo as the service account. For service ticket issuance, we could address the “next-tier nodes” by their silo, but for admin workstations and, indeed, the admin accounts, we’d still have to rely on group memberships or other types of claims. Let’s look at those next.

Scenario 5: Using attribute-based Claims

In all previous scenarios we defined the scope of AuthN Policies by either silo assignment or group memberships. Depending on how your AD is managed, these may not be the best fit for restricting – or allowing – resource access. Let’s assume, for the sake of this example, that your identity management system is very good at governing work-related attributes of user objects like Job Title and Department but does not maintain group memberships based on where in the organizational chart the employee resides. If you need to restrict access to a certain group of computers to just the members of the Finance department, the classic User Rights Assignment policy can only help you so far because you cannot 100% rely on group membership of users or OU placement of computers. Enter AuthN Policy and attribute-based claims!

First, let’s create a claim based on the department attribute. Because our IDM is so good at managing the department attribute of user objects, we can safely pull the list of possible values for our claim directly from AD. Since that attribute, somewhat surprisingly, is not part of the Global Catalog by default, we have to query every domain in our forest:

$deptValues = New-Object System.Collections.Generic.HashSet[string]
foreach ($domain in (Get-ADForest).Domains) {
    Get-ADUser -LDAPFilter '(department=*)' -Server $domain -Properties department | 
    Select-Object -ExpandProperty department | 
    ForEach-Object {$null = $deptValues.Add($_)}
}

This gives us a list of unique values from which to create suggested values for our claim. To create the claim with these suggestions, we need to convert them to the correct AD Management type first:

$deptValuesAD = New-Object System.Collections.Generic.List[Microsoft.ActiveDirectory.Management.ADSuggestedValueEntry]
foreach ($val in $deptValues) {
    $deptValuesAD.Add([Microsoft.ActiveDirectory.Management.ADSuggestedValueEntry]::new($val, $val, $val))
}
$claimType = @{
    'AppliesToClasses' =  @('user','computer') 
    'DisplayName' = 'Department' 
    'SourceAttribute' = 'department' 
    'IsSingleValued' = $true 
    'SuggestedValues' = $deptValuesAD
    'ProtectedFromAccidentalDeletion' = $true
}
$claim = New-ADClaimType @claimType -PassThru

Et voilà! The new claim is ready to be used in AuthN Policies:

You could have created it manually in ADAC, of course, but then you’d have to type all your different departments. All that is left to do is create a policy with a computer restriction for users based on the “Department” claim we just created:

From now on, only users with “Finance” in the department attribute will be able to log on to those computers, or indeed, access any services running in the SYSTEM context of those computers. To create the policy using PowerShell, just run

$newPolicy = @{
    'Name' = 'Access to Finance Workstations'
    'ComputerAllowedToAuthenticateTo' = 'O:SYG:SYD:(XA;OICI;CR;;;WD;(@USER.{0} == "Finance"))' -f $claim.ID
    'Enforce' = $true
    'ProtectedFromAccidentalDeletion' = $true
}
New-ADAuthenticationPolicy @newPolicy

I bet you can imagine how we could streamline the previous scenario using claims, too! We could, for example, use one and the same policy for SQL backend and Middleware and just assign the relationships between user, workstation and the service principal using the following technique.

Another neat Claim-based trick

The following use case may sound artificially constructed at first, but I wanted to include the underlying functionality so that you can apply it to more realistic scenarios if you encounter them in your organization. Assuming we have a resource – a file share, a web application, a database – that needs to be widely accessible within the organization, but we want to prevent it from being accessed by stolen credentials from a wrong endpoint. For that, we maintain the department attribute for both computers and users, create a claim as shown above, and for the service ticket issuance we can now add a condition like this:

Everyone will still be able to access the resource, but only from computers in their own department! Think time log entry – if Mary works on the 75th floor, we don’t want her to stop at Jane’s computer on the 2nd and already officially start her workday before she trudges up all those stairs, do we? Just kidding, I wouldn’t stay for a second in a workplace that thinks along these lines…

The Authentication Silo claim type is also supported for this kind of comparison, and so is mixing different claim types – as long as the values can indeed be compared!

Design, Deployment and Troubleshooting

To start you off, here are three things that to always keep in mind when designing AuthN Policies:

  1. AuthN Policies do not change anything in authentication flows for which the policy evaluation succeeds, it’s the other relationships that are affected. Therefore, when engineering authentication, describe who is supposed to communicate with whom and then design your policies accordingly.
  2. Devices that cannot or will not participate in both FAST and claim-based authentication, cannot be used as a rule criterion and will fail every evaluation, be it by group membership, silo assignment, or claims – they are just an “unknown” to the KDC when it comes to policies.
  3. There is no superposition, no “Resulting Set of AuthN Policy”, nor a “Default AuthN Policy” – only one policy, or none at all, is always applied to a principal. If a silo is assigned, it’s the policy linked to the silo for this principal type (user, gMSA or computer). If no silo is assigned, it’s the policy explicitly assigned to the principal. It also bears repeating that for silo assignment to be in effect, the principal in question has to be both linked to the silo and a member of the silo!

Do not overengineer – even if you leave the “channels” slightly broader than they necessarily need to be, you have still improved your security posture where it matters most!

Remember that not only the actual policy tied to a silo overrides an explicit policy association to a user, gMSA or computer, but the enforcement setting of the silo will also override the enforcement setting of the policies of that silo! Remember that ADAC has different defaults for policies and silos?

Targeting users in AuthN Policies (in Computer logon restrictions and service ticket issuance) by their group memberships is totally fine. Targeting computers by groups may require rebooting them or waiting for the TGT lifetime to pass. At least, that has been my experience so far.

Learn working with Authentication Policies and Silos using PowerShell early. You will definitely need it if your forest has more than just one domain, but in any case, making sense of more complex conditions gets a lot easier in PowerShell – with the notable exception of groups being represented by their SIDs. This will teach you early on to work with attribute-based claims wherever it makes sense!

Where are the logs?

The logs to troubleshoot Authentication Policy evaluation are, unsurprisingly, in the Event Logs. Since policy evaluation only happens at KDC level, that’s where you need to look. You’ll find it under “Applications and Services Logs\Microsoft\Windows\Authentication”; however, the “AuthenticationPolicyFailures-DomainController” log is disabled by default and set to 1 MB maximum size which will cause it to roll over pretty quickly, especially if you start by deploying your AuthN Policies in Audit rather than Enforce mode (in Enforce mode, successful policy evaluation does not generate a log entry). To enable the log and increase the maximum file size, run the following PowerShell commands on your Domain Controllers:

$log = Get-WinEvent -ListLog 'Microsoft-Windows-Authentication/AuthenticationPolicyFailures-DomainController'
$log.IsEnabled = $true
$log.MaximumSizeInBytes = 200MB
$log.SaveChanges()

If you are suspecting that your problem is not in the policy framework itself but rather in Kerberos Armoring (FAST), enable advanced auditing for Kerberos authentication and ticket events, including failure (success audit is enabled by default on modern Windows Server versions). There are no specific events for FAST negotiations or claims, but Event 4768 and 4769 contain information that will help you get to the heart of the matter.

Linux in the AuthN Policy framework

If you are using Active Directory Kerberos on Linux systems, you can benefit from AuthN Policies too, at least to some extent. If all your Linux machine does is validate service tickets using a keytab file (this can also be the case for a Tomcat server running on Windows, since Java uses its own Kerberos implementation), then you can limit the service ticket issuance for that service principal, just as we did in Scenario 4. The Linux computer itself does not actively participate in the well-engineered authentication framework, but it will benefit from it.

Supporting a Linux Kerberos client is a different story altogether. At the time of writing, the SSSD daemon supports FAST but not the claims extension in the ticket PAC so that a Linux device joined to AD will not supply the claims needed for AuthN Policy evaluation.

I hope you found this useful. If you have another good usage scenario for AuthN Policies that you think would be worth including here, hit me up on LinkedIn or BlueSky, and let’s talk!