Current documents at docs/installation/pki/microsoft.asciidoc create a major security vulnerability in Active Directory. The docs instruct the user to duplicate the "user" template in ADCS, and check the box to supply the SAN in the request. However, the documentation neglects to instruct the user to restrict enrollment to the certificate. By default all users in the domain have enrollment rights in the "user" certificate.
Combining these factors leads to ESC1, a privilege escalation vulnerability allowing any user in the domain to become a domain admin. Because the SAN is supplied in the request and all users can enroll in the template, any authenticated user can request a certificate for a domain administrator. That certificate can then be used for authentication, compromising the domain.
To fix this, only the service principle for NDES should have enrollment rights, and this should be specified in the documentation. PacketFence will send the request for a certificate for a particular user to NDES, and NDES will specify the SAN of that user in the request, thus obtaining the certificate.
Vendor documentation leading to ADCS vulnerabilities is a common problem. For further reading on the issue, check this article:
https://specterops.io/blog/2026/03/24/rtfm-read-the-fatal-manual-when-vendor-documentation-creates-critical-attack-paths/?utm_source=twitter&utm_medium=social&utm_campaign=soc-blog-260324-rtfm
For a better understanding of how this issue would be exploited by a threat actor, read here:
https://www.blackhillsinfosec.com/abusing-active-directory-certificate-services-part-one/
Current documents at docs/installation/pki/microsoft.asciidoc create a major security vulnerability in Active Directory. The docs instruct the user to duplicate the "user" template in ADCS, and check the box to supply the SAN in the request. However, the documentation neglects to instruct the user to restrict enrollment to the certificate. By default all users in the domain have enrollment rights in the "user" certificate.
Combining these factors leads to ESC1, a privilege escalation vulnerability allowing any user in the domain to become a domain admin. Because the SAN is supplied in the request and all users can enroll in the template, any authenticated user can request a certificate for a domain administrator. That certificate can then be used for authentication, compromising the domain.
To fix this, only the service principle for NDES should have enrollment rights, and this should be specified in the documentation. PacketFence will send the request for a certificate for a particular user to NDES, and NDES will specify the SAN of that user in the request, thus obtaining the certificate.
Vendor documentation leading to ADCS vulnerabilities is a common problem. For further reading on the issue, check this article:
https://specterops.io/blog/2026/03/24/rtfm-read-the-fatal-manual-when-vendor-documentation-creates-critical-attack-paths/?utm_source=twitter&utm_medium=social&utm_campaign=soc-blog-260324-rtfm
For a better understanding of how this issue would be exploited by a threat actor, read here:
https://www.blackhillsinfosec.com/abusing-active-directory-certificate-services-part-one/