Authentication Policy Silos.
What's the situation here?
Well,
I like to look at authentication policy silos in some ways as
an extension of the protected users group.
Remember with protected users, there is this collection of preconfigured,
non‑configurable security protections.
One I forgot to mention is that you can,
well, you can't configure it,
but there is a reduced Kerberos ticket lifetime if
you're in the protected users group.
The silos,
the authentication policies and their silos allow you to
configure your own timeouts for Kerberos,
and you can adjust protocols, authentication protocols,
and most particularly, you can control access between domain users and groups,
computer accounts, service accounts, and machines.
So let me explain, first of all, the relationship is one‑to‑many,
that is you have individual authentication policies and notice that you can
group these policies together into what are called silos.
And then in turn, you can associate a silo with a user account,
a group account, a computer account, a service account.
What's in the policies?
Well, first of all,
I just want to call out the fact here that you may have different silos
that group different collections of identities and have different types
of access and configuration and so on.
I want you to see here that single policies can belong to
more than one silo and different policies can contain
different groupings of users, groups, managed service accounts,
and computers.
So there is this parent/child relationship between the silo and the policy.
You can deploy policies individually,
but Microsoft's proven practice is similarly to how it's
easier to manage a group rather than control or give access
to individual user accounts.
It's going to be easier for you to give and restrict access at the silo level by
just modularly patching in and removing policy references,
instead of trying to directly attach policies.
Alright?
Now, if we look over on the right‑hand side,
I've given an example of an authentication policy silo in action.
For example,
we may have a policy in a silo that says that only members of a
particular Active Directory group are allowed to sign in to either
the secure1 server and the paw1 workstation.
PAW stands for privileged access workstation.
So these are higher security machines that you really need
to control who can sign into them such.
You know,
you might be accustomed to that concept of if you're a domain administrator,
you normally can sign into any domain system,
whether it's a server or a workstation.
Well,
authentication policy silos allow you to put a greater degree of
control such that even if you're a domain administrator,
in this case,
if you're not part of that silo that grants you access to secure1 and paw1,
you're not going to be able to sign in.
So it's quite powerful indeed,
particularly for a security compliance where you have machines that really
have especially strict security and access requirements.
So in this example,
notice that a user account may be blocked when they try to sign in
to either secure1 or paw1 because they're not a member of the group
that is attached to a particular silo.
Okay?
So this same pattern applies not only to Active Directory users and groups,
but also to your group managed service accounts.
In this way, using silos,
you can very granularly specify which systems a particular GMSA can
use and all else it would not be allowed to be used.
Again, this would be nice from a containment standpoint if a malicious user, process, or entity were to compromise a GMSA.