Service : can't set local account like NT SERVICE\MsDtsServer110

[Francois-Rousseau]

Using Service Resource, I'm not able to set services with local account like NT SERVICE\MsDtsServer110, with no password:

• I can't create a credential with an empty password (is it a way of doing that?)
• If I create a dummy password, it's trying to validate the credential and I got this error :
  PowerShell DSC resource MSFT_ServiceResource failed to execute Set-TargetResource functionality with error message: Failed to change 'Credential' property. Message: 'The 'Change' method of
  'Win32_Service' failed with error code: '22'.'
  Which means : The account under which this service runs is either invalid or lacks the permissions to run the service.

I can set this account manually in services.msc with no problem, with or without password.
I think the Service resource should handle that, like the SqlServiceAccount from SQL module do.
If the account is NT Authority or NT SERVICE, the password should be ignored?

Thank you!

[johlju]

The resource SqlServiceAccount using the SQL Server SMO object model to set the service account, and the object model probably has this built-in since we do nothing special to handle this in the resource. So the same functionality can not be reused. But similar could be added as an enhancement to this resource or it's equivalent xService in xPSDesiredStateConfiguration.

@kwirkykat Do you see this as an potential enhancement that the community could add to this resource, or do you rather see this added to xService in xPSDesiredStateConfiguration?

[stale]

This issue has been automatically marked as stale because it has not had activity from the community in the last 30 days. It will be closed if no further activity occurs within 10 days. If the issue is labelled with any of the work labels (e.g bug, enhancement, documentation, or tests) then the issue will not auto-close.

[johlju]

We are still waiting for response from @kwirkykat as per previous comment. Comment so that the issues keeps open.

[kwirkykat]

@Francois-Rousseau @johlju
You can create a PSCredential with no password:
New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList @("NT SERVICE\MsDtsServer110", (New-Object System.Security.SecureString))

I would try using that with the resource first to see if it works.
My guess is that it will work since for the 3 built-in accounts we do allow, we also just set the password to a blank.

If it doesn't work, it doesn't look like it would be a very hard change.
We could just remove the ValidateSet from the BuiltInAccount parameter to allow the user to specify whatever built in account they want to run with rather than limiting them to only the basic 3.
I think most of the logic will still work if we just take out that limitation.
I don't think that would constitute as a breaking change since all past scripts would still work with this update.
So I would accept this change here.
But please make sure that it is necessary to make the change first.

[johlju]

@Francois-Rousseau relabeled this as 'needs more information' until the suggestion from @kwirkykat has been evaluated by you. Let's us know your findings. Thank you!

[stale]

This issue has been automatically marked as stale because it has not had activity from the community in the last 30 days. It will be closed if no further activity occurs within 10 days. If the issue is labelled with any of the work labels (e.g bug, enhancement, documentation, or tests) then the issue will not auto-close.

[stale]

This issue has been automatically closed because it is has not had activity from the community in the last 40 days.