JustEnoughAdministration DSC: Unable to set GroupManagedServiceAccount
jnury opened this issue · 4 comments
Hi,
On a Windows Server 2012 R2 with WMF 5.1:
Name Value
---- -----
PSVersion 5.1.14409.1012
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.14409.1012
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
I successfully setup a JEA endpoint with the following DSC configuration:
Configuration JeaTest
{
Import-DscResource -Module JustEnoughAdministration, PSDesiredStateConfiguration
JeaEndpoint Endpoint
{
GroupManagedServiceAccount = 'UNDISLAB\gMSA-Undis02'
EndpointName = "JEA"
RoleDefinitions = "@{
'UNDISLAB\jnury' = @{ RoleCapabilities = 'Maintenance' }
}"
}
}
JeaTest
Start-DscConfiguration .\JeaTest -Force -Wait -Verbose
But Test-DSCConfiguration returns False:
VERBOSE: [UNDIS02]: [[JeaEndpoint]Endpoint] GroupManagedServiceAccount not equal: UNDISLAB\gMSA-Undis02$
VERBOSE: [UNDIS02]: LCM: [ End Test ] [[JeaEndpoint]Endpoint] False in 0.3900 seconds.
VERBOSE: [UNDIS02]: LCM: [ End Resource ] [[JeaEndpoint]Endpoint]
VERBOSE: [UNDIS02]: LCM: [ End Test ] Completed processing test operation. The operation returned False.
If I modify the config as the following (to match the Get-DSCConfiguration value):
JeaEndpoint Endpoint
{
GroupManagedServiceAccount = 'UNDISLAB\gMSA-Undis02$'
EndpointName = "JEA"
RoleDefinitions = "@{
'UNDISLAB\jnury' = @{ RoleCapabilities = 'Maintenance' }
}"
}
The Test-DSCConfiguration returns True, but the endpoint doesn't work .
Enter-PSSession from another host fails with error: The verification of the Managed Service Account failed with error 1326
That's because the RunAsUser is misspelled:
PS C:\Users\administrator.UNDISLAB\Desktop> Get-PSSessionConfiguration -name JEA | fl *
GroupManagedServiceAccount : UNDISLAB\gMSA-Undis02$
...
RunAsUser : UNDISLAB\gMSA-Undis02$$
Note that I get exactly the same behavior if I manually register PSSessionConfiguration with the trailing $ sign in GroupManagedServiceAccount parameter.
Hope it's clear ...
Have a nice day.
Great catch, Julien. The main rationale for using RunAsUser is that GroupManagedServiceAccount is not a valid member of a PSSessionConfiguration object if there isn't one configured. However, since PowerShell gracefully handles accessing non-existent properties, your proposed change seems fine.
RunAsUser also addressed an edge case where a static runas user (regular AD user account) was configured for an endpoint. It would trigger the DSC test to fail and re-deploy the endpoint using the correct runas account based on the DSC config. Since you can't really end up in this state with an endpoint deployed with our DSC configuration (only if you manually modify the endpoint), I don't see this as a huge concern.
@jnury this merge caused test() to incorrectly return false when GMSA is not set, my mod:
block not entered if both $currentInstance.GroupManagedServiceAccount & $this.GroupManagedServiceAccount null, this matters because
if (($currentInstance.GroupManagedServiceAccount) -or ($this.GroupManagedServiceAccount)) {
if($currentInstance.GroupManagedServiceAccount -ne ($this.GroupManagedServiceAccount -replace '\$$', ''))
{
Write-Verbose ('GroupManagedServiceAccount not equal: "{0}"' -f $($currentInstance.GroupManagedServiceAccount))
return $false
}
}