16.10 - AuthSearch - Teradata Database

Teradata Database Security Administration

Product
Teradata Database
Release Number
16.10
Release Date
June 2017
Content Type
Administration
Security
Publication ID
B035-1100-161K
Language
English (United States)

This feature maps existing or new directory entries that behave like groups to Teradata external roles. The directory is searched to establish a principal’s authorizations.

The configuration is added to TdgssUserConfigFile.xml and defines the search parameters needed to locate group-like entries in a directory server.

<AuthSearch
      Ref="service-id"
      Base="search-base"
      Scope="{onelevel|subtree}"
      MemberAttribute="member-attribute-name"
      ObjectClass="object-class-name"
      NamingAttribute="naming-attribute-name"
      <AuthSearchMap Match="regex" Pattern="pattern"/>
/>...

    <AuthSearch
    <AuthSearchMap Match="manager" Pattern="admin"/>
    < AuthSearchMap Match="socal" Pattern="tduser">
    />

</Mechanism>

For additional information, see Option 4: Lightweight LDAP Authorizations.

Attributes

Attribute Description
Ref The Ref attribute is used only when the <AuthSearch> is placed inside the <Canonicalizations> area of the <LdapConfig> section. It is not used when <AuthSearch> is placed inside the <MechanismProperties> element.

The attribute names the <Service> that will perform the search. The value in the Id attribute of the <Service> must be provided. The same rules apply to the Ref attribute that apply to the Ref attribute in the <IdentitySearch> and <IdentityMap> elements.

The search is performed in the service that identified the user. The same service associated with the canonicalization that generates the principal’s distinguished name (DN) will be searched for mappings.

Base The Base attribute is optional. If not provided, the value is taken from the mechanism’s or service’s LdapGroupBaseFQDN property. If an LdapGroupBaseFQDN property is not provided, the value comes from the LdapBaseFQDN. The value defines the location where the search is to start to locate the group-like entries that represent Teradata external roles.
Scope The Scope attribute is optional. This attribute specifies the search scope. It may take one of two values, “onelevel” or “subtree” with “subtree” being the default.
MemberAttribute The values of the MemberAttribute and ObjectClass attribute are used to construct a search filter.

The MemberAttribute attribute is optional. MemberAttribute names the attribute in the directory which contains the DN of the identified user. If the attribute is omitted, the value defaults to “member”. This attribute MUST use the distinguishedNameMatch equality matching rule and the 1.3.6.1.4.1.1466.115.121.1.12 (distinguished name) syntax rule.

ObjectClass The ObjectClass attribute is optional. If provided, it names the object class of the authorization entry and causes an ObjectClass term to be included in the search. If the attribute is omitted, no ObjectClass term will be included in the search filter.

The ObjectClass "group" has a member attribute (MemberAttribute) that is optional. The ObjectClass "groupOfNames" has a member attribute that must have at least one user named in it. Another ObjectClass is "groupOfUniqueNames" with a member attribute called "uniqueMember" that only allows a name to appear once.

If you don't set the ObjectClass the default sets memberAttribute to “member” and ObjectClass to “groupOfNames”. For Active Directory, ADAM, and AD LDS set ObjectClass to "group".

If an object class name is present, the generated search filter will be of the following form: (&(member-attribute-name=dn-of-principal)(objectClass=object-class-name))

If an object class name is not present, the generated search filter will be of the form: (member-attribute-name=dn-of-principal)

NamingAttribute The NamingAttribute attribute is optional. The value of this attribute names the attribute in the directory entry which contains the external role name. It is used to limit the returned attributes to this one attribute. If omitted, it defaults to “cn”. If the attribute contains multiple values, then all values are candidates for permitted roles. If the attribute is not present (has no values), the containing entry is ignored.
AuthSearchMap The AuthSearchMap element is optional. Configure as many AuthSearchMap elements as necessary. The Match and Pattern attributes of the AuthSearchMap are used to filter out unwanted group names. If the group name returned from the directory is not completely consumed by the regex pattern, it is discarded. If it matches, then the external role is derived according to the substitution pattern in the Pattern attribute. If the <AuthSearchMap> element is absent in the corresponding <AuthSearch> element then the group names are used as external roles as is.

Supporting Mechanisms for AuthSearch

The <AuthSearch> element enables lightweight authorizations.

Mechanisms that are not listed in the table do not support this property. The Property Editable column indicates if the setting for a property may be edited.
Mechanism Property Editable?
KRB5 May Be Edited
SPNEGO
LDAP
To set a value, you must manually add this property to the TdgssUserConfigFile.xml on the mechanisms that require it. See About Editing Configuration Files.

Editing Guidelines

  • Zero or more <AuthSearch> elements are placed in the <Canonicalizations> area of the <LdapConfig> section or as a child of the <MechanismProperties> element. In both cases, the <AuthSearch> is a sibling of <IdentitySearch> and <IdentityMap> elements.
  • Like <IdentitySearch> and <IdentityMap>, as many <AuthSearch> elements as necessary may be placed in the configuration. These elements may appear anywhere in the appropriate sections. They can be placed before or after the <IdentitySearch> and/or <IdentityMap> elements or they can be interleaved with the <IdentitySearch> and <IdentityMap> elements.
  • The LdapSystemFQDN attribute does not need to be populated in the configuration. If populated, it will be ignored when <AuthSearch> is present.
  • If UseLdapConfig="yes" for the mechanism, then the <LdapConfig> section of the configuration file should contain the <AuthSearch> entries. To use this feature a value for the LdapServiceFQDN and LdapServicePassword properties must be provided and user identities must be discovered using <IdentitySearch> and/or <IdentityMap> elements. The LdapServiceFQDN and password are used to do the canonicalization of the user. After canonicalization, but before Authentication, the authorization is retrieved using the service bind. All the authorization entries (roles) will be added to a roles list. The roles list will be returned after successful authentication. These roles will be used for database logon.