Add AD FS server and configuration database server as Tier Zero

TierZeroTable.json

@@ -878,7 +878,7 @@
     "AdminSDHolder Protected": "NO",
     "Episode": "Community contribution",
     "References": "https://cloud.google.com/blog/topics/threat-intelligence/defending-vsphere-from-unc3944\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/vsphere-active-directory-integration-risks\r\nhttps://knowledge.broadcom.com/external/article/314324/removal-of-integrated-windows-authentica.html\r\nhttps://knowledge.broadcom.com/external/article/433065"
-   },
+  },
   {
     "Asset": "Microsoft Entra Cloud Sync Provisioning Agent Server",
     "Category": "Computer host",
@@ -926,5 +926,37 @@
     "AdminSDHolder Protected": "N/A",
     "Episode": "Community contribution",
     "References": "https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference#directory-synchronization-accounts\r\nhttps://medium.com/tenable-techblog/stealthy-persistence-with-directory-synchronization-accounts-role-in-entra-id-63e56ce5871b\r\nhttps://www.tenable.com/blog/despite-recent-security-hardening-entra-id-synchronization-feature-remains-open-for-abuse\r\nhttps://www.mnemonic.io/resources/blog/deep-dive-into-the-entra-connect-sync-api/"
+  },
+  {
+    "Asset": "AD FS Server",
+    "Category": "Computer host",
+    "Platform": "Active Directory",
+    "Identification": "Not applicable - Not represented as an object. Identify by locating hosts running the Active Directory Federation Services role.",
+    "Description": "AD FS issues SAML/WS-Fed/OAuth tokens so users can authenticate to federated relying parties, commonly including Microsoft Entra ID when an org federates instead of using password hash sync. For the automatically generated, AD FS-managed token-signing certificate, the private key is decrypted at runtime in the AD FS process and, in the default configuration (WID), the configuration database that stores it encrypted is otherwise readable only in the AD FS service account's own context. A custom certificate instead stores its private key through the certificate store or an HSM, which does not follow this path.",
+    "Tier Zero Default Risk": "NO",
+    "Tier Zero Config Risk": "YES - Takeover",
+    "Tier Zero": "IT DEPENDS",
+    "Rationale": "Microsoft's AD DS tier model lists AD FS by name under Tier 0. A domain controller holds every credential in the domain no matter how you configure it, so it is always Tier Zero. An AD FS server is Tier Zero only if Entra ID is federated through it, if a relying party trust grants access equivalent to a Tier Zero principal, or if the AD FS service account is a member of Key Admins or Enterprise Key Admins, which on-premises Windows Hello for Business Key Trust deployments require.\r\n\r\nAn attacker with admin access to the server can dump the token-signing key from process memory, or act in the AD FS service account's context to pull the Distributed Key Manager key from AD and decrypt the key stored in the configuration database. With that key, the attacker can mint a Golden SAML token and impersonate any user with any claims against every relying party AD FS trusts. The forged tokens are generated offline and never touch AD FS again, so they do not appear in its logs.\r\n\r\nKey Admins and Enterprise Key Admins are themselves on Microsoft's protected accounts and groups list, the same list Domain Admins, Account Operators, and every other AdminSDHolder-protected group in this table is on. Membership in Key Admins gives a second, independent Tier Zero condition for that same reason, not because of what it can reach: it is a protected group, and control over the AD FS service account means control over a member of one. If none of the three conditions above apply, AD FS is not a Tier Zero security dependency.",
+    "Cypher": "N/A - Not identifiable via BloodHound collection alone. Cross-reference server inventories/CMDB against hosts running the AD FS role, and check AD FS service account membership in Key Admins/Enterprise Key Admins.",
+    "Microsoft PAS Role": "NO",
+    "AdminSDHolder Protected": "N/A",
+    "Episode": "Community contribution",
+    "References": "https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/tier-model\r\nhttps://github.com/mandiant/ADFSDump\r\nhttps://www.cisa.gov/news-events/cybersecurity-advisories/aa21-008a\r\nhttps://www.hunters.security/en/blog/adfs-threat-hunting-2-golden-saml\r\nhttps://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/deploy/on-premises-key-trust-adfs#add-the-ad-fs-service-account-to-the-key-admins-group\r\nhttps://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-c--protected-accounts-and-groups-in-active-directory"
+  },
+  {
+    "Asset": "AD FS Configuration Database Server (SQL Server)",
+    "Category": "Computer host",
+    "Platform": "Active Directory",
+    "Identification": "Not applicable - Not represented as an object. Identify by locating the SQL Server instance hosting an AD FS farm's configuration database. Only present when a farm uses a SQL Server backend instead of the default Windows Internal Database (WID); optional at any farm size, but required once a farm exceeds WID's limits (100 relying party trusts or 30 nodes).",
+    "Description": "AD FS farms can use a dedicated SQL Server instance for the configuration database instead of the default, locally hosted WID, for high availability, SAML artifact resolution, or token replay detection, none of which WID supports. Farms over 100 relying party trusts or 30 nodes require SQL Server, since WID cannot support them at that scale. For the automatically generated, AD FS-managed certificate, the database stores its token-signing private key encrypted with a key from the Distributed Key Manager container in Active Directory; a custom certificate's private key lives in the certificate store or an HSM instead.",
+    "Tier Zero Default Risk": "NO",
+    "Tier Zero Config Risk": "YES - Takeover",
+    "Tier Zero": "IT DEPENDS",
+    "Rationale": "Most AD FS farms run on WID, which is local to the AD FS server and readable only in the AD FS service account's own context, so this asset does not exist in most deployments. Where a farm uses a full SQL Server backend instead, sysadmin or db_owner access exposes the encrypted token-signing key blob to the SQL Server's own admin population, typically broader than the AD FS host's local admins. That access alone cannot forge tokens, since the Distributed Key Manager key from AD is also required to decrypt the blob, but it is one half of the Golden SAML chain described in the AD FS Server entry and should be scoped and monitored the same way. The server is Tier Zero whenever it is in use.",
+    "Cypher": "N/A - Not identifiable via BloodHound collection alone. Cross-reference AD FS farm configuration against the SQL Server instance hosting its configuration database.",
+    "Microsoft PAS Role": "NO",
+    "AdminSDHolder Protected": "N/A",
+    "Episode": "Community contribution",
+    "References": "https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-the-ad-fs-configuration-database\r\nhttps://learn.microsoft.com/en-us/windows-server/identity/ad-fs/design/federation-server-farm-using-sql-server\r\nhttps://github.com/mandiant/ADFSDump"
   }
 ]