I had to first apply a registry hack to get the Citrix code to log anything that was going wrong. From its admin guide:
You can also find useful troubleshooting information in the log files stored in sharepoint\LOGS\LogFolder, where LogFolder is a location you can specify by setting a string value for LogFolder in the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\WISP.
Without creating this key, nothing is logged. After creating it, I could see a curious sequence of events when trying to activate the Citrix Access Core feature:
...
Adding List Item Event Receiver: Added
Adding List Item Event Receiver: Deleting
Adding List Item Event Receiver: Deleted
Elevating privilege, now running as DOMAIN\moss-pool-dev
Adding new configuration update job (ConfigUpdateJob-default-WIConfiguration(DMOSS01))
AddConfigurationUpdateJob() Error: Access denied.
at Microsoft.SharePoint.Administration.SPPersistedObject.Update()
at Microsoft.SharePoint.Administration.SPJobDefinition.Update()
at Citrix.WISP.Configuration.Jobs.UpdateJob..ctor(String jobName, SPSite site, SPServer server, String configurationName, String configurationType, String filename, List`1 featureIds, SPJobLockType targetType)
at Citrix.WISP.Configuration.Jobs.Installer.<>c__DisplayClass2.
End of Elevating privilege, now running as DOMAIN\apenn
Adding new job CitrixAccessCoreDeployment(DMOSS01)(Citrix Access Core Service Provider Deployment) to DMOSS01(Application)
AddDeploymentJob() Error: Access denied.
at Microsoft.SharePoint.Administration.SPPersistedObject.Update()
at Microsoft.SharePoint.Administration.SPJobDefinition.Update()
at Citrix.WISP.AccessCore.Jobs.DeploymentJob..ctor(String jobName, SPSite site, SPServer server, SPJobLockType targetType, String title)
at Citrix.WISP.AccessCore.Jobs.Installer.<>c__DisplayClass2.
Updating Property Citrix.WISP.Site.Active in site https://devextranet.DOMAIN.local with value True
CitrixContentRedirectionModule: Add the web.config mod
- SPWebApp Name: Customer Extranet
- add/remove here: configuration/system.web/compilation/expressionBuilders
- the following:
CitrixAccessCore::Activate Error: Access to the path 'C:\Inetpub\wwwroot\wss\VirtualDirectories\devextranet.DOMAIN.local80\web.config' is denied.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share)
at System.Xml.XmlDocument.Save(String filename)
at Microsoft.SharePoint.Administration.SPWebApplication.ApplyWebConfigModifications()
at Microsoft.SharePoint.Administration.SPWebService.ApplyWebConfigModifications()
at Citrix.WISP.AccessCore.FeatureReceiver.<>c__DisplayClass2.
at Microsoft.SharePoint.SPSecurity.CodeToRunElevatedWrapper(Object state)
at Microsoft.SharePoint.SPSecurity.<>c__DisplayClass4.
at Microsoft.SharePoint.Utilities.SecurityContext.RunAsProcess(CodeToRunElevated secureCode)
at Microsoft.SharePoint.SPSecurity.RunWithElevatedPrivileges(WaitCallback secureCode, Object param)
at Microsoft.SharePoint.SPSecurity.RunWithElevatedPrivileges(CodeToRunElevated secureCode)
at Citrix.WISP.AccessCore.FeatureReceiver.changeExpressionBuilderInWebConfig(SPWebApplication app, Boolean remove)
at Citrix.WISP.AccessCore.FeatureReceiver.FeatureActivated(SPFeatureReceiverProperties properties)
CitrixAccessCore: Ended at Monday, March 24, 2008 9:51:03 AM
It was apparent it was trying to take some actions under the application pool identity for the web application which failed with 'access denied,' and then was trying to use MY account (a domain administrator, MOSS farm administrator, and local MOSS server administrator) for other actions and STILL getting 'access denied!'
The administrator's guide for WISP does state:
To complete the installation you must have server farm administrator permissions, meaning you must be a member of the
administrators group on each of your Web and Application servers, and SQL security administrator with database creator rights on each of your SQL servers.
Those rights my account had; however, to correct the 'access denied' problem, I had to make my APPLICATION POOL IDENTITY:
- A member of the Farm Administrators group in MOSS; and
- A local machine administrator on the MOSS server.
C'mon Citrix, the application pool identity is supposed to be a low-privileged account.
As you say the web app app pool should be a low level account. However, the activation of several of the features require higher privilege, specifically the ability to be able to create recurring Timer jobs, which requires a Farm admin account.
ReplyDeleteNow the problem is that SharePoint is supposed to allow delegated administration so that site collection admins can manage their own site collections, but site collection admins are not necessarily farm admins. Hence to facilitate the delegated admin story, the WISP team used an API call RunWithElevatedPrivileges() which effectively allows some code to run as the web app pool identity, which can have the required additional privileges.
The upshot of all this is that if you want delegated admin through the SharePoint web UI and WISP, then the web app pool has to be a farm admin. This is a matter of choice with regard to security policies.
If you want to run the app pool with the lowest level of privilege, then a SharePoint administrator has to activate the relevant features from the command line using the stadm command as described in Admin Guide.
Hopefully this clears up why this particular choice was made.
John Ashman
Manager, WISP Deve Team
Thanks for your reply. Now that you explain it, I understand what the admin guide is referring to:
ReplyDeleteTo activate the features from the user interface in a single server deployment, you must be a member of
both the SharePoint Farm Administrators and Local Administrators groups. In other types of deployments, the identity of the application pool ...
It would be nice if the guide could be reworded to call out that stsadm activation is required unless you have the highly-privileged app pool configuration, which is the exception, and to trap and throw better exception messages during installation when it detects the lack of privileges.
The curious thing is that even when it elevated its prileges to use the installer's (my) account, it still got access denied. My account has full farm and local admin rights. Any idea why this would have occurred?