test

Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)

サービス検索記述子 (SSD) とスキーママッピング

注 –

スキーママッピングは、注意深くかつ一貫した方法で使用する必要があります。 マッピングされた属性の構文が、マッピング先の属性との一貫性を保持していることを確認してください。 つまり、単一値の属性が単一値の属性にマッピングされ、属性の構文が一致しており、マッピングされたオブジェクトクラスが適正な必須 (通常はマッピングされた) 属性を保持することを確認します。

前述したように、LDAP ネームサービスはデフォルトで、DIT が特定の方法で構築されているという想定のもとに動作します。 必要に応じて、DIT 内のデフォルト以外の場所を検索するように Solaris LDAP ネームサービスに指示することができます。 また、デフォルトスキーマで指定された属性やオブジェクトクラスの代わりに、別の属性やオブジェクトクラスを指定して使用することもできます。 デフォルトフィルタの詳細については、LDAP ネームサービスで使用されるデフォルトフィルタを参照してください。

SSD の説明

serviceSearchDescriptor 属性 は、LDAP ネームサービスクライアントが特定のサービスに関する情報を検索する方法および場所を定義します。 serviceSearchDescriptor には、サービス名に続き、1 つ以上のセミコロンで区切られたベース - スコープ - フィルタのセットが含まれます。 これらのベース - スコープ - フィルタのセットは特定のサービス専用の検索定義に使用され、指定された順番で検索されます。 特定のサービスに対して複数のベース - スコープ - フィルタが指定されている場合、このサービスは、特定のエントリを検索する際、指定されたスコープおよびフィルタを保持する各ベースを検索します。

注 –

SSD では、デフォルト位置は SSD に含められていない限り、サービス (データベース) の検索対象にはなりません。 サービスに複数の SSD が指定されている場合、予期しない結果になることがあります。

次の例では、Solaris LDAP ネームサービスクライアントが、passwd サービスに対して、ou=west,dc=example,dc=com で 1 レベルの検索を実行し、次に ou=east,dc=example,dc=com で 1 レベルの検索を実行します。 ユーザーの username に対して passwd データを検索する場合、各 BaseDN に対してデフォルトの LDAP フィルタ (&(objectClass=posixAccount)(uid=username)) が使用されます。 


serviceSearchDescriptor: passwd:ou=west,dc=example,dc=com;ou=east,
dc=example,dc=com

次の例では、Solaris LDAP ネームサービスクライアントは、ou=west,dc=example,dc=com 内でpasswd サービスのサブツリー検索を実行します。 ユーザー username の passwd データを検索する場合、LDAP フィルタ (&(fulltimeEmployee=TRUE)(uid=username)) を使用して、サブツリー ou=west,dc=example,dc=com が検索されます。


serviceSearchDescriptor: passwd:ou=west,dc=example,
dc=com?sub?fulltimeEmployee=TRUE

特定のサービスタイプに複数のコンテナを関連付けることも可能です。

たとえば、次のサービス検索記述子は、3 つのコンテナ、ou=myuser,dc=example,dc=com、ou=newuser,dc=example,dc=com、および ou=extuser,dc=example,dc=com でパスワードエントリを検索することを指定しています。 末尾に「,」がある場合には、SSD の相対ベースに defaultSearchBase が付加されることを意味します。


defaultSearchBase: dc=example,dc=com
serviceSearchDescriptor: \
passwd:ou=myuser;ou=newuser,ou=extuser,dc=example,dc=com

スキーママップ

Solaris LDAP ネームサービスを使用すると、1 つ以上の属性名をいずれかのサービスに再マッピングできます (Solaris LDAP クライアントは、第 18 章「LDAP の一般的なリファレンス 」に記載されているよく知られている属性を使用します)。 属性を対応づける場合、その属性が元の属性と同じ意味および構文を必ず保持するようにしてください。 userPassword 属性を対応づけると、問題が発生する場合があります。

スキーママッピングを使用する理由として、次の 2 つが挙げられます。

この属性の書式は、service:attribute-name=mapped-attribute-name です。

指定されたサービスに対して複数の属性を対応づける場合は、複数の attributeMap 属性を定義できます。

次の例では、uid および homeDirectory 属性を passwd サービスで利用する場合、常に employeeName および home 属性が使用されます。 


attributeMap: passwd:uid=employeeName
attributeMap: passwd:homeDirectory=home

passwd サービスの gecos 属性を複数の属性に対応づける場合、特殊なケースが 1 つ存在します。 次に例を示します。 


attributemap: gecos=cn sn title

上の例では、gecos 値が、空白で区切られた cn、sn、および title 属性値のリストに対応づけられます。

objectClass マップ

Solaris LDAP ネームサービスを使用すると、オブジェクトクラスを任意のサービス用に対応づけしなおすことができます。 特定のサービス用に複数のオブジェクトクラスを対応づける場合、複数の objectclassMap 属性を定義できます。 次の例では、posixAccount オブジェクトクラスを使用する場合、常に myUnixAccount オブジェクトクラスが使用されます。 


objectclassMap: passwd:posixAccount=myUnixAccount