5.2.3. フォレスト間の信頼に関するインストール後の考慮事項
5.2.3.1. Active Directory 信頼で潜在的な動作の問題
5.2.3.1.1. Active Directory ユーザーおよび IdM の管理
現在、Active Directory (AD) ユーザーおよび管理者は、IdM Web UI にログインした後にそのセルフサービスページのみを確認できます。AD 管理者は、IdM Web UI の管理者ビューにアクセスできません。詳細は、『Linux Domain Identity、Authentication、and Policy Guide』 の Authenticating to IdM Web UI as an AD User のセクションを参照してください。
また、現在、AD ユーザーは独自の ID オーバーライドを管理できません。ID オーバーライドを追加および管理できるのは、IdM ユーザーのみです。
5.2.3.1.2. 削除された Active Directory ユーザーの認証
デフォルトでは、すべての IdM クライアントは SSSD サービスを使用して、ユーザー ID および認証情報をキャッシュします。IdM または AD バックエンドプロバイダーが一時的に利用できなくなると、SSSD により、ローカルシステムが、正常にログインしたユーザーのアイデンティティーを参照できます。
SSSD はユーザーの一覧をローカルに維持するため、バックエンドで加えられた変更は SSSD をオフラインで実行しているクライアントに即座に表示されないことがあります。このようなクライアントでは、IdM リソースにログインし、ハッシュ化されたパスワードが SSSD キャッシュに格納されているユーザーは、AD でユーザーアカウントが削除されても再度ログインできます。
上記の条件が満たされると、ユーザー ID が SSSD にキャッシュされ、ユーザーアカウントが AD から削除された場合でも、AD ユーザーは IdM リソースにログインできます。この問題は、SSSD がオンラインになり、AD ドメインコントローラーに対して AD ユーザーログオンを検証できるまで持続します。
クライアントシステムが SSSD をオンラインで実行している場合は、ユーザーが提供するパスワードが AD ドメインコントローラーにより検証されます。これにより、削除した AD ユーザーがログインできなくなります。
5.2.3.1.3. 認証情報キャッシュコレクションおよび Active Directory プリンシパルの選択
Kerberos 認証情報キャッシュは、次の識別子に基づいて、クライアントプリンシパルとサーバープリンシパルを以下の順序で照合しようとします。
- サービス名
- ホスト名
- レルム名
クライアントとサーバーのマッピングがホスト名または実際の名前および認証情報のキャッシュコレクションが使用されると、AD ユーザーとしてバインディングで予期しない動作が発生する可能性があります。これは、Active Directory ユーザーのレルム名は IdM システムのレルム名とは異なるためです。
AD ユーザーが
kinit ユーティリティーを使用してチケットを取得し、SSH を使用して IdM リソースに接続すると、リソースチケットにプリンシパルが選択されません。IdM プリンシパルはリソースのレルム名と一致するため、IdM プリンシパルが使用されます。
たとえば、AD ユーザーが
Administrator で、ドメインが ADEXAMPLE.ADREALM の場合、プリンシパルは Administrator@ADEXAMPLE.ADREALM になります。
[root@server ~]# kinit Administrator@ADEXAMPLE.ADREALM Password for Administrator@ADEXAMPLE.ADREALM: [root@server ~]# klist Ticket cache: KEYRING:persistent:0:0 Default principal: Administrator@ADEXAMPLE.ADREALM Valid starting Expires Service principal 27.11.2015 11:25:23 27.11.2015 21:25:23 krbtgt/ADEXAMPLE.ADREALM@ADEXAMPLE.ADREALM renew until 28.11.2015 11:25:16
これは、Active Directory チケットキャッシュのデフォルトプリンシパルとして設定されます。ただし、IdM ユーザーに Kerberos チケット (
admin など) がある場合は、IdM のデフォルトプリンシパルに別の IdM 認証情報キャッシュがあります。Active Directory ユーザーが SSH を使用してリソースに接続する場合は、その IdM デフォルトプリンシパルがホストチケットに対して選択されます。
[root@vm-197 ~]# ssh -l Administrator@adexample.adrealm ipaclient.example.com Administrator@adexample.adrealm@ipaclient.example.com's password: [root@vm-197 ~]# klist -A Ticket cache: KEYRING:persistent:0:0 Default principal: Administrator@ADEXAMPLE.ADREALM Valid starting Expires Service principal 27.11.2015 11:25:23 27.11.2015 21:25:23 krbtgt/ADEXAMPLE.ADREALM@ADEXAMPLE.ADREALM renew until 28.11.2015 11:25:16 Ticket cache: KEYRING:persistent:0:0Default principal: admin@EXAMPLE.COM>>>>> IdM user Valid starting Expires Service principal 27.11.2015 11:25:18 28.11.2015 11:25:16 krbtgt/EXAMPLE.COM@EXAMPLE.COM27.11.2015 11:25:48 28.11.2015 11:25:16 host/ipaclient.example.com@EXAMPLE.COM>>>>> host principal
これは、IdM プリンシパルのレルム名が IdM リソースのレルムと一致するためです。
5.2.3.1.4. グループ SID の解決
Kerberos チケットの損失
コマンドを実行して、Samba サービス (net getlocalsid、net getdomainsid など) から SID を取得し、既存の admin チケットを Kerberos キャッシュから削除します。
注記
Active Directory 信頼を使用するには、net getlocalsid、net getdomainsid などのコマンドを実行する必要はありません。
ユーザーのグループメンバーシップを確認できない
特定の信頼されるユーザーが特定の IdM グループ、外部、または POSIX に関連付けられていることを確認できません。
Active Directory ユーザー用に、リモート Active Directory グループメンバーを表示できません。
重要
IdM サーバーおよびクライアントが Red Hat Enterprise Linux 7.1 以降で実行している場合は、この問題が発生しなくなりました。
id ユーティリティーを使用すると、Linux システムユーザーのローカルグループの関連付けを表示できます。ただし、Samba ツールが表示されていても、id は Active Directory ユーザーの Active Directory グループのメンバーシップは表示されません。
これを回避するには、
ssh ユーティリティーを使用して、指定の AD ユーザーとして IdM クライアントマシンにログインできます。AD ユーザーが初めてログインすると、id 検索は AD グループメンバーシップを検出し、表示します。
[root@ipaserver ~]# id ADDOMAIN\user uid=1921801107(user@ad.example.com) gid=1921801107(user@ad.example.com) groups=1921801107(user@ad.example.com),129600004(ad_users),1921800513(domain users@ad.example.com)
