Fix AZResetPassword false positives

[simondotsh]

Some roles cannot reset the password of users that either own or are members of role-assignable groups. The queries to create AZResetPassword edges have been modified to take this into account for the following roles:

• Helpdesk Administrator
• Authentication Administrator
• Password Administrator
• User Administrator

[andyrobbins]

Hi @simondotsh

Thank you for this great PR. This false positive was due to an oversight on my part. I created some tests to validate the logic in your PR and I was able to verify that, indeed, Global Admins and Privileged Auth Admins can reset the passwords for members and owners of role-eligible groups while the other password-reset roles do not grant this ability.

I tested this by creating service principals for each default AAD admin role, granting the role to each SP, then having each SP try to reset the passwords for two users: one that owns a role eligible group, and one that is a member of a role eligible group. I also wanted to know whether groups can be owners of groups, and this does not appear to be possible through either the Azure portal GUI nor through the MS Graph API endpoint (so those details are in red:)

After testing each role's ability to reset the password for each of these users, I found that your report for the false positive is correct, but that we also have a false negative: the Partner Tier2 Support role grants the ability to reset the password for a user that owns a role eligible group, but not to reset the password for a member of a role eligible group:

I'm not sure if this is intended by Microsoft so I'm going to contact them and see what the deal is there before adding the password reset logic for Partner Tier2 Support into BloodHound.

Thank you again for this great PR

Andy

[andyrobbins]

The logic matches the behavior of Azure, and the build correctly creates AZResetPassword edges