Identity Management の設定および管理

手順

1. IdM にログインします。

   • ローカルシステムに現在ログインしているユーザーのユーザー名で、(ユーザー名を指定せずに) kinit を使用します。たとえば、ローカルシステムにログインしているユーザーが example_user の場合は、次のコマンドを実行します。

     [example_user@server ~]$ kinit
     Password for example_user@EXAMPLE.COM:
     [example_user@server ~]$

     ローカルユーザーのユーザー名と、IdM のユーザーエントリーが一致しないと、認証に失敗します。

     [example_user@server ~]$ kinit
     kinit: Client 'example_user@EXAMPLE.COM' not found in Kerberos database while getting initial credentials

   • ローカルユーザー名に対応しない Kerberos プリンシパルを使用して、kinit ユーティリティーに必要なユーザー名を渡します。たとえば、admin ユーザーとしてログインするには、次のコマンドを実行します。

     [example_user@server ~]$ kinit admin
     Password for admin@EXAMPLE.COM:
     [example_user@server ~]$

2. 必要に応じて、ログインが成功したことを確認するには、klist ユーティリティーを使用して、キャッシュした TGT を表示します。以下の例では、キャッシュに example_user プリンシパルのチケットが含まれています。これは、このホストでは IdM サービスにアクセスするのは、example_user にのみ許可されていることを示しています。

   $ klist
   Ticket cache: KEYRING:persistent:0:0
   Default principal: example_user@EXAMPLE.COM
   
   Valid starting     	Expires            	Service principal
   11/10/2019 08:35:45  	11/10/2019 18:35:45  	krbtgt/EXAMPLE.COM@EXAMPLE.COM

手順

1. Kerberos チケットを破棄するには、次のコマンドを実行します。

   [example_user@server ~]$ kdestroy

2. 必要に応じて、Kerberos チケットが破棄されたことを確認するには、次のコマンドを実行します。

   [example_user@server ~]$ klist
   klist: Credentials cache keyring 'persistent:0:0' not found

手順

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

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

   警告

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

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

   $ export KRB5_CONFIG=/etc/krb5_ipa.conf

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

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

手順

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

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

   $ ipa help topics

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

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

   $ ipa help user

4. IPA ヘルプの出力が長すぎるため、テキスト全体を表示できない場合は、以下の構文を使用します。

   $ ipa help user | less

   スクロールダウンすれば、ヘルプ全体を表示できます

手順

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

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

   $ ipa help commands

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

   $ ipa help user-add

手順

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

2. 新しいユーザーを追加するコマンドを入力します。

   $ ipa user-add

   このコマンドは、ユーザーアカウントの作成に必要な基本データの提供を求めるスクリプトを実行します。

3. First name: フィールドに、新規ユーザーの名前を入力して、Enter キーを押します。
4. Last name: フィールドに、新規ユーザーの苗字を入力し、Enter キーを押します。

5. User login [suggested user name]: にユーザー名を入力します。または、提案されたユーザー名を使用する場合は、Enter キーを押します。

   ユーザー名は、IdM データベース全体で一意にする必要があります。そのユーザー名がすでに存在するためにエラーが発生した場合は、ipa user-add コマンドでそのプロセスを再度実行し、別の一意のユーザー名を使用します。

手順

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

2. ipa user-mod コマンドを入力し、変更するユーザーと、パスワードを追加するための --password などのオプションを指定します。

   $ ipa user-mod euser --password

   このコマンドは、新しいパスワードを追加できるスクリプトを実行します。

3. 新しいパスワードを入力し、Enter キーを押します。

手順

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

   https://server.example.com

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

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

   

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

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

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

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

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

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

   

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

手順

1. IdM にログインします。

   • ローカルシステムに現在ログインしているユーザーのユーザー名で、(ユーザー名を指定せずに) kinit を使用します。たとえば、ローカルシステムにログインしているユーザーが example_user の場合は、次のコマンドを実行します。

     [example_user@server ~]$ kinit
     Password for example_user@EXAMPLE.COM:
     [example_user@server ~]$

     ローカルユーザーのユーザー名と、IdM のユーザーエントリーが一致しないと、認証に失敗します。

     [example_user@server ~]$ kinit
     kinit: Client 'example_user@EXAMPLE.COM' not found in Kerberos database while getting initial credentials

   • ローカルユーザー名に対応しない Kerberos プリンシパルを使用して、kinit ユーティリティーに必要なユーザー名を渡します。たとえば、admin ユーザーとしてログインするには、次のコマンドを実行します。

     [example_user@server ~]$ kinit admin
     Password for admin@EXAMPLE.COM:
     [example_user@server ~]$

2. 必要に応じて、ログインが成功したことを確認するには、klist ユーティリティーを使用して、キャッシュした TGT を表示します。以下の例では、キャッシュに example_user プリンシパルのチケットが含まれています。これは、このホストでは IdM サービスにアクセスするのは、example_user にのみ許可されていることを示しています。

   $ klist
   Ticket cache: KEYRING:persistent:0:0
   Default principal: example_user@EXAMPLE.COM
   
   Valid starting     	Expires            	Service principal
   11/10/2019 08:35:45  	11/10/2019 18:35:45  	krbtgt/EXAMPLE.COM@EXAMPLE.COM

手順

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

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

   

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

   

手順

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

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

   警告

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

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

   $ export KRB5_CONFIG=/etc/krb5_ipa.conf

   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

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

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

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

   ipa user-mod radiususer --radius=proxy_name

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

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

手順

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 フィールドにワンタイムパスワードを生成します。

   OTP 認証を有効にしていない場合は、このフィールドを空白のままにします。

4. 確認のために新しいパスワードを 2 回入力します。

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

   

手順

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

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

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

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

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

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 サービス経由で認証されている例では、pam_sss.so ライブラリーは /etc/pam.d/system-auth 設定ファイルを確認し、SSSD PAM の pam_sss.so エントリーを検出します。

   auth    sufficient    pam_sss.so

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 example.com --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

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

   [user@client ~]$ ping <IP_address_of_the_database_server>

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

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

   [user@client ~]$ dig -t SRV _ldap._tcp.example.com @<name_server>
   [user@client ~]$ ping <fully_qualified_host_name_of_the_server>

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

   注記

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

   • 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=<user_name>

   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=<user_name>

   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=<user_name>

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

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

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

      [user@client ~]$ kinit <user_name>

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

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

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

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

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

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

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

7. ホストで sudo を実行することが許可されている場合は、sssctl ユーティリティーを使用して、ユーザーがログインを許可されていることを確認します。

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

   この手順が失敗した場合は、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/example.com]
   debug_level = 6
   id_provider = ipa
   ...
   
   [sssd]
   debug_level = 6
   services = nss, pam, ifp, ssh, sudo
   domains = example.com
   
   [nss]
   debug_level = 6
   
   [pam]
   debug_level = 6
   
   [sudo]
   debug_level = 6
   
   [ssh]
   debug_level = 6
   
   [pac]
   debug_level = 6
   
   [ifp]
   debug_level = 6

3. sssd.conf ファイルを保存して閉じます。

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

   [root@server ~]# systemctl restart sssd

手順

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

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

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

   [root@server ~]# sssctl cache-expire -u idmuser

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

   [root@server ~]# sssctl logs-remove

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

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

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

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

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=idmuser@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=idmuser)(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

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

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

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

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

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

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

         [root@server sssd]# date; id idmuser; date
         Mon Mar 29 15:33:48 EDT 2021
         id: ‘idmuser’: no such user
         Mon Mar 29 15:33:49 EDT 2021

手順

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

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

   [domain/example.com]
   ipa_server = server.example.com
   ...

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

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

   [root@client ~]# systemctl restart sssd

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

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

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

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

   [root@server ~]# sssctl cache-expire -u idmuser

   [root@client ~]# sssctl cache-expire -u idmuser

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

   [root@server ~]# sssctl logs-remove

   [root@server ~]# sssctl logs-remove

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

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

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

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

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

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

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

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

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

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

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

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

       1. SSSD デバッグログ:

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

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

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

手順

1. SSSD ログファイルを確認するには、less ユーティリティーを使用してログファイルを開きます。たとえば、/var/log/sssd/sssd_example.com.log を表示するには、次のコマンドを実行します。

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

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

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

手順

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

   $ cd ~/MyPlaybooks

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

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

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

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

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

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

   $ ssh-keygen

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

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

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

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

   redhat

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

   $ chmod 0600 password_file

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

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

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

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

      ipaadmin_password: Secret123

手順

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 }}"

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
       }
   }

手順

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

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

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

   [ipaserver]
   server.idm.example.com

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

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

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

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

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

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

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

手順

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

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

   [ipaserver]
   server.idm.example.com

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

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

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

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

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

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

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

手順

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

   $ cd ~/MyPlaybooks/

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

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

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

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

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

手順

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

   $ cd ~/MyPlaybooks/

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

   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

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

手順

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

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

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

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

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

   注記

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

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

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

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

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

   $ ipa help user-add

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

手順

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

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

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

手順

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

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

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

   注記

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

手順

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

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

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

手順

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

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

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

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

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

手順

1. IdM Web UI にログインします。

   詳細は Web ブラウザーで IdM Web UI へのアクセス を参照してください。

2. ユーザー → ステージユーザー タブに移動します。

   または、ユーザー → アクティブユーザー にユーザーアカウントを追加できますが、アカウントにユーザーグループを追加することはできません。

3. + 追加 アイコンをクリックします。
4. ステージユーザーの追加 ダイアログボックスで、新規ユーザーの 名前 と 名字 を入力します。

5. (必要に応じて) ユーザーログイン フィールドにログイン名を追加します。

   空のままにすると、IdM サーバーは、名字の前に、名前の最初の 1 文字が追加された形式で、ログイン名を作成します。ログイン名には、32 文字まで使用できます。

6. (必要に応じて) GID ドロップダウンメニューで、ユーザーに含まれるグループを選択します。
7. [オプション] パスワード および パスワードの確認 フィールドに、パスワードを入力して確定し、両方が一致していることを確認します。

8. Add ボタンをクリックします。

   

手順

1. IdM Web UI にログインします。

   詳細は Web ブラウザーで IdM Web UI へのアクセス を参照してください。

2. ユーザー → ステージユーザー タブに移動します。
3. 有効にするユーザーアカウントのチェックボックスをクリックします。

4. アクティベート ボタンをクリックします。

   

5. Confirmation ダイアログボックスで OK をクリックします。

手順

1. IdM Web UI にログインします。

   詳細は Web ブラウザーで IdM Web UI へのアクセス を参照してください。

2. ユーザー → アクティブユーザー タブに移動します。
3. 無効にするユーザーアカウントのチェックボックスをクリックします。

4. 無効 ボタンをクリックします。

   

5. 確認 ダイアログボックスで、OK ボタンをクリックします。

手順

1. IdM Web UI にログインします。
2. ユーザー → アクティブユーザー タブに移動します。
3. 有効にするユーザーアカウントのチェックボックスをクリックします。

4. 有効 ボタンをクリックします。

   

5. 確認 ダイアログボックスで、OK ボタンをクリックします。

手順

1. IdM Web UI にログインします。

   詳細は Web ブラウザーで IdM Web UI へのアクセス を参照してください。

2. ユーザー → アクティブユーザー タブに移動します。
3. 保存するユーザーアカウントのチェックボックスをクリックします。

4. 削除 ボタンをクリックします。

   

5. ユーザーの削除 ダイアログボックスで、削除モード ラジオボタンを、保存 に切り替えます。

6. 削除 ボタンをクリックします。

   

手順

1. IdM Web UI にログインします。

   詳細は Web ブラウザーで IdM Web UI へのアクセス を参照してください。

2. ユーザー → 保存済みユーザー タブに移動します。
3. 復元するユーザーアカウントのチェックボックスをクリックします。

4. 復元 ボタンをクリックします。

   

5. 確認 ダイアログボックスで、OK ボタンをクリックします。

手順

1. IdM Web UI にログインします。

   詳細は Web ブラウザーで IdM Web UI へのアクセス を参照してください。

2. ユーザー → アクティブユーザー タブに移動します。

   ユーザー → ステージユーザー または ユーザー → 保存済みユーザー でも、ユーザーアカウントを削除できます。

3. 削除 アイコンをクリックします。
4. ユーザーの削除 ダイアログボックスで、モードの削除 ラジオボタンを、削除 に切り替えます。
5. 削除 ボタンをクリックします。

手順

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

   [ipaserver]
   server.idm.example.com

2. IdM に存在させるユーザーのデータを指定して Ansible Playbook ファイルを作成します。この手順は、/usr/share/doc/ansible-freeipa/playbooks/user/add-user.yml ファイルのサンプルをコピーして変更し、簡素化できます。たとえば、idm_user という名前のユーザーを作成し、 Password123 をユーザーパスワードとして追加するには、次のコマンドを実行します。

   ---
   - name: Playbook to handle users
     hosts: ipaserver
   
     vars_files:
     - /home/user_name/MyPlaybooks/secret.yml
     tasks:
     - name: Create user idm_user
       ipauser:
         ipaadmin_password: "{{ ipaadmin_password }}"
         name: idm_user
         first: Alice
         last: Acme
         uid: 1000111
         gid: 10011
         phone: "+555123457"
         email: idm_user@acme.com
         passwordexpiration: "2023-01-19 23:59:59"
         password: "Password123"
         update_password: on_create

   ユーザーを追加するには、以下のオプションを使用する必要があります。

   • 名前: ログイン名
   • first: 名前 (名) の文字列
   • last: 名前 (姓) の文字列

   利用可能なユーザーオプションの完全なリストは、/usr/share/doc/ansible-freeipa/README-user.md Markdown ファイルを参照してください。

   注記

   update_password: on_create オプションを使用する場合には、Ansible はユーザー作成時にのみユーザーパスワードを作成します。パスワードを指定してユーザーが作成されている場合には、Ansible では新しいパスワードは生成されません。

3. Playbook を実行します。

   $ ansible-playbook --vault-password-file=password_file -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/add-IdM-user.yml

手順

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

   [ipaserver]
   server.idm.example.com

2. IdM に存在させるユーザーのデータを指定して Ansible Playbook ファイルを作成します。この手順は、/usr/share/doc/ansible-freeipa/playbooks/user/ensure-users-present.yml ファイルのサンプルをコピーして変更し、簡素化できます。たとえば、ユーザー idm_user_1、idm_user_2、idm_user_3 を作成し、idm_user_1 のパスワードを Password123 として追加します。

   ---
   - name: Playbook to handle users
     hosts: ipaserver
   
     vars_files:
     - /home/user_name/MyPlaybooks/secret.yml
     tasks:
     - name: Create user idm_users
       ipauser:
         ipaadmin_password: "{{ ipaadmin_password }}"
         users:
         - name: idm_user_1
           first: Alice
           last: Acme
           uid: 10001
           gid: 10011
           phone: "+555123457"
           email: idm_user@acme.com
           passwordexpiration: "2023-01-19 23:59:59"
           password: "Password123"
         - name: idm_user_2
           first: Bob
           last: Acme
           uid: 100011
           gid: 10011
         - name: idm_user_3
           first: Eve
           last: Acme
           uid: 1000111
           gid: 10011

   注記

   update_password: on_create オプションを指定しないと、Ansible は Playbook が実行されるたびにユーザーパスワードを再設定します。最後に Playbook が実行されてからユーザーがパスワードを変更した場合には、Ansible はパスワードを再設定します。

3. Playbook を実行します。

   $ ansible-playbook --vault-password-file=password_file -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/add-users.yml

手順

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

   [ipaserver]
   server.idm.example.com

2. 必要なタスクが含まれる Ansible Playbook ファイルを作成します。存在させるユーザーのデータが指定された JSON ファイルを参照します。この手順は、/usr/share/doc/ansible-freeipa/ensure-users-present-ymlfile.yml ファイルのサンプルをコピーして変更し、簡素化できます。

   ---
   - name: Ensure users' presence
     hosts: ipaserver
   
     vars_files:
     - /home/user_name/MyPlaybooks/secret.yml
     tasks:
     - name: Include users.json
       include_vars:
         file: users.json
   
     - name: Users present
       ipauser:
         ipaadmin_password: "{{ ipaadmin_password }}"
         users: "{{ users }}"

3. users.json ファイルを作成し、IdM ユーザーを追加します。この手順を簡素化するには、/usr/share/doc/ansible-freeipa/playbooks/user/users.json ファイルのサンプルをコピーして変更できます。たとえば、ユーザー idm_user_1、idm_user_2、idm_user_3 を作成し、idm_user_1 のパスワードを Password123 として追加します。

   {
     "users": [
      {
       "name": "idm_user_1",
       "first": "Alice",
       "last": "Acme",
       "password": "Password123"
      },
      {
       "name": "idm_user_2",
       "first": "Bob",
       "last": "Acme"
      },
      {
       "name": "idm_user_3",
       "first": "Eve",
       "last": "Acme"
      }
     ]
   }

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

   $ ansible-playbook --vault-password-file=password_file -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-users-present-jsonfile.yml

手順

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

   [ipaserver]
   server.idm.example.com

2. IdM に存在させないユーザーを指定して Ansible Playbook ファイルを作成します。この手順は、/usr/share/doc/ansible-freeipa/playbooks/user/ensure-users-present.yml ファイルのサンプルをコピーして変更し、簡素化できます。たとえば、ユーザー idm_user_1、idm_user_2、idm_user_3 を削除するには、次のコマンドを実行します。

   ---
   - name: Playbook to handle users
     hosts: ipaserver
   
     vars_files:
     - /home/user_name/MyPlaybooks/secret.yml
     tasks:
     - name: Delete users idm_user_1, idm_user_2, idm_user_3
       ipauser:
         ipaadmin_password: "{{ ipaadmin_password }}"
         users:
         - name: idm_user_1
         - name: idm_user_2
         - name: idm_user_3
         state: absent

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

   $ ansible-playbook --vault-password-file=password_file -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/delete-users.yml

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

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

2. idm_user_1 に関する要求情報:

   $ ipa user-show idm_user_1
   ipa: ERROR: idm_user_1: user not found

   idm_user_1 という名前のユーザーは IdM に存在しません。