• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 3131
  • Last Modified:

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.
1 Solution
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?

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.
Easily Design & Build Your Next Website

Squarespace’s all-in-one platform gives you everything you need to express yourself creatively online, whether it is with a domain, website, or online store. Get started with your free trial today, and when ready, take 10% off your first purchase with offer code 'EXPERTS'.

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 http://support.microsoft.com/kb/817433) 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!!
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Creating Active Directory Users from a Text File

If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now