SPAppCatalog: Resource should not depend on CredSSP

[DennisL68]

Problem description

The resource SPAppCatalog requires CredSSP to elevate the credentials of the used Farm account to be able to perform all actions needed.

However, Microsoft states,

Caution

Credential Security Support Provider (CredSSP) authentication, in which the user credentials are passed to a remote computer to be authenticated, is designed for commands that require authentication on more than one resource, such as accessing a remote network share. This mechanism increases the security risk of the remote operation. If the remote computer is compromised, the credentials that are passed to it can be used to control the network session.

Verbose logs

VERBOSE: [SRVXXX1]         [[SPAppCatalog]My_AppCatalog] Executing using a provided credential and local PSSession
                           as User local\SPFarm
Connecting to remote server SRVXXX1 failed with the following error message: The WinRM client cannot process the
request. CredSSP authentication is currently disabled in the client configuration. [...]

DSC configuration

SPAppCatalog 'Setup_AppCatalog' {
  PsDescRunAsCredential = $SpFarmCredential
  SiteUrl               = 'https://mysite.local/apps'
}

Suggested solution

Use PowerShell Configured Sessions instead of CredSSP

$SessionName = (New-GUID).Guid
Register-PSSessionConfiguration -Name $SessionName -RunAsCredential $Credential

Invoke-Command localhost {
  # Code to run as another user
} -ConfigurationName $SessionName

Unregister-PSSessionConfiguration $SessionName -Force

Named sessions can even be locked down as in JEA (Just Enough Administration) to only allow certain users to attach to it.

or setup and remove CredSSP within the resource when needed.
(this should only be done if CredSSP isn't set at all to avoid side effects)

SharePoint version and build

SharePoint Subscription Edition 16.0.15601.20747

Operating system the target node is running

OsName               : Microsoft Windows Server 2022 Standard
OsOperatingSystemSKU : StandardServerEdition
OSArchitecture       : 64-bit
WindowsVersion       : 2009
WindowsBuildLabEx    : 20348.2849.amd64free.fe_release_svc_prod1.241101-1732
OsLanguage           : en-US
OsMuiLanguages       : {en-US}

PowerShell version and build the target node is running

Name                       Value
----                       -----
PSVersion                  5.1.20348.4163
PSEdition                  Desktop
PSCompatibleVersions       {1.0, 2.0, 3.0, 4.0...}
BuildVersion               10.0.20348.4163
CLRVersion                 4.0.30319.42000
WSManStackVersion          3.0
PSRemotingProtocolVersion  2.3
SerializationVersion       1.1.0.1

SharePointDsc version

Name          Version Path
----          ------- ----
SharePointDsc 5.6.1   C:\Program Files\WindowsPowerShell\Modules\SharePointDSC\5.6.1\SharePoindDSC.psd1

[DennisL68]

This is my workaround so far.
I still need to eliminate the side effects that might occur when I configure UserProfileService (which also requires CredSSP) and it happens to run at the same time...

I also need to make sure CredSSP only is enabled when the AppCatalog is missing. I don't want it to cycle with the DSC refresh frequency.

Script 'Enable_CredSSP_for_AppCatalog' {
    PsDscRunAsCredential = $SetupCredential

    GetScript   = { @{ Result = 'NoOp'} }

    SetScript   = {
        try {
            Write-Verbose 'Enabling CredSSP...'

            $FQDN = Resolve-DnsName $ENV:COMPUTERNAME -ErrorAction Stop |
                select -Unique -ExpandProperty Name

            Enable-WSManCredSSP -Role Client -DelegateComputer $FQDN, $ENV:COMPUTERNAME -Force | Out-Null
            Enable-WSManCredSSP -Role Server -Force | Out-Null

            Write-Verbose "Enabled CredSSP for WinRM loopback calls on $FQDN."
        }
        catch {}
    }

    TestScript  = {
        Write-Verbose 'Checking if CredSSP is enabled.'
        return (
            [boolean]((Get-WSManCredSSP)[0] | select-string $ENV:COMPUTERNAME) -and
            [boolean]((Get-WSManCredSSP)[1] -like '*is configured*')
        )
    }

}#end script

SPAppCatalog 'Setup_AppCatalog' { #* Extracts the Farm admin credentials from SP. Requires CredSSP
    PsDscRunAsCredential    = $SetupCredential
    SiteUrl                 = 'https://mysite.local/apps'
    DependsOn               = '[Script]Enable_CredSSP_for_AppCatalog'
}

Script 'Disable_CredSSP' {
    PsDscRunAsCredential = $SetupCredential

    GetScript   = { @{ Result = 'NoOp'} }

    SetScript   = {
        Disable-WSManCredSSP -Role Client
        Disable-WSManCredSSP -Role Server
        Write-Verbose "Disabled CredSSP."
    }

    TestScript  = {
        Write-Verbose 'Checking if CredSSP is enabled.'
        return (
            [boolean]((Get-WSManCredSSP)[0] -like '*is not configured*') -or
            [boolean]((Get-WSManCredSSP)[1] -like '*is not configured*')
        )
    }

    DependsOn   = '[SPAppCatalog]Setup_AppCatalog'

}#end script

    ~~~

[ykuijs]

Hi @DennisL68, the reason for the CredSSP requirement is the fact that SharePoint requires some code to be executed in the Farm account context. So either you have to run the resource as the farm account (but that also requires the farm account to have local administrator permissions to be able to log into the machine) or we have to elevate the process to the Farm account.

In order to accomplish this last option, SPDsc creates a connection to the server itself (localhost) which requires CredSSP to function properly. This method has been implemented since the start of SPDsc, when PowerShell DSC v4.0 still existed and the PSDscRunAsCredential didn't exist yet. We have tried many different solutions to move away from CredSSP, but without any luck so far.

You are absolutely right that the use of CredSSP has some security challenges. However we are also only using it locally. There is no connection to a remote machine whatsoever. So if the local machine is compromised, there is a whole different scenario going on. The attacker will be able to dump the memory and retrieve any used credential from there, including the Setup account (which has loads of permissions).

The downside of your Script solution is that the CredSSP config is switched on and off with each deployment or consistency run by the LCM. As a result, the DSC config will never be in a desired state, since either the first or the last resource won't be in the desired state. It is impossible that both are in a desired state.