NIS から LDAP への移行サービスの設定
次の 2 つの手順に示すように、標準のマッピングとカスタムマッピングのどちらかを使用して、N2L サービスを設定できます。
NIS から LDAP への変換作業の一部として、inityp2l コマンドを実行する必要があります。このコマンドは、対話型で、構成情報を入力するスクリプトを実行します。次のリストに、構成に必要な情報の種類を示します。これらの属性の詳細については、ypserv(1M) のマニュアルページを参照してください。
-
作成する構成ファイルの名前 (デフォルト = /etc/default/ypserv)
-
LDAP の構成情報を格納する DN (デフォルト = ypserv)
-
LDAP との間でデータをマッピングするための優先サーバーリスト
-
LDAP との間でデータをマッピングするための認証方式
-
LDAP との間でデータをマッピングするための TLS (Transport Layer Security)
-
LDAP との間でデータを読み書きするためのプロキシのユーザーバインド DN
-
LDAP との間でデータを読み書きするためのプロキシのユーザーパスワード
-
LDAP バインド動作のタイムアウト値 (秒単位)
-
LDAP 検索動作のタイムアウト値 (秒単位)
-
LDAP 変更動作のタイムアウト値 (秒単位)
-
LDAP 追加動作のタイムアウト値 (秒単位)
-
LDAP 削除動作のタイムアウト値 (秒単位)
-
LDAP サーバーでの検索動作の制限時間 (秒単位)
-
LDAP サーバーでの検索動作の制限サイズ (バイト単位)
-
N2L が LDAP 照会に従うかどうか
-
LDAP 検索のエラー処理、検索試行回数、および各試行間のタイムアウト (秒単位)
-
格納のエラー処理、検索試行回数、および各試行間のタイムアウト (秒単位)
-
マッピングファイル名
-
auto_direct マップのマッピング情報を生成するかどうか
スクリプトは、マッピングファイル内の適切な位置にカスタムマップについての情報を配置します。
-
ネーミングコンテキスト
-
パスワードの変更を有効にするかどうか
-
任意のマップのデフォルトの TTL 値を変更するかどうか
注 –
sasl/cram-md5 認証は、Sun Java System Directory Server を含むほとんどの LDAP サーバーではサポートされません。
標準マッピングを使用して N2L サービスを設定する方法
「サポートされる標準マッピング」にリストされているマップを移行する場合は、この手順に従います。カスタムマップまたは非標準マップを使用している場合 は、「カスタムマッピングまたは非標準マッピングを使用して N2L サービスを設定する方法」を参照してください。
LDAP サーバーの設定が終わったら、inityp2l スクリプトを実行して、プロンプトに従って構成情報を入力します。inityp2l は構成を行い、標準および auto.* マップのためのマッピングファイルを設定します。
-
「NIS から LDAP への移行のための前提条件」にリストされた前提条件の手順を完了します。
-
NIS マスターサーバーで、スーパーユーザーになるか、同等の役割になります。
役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の第 9 章「役割によるアクセス制御の使用 (手順)」を参照してください。
-
NIS マスターサーバーを N2L サーバーに変換します。
# inityp2l
NIS マスターサーバーで inityp2l スクリプトを実行して、プロンプトに従います。指定が必要な情報のリストは、「NIS から LDAP への移行サービスの設定」を参照してください。
詳細については、inityp2l(1M) のマニュアルページを参照してください。
-
LDAP ディレクトリ情報ツリー (DIT) が完全に初期化されているかどうかを判定します。
NISLDAPmapping ファイルにリストされたすべてのマップの配備に必要な情報がすでに DIT 内に存在する場合、DIT は完全に初期化されています。
-
NIS ソースファイルから移行するため、DIT を初期化します。
DIT が完全に初期化されていない場合に限って、次の手順を実行してください。
-
以前の NIS マップが最新の状態になっていることを確認してください。
# cd /var/yp # make
詳細については、ypmake(1M) のマニュアルページを参照してください。
-
NIS デーモンを停止します。
# svcadm disable network/nis/server:default
-
以前のマップを DIT にコピーしてから、マップ用の N2L サポートを初期化します。
# ypserv -Ir
ypserv が終了するまで待ちます。
ヒント –元の NIS dbm ファイルは上書きされません。必要に応じて、これらのファイルを回復できます。
-
NIS デーモンを起動し、デーモンが新しいマップを使用していることを確認します。
# svcadm enable network/nis/server:default
これで、標準マップでの N2L サービスの設定を完了します。手順 6 を行う必要はありません。
-
-
NIS マップを初期化します。
DIT が完全に初期化され、手順 5 をスキップした場合に限って、次の手順を実行してください。
カスタムマッピングまたは非標準マッピングを使用して N2L サービスを設定する方法
次の状況に適合する場合、この手順を実行してください。
-
「サポートされる標準マッピング」にリストされていないマップがある
-
RFC 2307 とは異なるマッピングで LDAP にマップしたい標準の NIS マップがある
-
「NIS から LDAP への移行のための前提条件」にリストされた前提条件の手順を完了します。
-
NIS マスターサーバーで、スーパーユーザーになるか、同等の役割になります。
役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の第 9 章「役割によるアクセス制御の使用 (手順)」を参照してください。
-
NIS マスターサーバーを N2L サーバーに構成します。
# inityp2l
NIS マスターサーバーで inityp2l スクリプトを実行して、プロンプトに従います。指定が必要な情報のリストは、「NIS から LDAP への移行サービスの設定」を参照してください。
詳細については、inityp2l(1M) のマニュアルページを参照してください。
-
/var/yp/NISLDAPmapping ファイルを修正します。
マッピングファイルの修正方法の例は、「カスタムマップの例」を参照してください。
-
LDAP ディレクトリ情報ツリー (DIT) が完全に初期化されているかどうかを判定します。
NISLDAPmapping ファイルにリストされたすべてのマップの配備に必要な情報がすでに DIT 内に存在する場合、DIT は完全に初期化されています。
-
初期化されていない場合、手順 6、手順 8、および手順 9 を完了します。
-
初期化されている場合、手順 6 をスキップして、手順 7、手順 8、および手順 9 を完了します。
-
-
NIS ソースファイルから移行するため、DIT を初期化します。
-
以前の NIS マップが最新の状態になっていることを確認してください。
# cd /var/yp # make
詳細については、ypmake(1M) のマニュアルページを参照してください。
-
NIS デーモンを停止します。
# svcadm disable network/nis/server:default
-
以前のマップを DIT にコピーしてから、マップ用の N2L サポートを初期化します。
# ypserv -Ir
ypserv が終了するまで待ちます。
ヒント –元の NIS dbm ファイルは上書きされません。必要に応じて、これらのファイルを回復できます。
-
NIS デーモンを起動し、デーモンが新しいマップを使用していることを確認します。
# svcadm enable network/nis/server:default
-
手順 7 をスキップして、手順 8 から続行します。
-
-
NIS マップを初期化します。
DIT が完全に初期化されている場合に限って、この手順を実行します。
-
LDAP エントリが正しいことを確認します。
エントリが間違っている場合、LDAP ネームサービスクライアントからはそのエントリを見つけられません。
# ldapsearch -h server -s sub -b "ou=servdates, dc=..." \ "objectclass=servDates"
-
LDAP_ マップの内容を確認します。
次に、makedbm を使用して servdate.bynumber マップの内容を確認する方法の例を示します。
# makedbm -u LDAP_servdate.bynumber plato: 1/3/2001 johnson: 2/4/2003,1/3/2001 yeats: 4/4/2002 poe: 3/3/2002,3/4/2000
出力結果が期待どおりの内容であれば、NIS から LDAP への移行は成功です。
元の NIS dbm ファイルは上書きされないことに注意してください。したがって、いつでもこれらのファイルは回復できます。詳細については、「NIS に戻す方法」を参照してください。
カスタムマップの例
次の 2 つの例に、マップをカスタマイズする方法を示します。必要に応じて、任意のテキストエディタを使用して、/var/yp/NISLDAPmapping ファイルを修正します。ファイルの属性と構文については、NISLDAPmapping(4) のマニュアルページと第 9 章LDAP 基本コンポーネントおよび概念 (概要)の LDAP ネームサービス情報を参照してください。
例 1-ホストエントリの移動
この例では、DIT でデフォルトの位置から別の (非標準の) 位置にホストエントリを移動する方法を示します。
NISLDAPmapping ファイルの nisLDAPobjectDN 属性を、新しいベース LDAP 識別名 (DN) に変更します。この例では、LDAP オブジェクトの内部構造は変更されません。したがって、objectClass エントリは変更されません。
変更前:
nisLDAPobjectDN hosts: \
ou=hosts,?one?, \
objectClass=device, \
objectClass=ipHost
|
変更後:
nisLDAPobjectDN hosts: \
ou=newHosts,?one?, \
objectClass=device, \
objectClass=ipHost
|
この変更によって、エントリは次のようにマッピングされます。
dn: ou=newHosts, dom=domain1, dc=sun, dc=com
元は、次のようでした。
dn: ou=hosts, dom=domain1, dc=sun, dc=com.
例 2-カスタムマップの実装
この例では、カスタムマップの実装方法を示します。
仮想のマップ「servdate.bynumber」には、システムのサービス日付についての情報が含まれます。このマップには、マシンのシリアル番号でインデックスが付けられます。この例では、123 です。各エントリは、マシンの所有者名、コロン、およびサービス日付のコンマ区切りのリストで構成されます。たとえば、John Smith:1/3/2001,4/5/2003 のようになります。
古いマップ構造は、次の形式の LDAP エントリにマップされます。
dn: number=123,ou=servdates,dc=... \
number: 123 \
userName: John Smith \
date: 1/3/2001 \
date: 4/5/2003 \
.
.
.
objectClass: servDates
|
NISLDAPmapping ファイルを調べると、必要なパターンに最も近いマッピングが group であることがわかります。カスタムマッピングは group マッピングを参考にできます。マップは 1 つだけなので、nisLDAPdatabaseIdMapping 属性は不要です。NISLDAPmapping に追加される属性は、次のとおりです。
nisLDAPentryTtl servdate.bynumber:1800:5400:3600
nisLDAPnameFields servdate.bynumber: \
("%s:%s", uname, dates)
nisLDAPobjectDN servdate.bynumber: \
ou=servdates, ?one? \
objectClass=servDates:
nisLDAPattributeFromField servdate.bynumber: \
dn=("number=%s,", rf_key), \
number=rf_key, \
userName=uname, \
(date)=(dates, ",")
nisLDAPfieldFromAttribute servdate.bynumber: \
rf_key=number, \
uname=userName, \
dates=("%s,", (date), ",")
|
- © 2010, Oracle Corporation and/or its affiliates