eDirectoryは、必ずAzure Virtual Networkのバックエンドサブネット内にデプロイする必要があります。図 4-1は、後続のセクションで説明されているデプロイメントのサンプルを示しています。
図 4-1 Azure上でのeDirectoryのデプロイメント
メモ:
プロキシは、管理者がSSHを使用して接続し、SSHエージェント転送を使用してバックエンドサブネット内の他のインスタンスに接続する、フロントエンドサブネット内の要塞ホストです。
eDirectoryにアクセスする必要があるアプリケーションは、バックエンドサブネットにデプロイする必要があります。これらのアプリケーションにインターネットからアクセスする必要がある場合は、フロントエンドサブネット内にAzureロードバランサーを設定して、アクセスを可能にします。詳細については、「Azure portalを使用してBasic Load Balancerを作成する」を参照してください。
デプロイメント手順は、次のステップで構成されます。
このセクションでは、eDirectoryで使用するAzureサービスを作成するための一般的な手順について概説します。これには、リソースグループ、仮想ネットワーク(VNet)、およびサブネットの作成が含まれます。
重要:仮想ネットワーク、セキュリティグループ、仮想マシンなどのサービスを作成する際には、[場所]に同じ値を指定していることを確認してください。
リソースグループは、Azureソリューションに関連するリソースを保持するコンテナです。リソースグループには、ソリューションのすべてのリソースを含めるか、またはグループとして管理するリソースのみを含めることができます。たとえば、AzureにeDirectoryをデプロイしている間は、リソースグループには仮想マシン、仮想ネットワーク、アプリケーションセキュリティグループ、ネットワークセキュリティグループ、パブリックIPアドレス、ネットワークインターフェイス、およびディスクが含まれている必要があります。リソースグループの作成方法の詳細については、「Azure portalを使用したAzureリソースの管理」を参照してください。
メモ:すべての管理者が、新しいリソースグループを作成する権限を持っているわけではありません。
Azure Virtual Networkを使用すると、Azure仮想マシン(VM)などの多くの種類のAzureリソースが、相互に、インターネットと、そしてオンプレミスのネットワークと安全に通信することができます。詳細については、「Azure Virtual Networkとは」を参照してください。
仮想ネットワークを作成する際には、デフォルトで1つのサブネットが作成されます。複数のサブネットを作成する場合は、新しく作成された仮想ネットワークから、[サブネット]>[サブネットの追加]に移動します。
アプリケーションセキュリティグループを使用すると、アプリケーション構造の自然な拡張としてネットワークセキュリティを設定できます。さらに、仮想マシンをグループ化し、それらのグループに基づいてネットワークセキュリティポリシーを定義することもできます。詳細については、「アプリケーションセキュリティグループ」を参照してください。
ネットワークセキュリティグループを設定する前に、次のアプリケーションセキュリティグループを作成する必要があります。
表 4-1 アプリケーションセキュリティグループ
|
名前 |
説明 |
|---|---|
|
SSH_Proxy |
SSH_Proxyを設定する仮想マシンのネットワークインターフェイスが含まれます |
|
eDirectory |
eDirectoryを設定するすべての仮想マシンのネットワークインターフェイスが含まれます |
|
eDirectory_CA |
ツリー認証局(CA)をホストするeDirectoryサーバが設定される仮想マシンのネットワークインターフェイスが含まれます |
|
iManager |
iManagerが設定される仮想マシンのネットワークインターフェイスが含まれます |
NSGを使用して、サブネットのインバウンドおよびアウトバウンドのネットワークトラフィックをフィルタすることができます。NSGには、ネットワークトラフィックを、IPアドレス、ポート、およびプロトコルによってフィルタするセキュリティルールが含まれています。
このセクションでは、フロントエンドサブネット用にNSGを作成するためのルールについて概説します。デフォルトのセキュリティルールの上に、次のルールを設定します。
インバウンドルール:
表 4-2 フロントエンドサブネットのインバウンドルール
|
優先度 |
名前 |
ポート範囲 |
ソース |
宛先 |
アクション |
説明 |
|---|---|---|---|---|---|---|
|
100 |
SSH |
TCP 22 |
すべて(Any) |
SSH_Proxy (ASG) |
許可 |
インターネットからプロキシサーバへのSSH接続を許可します |
|
110 |
Allow Subnet Traffic |
すべて(Any) |
すべて |
フロントエンドサブネット |
許可 |
(オプション)すべてのサブネット内トラフィックを許可します。 メモ:このルールは、相互に通信する必要のある他の仮想マシンがフロントエンドサブネット内にある場合にのみ設定します。 |
|
120 |
All Traffic |
すべて(All) |
すべて |
すべて |
拒否 |
前のルールによってまだ処理されていないすべてのインバウンドトラフィックを拒否します |
このセクションでは、バックエンドサブネットでNSGを作成するためのルールについて概説します。ネットワークセキュリティグループに対して、次のルールを設定します。
インバウンドルール:
表 4-3 バックエンドサブネットのインバウンドルール
|
優先度 |
名前 |
ポート範囲 |
ソース |
宛先 |
アクション |
説明 |
|---|---|---|---|---|---|---|
|
100 |
SSH |
TCP 22 |
プロキシ(ASG) |
バックエンドサブネット |
許可 |
SSHプロキシからのインバウンドSSHトラフィックを許可します |
|
110 |
iManager |
TCP 8443 |
プロキシ(ASG) |
iManager (ASG) |
許可 |
SSHプロキシからiManagerにアクセスするためのHTTPSトラフィックを許可します |
|
120 |
HTTP CRL |
TCP 8028 |
仮想ネットワーク |
eDirectory_CA (ASG) |
許可 |
ツリーCAによって発行された証明書を使用して設定されているVNetにサービスが存在する場合に、VNetからeDirectoryツリーのCRLにアクセスするために必要です。 |
|
130 |
Allow Subnet Traffic |
すべて(Any) |
バックエンドサブネット |
バックエンドサブネット |
許可 |
すべてのサブネット内トラフィックを許可します |
|
140 |
All Traffic |
すべて(All) |
すべて |
すべて |
拒否 |
すべてのインバウンドトラフィックを拒否します |
セキュリティグループは、仮想ネットワーク内の1つまたは複数の仮想マシンに割り当てることができる仮想ファイアウォールルールのセットです。
デフォルトでは、新しいセキュリティグループではポート22の着信トラフィックのみが許可されるので、インスタンスにはSSHを使用してのみ接続できます。
詳細については、「セキュリティグループ」を参照してください。
AzureにeDirectoryをデプロイするには、次のネットワークセキュリティグループを作成します: eDirectory_NSG_1、eDirectory_NSG_2、およびiManager_NSG。これらのセキュリティグループを作成して次のポートルールを設定し、デフォルトのセキュリティルールを上書きします。
eDirectory_NSG_1: このNSGは、eDirectoryツリーのCAをホストする仮想マシンに関連付ける必要があります。
|
優先度 |
名前 |
ポート範囲 |
ソース |
宛先 |
アクション |
説明 |
|---|---|---|---|---|---|---|
|
100 |
SSH |
TCP 22 |
SSHプロキシ(ASG) |
eDirectory (ASG) |
許可 |
SSHプロキシからのSSHトラフィックを許可します |
|
110 |
NCP |
TCP 524 |
バックエンドサブネット |
eDirectory (ASG) |
許可 |
バックエンドサブネット内でeDirectoryに対するNCPトラフィックを許可します |
|
120 |
HTTP CRL |
TCP 8028 |
仮想ネットワーク |
eDirectory_CA (ASG) |
許可 |
ツリーCAによって発行された証明書を使用して設定されているVNetにサービスが存在する場合に、VNetからeDirectoryツリーのCRLにアクセスするために必要です。 |
|
130 |
LDAPS |
TCP 636 |
バックエンドサブネット |
eDirectory (ASG) |
許可 |
バックエンドサブネット内でセキュリティ保護されたLDAPトラフィックを許可します |
|
140 |
SLP |
Any 427 |
バックエンドサブネット |
eDirectory (ASG) |
許可 |
バックエンドサブネット内のSLPトラフィックを許可します |
|
150 |
All Traffic |
すべて(All) |
すべて |
すべて |
拒否 |
すべてのインバウンドトラフィックを拒否します |
メモ:eDirectoryサーバは、LDAPポート389でリスンするように設定してはならず、eDirectoryに割り当てられているセキュリティグループに対してポート389へのアクセスを許可してはなりません。また、HTTPポートへのアクセスを許可するのは、ツリーのCAをホストしているeDirectoryサーバに割り当てられたセキュリティグループに対してのみにする必要があります。
eDirectory_NSG_2: このNSGは、eDirectoryツリーCA以外のeDirectoryサーバをホストしているすべての仮想マシンに関連付ける必要があります。
|
優先度 |
名前 |
ポート範囲 |
ソース |
宛先 |
アクション |
説明 |
|---|---|---|---|---|---|---|
|
100 |
SSH |
TCP 22 |
SSHプロキシ(ASG) |
eDirectory (ASG) |
許可 |
SSHプロキシからのSSHトラフィックを許可します |
|
110 |
NCP |
TCP 524 |
バックエンドサブネット |
eDirectory (ASG) |
許可 |
バックエンドサブネット内でeDirectoryに対するNCPトラフィックを許可します |
|
120 |
LDAPS |
TCP 636 |
バックエンドサブネット |
eDirectory (ASG) |
許可 |
バックエンドサブネット内でセキュリティ保護されたLDAPトラフィックを許可します |
|
130 |
SLP |
Any 427 |
バックエンドサブネット |
eDirectory (ASG) |
許可 |
バックエンドサブネット内のSLPトラフィックを許可します |
|
140 |
All Traffic |
すべて(All) |
すべて |
すべて |
拒否 |
すべてのインバウンドトラフィックを拒否します |
iManager_NSG: このNSGは、iManagerをホストする仮想マシンに関連付ける必要があります。次のNSGルールを使用すると、プロキシサーバのみからiManagerサーバにアクセスできるようになります。
|
優先度 |
名前 |
ポート範囲 |
ソース |
宛先 |
アクション |
説明 |
|---|---|---|---|---|---|---|
|
100 |
SSH |
TCP 22 |
SSHプロキシ(ASG) |
iManager (ASG) |
許可 |
プロキシからのSSHトラフィックを許可します |
|
110 |
HTTPS |
TCP 8443 |
SSHプロキシ(ASG) |
iManager (ASG) |
許可 |
プロキシからiManagerにアクセスする、セキュリティ保護されたHTTPトラフィックを許可します |
|
120 |
All Traffic |
すべて(All) |
すべて |
すべて |
拒否 |
すべてのインバウンドトラフィックを拒否します |
Azure VMを設定する前に、SSHキーペアを作成する必要があります。キーペアを作成するには、次の手順を実行します。
次のコマンドを使用して、クライアント上で4096ビットのRSA SSHキーペアを作成します。
ssh-keygen -t rsa -b 4096
ssh-keygenにより、新しく作成された公開鍵が~/.ssh/id_rsa.pubに置かれます。
このSSH公開鍵をAzureアカウントに提供します。詳細については、「SSH公開鍵を提供する」を参照してください。
重要:SSH秘密鍵を使用してのみ、仮想マシンに接続して管理できます。そのため、SSH秘密鍵を紛失しないようにしてください。
サポートされているプラットフォームのいずれかで仮想マシン(VM)を作成して起動します。VMを作成して起動する方法の詳細については、「Azure portalでLinux仮想マシンを作成する」を参照してください。インスタンスを作成および起動する際には、次の手順も実行する必要があります。
最初のeDirectoryサーバを設定するVMにeDirectory_NSG_1を関連付け、その他のすべてのeDirectoryサーバを設定するVMにeDirectory_NSG_2を関連付け、iManagerを設定するVMにiManager_NSGを関連付けます。セキュリティグループの詳細については、仮想マシン用のネットワークセキュリティグループの設定を参照してください。
SSHキーペアを作成するセクションで作成した公開鍵をインスタンスに関連付けます。
メモ:選択したAzureの場所に対して複数の可用性ゾーンが使用可能な場合は、レプリカサーバをマスタeDirectoryサーバと同じ可用性ゾーンにデプロイしないでください。
Azure VMのクラッシュが発生した場合にeDirectoryのデータと設定が失われるのを防ぐには、データディスクを設定する必要があります。eDirectoryのデータと設定を復元する方法の詳細については、障害復旧を参照してください。VMを作成した後、次の手順を実行して、eDirectoryをデプロイできるようにVMを準備します。
データディスクを作成して接続するために、「ポータルを利用し、データディスクをLinux VMに接続する」の手順を実行します。
VMにログインし、ext4ファイルシステムを使用してデータディスクをフォーマットし、データディスクをマウントします。データディスクをフォーマットしてマウントする方法の詳細については、「Linux VMを接続して新しいディスクをマウントする」を参照してください。
ディレクトリを、データディスクからeDirectoryデータディレクトリとNICIデータディレクトリにバインドマウントします。ルートユーザとして次の手順を実行して、バインドマウントします。
次のコマンドを使用して、eDirectoryデータディレクトリを作成します。
mkdir <mount_point>/eDirectory_data
次のコマンドを使用して、NICIデータディレクトリを作成します。
mkdir <mount_point>/nici_data
次のコマンドを使用して、NICIおよびeDirectoryの環境設定ディレクトリを作成します。
mkdir <mount_point>/eDirectory_nici_conf
次のコマンドを使用して、eDirectoryに必要なディレクトリを作成します。
mkdir --parents /var/opt/novell/eDirectory mkdir –-parents /var/opt/novell/nici mkdir –-parents /etc/opt/novell/eDirectory
ディレクトリをバインドマウントするために、次の内容を/etc/fstabに追加します。
<mount_point>/eDirectory_data /var/opt/novell/eDirectory none defaults,bind 0 0
<mount_point>/nici_data /var/opt/novell/nici none defaults,bind 0 0
<mount_point>/eDirectory_nici_conf /etc/opt/novell/eDirectory none defaults,bind 0 0
メモ:VM内でのすべての操作は、ルートユーザとして実行する必要があります。
「システム要件」に記載されている要件を満たしていることを確認します。
仮想マシン用のネットワークセキュリティグループの設定で説明されているように、セキュリティグループを作成します。
プロキシVMは、強化され、セキュリティ保護されたサーバである必要があります。バックエンドサブネット内のVMおよびプロキシVMへのアクセスに必要なSSH秘密鍵は、VNet内には保存しないでください。クライアント上にのみ保存してください。このインスタンスに適したパフォーマンスとメモリを提供するVMサイズを選択します。
プロキシVMに対する追加のネットワークインターフェイスを作成し、そのインターフェイスにスタティックなパブリックIPアドレスを割り当てます。
プロキシVM内にVNCサーバを設定します。VNCサーバは、強力なパスワードを使用して強化する必要があります。セキュリティ保護された通信を可能にするために、SSHトンネルを使用してVNCサーバに接続します。VNCサーバは、localhostからの接続についてのみリスンするように設定する必要があります。セッションのロックアウトを防止するために、画面ロックを無効にします。VNCサーバを使用した後、セッションを終了する必要があります。
VMの/etc/hostsファイルを手動で更新して、IP-Address Full-Qualified-Hostname Short-Hostnameエントリを設定します。これは、逆引きDNS検索を実行する際のAzureの制限を回避するためです。
eDirectory/iManagerを設定するバックエンドサブネット内のVMには、SSHプロキシを使用して接続します。
ssh -i edir_key.pem -A -J azureuser@<ssh_proxy_ip> azureuser@<instance_private_ip>
メモ:
上記のサンプルコマンドで、edir_key.pemは、サーバキーを含むサンプルファイル名です。
SSH-Addコマンドを使用してエージェント内に識別情報ファイルを追加すれば、ログインするたびに識別情報ファイルを使用しないで済みます。
VMのプライベートIPアドレスを表示するには、[インスタンス]>[インスタンス]>[説明]をクリックします。
バックエンドサブネット内のVMにSLPディレクトリエージェント(DA)サーバを設定します。SLP DAがデプロイされているVMに対して、NSGのインバウンドルールでポート427を開きます。slp.confファイルを編集して、DA操作を有効にします。詳細については、『NetIQ eDirectory管理ガイド』の「OpenSLP for eDirectoryの設定」を参照してください。
このセクションでは、Azure環境にeDirectoryとiManagerをインストールして設定する手順について説明します。eDirectoryをインストールした後、次の条件を満たしていることを確認する必要があります。
EBAが有効になっている
SNMPが無効になっている
eDirectoryがポート389でリスンしていない
LDAPおよびHTTPサービスは、ECDSA証明書のみを使用するように設定されている
バックエンドサブネット内のAzure VMのSSHポートへのアクセスは、不使用時は無効になっている
iMonitor、eMBox、およびDHostモジュールを無効にして、セキュリティを強化する。これらのモジュールを無効にした後、これらのモジュールに関係するすべてのアクティビティは、NDSユーティリティのみを使用して実行する必要があります。
eDirectoryを設定するバックエンドサブネット内のVMに、セキュアコピー(scp)を使用してeDirectory_<version>_Linux_x86_64.tar.gzファイルをコピーします(SSHプロキシを使用します)。
scp -i <keyname> -o ProxyJump=vm-user@<ssh_proxy_ip> eDirectory_<version>_Linux_x86_64.tar.gz vm-user@<instance_ip>:/<directory>eDirectoryをインストールします。詳細については、「nds-installユーティリティを使用してeDirectoryコンポーネントをインストールする」を参照してください。
eDirectoryを設定します。詳細については、「ndsconfigユーティリティを使用してeDirectoryレプリカサーバを追加または削除する」を参照してください。たとえば、eDirectoryをインストールして設定するためのコマンドのサンプルを次に示します。
ndsconfig new [-t <tree_name>] [-n <server context>] -a <admin FDN> [-w <admin password>] -P ldaps://<instance_ip> --configure-eba-now yesopenslp-serverをインストールして、SLPDサービスを始動します。
iManager管理コンソールを使用すると、Azure環境上でのeDirectoryの操作を管理できます。iManagerは、eDirectoryをインストールした後で、Azure VMにインストールする必要があります。
iManagerを設定するバックエンドサブネット内のインスタンスに、セキュアコピー(scp)を使用してiMan_<version>_linux_x86_64.tgzファイルをコピーします(SSHプロキシを使用します)。
scp -i <keyname> -o ProxyJump=vm-user@<ssh_proxy_ip> iMan_<version>_linux_x86_64.tgz vm-user@<instance_ip>:/<directory>iManagerをインストールして設定します。詳細については、「LinuxでのiManagerサーバのインストール」を参照してください。iManagerをインストールする前に、『iManagerインストールガイド』の「システム要件」セクションに記載されているシステム要件を参照してください。
iManagerが実行されているVMに、EBA CA証明書をダウンロードします。詳細については『NetIQ eDirectory管理ガイド』の「iManagerを使用したEBA CAの管理」を参照してください。
iManagerを実行しているVMの自己署名証明書を、セキュアCA署名証明書で置き換えます。詳細については、「iManager用の一時的な自己署名証明書の置き換え」を参照してください。
メモ:iManager サーバは、ECDSA証明書のみを使用するように設定してください。iManagerをインストールした後、権限を持ったユーザと、このユーザが管理する適切なeDirectoryツリー名を指定します。
次の手順を実行して、iManagerを起動します。
SSHトンネルを使用して、プロキシVMのlocalhost上で実行されているVNCサーバに接続します。
同じインスタンスにブラウザをインストールして起動します。
IPアドレスまたはツリー名を使用して、eDirectoryツリーを起動して接続します。
EBAが有効になっているかどうかを確認するため、『NetIQ eDirectory管理ガイド』「EBAに関する情報の表示」を参照してください。
証明書サーバでSuite Bを有効にします。詳細については、『NetIQ eDirectory管理ガイド』の「証明書サーバでのSuite Bの有効化」を参照してください。
1番目のeDirectoryサーバに対してAES 256ビットツリーキーを設定します。詳細については、『NICI Administration Guide (NICI管理ガイド)』の「Creating an AES 256-Bit Tree Key (AES 256ビットツリーキーを作成する)」を参照してください。
1番目のeDirectoryサーバにあるCRL配布ポイントを削除します。ポート389でのセキュリティ保護されていないLDAPアクセスはすべてのeDirectoryサーバで無効化されているため、ツリーCAのCRLはHTTPのみでダウンロードできるようにする必要があります。次の手順を実行して、CRL配布ポイントを削除します。
管理者としてiManagerにログインします。
[役割およびタスク]>[NetIQ証明書サーバ]>[認証局の環境設定]に移動します。
[CRL]をクリックします。
[One]をクリックします。HTTP CRL配布ポイント(http://<instance_ip>:8028/crl/one.crl)以外のすべての[CRL配布ポイント]を選択して削除します。
[適用]をクリックし、[閉じる]をクリックします。
[OneEC]をクリックします。HTTP CRL配布ポイント(http://<instance_ip>:8028/crl/oneec.crl)以外のすべての[CRL配布ポイント]を選択して削除します。
[適用]をクリックし、[OK]をクリックします。
iManager証明書サーバプラグインを使用して、サーバのデフォルト証明書を修復します。デフォルト証明書を修復するには、次の手順を実行します。
管理者としてiManagerにログインします。
[役割およびタスク]>[NetIQ証明書サーバ]>[デフォルト証明書の修復]に移動します。
証明書を所有するサーバを選択して、[次へ]をクリックします。
[デフォルト証明書はすべて上書きされます]を選択し、[次へ]をクリックします。
実行するタスクを確認し、[完了]を選択します。
ECDSA証明書とSuite B暗号化を使用するようにLDAPサービスとHTTPサービスを設定します。詳細については『NetIQ eDirectory管理ガイド』の「ECDSA証明書とSuite B Cipherを使用するためのLDAPサービスとHTTPサービスの設定」を参照してください。完了したら、eDirectory を再起動します。
SNMPサブエージェントがアンロードされているかどうかを確認する方法について、『NetIQ eDirectory管理ガイド』の「SNMPサーバモジュールのロードとアンロード」を参照します。
eDirectoryがポート389でリスンしていないことを確認します。
iMonitor、eMBox、DHost、およびHTTPスタックを無効にします。
次の手順を実行して、ツリーCAをホストしているeDirectoryサーバのiMonitor、eMBox、およびDHostを無効にします。
ndsmodules.confファイルを編集して、hconserv、imon、およびemboxをコメント化します。
eDirectoryを再起動します。
次の手順を実行して、eDirectoryレプリカサーバのHTTPスタックを無効にします。
ndsmodules.confファイルを編集して、httpstk、hconserv、imon、およびemboxをコメント化します。
eDirectoryを再起動します。
メモ:httpstkは、コメント化の前に、ndsmodules.confファイル内でndsより上に配置されている必要があります。これにより、ndsモジュールはHTTPスタックを有効にしなくなります。
アドバタイジング方式としてユニキャストを使用することをeDirectoryに強制するように、SLPを設定します。バックエンドサブネット内のDAサーバのIPアドレスを提供するように、slp.confファイルを編集します。詳細については、『NetIQ eDirectory管理ガイド』の「環境設定パラメータ」を参照してください。
メモ:すべてのeDirectory VMとiManagerの設定が完了したら、SSHポートへのアクセスを拒否し、必要な場合にのみ許可するように、Azureバックエンドサブネットのセキュリティルールを設定してください。
AzureにCommon Event Format (CEF)監査サービスをデプロイして、さまざまなeDirectoryイベントを監査することができます。CEF監査サービスをデプロイするには、次の手順を実行します。
VNetに監査サーバをインストールします。
ポート上でリスンするように監査サーバを設定します
メモ:監査サーバとしてはSentinelを使用することをお勧めします。
フロントエンドサブネットに新しいネットワークセキュリティグループルールを作成して次のように設定し、監査サーバが実行されているVMに関連付けます。
|
名前 |
ポート |
ソース |
宛先 |
説明 |
|---|---|---|---|---|
|
Auditing Server Port |
TCP (監査サーバポート) |
バックエンドサブネット |
監査サーバのIP |
eDirectoryサーバからのイベントの受信を許可します |
すべてのeDirectoryインスタンスで、次のように/etc/opt/novell/eDirectory/conf/auditlogconfig.propertiesファイルを更新します。
log4j.appender.S.Host=<Auditing server ip> log4j.appender.S.Port=<auditing server port>
iManagerから、対応するCEFイベントを有効にします。詳細については、「監査するCEFイベントの設定」を参照してください。有効にされたイベントは、監査サーバに転送されます。
障害復旧は、eDirectoryが実行されているVMでクラッシュが発生した場合に実行します。障害復旧を行うには、次の手順を実行します。
クラッシュしたVMを停止し、データディスクとの関連付けを解除します。詳細については、「データディスクをLinux仮想マシンから切断する方法」を参照してください。
クラッシュしたVMと同じオペレーティングシステムを使用して、新しいVMを設定します。
新しいVMに同じバージョンのeDirectoryをインストールします。
データディスクを新しいVMに接続し、ファイルシステムをマウントします。詳細については、「ポータルを利用し、データディスクをLinux VMに接続する」を参照してください。
ディレクトリをバインドマウントします。
ディレクトリをバインドマウントするには、/etc/fstabを次のように更新します。
<mount_point>/eDirectory_data /var/opt/novell/eDirectory none defaults,bind 0 0
<mount_point>/nici_data /var/opt/novell/nici none defaults,bind 0 0
<mount_point>/eDirectory_nici_conf /etc/opt/novell/eDirectory none defaults,bind 0 0
/etc/opt/novell/eDirectory/conf/nds.conf内のIPアドレスを、現在のVMのIPアドレスに変更します。
eDirectoryをアップグレードしてヘルスチェックをスキップします。詳細については、『NetIQ eDirectoryインストールガイド』の「eDirectoryをアップグレードする」を参照してください。
ndsrepairユーティリティを使用して、ネットワークアドレスを修復します。詳細については、『NetIQ eDirectory管理ガイド』の「DSRepairオプション」を参照してください。
ツリーCAのIPアドレスが変更された場合は、CRL配布ポイントのIPアドレスを変更します。IPアドレスの変更方法の詳細については、『NetIQ eDirectory管理ガイド』の「CRL環境設定オブジェクトのプロパティの表示と変更」を参照してください。
iManager証明書サーバプラグインを使用して、サーバのデフォルト証明書を修復します。デフォルト証明書を修復するには、次の手順を実行します。
管理者としてiManagerにログインします。
[役割およびタスク]>[NetIQ証明書サーバ]>[デフォルト証明書の修復]に移動します。
証明書を所有するサーバを選択して、[次へ]をクリックします。
[デフォルト証明書はすべて上書きされます]を選択し、[次へ]をクリックします。
実行するタスクを確認し、[完了]を選択します。
新しいECDSA証明書を使用するようにLDAPおよびHTTPサービスを設定します。