Provision a fax DID write delegation

The fax broker needs to write fax numbers onto user objects when it provisions a new DID (direct inward dial number). Handing it broad write access would be a liability, so the lab grants a delegation scoped to exactly two attributes and nothing more. This is a worked example of least-privilege delegation in AD.

Provision it

make fax-rw

That creates two accounts and one access-control entry:

svc-fax-rw — a write bind account, a plain Domain User with no special group membership.
faxtest.provision — a disabled, no-fax proof target under OU=Fax Endpoints, so you can test a write without touching a real user.
A scoped ACE on OU=Supported Systems granting svc-fax-rw write-property on only facsimileTelephoneNumber and otherFacsimileTelephoneNumber, inherited to objectClass=user objects in the subtree.

Deliver the password

The account is created with a throwaway password. Set its real one and deliver it into the broker’s .env the same way as any service account:

make rotate-svc U=svc-fax-rw ENVFILE=~/bingham/faxart/.env KEY=AD_WRITE_BIND_PASSWORD

See Rotate a service-account password for the mechanics.

What the scope actually is

The ACE is expressed in SDDL and grants write-property (WP) on two specific attribute GUIDs, for the user object class, to the svc-fax-rw SID:

(OA;CIIO;WP;<facsimileTelephoneNumber GUID>;<user class GUID>;<svc-fax-rw SID>)
(OA;CIIO;WP;<otherFacsimileTelephoneNumber GUID>;<user class GUID>;<svc-fax-rw SID>)

That is the entire grant. svc-fax-rw cannot change a display name, cannot reset a password, cannot create or delete objects, and cannot touch anything outside OU=Supported Systems. You can confirm the limits by binding as the account and trying to write a different attribute: it is denied.