xPDT – Credentials, CredSSP, and Execution

In “xPDT – the next generation of deployment automation”, I outlined the requirements and challenges of automating distributed deployment. This post will examine the challenges associated with Credentials, CredSSP, and Execution.

In a distributed deployment, there are two types of tasks that we need to execute through DSC – installation and configuration.  Installation tasks typically run a setup.exe, which often requires specific credentials.  In many scenarios, those credentials also need to be able to access remote systems – for example, to create or access a database on a remote SQL Server.  Configuration tasks also often need specific credentials, especially when they are being used to configure a product that has it’s own administrative model such as most of the System Center components.

So, we need a way to run tasks within DSC resources as a credential, and in the case where that credential needs to access a remote system, we need to use CredSSP.

The Local Configuration Manager (LCM) is the component that runs the configuration defined in DSC.  LCM runs as system.  Fortunately, PowerShell offers several ways to execute something using an alternate credential, and DSC provides a secure way to pass a credential to a DSC resource as a PSCredential object.  Both Start-Process and Invoke-Command accept a credential as a parameter.  However, Start-Process with a credential fails inside a DSC resource with “access denied”.  Invoke-Command, even when executed against the local system, effectively uses remoting, and certain setups fail when used inside remoting usually when they attempt to check for a Windows Update as a prerequisite – that check is specifically blocked in remoting.  So we need an alternate way to start a process as a credential for installation tasks.

The answer to this problem came from another resource in the DSC Resource Kit – xProcess.  xProcess provides the ability to ensure a specific process is running, including under a specific credential.  There are supporting functions in the xProcess resource that do this using PInvoke.  I converted those supporting functions to a supporting module, xPDT.psm1, that is included in each of the xPDT resources.  Unlike xProcess, xPDT uses those functions start and then wait for completion of the process.  PInvoke provides the process with local logon credentials, which means that process is allowed to access remote systems.  There are still a couple of scenarios that aren’t covered by PInvoke, specifically those where a user profile is expected by setup – PInvoke does not create a user profile.  I will address those scenarios in a later post on profiles.

For configuration tasks, we usually call existing PowerShell cmdlets – and those work well with Invoke-Command and a credential.  Many of them still need to access remote systems, so need to use –Authentication CredSSP.  This means that CredSSP needs to be enabled on the system, with a delegated computer of itself.  For this, I created the xCredSSP resource, also included in the resource kit, to allow CredSSP Server and Client roles to be enabled within a DSC configuration.

Many of the samples that are included with the xSC* resources in the DSC Resource Kit use xCredSSP, so I would encourage you to explore those to fully understand how to use these approaches.

In my next post, I’ll discuss profile requirements and how I solved those in xPDT.