Identity Management サービスへのアクセス

kinit ユーティリティーを使用して Identity Management (IdM) 環境に対して手動で認証するには、次の手順に従います。kinit ユーティリティーは、IdM ユーザーの代わりに Kerberos の TGT (Ticket-Granting Ticket) を取得して、キャッシュに格納します。

この手順は、最初の Kerberos TGT を破棄したか、有効期限が切れている場合にのみ使用します。ローカルマシンに、IdM ユーザーとしてログインすると、IdM に自動的にログインします。これは、ログイン後に IdM リソースにアクセスするのに kinit ユーティリティーを使用する必要がないことを示しています。

ユーザーのアクティブな Kerberos チケットを含む認証情報キャッシュをクリアするには、次の手順に従います。

Identity Management (IdM) ユーザーが Kerberos 認証情報を使用して外部システムから IdM にログインできるように外部システムを設定するには、この手順に従います。

外部システムの Kerberos 認証を有効にすることは、インフラストラクチャーに、複数のレルムまたは重複ドメインが含まれている場合に特に便利です。また、ipa-client-install を実行してシステムを IdM ドメインに登録していない場合にも便利です。

IdM ドメインのメンバーではないシステムから IdM への Kerberos 認証を有効にするには、IdM 固有の Kerberos 設定ファイルを外部システムに定義します。

外部システムのユーザーが、kinit ユーティリティーを使用して IdM サーバーで認証できるようになりました。

IdM サーバーおよびクライアントにインストールして実行できるサービスには、さまざまなものがあります。

IdM は、シングルサインオンに対応する Kerberos プロトコルを使用します。Kerberos では、正しいユーザー名とパスワードを一度提示するだけで済み、システムから認証情報を再度求められることなく IdM サービスにアクセスできます。

Kerberos は 2 つの部分に分類されます。

IdM で Kerberos を使用して認証する方法は、コマンドラインからの Identity Management へのログイン および Web UI で IdM にログイン: Kerberos チケットの使用 を参照してください。

IdM の LDAP ディレクトリーサーバー インスタンスは、Kerberos、ユーザーアカウント、ホストエントリー、サービス、ポリシー、DNS などの情報をはじめとした、IdM 情報をすべて保存します。LDAP ディレクトリーサーバーインスタンスは、Red Hat Directory Server と同じテクノロジーをベースにしています。ただし、IdM 固有のタスクに合わせて調整されます。

統合 認証局 (CA) は、Red Hat Certificate System と同じテクノロジーをベースにしています。pki は、Certificate System サービスにアクセスするためのコマンドラインです。

必要な証明書をすべて単独で作成して提供する場合は、統合 CA なしでサーバーをインストールすることもできます。

詳細は、CA サービスの計画 を参照してください。

IdM は、動的サービス検出に DNS を使用します。IdM クライアントのインストールユーティリティーは、DNS からの情報を使用して、クライアントマシンを自動的に設定できます。クライアントを IdM ドメインに登録したら、クライアントは DNS を使用してドメイン内の IdM サーバーおよびサービスを検索します。Red Hat Enterprise Linux の DNS (Domain Name System) プロトコルの BIND (Berkeley Internet Name Domain) 実装には、named の DNS サーバーが含まれています。

詳細は、Planning your DNS services and host names を参照してください。

Apache HTTP Web サーバー には、IdM Web UI があり、認証局とその他の IdM サービスの間の通信も管理します。

Samba は、Red Hat Enterprise Linux に、Common Internet File System (CIFS) プロトコルとも呼ばれる Server Message Block (SMB) プロトコルを実装します。smb サービス経由で SMB プロトコルを使用すると、ファイル共有や共有プリンターなどのサーバーのリソースにアクセスできます。Active Directory (AD) 環境で信頼を設定している場合には、`Winbind` サービスが IdM サーバーと AD サーバー間の通信を管理します。

ワンタイムパスワード (OTP) は、2 要素認証の一部として、認証トークンがセッション 1 回だけ使用できるように生成するパスワードです。OTP 認証は、ipa-otpd サービスを介して Red Hat Enterprise Linux に実装されています。

詳細は ワンタイムパスワードを使用して Identity Management Web UI へのログイン を参照してください。

OpenDNSSEC は、DNSSEC (DNS Security Extensions) キーおよびゾーンの署名の記録プロセスを自動化する DNS マネージャーです。ipa-dnskeysyncd サービスは、IdM Directory Server と OpenDNSSEC との間の同期を管理します。

View larger image

SSSD (System Security Services Daemon) は、ユーザー認証およびキャッシュ認証情報を管理するクライアント側のアプリケーションです。キャッシュを使用すると、IdM サーバーが利用できなくなったり、クライアントがオフラインになったりした場合に、ローカルシステムが通常の認証操作を継続できるようになります。

詳細は SSSD とその利点について を参照してください。

certmonger サービスは、クライアント上の証明書を監視、更新します。このサービスは、システム上のサービスに対して新しい証明書を要求できます。

詳細は、certmonger を使用したサービスの IdM 証明書の取得 を参照してください。

View larger image

IdM サーバーに設定されている IdM サービスの状態を表示するには、ipactl status コマンドを実行します。

ipactl status

[root@server ~]# ipactl status
Directory Service: RUNNING
krb5kdc Service: RUNNING
kadmin Service: RUNNING
named Service: RUNNING
httpd Service: RUNNING
pki-tomcatd Service: RUNNING
smb Service: RUNNING
winbind Service: RUNNING
ipa-otpd Service: RUNNING
ipa-dnskeysyncd Service: RUNNING
ipa: INFO: The ipactl command was successful

サーバーの ipactl status コマンドの出力は、IdM 設定により異なります。たとえば、IdM デプロイメントに DNS サーバーが含まれていない場合は、named サービスがリストに表示されません。

ipa systemd サービスを使用して、IdM サーバー全体を、インストールしたすべてのサービスを停止、起動、または再起動します。systemctl ユーティリティーを使用して ipa systemd サービスを制御すると、すべてのサービスが適切な順序で停止、開始、または再起動されます。ipa systemd サービスは、IdM サービスを起動する前に RHEL IdM 設定もアップグレードし、IdM サービスの管理時に適切な SELinux コンテキストを使用します。systemctl ipa コマンドを実行するには、有効な Kerberos チケットは必要ありません。

systemctl start ipa

# systemctl start ipa

IdM サーバー全体を停止するには、次のコマンドを実行します。

systemctl stop ipa

# systemctl stop ipa

IdM サーバー全体を再起動するには、次のコマンドを実行します。

systemctl restart ipa

# systemctl restart ipa

IdM を設定するすべてのサービスのステータスを表示するには、ipactl ユーティリティーを使用します。

ipactl status

# ipactl status

IdM 設定ファイルを手動で変更することは推奨されていません。ただし、特定の状況では、管理者が特定のサービスを手動で設定する必要があります。このような場合は、systemctl ユーティリティーを使用して、個々の IdM サービスを停止、開始、または再開します。

たとえば、その他の IdM サービスを変更せずに、Directory Server の挙動をカスタマイズした場合は、systemctl を使用します。

systemctl restart dirsrv@REALM-NAME.service

# systemctl restart dirsrv@REALM-NAME.service

また、Active Directory と IdM の信頼を最初にデプロイする場合は、/etc/sssd/sssd.conf ファイルを変更して、以下を追加します。

/etc/sssd/sssd.conf ファイルに加えた変更を適用する場合は、次のコマンドを実行します。

systemctl restart sssd.service

# systemctl restart sssd.service

System Security Services Daemon (SSSD) は、設定を自動的に再読み込みまたは再適用しないため、systemctl restart sssd.service を実行する必要があります。

変更が、IdM の ID 範囲に影響を及ぼす場合は、サーバーを完全に再起動することが推奨されます。

systemctl start name.service

# systemctl start name.service

特定の IdM サービスを停止するには、次のコマンドを実行します。

systemctl stop name.service

# systemctl stop name.service

特定の IdM サービスを再開するには、次のコマンドを実行します。

systemctl restart name.service

# systemctl restart name.service

特定の IdM サービスの状態を表示するには、次のコマンドを実行します。

systemctl status name.service

# systemctl status name.service

IdM バージョン番号は次の方法で表示できます。

IPA コマンドラインインターフェイス (CLI) は、Identity Management (IdM) の管理向けの基本的なコマンドラインインターフェイスです。

新しいユーザーを追加するための ipa user-add コマンドなど、IdM を管理するための多くのサブコマンドがサポートされています。

IPA CLI では以下を行うことができます。

IPA ヘルプは、IdM サーバー用の組み込みドキュメントシステムです。

IPA コマンドラインインターフェイス (CLI) は、読み込んだ IdM プラグインモジュールから、利用可能なヘルプトピックを生成します。IPA ヘルプユーティリティーを使用するには、以下が必要です。

オプションを指定せずに ipa help コマンドを実行すると、基本的なヘルプの使用方法と、最も一般的なコマンドの例が表示されます。

さまざまな ipa help のユースケースに対して、次のオプションを使用できます。

ipa help [TOPIC | COMMAND | topics | commands]

$ ipa help [TOPIC | COMMAND | topics | commands]

以下の手順では、コマンドラインで IPA ヘルプを使用する方法について説明します。

IPA CLI は、ユーザー トピックのヘルプページを表示します。概要を読むと、トピックのコマンドを使用するパターンに関して、多くの例を確認できます。

以下の手順では、コマンドラインで IPA help コマンドを作成する方法を説明します。

IPA CLI は、以下のタイプのコマンドを区別します。

IPA コマンドの構造を使用すると、さまざまなタイプのオブジェクトを管理できます。以下に例を示します。

その他にも多数あります。

このようなほとんどのオブジェクトでは、IPA CLI に、以下を行うためのコマンドが含まれます。

コマンドの構造は次のとおりです。

ipa user-add、ipa user-mod、ipa user-del、ipa user-find、ipa user-show

ipa host-add、ipa host-mod、ipa host-del、ipa host-find、ipa host-show

ipa dnsrecord-add、ipa dnsrecord-mod、ipa dnsrecord-del、ipa dnsrecord-find、ipa dnrecord-show

ipa user-add [options] でユーザーを作成できます。[options] は任意です。ipa user-add コマンドのみを使用する場合、スクリプトは、詳細を 1 つずつ要求します。

[オプション] --raw と --structured は相互に排他的であり、一緒に実行してはならないことに注意してください。

既存のオブジェクトを変更するには、オブジェクトを定義する必要があります。そのため、コマンドには、オブジェクト ipa user-mod USER_NAME [options] も含まれます。

Identity Management (IdM) は、多値属性の値をリスト形式で保存します。

IdM は、多値リストを提供する次の方法に対応します。

上記の例は、オブジェクトにパーミッションを追加するコマンド permission-add を示しています。オブジェクトはこの例には記載されていません。…​ の代わりに、パーミッションを追加するオブジェクトを指定する必要があります。

このような多値属性をコマンド行から更新すると、IdM は、前の値リストを新しいリストで完全に上書きします。したがって、多値属性を更新するときは、追加する 1 つの値だけでなく、新しいリスト全体を指定する必要があります。

たとえば、上記のコマンドでは、パーミッションのリストには、読み取り、書き込み、および削除が含まれます。permission-mod コマンドでリストを更新する場合は、すべての値を追加する必要があります。すべての値を追加しないと、追加されていない値は削除されます。

例 1: - ipa permission-mod コマンドは、以前に追加した権限をすべて更新します。

ipa permission-mod --right=read --right=write --right=delete ...

$ ipa permission-mod --right=read --right=write --right=delete ...

または

ipa permission-mod --right={read,write,delete} ...

$ ipa permission-mod --right={read,write,delete} ...

例 2 - ipa permission-mod コマンドは、--right=delete 引数を削除します。この引数はコマンドに含まれていないためです。

ipa permission-mod --right=read --right=write ...

$ ipa permission-mod --right=read --right=write ...

または

ipa permission-mod --right={read,write} ...

$ ipa permission-mod --right={read,write} ...

特殊文字を含むコマンドライン引数を ipa コマンドに渡す場合は、この文字をバックスラッシュ (\) でエスケープします。たとえば、一般的な特殊文字には、山かっこ (< および >)、アンパサンド (&)、アスタリスク (*)、またはバーティカルバー (|) があります。

たとえば、アスタリスク (*) をエスケープするには、次のコマンドを実行します。

ipa certprofile-show certificate_profile --out=exported\*profile.cfg

$ ipa certprofile-show certificate_profile --out=exported\*profile.cfg

シェルが特殊文字を正しく解析できないため、エスケープしていない特殊文字をコマンドに含めると、予想通りに機能しなくなります。

ipa *-find コマンドを使用すると、特定のタイプの IdM エントリーを検索できます。

すべての find コマンドを表示するには、次の ipa help コマンドを使用します。

ipa help commands | grep find

$ ipa help commands | grep find

特定のユーザーが IdM データベースに含まれているかどうかの確認が必要になる場合があります。次のコマンドを使用すると、ユーザーをリスト表示できます。

ipa user-find

$ ipa user-find

指定の属性にキーワードが含まれるユーザーグループのリストを表示するには、次のコマンドを実行します。

ipa group-find keyword

$ ipa group-find keyword

たとえば、ipa group-find admin コマンドは、名前または説明に文字列 admin が含まれるグループのリストを表示します。

----------------
3 groups matched
----------------
   Group name: admins
   Description: Account administrators group
   GID: 427200002

   Group name: editors
   Description: Limited admins who can edit other users
   GID: 427200002

   Group name: trust admins
   Description: Trusts administrators group

----------------
3 groups matched
----------------
   Group name: admins
   Description: Account administrators group
   GID: 427200002

   Group name: editors
   Description: Limited admins who can edit other users
   GID: 427200002

   Group name: trust admins
   Description: Trusts administrators group

ユーザーグループの検索の際には、特定のユーザーを含むグループに検索結果を絞り込むことも可能です。

ipa group-find --user=user_name

$ ipa group-find --user=user_name

また、特定のユーザーを含まないグループを検索するには、次のコマンドを実行します。

ipa group-find --no-user=user_name

$ ipa group-find --no-user=user_name

ipa *-show コマンドを使用して、特定の IdM エントリーの詳細を表示します。

IdM ユーザーのリストを要求するなど、一部のクエリーでは、エントリー数が大量に返される場合があります。この検索操作を調整して、ipa user-find などの ipa *-find コマンドの実行時や、Web UI で対応するリストを表示する際に、全体的なサーバーのパフォーマンスを向上できます。

この値が -1 に設定されていると、IdM は、検索時に制限を適用しません。

IdM (Identity Management) Web UI は、IdM 管理用の Web アプリケーションです。IdM Web UI には、以下のユーザーとしてアクセスできます。

Identity Management (IdM) は、Web UI への接続に、以下のブラウザーをサポートします。

ブラウザーで TLS v1.3 を使用しようとすると、スマートカードで IdM Web UI にアクセスできなくなる場合があります。

[ssl:error] [pid 125757:tid 140436077168384] [client 999.999.999.999:99999] AH: verify client post handshake
[ssl:error] [pid 125757:tid 140436077168384] [client 999.999.999.999:99999] AH10158: cannot perform post-handshake authentication
[ssl:error] [pid 125757:tid 140436077168384] SSL Library Error: error:14268117:SSL routines:SSL_verify_client_post_handshake:extension not received

[ssl:error] [pid 125757:tid 140436077168384] [client 999.999.999.999:99999] AH: verify client post handshake
[ssl:error] [pid 125757:tid 140436077168384] [client 999.999.999.999:99999] AH10158: cannot perform post-handshake authentication
[ssl:error] [pid 125757:tid 140436077168384] SSL Library Error: error:14268117:SSL routines:SSL_verify_client_post_handshake:extension not received

これは、最新バージョンのブラウザーで TLS Post-Handshake Authentication (PHA) がデフォルトで有効になっていないか、PHA をサポートしていないためです。スマートカード認証で IdM Web UI にアクセスする場合など、Web サイトの一部にのみ TLS クライアント証明書を必要とする場合は、PHA が必要です。

Mozilla Firefox 68 以降でこの問題を解決するには、TLS PHA を有効にします。

現在 PHA をサポートしていない Chrome でこの問題を解決するには、TLS v1.3 を無効にします。

IdM は ssl.conf ファイルを管理するため、パッケージの更新時にそのコンテンツが上書きされる可能性があることに注意してください。IdM パッケージの更新後に、カスタム設定を確認します。

次の手順では、パスワードを使用して、IdM (Identity Management) Web UI に最初にログインする方法を説明します。

最初のログイン後に、IdM サーバーを認証するように設定できます。

ログインに成功したら、IdM サーバーの設定を開始できます。

Identity Management (IdM) は、シングルサインオンに対応する Kerberos プロトコルを使用します。シングルサインオン認証により、ユーザーが正しいユーザー名およびパスワードを一度入力すれば、再度システムに認証情報を求められることなく、Identity Management サービスにアクセスできます。

DNS および証明書の設定が適切に設定されている場合は、インストール直後に、IdM サーバーが Kerberos 認証を提供します。詳細は、Identity Management のインストール を参照してください。

ホストで Kerberos 認証を使用するには、以下をインストールします。

kinit ユーティリティーを使用して Identity Management (IdM) 環境に対して手動で認証するには、次の手順に従います。kinit ユーティリティーは、IdM ユーザーの代わりに Kerberos の TGT (Ticket-Granting Ticket) を取得して、キャッシュに格納します。

この手順は、最初の Kerberos TGT を破棄したか、有効期限が切れている場合にのみ使用します。ローカルマシンに、IdM ユーザーとしてログインすると、IdM に自動的にログインします。これは、ログイン後に IdM リソースにアクセスするのに kinit ユーティリティーを使用する必要がないことを示しています。

Kerberos チケットによる認証を有効にするには、ブラウザー設定の変更が必要になることもあります。

以下の手順は、IdM ドメインにアクセスする Kerberos ネゴシエーションに対応するのに役に立ちます。

Kerberos に対応する方法はブラウザーによって異なるため、ブラウザーごとに異なる設定が必要です。IdM Web UI には、次のブラウザーに関するガイドラインが含まれています。

設定が完了したら、IdM Web UI に戻り、Log in をクリックします。

Kerberos Ticket-Granting Ticket (TGT) を使用して IdM Web UI にログインするには、次の手順に従います。

TGT は、事前定義された時間で有効期限が切れます。デフォルトの時間間隔は 24 時間で、IdM Web UI でそれを変更できます。

期限が切れたら、次の方法でチケットを更新する必要があります。

Identity Management (IdM) ユーザーが Kerberos 認証情報を使用して外部システムから IdM にログインできるように外部システムを設定するには、この手順に従います。

外部システムの Kerberos 認証を有効にすることは、インフラストラクチャーに、複数のレルムまたは重複ドメインが含まれている場合に特に便利です。また、ipa-client-install を実行してシステムを IdM ドメインに登録していない場合にも便利です。

IdM ドメインのメンバーではないシステムから IdM への Kerberos 認証を有効にするには、IdM 固有の Kerberos 設定ファイルを外部システムに定義します。

外部システムのユーザーが、kinit ユーティリティーを使用して IdM サーバーで認証できるようになりました。

Active Directory ユーザーに対して Web UI ログインを有効にするには、デフォルトの信頼ビュー で、Active Directory の各ユーザーに対して ID のオーバーライドを定義します。

ワンタイムパスワードにより、認証セキュリティーに関する手順が追加されます。この認証では、ユーザーのパスワードと自動的に生成されたワンタイムパスワードを使用します。

ワンタイムパスワードを生成するには、ハードウェアまたはソフトウェアのトークンを使用できます。IdM は、ソフトウェアトークンとハードウェアトークンの両方をサポートします。

Identity Management は、次の標準的な OTP メカニズムをサポートしています。

Identity Management (IdM) 管理者は、IdM ユーザーに対して 2 要素認証 (2FA) をシステム全体でまたは個別に有効にすることができます。ユーザーは、コマンドラインまたは Web UI ログインダイアログの専用フィールドで、通常のパスワードの後にワンタイムパスワード (OTP) を入力します。これらのパスワードの間にはスペースを入れません。

2FA を有効にしても、2FA が強制されるわけではありません。LDAP バインドに基づくログインを使用する場合、IdM ユーザーはパスワードを入力するだけで認証できます。ただし、krb5 ベースのログインを使用する場合は、2FA が強制されます。

なお、すべての LDAP クライアントに OTP の使用を強制して LDAP バインドに 2FA を強制するという選択肢もあります。詳細は、すべての LDAP クライアントに OTP の使用を強制する を参照してください。

IdM Web UI を使用して、個々の example.user IdM ユーザーに対して 2FA を有効にするには、以下の手順を完了します。

この時点で、IdM ユーザーに対して OTP 認証が有効になります。

次に、管理者権限を持つユーザーまたは example.user が、example.user アカウントに新しいトークン ID を割り当てる必要があります。

プロプライエタリーのワンタイムパスワード (OTP) ソリューションから Identity Management (IdM) ネイティブの OTP ソリューションへの大規模なデプロイメントの移行を可能にするために、IdM では、ユーザーのサブセットに対して OTP バリデーションをサードパーティーの RADIUS サーバーにオフロードすることができます。管理者は、各プロキシーが単一の RADIUS サーバーのみを参照できる RADIUS プロキシーのセットを作成します。複数のサーバーに対応する必要がある場合は、複数の RADIUS サーバーを参照する仮想 IP ソリューションを作成することが推奨されます。

このようなソリューションは、keepalived デーモンなどを使用して、RHEL IdM の外部でビルドする必要があります。次に、管理者はこれらのプロキシーセットのいずれかをユーザーに割り当てます。ユーザーが RADIUS プロキシーが設定されている限り、IdM は他のすべての認証メカニズムをバイパスします。

OTP バリデーション用に RADIUS サーバーを設定し、プロキシーサーバーにユーザーを追加する手順を実行します。

これにより、RADIUS プロキシーサーバーがユーザーの OTP 認証の処理を開始します。

ユーザーが IdM ネイティブ OTP システムに移行する準備ができたら、ユーザーの RADIUS プロキシー割り当てを削除するだけです。

次のセクションでは、IdM Web UI とソフトウェアトークンジェネレーターにトークンを追加する方法を説明します。

これで、ワンタイムパスワードを生成して、IdM Web UI にログインできるようになりました。

ワンタイムパスワード (OTP) を使用して IdM Web UI に初めてログインする際には、この手順に従います。

ログインに成功すると、IdM Web UI が開きます。

OTP (ワンタイムパスワード) でのログインに失敗した場合、OTP トークンは正しく同期しません。

以下のテキストは、トークンの再同期を説明します。

同期が成功すると、IdM サーバーにログインできます。

Identity Management の管理者は、ユーザーが次回ログインするときにパスワードを変更するよう強制する場合があります。その場合、パスワードを変更するまで IdM Web UI にログインできません。

パスワードの有効期限は、Web UI に初めてログインしたときに発生する可能性があります。

有効期限のパスワードのダイアログが表示されたら、手順の指示に従ってください。

パスワードの変更が成功すると、通常のログインダイアログが表示されます。新しいパスワードでログインします。

OTP ユーザーとして Kerberos TGT (Ticket-granting ticket) を取得するには、匿名の Kerberos チケットを要求し、Secure Tunneling (FAST) チャネルを介したフレキシブル認証を有効にして、Kerberos クライアントと Kerberos ディストリビューションセンター (KDC) 間のセキュアな接続を提供します。

RHEL IdM では、2 要素 (OTP) 認証が設定されたユーザーアカウントの LDAP サーバー認証のデフォルト動作を設定できます。LDAP クライアントは、OTP が強制されている場合、関連付けられた OTP トークンを持つユーザーの単一要素認証 (パスワード) を使用して、LDAP サーバーに対して認証することはできません。この方式は、RHEL IdM によって、データなしの OID 2.16.840.1.113730.3.8.10.7 を使用した特別な LDAP 制御を使用して、Kerberos バックエンドを通じてすでに強制されています。

デフォルトでは、RHEL 8 の Identity Management (IdM) はシステム全体の暗号化ポリシーを使用します。このポリシーの利点は、個々の IdM コンポーネントを手動で強化する必要がないことです。

デフォルトでは、Identity Management (IdM) LDAP サーバーへの匿名バインドが有効になっています。匿名バインドは、特定の設定またはディレクトリー値を公開できます。ただし、realmd などの一部のユーティリティーや古い RHEL クライアントでは、クライアントの登録時にドメイン設定を検出する匿名バインドを有効にする必要があります。

LDAP ツールを使用して nsslapd-allow-anonymous-access 属性をリセットすることで、Identity Management (IdM) 389 Directory Server インスタンスで匿名バインドを無効にできます。

以下は nsslapd-allow-anonymous-access 属性の有効な値です。

Red Hat では、属性を off に設定して匿名バインドを完全に拒否すると、外部クライアントによるサーバー設定のチェックもブロックするため、この設定は推奨していません。LDAP および web クライアントはドメインクライアントに限られるわけではないため、こうしたクライアントは匿名で接続を行ってルートの DSE ファイルを読み取り接続情報を取得します。

nsslapd-allow-anonymous-access 属性の値を rootdse に変更すると、ディレクトリーデータにアクセスせずにルート DSE およびサーバー設定へのアクセスを許可します。

以下の表は、Identity Management (IdM) サーバーおよびクライアントが情報のログ記録に使用するディレクトリーおよびファイルを示しています。インストールエラーのトラブルシューティングには、ファイルおよびディレクトリーを使用できます。

以下の表は、Identity Management (IdM) Directory Server (DS) インスタンスが情報をログ記録に使用するディレクトリーおよびファイルを示しています。DS 関連の問題のトラブルシューティングには、ファイルおよびディレクトリーを使用できます。

監査目的で Identity Management (IdM) サーバーでのロギングを有効にするには、次の手順に従います。詳細なログを使用すると、データの監視、問題のトラブルシューティング、ネットワーク上の疑わしいアクティビティーを確認できます。

modifiersName: ipaanchoruuid=:sid:s-1-5-21-19610888-1443184010-1631745340-279100,cn=default trust view,cn=views,cn=accounts,dc=idma,dc=idm,dc=example,dc=com

$ modifiersName: ipaanchoruuid=:sid:s-1-5-21-19610888-1443184010-1631745340-279100,cn=default trust view,cn=views,cn=accounts,dc=idma,dc=idm,dc=example,dc=com

SID ユーザーがある場合は、pysss_nss_idmap.getnamebysid Python コマンドを使用して AD ユーザーを検索します。

>>> import pysss_nss_idmap
>>> pysss_nss_idmap.getnamebysid('S-1-5-21-1273159419-3736181166-4190138427-500'))
{'S-1-5-21-1273159419-3736181166-4190138427-500': {'name': 'administrator@ad.vm', 'type': 3}}

>>> import pysss_nss_idmap
>>> pysss_nss_idmap.getnamebysid('S-1-5-21-1273159419-3736181166-4190138427-500'))
{'S-1-5-21-1273159419-3736181166-4190138427-500': {'name': 'administrator@ad.vm', 'type': 3}}

特定の種類のエラーに関するデバッグ情報を取得するには、次の手順に従います。この例では、エラーログレベルを 8192 に設定して、レプリケーションに関する詳細なエラーログを取得することに重点を置いています。異なるタイプの情報を記録するには、Red Hat Directory Server ドキュメントの Error Log Logging Levels の表から別の番号を選択します。

以下の表は、Identity Management (IdM) Apache Server が情報をログに記録するために使用するディレクトリーおよびファイルを示しています。

以下の表は、Identity Management (IdM) Certificate System が情報のログ記録に使用するディレクトリーおよびファイルを示しています。

以下の表は、Kerberos が Identity Management (IdM) に情報をログに記録するために使用するディレクトリーおよびファイルを示しています。

以下の表は、DNS が Identity Management (IdM) に情報をログに記録するために使用するディレクトリーおよびファイルを示しています。

以下の表は、Custodia が Identity Management (IdM) に情報をログに記録するために使用するディレクトリーおよびファイルを示しています。