Show Table of Contents
このページには機械翻訳が使用されている場合があります (詳細はこちら)。
5.2. フォレスト間の信頼作成
5.2.1. 環境およびマシン要件
信頼関係を設定する前に、Active Directory と Identity Management の両方のサーバー、マシン、および環境が本セクション記載の要件および設定を満たしていることを確認してください。
5.2.1.1. サポートされる Windows プラットフォーム
以下のフォレストやドメイン機能レベルを使用する Active Directory フォレストで、信頼関係を確立することができます。
- Windows Server 2016Windows Server 2012 R2
- ドメイン機能レベルの範囲 - Windows Server 2008 - Windows Server 2016
以下のオペレーティングシステムは、上記の機能レベルを用いた信頼確立においサポートされ、テストされています。
- Windows Server 2012 R2
- Windows Server 2016
以前のバージョンの Windows Server では、信頼確立のサポートはありません。
5.2.1.2. DNS およびレルム設定
信頼関係を確立するには、Active Directory と Identity Management で以下の特定の DNS 設定が必要になります。
- 一意のプライマリー DNS ドメイン
- 各システムは、一意のプライマリー DNS ドメインを設定する必要があります。例えば、
- AD の場合は
ad.example.com
、IdM の場合はidm.example.com
- AD の場合は
example.com
、IdM の場合はidm.example.com
- AD の場合は
ad.example.com
、IdM の場合はexample.com
重要
IdM ドメインが AD ドメインの親ドメインである場合、IdM サーバーは Red Hat Enterprise Linux 7.5 以降で実行する必要があります。
最も便利な管理ソリューションは、各 DNS ドメインが統合 DNS サーバーで管理されている環境ですが、標準準拠の DNS サーバーであればいずれのものでも使用できます。AD または IdM では、アイデンティティー管理目的でプライマリー DNS ドメインを別のシステムと共有することはできません。詳細については、 Linux ドメイン ID、認証、およびポリシーガイド のホスト名および DNS 設定要件のセクションを参照してください。 - Kerberos レルム名は、プライマリー DNS ドメイン名を大文字にしたもの
- Kerberos レルム名はプライマリー DNS ドメイン名と同一のものにし、すべて大文字にする必要があります。例えば、AD のドメイン名が
ad.example.com
、IdM のドメイン名がidm.example.com
である場合、Kerberos レルム名はAD.EXAMPLE.COM
およびIDM.EXAMPLE.COM
とします。 - DNS レコードが信頼内の全 DNS ドメインから解決可能であること
- 信頼関係内で関連するすべての DNS ドメインからの DNS レコードをすべてのマシンが解決可能である必要があります。
- IdM DNS を設定する際には、Linux ドメイン ID、認証、およびポリシーガイド の IdM ドメイン内での DNS サービスの設定 および 『DNS 転送の管理』 セクションに記載の指示に従います。
- 統合 DNS なしで IdM を使用している場合は、Linux ドメイン ID、認証、およびポリシーガイド の 『統合 DNS なしでサーバーをインストールする』 セクションにある指示に従ってください。
- IdM と AD DNS ドメイン間で重複しないこと
- IdM に参加したマシンは複数の DNS ドメインに分配することができます。IdM クライアントを含んでいる DNS ドメインは、AD に参加しているマシンを含んでいる DNS ドメインと重複することはできません。AD 信頼をサポートするには、プライマリー IdM DNS ドメインに適切な SRV レコードがある必要があります。
$ ipa dns-update-system-records --dry-run
コマンドを実行して、お使いのシステム設定に固有の必須 SRV レコード一覧を取得できます。生成されたリストは、以下のような形式になっています。$ ipa dns-update-system-records --dry-run IPA DNS records: _kerberos-master._tcp.example.com. 86400 IN SRV 0 100 88 server.example.com. _kerberos-master._udp.example.com. 86400 IN SRV 0 100 88 server.example.com. _kerberos._tcp.example.com. 86400 IN SRV 0 100 88 server.example.com. _kerberos._udp.example.com. 86400 IN SRV 0 100 88 server.example.com. _kerberos.example.com. 86400 IN TXT "EXAMPLE.COM" _kpasswd._tcp.example.com. 86400 IN SRV 0 100 464 server.example.com. _kpasswd._udp.example.com. 86400 IN SRV 0 100 464 server.example.com. _ldap._tcp.example.com. 86400 IN SRV 0 100 389 server.example.com. _ntp._udp.example.com. 86400 IN SRV 0 100 123 server.example.com.
同じ IdM レルムの一部である他の DNS ドメインでは、AD への信頼設定時に SRV レコードを設定する必要がありません。これは、AD ドメインコントローラーが KDC の検索に SRV レコードを使用せず、KDC の検索には信頼の名前サフィックスルーティング情報を使用するためです。
DNS 設定の確認
信頼を設定する前に、Identity Management と Active Directory サーバーが自身を解決し、また相互に解決できることを確認します。
以下のコマンドを実行しても期待される結果が表示されない場合は、コマンドが実行されたホストの DNS 設定を調べます。このホスト設定が正しい場合は、親から子ドメインへの DNS 委任が正しく設定されていることを確認します。
AD は DNS 検索の結果をキャッシュするので、DNS 内の変更は直ちには見えない場合があることに注意してください。
ipconfig /flushdns
コマンドを実行するとキャッシュが削除できます。
- IdM でホストされているサービスが信頼確立に使用される IdM ドメインサーバーから解決可能であることを確認する
- TCP サービスレコードに対する LDAP と UDP による Kerberos の DNS クエリを実行します。
[root@ipaserver ~]# dig +short -t SRV _kerberos._udp.ipa.example.com. 0 100 88 ipamaster1.ipa.example.com. [root@ipaserver ~]# dig +short -t SRV _ldap._tcp.ipa.example.com. 0 100 389 ipamaster1.ipa.example.com.
このコマンドでは、全 IdM サーバーが一覧表示されるはずです。 - IdM Kerberos レルム名で TXT レコードの DNS クエリーを実行します。取得される値は、IdM インストール時に指定した Kerberos レルムと一致することが期待されます。
[root@ipaserver ~]# dig +short -t TXT _kerberos.ipa.example.com. IPA.EXAMPLE.COM
ipa-adtrust-install
にあるように 「信頼向けに IdM サーバーを準備する」 ユーティリティーを実行した後、TCP サービスレコードに対する LDAP と UDP による MS DC Kerberos の DNS クエリを実行します。[root@ipaserver ~]# dig +short -t SRV _kerberos._udp.dc._msdcs.ipa.example.com. 0 100 88 ipamaster1.ipa.example.com. [root@ipaserver ~]# dig +short -t SRV _ldap._tcp.dc._msdcs.ipa.example.com. 0 100 389 ipamaster1.ipa.example.com.
このコマンドでは、ipa-adtrust-install
を実行した全 IdM サーバーが一覧表示されるはずです。ipa-adtrust-install
を IdM サーバーで実行していない場合は、出力は空白になることに留意してください。最初の信頼関係を確立していない場合は、これはよくあることです。
- IdM が AD のサービスレコードを解決可能であることを確認する
- TCP サービスレコードに対する LDAP と UDP による Kerberos の DNS クエリを実行します。
[root@ipaserver ~]# dig +short -t SRV _kerberos._udp.dc._msdcs.ad.example.com. 0 100 88 addc1.ad.example.com. [root@ipaserver ~]# dig +short -t SRV _ldap._tcp.dc._msdcs.ad.example.com. 0 100 389 addc1.ad.example.com.
このコマンドでは、AD ドメインコントローラーの名前が返されるはずです。 - IdM でホストされているサービスが AD サーバーから解決可能であることを確認する
- AD サーバーでサービスレコードを検索する
nslookup.exe
ユーティリティーをセットアップします。C:\>nslookup.exe > set type=SRV
- TCP サービスレコードに対する LDAP と UDP による Kerberos のドメイン名を入力します。
> _kerberos._udp.ipa.example.com. _kerberos._udp.ipa.example.com. SRV service location: priority = 0 weight = 100 port = 88 svr hostname = ipamaster1.ipa.example.com > _ldap._tcp.ipa.example.com _ldap._tcp.ipa.example.com SRV service location: priority = 0 weight = 100 port = 389 svr hostname = ipamaster1.ipa.example.com
予測される出力には IdM でホストされているサービスが信頼確立に使用される IdM ドメインサーバーから解決可能であることを確認する で表示される IdM サーバーと同じものが含まれます。 - サービスタイプを TXT に変更し、IdM Kerberos レルム名を使って TXT レコードの DNS クエリを実行します。
C:\>nslookup.exe > set type=TXT > _kerberos.ipa.example.com. _kerberos.ipa.example.com. text = "IPA.EXAMPLE.COM"
出力は IdM でホストされているサービスが信頼確立に使用される IdM ドメインサーバーから解決可能であることを確認する で表示される値と同じものが含まれるはずです。 ipa-adtrust-install
にあるように 「信頼向けに IdM サーバーを準備する」 ユーティリティーを実行した後、TCP サービスレコードに対する LDAP と UDP による MS DC Kerberos の DNS クエリを実行します。C:\>nslookup.exe > set type=SRV > _kerberos._udp.dc._msdcs.ipa.example.com. _kerberos._udp.dc._msdcs.ipa.example.com. SRV service location: priority = 0 weight = 100 port = 88 svr hostname = ipamaster1.ipa.example.com > _ldap._tcp.dc._msdcs.ipa.example.com. _ldap._tcp.dc._msdcs.ipa.example.com. SRV service location: priority = 0 weight = 100 port = 389 svr hostname = ipamaster1.ipa.example.com
このコマンドでは、ipa-adtrust-install
ユーティリティーを実行した全 IdM サーバーが一覧表示されるはずです。ipa-adtrust-install
を IdM サーバーで実行していない場合は、出力は空白になることに留意してください。最初の信頼関係を確立していない場合は、これはよくあることです。
- AD サービスが AD サーバーから解決可能であることを確認する
- AD サーバーでサービスレコードを検索する
nslookup.exe
ユーティリティーをセットアップします。C:\>nslookup.exe > set type=SRV
- TCP サービスレコードに対する LDAP と UDP による Kerberos のドメイン名を入力します。
> _kerberos._udp.dc._msdcs.ad.example.com. _kerberos._udp.dc._msdcs.ad.example.com. SRV service location: priority = 0 weight = 100 port = 88 svr hostname = addc1.ad.example.com > _ldap._tcp.dc._msdcs.ad.example.com. _ldap._tcp.dc._msdcs.ad.example.com. SRV service location: priority = 0 weight = 100 port = 389 svr hostname = addc1.ad.example.com
予測される出力には IdM が AD のサービスレコードを解決可能であることを確認する で表示される AD サーバーと同じものが含まれます。
5.2.1.3. NetBIOS 名
NetBIOS 名は Active Directory (AD) ドメインを識別するために重要です。IdM の場合は、IdM ドメインおよびサービスを特定するために、AD で構成された信頼があります。そのため、IdM ドメインには、フォレストの信頼を確立する AD ドメインで使用されている NetBIOS 名とは異なる NetBIOS 名を使用する必要があります。
Active Directory または IdM ドメインの NetBIOS 名は通常、対応する DNS ドメインの一番左の部分になります。たとえば、DNS ドメインが
ad.example.com
の場合、NetBIOS 名は通常 AD
になります。
注記
NetBIOS 名は最長 15 文字です。
5.2.1.4. ファイアウォールおよびポート
AD ドメインコントローラーと IdM サーバーとの通信を可能にするには、以下のポート要件を満たす必要があります。
- AD 信頼に必要なポート と AD 信頼内の IdM サーバーに必要なポート を IdM サーバーと全 AD ドメインコントローラーで開きます。これらは、IdM サーバーから AD ドメインコントローラーおよびその逆の両方向で開きます。
- AD 信頼内の IdM クライアントで必要なポート を信頼される AD フォレストの全 AD ドメインコントローラーで開きます。IdM クライアント上では、ポートが発信方向で開いていることを確認します (Linux ドメイン ID、認証、およびポリシーガイド の 『クライアントインストールの前提条件』 を参照してください)。
表5.2 AD 信頼に必要なポート
表5.3 信頼内の IdM サーバーに必要なポート
サービス | ポート | プロトコル |
---|---|---|
Kerberos | Linux ドメイン ID、認証、およびポリシーガイド の 『ポート要件』 を参照してください。 | |
LDAP | ||
DNS |
表5.4 AD 信頼内の IdM クライアントに必要なポート
サービス | ポート | プロトコル | 注記 |
---|---|---|---|
Kerberos | 88 | UDP および TCP | libkrb5 ライブラリーは UDP を使用し、Kerberos Distribution Center (KDC) から送信されたデータが大きすぎる場合は TCP プロトコルにフォールバックします。Active Directory が Privilege Attribute Certificate (PAC) を Kerberos チケットに割り当てます。これによりサイズが大きくなり、ほとんどの場合は TCP プロトコルを使用する必要があります。フォールバックと要求の再送信を回避するため、デフォルトでは、Red Hat Enterprise Linux 7.4 以降の SSSD は、ユーザー認証に TCP を使用します。libkrb5 が TCP を使用する前にサイズを構成するには、/etc/krb.5.conf ファイルで udp_preference_limit を設定します。詳細は、man ページのkrb5.conf(5)を参照してください。
|
その他のリソース
- 必要なポートを開く方法に関しては、Linux ドメイン ID、認証、およびポリシーガイド の 『ポート要件』 を参照してください。
5.2.1.5. IPv6 設定
IdM システムでは、カーネル内で IPv6 プロトコルが有効になっている必要があります。IPv6 が無効になっていると、IdM サービスが使用する CLDAP プラグインが初期化に失敗します。
5.2.1.6. 時計の設定
Active Directory サーバーと IdM サーバーの両方の時計が同期している必要があります。
5.2.1.7. AD 内の IdM ドメイン用の条件フォワーダーの作成
AD DNS サーバーを準備して、IdM ドメインのクエリーを IdM DNS サーバーに転送します。
- Windows AD ドメインコントローラーで、Active Directory (AD)
DNS
コンソールを開きます。 - New Conditional Forwarder を選択します。を右クリックし、
- IdM DNS ドメイン名および IdM DNS サーバーの IP アドレスを入力します。
- Store this conditional forwarder in Active Directory, and replicate it as follows を選択し、お使いの環境に一致するレプリケーション設定を選択します。
- AD ドメインコントローラー (DC) が IdM ドメインから DNS エントリーを解決できることを確認するには、コマンドプロンプトを開いて次のコマンドを入力します。
C:\> nslookup server.idm.example.com
コマンドにより IdM サーバーの IP アドレスが返されると、条件付きフォワーダーが適切に機能していることになります。
5.2.1.8. IdM で AD ドメインへの正引きゾーンの作成
IdM DNS サーバーを準備して、AD ドメインのクエリーを AD DNS サーバーに転送します。
- IdM サーバーで、AD DNS ドメインに正引きゾーンのエントリーを作成します。IdM に DNS 正引きゾーンを作成する方法は、『Linux ドメイン ID、認証、およびポリシーガイド』の『正引きゾーンの設定』を参照してください。
- AD DNS サーバーが DNSSEC に対応していない場合は、IdM サーバーで DNSSEC 検証を無効にします。
/etc/named.conf
ファイルを編集し、dnssec-validation
パラメーターをno
に設定します。dnssec-validation no;
named-pkcs11
サービスを再起動します。# systemctl restart named-pkcs11
- IdM サーバーが AD ドメインの DNS エントリーを解決できることを確認するには、以下を入力します。
# host server.ad.example.com
コマンドが AD DC の IP アドレスを返すと、正引きゾーンは正しく動作しています。
5.2.1.9. サポートされるユーザー名の形式
IdM はローカル SSSD クライアント内でユーザー名マッピングを実行します。SSSD がサポートする信頼されたドメインの、ユーザーのデフォルトの出力ユーザー名形式は
user_name@domain
です。Active Directory は user_name
、user_name@DOMAIN_NAME
、および DOMAIN_NAME\user_name
といった形式をサポートします。
ユーザーはユーザー名 (
user_name
) または完全修飾ユーザー名 (user_name@domain_name
) のどちらかを使用できます。たとえば、システムに認証できます。
警告
推奨は、同じユーザー名が複数のドメイン内に存在する場合は競合を回避するために、完全修飾ユーザー名を使用します。
ユーザーがドメインなしでユーザー名のみを指定すると、SSSD は
/etc/sssd/sssd.conf
ファイルおよび信頼できるドメインに設定されたすべてのドメインでアカウントを検索します。「IdM クライアントでのドメイン解決順の設定」の説明に従ってドメイン解決順序を設定すると、SSSD は定義された順序でユーザーを検索します。いずれにしても、SSSD は最初に見つかったエントリーを使用します。したがって、同じユーザー名が複数のドメインに存在し、最初に見つかったエントリーが予期したものでない場合に混乱を招く可能性があります。
デフォルトでは、SSSD は、常に完全修飾形式でユーザー名を表示します。この形式の変更に関する詳細は、「SSSD が表示するユーザー名の形式の変更」を参照してください。
ユーザー名と所属するドメインを特定するために、SSSD は
re_expression
オプションで定義される正規表現を使用します。この正規表現は IdM バックエンドおよび AD バックエンドで使用され、上記の形式すべてをサポートします。
re_expression = (((?P<domain>[^\\]+)\\(?P<name>.+$))|((?P<name>[^@]+)@(?P<domain>.+$))|(^(?P<name>[^@\\]+)$))
5.2.2. 信頼の作成
以下のセクションでは、各種の設定シナリオにおける信頼の作成について説明しています。「コマンドラインからの信頼作成」 には、コマンドラインから信頼を設定する完全な手順が含まれています。他のシナリオでは、基本的な設定シナリオとは別のステップを説明し、他のすべてのステップの基本的な手順を紹介しています。
注記
既存の信頼コントローラーでレプリカを設定する場合、レプリカは信頼コントローラーとして自動的に設定されていません。このレプリカを追加の信頼コントローラーとして設定するには、このセクションの手順に従ってください。
信頼の作成後には 「フォレスト間の信頼のインストール後の検討事項」 を参照してください。
5.2.2.1. コマンドラインからの信頼作成
IdM と Active Directory Kerberos レルム間での信頼関係の作成には以下を実行します。
- 「信頼向けに IdM サーバーを準備する」 にあるように、信頼向けに IdM サーバーを準備します。
- 「信頼合意の作成」 にあるように、信頼の合意を作成します。
- 「Kerberos 設定の確認」 にあるように、Kerberos 設定を確認します。
5.2.2.1.1. 信頼向けに IdM サーバーを準備する
AD との信頼関係向けに IdM サーバーを設定するには、以下の手順に従います。
- 必要な IdM、信頼、および Samba パッケージをインストールします。
[root@ipaserver ]# yum install ipa-server ipa-server-trust-ad samba-client
- 信頼サービスを有効にするために IdM サーバーを設定します。
ipa-replica-install --setup-adtrust
コマンドでサーバーをインストールしている場合は、この手順を省略できます。ipa-adtrust-install
ユーティリティーを実行します。[root@ipaserver ]# ipa-adtrust-install
ユーティリティーは、AD 信頼に必要な DNS サービスレコードを追加します。このレコードは、IdM が統合 DNS サーバーとともにインストールされている場合は自動的に作成されます。IdM が統合 DNS なしでインストールされた場合は、ipa-adtrust-install
はこの後の手順を進める前に手動で DNS に追加する必要のあるサービスレコード一覧を出力します。重要
Red Hat では、「DNS 設定の確認」 の説明にあるように、ipa-adtrust-install
の実行後は毎回 DNS 設定を確認することを強く推奨します。IdM もしくは AD が統合 DNS サーバーを使用しない場合は特にこれが該当します。- このスクリプトは、古い Linux クライアントが信頼されるユーザーと作業可能にする互換性プラグインである
slapi-nis
プラグインの設定を以下のように求めます。Do you want to enable support for trusted domains in Schema Compatibility plugin? This will allow clients older than SSSD 1.9 and non-Linux clients to work with trusted users. Enable trusted domains support in slapi-nis? [no]: y
- ディレクトリーの初回作成時には少なくとも 1 人のユーザー (IdM 管理者) が存在します。SID 生成タスクでは既存ユーザー向けに SID を作成し、信頼環境に対応します。これはリソース集約型タスクです。ユーザー数が多い場合は、タスクを個別に実行できます。
Do you want to run the ipa-sidgen task? [no]: yes
- 「DNS およびレルム設定」 にあるように、DNS が正常に設定されていることを確認します。
smb
サービスを起動します。[root@ipaserver ~]# systemctl start smb
- 必要に応じて、システムの起動時に
smb
サービスが自動的に起動するように設定します。[root@ipaserver ~]# systemctl enable smb
- 必要に応じて、
smbclient
ユーティリティーを使用して、Samba が IdM 側から Kerberos 認証に応答することを確認します。[root@ipaserver ~]# smbclient -L ipaserver.ipa.example.com -k lp_load_ex: changing to config backend registry Sharename Type Comment --------- ---- ------- IPC$ IPC IPC Service (Samba 4.9.1) Reconnecting with SMB1 for workgroup listing. Server Comment --------- ------- Workgroup Master --------- -------
5.2.2.1.2. 信頼合意の作成
コマンドで Active
ipa trust-add
Directory ドメインと IdM ドメインの信頼合意を作成します。
# ipa trust-add --type=type ad_domain_name --admin ad_admin_username --password
ipa trust-add
は、デフォルトで一方向の信頼を設定します。双方向の信頼を確立するには、--two-way=true
オプションを渡します。詳細は、「一方向および双方向の信頼」 を参照してください。
外部の信頼を確立するには、
--external=true
オプションを ipa trust-add
コマンドに渡します。詳細は、「Active Directory への外部の信頼」 を参照してください。
注記
ipa trust-add
コマンドはデフォルトで、サーバーを信頼コントローラーとして設定します。詳細は、「信頼コントローラーおよび信頼エージェント」 を参照してください。
以下の例では、
--two-way=true
オプションを使用して双方向の信頼を確認します。
[root@ipaserver ~]# ipa trust-add --type=ad ad.example.com --admin Administrator --password --two-way=true Active Directory domain administrator's password: ------------------------------------------------------- Added Active Directory trust for realm "ad.example.com" ------------------------------------------------------- Realm-Name: ad.example.com Domain NetBIOS name: AD Domain Security Identifier: S-1-5-21-796215754-1239681026-23416912 SID blacklist incoming: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, S-1-5-17, S-1-5-16, S-1-5-15, S-1-5-14, S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, S-1-1, S-1-0, S-1-5-19, S-1-5-18 SID blacklist outgoing: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, S-1-5-17, S-1-5-16, S-1-5-15, S-1-5-14, S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, S-1-1, S-1-0, S-1-5-19, S-1-5-18 Trust direction: Two-way trust Trust type: Active Directory domain Trust status: Established and verified
5.2.2.1.3. Kerberos 設定の確認
Kerberos 設定を確認するには、IdM ユーザーのチケットを取得できるか、また IdM ユーザーがサービスチケットをリクエストできるかをテストします。
双方向の信頼を確認するには、以下を実行します。
- IdM ユーザーのチケットをリクエストします。
[root@ipaserver ~]# kinit user
- IdM ドメイン内のサービスのサービスチケットをリクエストします。
[root@ipaserver ~]# kvno -S host ipaserver.example.com
- AD ドメイン内のサービスのサービスチケットをリクエストします。
[root@ipaserver ~]# kvno -S cifs adserver.example.com
AD サービスチケットが正常に付与されると、レルム間のチケット保証チケット (TGT) にリクエストされた他のチケットすべてが記載されます。この TGT はkrbtgt/AD.DOMAIN@IPA.DOMAIN
という名前になります。[root@ipaserver ]# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: user@IPA.DOMAIN Valid starting Expires Service principal 06/15/12 12:13:04 06/16/12 12:12:55 krbtgt/IPA.DOMAIN@IPA.DOMAIN 06/15/12 12:13:13 06/16/12 12:12:55 host/ipaserver.ipa.example.com@IPA.DOMAIN 06/15/12 12:13:23 06/16/12 12:12:55 krbtgt/AD.DOMAIN@IPA.DOMAIN 06/15/12 12:14:58 06/15/12 22:14:58 cifs/adserver.ad.example.com@AD.DOMAIN
IdM 側からの一方向の信頼を確認するには、以下を実行します。
- Active Directory ユーザーのチケットをリクエストします。
[root@ipaserver ~]# kinit user@AD.DOMAIN
- IdM ドメイン内のサービスのサービスチケットをリクエストします。
[root@ipaserver ~]# kvno -S host ipaserver.example.com
AD サービスチケットが正常に付与されると、レルム間のチケット保証チケット (TGT) にリクエストされた他のチケットすべてが記載されます。この TGT はkrbtgt/IPA.DOMAIN@AD.DOMAIN
という名前になります。[root@ipaserver ]# klist Ticket cache: KEYRING:persistent:0:krb_ccache_hRtox00 Default principal: user@AD.DOMAIN Valid starting Expires Service principal 03.05.2016 18:31:06 04.05.2016 04:31:01 host/ipaserver.ipa.example.com@IPA.DOMAIN renew until 04.05.2016 18:31:00 03.05.2016 18:31:06 04.05.2016 04:31:01 krbtgt/IPA.DOMAIN@AD.DOMAIN renew until 04.05.2016 18:31:00 03.05.2016 18:31:01 04.05.2016 04:31:01 krbtgt/AD.DOMAIN@AD.DOMAIN renew until 04.05.2016 18:31:00
localauth
プラグインが Kerberos プリンシパルをローカルの SSSD ユーザー名にマッピングします。これにより AD ユーザーは Kerberos 認証を使用し、GSSAPI 認証を直接サポートする Linux サービスにアクセスできるようになります。
注記
このプラグインについての詳細は、「パスワードなしでの SSH の使用」 を参照してください。
5.2.2.3. ID マッピングの検証
ID マッピングを検証するには、以下を行います。
- Windows Active Directory ドメインコントローラー (DC) で以下のコマンドを実行し、一番大きい ID を表示します。
C:\> dcdiag /v /test:ridmanager /s:ad.example.com ... Available RID Pool for the Domain is 1600 to 1073741823 ...
- IdM サーバー上の ID 範囲の一覧を表示します。
[root@ipaserver ~]# ipa idrange-find ---------------- 1 range matched ---------------- Range name: AD.EXAMPLE.COM_id_range First Posix ID of the range: 610600000 Number of IDs in the range: 200000 First RID of the corresponding RID range: 0 Domain SID of the trusted domain: S-1-5-21-796215754-1239681026-23416912 Range type: Active Directory domain range ---------------------------- Number of entries returned 1 ----------------------------
後のステップで最初の POSIX ID 値が必要になります。 - Active Directory DC で、セキュリティー ID (SID) またはユーザーを表示します。たとえば、
administrator
の SID を表示するには、以下を設定します。C:\> wmic useraccount where name="administrator" get sid S-1-5-21-796215754-1239681026-23416912-500
SID の最後の部分は、相対識別子 (RID) です。次の手順では、ユーザーの RID が必要になります。注記
RID がデフォルトの ID 範囲 (200000) よりも高い場合は、ipa idrange-mod
コマンドを使用して範囲を拡張します。以下に例を示します。# ipa idrange-mod --range-size=1000000 AD.EXAMPLE.COM_id_range
- IdM サーバー上の同一ユーザーのユーザー ID を表示します。
[root@ipaserver ~]# id ad\\administrator uid=610600500(administrator@ad.example.com)...
- 最初の POSIX ID 値 (610600000) を RID (500) に追加する場合は、IdM サーバー (610600500) に表示されるユーザー ID と一致する必要があります。
5.2.2.4. 既存の IdM インスタンス上での信頼の作成
既存の IdM インスタンスで信頼を設定する場合は、IdM サーバーとそのドメイン内のエントリーについての特定のセッティングは設定済みになっています。ただし、Active Directory ドメインの DNS 設定では、Active Directory SID をすべての既存の IdM ユーザーおよびグループに割り当てる設定にする必要があります。
- 「信頼向けに IdM サーバーを準備する」 にあるように、信頼向けに IdM サーバーを準備します。
- 「信頼合意の作成」 にあるように、信頼の合意を作成します。
- 各 IdM ユーザーに SID を生成します。
注記
ipa-adtrust-install
ユーティリティーを使用した信頼の確立時に SID が生成されている場合は、このステップを実行しないでください。- バックエンドの LDAP ディレクトリーで、
ipa-sidgen-task
操作を実行して、各エントリーごとに、SID を含む、新しいipaNTSecurityIdentifier
属性を自動的に追加します。[root@ipaserver ]# ldapmodify -x -H ldap://ipaserver.ipa.example.com:389 -D "cn=directory manager" -w password dn: cn=sidgen,cn=ipa-sidgen-task,cn=tasks,cn=config changetype: add objectClass: top objectClass: extensibleObject cn: sidgen nsslapd-basedn: dc=ipadomain,dc=com delay: 0 adding new entry "cn=sidgen,cn=ipa-sidgen-task,cn=tasks,cn=config"
- このタスクが正常に完了すると、SID 生成タスク (
Sidgen task
) がステータスゼロ (0) で終了したというメッセージがエラーログに記録されます。[root@ipaserver ]# grep "sidgen_task_thread" /var/log/dirsrv/slapd-IDM-EXAMPLE-COM/errors [20/Jul/2012:18:17:16 +051800] sidgen_task_thread - [file ipa_sidgen_task.c, line 191]: Sidgen task starts ... [20/Jul/2012:18:17:16 +051800] sidgen_task_thread - [file ipa_sidgen_task.c, line 196]: Sidgen task finished [0].
- 「Kerberos 設定の確認」 にあるように、Kerberos 設定を確認します。
5.2.2.5. 2 つ目の信頼の追加
1 つ以上の信頼合意が設定されている IdM サーバーに新たな信頼を追加する際は、信頼関連のパッケージのインストールや SID の設定といった一般的な IdM 信頼設定の一部が不要になります。新たな信頼を追加するには、DNS を設定し、信頼合意を確立することのみが必要になります。
- 「DNS およびレルム設定」 にあるように、DNS が正常に設定されていることを確認します。
- 「信頼合意の作成」 にあるように、信頼の合意を作成します。
5.2.2.6. Web UI 内での信頼の作成
Web UI 内で信頼を作成する前に、信頼用の IdM サーバーを用意します。この信頼設定はコマンドラインから実行すると最も容易で、「信頼向けに IdM サーバーを準備する」 で説明されています。
初期設定が完了したら、信頼合意を IdM web UI で追加します。
- IdM web UI を開きます。
https://ipaserver.example.com
- IPA Server メインタブを開いてから、Trusts サブタブを選択します。
- Trusts サブタブで Add をクリックし、新規信頼設定ウィンドウを開きます。
- 信頼についての必須情報を入力します。
- Domain フィールドに AD ドメイン名を記入します。
- 信頼を双方向にするには、Two-way trust チェックボックスを選択します。信頼を一方向にするには、Two-way trust を選択しないでください。一方向および双方向の信頼に関する詳細情報は、「一方向および双方向の信頼」 を参照してください。
- 別のフォレストにあるドメインへの外部の信頼を確立するには、External Trust チェックボックスを選択します。詳細は、「Active Directory への外部の信頼」 を参照してください。
- Establish using セクションでは、信頼の確立方法を定義します。
- AD 管理者のユーザー名とパスワードを使って信頼を確立する場合は、Administrative account を選択して必要な認証情報を入力します。
- 共有パスワードを使って信頼を確立する場合は、Pre-shared password を選択して信頼パスワードを入力します。
- 信頼の ID 設定を定義します。
- Range type オプションでは、ID 範囲のタイプを選択できます。IdM が自動的に使用する ID 範囲のタイプを検出するようにするには、Detect を選択します。
- ID 範囲の最初の ID を定義するには、Base ID フィールドを使用します。ID 範囲のサイズを定義するには、Range size フィールドを使用します。これらのオプションを指定しないと、IdM は ID 範囲のデフォルト値を使用します。
ID 範囲についての詳細は、「ID の範囲」 を参照してください。
図5.5 Web UI での信頼の追加
この後に 「Kerberos 設定の確認」 にあるように、Kerberos 設定を確認します。
5.2.3. フォレスト間の信頼のインストール後の検討事項
5.2.3.1. Active Directory 信頼における動作の潜在的問題
5.2.3.1.1. Active Directory ユーザーと IdM 管理
現在、IdM Web UI にログイン後は、Active Directory (AD) ユーザーおよび管理者には、セルフサービスページのみが表示されます。AD 管理者は、IdM Web UI の管理者ビューにアクセスできません。詳細は、『Linux ドメインアイデンティティー認証およびポリシーガイド』の対応するセクションを参照してください。
また、AD ユーザーは現時点で自身の ID 上書きを管理することはできません。ID の上書きの追加および管理が可能なのは、IdM ユーザーのみです。
5.2.3.1.2. 削除された Active Directory ユーザーの認証
デフォルトでは、すべての IdM クライアントは SSSD サービスを使用してユーザー ID および資格情報をキャッシュします。IdM または AD バックエンドプロバイダーが一時的に利用できない場合は、SSSD によりローカルシステムはこれまでに正常にログインしたことのあるユーザーの ID を参照することができます。
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 を使って an IdM リソースに接続すると、プリンシパルはこのリソースチケットに選択されません。an 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 デフォルトプリンシパルと共に別の an IdM 認証情報キャッシュも存在することになります。その IdM デフォルトプリンシパルは、Active Directory ユーザーが SSH を使用してリソースに接続する場合にホストチケットに選択されます。
[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 チケットの失効
net getlocalsid
または net getdomainsid
などの、Samba サービスから SID を取得するためのコマンドを実行すると、Kerberos キャッシュから既存の admin チケットが削除されます。
注記
Active
net getlocalsid
Directory 信頼を使用するために getdomainsid
や といったコマンドを実行する必要はありません。
ユーザーのグループメンバーシップを確認できない
特定の信頼されるユーザーが特定の IdM グループ、外部または POSIX グループに関連付けられていることを確認することはできません。
Active Directory ユーザーの (リモート) Active Directory グループメンバーシップを表示できない
重要
IdM サーバーおよびクライアントが Red Hat Enterprise Linux 7.1 またはそれ以降で実行される場合は、この問題は発生しないことに留意してください。
id
ユーティリティーを使うと、Linux システムユーザーのローカルグループの関連付けが表示できます。ただし、Samba ツールでは Activeid
Directory ユーザーの Active Directory グループメンバーシップは表示できますが、 ではこれは表示されません。
この問題を回避するには、
ssh
ユーティリティーを使って指定された AD ユーザーとして an 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)
5.2.3.2. 信頼エージェントの設定
信頼環境で新しいレプリカを設定したら、レプリカには自動的に
AD 信頼エージェント
ロールがインストールされていません。レプリカを信頼エージェントとして設定するには、以下を実行します。
- 既存の信頼コントローラーで、
ipa-adtrust-install --add-agents
コマンドを実行します。[root@existing_trust_controller]# ipa-adtrust-install --add-agents
このコマンドは、対話型の設定セッションを開始し、エージェントの設定に必要な情報の入力を求めるプロンプトを表示します。--add-agents
オプションの詳細は、man ページの ipa-adtrust-install(1) を参照してください。 - 新規レプリカで以下を行います。
- IdM サービスを再起動します。
[root@new_trust_controller]# ipactl restart
- SSSD キャッシュからすべてのエントリーを削除します。
[root@new_trust_controller]# sssctl cache-remove
注記
sssctl
コマンドを使用するには、sssd-tools パッケージがインストールされている必要があります。 - 必要に応じて、レプリカに
AD 信頼エージェント
ロールがインストールされていることを確認します。[root@new_trust_controller]# ipa server-show new_replica.idm.example.com ... Enabled server roles: CA server, NTP server, AD trust agent
このページには機械翻訳が使用されている場合があります (詳細はこちら)。