Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden with our free interactive tool and use it to determine the right price for your IT services. Download your free eBook now!
AD LDAP attribute - assign 'modify' permission
Hi all
I have written a script to modify a single LDAP attribute for all users across the domain. The attribute in question is msExchOmaAdminWirelessEnab
If i run the script as my domain admin account, it works fine and updates the attribute value as expected.
This script will be running as a scheduled task, so i have created a domain user for this script to run as, and have given 'write' permissions to the attribute in question using ADSIEdit.
But it doesn't work and i can't write the value to the attribute.
If i get out LDP, bind as the user in question, and try and perform a modify operation on the above value, i get [INSUFF_ACCESS_RIGHTS} problem 4003, server error 00002098.
So it seem pretty clear that simply giving write permission to this user account has not had the desired effect...
Can anybody point me in the right direction?
I have assigned this permission by opening ADSI edit as a schema admin, connecting to the Schema partition, finding the entry "CN=ms-Exch-Oma-Admin-Wire
User account in question is brand new (yesterday), and a member of the Domain Users group only.
One other thing to note is our AD is parent-child domain - parent domain is basically empty, everything lives in child domain so i am operating on the child domain directory.
I have written a script to modify a single LDAP attribute for all users across the domain. The attribute in question is msExchOmaAdminWirelessEnab
If i run the script as my domain admin account, it works fine and updates the attribute value as expected.
This script will be running as a scheduled task, so i have created a domain user for this script to run as, and have given 'write' permissions to the attribute in question using ADSIEdit.
But it doesn't work and i can't write the value to the attribute.
If i get out LDP, bind as the user in question, and try and perform a modify operation on the above value, i get [INSUFF_ACCESS_RIGHTS} problem 4003, server error 00002098.
So it seem pretty clear that simply giving write permission to this user account has not had the desired effect...
Can anybody point me in the right direction?
I have assigned this permission by opening ADSI edit as a schema admin, connecting to the Schema partition, finding the entry "CN=ms-Exch-Oma-Admin-Wire
User account in question is brand new (yesterday), and a member of the Domain Users group only.
One other thing to note is our AD is parent-child domain - parent domain is basically empty, everything lives in child domain so i am operating on the child domain directory.
Asked:
Who is Participating?
Experts Exchange Solution brought to you by
Enjoy your complimentary solution view.
Get every solution instantly with Premium.
Start your 7-day free trial.
I wear a lot of hats...
"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.
Experts Exchange Solution brought to you by
Your issues matter to us.
Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.
Start your 7-day free trial
MojoTech - Thanks that does make sense now you say it. Will investigate and report back.
marcokrecic - are you saying that for any user account to modify any single attribute on a user object, it needs to be a member of the Schema Admins group? Sounds a bit mad to me! i don't want my script to go wrong, or someone to change it, and have all sorts being edited throughout the schema. i was hoping i could limit the risk by just allowing this one account to change the one property.
marcokrecic - are you saying that for any user account to modify any single attribute on a user object, it needs to be a member of the Schema Admins group? Sounds a bit mad to me! i don't want my script to go wrong, or someone to change it, and have all sorts being edited throughout the schema. i was hoping i could limit the risk by just allowing this one account to change the one property.
Sorry, is a misunderstanding, you haven't to create new properties but change an existing property.
I think that you have to set Security in the Domain Section (in adsiedit) to allow change of properties and not in the schema section.
I think that you have to set Security in the Domain Section (in adsiedit) to allow change of properties and not in the schema section.
If the script is going to run against all new accounts you would want to delegate the right to your service account to write msExchOmaAdminWirelessEnab
You will be able to do this by using delegation wizard and then going through advanced user attributes to find that specific attribute.
This would stop you having to drop this user into the DA group.
You will be able to do this by using delegation wizard and then going through advanced user attributes to find that specific attribute.
This would stop you having to drop this user into the DA group.
OK so i needed to give the permissions to the user objects themselves rather than the attribute object. This is embarrasingly obvious now! :(
This property (msExchOmaAdminWirelessEna
I have removed the permission i added to the actual schema object through ADSIedit.
And my script works kinda - but now on to interitance and protected groups\adminSDHolder issues! (if you have the same problem as me check out http://support.microsoft.com/kb/817433) HTH.
Points to Mojotech - thanks.
This property (msExchOmaAdminWirelessEna
I have removed the permission i added to the actual schema object through ADSIedit.
And my script works kinda - but now on to interitance and protected groups\adminSDHolder issues! (if you have the same problem as me check out http://support.microsoft.com/kb/817433) HTH.
Points to Mojotech - thanks.
principal of least privilege - i didn't want to give the account domain admin and full AD write access in case something happens later (eg. somebody else changes the script to do something else, or i cock something else up). but you were right with the first section of your post!! Thanks!!
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Databases
From novice to tech pro — start learning today.
Experts Exchange Solution brought to you by
Enjoy your complimentary solution view.
Get every solution instantly with Premium.
Start your 7-day free trial.
If the account you created is just for the secheduled task is it an option to make this user part of the domain admins group and set and incredibly complex password? (as if it is just for this task it wont change or be used on a daily basis) just set it and forget it?