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 msExchOmaAdminWirelessEnable.

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-Wireless-Enable", Properties, security tab and Add.

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.
Who is Participating?
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.

Mike ThomasConsultantCommented:
I think you may have to delegate authority (or rather assign security permissions) over the accounts in AD not just that attribute for this user you created?

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?


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
account use for write to AD schema must be member of Schema Admins Group.
straynorAuthor Commented:
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.
Determine the Perfect Price for Your IT Services

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!

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.
If the script is going to run against all new accounts you would want to delegate the right to your service account to write msExchOmaAdminWirelessEnable.

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.
straynorAuthor Commented:
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 (msExchOmaAdminWirelessEnable), along with possibly all others, is exposed in the 'Delegate Control...' wizard in ADUC.  I haven't used that wizard for some time, perhaps a previous version of Windows Server, and had it in my head that it was very basic, but it seems to allow wizard-based delegation over pretty much every property.

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 HTH.

Points to Mojotech - thanks.
straynorAuthor Commented:
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

From novice to tech pro — start learning today.