Tier Access Controls: Authentication Policies and Silos

Posted on Updated on by ChrisCategories:Uncategorized

I suppose the very first thing we should cover is what “authentication policies and silos” are, and how they can help us.

At it’s simplest, this functionality was introduced by Microsoft starting with Server 2012 R2. The purpose was to give a bit of a bump to Kerberos account protections by adding the ability for AD to process claims. These claims can be applied to groups of users and be used to limit where those accounts are permitted to authenticate from. That last component is key here, as this is not a mechanism to prevent accounts from being used from a workstation or server, it can only prevent authentication from specific systems. To put it more simply, this will not enable you to prevent someone creating a credential object in PowerShell, or using an account with RDP to access another system from a front-line workstation, as the actual authentication occurs at the remote endpoint. Even then, if the account can fall back to NTLM, which doesn’t support Kerberos claims, then this protection fails to apply. If you want to learn more about all the nitty gritty details, I recommend reading the Microsoft documentation on the topic (https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/authentication-policies-and-authentication-policy-silos), as this article is more about the deployment and configuration.

The other key piece to really understand about auth silos, is that they have nothing to do with controlling access to the systems. The access control still comes for rights assignments in GPOs and membership on local systems. If a user is a member of Domain Admins, and Domain Admins is still set up with the default access, then Domain Admins has access to every system in the domain. The auth silo doesn’t take away this access, it only negates the ability to log in interactively on the systems it applies to. So what does that mean?

In the scenario above, where you are a DA, and DAs have access to all systems, but you’ve put in a auth policy to prevent DAs from logging in to desktops. If you try to log in directly, via RDP, or WinRM, your authentication will be rejected. If, on the other hand, you are querying WMI, or you are connecting the Computer Management MMC to the workstation, this will generally work because you have the required rights, and the login type isn’t one of the ones protected by auth policies. If you want a given group to have no access at all, then you have to use rights assignment GPO settings, which can be tricky if you don’t have a comprehensive set of use cases and associated tests.

Now that we all hopefully have a clearer picture of what we can, and cannot do, with auth policies and silos, let’s dive in.

Step 1: Enabling

Before we can effectively deploy our new protective measures, there are a few things we need to knock out, such as turning on the functionality in the first place. This is accomplished with two Group Policy settings; one applied to Domain Controllers, and the other applied to your client systems and servers.

The first setting should be set on your domain controllers container, and it’s purpose is to tell the DCs that they should tell clients whether or not claims are supported. While you can theoretically make this change within the Default Domain Controllers Policy, as a best practice you should really have a second policy in which changes are made. The setting can be found in Computer Configuration -> Policies -> Administrative Templates -> System -> KDC, and the entry we will be configuring is ‘KDC support for claims, compound authentication and Kerberos armoring’. Within this setting, we can choose one of four options:

  • Not Supported – Keep your dirty claims to yourself
  • Supported – If you feel like sending claims, we can process them
  • Always provide claims – You didn’t ask for claims? Too bad, here’s your claims anyway
  • Fail unarmored authentication request – You will take these claims and protect them with your miserable life or you will not be allowed to play here

I should note here that using the last two options does require a 2012 domain and forest functional level. Windows Server 2008 R2 (oh gods why are these still around?) can support claims as a client, but it cannot support full armoring, so setting either of the last two has the net effect of ‘Supported’ for those systems. My recommendation is to use either Supported, if you have a lot of legacy systems, or Always provide. If all of your systems are running on the latest and greatest, you might be able to get away with failing unarmored requests. That said, if you have non-Windows systems that are binding to your domain via Kerberos, you will have to modify their configurations to enable armoring behaviors. Things also get a bit trickier if you are binding with Kerberos over LDAP, which is just silly in my opinion. If your systems support a Kerberos bind, then just use Kerberos directly and call it a day, but I digress. If a client is purely LDAP, meaning that the system is not using Kerberos for auth at all, then they will be unaffected by these settings, unless you fully disable down-level auth types.

The second setting needs to apply to all clients in your domain, and would typically be set in a policy connected to the root of the domain. As with the last setting, while you technically can set this value within the Default Domain Policy, you should really consider not doing that. This setting is also found in Computer Configuration -> Policies -> Administrative Templates -> System, but this time in the Kerberos section instead of the KDC. The entry being configured this time is ‘Kerberos client support for claims, compound authentication and Kerberos armoring’. There are fewer options for this setting, amounting to basically on, off, or whatever (not configured). This setting should be set to Enabled to achieve the desired effect, which is to have your clients request claims and to armor their Kerberos requests. Again, this setting will only impact your Windows clients, so you will need to update other Kerberos systems manually.

Step 2: Organizing and Tagging

The next step begins with identifying all of our systems and users in terms of who should be permitted to log on where. In my personal opinion, this is where the ‘Tiering’ piece comes into play in the form of top-level OUs to reflect your Tiers. I am fully aware that some people prefer a flatter model that just as an Admins OU, but I maintain that those people should consider re-examining that approach. While many maintain that any ability to set object values makes an account Tier 0, and therefore all admins are of a kind, that ideology doesn’t work in the real world. Desktop support and helpdesk have to access client systems to elevate installs or fix systems, but they also need the ability to reset passwords and modify groups. The biggest driver for treating all accounts like Tier 0 is usually because those same people are often asked to manage satellite servers, or perform other tasks that might require additional rights provided by a built-in group. To this, I say horse puckey! Just about anything can be delegated, and while it may mean you have to hire a few more people, people should have clearly defined job descriptions and matching rights assignments…stop providing rainy day access!

Sorry…getting back on track now. Where were we? Ah yes, organizing.

My own approach, as indicated above, is to have three top-level OUs that represent each Tier, plus the Domain Controllers container. How you organize underneath this is functionally up to you, but with the right structure in place, you can be more specific with your claims, as well as making it easier to see the items that are out of line. For this reason, I tend to split objects out into what I call focus areas next. For my own models, this usually means a dedicated container for privileged objects (ADM), another for server objects (SRV), and one for unprivileged objects (STD) within each Tier. From this point, you can get more granular, or you can keep things at this level depending on the administrative scoping your organization requires. I’ll go into my own personal approach in another post at some point, but it isn’t really relevant for this one. Once you have your structure set up, organize your objects into it, for which I recommend the following rules:

  • Tier 2 – Should typically include all of your workstations, all your standard user accounts, any non-privileged groups specific to the user side of things, and accounts used by admins to administer these objects
  • Tier 1 – Servers, service accounts used by servers (for specific apps, or functions), accounts used by admins to administer servers
  • Tier 0 – Domain Controllers, PKI, identity provisioning servers, cloud identity sync servers, and any accounts with power over these systems (which includes having the ability to create and link GPOs, unless you have limited the link points)

One quick note here on the tags. While Domain Controllers are, without question, Tier 0, there is no need to tag them as such. Partly this is because they are automatically placed in a dedicated container that sets them apart. The other reason is that I’ll be providing some automation steps later where we will leverage these tags, and your Domain Controllers should generally not have auth silos applied to them, unless done in a very precise manner.

You will undoubtedly find at this point, that you have a TON of service accounts and users either directly or indirectly in Administrators, Domain Admins, Account Operators, Server Operators, etc. I’m afraid that, if you truly want to protect your Tier 0 accounts, you’re going to have to put on your big kid pants and do some housework. In the vast majority of these cases, service accounts or users are added to these groups as a matter of convenience, and to ensure that certain groups can always access systems. It’s lazy, particularly because there is no reason for it when you have Group Policy Preferences, which can also take advantage of the tagging we will discuss today (sigh…yet another blog I need to write lol). Point is, clean this up and get down to as few as possible. Use delegation or other means to provide access. For anything that will still “need” Domain Admins once you are done, you will want to push those teams to figure out how to use multiple accounts; one for the Tier 0 assets, and one for everything else.

A brief note on this organization effort. Technically speaking, it is not necessary to move the objects into a Tier structure in order to benefit from this approach. It is entirely possible to achieve the same results by simply categorizing everything on paper, so to speak, and then use that for your tagging. If you want to go this route, my recommendation is still to leverage OUs rather than devices. Create a child OU for your high-privilege devices, or designate a given OU as high-privilege only. The reasoning behind this is simple…I am a lazy administrator and, if you are reading this blog, you probably are too. That means you don’t want to work harder than necessary, because you have more than enough on your plate already. If you use object specific associations, you will inevitably fall behind, and all your efforts will be wasted. If you designate specific OUs however, then it becomes easy to script tag deployments and have it run a few times a day to ensure tags are there. If you do it by object however, and you miss adding one, it ends up untagged and then people won’t be able to log into it.

Now that everything is organized and cleaned up, it’s time to actually tag the objects. I personally like apply these tags to all users, groups, and devices. This lets me quickly verify if all objects are in the right places, and it makes it easier to keep everything nice and neat. We want to avoid using things like the extension attributes, or even any of the semi-common attributes for this purpose. This is because we don’t want these attributes syncing, though you may also wish to use these attributes to control sync scopes. If your goal, like mine, is to tag everything, then you ideally want to select an attribute that is common to all object types, such as adminDescription, adminDisplayName, url, or wWWHomePage. If all you need is to control login access however, you only need to worry about devices and users, which gives you many more options. My personal preference here is to extend the schema to create new attributes dedicated for this purpose, but I know a lot of people are scared of making schema extensions for fear they will break something. I can assure you that, if done with care and intent (i.e., you read the MS guidance), there will be no issues with extending the schema. If you are using both the Tier and the Focus types, you will want at least two attributes; one to hold the Tier number (0, 1, 2), and one to hold the focus type (ADM, SRV, STD).

Now that you have selected attributes and identified all your objects, you can apply the values to your objects as appropriate for your situation. For this article, we’ll go ahead and stick with adminDisplayName for Focus, and adminDescription for Tier.

Step 3: Claim Types

The next step has to be done in either PowerShell or in the Active Directory Administrative Center (ADAC), as none of the legacy MMC consoles were updated to deal with this functionality. While I’m generally one to go straight to PowerShell for this kind of thing, we’ll stick with ADAC for the moment.

Open up ADAC and you should see options on the left side, one of which should be Authentication, which can be expanded to find Authentication Policies:

If we were to try and define a new Authentication Policy now, we would find that the only conditions we can specify for a user is the assigned authentication silo, or group membership. While something like Group Membership might work, if that’s all we cared about, we want to protect all accounts designated as Tier 0, which may include accounts that aren’t members of a common group. Since we want to leverage attribute values to manage our access, we’ll need to add some new claims options. This can be done by expanding ‘Dynamic Access Control’, and then navigating to ‘Claim Types’, where you will see the single item ‘AuthenticationSilo’. You can either right-click in some blank space in the middle section to access the New -> Claim Type option, or you can use the same items in the task pane on the right side of the window.

As you can see, I’ve already added the values, but I’ll walk through the creation process again.

Once you’ve got the new Claim Type window open, the first thing you will see is a list of all the available attributes within AD. Since we are using adminDescription for the Tier, go ahead and select that attribute. While you can modify the display name, my recommendation is to leave this be, though we do want to ensure that both Computer and User are enabled. The last piece we’ll need to set is the Suggested Values, as this makes it easier for users to avoid misconfigurations. Make sure you have selected ‘The following values are suggested’, and then click ‘Add’. For the value, use 0, but for the display name, use ‘Tier 0’. Setting the description is technically optional. Go ahead and add the other two Tier entries, using 1 and 2 for the values respectively for each. Even if you don’t plan to use these right now, adding them now just makes things easier later.

If you are using the Focus construct as well, go ahead and add that attribute, along with the appropriate suggested values and display names. Don’t forget to enable for both computers and users.

Step 4: Policies

Once your new claim options have been defined, you’re ready to go back to setting up your Authentication Policy. I recommend using a strong naming convention here that avoids ambiguity. Make sure the convention is documented and accounts for extension scenarios in the future. I also strongly recommend setting a meaningful description, as well as initially setting the policy to audit mode, rather than enforce. This will enable you to identify gaps that may adversely impact logins without preventing functionality. For the moment, don’t worry about specifying accounts, unless you merely want to add a specific system and user only for testing. Again, we want to put all of our policies into Audit mode first, and verify the behavior for different users in different scenarios via the event logs before switching to enforce mode.

PLEASE ensure that you test using this method when applying to your production environment, even if you already tested everything in a lab first. Applying these values incorrectly can break logins for your environment.

The next set of will be slightly different, depending on the specific outcomes you are trying to achieve.

Restricting User Logon Only

The first policy we will define will be just for restricting user logins for our Tier 0 designated users and service accounts. This will limit the users we specify, without applying any other restrictions to the computers. To put this another way, our Tier 0 users will only be able to log in to systems added to the silo however, other users that are granted login rights will also be able to log into the systems because we will not be applying restrictions to the systems. For those just wanting to dip their toes, this is a viable approach to test out the waters before jumping in with both feet. That said, if you have users from different access tiers using the same systems as your Tier 0 admins, you should know that this won’t be an effective control, as a compromise of the lower tier account will still provide a path to environment takeover. If all you want is to “check the box” for control of T0 logins though, this will work.

In the User Sign On section, you will want to click the ‘Edit’ button for the conditions section. In the resulting window, you will click the ‘Add a condition’ link in the lower left corner.

From here, you can select from various dropdowns to achieve your desired filtering approach. If you are going for the user restriction only, and are only concerned about specific groups, such as Domain Admins, Enterprise Admins, and Administrators, then you can use Group, Member of any, and Value. For the last field, you will click the ‘Add items’ button and search for the first group (e.g., Domain Admins), then click OK. Repeat this process for each group you want to control logon for. Once all groups have been added, click OK to close the filter window, then save your policy and close the edit window.

If you are wanting to protect a bit more than simply the members of a group, but still don’t want to mess with applying restrictions to the systems, you can alternatively use the adminDescription with a value set to the Tier tag of your choice here. This avoids having to keep up with group memberships just to ensure the desired behavior.

Once your policy is good to go, you can skip the next couple of scenario subsections and go to step 5.

Protecting User and System Logon

If you want to get the best mileage out of this option, then you will want to protect logon from both sides of the equation. This means that, not only do you want to limit which systems a particular user can log into, but also who else is permitted to log into the same systems as your highly privileged users. If you have users performing interactive logons to Tier 0 systems, then those users are, by definition, Tier 0, even if they don’t have admin rights on said system. In my Tiering implementation engagements, this rule is inviolate; To perform interactive logins, remote management, or any server interaction other than consuming hosted services, the account must be from the same tier as the system. I’d note also that, while general guidance may be that administering down tier is permissible, I politely, but firmly, disagree. The only times that cross-tier administration should occur is when you are using your ‘gold/red’ card access to implement or modify access controls or modify forest or domain level settings that are not delegated (i.e., schema modifications, authorizing DHCP servers, etc.).

A few words of caution here, before we move on.

  1. Do NOT apply this policy to your DCs; It will prevent all users from logging into the domain (we’ll address this further down)
  2. When we apply our restrictions to the system, it means that any account that performs one of the supported login types will be affected, so ensure that ALL accounts that will be permitted to log in are tagged with Tier 0
  3. As with permitting lower tier users to log into upper tier systems, use of ‘global’ service accounts instead of separate ones for at least T0 means you aren’t solving your exposure issue, just reducing it

For this scenario, we will be setting conditions for both the users and the systems. The reason for this is that we want to take advantage of one of the features of Kerberos armoring and Flexible Authentication Secure Tunneling (FAST), which is compound authentication. Compound authentication essentially enables both a user and a computer to be used as parts of the Kerberos Ticket-Granting Service (TGS) request. The net effect is that we will be able to restrict access from both sides of the equation. Users that are designated as Tier 0 will only be permitted to log on to similarly tagged systems, and Tier 0 systems will only permit users to log in if they are supposed to be accessing Tier 0 systems.

As with the scenario above, we will start by clicking the ‘Edit’ button in the User Sign On section. This will pop up a new window, where we’ll want to click on ‘Add a condition’, which will result in the below view. Where we will differ this time is that, instead of using group membership, we will leverage our custom claims. As shown in the screen shot below, this means we will be using the adminDescription option, Equals, Value, and we will then want to select Tier 0 from the list of options before clicking OK.

I recommend completing these steps for the Service Tickets for User Accounts, Service Sign On, and Service Tickets for Service Accounts, with one adjustment. In addition to the adminDescription being set to Tier 0, I recommend adding a Group condition where the user is a member of a non-interactive service accounts group. While interactive use is all well and good for some service accounts in lower tiers, it is my firm belief that this should never be the case for Tier 0 service accounts. I don’t care if the vendor insists that it’s necessary, I can assure you with extreme amounts of confidence from years of proving them wrong that they are decidedly, and universally, wrong. If you at some point encounter a product that things can’t be made to work without interactive use of the service account, then my recommendation is to never let that product touch Tier 0.

Below is a screen shot depicting my set of test policy settings, based on the above guidance.

The final section is the Computer settings, which is where we will dynamically enforce matching tier values for login. To accomplish this, we will add three conditions.

  • User adminDescription Equals Value of Tier 0
  • AND
  • Device adminDescription Equals Value of Tier 0 OR Device Group Member of each value of Domain Controllers

The two device filters should be grouped together. This can be accomplished by clicking the ‘Manage grouping’ button, selecting the two device filters, and clicking the ‘Group’ button.

You may find yourself asking at this point “Why use attributes instead of group memberships?”, and the answer to that question is mostly about familiarity. Threat actors are very practiced at finding key group memberships and using them to trace access paths. If all users that log onto a system have a common group, and you want onto said system, then you find a way to get into that group. Groups are a commonly leveraged mechanism, so analysis in this regard is very mature in terms of discoverability. Use of an attribute, on the other hand, is a lot less common, as is the use of Auth Silos, meaning that the tools and scanning processes aren’t necessarily going to immediately reveal the required steps to take.

Admittedly, this is a little bit of a security through obscurity approach as all we are really accomplishing with this is maybe slowing them down a bit. Anything that gives you more time to detect threat actors has value in my opinion however. If you also happen to monitor for accounts lacking tags, or tags that show up under the wrong OU structure, they’re far more likely to give themselves away using the most common tactics. If you want to increase the security a bit however, then I would go back to recommending a custom schema extension. This will enable you to apply some supplemental controls, such as making the attribute confidential and restricting access to read or modify it. If you ensure it’s sufficiently restricted (self read, as well as Enterprise DCs, DA/EA, and maybe your provisioning tool for modify), then the ability to infiltrate the environment gets much harder. The trade off, of course, is that you would not want to delegate the ability to create objects in the directory. Every user and computer would need the value set, and that means limiting where those objects can be introduced from (something you should really be doing anyway).

Domain Controllers

As mentioned above, you theoretically don’t want to apply auth policies to the DCs, as it runs the risk of preventing domain logins. That said, there is some possible benefit to limiting logins as a whole to user accounts that have been appropriately tagged. In this scenario, we can apply a policy that requires that users be tagged with any of the available Tiers by specifying ‘Any of’ instead of ‘Equals’ and then selecting all three tier values. To be extra thorough here, we would also add a device policy that would look for the same thing. The user filter would be specified on each of the user-based filters.

The net effective of this policy, when applied in a silo specific to the DCs and all users, is that a given user would only be able to log in to the domain if they were properly tagged.

NOTE: I have only previously deployed this configuration in small lab environments as most prior customers opted to skip this particular control because they did not want to lock down account creation, and didn’t want issues popping up if someone forget to set the value. While everything worked as expected in my small lab, make sure you thoroughly test this in audit mode before enforcing it!

Step 5: Silos

The next step in the process is to create the actual Silo, which we’ll do by navigating to the ‘Authentication Policy Silos’ section and, either selecting ‘New’ from the task pane, or right-clicking in the middle. This will bring up the now familiar window for editing. Once again, we will to specify a name, as well as to determine whether the silo will be enforced or only audited. In our case, we will again skip by the Permitted Accounts for the moment and instead configure the Authentication Policy. Since we only have one policy that will apply to this silo, we’ll select that option and then use the drop-down to select the policy we created in the prior step.

If you created separate policies for users vs managed service accounts or computer accounts, then you can select the separate option and specify each policy. In my opinion, using separate policies isn’t really helpful, as it creates more overhead without providing any real benefits that I’ve been able to identify.

Step 6: Assignments

On of the potential drawbacks of this approach, and the one that makes most people believe it’s not scalable, is the fact that policies can’t just be pointed at an OU like a GPO, or tied to a group. The users and systems that the auth silo will affect has to be set directly. Fortunately for you, I’m a huge fan of automation, and I would never leave you in the lurch here. 

#requires -Module ActiveDirectory
function Register-ADAuthSiloTargets {
    [PsCmdletBinding()]
    param(
        [Parameter(Mandatory)]
        [string]$SiloName,
        [Parameter()]
        [string]$TargetAttribute = "adminDescription",
        [Parameter()]
        [ValidateRange(0, 2)]
        [int]$TargetTier = 0
    )

    try {
        $silo = Get-ADAuthenticationPolicySilo -Identity $SiloName -ErrorAction Stop
    } catch {
        Write-Error "AuthSilo '$SiloName' not found."
        return
    }

    if($silo){
        try {
            $targets = Get-ADUser -Filter { $TargetAttribute -like "*$SiloName*" } -Properties $TargetAttribute -ErrorAction Stop
            $targets += Get-ADComputer -Filter { $TargetAttribute -like "*$SiloName*" } -Properties $TargetAttribute -ErrorAction Stop
        }
        catch {
            Write-Error "Error retrieving targets using attribute '$TargetAttribute' and value '$TargetTier'."
            return
        }
    }

    if($targets){
        $targets | Grant-ADAuthenticationPolicySiloAccess -Identity $SiloName -ErrorAction Stop
    }
}

The above function is fairly simple and, I believe, straight forward, but we’ll go through it anyway.

The very first thing we are doing is setting a Requires because we will depend on the Active Directory module for the commands we are running.

The parameters are relatively simple as well, in that we are looking for the name of the silo to assign the objects to, the attribute we are leveraging, and the tier value that we want to include. Since we’ve been using adminDescription for this article, I’ve set that as the default value.

The first real action we will take is to try and retrieve the silo using the name specified. When I get some time, I’ll convert this to a dynamic parameter that auto-retrieves the values and supports tab completion, but for now, you’ll have to look it up. Worst case, you can run ‘Get-ADAuthenticationPolicySilo -Filter *’ to return all available policies.

The next step, provided we have a valid silo, is to retrieve all user and computer objects with the attribute and value we are looking for. In theory, we could have used Get-ADObject to simplify our query here, however this returns an object that isn’t accepted by the Grant cmdlet via pipeline, likely because it was set to expect specific classes of object, rather than just any object with the right property name it needed.

The last step is to take our targets, if any, and use the pipeline to add the objects to the silo.

Conclusion

In this article, we spent some time going over some tier practices that I tend to leverage. In my normal deployments, I will generally include additional filters in my policies that accounts for additional attributes like the Focus. This usually involves setting up servers to prevent login unless the account is tagged for both the correct tier, and as an ADM focus account. This ensures that regular users aren’t signing into servers. This obviously gets shifted a bit for Tier 2 servers, where users are expected to sign in using their standard accounts, but this practice should be limited to things like RDS or Citrix hosts, which should be categorized as Tier 2, while the management plane systems are categorized as Tier 1. In cases where users have a viable reason to log into a Tier 1 server, I believe they should get a Tier 1 specific account that, if it won’t have admin rights (and it shouldn’t), is tagged as STD. I’m not a fan of this particular pattern, as I feel it weakens the overall security posture of the environment by requiring a loosening of things like the auth policies, but it has been a requirement in the past.

I would encourage you to play with the Claim Types as well. While we only covered some relatively narrow use cases here, it’s entirely possible to do a great many other things. For example, you could leverage the canonicalName or distinguishedName properties, without a suggested value, and ensure that users or systems are in specific locations within your structure. Using this with a ‘Contains each of’ should allow you to look for something that contains the correct path, such as a particular application group. Personally I am not a fan of tying things to the structure beyond a framework level, as this means objects may have to be moved around to ensure the desired behavior, and use of locations doesn’t allow for more complex needs. For example, if you wanted both the DBA team and an app team to have access to a particular DB server. If you are trying to allow access based on location, it won’t work because you either have to allow your DBAs to potentially access your app server (if using app OU), or your app teams potential access to your DB servers (if using a functional OU). Attributes, especially if using multi-value attributes, are a much better fit here, as I can keep all my servers in one place (unless they need different GPOs), and still dynamically control access using a combination of Policy Preferences and Auth Silos.

Chris