ツッコミの内容は検索サイトからの検索やサイトのレーティングに影響します。そのため問題があるキーワードを含むと思われるツッコミについては、当方の判断で削除することがあります。予めご了承ください。 なお、コメントspamと判断されたツッコミは自動的に消去されます。ご容赦ください。
【改訂新版】Samba [実践]入門 |
Linux教科書 LPICレベル3 300試験 |
マスタリング Nginx |
実践 パケット解析 第2版 |
改訂版 Sambaのすべて |
アンドキュメンテッド Microsoftネットワーク |
その他の書籍は だめだめ日記のおみせ@本店でどうぞ。
Samba 4.3.0 リリースノートの翻訳にも言及がありますが、Samba4のSamba 4.3系列からはドメイン間およびフォレスト間の外部信頼関係がサポートされています。
せっかくですので、Samba 4.3.1で検証してみました。
信頼関係を締結する上では、互いのADのDNSゾーンを参照できる必要があります。一番手っ取り早いのは互いに相手のドメインのセカンダリになることなのですが、Samba内蔵DNSはセカンダリゾーンをサポートしていないため、BIND9_DLZで構築してみました。
まずは、Sambaサーバ上でBIND9をConfigure BIND as backend for Samba ADを参考に設定を行い、BIND9_DLZが正しく動作している状態にします。
ついで、互いをセカンダリゾーンとする設定を行います。
WindowsのDNSサーバをBIND9のセカンダリとして設定する際ですが、試した限りBIND9側はデフォルトでゾーン転送を許可しているようで、Windowsサーバ側でBIND9のセカンダリの設定を行っただけで、普通にゾーン転送が行われました。今回は念のため、ドメイン名ゾーンと_msdcs.ドメイン名ゾーンの両方のセカンダリとして構成しました。
BINDをWindowsのDNSサーバのセカンダリとして構成する際は、このあたりなどを参考にして別サーバへのゾーン転送を許可します。
まずはWindows側で双方向の外部信頼の設定を通常通り行います。
ついで、いよいよSamba側で信頼関係の設定となります。
root@jessie64-1:/usr/local/samba/etc# samba-tool domain trust create ADDOM1.AD.LOCAL --type=external --direction=both --create-location=local --no-aes-keys -U Administrator -W ADDOM1 New Incoming Trust Password: ←入力方向の信頼関係のパスワードを入力 Retype Incoming Trust Password: ←入力方向の信頼関係のパスワードを入力 New Outgoing Trust Password: ←出力方向の信頼関係のパスワードを入力 Retype Outgoing Trust Password: ←出力方向の信頼関係のパスワードを入力 LocalDomain Netbios[ADDOM2] DNS[addom2.ad.local] SID[S-1-5-21-938814754-xxxxxxxxx-xxxxxxxxxx] RemoteDC Netbios[WIN2K3R2ENT-1] DNS[win2k3r2ent-1.ADDOM1.AD.LOCAL] ServerType[PDC,GC,LDAP,DS,KDC,TIMESERV,CLOSEST,WRITABLE,GOOD_TIMESERV] Password for [ADDOM1\Administrator]: RemoteDomain Netbios[ADDOM1] DNS[ADDOM1.AD.LOCAL] SID[S-1-5-21-2707235770-xxxxxxxxx-xxxxxxxx] Creating local TDO. Local TDO created Validating outgoing trust... OK: LocalValidation: DC[\\win2k3r2ent-1.ADDOM1.AD.LOCAL] CONNECTION[WERR_OK] TRUST[WERR_OK] VERIFY_STATUS_RETURNED Success.
--typeとしては、external(外部信頼)かforest(フォレスト間信頼)を指定します。
--directionについては、現状双方向しかサポートしていないとありましたので、bothを指定しました。
--create-locationでは、bothを指定するとWindowsサーバ側の信頼関係の設定も行えるようでしたが、今回はWindows側で事前に設定済ですので、localを指定しました。
最後に、今回は脱Windows Server 2003ということで、Windows Server 2003 R2で検証したため、--no-aes-keysを設定しています。
まずはWindows側で確認してみました。最初に「ドメインと信頼関係」で「信頼関係の検証を行い、入出力双方とも検証に成功することを確認しました。
ついで、次のように、オブジェクトピッカーで、Sambaで構築したドメインのユーザ(たとえばdns-jessie64-1とか)が参照できることを確認しました。
実際に、ファイルのアクセス許可に設定することもできました。
ログオン画面でも信頼するドメイン名(ADDOM2)が表示されています。
Sambaで構築したドメインのユーザとして、認証に成功していることを確認。
ちなみに認証に失敗すると、以下のエラーではなく、「ログオンできません」というエラーになります。
つぎはSamba側での動作確認です。まずはsamba-toolで確認して、
root@jessie64-1:/usr/local/samba/etc# samba-tool domain trust validate addom1.ad.local -U ADDOM1\\Administrator LocalDomain Netbios[ADDOM2] DNS[addom2.ad.local] SID[S-1-5-21-938814754-xxxxxxxxx-xxxxxxxxxx] LocalTDO Netbios[ADDOM1] DNS[ADDOM1.AD.LOCAL] SID[S-1-5-21-2707235770-xxxxxxxxx-xxxxxxxx] OK: LocalValidation: DC[\\win2k3r2ent-1.ADDOM1.AD.LOCAL] CONNECTION[WERR_OK] TRUST[WERR_OK] VERIFY_STATUS_RETURNED OK: LocalRediscover: DC[\\win2k3r2ent-1.ADDOM1.AD.LOCAL] CONNECTION[WERR_OK] RemoteDC Netbios[WIN2K3R2ENT-1] DNS[win2k3r2ent-1.ADDOM1.AD.LOCAL] ServerType[PDC,GC,LDAP,DS,KDC,TIMESERV,CLOSEST,WRITABLE,GOOD_TIMESERV] Password for [ADDOM1\Administrator]: OK: RemoteValidation: DC[\\jessie64-1.addom2.ad.local] CONNECTION[WERR_OK] TRUST[WERR_OK] VERIFY_STATUS_RETURNED OK: RemoteRediscover: DC[\\jessie64-1.addom2.ad.local] CONNECTION[WERR_OK] root@jessie64-1:/usr/local/samba/etc# samba-tool domain trust show addom1.ad.local LocalDomain Netbios[ADDOM2] DNS[addom2.ad.local] SID[S-1-5-21-938814754-xxxxxxxxxx-xxxxxxxxxx] TrusteDomain: NetbiosName: ADDOM1 DnsName: ADDOM1.AD.LOCAL SID: S-1-5-21-2707235770-xxxxxxxxx-xxxxxxxx Type: 0x2 (UPLEVEL) Direction: 0x3 (BOTH) Attributes: 0x4 (QUARANTINED_DOMAIN) PosixOffset: 0x00000000 (0) kerb_EncTypes: 0x4 (RC4_HMAC_MD5)
ついで、Sambaで構築したADドメインに参加しているWindows 7マシンから、Windowsで構築したADドメインのユーザでログオンしてみました。
字が小さくて見づらいですが、「システム」ではaddom2.ad.localドメイン(Sambaで構築)に所属しているにも関わらず、左上にあるアクセス許可の設定画面では、aduser01@addom1.ad.localというユーザにアクセス許可が設定されていることが確認できます。
ただし、オブジェクトピッカーで、Windowsで構築したADドメインのユーザなどが参照できるか確認したのですが、参照はできず、アクセス許可の設定もできませんでした。
こんな感じ
root@jessie64-1:/usr/local/samba/etc# samba-tool domain trust delete addom1.ad.local -UADDOM1\\Administrator LocalDomain Netbios[ADDOM2] DNS[addom2.ad.local] SID[S-1-5-21-938814754-xxxxxxxxx-xxxxxxxxxxx] RemoteDC Netbios[WIN2K3R2ENT-1] DNS[win2k3r2ent-1.ADDOM1.AD.LOCAL] ServerType[PDC,GC,LDAP,DS,KDC,TIMESERV,CLOSEST,WRITABLE,GOOD_TIMESERV] Password for [ADDOM1\Administrator]: RemoteDomain Netbios[ADDOM1] DNS[ADDOM1.AD.LOCAL] SID[S-1-5-21-2707235770-xxxxxxxxx-xxxxxxxx] RemoteTDO deleted.
あらためて、--direction=bothとして、Samba側からWindows側の信頼関係の設定も含めて作成してみました。
また、よくみるとSIDフィルタは未サポートでしたので、--quarantined=no を指定してみました。
root@jessie64-1:/usr/local/samba/etc# samba-tool domain trust create ADDOM1.AD.LOCAL --type=external --direction=both --create-location=both --no-aes-keys --quarantined=no -U ADDOM1\\Administrator LocalDomain Netbios[ADDOM2] DNS[addom2.ad.local] SID[S-1-5-21-938814754-xxxxxxxxx-xxxxxxxxxx] RemoteDC Netbios[WIN2K3R2ENT-1] DNS[win2k3r2ent-1.ADDOM1.AD.LOCAL] ServerType[PDC,GC,LDAP,DS,KDC,TIMESERV,CLOSEST,WRITABLE,GOOD_TIMESERV] Password for [ADDOM1\Administrator]: RemoteDomain Netbios[ADDOM1] DNS[ADDOM1.AD.LOCAL] SID[S-1-5-21-2707235770-xxxxxxxxx-xxxxxxxx] Creating remote TDO. Remote TDO created. Creating local TDO. Local TDO created Validating outgoing trust... OK: LocalValidation: DC[\\win2k3r2ent-1.ADDOM1.AD.LOCAL] CONNECTION[WERR_OK] TRUST[WERR_OK] VERIFY_STATUS_RETURNED Validating incoming trust... OK: RemoteValidation: DC[\\jessie64-1.addom2.ad.local] CONNECTION[WERR_OK] TRUST[WERR_OK] VERIFY_STATUS_RETURNED Success.
root@jessie64-1:/usr/local/samba/etc# samba-tool domain trust show addom1.ad.local LocalDomain Netbios[ADDOM2] DNS[addom2.ad.local] SID[S-1-5-21-938814754-xxxxxxxxx-xxxxxxxxxx] TrusteDomain: NetbiosName: ADDOM1 DnsName: ADDOM1.AD.LOCAL SID: S-1-5-21-2707235770-xxxxxxxxx-xxxxxxxx Type: 0x2 (UPLEVEL) Direction: 0x3 (BOTH) Attributes: 0x0 () PosixOffset: 0x00000000 (0) kerb_EncTypes: 0x4 (RC4_HMAC_MD5)
こちらも問題なく機能しましたが、やはりSambaで構築したADドメインに所属するメンバについては、信頼するドメインのユーザでログオンはできるものの、アクセス許可を付与できず……。
リリースノートをよく見ると
とあるので、今のところ、アクセス許可の付与ができないのは仕様っぽい気がしました。