Identity Management の設定および管理

手順

1. IdM サーバーから外部システムに /etc/krb5.conf ファイルをコピーします。以下に例を示します。

   # scp /etc/krb5.conf root@externalsystem.example.com:/etc/krb5_ipa.conf

   Copy to Clipboard Toggle word wrap
   警告

   外部マシンにある既存の krb5.conf ファイルは上書きしないでください。

2. 外部システムで、コピーした IdM の Kerberos 設定ファイルを使用するように、端末セッションを設定します。

   $ export KRB5_CONFIG=/etc/krb5_ipa.conf

   Copy to Clipboard Toggle word wrap

   KRB5_CONFIG 変数は、ログアウトまで一時的に存在します。ログアウト時に削除されないように、この変数のファイル名を変えてエクスポートします。

3. /etc/krb5.conf.d/ ディレクトリーの Kerberos 設定部分を、外部システムにコピーします。

手順

1. 端末を開き、IdM サーバーに接続します。

2. ヘルプに記載されているトピックのリストを表示するには、ipa help topics を実行します。

   $ ipa help topics

   Copy to Clipboard Toggle word wrap

3. トピックの 1 つを選択し、ipa help [topic_name] のパターンに従ってコマンドを作成します。topic_name 文字列の代わりに、前の手順でリストしたトピックの 1 つを追加します。

   この例では、user トピックを使用します。

   $ ipa help user

   Copy to Clipboard Toggle word wrap

4. (オプション) IPA ヘルプの出力が長すぎてテキスト全体を表示できない場合は、次の構文を使用します。

   $ ipa help user | less

   Copy to Clipboard Toggle word wrap

   下にスクロールすると、ヘルプ全体を読むことができます。

手順

1. 端末を開き、IdM サーバーに接続します。

2. ヘルプで使用できるコマンドのリストを表示するには、ipa help commands コマンドを実行します。

   $ ipa help commands

   Copy to Clipboard Toggle word wrap

3. コマンドの 1 つを選択し、ipa help <COMMAND> のパターンに従ってヘルプコマンドを作成します。<COMMAND> 文字列の代わりに、前の手順でリストしたコマンドの 1 つを追加します。

   $ ipa help user-add

   Copy to Clipboard Toggle word wrap

1. アドレスバーに about:config と入力して、Mozilla Firefox 設定メニューにアクセスします。
2. 検索バーに security.tls.enable_post_handshake_auth と入力します。
3. トグルボタンをクリックして、パラメーターを true に設定します。

1. /etc/httpd/conf.d/ssl.conf 設定ファイルを開きます。

2. -TLSv1.3 を SSLProtocol オプションに追加します。

   SSLProtocol all -TLSv1 -TLSv1.1 -TLSv1.3

   Copy to Clipboard Toggle word wrap

3. httpd サービスを再起動します。

   service httpd restart

   Copy to Clipboard Toggle word wrap

手順

1. ブラウザーのアドレスバーに、IdM サーバーの URL を入力します。名前は次の例のようになります。

   https://server.example.com

   Copy to Clipboard Toggle word wrap

   server.example.com を、IdM サーバーの DNS 名に変更するだけです。

   これで、ブラウザーに IdM Web UI ログイン画面が開きます。

   

   • サーバーが応答しない、またはログイン画面が開かない場合は、接続している IdM サーバーの DNS 設定を確認してください。

   • 自己署名証明書を使用する場合は、ブラウザーに警告が表示されます。証明書を確認し、セキュリティー例外を許可して、ログインを続行します。

     セキュリティーの例外を回避するために、認証局が署名した証明書をインストールします。

2. Web UI ログイン画面で、IdM サーバーのインストール時に追加した管理者アカウントの認証情報を入力します。

   詳細は Identity Management サーバーのインストール: 統合 DNS と統合 CA の場合 を参照してください。

   IdM サーバーに、個人アカウントの認証情報がすでに入力されている場合は、それを入力できます。

   

3. Log in をクリックします。

手順

1. Web ブラウザーで、WebUI ログインダイアログを開きます。

2. Web UI ログイン画面でブラウザー設定のリンクをクリックします。

   

3. 設定ページの手順に従います。

   

手順

1. IdM サーバーから外部システムに /etc/krb5.conf ファイルをコピーします。以下に例を示します。

   # scp /etc/krb5.conf root@externalsystem.example.com:/etc/krb5_ipa.conf

   Copy to Clipboard Toggle word wrap
   警告

   外部マシンにある既存の krb5.conf ファイルは上書きしないでください。

2. 外部システムで、コピーした IdM の Kerberos 設定ファイルを使用するように、端末セッションを設定します。

   $ export KRB5_CONFIG=/etc/krb5_ipa.conf

   Copy to Clipboard Toggle word wrap

   KRB5_CONFIG 変数は、ログアウトまで一時的に存在します。ログアウト時に削除されないように、この変数のファイル名を変えてエクスポートします。

3. /etc/krb5.conf.d/ ディレクトリーの Kerberos 設定部分を、外部システムにコピーします。
4. Kerberos 認証用のブラウザーの設定 の説明に従って、外部システムでブラウザーを設定します。

手順

1. IdM admin 権限を使用して IdM Web UI にログインします。

2. Identity → Users → Active users タブを開きます。

   

3. example.user を選択してユーザー設定を開きます。
4. User authentication types で、Two factor authentication (password + OTP) を選択します。
5. Save をクリックします。

手順

1. RADIUS プロキシーを追加します。

   $ ipa radiusproxy-add proxy_name --secret secret

   Copy to Clipboard Toggle word wrap

   このコマンドは、必要な情報を挿入するように求められます。

   RADIUS プロキシーの設定には、クライアントとサーバーとの間の共通のシークレットを使用して認証情報をラップする必要があります。--secret パラメーターにこのシークレットを指定します。

2. 追加したプロキシーにユーザーを割り当てます。

   ipa user-mod radiususer --radius=proxy_name

   Copy to Clipboard Toggle word wrap

3. 必要に応じて、RADIUS に送信するユーザー名を設定します。

   ipa user-mod radiususer --radius-username=radius_user

   Copy to Clipboard Toggle word wrap

手順

1. ユーザー名とパスワードを使用して IdM Web UI にログインします。
2. Authentication → OTP Tokens タブを開いて、携帯電話でトークンを作成します。

3. Add をクリックします。

   

4. Add OTP token ダイアログボックスに何も入力せず、Add をクリックします。

   この段階で、IdM サーバーはデフォルトパラメーターを使用してトークンを作成し、QR コード付きページを開きます。

5. QR コードを携帯電話にコピーします。
6. OK をクリックして QR コードを閉じます。

手順

1. Identity Management ログイン画面で、自身のユーザー名、または IdM サーバー管理者アカウントのユーザー名を入力します。
2. 上記で入力したユーザーのパスワードを追加します。
3. デバイスでワンタイムパスワードを生成します。
4. パスワードの直後に空白文字を入れずにワンタイムパスワードを入力します。

5. Log in をクリックします。

   認証に失敗した場合は、OTP トークンを同期します。

   CA が自己署名証明書を使用する場合は、ブラウザーに警告が表示されます。証明書を確認し、セキュリティー例外を許可して、ログインを続行します。

   IdM Web UI が開かない場合は、Identity Management サーバーの DNS 設定を確認してください。

手順

1. IdM Web UI ログイン画面で、Sync OTP Token をクリックします。

   

2. ログイン画面で、ユーザー名と、Identity Management パスワードを入力します。
3. ワンタイムパスワードを生成し、First OTP フィールドに入力します。
4. ワンタイムパスワードをもう一度生成し、Second OTP フィールドに入力します。

5. オプション: トークン ID を入力します。

   

6. Sync OTP Token をクリックします。

手順

1. パスワード有効期限のログイン画面に、ユーザー名を入力します。
2. 上記で入力したユーザーのパスワードを追加します。
3. ワンタイムパスワード認証を使用する場合は、OTP フィールドでワンタイムパスワードを生成します。
4. 確認のために新しいパスワードを 2 回入力します。

5. Reset Password をクリックします。

   

手順

1. 次のコマンドを実行して認証情報キャッシュを初期化します。

   [root@client ~]# kinit -n @IDM.EXAMPLE.COM -c FILE:armor.ccache

   Copy to Clipboard Toggle word wrap

   このコマンドは、新しい Kerberos チケットを要求するたびに指定する必要がある armor.ccache ファイルを作成することに注意してください。

2. 次のコマンドを実行して Kerberos チケットを要求します。

   [root@client ~]# kinit -T FILE:armor.ccache <username>@IDM.EXAMPLE.COM
   Enter your OTP Token Value.

   Copy to Clipboard Toggle word wrap

1. getent コマンドは、libc ライブラリーから getpwnam 呼び出しをトリガーします。
2. libc ライブラリーは、/etc/nsswitch.conf 設定ファイルを参照して、どのサービスがユーザー情報を提供するかを確認し、SSSD サービスのエントリー sss を検出します。
3. libc ライブラリーは、nss_sss モジュールを開きます。
4. nss_sss モジュールは、ユーザー情報のメモリーマップキャッシュを確認します。データがキャッシュに存在する場合は、nss_sss モジュールがそれを返します。
5. ユーザー情報が memory-mapped キャッシュにない場合、リクエストは SSSD sssd_nss レスポンダープロセスに渡されます。
6. SSSD サービスはキャッシュをチェックします。データがキャッシュに存在し、有効な場合は、sssd_nss レスポンダーがキャッシュからデータを読み取って、アプリケーションに返します。
7. データがキャッシュにない場合や期限切れである場合、sssd_nss レスポンダーは適切なバックエンドプロセスに対してクエリーを実行し、応答を待機します。SSSD サービスは、sssd.conf 設定ファイルで id_provider=ipa を設定して有効にした、IdM 環境の IPA バックエンドを使用します。
8. sssd_be バックエンドプロセスは IdM サーバーに接続して、IdM LDAP Directory Server から情報を要求します。
9. IdM サーバーの SSSD バックエンドは、IdM クライアントの SSSD バックエンドプロセスに対応します。
10. クライアントの SSSD バックエンドは、生成されるデータを SSSD キャッシュに保存し、キャッシュが更新されたレスポンダープロセスを警告します。
11. sssd_nss フロントエンドレスプロセスが SSSD キャッシュから情報を取得します。
12. sssd_nss レスポンダーは、nss_sss レスポンダーにユーザー情報を送信し、リクエストを完了します。
13. libc ライブラリーは、要求したアプリケーションにユーザー情報を返します。

1. IdM クライアントは、AD ユーザー情報に関するローカルの SSSD キャッシュを検索します。
2. IdM クライアントにユーザー情報がない場合や、情報が古い場合に、クライアントの SSSD サービスが IdM サーバーの extdom_extop プラグインに問い合わせて、LDAP 拡張操作を実行し、情報を要求します。
3. IdM サーバーの SSSD サービスは、ローカルキャッシュで AD ユーザー情報を検索します。
4. IdM サーバーに SSSD キャッシュにユーザー情報がない場合や、その情報が古い場合は、LDAP 検索を実行して、AD ドメインコントローラーからユーザー情報を要求します。
5. IdM サーバーの SSSD サービスは、AD ドメインコントローラーから AD ユーザー情報を受け取り、キャッシュに保存します。
6. extdom_extop プラグインは、LDAP 拡張操作を完了する IdM サーバーの SSSD サービスから情報を受信します。
7. IdM クライアントの SSSD サービスは、LDAP 拡張操作から AD ユーザー情報を受信します。
8. IdM クライアントは、AD ユーザー情報を SSSD キャッシュに保存し、要求したアプリケーションに情報を返します。

1. ssh コマンドで認証を試みると、libpam ライブラリーがトリガーされます。

2. libpam ライブラリーは、認証の試行を要求するサービスに対応する /etc/pam.d/ ディレクトリーの PAM ファイルを参照します。この例では、ローカルホストの SSH サービス経由で認証されている例では、libpam ライブラリーは /etc/pam.d/system-auth 設定ファイルを確認し、SSSD PAM の pam_sss.so エントリーを検出します。

   auth    sufficient    pam_sss.so

   Copy to Clipboard Toggle word wrap
3. 利用可能な認証方法を判断するため、libpam ライブラリーは pam_sss モジュールを開き、SSSD サービスの sssd _pam PAM レスポンダーに SSS_PAM_PREAUTH リクエストを送信します。
4. スマートカード認証が設定されていると、SSSD サービスは一時的な p11_child プロセスを生成し、スマートカードを確認し、そこから証明書を取得します。
5. ユーザーにスマートカード認証が設定されていると、sssd_pam レスポンダーは、スマートカードの証明書とユーザーを照合します。sssd_pam レスポンダーは、グループメンバーシップがアクセス制御に影響する可能性があるため、ユーザーが属するグループの検索も実行します。
6. sssd_pam レスポンダーは、SSS_PAM_PREAUTH 要求を sssd_be バックエンドレスに送信し、パスワードや 2 要素認証などのサーバーがサポートする認証方法を表示します。SSSD サービスが IPA レスポンダーを使用する IdM 環境では、デフォルトの認証方法は Kerberos です。この例では、ユーザーは簡単な Kerberos パスワードで認証されます。
7. sssd_be レスポンダーは一時的な krb5_child プロセスを起動します。
8. krb5_child プロセスは、IdM サーバーの KDC に連絡して、利用可能な認証方法を確認します。

9. KDC はリクエストに応答します。

   1. krb5_child プロセスは応答を評価し、結果を sssd_be バックエンドプロセスに送信します。
   2. sssd_be バックエンドプロセスが結果を受け取ります。
   3. sssd_pam レスポンダーは結果を受け取ります。
   4. pam_sss モジュールは結果を受け取ります。
10. ユーザーにパスワード認証が設定されていると、pam_sss モジュールにより、パスワードの入力が求められます。スマートカード認証が設定されていると、pam_sss モジュールにより、スマートカードの PIN の入力が求められます。

11. モジュールがユーザー名とパスワードを使用して SSS_PAM_AUTHENTICATE 要求を送信します。これは次の宛先に送信されます。

    1. sssd_pam レスポンダー。
    2. sssd_be バックエンドプロセス。
12. sssd_be プロセスは、KDC に問い合わせる一時的な krb5_child プロセスを起動します。
13. krb5_child process は、ユーザー名とパスワードを使用して KDC から Kerberos チケット保証チケット (TGT) の取得を試みます。
14. krb5_child プロセスは、認証の試行の結果を受け取ります。

15. krb5_child プロセス:

    1. TGT を認証情報キャッシュに保存します。
    2. sssd_be バックエンドプロセスに認証結果を返します。

16. 認証結果は sssd_be プロセスから以下を行います。

    1. sssd_pam レスポンダー。
    2. pam_sss モジュール。
17. pam_sss モジュールは、その他のアプリケーションが参照できるように、環境変数をユーザーの TGT の場所で設定します。

手順

1. SSSD サービスおよびそのプロセスが実行していることを確認します。

   [root@client ~]# pstree -a | grep sssd
     |-sssd -i --logger=files
     |   |-sssd_be --domain implicit_files --uid 0 --gid 0 --logger=files
     |   |-sssd_be --domain <domain_name> --uid 0 --gid 0 --logger=files
     |   |-sssd_ifp --uid 0 --gid 0 --logger=files
     |   |-sssd_nss --uid 0 --gid 0 --logger=files
     |   |-sssd_pac --uid 0 --gid 0 --logger=files
     |   |-sssd_pam --uid 0 --gid 0 --logger=files
     |   |-sssd_ssh --uid 0 --gid 0 --logger=files
     |   `-sssd_sudo --uid 0 --gid 0 --logger=files
     |-sssd_kcm --uid 0 --gid 0 --logger=files

   Copy to Clipboard Toggle word wrap

2. クライアントが IP アドレスを使用してユーザーデータベースサーバーに接続できることを確認します。

   [user@client ~]$ ping <IP_address_of_the_database_server>

   Copy to Clipboard Toggle word wrap

   この手順が失敗した場合は、ネットワークとファイアウォール設定が、IdM クライアントとサーバー間の直接通信が許可されていることを確認してください。firewalld の使用および設定 を参照してください。

3. クライアントが、完全修飾ホスト名を使用して IdM LDAP サーバー (IdM ユーザー用) または AD ドメインコントローラー (AD ユーザーの場合) を検出して連絡できることを確認します。

   [user@client ~]$ dig -t SRV ldap._tcp.<domain>@<server_name>
   [user@client ~]$ ping <fully_qualified_host_name_of_the_server>

   Copy to Clipboard Toggle word wrap

   この手順が失敗した場合は、/etc/resolv.conf ファイルを含む Dynamic Name Service (DNS) の設定を確認してください。DNS サーバーの順序の設定 を参照してください。

   注記

   デフォルトでは、SSSD サービスは DNS サービス (SRV) レコードを介して LDAP サーバーと AD DC を自動的に検出しようとします。SSSD を特定のサーバーに制限するには、sssd.conf 設定ファイルで次のオプションを使用してサーバーを定義します。

   • ipa_server = <fully_qualified_host_name_of_the_server>
   • ad_server = <fully_qualified_host_name_of_the_server>
   • ldap_uri = <fully_qualified_host_name_of_the_server>

   このオプションを使用する場合は、そのオプションに記載されているサーバーと通信できることを確認します。

4. クライアントが LDAP サーバーに対して認証でき、ldapsearch コマンドでユーザー情報を取得できることを確認します。

   1. LDAP サーバーが server.example.com などの IdM サーバーである場合は、ホストの Kerberos チケットを取得し、ホスト Kerberos プリンシパルで認証されるデータベース検索を実行します。

      [user@client ~]$ kinit -k 'host/client.example.com@EXAMPLE.COM'
      [user@client ~]$ ldapsearch -LLL -Y GSSAPI -h server.example.com -b “dc=example,dc=com” uid=<idm_user>

      Copy to Clipboard Toggle word wrap

   2. LDAP サーバーが server.example.com などの Active Directory (AD) Domain Controller (DC) サーバーである場合は、ホストの Kerberos チケットを取得し、ホスト Kerberos プリンシパルで認証されるデータベース検索を実行します。

      [user@client ~]$ kinit -k 'CLIENT$@AD.EXAMPLE.COM'
      [user@client ~]$ ldapsearch -LLL -Y GSSAPI -h server.ad.example.com -b “dc=example,dc=com” sAMAccountname=<idm_user>

      Copy to Clipboard Toggle word wrap

   3. LDAP サーバーがプレーン LDAP サーバーであり、sssd.conf ファイルに ldap_default_bind_dn および ldap_default_authtok オプションを設定した場合は、同じ ldap_default_bind_dn アカウントとして認証されます。

      [user@client ~]$ ldapsearch -xLLL -D "cn=ldap_default_bind_dn_value" -W -h ldapserver.example.com -b “dc=example,dc=com” uid=<idm_user>

      Copy to Clipboard Toggle word wrap

   この手順が失敗した場合は、データベース設定で、ホストが LDAP サーバーを検索できることを確認します。

5. SSSD サービスは Kerberos 暗号化を使用するため、ログインできないユーザーとして Kerberos チケットを取得できます。

   1. LDAP サーバーが IdM サーバーの場合:

      [user@client ~]$ kinit <idm_user>

      Copy to Clipboard Toggle word wrap

   2. LDAP サーバーデータベースが AD サーバーの場合:

      [user@client ~]$ kinit <ad_user@AD.EXAMPLE.COM>

      Copy to Clipboard Toggle word wrap

   この手順が失敗した場合は、Kerberos サーバーが適切に動作し、すべてのサーバーが同期され、ユーザーアカウントがロックされていないことを確認します。

6. コマンドラインに関するユーザー情報を取得できることを確認します。

   [user@client ~]$ getent passwd <idm_user>
   [user@client ~]$ id <idm_user>

   Copy to Clipboard Toggle word wrap

   この手順が失敗した場合は、クライアントの SSSD サービスがユーザーデータベースから情報を受信できることを確認します。

   1. /var/log/messages ログファイルのエラーを確認します。
   2. SSSD サービスで詳細なロギングを有効にし、デバッグログを収集して、問題のソースに関するログを確認します。
   3. オプション: Red Hat テクニカルサポートケースを作成し、収集したトラブルシューティング情報を提供します。

7. ホスト上で sudo 権限を持っている場合は、sssctl ユーティリティーを使用して、ユーザーがログインできるかどうかを確認します。

   [user@client ~]$ sudo sssctl user-checks -a auth -s ssh <idm_user>

   Copy to Clipboard Toggle word wrap

   この手順が失敗した場合は、PAM 設定、IdM HBAC ルール、IdM RBAC ルールなどの認可設定を確認します。

   1. ユーザーの UID が、/etc/login.defs ファイルで定義されている UID_MIN 以上であることを確認してください。
   2. /var/log/secure ログファイルおよび /var/log/messages ログファイルで認可エラーを確認します。
   3. SSSD サービスで詳細なロギングを有効にし、デバッグログを収集して、問題のソースに関するログを確認します。
   4. オプション: Red Hat テクニカルサポートケースを作成し、収集したトラブルシューティング情報を提供します。

手順

1. テキストエディターで /etc/sssd/sssd.conf ファイルを開きます。

2. debug_level オプションをファイルのすべてのセクションに追加し、デバッグレベルを、選択した詳細に設定します。

   [domain/<domain_name>]
   debug_level = 6
   id_provider = ipa
   ...
   
   [sssd]
   debug_level = 6
   services = nss, pam, ifp, ssh, sudo
   domains = <domain_name>
   
   [nss]
   debug_level = 6
   
   [pam]
   debug_level = 6
   
   [sudo]
   debug_level = 6
   
   [ssh]
   debug_level = 6
   
   [pac]
   debug_level = 6
   
   [ifp]
   debug_level = 6

   Copy to Clipboard Toggle word wrap
3. sssd.conf ファイルを保存して閉じます。

4. SSSD サービスを再起動して、新しい設定を読み込みます。

   [root@server ~]# systemctl restart sssd

   Copy to Clipboard Toggle word wrap

手順

1. IdM サーバーで詳細な SSSD デバッグロギングを有効にします。

   [root@server ~]# sssctl debug-level 6

   Copy to Clipboard Toggle word wrap

2. 認証問題が発生しているユーザーの SSSD キャッシュでオブジェクトを無効にするため、LDAP サーバーを省略し、SSSD がすでにキャッシュされている情報を取得しません。

   [root@server ~]# sssctl cache-expire -u <idm_user>

   Copy to Clipboard Toggle word wrap

3. 古い SSSD ログを削除して、トラブルシューティングのデータセットを最小限に抑える。

   [root@server ~]# sssctl logs-remove

   Copy to Clipboard Toggle word wrap

4. 認証問題が発生し、試行前後にタイムスタンプを収集する際に、ユーザーが認証問題が発生しようと試みます。これらのタイムスタンプは、データセットのスコープをさらに絞り込むことができます。

   [root@server sssd]# date; su <idm_user>; date
   Mon Mar 29 15:33:48 EDT 2021
   su: user idm_user does not exist
   Mon Mar 29 15:33:49 EDT 2021

   Copy to Clipboard Toggle word wrap

5. オプション: 詳細な SSSD ログの収集を継続しない場合は、デバッグレベルを下げます。

   [root@server ~]# sssctl debug-level 2

   Copy to Clipboard Toggle word wrap

6. 障害のある要求に関する情報を SSSD ログで確認します。たとえば、/var/log/sssd/sssd_example.com.log ファイルを確認すると、SSSD サービスが cn=accounts,dc=example,dc=com LDAP サブツリーでユーザーを見つけられなかったことを示しています。これは、ユーザーが存在しないか、別の場所に存在することを示しています。

   (Mon Mar 29 15:33:48 2021) [sssd[be[example.com]]] [dp_get_account_info_send] (0x0200): Got request for [0x1][BE_REQ_USER][name=idm_user@example.com]
   ...
   (Mon Mar 29 15:33:48 2021) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(uid=idm_user)(objectclass=posixAccount)(uid=)(&(uidNumber=)(!(uidNumber=0))))][cn=accounts,dc=example,dc=com].
   (Mon Mar 29 15:33:48 2021) [sssd[be[example.com]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set
   (Mon Mar 29 15:33:48 2021) [sssd[be[example.com]]] [sdap_search_user_process] (0x0400): Search for users, returned 0 results.
   (Mon Mar 29 15:33:48 2021) [sssd[be[example.com]]] [sysdb_search_by_name] (0x0400): No such entry
   (Mon Mar 29 15:33:48 2021) [sssd[be[example.com]]] [sysdb_delete_user] (0x0400): Error: 2 (No such file or directory)
   (Mon Mar 29 15:33:48 2021) [sssd[be[example.com]]] [sysdb_search_by_name] (0x0400): No such entry
   (Mon Mar 29 15:33:49 2021) [sssd[be[example.com]]] [ipa_id_get_account_info_orig_done] (0x0080): Object not found, ending request

   Copy to Clipboard Toggle word wrap

7. 認証問題の原因を判断できない場合は、以下を行います。

   1. 最近生成した SSSD ログを収集します。

      [root@server ~]# sssctl logs-fetch sssd-logs-Mar29.tar

      Copy to Clipboard Toggle word wrap

   2. Red Hat テクニカルサポートケースを作成し、以下を提供します。

      1. SSSD ログ: sssd-logs-Mar29.tar

      2. ログに対応する要求のタイムスタンプおよびユーザー名を含むコンソールの出力。

         [root@server sssd]# date; id <idm_user>; date
         Mon Mar 29 15:33:48 EDT 2021
         id: 'idm_user': no such user
         Mon Mar 29 15:33:49 EDT 2021

         Copy to Clipboard Toggle word wrap

手順

1. クライアントで、テキストエディターで /etc/sssd/sssd.conf ファイルを開きます。

2. クライアントで、ファイルの [domain] セクションに ipa_server オプションを追加し、このオプションを完全修飾ドメイン名 (FQDN) を使用して IdM サーバーに設定します。これにより、IdM クライアントは他の IdM サーバーの自動検出を避け、このテストを 1 つのクライアントおよびサーバー 1 台だけに制限します。

   [domain/<idm_domain_name>]
   ipa_server = <idm_server_fqdn>
   ...

   Copy to Clipboard Toggle word wrap
3. クライアントで sssd.conf ファイルを保存して閉じます。

4. クライアントで SSSD サービスを再起動して、設定の変更を読み込みます。

   [root@client ~]# systemctl restart sssd

   Copy to Clipboard Toggle word wrap

5. サーバーおよびクライアントで、詳細な SSSD デバッグロギングを有効にします。

   [root@server ~]# sssctl debug-level 6

   Copy to Clipboard Toggle word wrap

   [root@client ~]# sssctl debug-level 6

   Copy to Clipboard Toggle word wrap

6. サーバーおよびクライアントで、認証問題が発生しているユーザーの SSSD キャッシュの検証オブジェクトでは、LDAP データベースを迂回せず、SSSD がすでにキャッシュされています。

   [root@server ~]# sssctl cache-expire -u <idm_user>

   Copy to Clipboard Toggle word wrap

   [root@client ~]# sssctl cache-expire -u <idm_user>

   Copy to Clipboard Toggle word wrap

7. サーバーおよびクライアントで、古い SSSD ログを削除して、トラブルシューティングのデータセットを最小限に抑える。

   [root@server ~]# sssctl logs-remove

   Copy to Clipboard Toggle word wrap

   [root@server ~]# sssctl logs-remove

   Copy to Clipboard Toggle word wrap

8. クライアントで、認証問題が発生し、試行前後にタイムスタンプを収集する際に、ユーザーが認証問題が発生しようと試みます。これらのタイムスタンプは、データセットのスコープをさらに絞り込むことができます。

   [root@client sssd]# date; su <idm_user>; date
   Mon Mar 29 16:20:13 EDT 2021
   su: user idm_user does not exist
   Mon Mar 29 16:20:14 EDT 2021

   Copy to Clipboard Toggle word wrap

9. オプション: サーバーおよびクライアントで、詳細な SSSD ログの収集を継続しない場合は、デバッグレベルを下げます。

   [root@server ~]# sssctl debug-level 0

   Copy to Clipboard Toggle word wrap

   [root@client ~]# sssctl debug-level 0

   Copy to Clipboard Toggle word wrap

10. サーバーおよびクライアントで、失敗した要求に関する情報を SSSD ログを確認します。

    1. クライアントログのクライアントからの要求を確認します。
    2. サーバーログのクライアントからの要求を確認します。
    3. サーバーログでリクエストの結果を確認します。
    4. サーバーからリクエストの結果を受信するクライアントの結果を確認します。

11. 認証問題の原因を判断できない場合は、以下を行います。

    1. IdM サーバーおよび IdM クライアントで最近生成した SSSD ログを収集します。ホスト名またはロールに応じてラベルを付けます。

       [root@server ~]# sssctl logs-fetch sssd-logs-server-Mar29.tar

       Copy to Clipboard Toggle word wrap

       [root@client ~]# sssctl logs-fetch sssd-logs-client-Mar29.tar

       Copy to Clipboard Toggle word wrap

    2. Red Hat テクニカルサポートケースを作成し、以下を提供します。

       1. SSSD デバッグログ:

          1. サーバーから sssd-logs-server-Mar29.tar
          2. クライアントからの sssd-logs-client-Mar29.tar

       2. ログに対応する要求のタイムスタンプおよびユーザー名を含むコンソールの出力。

          [root@client sssd]# date; su <idm_user>; date
          Mon Mar 29 16:20:13 EDT 2021
          su: user idm_user does not exist
          Mon Mar 29 16:20:14 EDT 2021

          Copy to Clipboard Toggle word wrap

手順

1. SSSD のログファイルを確認するために、less ユーティリティーを使用してログファイル /var/log/sssd/sssd_<domain_name>.log を開きます。以下に例を示します。

   [root@server ~]# less /var/log/sssd/sssd_example.com.log

   Copy to Clipboard Toggle word wrap

2. SSSD ログでクライアント要求に関する情報を確認します。

   (2021-07-26 18:26:37): [be[testidm.com]] [dp_req_destructor] (0x0400): [RID#3] Number of active DP request: 0
   (2021-07-26 18:26:37): [be[testidm.com]] [dp_req_reply_std] (0x1000): [RID#3] DP Request AccountDomain #3: Returning [Internal Error]: 3,1432158301,GetAccountDomain() not supported
   (2021-07-26 18:26:37): [be[testidm.com]] [dp_attach_req] (0x0400): [RID#4] DP Request Account #4: REQ_TRACE: New request. [sssd.nss CID #1] Flags [0x0001].
   (2021-07-26 18:26:37): [be[testidm.com]] [dp_attach_req] (0x0400): [RID#4] Number of active DP request: 1

   Copy to Clipboard Toggle word wrap

   SSSD ログファイルからのこの出力例は、2 つの異なる要求について一意の識別子の RID#3 および RID#4 を示しています。

手順

1. ~/MyPlaybooks/ ディレクトリーに移動します。

   $ cd ~/MyPlaybooks

   Copy to Clipboard Toggle word wrap

2. ~/MyPlaybooks/ansible.cfg ファイルを以下の内容で作成します。

   [defaults]
   inventory = /home/your_username/MyPlaybooks/inventory
   remote_user = admin

   Copy to Clipboard Toggle word wrap

3. ~/MyPlaybooks/inventory ファイルを以下の内容で作成します。

   [eu]
   server.idm.example.com
   
   [us]
   replica.idm.example.com
   
   [ipaserver:children]
   eu
   us

   Copy to Clipboard Toggle word wrap

   この設定は、これらの場所にあるホストの 2 つのホストグループ (eu と us) を定義します。さらに、この設定は、eu および us グループのすべてのホストを含む ipaserver ホストグループを定義します。

4. オプション: SSH 公開鍵および秘密鍵を作成します。テスト環境でのアクセスを簡素化するには、秘密鍵にパスワードを設定しないでください。

   $ ssh-keygen

   Copy to Clipboard Toggle word wrap

5. 各マネージドノードの IdM admin アカウントに SSH 公開鍵をコピーします。

   $ ssh-copy-id admin@server.idm.example.com
   $ ssh-copy-id admin@replica.idm.example.com

   Copy to Clipboard Toggle word wrap

   これらのコマンドでは、IdM 管理者 パスワードを入力します。

6. Vault パスワードを含む password_file ファイルを作成します。

   redhat

   Copy to Clipboard Toggle word wrap

7. ファイルを変更する権限を変更します。

   $ chmod 0600 password_file

   Copy to Clipboard Toggle word wrap

8. IdM の admin パスワードを保存する secret.yml Ansible Vault を作成します。

   1. Vault パスワードを保存するように password_file を設定します。

      $ ansible-vault create --vault-password-file=password_file secret.yml

      Copy to Clipboard Toggle word wrap

   2. プロンプトが表示されたら、secret.yml ファイルの内容を入力します。

      ipaadmin_password: Secret123

      Copy to Clipboard Toggle word wrap

手順

1. Ansible Playbook ファイル /usr/share/doc/ansible-freeipa/playbooks/config/retrieve-config.yml を開いて編集します。

   ---
   - name: Playbook to handle global IdM configuration
     hosts: ipaserver
     become: no
     gather_facts: no
   
     vars_files:
     - /home/user_name/MyPlaybooks/secret.yml
     tasks:
     - name: Query IPA global configuration
       ipaconfig:
         ipaadmin_password: "{{ ipaadmin_password }}"
       register: serverconfig
   
     - debug:
         msg: "{{ serverconfig }}"

   Copy to Clipboard Toggle word wrap

2. 以下を変更してファイルを調整します。

   • IdM 管理者のパスワード。
   • その他の値 (必要な場合)。
3. ファイルを保存します。

4. Ansible Playbook を実行します。Playbook ファイル、secret.yml ファイルを保護するパスワードを格納するファイル、およびインベントリーファイルを指定します。

   $ ansible-playbook --vault-password-file=password_file -v -i path_to_inventory_directory/inventory.file /usr/share/doc/ansible-freeipa/playbooks/config/retrieve-config.yml
   [...]
   TASK [debug]
   ok: [server.idm.example.com] => {
       "msg": {
           "ansible_facts": {
               "discovered_interpreter_
           },
           "changed": false,
           "config": {
               "ca_renewal_master_server": "server.idm.example.com",
               "configstring": [
                   "AllowNThash",
                   "KDC:Disable Last Success"
               ],
               "defaultgroup": "ipausers",
               "defaultshell": "/bin/bash",
               "emaildomain": "idm.example.com",
               "enable_migration": false,
               "groupsearch": [
                   "cn",
                   "description"
               ],
               "homedirectory": "/home",
               "maxhostname": "64",
               "maxusername": "64",
               "pac_type": [
                   "MS-PAC",
                   "nfs:NONE"
               ],
               "pwdexpnotify": "4",
               "searchrecordslimit": "100",
               "searchtimelimit": "2",
               "selinuxusermapdefault": "unconfined_u:s0-s0:c0.c1023",
               "selinuxusermaporder": [
                   "guest_u:s0$xguest_u:s0$user_
               ],
               "usersearch": [
                   "uid",
                   "givenname",
                   "sn",
                   "telephonenumber",
                   "ou",
                   "title"
               ]
           },
           "failed": false
       }
   }

   Copy to Clipboard Toggle word wrap

手順

1. 必要に応じて、現在の IdM CA 更新サーバーを特定します。

   $ ipa config-show | grep 'CA renewal'
     IPA CA renewal master: server.idm.example.com

   Copy to Clipboard Toggle word wrap

2. inventory.file などのインベントリーファイルを作成して、そのファイルに ipaserver を定義します。

   [ipaserver]
   server.idm.example.com

   Copy to Clipboard Toggle word wrap

3. Ansible Playbook ファイル /usr/share/doc/ansible-freeipa/playbooks/config/set-ca-renewal-master-server.yml を開いて編集します。

   ---
   - name: Playbook to handle global DNS configuration
     hosts: ipaserver
     become: no
     gather_facts: no
     vars_files:
     - /home/user_name/MyPlaybooks/secret.yml
   
     tasks:
     - name: set ca_renewal_master_server
       ipaconfig:
         ipaadmin_password: "{{ ipaadmin_password }}"
         ca_renewal_master_server: carenewal.idm.example.com

   Copy to Clipboard Toggle word wrap

4. 以下を変更してファイルを調整します。

   • ipaadmin_password 変数で設定した IdM 管理者のパスワード
   • ca_renewal_master_server 変数で設定した CA 更新サーバーの名前。
5. ファイルを保存します。

6. Ansible Playbook を実行します。Playbook ファイル、secret.yml ファイルを保護するパスワードを格納するファイル、およびインベントリーファイルを指定します。

   $ ansible-playbook --vault-password-file=password_file -v -i path_to_inventory_directory/inventory.file /usr/share/doc/ansible-freeipa/playbooks/config/set-ca-renewal-master-server.yml

   Copy to Clipboard Toggle word wrap

1. IdM 管理者として ipaserver にログインします。

   $ ssh admin@server.idm.example.com
   Password:
   [admin@server /]$

   Copy to Clipboard Toggle word wrap

2. IdM CA 更新サーバーの ID を要求します。

   $ ipa config-show | grep ‘CA renewal’
   IPA CA renewal master:  carenewal.idm.example.com

   Copy to Clipboard Toggle word wrap

   この出力には、carenewal.idm.example.com サーバーが新しい CA 更新サーバーであることが分かります。

手順

1. 必要に応じて、Ansible Playbook retrieve-config.yml を使用して、IdM ユーザーの現在のシェルを特定します。詳細は、Ansible Playbook での IdM 設定の取得 を参照してください。

2. inventory.file などのインベントリーファイルを作成して、そのファイルに ipaserver を定義します。

   [ipaserver]
   server.idm.example.com

   Copy to Clipboard Toggle word wrap

3. Ansible Playbook /usr/share/doc/ansible-freeipa/playbooks/config/ensure-config-options-are-set.yml ファイルを開いて編集します。

   ---
   - name: Playbook to ensure some config options are set
     hosts: ipaserver
     vars_files:
     - /home/user_name/MyPlaybooks/secret.yml
   
     tasks:
     # Set defaultlogin and maxusername
     - ipaconfig:
         ipaadmin_password: "{{ ipaadmin_password }}"
         defaultshell: /bin/bash
         maxusername: 64

   Copy to Clipboard Toggle word wrap

4. 以下を変更してファイルを調整します。

   • ipaadmin_password 変数で設定した IdM 管理者のパスワード
   • defaultshell 変数で設定されている IdM ユーザーのデフォルトのシェルが /bin/sh に設定されます。
5. ファイルを保存します。

6. Ansible Playbook を実行します。Playbook ファイル、secret.yml ファイルを保護するパスワードを格納するファイル、およびインベントリーファイルを指定します。

   $ ansible-playbook --vault-password-file=password_file -v -i path_to_inventory_directory/inventory.file /usr/share/doc/ansible-freeipa/playbooks/config/ensure-config-options-are-set.yml

   Copy to Clipboard Toggle word wrap

1. IdM 管理者として ipaserver にログインします。

   $ ssh admin@server.idm.example.com
   Password:
   [admin@server /]$

   Copy to Clipboard Toggle word wrap

2. 現在のシェルを表示します。

   [admin@server /]$ echo "$SHELL"
   /bin/sh

   Copy to Clipboard Toggle word wrap

   ログインしているユーザーが sh シェルを使用している。

手順

1. ~/MyPlaybooks/ ディレクトリーに移動します。

   $ cd ~/MyPlaybooks/

   Copy to Clipboard Toggle word wrap
2. netbios-domain-name-present.yml Ansible Playbook ファイルを作成します。

3. 以下の内容をファイルに追加します。

   ---
   - name: Playbook to change IdM domain netbios name
     hosts: ipaserver
     become: no
     gather_facts: no
   
   
     vars_files:
     - /home/user_name/MyPlaybooks/secret.yml
   
     tasks:
       - name: Set IdM domain netbios name
         ipaconfig:
           ipaadmin_password: "{{ ipaadmin_password }}"
           netbios_name: IPADOM

   Copy to Clipboard Toggle word wrap
4. ファイルを保存します。

5. Ansible Playbook を実行します。Playbook ファイル、secret.yml ファイルを保護するパスワードを格納するファイル、およびインベントリーファイルを指定します。

   $ ansible-playbook --vault-password-file=password_file -v -i inventory netbios-domain-name-present.yml

   Copy to Clipboard Toggle word wrap

   プロンプトが表示されたら、ボールトファイルのパスワードを入力します。

手順

1. ~/MyPlaybooks/ ディレクトリーに移動します。

   $ cd ~/MyPlaybooks/

   Copy to Clipboard Toggle word wrap
2. sids-for-users-and-groups-present.yml Ansible Playbook ファイルを作成します。

3. 以下の内容をファイルに追加します。

   ---
   - name: Playbook to ensure SIDs are enabled and users and groups have SIDs
     hosts: ipaserver
     become: no
     gather_facts: no
   
     vars_files:
     - /home/user_name/MyPlaybooks/secret.yml
   
     tasks:
       - name: Enable SID and generate users and groups SIDS
         ipaconfig:
           ipaadmin_password: "{{ ipaadmin_password }}"
           enable_sid: true
           add_sids: true

   Copy to Clipboard Toggle word wrap

   enable_sid 変数は、将来の IdM ユーザーおよびグループの SID 生成を有効にします。add_sids 変数は、既存の IdM ユーザーおよびグループの SID を生成します。

   注記

   add_sids: true を使用する場合は、enable_sid 変数を true に設定する必要もあります。

4. ファイルを保存します。

5. Ansible Playbook を実行します。Playbook ファイル、secret.yml ファイルを保護するパスワードを格納するファイル、およびインベントリーファイルを指定します。

   $ ansible-playbook --vault-password-file=password_file -v -i inventory sids-for-users-and-groups-present.yml

   Copy to Clipboard Toggle word wrap

   プロンプトが表示されたら、ボールトファイルのパスワードを入力します。

手順

1. 端末を開き、IdM サーバーに接続します。

2. ユーザーのログイン、ユーザーの名前、および名字を追加します。メールアドレスを追加することもできます。

   $ ipa user-add user_login --first=first_name --last=last_name --email=email_address

   Copy to Clipboard Toggle word wrap

   IdM は、以下の正規表現で説明できるユーザー名をサポートします。

   [a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?

   Copy to Clipboard Toggle word wrap
   注記

   ユーザー名の末尾がドル記号 ($) で終わる場合は、Samba 3.x マシンでのサポートが有効になります。

   大文字を含むユーザー名を追加すると、IdM が名前を保存する際に自動的に小文字に変換されます。したがって、IdM にログインする場合は、常にユーザー名を小文字で入力する必要があります。また、user と User など、大文字と小文字のみが異なるユーザー名を追加することはできません。

   ユーザー名のデフォルトの長さは、最大 32 文字です。これを変更するには、ipa config-mod --maxusername コマンドを使用します。たとえば、ユーザー名の最大長を 64 文字にするには、次のコマンドを実行します。

   $ ipa config-mod --maxusername=64
    Maximum username length: 64
    ...

   Copy to Clipboard Toggle word wrap

   ipa user-add コマンドには、多くのパラメーターが含まれます。リストを表示するには、ipa help コマンドを使用します。

   $ ipa help user-add

   Copy to Clipboard Toggle word wrap

   ipa help コマンドの詳細は、IPA のヘルプとは を参照してください。

手順

1. 端末を開き、IdM サーバーに接続します。

2. 次のコマンドでユーザーアカウントをアクティブ化します。

   $ ipa stageuser-activate user_login
   -------------------------
   Stage user user_login activated
   -------------------------
   ...

   Copy to Clipboard Toggle word wrap

手順

1. 端末を開き、IdM サーバーに接続します。

2. 次のコマンドで、ユーザーアカウントを保存します。

   $ ipa user-del --preserve user_login
   --------------------
   Deleted user "user_login"
   --------------------

   Copy to Clipboard Toggle word wrap
   注記

   ユーザーアカウントが削除されたという出力が表示されたにもかかわらず、アカウントは保持されています。

手順

1. 端末を開き、IdM サーバーに接続します。

2. 次のコマンドで、ユーザーアカウントを削除します。

   $ ipa user-del user_login
   --------------------
   Deleted user "user_login"
   --------------------

   Copy to Clipboard Toggle word wrap

手順

1. 端末を開き、IdM サーバーに接続します。

2. 次のコマンドでユーザーアカウントをアクティブ化します。

   $ ipa user-undel user_login
   ------------------------------
   Undeleted user account "user_login"
   ------------------------------

   Copy to Clipboard Toggle word wrap

   または、ユーザーアカウントをステージユーザーとして復元することもできます。

   $ ipa user-stage user_login
   ------------------------------
   Staged user account "user_login"
   ------------------------------

   Copy to Clipboard Toggle word wrap