ADManagedServiceAccount: Proposed Breaking Change

[X-Guardian]

I am currently working on the ADManagedServiceAccount resource to fix issues #511 and #512. Going through the code, there are other issues with it which I am taking the opportuntity to fix, including the following breaking changes:

Breaking:

• AccountType parameter ValidateSet changed from ('Group', 'Single') to ('Group', 'Standalone') - Standalone is the correct terminology. ref: https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/service-accounts.
• AccountType parameter default of Single removed. - Enforce positive choice of account type.
• MembershipAttribute parameter ValidateSet member SID changed to ObjectSid to match result property of Get-AdObject. Current code does not work if SID is specified.
• AccountTypeForce parameter removed - unnecessary complication. With the current code for this in place, if the AccountType is changed without specifying this parameter, the change will not apply, but the DSC will still complete successfully. A warning is written to the log, but unless you are looking for it you won't see it. I don't think this is a good model, and none of the other resources use it.
• Renamed Members parameter to ManagedPasswordPrincipals - to closer match Get-AdServiceAccount result property PrincipalsAllowedToRetrieveManagedPassword. This is so that a DelegateToAccountPrincipals parameter can be added later.

I also intend to subsequently add the following missing parameters to the resource that are directly supported by the ADServiceAaccount PowerShell cmdlets:

• AccountExpirationDate
• AccountNotDelegated
• CompoundIdentitySupported
• DelegateToAccountPrincipals (PrincipalsAllowedToDelegateToAccount)
• HomePage
• ServicePrincipalNames
• TrustedForDelegation
• Enabled

Any comments?

[johlju]

Just wondering if we remove $AccountTypeForce how does the user opt-in to change a standalone to group or vice verse?
I think the opt-in was meant so that an existing account couldn't be changed by mistake. It would be more proper for the resource to throw if it needs to change the type but is not opt-in. 🤔

[X-Guardian]

Throwing in this scenario would be better than the current code, but do we really need to protect against this? Part of the reason that I'm proposing to remove the default on AccountType is so that you are always making a positive choice in the first place.