Knowledge Partner Knowledge Partner
Knowledge Partner

Interesting case with AD title permissions

This case is not exactly IDM related, but maybe my post will help you to save time during your own investigation.

I have a "relatively simple" business case, that required to update specific AD attributes for pre-existing AD users.

Driver service account in AD doesn't have admin-level privileges (just RW permissions for specific attributes).

Smoke-test permission validation (attempts to update specific attributes from Apache LDAP Studio from session bind with the driver service account) failed on one attribute "title".

AD View Effective Access shows proper permissions (exactly the same, like other attributes).Effective AccessEffective AccessRWRW

Attempt to update the title



Long story short: this is a "well-known" AD bug, reported a long time ago and never solved. (my suspicious, that it will never resolve,  as it maybe has "internal" architecture dependencies).

MS recommendation is a "classic" example of ... (never accept that you have an issue, admin permission "required" for the simple task)

Example of the report about "same" issue:

When trying to delegate the permissions for a service account to update user “Title” (job title) attributes in Active Directory we found that despite effective permissions showing write permissions, access was denied.

On further instigation, we found that “Write All Properties” worked, which made it even stranger.

The same issue is reported here:

The article references the need to modify the attribute in the schema, for us we opted for the Write All Properties option.



P.S. If anybody has any idea, how to resolve this issue without the use of an "admin-like" account or "Write-All" permission - you are welcome to share your ideas. 🙂 (Admin account, Write-All options declined by security)

Labels (1)
2 Replies
Knowledge Partner Knowledge Partner
Knowledge Partner

Is this the issue, where a Domain Admin, cannot be modified by someone who is not also a Domain Admin?  In your case, you are explicitly trying to avoid using Domain admin in your AD servcie account,

Knowledge Partner Knowledge Partner
Knowledge Partner

I will start with the second part of your comment.
"Security" team didn't approve "Domain-admin" accounts for "external" (does not own by security team) apps. (just stupid "internal" politics).

This issue independent from "blocking inheritance for "protected" accounts" (this is a real explanation for the issue where a Domain Admin, cannot be modified by someone who is not also a Domain Admin).

This specific "title" case impacts any AD user.
My personal feeling, this issue related to the bugs in the AD engine "internal" implementation.
Potentially MS has problems, when they doing internal "mapping" between "visual" representation of attribute in ADUC, BlueJet DB engine, ACL/SDPROP process (that run once an hour), and AD LDAP service.
I saw some discussions when people mentioned "cross-linkage" between "title" (supposed to be Job Title) and "Personal Title".
If "Write All Properties" enabled - you able to modify the title, if you have to be "attribute-specific" - Access Denied.

"The electron is as inexhaustible as the atom..." Lenin, Materialism and Empirio-Criticism (1908)
Only you think, that you already know about all AD bugs, as you will find another one, that more stupid, aglee and unexplainable than all previous bugs...

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.