General access denied error

Apr 27, 2009 at 8:06 AM


I have installed the WebPart within my SharePoint Services 3.0 intranet, but I am receiving an error which, I'm presuming, is related to the IUSR not having access to the Active Directory.

The instructions specify that I need to add the IURS to the "Account Operators" group, but the only IUSR in the Active Directory users listing is IUSR_TEMPLATE which is the same user to access the website according to the IIS properties for the SharePoint website.  When I add IUSR_TEMPLATE to be a member of "Account Operators" I sill keep receiving the error, "General access denied error".

Is there another user I need to give access to the "Account Operators" group or do I need to do something else?


Apr 27, 2009 at 1:57 PM
Hi Tony,

This is indeed a bit confusing in the documentation. The user that should be a member of the "Account Operators" is the Application Pool Account. You can find the application pool user in IIS > Application Pools > Your Allplication Pool > Properties > Identity, or in the Central Administration under Operations > Security Configuration > Service Accounts > Web Application Pool

I'll update the documentation.

Apr 28, 2009 at 12:39 AM
Edited Apr 28, 2009 at 12:51 AM

Thanks for that Mel.

When I go to the Application Pools settings for my application, the details displayed on the Identity tab are:

"Select a security account for this application pool" ... Predefined is selected with "Network Service" displayed in the drop down list.

In this case what User Account do I add to be a member of "Account Operators"?

Would it be IWAN_TEMPLATE?

In any case I did add the IWAN_TEMPLATE user to be a member of "Account Operators", but I am still receiving the error "General access denied error".

Do you have any more thoughts


Apr 28, 2009 at 8:10 AM
Hi Tony,

The account "Network Service" should be a member of the "Account Operators"
Apr 28, 2009 at 12:41 PM

Hi Mel

I found the "Network Service" account in the active directory listing under ForeignSecurityPrincipals.  When I view it's properties, and clicked on the MemberOf tab it already contained the "Account Operators"

I have also tried adding  "Account Operators" to the both the IUSR_TTEMPLATE & IWAM_TEMPLATE users but still haven't had any luck. 

Do you have any more ideas?



Apr 28, 2009 at 1:52 PM
Hi Tony,

This may be a problem of the Network Service account, maybe because it's a local account and not part of the domain?
I have my application running with a new user that is member of the IIS_WPG and WSS_WPG groups (iis and sharepoint worker process groups), and also member of the Account Operators.

Can you try to do that?

You can change the user of the application pool in the Central Administration website under perations > Security Configuration > Service Accounts > Web Application Pool
Apr 29, 2009 at 1:02 AM
Hi Mel

That worked a treat. 

Thanks for all your help and patience working through this issue.

Apr 29, 2009 at 3:07 AM
Hi Mel

I spoke to soon.  This above all works fine for creating a new user, but when I try to use the Change Password page I receive an "Object reference not set to an instance of an object." error.

Any ideas with this error?

Apr 30, 2009 at 11:59 AM
Hi Tony,

The error you recieved was caused by a bug. The application erronously tried to connect to Active Directory with the connection string that from the web.config instead on the one entered in the Site collection Active Directory settings.
I have fixed the error and uploaded the fixed version.

May 6, 2009 at 1:11 PM
Hi Mel

Thanks for posting the update.  I have now deployed the update and it now allows me to change the users password, which is great. 

The only thing is when I try to login to access the SharePoint website it now allows me to use both my old and new password. 

I initiall thought it was a caching issue, but I have tried on different pc which have never access the sharepoint website before and it still allows both passwords.

Any ideas on this?

Sep 14, 2009 at 7:20 PM
Edited Sep 14, 2009 at 9:15 PM
Another update to my post, since I am having a field day with AD providers:
- "The method or operation is not implemented." comes up because MOSS AD provider does not support "CreateUser"-method. Thank you Microsoft!
- has its own issues when connecting to AD (it basically works, then it stops working without a cause, then works again...)
I wonder if anyone got this to work reliably (with "CreateUser" and "ChangePassword"). If you did, which version of MOSS (SP1/SP2) and which *provider* was used? I am sure that there is only one winning combination.
Once again, kudos to Microsoft for creating this mess with half-baked providers and for not supporting an essential method (CreateUser) in MOSS AD provider.
I solved the problem outlined below (saving configuration settings) by, I hope you are sitting down, rebooting the Windows 2008 box.
Now I have a new error. When I try to create a user, I get
"The method or operation is not implemented."
argc, argv, argh!
I installed the latest build you have here on codeplex.


Hi Mel,

Thank you for posting "SharePoint Account Provisioning" component.

I tried all hints and tips posted here, but I cannot make it work.

Although I can connect to my active directory with "active directory browser", SharePoint won't connect: when I try to save my LDAP connection string on the SiteCollectionADSetting.aspx-page, I get an error saying "Cannot connect using this connection string."

Here is what I am entering in the fields:

Active directory connection string: LDAP://DCSERVER.DOMAIN.COM/OU=Customers,DC=DOMAIN,DC=COM (note that I can connect with this string with "active directory browser")

Organizational unit: Portal

"Portal" is a child-OU below "Customers" in our AD.

Also, note that I am setting this up on Windows 2008 server.

My application pool account is a member of WSS_ADMIN_WPG, WSS_RESTRICTED_WPG, Domain Admins (as a desperate measure ...).

What is the security model behind your component? Does AD connection have to be established under specific privileges? Would it be better to establish the AD connection in the DLL itself while running under "elevated privileges" (this would require another build of the DLL though).

What is the equivalent of "Account Operators" under Windows 2008?

After adding my app pool account to Domain Admins group and still could not get this to work, I am out of ideas.

Thank you for any hints you can provide.