Version Affected: All
Overview
When trying to delegate permissions to a specific Active Directory (AD) attribute for User objects -- for example, registeredAddress -- the attribute doesn't appear in the Delegation of Control wizard's Permissions list. For general guidance on scoping a SecureAuth service account's Active Directory permissions, see How To: Determine the Minimum Permissions Required for a SecureAuth Service Account.
Cause
Many AD attributes aren't delegated individually -- they're grouped into property sets, and it's the property set that appears in the Permissions list, not the individual attribute.
The Delegation of Control wizard's Permissions list shows entries at the property-set level -- for example, Write general information, Write personal information, Write private information, and Write public information -- rather than individual attributes.
The property sets for User objects are:
General Information
Property set containing a set of user attributes that constitute general user information.
Applies to: User
- Display Name
- adminDescription
- codePage
- CountryCode
- ObjectSid
- primaryGroupID
- sAMAccountName
- sAMAccountType
- sDRightsEffective
- showInAdvancedViewOnly
- sIDHistory
- UID
- comment
Personal Information
Property set containing user attributes that describe personal user information.
Applies to: Computer, Contact, User
- streetAddress
- homePostalAddress
- assistant
- info
- country/region name
- facsimileTelephoneNumber (fax number)
- International-ISDN-Number
- Locality-Name
- MSMQ-Digests
- mSMQSignCertificates
- Personal-Title
- Phone-Fax-Other
- Phone-Home-Other
- Phone-Home-Primary
- otherIpPhone
- ipPhonenumber
- primaryInternationalISDNNumber Phone-ISDN-Primary
- Phone-Mobile-Other (otherMobile)
- Phone-Mobile-Primary
- Phone-Office-Other (otherTelephone)
- Phone-Pager-Other
- Phone-Pager-Primary
- physicalDeliveryOfficeName
- thumbnailPhoto (Picture)
- postalCode
- preferredDeliveryMethod
- registeredAddress
- State-Or-Province-Name
- Street-Address
- telephoneNumber
- teletexTerminalIdentifier
- telexNumber
- primaryTelexNumber
- userCert
- User-Shared-Folder
- User-Shared-Folder-Other
- userSMIMECertificate
- x121Address
- X509-Cert
Public Information
Property set containing user attributes that describe user public information.
Applies to: Computer, User
- Additional-Information notes
- Allowed-Attributes
- allowedAttributesEffective
- allowedChildClasses
- allowedChildClassesEffective
- altSecurityIdentities
- Common-Name (cn)
- company
- department
- description
- displayNamePrintable
- division
- E-mail-Addresses
- givenName
- initials
- legacyExchangeDN
- manager
- msDS-Approx-Immed-Subordinates
- msDS-Auxiliary-Classes
- distinguishedName (Obj-Dist-Name)
- Object-Category
- Object-Class
- Object-Guid
- Organization-Name
- Organizational-Unit-Name
- otherMailbox
- Proxy-Addresses
- RDN name
- Reports (directReports)
- servicePrincipalName
- showInAddressBook
- Surname
- System-Flags
- Text-Country/Region
- Title
- userPrincipalName
Private Information (2008 Domain Functional Level or newer)
Property set containing user attributes that describe user public information.
Applies to: Computer, User
- ms-PKI-Credential-Roaming-Tokens
- ms-PKI-RoamingTimeStamp
- ms-PKI-DPAPIMasterKeys
- ms-PKI-AccountCredentials
Resolution:
Find the attribute you're trying to delegate permissions to in the list above, then delegate read/write permissions to the property set it belongs to instead of the individual attribute.
Special Considerations
Delegating permissions to a property set grants read/write access to every attribute in that set, not just the one you need -- this may be more access than you want to grant to the IdP's service account. If that's a concern, consider whether a different AD attribute would work for storing the data the IdP needs.
SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.
Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.
Comments
0 comments
Please sign in to leave a comment.