The following method will grant access to User Profile Service Application for a specified account name of the format DOMAIN\User.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 | private static void GrantPermissionsToUserProfileService(string accountName) { var upServiceproxy = SPFarm.Local.Services.Where(s => s.GetType().Name.Contains("UserProfileService")).FirstOrDefault(); if (upServiceproxy != null) { var upServiceApp = upServiceproxy.Applications.OfType<SPIisWebServiceApplication>().FirstOrDefault(); if (upServiceApp != null) { var mgr = SPClaimProviderManager.Local; var security = upServiceApp.GetAccessControl(); var claim = mgr.ConvertIdentifierToClaim(accountName, SPIdentifierTypes.WindowsSamAccountName); security.AddAccessRule(new SPAclAccessRule<SPIisWebServiceApplicationRights>(claim, SPIisWebServiceApplicationRights.FullControl)); upServiceApp.SetAccessControl(security); var adminSecurity = upServiceApp.GetAdministrationAccessControl(); var adminClaim = mgr.ConvertIdentifierToClaim(accountName, SPIdentifierTypes.WindowsSamAccountName); adminSecurity.AddAccessRule(new SPAclAccessRule<SPCentralAdministrationRights>(adminClaim, SPCentralAdministrationRights.FullControl)); upServiceApp.SetAdministrationAccessControl(adminSecurity); upServiceApp.Uncache(); upServiceproxy.Uncache(); } } } |
In the scenario where your application's execution context is a SPJobDefinition, your code will be running under the account identity of the SharePoint 2010 Timer service. In this previous article, I showed you how to write a method to determine the account identity of the timer service. Combining the two methods should allow you to create a custom SharePoint PowerShell cmdlet which will grant access before running your custom timer job to perform such functions as updating SharePoint user profiles.