識別ボールトの環境を適切に設定する必要があります。たとえば、サーバには、識別ボールトのツリー名をサーバ参照に解決するために使用できる方法(サービスまたは指定のファイル)が存在している必要があります。このセクションは、識別ボールトをインストールする前に、ご使用の環境を準備するために役立ちます。
サーバ名にピリオドが使用されているWindowsサーバをディレクトリツリーに追加できます。たとえば、O=netiq.com、C=u.s.aなどです。ただし、ツリー内のコンテナの名前にピリオド(「.」)が含まれている場合は、エスケープ文字を使用する必要があります。次の考慮事項を確認してください。
サーバ名の先頭にピリオドを使用しないでください。たとえば、.netiqなどです。
コンテナ名のピリオドは、円記号(「\」)でエスケープします。次に例を示します。
O=novell\.com
または
C=a\.b\.c
iMonitor、iManager、DHost iConsole、DSRepair、Backup、DSMerge、DSLogin、およびldapconfigなどのユーティリティの、ドットが含まれている管理者名およびコンテキストを入力する場合も、エスケープ文字を使用してください。たとえば、iMonitorにログインする場合、ツリー内のOの名前がnetiq.comである場合、「'admin.netiq\.com'」または「admin.netiq\.com」と入力します。
識別ボールトインフラストラクチャをインストールする前に、サーバには、識別ボールトのツリー名をサーバ参照に解決するために使用できる方法(サービスまたは指定のファイル)が存在している必要があります。NetIQでは、サービスロケーションプロトコル(SLP)サービスを使用してツリー名を解決することをお勧めします。eDirectoryの以前のバージョンには、OpenSLPが含まれていました。しかし、eDirectory 8.8以降、OpenSLPは含まれなくなりました。SLPサービスを別途インストールするか、hosts.ndsファイルを使用する必要があります。SLPサービスを使用する場合は、サービスのディレクトリエージェント(SLPDA)が安定している必要があります。
この節では、次のトピックについて説明します。
hosts.ndsファイルは、識別ボールトアプリケーションが識別ボールトパーティションおよびサーバを検索するために使用するスタティックなルックアップテーブルです。SLP DAがネットワークに存在しない場合、このファイルは、SLPマルチキャストによる遅延を回避するために役立ちます。各ツリーまたはサーバについて、次の情報をhosts.ndsファイルに1行で指定する必要があります。
サーバ名またはツリー名: ツリー名は後続ドット(.)で終了します。
インターネットアドレス: DNS名の場合もあればIPアドレスの場合もあります。localhostは使用しないでください。
サーバポート: オプションです。インターネットアドレスにコロン(:)が付加されます。
サーバがデフォルト以外のNCPポートをリスンする場合を除き、ファイル内のローカルサーバのエントリを含める必要はありません。
hosts.ndsファイルを設定するには:
新しいファイルを作成するか、既存のhosts.ndsファイルを開きます。
次の情報を追加します。
partition_name.tree_name. host_name/ip-addr:port server_name dns-addr/ip-addr:port
次に例を示します。
# This is an example of a hosts.nds file: # Tree name Internet address/DNS Resolvable Name CORPORATE. myserver.mycompany.com novell.CORPORATE. 1.2.3.4:524 # Server name Internet address CORPSERVER myserver.mycompany.com:524
(オプション)後で、SLPを使用してツリー名を解決し、識別ボールトツリーをネットワークで使用できるようにすることを決めた場合は、hosts.ndsファイルに次のテキストを追加します。
/usr/bin/slptool findattrs services:ndap.novell///(svcname-ws==[treename or *])"
たとえば、svcname-ws属性が値SAMPLE_TREEと一致するサービスを検索するには、次のコマンドを入力します。
/usr/bin/slptool findattrs services:ndap.novell///(svcname-ws==SAMPLE_TREE)"
メモ:SLPおよび識別ボールトをインストールした後、この操作を実行します。
svcname-ws属性がSAMPLE_TREEとして登録されたサービスがある場合、出力はservice:ndap.novell:///SAMPLE_TREEのようになります。それ以外の場合、出力応答はありません。
OpenSLPは、IETF Service Location Protocol Version 2.0規格のオープンソースによる実装です。この規格は、IETF Request-For-Comments (RFC) 2608で文書化されました。
OpenSLPソースコードが提供するインタフェースは、SLP機能にプログラム的にアクセスするための別のIETF規格を実装したもので、RFC 2614で文書化されています。
SLPの動作を完全に理解するため、前述の文書を読んで修得することをお勧めします。読みやすい文書ではありませんが、インターネットでのSLPの正しい設定を行うためには重要なドキュメントです。
OpenSLPプロジェクトの詳細については、OpenSLPおよびSourceForgeのWebサイトを参照してください。OpenSLPのWebサイトには、環境設定に関する貴重なヒントを含んださまざまな文書があります。ただし、このガイドの公開時点では、これらのドキュメントの多くは未完成です。
このセクションでは、SLPの使用、およびSLPが識別ボールトとどのように関連するかについて説明します。このセクションには、次のトピックがあります。
NovellのバージョンのSLPでは、強力なサービスアドバータイズ環境を提供するため、SLP標準が一部変更されます。しかし、このために一部の拡張性を犠牲にしています。
たとえば、サービスアドバータイズのフレームワークの拡張性を改善するために、サブネット上でのブロードキャストまたはマルチキャストのパケット数が制限されます。SLPの仕様では、これを管理するために、ディレクトリエージェントのクエリに関してサービスエージェントおよびユーザエージェントに制限を加えています。必要なスコープに対応するための最初に検出されたディレクトリエージェントは、サービスエージェント(つまり結果的にローカルユーザエージェント)がそのスコープ上の将来の要求すべてに使用するエージェントとなります。
NetIQ SLPを実装すると、クエリ情報の検索について既知のディレクトリエージェントをすべてスキャンします。スキャンの所要時間は300ミリ秒とかなり長く、したがって、約3～5秒以内で10台のサーバしかスキャンできません。SLPがネットワーク上で正しく設定されている場合にはこのような検索の必要はありません。OpenSLPでは、ネットワークが実際にSLPトラフィック用に設定されていると見なされます。OpenSLPの応答タイムアウト値はNetIQのSLPサービスプロバイダの応答タイムアウト値よりも大きい値です。ディレクトリエージェント数は、エージェントの情報が正確で完全であるかどうかに関係なく、最初に応答するディレクトリエージェントに制限されます。
ユーザエージェント(UA)の物理形式は、アプリケーションにリンクされたスタティックライブラリまたはダイナミックライブラリです。ユーザエージェントにより、アプリケーションはSLPサービスに対して問い合わせることができます。ユーザエージェントは、クライアントがサービスを問い合わせたり、サービスがそれ自体を通知するためのプログラムインタフェースを提供します。ユーザエージェントはディレクトリエージェントに接続し、指定したスコープ内の指定したサービスクラスに登録されたサービスを問い合わせます。
ユーザエージェントは、アルゴリズムに従って、クエリの送信先になるディレクトリエージェントのアドレスを取得します。指定したスコープのディレクトリエージェントの(DA)アドレスを取得すると、ユーザエージェントはそのスコープから応答がなくなるまで同じアドレスを使用し続けます。応答がなくなると、ユーザエージェントはそのスコープに対する別のDAアドレスを取得します。ユーザエージェントは、指定されたスコープのディレクトリエージェントのアドレスを次の方法で検索します。
現在の要求のソケットハンドルが、指定したスコープのDAに接続されているかどうかを確認する。複数の要求の場合は、すでにキャッシュ化された接続がある可能性がある。
指定したスコープと一致しているDAの、既知のローカルDAキャッシュをチェックする。
指定したスコープでローカルサービスエージェント(SA)に対してDAを確認する(その後キャッシュに新しいアドレスを追加します)。
指定したスコープに一致するDAのネットワーク設定済みのアドレスをDHCPに問い合わせる(その後キャッシュに新しいアドレスを追加します)。
既知のポートでDAの検出要求をマルチキャストする(その後キャッシュに新しいアドレスを追加します)。
スコープを指定しない場合、指定スコープは「デフォルト」になります。つまり、SLP設定ファイルで静的に定義されたスコープがなく、クエリでスコープを指定していない場合は、使用されるスコープは「デフォルト」という単語になります。また、識別ボールトの登録では、スコープを指定しないことに注意してください。スコープが静的に設定されている場合、そのスコープが、すべてのローカルUA要求およびSA登録に対して、指定したスコープがない場合のデフォルトのスコープになります。
サービスエージェントの物理形式は、ホストマシン上での個別のプロセスです。slpd.exeは、ローカルマシン上でサービスとして実行されます。ユーザエージェントは、既知のポート上のループバックアドレスにメッセージを送信することによって、ローカルサービスエージェントを問い合わせます。
サービスエージェントは、SLPで登録されたローカルサービスを持続的に格納し、維持する場所を提供します。サービスエージェントは主として、登録済みのローカルサービスをメモリ内データベースとして維持します。この場合、サービスはローカルSAがない限りSLPで登録できません。クライアントがサービスを検出するのはUAライブラリ内のみですが、登録するにはSAが必要です。これは主に、ディレクトリエージェントを受信して登録を維持するためには、登録済みサービスの存在をSAが定期的に表明する必要があるためです。
サービスエージェントは、潜在DAアドレスにDA検出要求を直接送信することにより、ディレクトリエージェントおよびそれがサポートするスコープリストを検出してキャッシュします。DA検出要求は、次の方法で送信されます。
静的に設定されたDAアドレスをすべてチェックする(その後SAの既知のDAキャッシュに新しいDAアドレスを追加します)。
DHCPからDAとスコープのリストを要求する(その後SAの既知のDAキャッシュに新しいリストを追加します)。
既知のポートでDAの検出要求をマルチキャストする(その後SAの既知のDAキャッシュに新しいポートを追加します)。
DAによって定期的にブロードキャストされたDAのアドバータイズパケットを受信する(その後SAの既知のDAキャッシュに新しいアドバータイズパケットを追加します)。
ユーザエージェントは常に、最初にローカルサービスエージェントに対して問い合わせます。ローカルサービスエージェントの応答によってユーザエージェントが次の検出段階を続行するかどうかが決定されるため、このことは重要な点です (DHCPのこのケースについては、ユーザエージェントのステップ 3およびステップ 4を参照してください)。
ディレクトリエージェントは、通知されたサービスに対して長期間持続的にキャッシュを提供し、ユーザエージェントがサービスを検索するためのアクセスポイントとなります。キャッシュ機能を提供するDAは、SAが新しいサービスを通知するのを受信し、これらの通知をキャッシュします。DAのキャッシュは、短時間でいっぱいになるか、完了します。ディレクトリエージェントは、期限切れのアルゴリズムを使用してエントリキャッシュを有効期限切れにします。ディレクトリエージェントが起動すると、持続的な格納領域(通常はハードドライブ)からキャッシュを読み込み、アルゴリズムに従ってエントリを有効期限切れにします。新しいDAが起動したり、キャッシュが削除されると、DAはこの条件を検出して受信中のすべてのSAに特別な通知を送信します。SAは、DAが直ちにキャッシュを作成できるようにローカルデータベースをダンプします。
ディレクトリエージェントが存在しない場合、UAはSAが応答できる一般的なマルチキャスト方式のクエリを使用し、DAがキャッシュを作成するのとほぼ同じ方法で、要求されたサービスのリストを作成します。このクエリによって返されるサービスのリストは、DAが提供するリストと比較すると不完全かつ局所的です。特に、多くのネットワーク管理者が使用するマルチキャスト方式でのフィルタ処理では、ブロードキャストおよびマルチキャストの対象がローカルサブネットのみに制限されるためです。
つまり、指定されたスコープに対してユーザエージェントが検索するものは、すべてディレクトリエージェントに依存します。
%systemroot%/slp.confファイル内の次のパラメータによって、ディレクトリエージェントの検出が制御されます。
net.slp.useScopes = comma-delimited scope list net.slp.DAAddresses = comma-delimited address list net.slp.passiveDADetection = <"true" or "false"> net.slp.activeDADetection = <"true" or "false"> net.slp.DAActiveDiscoveryInterval = <0, 1, or a number of seconds>
SAの通知先のスコープ、およびサービスまたはクライアントアプリケーションで作成された登録またはクエリに指定したスコープが存在しない場合にクエリが作成されるスコープを示します。識別ボールトは常にデフォルトのスコープに通知し、問い合わせを行うため、このリストが識別ボールトのすべての登録およびクエリに対するデフォルトのスコープリストになります。
コンマで区切られたIPアドレスのリストで、アドレスは10進数とドットで表記されます。このアドレスが他のすべてに対して優先されます。設定されたDAのこのリストが登録またはクエリのスコープをサポートしない場合、検出を無効にしていない限りは、SAおよびUAはマルチキャスト方式でDAを検出します。
デフォルトではTrueです。ディレクトリエージェントは、設定に応じて定期的にそれ自体の存在をサブネットの既知のポート上にブロードキャストします。これらのパケットはDAAdvertパケットと名付けられます。このオプションに「FALSE」を設定した場合、ブロードキャスト方式のすべてのDAAdvertパケットはSAに無視されます。
デフォルトではTrueです。この設定により、SAはすべてのDAに対して、指示されたDAAdvertパケットで応答するように、定期的にブロードキャスト方式で要求できます。指示されたパケットはブロードキャストではありませんが、この要求に対する応答ではSAに直接送信されます。このオプションに「FALSE」を設定した場合、SAは定期的なDAの検出要求をブロードキャストしません。
tri-stateパラメータを表します。デフォルト値は1です。これは、初期化の際に、SAがDAの検出要求を1回送る設定であることを意味する特別な値です。このオプションに0を設定すると、activeDADetectionオプションに「FALSE」を設定した場合と結果は同じです。その他の値は、検出をブロードキャストする間隔を秒数で表します。
このオプションを正しく使用すると、サービスアドバータイズに使用するネットワーク帯域幅を適切に設定できます。ただし、デフォルト設定は平均的なネットワークで拡張性を最適化するように設計されています。
識別ボールトの基盤となるインフラストラクチャであるeDirectoryは、プロセッサ集約というよりはI/O集約アプリケーションです。識別ボールトのパフォーマンスを向上させる2つの要因は、キャッシュメモリの量を増やすことと、プロセッサの処理速度を上げることです。最適な結果を得るためには、ハードウェアで可能な限り多くのDIB (Directory Information Base)セットをキャッシュに入れるようにします。
eDirectoryは単一のプロセッサで適切にスケーリングされますが、複数のプロセッサの使用を検討することも考えられます。プロセッサを追加すると、ユーザログインなどの領域でパフォーマンスが向上します。さらに、複数のプロセッサ上で複数のスレッドをアクティブにすることによってもパフォーマンスが向上します。
次の表は、eDirectory内で想定されるオブジェクトの数に基づく、サーバ設定の一般的なガイドラインを示しています。
|
オブジェクト |
メモリ |
ハードディスク |
|---|---|---|
|
100.000 |
384MB |
144MB |
|
100万 |
4GB |
1.5GB |
|
1,000万 |
2GB以上 |
15GB |
たとえば、標準スキーマを使用する基本的なeDirectoryのインストールでは、50,000ユーザごとに約74MBの空きディスク容量が必要です。ただし、新しい属性のセットを追加したり、既存の属性をすべて使用すると、オブジェクトのサイズは拡大します。それに対応して、必要な空きディスク容量、プロセッサ、およびメモリが変わります。また、プロセッサの要件は、コンピュータで利用できる追加サービス、およびコンピュータが処理している認証と読み書きの数によっても決まります。暗号化や索引付けなどの処理では、プロセッサが集中して使用されることがあります。
識別ボールトでは、IPv4アドレスとIPv6アドレスの両方がサポートされています。識別ボールトのインストール時に、IPv6アドレスを有効にできます。以前のバージョンからアップグレードする場合、IPv6アドレスを手動で有効にする必要があります。
識別ボールトでは、デュアルIPスタック方式、トンネル方式、およびピュアIPv6移行方式をサポートしています。グローバルのIPアドレスのみがサポートされます。次に例を示します。
[::]
[::1]
[2015::12]
[2015::12]:524
IPv6アドレスは、角かっこ[ ]で囲んで指定する必要があります。IPアドレスではなく、ホスト名を用いる場合、C:\Windows\System32\drivers\etc\hostsファイルで名前を指定し、それをIPv6アドレスに関連付ける必要があります。
WindowsサーバでIPv6アドレスを使用するには、インストール時にIPV6の初期設定の下のIPV6を有効にするチェックボックスを選択する必要があります。このオプションにより、IPv6アドレスに対して、NCP、HTTP、およびHTTPSプロトコルが有効になります。インストールプロセス中にIPv6アドレスを有効にせず、後から使用することにした場合は、セットアッププログラムを再度実行する必要があります。詳細については、セクション 7.3, 識別ボールトのインストールを参照してください。
リンクhttp://[2015::3]:8028/ndsを使用して、IPv6アドレスを介してiMontiorにアクセスできます。
識別ボールトをインストールする場合、LDAPサーバが監視するポートを指定して、LDAP要求を処理できるようにする必要があります。デフォルトの設定では、平文とSSL/TLSのポート番号として389と636が設定されます。
LDAP単純バインドでは、DNおよびパスワードのみが要求されます。パスワードは平文形式です。ポート389を使用する場合、すべてのパケットは平文形式です。ポート389では平文が使用できるため、LDAPサーバサービスではこのポートを通じてeDirectoryへの読み込みおよび書き込みを処理します。このポートの使用は開放性が高く、通信に妨害を受けることがなく、パケットが不正受信されない信頼性の高い環境に適しています。デフォルトでは、インストールの実行中にこのオプションは使用できません。
ポート636を通じた接続は暗号化されます。TLS(以前のSSL)によって暗号化が管理されます。ポート636への接続では、自動的にハンドシェークをインスタンス生成します。ハンドシェークが失敗した場合、接続は拒否されます。
メモ:インストールプログラムにより、TLS/SSL通信用にデフォルトでポート636が選択されます。この設定をデフォルトで選択することで、ローカルLDAPサーバに問題が発生する場合があります。eDirectoryがインストールされる前にホストサーバにロードされているサービスがポート636を使用している場合は、別のポートを指定する必要があります。eDirectory 8.7以前のインストールでは、この競合は致命的なエラーとみなされ、nldapはアンロードされます。eDirectory 8.7.3以降、インストールプログラムによってnldapがロードされ、dstrace.logファイルにエラーメッセージが記録されて、セキュリティ保護されたポートを使用せずに実行されます。
インストールプロセスで、平文パスワードおよび他のデータの使用を禁止するように識別ボールトを設定できます。パスワードとの単純バインドにTLSを必要とするオプションによって、閲覧可能なパスワードの送信ができないようになっています。この設定を選択しない場合、ユーザは別の人がパスワードを閲覧しても気が付きません。このオプションは接続を許可しないように設定するもので、平文ポートにのみ適用できます。ポート636に対してセキュリティ保護された接続を行い、単純バインドを実行する場合は、接続はその時点ですでに暗号化されています。このため、パスワード、データパケット、またはバインド要求を閲覧することはできません。
次のシナリオを検討します。
ユーザはパスワードを要求するクライアントを使用しています。パスワードを入力した後、クライアントはサーバに接続します。ただし、LDAPサーバでは平文ポートからサーバにバインドする接続は許可されていません。誰でもユーザのパスワードを見ることができますが、ユーザはバインド接続できません。
ローカルサーバでActive Directoryを実行しています。Active Directoryでは、ポート636を使用してLDAPプログラムを実行しています。eDirectoryをインストールします。インストールプログラムによってポート636がすでに使用されていることが検出されるため、NetIQ LDAPサーバにポート番号は割り当てられません。LDAPサーバはロードを開始し、実行されているように見えますが、。LDAPサーバではすでに開いているポートを複製または使用できないため、複製されたポートでの要求はLDAPサーバで処理されません。
ポート389またはポート636がNetIQ LDAPサーバに割り当てられているかどうかを確認するには、ICEユーティリティを実行します。［ベンダバージョン］フィールドにNetIQが指定されていない場合は、eDirectoryのLDAP Serverを再設定し、別のポートを選択する必要があります。詳細については、『NetIQ eDirectory 管理ガイド』の「LDAPサーバが実行されているか確認する」を参照してください。
Active Directoryが実行中であり、平文ポート389が開いている場合、ポート389にICEコマンドを実行し、ベンダーバージョンを問い合わせることができます。レポートにMicrosoft*が表示されます。次に、別のポートを選択してNetIQ LDAPサーバを再設定します。eDirectory LDAPサーバがLDAPの要求を処理できるようになります。
また、iMonitorでは、ポート389または636がすでに開かれているかどうかもレポートされます。LDAPサーバが動作していない場合、iMonitorを使用して、詳細を特定します。詳細については、『NetIQ eDirectory 管理ガイド』の「LDAPサーバが実行されているか確認する」を参照してください。
iManagerなどの管理ユーティリティを使用するすべてのワークステーションにNICIをインストールする必要があります。NICIを識別ボールトとともに使用する方法の詳細については、識別ボールトのインストールに関する前提条件を参照してください。
NICIをインストールするには、NICI_wx64.msiファイルを使用します。このファイルは、デフォルトではproducts\eDirectory\processor_type\windows\processor_type\niciフォルダにあります。ガイド付きプロセス(ウィザード)として、またはサイレントインストールとしてファイルを実行できます。
NMASログインメソッドを使用する各クライアントワークステーションに、NetIQ Modular Authentication Service (NMAS)クライアントソフトウェアをインストールする必要があります。識別ボールトをインストールするときにログインメソッドを指定します。
管理者アカウントを使用して、クライアントワークステーションにログインします。
インストールディレクトリからnmasinstall.exeプログラムを実行します。デフォルトでは、Win:\products\eDirectory\processor_type\nmas\にあります。
NMASクライアントコンポーネントをクリックします。
(オプション) NICIコンポーネントをインストールするNICIオプションを選択します。
OKをクリックします。
インストールプロセスが完了したら、クライアントワークステーションを再起動します。