I am trying to create a user profile programmatically for an AD user whose user profile does not exist already in SharePoint 2013. I know from MSDN that in order to create a user profile for somebody else you need to have PortalRight.ManageUserProfile permission for the user running the code. As the solution I am developing will be run for everyone and in order to cater Manage User Profile permissions I am impersonating the code as System Account! But upon running the solution the page is hit with Http 403 Forbidden message. The log entry for the event displays:

UnauthorizedAccessException for the request. 403 Forbidden will be returned. Error=Access Denied: To create a user profile, you must be an administrator, or create your own profile and have personal features rights.

Following is the code I am using:

SPServiceContext serviceContext = SPServiceContext.GetContext(web.Site);
UserProfileManager profileManager = new UserProfileManager(serviceContext);

   using (SPSite site = new SPSite(profileManager.MySiteHostUrl))
       SPServiceContext tempServiceContext = SPServiceContext.GetContext(site);
       UserProfileManager tempUserProfileManager = new UserProfileManager(tempServiceContext);
       UserProfile tempUserProfile = tempUserProfileManager.CreateUserProfile(EmployeeUser.User.LoginName, EmployeeUser.User.Name);

I believe the above code runs in full trust. What possibly is going wrong?

2 Answers 2


as robert noted! You have two options! either use impersonation that uses an account part of the administrator group or add the web application app pool account to the administrator group!

SharePoint -access to path is denied


looks like the bug is still there is 2013! lol, seems like event tho its a system account it doesnt mean it has access as your app pool account needs to be part of Manage User Profiles

The other way would be impersonating the account by creating a SPSite object with the token from the SSP app pool user or impersonate the site collection admin. Pass that SPSite into the SPServiceContext and then into the UserProfileManager.

that method would be the proper way and most clean as you would get rid of the spsite and SPServiceContext once finished!

seems like this issue is ongoing from 2007/2010 and now 2013

  • As the code is not run with anonymous users so I am guessing the RunWithElevatedPrivileges is working fine here and impersonating system account already? Do i need to explicitly pass system account token for the new site anyway? About the 2nd part the account running the web app pool is already part of local administrators group and has Full Control on UPSA in CA!
    – Usman
    Apr 10, 2014 at 8:27
  • just ammended my answer! looks like its alot more deep than i thought!
    – Ali Jafer
    Apr 10, 2014 at 8:51

No, RunWithElevatedPrivileges as you use it will impersonate the Application Pool account!

So you need to make sure that the account running your web application app pool has administative rights to your UPS

  • UPS in services.msc is currently logged on as Local System. Should I change it to the account which runs my web application app pool?
    – Usman
    Apr 10, 2014 at 8:10
  • No, you should grant the APP Pool account permissions on hte Service application for User Profile Apr 10, 2014 at 8:15
  • 2
    The account running the app pool has already Full Control on User Profile Service Application in CA
    – Usman
    Apr 10, 2014 at 8:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.