16.10 - Examples Using Lightweight LDAP Authorizations - Teradata Database

Teradata Database Security Administration

prodname
Teradata Database
vrm_release
16.10
created_date
June 2017
category
Administration
Security
featnum
B035-1100-161K
The following examples show how to use <AuthSearch> to enable lightweight LDAP authorizations.

For an explanation of <AuthSearch> elements, such as Ref, Base, Scope, and so on, see AuthSearch.

Example: <AuthSearch> in the <Mechanism> Section of TdgssUserConfigFile.xml

The example uses a default scope=”subtree”, default MemberAttribute=”member”, and default NamingAttribute=”cn”.

If the base is 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. So the default value of base comes from LdapBaseFQDN which is “dc=example,dc=com”.

In this case, a search of dc=example,dc=com is done. The search matches the contents of the attribute named member with the DN of the principal that represents the user logging on. The contents of the Common Name (CN) attribute are fetched and merged into a list that becomes the list of groups. The generated search filter used for directory search is (member=dn-of-principal).

<Mechanism Name="ldap">    
    <MechanismProperties       
      AuthenticationSupported="yes"       
      AuthorizationSupported="yes"       
      LdapBaseFQDN="dc=example,dc=com"       
       … /> 
    <AuthSearch/>

</Mechanism>
For information about LdapBaseFQDN and LdapGroupBaseFQDN, see Configuring LDAP Properties to Narrow the Search Base.

Example: <AuthSearch> in the <LdapConfig> Section of TdgssUserConfigFile.xml

In the example, if the user is authenticated in the service “my-svc”, then the <AuthSearch> elements whose Ref attributes contain “my-svc” are used to locate the lightweight authorizations for the user. And the search filter used to search the directory is (member=dn-of-principal).

<Mechanism Name="ldap">

    <MechanismProperties
        AuthenticationSupported="yes"
        AuthorizationSupported="yes"
        UseLdapConfig="yes"
        … />

</Mechanism>
…

<LdapConfig>
    …

    <Services>
        <Service
            Id="my-svc"
            LdapBaseFQDN="dc=example,dc=com"
            … />
        …
    </Services>

    <Canonicalizations>
        <AuthSearch Ref="my-svc”/>
        …
    </Canonicalizations>
    …
</LdapConfig>

Example: Using Nested Groups in Active Directory

In this example, the extensible match operator LDAP_MATCHING_RULE_IN_CHAIN is added to the search filter by including the OID in the MemberAttribute. The OID 1.2.840.113556.1.4.1491 asks Active Directory to find all groups that claim the user as a member. For example, if group A were a member of group B and the user is a member of group A, then this match causes both groups A and B to be returned. The user has a membership in group B because the user is a member of group A and group A is a member of group B. If the OID were dropped from the MemberAttribute attribute’s value, then the search would yield only group A. The search filter used to do the directory search is (member:1.2.840.113556.1.4.1491:=dn-of-principal).

This kind of search performs poorly in Active Directory because it requires multiple passes over the directory information tree. The more deeply nested a candidate group is, the worse the search performs. Teradata does not recommend this kind of search in high performance environments, but it is presented here to illustrate the flexibility of the <AuthSearch> element.

<Mechanism Name="ldap">

    <MechanismProperties
        AuthenticationSupported="yes"
        AuthorizationSupported="yes"
        LdapBaseFQDN="dc=example,dc=com"
        … />

    <AuthSearch
        MemberAttribute="member:1.2.840.113556.1.4.1491:"
        Base=”dc=example,dc=com”
        Scope=”subtree”
        NamingAttribute=”cn”
        <AuthSearchMap Match=".+" Pattern="${0}"/> 
    />

</Mechanism>

For information about supported match operators, see the documentation for your particular directory server.

Example: Using groupOfUniqueNames in <AuthSearch>

In the example, ObjectClass is used to construct a search filter. ObjectClass names the object class of the authorization entry and causes an objectClass term to be included in the search. In the example, the search filter used in the directory search is (&(ObjectClass=groupOfUniqueNames)(uniqueMember=dn-of-principal)).

<Mechanism Name="ldap">

    <MechanismProperties
        AuthenticationSupported="yes"
        AuthorizationSupported="yes"
        LdapBaseFQDN="dc=example,dc=com"
        … />
    <AuthSearch
        ObjectClass="groupOfUniqueNames"
        MemberAttribute="uniqueMember"/>

</Mechanism>
For more information on ObjectClass, see AuthSearch.

Example: Using Multiple <AuthSearch> Elements

The example performs three different searches each with subtree scope. Each search gets its own search base. The generated search filter is “(member=dn-of-principal)” and the role names are gathered from the values in the returned object’s CN attribute.

<Mechanism Name="ldap">

    <MechanismProperties
        AuthenticationSupported="yes"
        AuthorizationSupported="yes"
        LdapBaseFQDN="dc=example,dc=com"
        … />

    <AuthSearch
        Base="ou=groups,ou=americas,dc=example,dc=com"/>
    <AuthSearch
        Base="ou=groups,ou=emea,dc=example,dc=com"/>
    <AuthSearch
        Base="ou=groups,ou=apj,dc=example,dc=com"/>

</Mechanism>

Example: Using Multiple AuthSearchMap Elements in <AuthSearch>

In the example, the generated search filter used for directory search is (member=dn-of-principal) and group names are returned from the directory search. If the directory group name is manager then the external role in the Teradata database is admin. If the directory group name is socal then the external role in the Teradata database is tduser.

<Mechanism Name="ldap">

    <MechanismProperties
        AuthenticationSupported="yes"
        AuthorizationSupported="yes"
        LdapBaseFQDN="dc=example,dc=com"
        … />

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

</Mechanism>