追記だめだめ日記ツッコミの内容は検索サイトからの検索やサイトのレーティングに影響します。そのため問題があるキーワードを含むと思われるツッコミについては、当方の判断で削除することがあります。コメントspamと判断されたツッコミは自動的に消去されます。だめだめ日記のおみせ@本店でどうぞ。Storage機能がGAされたとあったので、とりあえず試してみました。Windowsからももちろんつなげたんですが、一応smbclientからつないでみました。availableドメイン名は上記のとおり「X」で、OS名、サーバ名は空欄でした。ここは伏せ字にしたわけではありません。ドライブのみで実行できます。Storage機能とどう絡むのかがよくわからない......なんか面倒そう。APIでのみサポートとあります。いうことで、現状SMB接続では実質アクセス制御はできない、と。4.3.0ではWindowsでは直接参照できないDNSに関するFSMOを操作できるとあったので、試してみました。Settings,CN=WIN2K3R2ENT-1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=addom1,DC=ad,DC=localDomainDnsZonesMasterRoleとForestDnsZonesMasterRoleというFSMOが確認できます。Services(略称AADDS)のプレビュー版が使えるようになったということなので、とりあえず触ってみました。サービス」が表示されているので、「はい」を選択して構成してみます。Administratorsグループ(必ずこの名前である必要がある)の作成とメンバの追加、メンバのパスワードリセットを行ったうえで、Windowsクライアントを参加させ、RSATで眺めてみました。ちなみにDCのコンピュータ名は初期設定のままのランダムな名称となっています。ComputersというOUに格納されます。Administratorsグループに所属するユーザは、ADの管理権があることになっていますが、ADのもつ権限の委任(Delegation)機能により、一部の機能が委任されているだけなので、実際はかなり制限がありました。サイトとサービスからの操作たとえば、ADUCでドメインのアイコンを右クリックしても、通常なら出てくるはずの「新規作成(New)」メニューが表示されません。Policyは編集できないので、使えるのはAADDCからはじまる名前の2つだけです。そんなこんなで機能制限が多いAADDSではありますが、それでもコンピュータの参加とGPOの適用という基本的な機能が実現できるのは大きいと思います。[Samba][Windows]AADDSにSambaサーバを参加プレビュー版がリリースされたAADDSに、とりあえずSambaを参加させてみました。'AZUREx.monyo.com'あっけなく参加できました。こんな感じで、ユーザ一覧も取得できます。R2で構築されてますねということで。4.3系列からはドメイン間およびフォレスト間の外部信頼関係がサポートされています。4.3.1で検証してみました。信頼関係を締結する上では、互いのADのDNSゾーンを参照できる必要があります。手っ取り早いのは互いに相手のドメインのセカンダリになることなのですが、Samba内蔵DNSはセカンダリゾーンをサポートしていないため、BIND9_DLZで構築してみました。ADを参考に設定を行い、BIND9_DLZが正しく動作している状態にします。互いをセカンダリゾーンとする設定を行います。WindowsのDNSサーバをBIND9のセカンダリとして設定する際ですが、試した限りBIND9側はデフォルトでゾーン転送を許可しているようで、Windowsサーバ側でBIND9のセカンダリの設定を行っただけで、普通にゾーン転送が行われました。今回は念のため、ドメイン名ゾーンと_msdcs.ドメイン名ゾーンの両方のセカンダリとして構成しました。BINDをWindowsのDNSサーバのセカンダリとして構成する際は、このあたりなどを参考にして別サーバへのゾーン転送を許可します。信頼関係の設定まずはWindows側で双方向の外部信頼の設定を通常通り行います。Samba側で信頼関係の設定となります。VERIFY_STATUS_RETURNEDSuccess.--typeとしては、external(外部信頼)かforest(フォレスト間信頼)を指定します。--directionについては、現状双方向しかサポートしていないとありましたので、bothを指定しました。--create-locationでは、bothを指定するとWindowsサーバ側の信頼関係の設定も行えるようでしたが、今回はWindows側で事前に設定済ですので、localを指定しました。R2で検証したため、--no-aes-keysを設定しています。動作確認(Windows)まずはWindows側で確認してみました。最初に「ドメインと信頼関係」で「信頼関係の検証を行い、入出力双方とも検証に成功することを確認しました。次のように、オブジェクトピッカーで、Sambaで構築したドメインのユーザ(たとえばdns-jessie64-1とか)が参照できることを確認しました。実際に、ファイルのアクセス許可に設定することもできました。ログオン画面でも信頼するドメイン名(ADDOM2)が表示されています。Sambaで構築したドメインのユーザとして、認証に成功していることを確認。ちなみに認証に失敗すると、以下のエラーではなく、「ログオンできません」というエラーになります。動作確認(Samba)つぎはSamba側での動作確認です。7マシンから、Windowsで構築したADドメインのユーザでログオンしてみました。字が小さくて見づらいですが、「システム」ではaddom2.ad.localドメイン(Sambaで構築)に所属しているにも関わらず、左上にあるアクセス許可の設定画面では、aduser01@addom1.ad.localというユーザにアクセス許可が設定されていることが確認できます。オブジェクトピッカーで、Windowsで構築したADドメインのユーザなどが参照できるか確認したのですが、参照はできず、アクセス許可の設定もできませんでした。deleted.Samba側からWindows側も含めた信頼関係を作成あらためて、--direction=bothとして、Samba側からWindows側の信頼関係の設定も含めて作成してみました。(RC4_HMAC_MD5)こちらも問題なく機能しましたが、やはりSambaで構築したADドメインに所属するメンバについては、信頼するドメインのユーザでログオンはできるものの、アクセス許可を付与できず......。追記(10/25)リリースノートをよく見ると信頼するドメインのユーザやグループをドメイングループに追加することができないとあるので、今のところ、アクセス許可の付与ができないのは仕様っぽい気がしました。R2で構築した、機能レベルも2012R2(ドメイン、フォレストとも)のADドメインと信頼関係が締結できるかを試してみました。以下の実行例では若干怪しいメッセージも出ていますが、信頼関係自体は締結できました。ちなみにADDOM3がSambaで構築したドメイン、ADDOM4がWindowsで構築したドメインです。2.3.8-p459。