tyea
asked on
-2147024891 Active Directory General access denied error
I have an activex script that performs 3 functions - 1) creates accounts within active directory, 2) updates expiry dates for some accounts, 3) modifies the groups that a user is part of. The script runs within SQL Server and connects to a database in order to determine what accounts to create or modify. The script runs on one server and creates / modifies accounts on a second server.
When I am logged into the first server and run the script, then the script works perfectly. However, when I schedule the script to run from a job (and am therefore not logged in) my script generates the error '-2147024891 Active Directory General access denied error' when it tries to create new accounts or update the expiry dates of existing accounts. It does not however seem to have any problems adding users to groups or creating new groups.
I am guessing that this problem is permissions based??? Does anyone have any suggestions as to what permissions my user needs to have in order to create and update accounts? Is it something that needs to be set within group policy?
Any suggestions would be appreciated!
When I am logged into the first server and run the script, then the script works perfectly. However, when I schedule the script to run from a job (and am therefore not logged in) my script generates the error '-2147024891 Active Directory General access denied error' when it tries to create new accounts or update the expiry dates of existing accounts. It does not however seem to have any problems adding users to groups or creating new groups.
I am guessing that this problem is permissions based??? Does anyone have any suggestions as to what permissions my user needs to have in order to create and update accounts? Is it something that needs to be set within group policy?
Any suggestions would be appreciated!
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
It turns out that regardless of the user that I had set against the job in SQL Server, in this situation it was running under the account that the SQL Server Agent service was started under. The service was started under the local system account and that was the problem..... I changed the service to run under srvadmin and now all is good!