Hi again

Thanks for the suggestions re the ACI - I managed to resolve that part, but now have hit yet another wall with the "interesting" way in which our accounts are set up.

As I stated, we have a service desk that manage all the user accounts, however, I've just been reliably informed that they are only going to be managing the password resets of any user accounts, and that a subgroup of the department I'm building the directory for, will actually be creating the user accounts.

Here's where it gets interesting - although the subgroup will be creating the accounts, they will not be permitted to reset any passwords hence I'm now in a confusing place.

I've looked at the ACIs and the service desk part was easy enough to achieve, I thought the other part would be as simple as denying write permission to the userpassword attribute, but this doesnt work as I'm assuming setting the password at user creation is effectively a form of write to the attribute.

The question therefore, is can you allow a person/group to be able to create user accounts, but not have the ability to modify the password attribute after its created. I'd like to trust the users not to be resetting passwords on their own, however we need to have an auditable trail of the user permissions that details this.

Thanks in advance for any help (and for the help supplied so far!)

Darren
This e-mail and any attachments may be confidential or legally privileged.If you received this message in error or are not the intended recipient, you should destroy the email message and any attachments or copies, and you are prohibited from retaining, distributing, disclosing or using any information contained herein. Please inform us of the erroneous delivery by return e-mail. Thank you for your co-operation.

Mercer Human Resource Consulting Limited is authorised and regulated by the Financial Services Authority. Registered in England No. 984275. Registered Office: 1 Tower Place West, Tower Place, London, EC3R 5BU.