Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MSFT_xWebAppPool Does not allow Managed Service Accounts #80

Open
randomchance opened this issue Jan 7, 2016 · 14 comments
Open

MSFT_xWebAppPool Does not allow Managed Service Accounts #80

randomchance opened this issue Jan 7, 2016 · 14 comments

Comments

@randomchance
Copy link

@randomchance randomchance commented Jan 7, 2016

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 randomchance changed the title MSFT_xWebAppPool Does not allow Manage Service Accounts MSFT_xWebAppPool Does not allow Managed Service Accounts Jan 7, 2016
@randomchance

This comment has been minimized.

Copy link
Author

@randomchance randomchance commented Jan 12, 2016

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

This comment has been minimized.

Copy link
Contributor

@tysonjhayes tysonjhayes commented Jan 13, 2016

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

@tysonjhayes

This comment has been minimized.

Copy link
Contributor

@tysonjhayes tysonjhayes commented Jan 14, 2016

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.

@tysonjhayes tysonjhayes added the bug label Jan 14, 2016
@randomchance

This comment has been minimized.

Copy link
Author

@randomchance randomchance commented Jan 21, 2016

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

This comment has been minimized.

Copy link

@MarvTheRobot MarvTheRobot commented Mar 10, 2016

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

This comment has been minimized.

Copy link
Contributor

@TravisEz13 TravisEz13 commented Apr 16, 2016

@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

This comment has been minimized.

@MarvTheRobot

This comment has been minimized.

Copy link

@MarvTheRobot MarvTheRobot commented Jun 8, 2016

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

This comment has been minimized.

Copy link
Author

@randomchance randomchance commented Aug 25, 2016

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

This comment has been minimized.

Copy link

@MarvTheRobot MarvTheRobot commented Aug 25, 2016

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

This comment has been minimized.

Copy link
Contributor

@TravisEz13 TravisEz13 commented Aug 25, 2016

@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

This comment has been minimized.

Copy link

@MarvTheRobot MarvTheRobot commented Aug 25, 2016

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 johlju added enhancement help wanted and removed bug labels Apr 25, 2018
@johlju

This comment has been minimized.

Copy link
Member

@johlju johlju commented Apr 25, 2018

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

This comment has been minimized.

Copy link

@MarvTheRobot MarvTheRobot commented Apr 25, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.