<AuthSearch> - Analytics Database - Teradata Vantage

Security Administration

Deployment
VantageCloud
VantageCore
Edition
Enterprise
IntelliFlex
VMware
Product
Analytics Database
Teradata Vantage
Release Number
17.20
Published
June 2022
Language
English (United States)
Last Update
2023-12-11
dita:mapPath
hjo1628096075471.ditamap
dita:ditavalPath
qkf1628213546010.ditaval
dita:id
zuy1472246340572
lifecycle
latest
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 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.

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.

Base [Optional] If not provided, the value is taken from the mechanism or service LdapGroupBaseFQDN property. The value defines the location where the search is to start to locate the group-like entries that represent Vantage external roles.
Scope [Optional] This attribute specifies the search scope. It takes the 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 [Optional] 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.
  • The ObjectClass "groupOfUniqueNames" has 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 is 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 is of the form:

(member-attribute-name=dn-of-principal)

NamingAttribute [Optional] 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 [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 <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 is 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) are added to a roles list. The roles list is returned after successful authentication. These roles are used for database logon.