This topic contains 6 replies, has 3 voices, and was last updated by
May 29, 2014 at 8:18 am #15736
I am trying to use the Built-In "Group" resource to add a domain account to a local group on the server being configured. This appears to require that because I am adding a domain account to the local group (as opposed to a local account), I MUST set the "Credential" property in order to do this. There is the following note for the "Credential" property in the TechNet documentation:
"This account must have the appropriate Active Directory permissions to add all non-local accounts to the group; otherwise, an error will occur."
What I am not sure about is which account to use. While I got it working using my own domain account while testing, what should be used when configuring actual servers? If I used my account, what happens when I need to change my password, as the value encrypted in the .mof will no longer work, requiring all server configurations to be updated?
Because the domain account is being added to a local group, it would seem that all that is required is admin rights on the server to do this. Given that the LCM runs as "System", wouldn't it have the rights is needs?
May 29, 2014 at 8:22 am #15737
It'd be a LOCAL account that has permission to add NON-LOCAL (AD) accounts to LOCAL groups. Your account worked because it's likely in Domain Admins, which is in the local Administrators group. SYSTEM wouldn't necessarily have permission, which is why a credential would be needed. And, as you probably realize, when the account password changes, you'd need to re-produce the MOF. The whole thing with encrypted credentials in MOFs is one I don't feel has been sufficiently thought-out at this point, and it's likely only going to be solved once we have some management tooling on top of DSC that can handle that detail for us.
May 29, 2014 at 8:36 am #15738MemberTopics: 9Replies: 2322Points: 0Rank: Member
I can't test this right away, but conceptually, adding a domain account to a local group should work as SYSTEM. It might be a bug in the resource, if that doesn't work.
When something running as SYSTEM locally tries to access a remote resource, it authenticates using the computer's AD account. This should have no problem with read access to the domain, resolving group names to SIDs and such. SYSTEM also has Administrator or better permissions to the local computer, which should be sufficient to add users to any local group. This is no different than what the Group Policy engine is doing when you use Restricted Groups or Group Policy Preferences to add things to a local group.
May 29, 2014 at 8:41 am #15739
The testing I did so far was on my Windows 7 desktop machine. I am in the local Administrators group which is why it worked.
The approach of using a LOCAL account that has the required permissions doesn't seem right. To avoid having server specific credentials, we would need to have the same local account created on all servers being configured, and to be sure all there passwords were the same.
So for resources that require the use of a credential which has the rights necessary to perform the configuration operation, does the LCM then logon somehow using this credential? I would suspect that this account would typically be added to each servers local Administrators group?
How about the approach of creating a common domain service account that is then added to the local administrators group for all servers being managed? If not one, you could at least have different accounts for DEV, QA, PROD, etc. environments.
May 29, 2014 at 8:50 am #15741
In terms of what the LCM is doing, you could open the resource's script file to see what it's doing with the credential – it'll depend a lot on what, specifically, it's doing. In some cases in may do something similar to a "Runas," in other cases it might pass the credential to a cmdlet. Short answer, the LCM doesn't do anything – it just runs resources. It's what the resources do that matter.
Dave's right in that you might test this without a credential to see if SYSTEM has enough permissions to do what you need. Documentation aside. But, if SYSTEM doesn't, then you're going to need an account that has permissions over a LOCAL resource. That can be a domain account, of course, but that domain account would get its permissions by being in a LOCAL group. Just like your Domain Admin account gets it superpowers by being in the local Administrators group, not just by being a domain admin. Local machines, by default, don't assign any permissions to domain accounts.
Creating a common domain account would probably be a good approach in the current state of things, provided you could get that account into the local Administrators group as part of your configuration or a pre-config build. It wouldn't be a "service" account – I realize we're used to using that term somewhat generically, but a "Managed Service Account" is a specific thing, now.
May 29, 2014 at 9:36 am #15742
I took a look at the Group resources script file, and the way its coded, if the account being added has a domain name in it, it requires that the Credential property has a value.
Is there a way to created a credential (PSCredential) for "SYSTEM"?
If not, I may need to experiment by creating a modified version of the resource.
May 29, 2014 at 9:42 am #15743
Offhand, I don't think so, but I haven't dug into it. SYSTEM isn't an "account" per se. It doesn't have a password in the normal sense.
The topic ‘MSFT Group Resource’ is closed to new replies.