Add a check for GMSA accounts and exclude them of specific rules

[mpgn]

When checking for rules in "Privileged Accounts", two rules are triggered if a gmsa account is found to be in an "admin group" (like DnsAdmin for example).

• Check if all privileged accounts are in the special group Protected Users. - Rule ID: P-ProtectedUsers
• At least one Administrator Account can be delegated - Rule ID: P-Delegated

Nevertheless, gmsa accounts cannot be put in the Protected Users group and they cannot be set as "this account is sensitive and cannot be delegated" (it doesn't exist on gmsa)

Therefore gmsa accounts considered as "admin" should be excluded of these two rules as it is just impossible to use the solution provided by pingcastle for gmsa accounts.

[An-dir]

In general it is not a false positive, because the GMSA has both identified risk rules.

P-Delegated is fine and does not need to be changed as far as i know.
You can set the delegation option on a GMSA. Here is a description: https://learn.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/configure-kerberos-delegation-group-managed-service-accounts

P-ProtectedUsers increases security in many ways, the most important for you is that it doesn't allow to save the password for services/tasks. So even if you know what you are doing it is a risk that needs to be discovered. The system you are using this account on, needs to be protected because as the credentials on it could be misused in several cases.

No change to either rule makes sense in my opinion.

[mpgn]

Hello,

P-Delegated is fine and does not need to be changed as far as i know.
You can set the delegation option on a GMSA. Here is a description: https://learn.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/configure-kerberos-delegation-group-managed-service-accounts

I didn't know that, I will try this on my lab.

P-ProtectedUsers increases security in many ways, the most important for you is that it doesn't allow to save the password for services/tasks. So even if you know what you are doing it is a risk that needs to be discovered. The system you are using this account on, needs to be protected because as the credentials on it could be misused in several cases.

True, my point is about the recommandation, not the rule itself. If this is a gmsa, the recommendation is not valid and it should not recommand something that doesn't not apply to a gmsa. At least a note should be written regarding if this is a gmsa account.

[mpgn]

So @An-dir I double check on the "delegation" thing and I still think it's a false positive to report a gmsa in an admin group as not secure.
By default, a gmsa is not delegated to anything and unless the value is set to TRUSTED_TO_AUTH_FOR_DELEGATION or TRUSTED_FOR_DELEGATION or msDS-AllowedToDelegateTo is not empty there is not delegation possible.

Default value for a gmsa is -TrustedForDelegation $false, -TrustedToAuthForDelegation $false and msDS-AllowedToDelegateTo is empty

You can test this by checking the userAccountControl of a gmsa => default = 0x1000
Run the command -TrustedForDelegation $false -TrustedToAuthForDelegation $false and the uAC will be the same value.

So from my understanding, if a gmsa cannot be delegated by default, why reporting it as vulnerable ?

[spotet]

Hi,
We tested this very promising solution for us, but the score is not representative for the same problem announced here by @mpgn, a gMSA cannot be TrustedForDelegation. We would like to take this solution commercially for the image of our company from the customer point of view. This anomaly would not allow us to present a score reflecting the efforts made by the use of gMSA.

[mpgn]

I've just tested using beta version: 3.1.5.0 Beta

The problem is fixed on my side with this version 🥳