MSFT_xWebAppPool Does not allow Managed Service Accounts

[randomchance]

I don't seem to be able to use MSFT_xWebAppPool to set an AppPool to Run as a gMSA.

I had hoped it would work using a credential with a blank password like so:
Note that You have to set PSDscAllowPlainTextPassword = $true in the configuration data for this to work.

$pw = (new-object System.Security.SecureString)
$un = "domain\account$"
$cred = New-Object System.Management.Automation.PSCredential ( $un, $pw)

xWebAppPool testpool
{
    Name = "testPool"
    Ensure = "Present"
    enable32BitAppOnWin64 = $true
    autoStart = $true
    managedRuntimeVersion = "v4.0"
    managedPipelineMode = "Integrated"
    startMode = "AlwaysRunning"
    LoadUserProfile = $false
    IdentityType = "SpecificUser"
    Credential = $cred
    restartSchedule = @()
}

Note that You have to set PSDscAllowPlainTextPassword = $true in the configuration data for this to work (well, not work, but you get the Idea... )

This creates the Schema files correctly (I think!)

However I receive the following error when I send the configuration:

The password supplied to the Desired State Configuration resource MSFT_xWebAppPool is not valid. The password cannot be null or empty.
    + CategoryInfo          : InvalidResult: (:) [], CimException
    + FullyQualifiedErrorId : InvalidPassword
    + PSComputerName        : localhost

The SendConfigurationApply function did not succeed.
    + CategoryInfo          : ObjectNotFound: (root/Microsoft/...gurationManager:String) [], CimException
    + FullyQualifiedErrorId : MI RESULT 6
    + PSComputerName        : localhost

Is there any hope for this? Not allowing gMSA's is a deal breaker for my situation, so I would be thankful for any workaround...

I'm pasting a complete test config below to make checking this easier.

Configuration testIIS
{
    # Import the module that defines custom resources
    Import-DscResource -Module xWebAdministration, PSDesiredStateConfiguration

    # Dynamically find the applicable nodes from configuration data
    Node $AllNodes.where{$_.Roles -contains 'Web'}.NodeName
    {
        # Install the IIS role
        WindowsFeature IIS
        {
            Ensure          = 'Present'
            Name            = 'Web-Server'
        }

        # Install the ASP .NET 4.5 role
        WindowsFeature AspNet45
        {
            Ensure          = 'Present'
            Name            = 'Web-Asp-Net45'
        }

        $pw = (new-object System.Security.SecureString)
        $un = "domain\account$"
        $cred = New-Object System.Management.Automation.PSCredential ( $un, $pw)

        xWebAppPool testpool
        {
            Name = "testPool"
            Ensure = "Present"
            enable32BitAppOnWin64 = $true
            autoStart = $true
            managedRuntimeVersion = "v4.0"
            managedPipelineMode = "Integrated"
            startMode = "AlwaysRunning"
            LoadUserProfile = $false
            IdentityType = "SpecificUser"
            Credential = $cred
            restartSchedule = @()
        }

        # Create a new website
        xWebsite testSite 
        {
            Ensure          = 'Present'
            Name            = "TestSite"
            State           = 'Started'
            PhysicalPath    = 'D:\Acumen\InetPub\Test-Site'
            DependsOn       = '[xWebAppPool]testpool'
        }

    }


}

$configData = @{
    AllNodes = @(
                    @{
                        NodeName = "*";
                        PSDscAllowPlainTextPassword = $true
                    }
                    @{
                        NodeName = "localhost";
                        Roles=@("web")

                    }


        )
    }

testIIS -ConfigurationData $configData 

[randomchance]

So it appears that you can't use a credential with an empty password anywhere in DSC, the Community resource gets around this by passing the username as a string and the password as a PSCredential object. Their approach does in fact allow me to use GMSAs so I have a path forward, however it would be nice if I could do the same using this resource.

[tysonjhayes]

Interesting, I'll take a look into this as soon as I have a chance.

[tysonjhayes]

Looking at this it appears to be an issue with DSC itself. As I can run the specific command without issue.

"VERBOSE: [COMPUTERNAME]: LCM:  [ End    Test     ]  [[xWebAppPool]testpool]  in 0.0070 seconds.
The password supplied to the Desired State Configuration resource MSFT_xWebAppPool is not valid. The password cannot be null or empty.
    + CategoryInfo          : InvalidResult: (:) [], CimException
    + FullyQualifiedErrorId : InvalidPassword
    + PSComputerName        : localhost
"

Credentials in this case were username: test password: (null)

Set-TargetResource -Name 'testapp' -Ensure 'Present' -Credential $(Get-Credential) -identityType 'SpecificUser' -restartSchedule @()

cmdlet Get-Credential at command pipeline position 1
Supply values for the following parameters:
Credential

@TravisEz13 or @KarolKaczmarek - Do either of you know why we specific disallow blank passwords in credential objects in DSC?

I can modify this to match the community code but it would be inconsistent with how we use credentials in other resources.

[randomchance]

Thanks for looking into it, I reached the same conclusion. I'm actually working on modifying several of the MSFT_x... resources to pass the user names separately (Notably xService and xSqlServer .) I'll admit it feels clunky, but it seems to be the best way to keep our deployment on track for now....

[MarvTheRobot]

I thought when using gMSA in PowerShell, you had to supply 'password' as the password?.. I'm going through it now so will take a look at update.

Someone else reading this may be quicker than I :)

[TravisEz13]

@tysonjhayes
No, I see no reason to disallow blank passwords, but I believe @randomchance is correct. Please file user

Please file a user voice issue that DSC should allow this:
https://windowsserver.uservoice.com/forums/301869-powershell?query=password

[randomchance]

Done - DSC: Should allow Credentials with Blank Passwords, so you can use GMSA accounts

[MarvTheRobot]

Added comment to the user voice entry... I'll copy here as well just so you see it.

I'll try and update this once I've given it a go, as currently my workaround is a custom resource that installs and sets the gMSA on the app pool. Obviously that's not ideal but does mean I'm not having to edit existing resources as this 'issue' will obviously apply to every use of a managed service account

---

I've been thinking about this since running into the problem myself. The thing I'm thinking now is to keep the behaviour of credentials not allowing blank passwords (because it's difficult to create a secure string on a blank object).

Instead, have the resources check the credential's username, if it ends in a $ symbol (required for Managed Service Accounts), ignore the password.

It's what I'm about to do, although I don't like changing the DSC resources from the gallery too much but I'll see if it works then submit a PR.

[randomchance]

I believe DSC stops the credential from ever being delivered, preventing you from being able to check the username - but I could be mistaken

[MarvTheRobot]

The credential can't be created with a blank password but you can just use any value, such as 'password'. If the resources are coded to check for a username ending in a $, you'll know to ignore the password as its a Managed Service Account.

Obviously this is just one way, but it's how I got round the problem.

Getting PowerShell to check for $ symbols was just all kinds of fun -- not. ;)

[TravisEz13]

@MarvTheRobot not all accounts ending in $ are managed service accounts. Machine accounts in a domain also end in $, but I don't think they could be used in this way...

[MarvTheRobot]

Yeah I appreciate that as MSAs are just machine accounts anyway. But someone passing in a machine account would just get a failed Set.

I check the username, if it ends in a $ I put it through the Test and Install-AdServiceAccount, then add it to the app pool if everything is ok.

This is also the way I do Windows Services and it works quite well.

If it doesn't end in a $, I just allow the original code to execute.

I've found the approach to be slightly better than trying to change the DSC resources to take string usernames and passwords.

[johlju]

I think @MarvTheRobot did something like this Install and Configure a Group Managed Service Account with PowerShell

It doesn't seem to been work done on this yet. The resource still expect to set a password. No check is made to see if it is a managed account (as proposed above). To see if it is a gMSA we could use accountName$ -match '\$$', but it will be true for a computer name as well, so that works only if computer names are not allowed as account names.

[MarvTheRobot]

Yeah I do something along these lines.

I import my accounts from config, create them, and remotely install them on the target machines - then configure the services/app pools to use them.

I don’t use a group for the hosts though. Each principal is added directly onto the account, this removes the need for a machine reboot, but does make it slightly more difficult to see/manage the identities - not much though.