{"id":1212,"date":"2025-03-17T16:26:47","date_gmt":"2025-03-17T15:26:47","guid":{"rendered":"https:\/\/blog.chrisse.se\/?p=1212"},"modified":"2025-03-17T17:35:09","modified_gmt":"2025-03-17T16:35:09","slug":"when-your-enterprise-pki-becomes-one-of-your-enemies-part-5","status":"publish","type":"post","link":"https:\/\/blog.chrisse.se\/?p=1212","title":{"rendered":"When your Enterprise PKI becomes one of your enemies (Part 5)"},"content":{"rendered":"\n

Mitigate Authentication Mechanism Assurance (AMA) abuse<\/strong>
In the last blog post series – When your Enterprise PKI becomes one of your enemies (Part 4)<\/a> we vent trough how Authentication Mechanism Assurance (AMA) works and how it can be abused together with Public Key Infrastructure (PKI) to compromise an Active Directory forest if it’s not designed the right way.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

One of the core issues here is that has been demonstrated in the previous blog article(s) is that AMA abuse can be performed by obtaining a certificate from a certificate authority that is trusted by the KDC (but not necessarily being trusted in NTAuth) – to summary the requirements again.<\/p>\n\n\n\n

    \n
  1. Obtain a certificate from a certificate authority (CA) that is trusted on the KDC and being able to supply the AMA Issuance Policy OID – this can be archived by:\n