こんにちは、富士榮です。
先日パブリック・プレビューが公開されたAzure Active Directory Domain Services（Azure AD DS/AADDS）を使うことでオンプレミスのActive Directoryが提供してきたドメイン・サービス（ドメイン参加やグループポリシーなど）を、同一Azure VNET上のマシンに対して提供することが可能になりました。
公式blogでのアナウンス
Azure AD Domain Services is now in Public Preview ? Use Azure AD as a cloud domain controller!
http://blogs.technet.com/b/ad/archive/2015/10/14/azure-ad-domain-services-is-now-in-public-preview-use-azure-ad-as-a-cloud-based-domain-controller.aspx
尚、基本的なセットアップ方法や簡単な注意点についてはMicrosoft Regional Directorの亀渕さんが紹介しているので、そちらを参考にしてください。
ブチザッキ
Azure Active Directory Domain Services (Public Preview)
https://buchizo.wordpress.com/2015/10/15/azure-active-directory-domain-services-public-preview/
公式ドキュメントや亀渕さんのblogにも書かれているとおり、AADDSで提供されているドメインサービスには一部制限があります。
・サイトの構成やマルチフォレスト・マルチドメインなどのドメイン構成自体のカスタマイズはできない
・グループポリシーはビルトインのもののみで、カスタマイズができない
・直接ユーザやグループをMMCで管理できない
・管理者（ドメイン参加権限くらいしかない）はAAD DS Administratorsグループに入る
などなどです。
オンプレミスの既存サービスをクラウドへ持って行こうとすると、これらの制限によって少々困ることが出てくるので移行計画を立てる際は注意が必要です。
私が試していて特に困った点は「Domain Admins」権限をユーザに付与できない、という点です。
既存アプリケーションの中にはActive Directory上のオブジェクトを参照・更新するものもあり、それらのアプリケーションは多くの場合Domain Admins権限を要求します。
（アプリケーションの作りの問題ではありますが・・・）
ちなみにAzure AD DSのDomain Adminsにはdcaasadminというユーザが固定でメンバ登録されていますが、このユーザのパスワードがわからないので、なんともなりません。
もちろんこのユーザのパスワードを更新することはできないようになっていますし、Azure AD側への同期もされていません。
![]()
以下、Domain Admins権限を求める例です。
１．メンバサーバへのリモート・デスクトップ・ログイン
これは回避策がありますが、サーバをAzure仮想マシンで構築し、Azure AD DSへ参加させた後、サーバへリモート・デスクトップでAzure AD DS上のユーザでログインしようとしても拒否されてしまいます。
![]()
これはメンバサーバへのリモート・デスクトップ接続が初期状態でビルトインのAdministratorsのみに許可されているためです。Domain Adminsはドメインに参加した時点でビルトインAdministratorsグループに登録されるため、オンプレミス環境ではDomain Adminsのメンバでサーバを管理すれば特に困ることはありませんでした。
ところが、Azure AD DSでは先述の通り、Domain Adminsは使えないので、まずはローカル・アカウントでログインし、コンピュータの管理からローカルのAdministratorsにリモート・デスクトップ接続したいユーザもしくはグループを追加する必要があります。
![]()
２．Domain Admins権限を要求するアプリケーションを導入する
これは現状どうしようもありません。アプリケーションが固定でDomain Admins権限を要求してくるので、なんともなりません。
例えば、Active Directory Federation Services（AD FS）などマイクロソフトのサービスはこの時点でほぼ全滅です。（この辺りはAzure ADを使えってことなんでしょうけど）
![]()
今後正式版がリリースされるまでにうまく回避策が出てくるといいですねぇ。。
先日パブリック・プレビューが公開されたAzure Active Directory Domain Services（Azure AD DS/AADDS）を使うことでオンプレミスのActive Directoryが提供してきたドメイン・サービス（ドメイン参加やグループポリシーなど）を、同一Azure VNET上のマシンに対して提供することが可能になりました。
公式blogでのアナウンス
Azure AD Domain Services is now in Public Preview ? Use Azure AD as a cloud domain controller!
http://blogs.technet.com/b/ad/archive/2015/10/14/azure-ad-domain-services-is-now-in-public-preview-use-azure-ad-as-a-cloud-based-domain-controller.aspx
尚、基本的なセットアップ方法や簡単な注意点についてはMicrosoft Regional Directorの亀渕さんが紹介しているので、そちらを参考にしてください。
ブチザッキ
Azure Active Directory Domain Services (Public Preview)
https://buchizo.wordpress.com/2015/10/15/azure-active-directory-domain-services-public-preview/
公式ドキュメントや亀渕さんのblogにも書かれているとおり、AADDSで提供されているドメインサービスには一部制限があります。
・サイトの構成やマルチフォレスト・マルチドメインなどのドメイン構成自体のカスタマイズはできない
・グループポリシーはビルトインのもののみで、カスタマイズができない
・直接ユーザやグループをMMCで管理できない
・管理者（ドメイン参加権限くらいしかない）はAAD DS Administratorsグループに入る
などなどです。
オンプレミスの既存サービスをクラウドへ持って行こうとすると、これらの制限によって少々困ることが出てくるので移行計画を立てる際は注意が必要です。
私が試していて特に困った点は「Domain Admins」権限をユーザに付与できない、という点です。
既存アプリケーションの中にはActive Directory上のオブジェクトを参照・更新するものもあり、それらのアプリケーションは多くの場合Domain Admins権限を要求します。
（アプリケーションの作りの問題ではありますが・・・）
ちなみにAzure AD DSのDomain Adminsにはdcaasadminというユーザが固定でメンバ登録されていますが、このユーザのパスワードがわからないので、なんともなりません。
もちろんこのユーザのパスワードを更新することはできないようになっていますし、Azure AD側への同期もされていません。
以下、Domain Admins権限を求める例です。
１．メンバサーバへのリモート・デスクトップ・ログイン
これは回避策がありますが、サーバをAzure仮想マシンで構築し、Azure AD DSへ参加させた後、サーバへリモート・デスクトップでAzure AD DS上のユーザでログインしようとしても拒否されてしまいます。
これはメンバサーバへのリモート・デスクトップ接続が初期状態でビルトインのAdministratorsのみに許可されているためです。Domain Adminsはドメインに参加した時点でビルトインAdministratorsグループに登録されるため、オンプレミス環境ではDomain Adminsのメンバでサーバを管理すれば特に困ることはありませんでした。
ところが、Azure AD DSでは先述の通り、Domain Adminsは使えないので、まずはローカル・アカウントでログインし、コンピュータの管理からローカルのAdministratorsにリモート・デスクトップ接続したいユーザもしくはグループを追加する必要があります。
２．Domain Admins権限を要求するアプリケーションを導入する
これは現状どうしようもありません。アプリケーションが固定でDomain Admins権限を要求してくるので、なんともなりません。
例えば、Active Directory Federation Services（AD FS）などマイクロソフトのサービスはこの時点でほぼ全滅です。（この辺りはAzure ADを使えってことなんでしょうけど）
今後正式版がリリースされるまでにうまく回避策が出てくるといいですねぇ。。