๐ Secure Bits ๐ก
๐๐๐๐ต๐ฒ๐ป๐๐ถ๐ฐ๐ฎ๐๐ถ๐ผ๐ป ๐ฃ๐ผ๐น๐ถ๐ฐ๐ ๐ฆ๐ถ๐น๐ผ๐. ๐ช๐ต๐?
So, by now you know how Kerberos works, you understand Kerberoasting, and youโve seen how Authentication Policies can help.
Letโs talk about the next layer: ๐๐๐๐ต๐ฒ๐ป๐๐ถ๐ฐ๐ฎ๐๐ถ๐ผ๐ป ๐ฃ๐ผ๐น๐ถ๐ฐ๐ ๐ฆ๐ถ๐น๐ผ๐.
Silos are essentially ๐ฐ๐ผ๐ป๐๐ฎ๐ถ๐ป๐ฒ๐ฟ๐ ๐ณ๐ผ๐ฟ ๐๐๐ฒ๐ฟ, ๐ฐ๐ผ๐บ๐ฝ๐๐๐ฒ๐ฟ, ๐ฎ๐ป๐ฑ ๐๐ฒ๐ฟ๐๐ถ๐ฐ๐ฒ ๐ฎ๐ฐ๐ฐ๐ผ๐๐ป๐๐. You link them to an Authentication Policy, and everyone inside follows the rules of that policy (or more policies).
Why not to use just the Authentication Policy ?
You ๐ฐ๐ฎ๐ปโ๐ ๐ฎ๐ฝ๐ฝ๐น๐ ๐ฎ๐ป ๐๐๐๐ต๐ฒ๐ป๐๐ถ๐ฐ๐ฎ๐๐ถ๐ผ๐ป ๐ฃ๐ผ๐น๐ถ๐ฐ๐ ๐๐ผ ๐ฎ ๐ด๐ฟ๐ผ๐๐ฝ. So the silo acts like your grouping mechanism. Thatโs it. A workaround with a fancy name.
๐ฆ๐ผ, ๐ต๐ผ๐ ๐ฑ๐ผ๐ฒ๐ ๐ถ๐ ๐๐ผ๐ฟ๐ธ?
โ
You create a Silo
โ
You link your Authentication Policy to it
โ
You add accounts manually
โ
You must also assign the silo to each accountโs Silo tab in ADAC (Active Directory Administrative Center).
Double assignment. Why? I have no idea. If you do, let me know.
๐ง๐ผ ๐๐ฒ๐ ๐๐ต๐ถ๐ ๐๐ฝ:
1๏ธโฃ Create the Authentication Policy
โช๏ธ Skip assigning accounts for now
โช๏ธ Define your conditions โ e.g., User.AuthenticationSilo Equals “T0-Silo”
โช๏ธ Set rules for sign-on, ticket lifetimes, etc.
2๏ธโฃ Create the Silo
โช๏ธ Add permitted accounts
โช๏ธ Attach the Authentication Policy
3๏ธโฃ Assign the Silo to each account via ADAC
โ ๏ธ You may need to reboot your Domain Controllers afterward. I always did.
๐๐ ๐ถ๐ ๐๐ผ๐ฟ๐๐ต ๐ถ๐?
Sometimes. It brings structure and better control. But in many of my cases, it felt like an unnecessary step โ especially in simpler environments.
Have you used Authentication Policy Silos? Was it helpful, or just added complexity?
