Ref、Base、Scopeなどの<AuthSearch>要素の説明については、<AuthSearch>を参照してください。
例: TdgssUserConfigFile.xmlの<Mechanism>セクションにある<AuthSearch>
この例は、デフォルトのscope=”subtree”、デフォルトのMemberAttribute=”member”、およびデフォルトのNamingAttribute=”cn”を使用します。
基準値が指定されていない場合、値はメカニズムまたはサービスのLdapGroupBaseFQDNプロパティから取得されます。LdapGroupBaseFQDNプロパティが指定されていない場合、値はLdapBaseFQDNから取得されます。そのため基準のデフォルト値は"dc = example、dc = com"とするLdapBaseFQDNから取得されます。
この場合、dc = example、dc = comとする検索が行なわれます。その結果、メンバー属性の内容とログオンしているユーザーを表わすプリンシパルDNが一致するものが抽出されます。Common Name(CN)属性の内容がフェッチされ、リストにマージされてグループ リストになります。生成されるディレクトリ検索に使用される検索フィルタは(member = dn-of-principal)です。
<Mechanism Name="ldap"> <MechanismProperties AuthenticationSupported="yes" AuthorizationSupported="yes" LdapBaseFQDN="dc=example,dc=com" … /> <AuthSearch/> </Mechanism>LdapBaseFQDNとLdapGroupBaseFQDNについては、LDAPプロパティを構成しての検索ベースの絞り込みを参照してください。
例: TdgssUserConfigFile.xmlの<LdapConfig>セクションにある<AuthSearch>
この例では、ユーザーがサービス "my-svc"で認証されている場合、Ref属性に"my-svc"が含まれる<AuthSearch>要素が使用され、ユーザーの簡易認証が検索されます。ディレクトリの検索に使用される検索フィルタは(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>
例: Active Directoryで入れ子グループの使用
この例では、拡張マッチ演算子LDAP_MATCHING_RULE_IN_CHAINがOIDをMemberAttributeに含めることによって検索フィルタに追加されます。OID 1.2.840.113556.1.4.1491はActive Directoryに対してユーザーがメンバーとなっているすべてのグループを検索するように要求します。例えば、グループAがグループBのメンバーであり、ユーザーがグループAのメンバーである場合、ユーザーは両方のグループに含まれるためグループAとBが返されます。ユーザーはグループAのメンバーであり、グループAはグループBのメンバーであるため、ユーザーはグループBのメンバーシップを持っています。OIDがMemberAttribute属性の値から削除された場合、検索結果はグループAだけになります。ディレクトリ検索に使用される検索フィルタは(member:1.2.840.113556.1.4.1491:=dn-of-principal)です。
このタイプの検索はディレクトリ情報ツリーに対する複数のパスを必要とするため、Active Directoryではうまく機能しません。候補グループがより深くネストされているほど、検索結果はふるいません。Teradataは高性能環境でこのような検索を行なうことを推奨していませんが、<AuthSearch>要素の柔軟性を示すためにここで説明しています。
<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>
サポートされているマッチ演算子については、お使いのディレクトリ サーバーのドキュメントを参照してください。
例: <AuthSearch>でgroupOfUniqueNamesの使用
この例では、ObjectClassを使用して検索フィルタを構築しています。ObjectClassは許可エントリのオブジェクト クラスを命名し、単語objectClassを検索に含めます。この例のディレクトリ検索で使用される検索フィルタは(&(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>ObjectClassの詳細については、<AuthSearch>を参照してください。
例: 複数の<AuthSearch>要素の使用
この例では、サブツリー スコープに対する3つの異なる検索を実行します。各検索は独自の検索基準を取得します。生成される検索フィルタは “(member=dn-of-principal)”であり、ロール名は返されたオブジェクトのCN属性値から構成されます。
<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>
例: <AuthSearch>で複数のAuthSearchMap要素の使用
この例では、ディレクトリ検索に使用される生成検索フィルタは(member=dn-of-principal)であり、グループ名がディレクトリ検索から返されます。ディレクトリ グループ名がmanagerの場合、Teradata Database内の外部ロールはadminです。ディレクトリ グループ名がsocalの場合、Teradata Database内の外部ロールは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"/> </AuthSearch> </Mechanism>