DSC config for service account password change...almost

Tagged: 

This topic contains 2 replies, has 2 voices, and was last updated by Profile photo of Jeremy Murrah Jeremy Murrah 2 months, 3 weeks ago.

  • Author
    Posts
  • #60927
    Profile photo of Jeremy Murrah
    Jeremy Murrah
    Participant

    So I thought it would be cool to explore using DSC to handle changing of a service account password, both the password change in AD and the service configuration, using xADUser and xService. The xADUser part works perfectly, but it turns out that xService only updates the password for the logon account when the username changes. In the case of a password change with the same username, the resource passes the test without ever checking the password. I found this bug already filed on github, so I guess there's not much else I can do. In looking through the various methods and properties for win32_Service, it doesn't appear there's any way to query or validate against the stored password for a service, so probably not something that can be fixed easily.

    Any other ideas for workarounds or anything? About the only thing I can think of is a script resource that just always sets the service password every time it runs, but that seems pretty gross.

  • #60949
    Profile photo of Don Jones
    Don Jones
    Keymaster

    The problem is, in fact, that there's no way to check the current password to see if it needs to be changed. So the only thing you could do would be to change it every single time the LCM ran, which might not be a great idea ("gross" indeed). It's a design constraint of Windows – you can't "read" a service's current password, for security reasons.

  • #60984
    Profile photo of Jeremy Murrah
    Jeremy Murrah
    Participant

    so random thought, something that would potentially help in this and other weird situations like it. Resources already have the built-in "dependsOn" property, what if there was something like a "dependsOnSetAssertion" that would cause the resource to trigger only if the Set method was run for the specified resource during that particular execution of the configuration.

    Could also be useful for cases where after you make some application change you need to bounce the service, you could have something like:

    customresource appdata {
      name = myApp
      setting = MakeItWork
    }
    service MyAppStop {
      name = myAppSVC
      State = Stopped
      dependsOnSetAssertion = [customresource]appdata
    }
    service MyAppStart {
      name = myAppSVC
      State = Started
      dependsOnSetAssertion = [customresource]appdata,[service]MyAppStop
    }
    

    Might be a useful extension to DSC, or maybe just a really confusing one.

You must be logged in to reply to this topic.