<AuthSearch> - Advanced SQL Engine - Teradata Database

Security Administration

Product
Advanced SQL Engine
Teradata Database
Release Number
17.10
Published
July 2021
Language
English (United States)
Last Update
2022-02-15
dita:mapPath
ppz1593203596223.ditamap
dita:ditavalPath
wrg1590696035526.ditaval
dita:id
B035-1100
lifecycle
previous
Product Category
Teradata Vantage™

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

The <AuthSearch> element enables lightweight 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>

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.

This attribute names the <Service> that performs the search. The value in the Id attribute of <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 Vantage 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 is 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 <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.

Editing Guidelines

  • To set a value, you must manually add this property to the TdgssUserConfigFile.xml on the mechanisms that require it. See Editing Configuration Files.
  • 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.