Troubleshooting: Cannot Find an AD Attribute to Delegate Permissions for User Objects

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.