SPUserProfileServiceApp throws access denied when using the FarmAccount as the PsDscRunAsCredential

[mariusv76]

Details of the scenario you try and problem that is occurring:
I've executed the SPUserProfileServiceApp resource with the SharePoint Setup account as the PsDscRunAsCredential, also the account used in the examples. When the resource executes it thows an error that it should be the farm account.

I then changed the PsDscRunAsCredential to the FarmAccount, i then get the following:

VERBOSE: [SPDFSP2]: [[SPUserProfileServiceApp]UserProfileServiceApp] Creating user profile service application User Profile Service Application
Exception calling "Add" with "1" argument(s): "Access is denied.
"
+ CategoryInfo : NotSpecified: (:) [], CimException
+ FullyQualifiedErrorId : CatchFromBaseAdapterMethodInvokeTI
+ PSComputerName : SPDFSP2

Service 'SharePoint Timer Service (SPTimerV4)' cannot be stopped due to the following error: Cannot open SPTimerV4 service on computer '.'.
+ CategoryInfo : CloseError: (System.ServiceProcess.ServiceController:) [], CimException
+ FullyQualifiedErrorId : CouldNotStopService,Microsoft.PowerShell.Commands.RestartServiceCommand
+ PSComputerName : SPDFSP2

VERBOSE: [SPDFSP2]: [[SPUserProfileServiceApp]UserProfileServiceApp] Executing as the local run as user CONTOSO\spfarm
VERBOSE: [SPDFSP2]: [[SPUserProfileServiceApp]UserProfileServiceApp] Leaving BeginProcessing Method of Get-SPServiceApplication.
VERBOSE: [SPDFSP2]: [[SPUserProfileServiceApp]UserProfileServiceApp] Leaving ProcessRecord Method of Get-SPServiceApplication.
VERBOSE: [SPDFSP2]: [[SPUserProfileServiceApp]UserProfileServiceApp] Leaving EndProcessing Method of Get-SPServiceApplication.
VERBOSE: [SPDFSP2]: [[SPUserProfileServiceApp]UserProfileServiceApp] Leaving BeginProcessing Method of New-SPProfileServiceApplication.
VERBOSE: [SPDFSP2]: [[SPUserProfileServiceApp]UserProfileServiceApp] Performing the operation "New-SPProfileServiceApplication" on target "User Profile Service Application".
VERBOSE: [SPDFSP2]: [[SPUserProfileServiceApp]UserProfileServiceApp] Leaving ProcessRecord Method of New-SPProfileServiceApplication.
VERBOSE: [SPDFSP2]: LCM: [ End Set ] [[SPUserProfileServiceApp]UserProfileServiceApp] in 65.1490 seconds.
PowerShell DSC resource MSFT_SPUserProfileServiceApp failed to execute Set-TargetResource functionality with error message: Access denied. Only machine administrators are allowed to create administration service job definitions of type:
Microsoft.SharePoint.Administration.SPServiceApplicationInstanceProvisioningJobDefinition, Microsoft.SharePoint, Version=16.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c.
+ CategoryInfo : InvalidOperation: (:) [], CimException
+ FullyQualifiedErrorId : ProviderOperationExecutionFailure
+ PSComputerName : SPDFSP2

I suspect the issue is that the FarmAccount cannot add itself to the Admin group. The FarmAccount is not an administrator on any of the SP Servers, only the SetupAccount.

The DSC configuration that is using the resource:
SPUserProfileServiceApp UserProfileServiceApp
{
Ensure = "Present"
Name = $ConfigurationData.NonNodeData.SharePoint.UserProfileService.Name
ApplicationPool = $ConfigurationData.NonNodeData.SharePoint.Services.ApplicationPoolName
MySiteHostLocation = $ConfigurationData.NonNodeData.SharePoint.UserProfileService.MySiteUrl
ProfileDBName = $ConfigurationData.NonNodeData.SharePoint.UserProfileService.ProfileDB
ProfileDBServer = $ConfigurationData.NonNodeData.SQLServer.ServiceAppDatabaseServer
SocialDBName = $ConfigurationData.NonNodeData.SharePoint.UserProfileService.SocialDB
SocialDBServer = $ConfigurationData.NonNodeData.SQLServer.ServiceAppDatabaseServer
SyncDBName = $ConfigurationData.NonNodeData.SharePoint.UserProfileService.SyncDB
SyncDBServer = $ConfigurationData.NonNodeData.SQLServer.ServiceAppDatabaseServer
PsDscRunAsCredential = $SPSetupAccount
DependsOn = @('[SPServiceAppPool]MainServiceAppPool', '[SPManagedMetaDataServiceApp]ManagedMetadataServiceApp', '[SPManagedAccount]WebPoolManagedAccount')
}
Version of the Operating System and PowerShell the DSC Target Node is running:
Windows 2016

Version of the DSC module you're using:
2.0.0.0

[ykuijs]

Hi @mariusv-msft, good point. Will check how we can fix this issue.

[Yvand]

Hello, I'm facing the same issue.
To workaround this I added the farm account to local admin group, but it's really not a good practice so I hope you can fix this soon

[ykuijs]

This issue is a tricky one. Since v2.0 we require the PSRunAsCredentials or InstallAccount to be the farm account (so it wasn't required to use CredSSP). If the farm account is not local admin, in code we are trying to add these permissions to the account. But since the account isn't local admin, it is impossible to add local admin permissions......a true catch 22 :-(

We are looking at the best way to solve this issue. If you have any suggestions, please share ;-)

[Yvand]

Actually I didn't know that v2 requires that PSRunAsCredentials or InstallAccount is set with the farm account.
But does it make sense? SharePoint requires the setup to be run as a setup account, that is local admin on SharePoint servers, and has SQL roles dbcreator and securityadmin.
The requirement you mention implies that the farm account must have all those permissions before SharePointDsc runs, is that correct?

[ykuijs]

@Yvand, the farm account is only required for the User Profile Service App and Sync Connection resources, the rest should be run using an install account. The reason is that the User Profile requires this. Before v2.0 we already did that, but that method relied on CredSSP. Since we wanted to remove that requirement, we updated the resource unfortunately introducing this issue.

[ronx]

@ykuijs, I believe SPAutoInstaller used to have an option to add the farm account to local admins while executing the script and would remove it from local admins when the script was finished (unless you specified the option to leave the user in the local admins group. On workaround would be to provide similar NonNodeData options like this and then use the Group resource to add (and optionally remove) the farm user to/from local admins. Not ideal, but just spitballin'.

[NikCharlebois]

Time to bring in super @brianlalancette into the loop.

[ronx]

Here's the AutoSPInstaller piece I'm talking about:

https://github.com/brianlala/AutoSPInstaller/blob/master/AutoSPInstallerInput.xml#L80-L88

[brianlala]

Yep that's correct AutoSPInstaller has that option. Feel free to reuse any code, if it makes sense to.

[NikCharlebois]

Also, most users rely on @spencerharbar article to configure the UPS, and Spence makes the following recommendation:
"To provision the UPS service – we must make the DOMAIN\spfarm account a local administrator of the box hosting the UPS service. Once we are done we can remove this. Don’t try and work around this – you won’t succeed! The local administrator rights are only required during provisioning."

[ronx]

Haha, well there ya go. So maybe something like:

Group AddFarmAccountToLocalAdmins
        {
            GroupName        = 'Administrators'
            MembersToInclude = @($ConfigurationData.NonNodeData.SharePoint.ServiceAccounts.FarmAccount)
            Credential       = $SPSetupAccount
        }

[ronx]

And good news, no changes needed to SP DSC ;)... just some documentation and examples updated prob.

[brianlala]

Correct, the AutoSPInstaller method is based on this. I actually launch a new PS session as the Farm account
in order to accomplish this.

[ykuijs]

That is what we did before 2.0: The resource ran with the Setup account permissions, which was local admin and was able to add the farm account to the local admin. Then UPS was provisioned and afterwards the farm account was removed again. However this method relied on CredSSP being configured and since CredSSP has some security issues we wanted to remove that dependency.

I have thought about that Group resource option as well, but to prevent the farm account being present in the local administrators group for ever, we also need a resource to remove it again. And if we do that, the two resources are in conflict with each other, resulting in the farm account constantly being added and removed again each time the config is applied to the system. Personally I do not like that situation.

[ronx]

Good point regarding the constant adding and removing of the farm account to/from local admins. However, that would only happen if LCM was set to ApplyAndAutoCorrect. Assuming most, if not all, people will be using either ApplyOnly or ApplyAndMonitor, this shouldn't be an issue. However, with ApplyAndMonitor, it would still report FirstAppServer as out of compliance after the 2nd run.

This brings back up the ongoing question about which resources it makes sense to monitor for drift after initial deployment of the farm. Will people want to use this to ensure that a User Profile Service Application exists and automatically recreate it if it doesn't? Personally, if UPS goes missing, it's because I blew it away manually and would prefer to manually push the DSC config again or recreate it myself with powershell.

[ykuijs]

I see many customers that are in the process of implementing DSC to make sure DTAP environments are really equal. They are planning to use DSC to deploy all types of changes and to monitor on a daily basis if the environments are still according to their baseline.

That is why I would like to prevent a server constantly reporting it is out of compliance, which in this case it will.

I have an alternative idea:
If we can use Invoke-Command without CredSSP to change the permissions of the farm account, we can first update the group membership using the setup account and then the farm account to deploy the UPS. Unfortunately I so far I have failed to get Invoke-Command to the localhost working without CredSSP. It gives me an Access Denied error.

[ronx]

Just to reinforce the mindset that adding/removing to/from admins using the Group resource is NOT the way to go, DSC doesn't let us do this anyway. It throws an error when building the mof that a conflict exists between resources. ;)

Is it really such a bad thing to use CredSSP? Is the main concern eliminating dependencies or reducing security vulnerabilities? If security, maybe we could further limit the delegate computers allowed from the client management box? This seems like a pretty crippling issue for the current production release, and I'm assuming the only current workaround is to manually add the farm account to the local admins of all boxes? Just thinking out loud.

[ykuijs]

The reason why we wanted to remove CredSSP is security, as described in this article.

But the more I investigate this issue, the less options we seem to have. Depending on CredSSP looks like the only option we have.

[NikCharlebois]

It appears that our only option (if we keep CredSSP out of the equation), is to modify the Set-TargetResource function of the SPUserProfileServiceApp with additional logic to handle the following flow:

• Add the farm account to local group
• Provision the Service App
• Remove the farm account from the local group

This way, we would not have any conflicting resource blocks, and the Test-TargetResource would not always report it as not compliant. When you really think about it, the provisioning portion ABSOLUTELY requires the Farm admin to be local admin for it to work, therefor it makes sense that this resource handles the add/remove process as well instead of depend on other resources to do stuff it requires.

[NikCharlebois]

Actually, to add to my point, a colleague just pointed out to me that we are doing the same thing in the SPUserProfileSyncService resource. We call Add-SPDSCUserToLocalAdmin, start the service and then call Remove-SPDSCUserToLocalAdmin once everything has been provisioned. We should be reusing the same logic here.

[ykuijs]

We have two issues with this solution:

1. When the Farm account isn't local admin, it cannot add itself to the local administrators group since it does not have the permissions to do so.
2. When you change permissions of an account, you need to login again to refresh the logon token with the group memberships. If we find another way to add the farm account to the local administrators group from inside the resource, the code still isn't able to provision the service application right away. This because the Set method was still running as the farm account and didn't re-logon. The provision first has to fail and then it will work on the second attempt. With the assumption that as soon as it fails on the first attempt, the code doesn't remove the account again ;-)

This leads me to believe that re-adding a farm account parameter again, running the resource as the install account, adding the farm account and then executing the service application provision using CredSSP is the only option that will work.

[NikCharlebois]

@ykuijs

1. Can't we use PsDscRunAsCredential = SP_Setup to add the Farm admin to the local admin group? the setup account should already be a local admin at that point, no?

2 - Wouldn't calling into a separate Invoke-SPDSCCommand script block pick up the new permissions without having to log out/on? How are we doing it in the User Profile Sync Service?

Thanks

[ronx]

@NikCharlebois I could certainly be wrong, but on first glance, it looks to me like the difference is that the sync service doesn't try to run any process AS the farm account. Instead, it looks up the farm account name and password and passes those values to $ups.SetSynchronizationMachine where $ups is the object returned from Get-SPServiceApplication. So the DSC module isn't trying to create a new process using different credentials, which would violate the 2-hop rule that CredSSP was being used for previously.

On the other hand, the SPUserProfileServiceApp resource needs to run New-SPProfileServiceApplication under the context of the farm credential. Assuming we run the resource as the setup account (because of local admin), the resource would then need to invoke another process under the farm credential in order to do this.

I think that, at least in the near term, @ykuijs is right in that re-enabling CredSSP is the best/only way to get this working again. Maybe we can figure out a way to get around this in the future, but I think the minimal risk tied to CredSSP is acceptable to get this high profile functionality working again. Maybe we could CYA by linking to articles/documentation about CredSSP that explains the risks and how to set it up properly to only allow delegating across secure channels/servers.

[ykuijs]

The Sync Service resource does two things:

1. It runs as the Farm Account to create the Sync service. It is using the InstallAccount or PsDscRunAsCredential for that.
2. It uses the credentials in the FarmAccount parameter to configure the service application. We had to use the FarmAccount parameter, because when you use PsDscRunAsCredential there is no way to retrieve the password from code unfortunately.

@NikCharlebois:

1. That is exactly what we did pre 2.0. This does however mean that you have to use CredSSP to run other code as the Farm account. I do believe that currently this is the only way to solve this issue. I am working on implementing this solution, but couldn't get it implemented in time for v2.1 :-(

@ronx:
Good idea to add the CredSSP info to the Readme.md of both resources and the Wiki. Will add that as well.

[ykuijs]

Closed via PR #775