Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

The custom attribute permission groups need to address multiple items:

  1. Must use "ControlAccess" due to confidential attributes
  2. The standard No Access vs. Read vs. Write
  3. The ability to address record restrictions for future directory services work

Current proposal is AUSTIN-[short-object-type]-[short-attribute-name]-[permission-code]. The "short object type" is the shortened string of the AD object class (ex. User, OU, Computer, Group). The "short attribute name" is the AD attribute name less the "utexasEduAustin" prefix. The "permission code" is one of the following:

  • A - Access - User is allowed to read the attribute but can be blocked by record restrictions
  • B - Bypass - User is allowed to read the attribute regardless of record restrictions
  • C - Change - User is allowed to read and write the attribute

    Change to Use of the "B" Group

    The B group is currently not in use for any attributes. Do not use it at the present time!


    We will rework the B group into Blockable and will grant read unless overridden by a record restriction. It'll be a rare use-case

This would create groups named as follows:

  • AUSTIN-User-Single11-A - the members are allowed to read the utexasEduAustinSingle11 attribute on users
  • AUSTIN-OU-Multi12-C - the members are allowed to read and write the utexasEduAustinMulti12 attribute on OUs

Record restrictions are handled by placing a deny directly on the user object for the appropriate Access group. Membership in the Access, Bypass, and Change groups must be exclusive to prevent conflicts.


Script for setting the ACEs for access groups.

In order to reduce the size of the ACL, only set an ACE for groups where that access type has been requested.
For example, if there is a request to read an attribute, but no request to write it as well, only set the ACE for the appropriate -A group. Do not set an ACE for the -C group as well if write access is not requested.

NameAdd-Attribute-ACE.ps1
Location\\aad-share-p01.austin.utexas.edu\Shares\Scripts\Permissions
Variables

$ad_container - String containing the FQDN of the container to be updated

For user attributes, this will be "OU=People,DC=austin,DC=utexas,DC=edu" in AUSTIN

$ad_group - String containing the name of the attribute group

Example: AUSTIN-User-Single1-A, AUSTIN-User-Single1-B, AUSTIN-User-Single1-C

$ad_write_ace - Boolean containing the state of the script (write the ACE or not)

This variable must be True in order to write the ACE.

You must set the variable on each run of the script in order to have it write the ACE. It is set to False at the end of the script.

  • No labels