Azure AD Domain Services Azure Resource Manager 利用の状況

先日の de:code 2017 でご紹介した 「Azure Active Directory Domain Services)」。PaaS としてAzureにドメインコントローラーを実装しKerberos認証が利用できるサービスです。

 

 

Azure AD  Domain Services (以下、AADDS) が、Azure Resource Manager(Azure New ポータル)(以下、ARM)でプレビューとなりました。以下のようにARM画面で表示されます。

 

 

 

 

 

 

これまではクラシックポータルのみで作成可能。作成したAADDSにドメイン参加するマシンもクラシックポータルで作成されたものに限られていました。よって、ARMで作成されたマシンをAADDSのドメインへ参加させるにはvNet ピアリングを利用するなどの工夫が必要でした。

ようやくARMでAADDSが作成できるようになりましたが、やはり一筋縄ではいかない「プレビュー版」。残念ながら現時点(2017.07.中旬時点)では動作が不完全のようです。

そもそも、上記画面から作成したAADDSをARM画面上で確認することができません。

 

 

 

 

詳細リンクを確認してみると、「ARMではまだ対応できてないからクラシックポータルでみてね」と記載されています。

※作成して15分経過後にクラシックポータルをみましたが作成された情報は確認できませんでした。(本当に作成されたんだろうか・・・)

また、ネットワークについてもまだARM対応ができていないとのこと。これが一番肝なのですが。残念。

詳細はこちらをご参照ください。

「New Public Preview: Azure AD Domain Services admin UX in the new Azure Portal」

つまり、今回は「予告編」といった印象ですね。また更新情報あれば掲載したいと思います。

 

 

 

シチュエーション別 Active Directory デザインパターン

先月行われた Microsoft de:code 2017 の登壇資料と動画が公開されました。

こちらになります。

今回は認証基盤をAzure ADで一本化するとどんなメリットがあるのか?ということを主体にお話ししています。

登壇の後、この構成を検討しているという企業の方からご相談もいただきました。その企業では社内 (オンプレ) にはファイルサーバーと Active Directory 環境のみだそうです。また Office 365 などの SaaS をご利用されているとのこと。

徐々にこういう構成を検討される企業は増えているようですね。

 

 

 

 

 

Office 365 へのアクセス場所制御

ずいぶん前から、Office 365のアクセス場所について「社内からのみアクセスさせたい」、「社外からのアクセスを制限したい」などご要望を耳にしていました。現在は3つの方法から選択することができます。

①ADFSによる制御

これらの制御を実現する方法として従来までだと、ADFSによる実装が代表的でした。利用状況により懸念(ADFSで認証・認可された状態で外出時など)はありますが…。

②Azure ADによる制御

また、昨年秋ごろからAzureAD側で実装することも可能になっています。(※現在プレビュー)Azure AD から該当ディレクトリを選択し、[構成] 画面をスクロールしていくと「組織のパブリックipアドレス範囲」項目が表示されます。こちらに利用を許可する場所からのパブリックIPを登録します。

③Onedrive(OneDrive for Business)管理画面による制御

外部からのアクセス制御したいサービスに「OneDrive for Business」やSharepoint」があげられます。

現在プレビュー段階(※2017年1月中にGA予定。)ですが、OneDrive for Businessに管理画面ができました。先行リリースを有効にしていると、Onedriveの画面メニューに「OneDrive 管理者プレビュー」というリンクが表示されます。表示されなかった場合は以下のリンクからご利用ください。(テナントにより表示されない可能性もあります)

https://admin.onedrive.com/

管理者プレビュー画面より「デバイスアクセス」をクリックします。「ネットワークの場所に基づいてアクセスを制限する」項目が表示されます。

チェックボックスにチェックをいれるとIPを登録する画面が表示されます。そこへアクセスを許可する場所のパブリックIPを登録します。

 

登録された場所以外からのアクセスは拒否されることが確認できます。

選択肢が増え柔軟に対応できるようになってきましたが、以下のような注意事項もありますので、自社の状況を考慮し適切な選択をする必要がありそうです。

●アクセスの許可/拒否はテナント単位です。

●現在はIPによるアクセスを許可されていない場合は、管理画面へのアクセスも不可能です。

※現在プレビューのため、GAされた際には仕様やUIなど変更されている可能性もあります。ご了承ください。

 

Azure AD Connect 構成前の準備

先日、Azure AD Connect のNew Version 1.1.105.0 が出てきました。
こちらに新機能情報が網羅されているので、ご確認下さい。
Azure AD Connect: Version Release History

Office 365 のディレクトリ同期ツールとしてもこちらの利用が推奨されるようになりました。
DirSync を利用されている企業も多いと思いますが、サポート期限の問題もありますので、
折をみてこちらへの移行をお勧めいたします。

さて、Azure AD Connect は、ディレクトリ同期のみならず、ADFSを利用したシングルサインオン環境をほぼ自動で構築することもできます。
詳細は、こちらをご一読下さい。
Office 365 運用管理入門(10)
最新のディレクトリ同期ツール「Azure Active Directory Connect」でシングルサインオン環境を構築する

さて、前置きが長くなりました。
AADConnectを利用してSSO環境を構成する場合、極力一度の操作で終了できるように事前準備を行いましょう。
設定漏れ、準備ミスなどで失敗した場合、「AADConnectアンインストール」 → 「WID(ADFSでSQLServer以外の場合に利用するDB)削除」→「ADFS アンインストール」
などの対応が必要です。
※WIDの削除に関しては、他システムで利用している可能性がある場合は、必要なDBのみ選択して削除します。

エバンジェリスト安納さんのブログ
こちらはADFS 2.0 ベースのお話ですが、ADFS 3.0 の場合は対応する SQLServer Managementを別途ダウンロードしてください。

では、何を準備するかを以下にまとめます。

<準備リスト>
①SSL証明書…さすがにこれは忘れないと思いますが、公的な認証局から取得して下さい。AADConnect構成時に、証明書を参照する必要があります。
②公開DNSレコードの登録…公開DNSへフェデレーションサービス名でプロキシに設置するADFSのIPを登録します。
③内部DNSレコードの登録…DC,ADFSはドメイン内なので問題ありませんが、ADFSプロキシのプライベートIPも登録しておかないと、AADConnectで構成する際に、認識してくれないことがあります。
④リモート管理の有効化…とくにAzure仮想マシンでこの環境を構成する場合は必須です。
(さらにGUIだと一見有効化になっていても認識されないことがあるので)PowerShellでADFS、ADFS Proxy 側で以下のコマンドを実行します。

Enable-PSRemoting -Force

ADFSプロキシをリモート管理するために、DC側で、以下のコマンドを実行します。

Set-Item WSMan:\Localhost\Client\TrustedHosts -Value <Web アプリケーション プロキシのホスト名>.<Active Directory ドメイン名

上記の準備を終了してからAADConnectを構成しましょう。
アンインストールして再実行しようとすると、初回にはなかったエラーが出てくることがあります。
準備を整えて、1度の構成で終了できるようにするのがお勧めです。