皆さんこんにちは。国井です。

今日は、1年ほど前に紹介させていただいた、Azure Multi-Factor Authenticationを利用したADFSの多要素認証についてです。

Microsoft Azureで多要素認証のライセンスを購入した場合(またはAzure AD Premiumのライセンスを購入した場合)、Azureで用意した多要素認証機能(電話、SMS、モバイルアプリなど)を利用して、ADFSでの多要素認証ができるようになります。そして、オンプレミスではMulti-Factor Authentication Serverというツールをインストールすることで、Active Directoryに登録されているユーザー情報をインポートし、多要素認証を行うユーザーの登録が簡単に行えるようになります。

Multi-Factor Authentication Serverというツールの具体的な使い方は、過去の投稿でも掲載しているので、そちらをご覧いただくこととして、ここでは効果的な利用方法について考えてみたいと思います。

■　■　■

Multi-Factor Authentication Serverは起動すると、[ユーザー]項目から多要素認証を利用するユーザーを登録することができ、ユーザーの登録にはActive Directoryに作成されたユーザーをインポートして登録することができます。

[Active Directoryからインポート]ボタンをクリックして登録すれば、登録の手間はかなり省けるのですが、ひとつだけ注意しなければならないことがあります。それは、多要素認証に電話を利用する場合、電話番号をどうやってActive Directoryからインポートするか？ということです。過去の投稿でも書きましたが、電話で行う多要素認証は電話番号の先頭のゼロを取り除いた番号である必要があり、また、国コードもデフォルトの米国から日本に切り替える必要があります。

以上の設定を手動で行うのは、とても面倒なので、インポートする前のタイミングで変更
(つまりActive Directoryに登録されているユーザーのプロパティから変更)するのがベストではないかと考えています。

それを踏まえて、Active Directoryユーザーのプロパティには、電話番号を次のように入れておくことをお勧めします。

このように設定しておけば、Multi-Factor Authentication Serverにインポートされるときは、国コード +81、電話番号 80XXXXXXXXと登録されるようになります。問題は、Active Directoryでどうやって、既存の携帯電話番号080～を+8180～に変更するかです。
ここはPowerShellに頑張っていただきましょう。
前回の投稿で登場したスクリプトをベースに、こんな感じにしてみました。

Get-ADUser –Filter {UserPrincipalName –like “080*”} `
–Property mobile –SearchBase “DC=example,DC=com” | `
ForEach-Object
{
$mobile = $_.mobile.Replace(“080”, “+8180”)
Set-ADUser $_ -MobilePhone $mobile
}

example.comは現在お使いのActive Directoryドメイン名、080は携帯電話の先頭の番号です。090で始まる携帯電話番号の場合は080→090、+8180→+8190のように書き換えて使ってください。

皆さんこんにちは。国井です。

Office 365を利用時のシングルサインオン設定は私の周りでも
様々なご質問やご相談をいただくことが多く、年々ニーズの高まりを感じます。

そんな折、Azure Active Directory Connect (AAD Connect)がGAされ、
広く一般にAADConnectを利用したシングルサインオン環境の構築ができるようになりました。
そこで今回はAADConnectを利用したOffice365のシングルサインオン環境の構築を
ステップバイステップで見てみたいと思います。

■　■　■

AADConnectを利用したOffice365のシングルサインオン環境の構築が
従来のシングルサインオン環境の構築方法と決定的に異なるのは設定の簡単さ。

これまでよりも必要な設定手順が大幅に簡略化され、AADConnectのウィザード画面から
ほとんどすべての作業ができてしまう、という優れものです。

ですが、実際にはAADConnectだけで、すべての設定が完了するわけではありません。
できること、できないことを確認しておきましょう。

■AADConnectで実現可能なシングルサインオン環境の設定
・ディレクトリ同期ツールのインストールと設定
・ADFSのインストールと設定
・Webアプリケーションプロキシ(WAP)のインストールと設定

■AADConnectで実現できない設定(手動設定が必要な作業)
・Windows Server 2012 R2がインストールされたサーバー(ディレクトリ同期サーバー、ADFSサーバー、Webアプリケーションプロキシ用)の用意
・SSL証明書の用意
・Office365で使うドメインの登録
・ディレクトリ同期のアクティブ化
・ADFSサーバーやWebアプリケーションプロキシにアクセスするためのDNSレコード

ということですので、SSL証明書は商用認証局から購入しておくこと、
Office365で使うドメインの登録とディレクトリ同期のアクティブ化はそれぞれ
Office365管理センター(https://portal.office.com)で設定しておきましょう。
また、DNSレコードはActive Directory用のDNSサーバーと外部公開しているDNSサーバーにそれぞれSSL証明書の名前と同じ名前のレコードを登録してください。

それが完了したらAADConnectを使ってシングルサインオン環境の構築開始です。
今回構築するのは以下の図のうち、ディレクトリ同期サーバー、AD FS、Webアプリケーションプロキシの3つのサーバーです。

■　■　■

まず、AADConnectツールですが、マイクロソフトのダウンロードセンターからダウンロードしておきます。
この投稿を執筆している時点では英語版だけがダウンロード可能です。

ダウンロードしたら、ディレクトリ同期ツールをインストールするWindows Server 2012 R2サーバー上で、実行します。ウィザードの最初の画面では使用許諾契約のチェックをつけてContinueをクリック

Express Settingsとは、ディレクトリ同期ツール(AADSync)だけをインストールするオプションです。ですが、今回はADFSもインストールするので、Customizeをクリック

Install requied componentsでは、ディレクトリ同期ツールをインストールするときのインストールオプションを選択できます。今回は何も選択せずにInstallをクリック

User sign-inではOffice365へのサインイン方法を選択します。ここではADFSを使うので、Federation with AD FSを選択して、Nextをクリック

Connect to Azure ADでは、Azure AD(Office365)管理者の資格情報を入力し、Nextをクリック

Connect your directoriesでは、シングルサインオンに使うActive Directoryドメイン(フォレスト)の名前と管理者の資格情報を入力して、Add Directoryをクリック

すると、フォレストが登録されます。フォレストは複数登録することも可能です。登録が完了したら、Nextをクリック

Uniquely identifying your usersでは、ディレクトリ同期によって同期されたユーザーをADとAzure ADでどのような属性を使ってマッピングするか選択します。
Users are represented only once across all directoriesを選択すれば、デフォルト設定でのシングルサインオンになりますし、
User identities exist across multiple directoriesを選択すれば、任意の属性を利用したシングルサインオン(いわゆるAlternate Login ID)になります。
ここでは前者を選択して、Nextをクリック

Filter users and devicesでは、同期対象となるグループを選択できます。ここでは特に設定せず、Nextをクリック

Optional featuresでは、同期対象となる属性や同期方法(片方向の同期または両方向の同期)などを選択できます。ここでは特に設定せず、Nextをクリック

AD FS Farmでは、これからインストールするADFSサーバーを新規ファームとするか、既存のファームに追加するか選択します。
新規ファームの場合は、使用するSSL証明書ファイル(PFX形式)を指定します。
設定したらNextをクリック

ADFSサーバーをインストールするサーバー名を指定してAddをクリック

インストールするADFSサーバーは複数指定することが可能です。インストールするサーバーをすべて指定したらNextをクリック

Web application proxy serversでは、WAPをインストールするサーバーを指定します。
こちらも複数のサーバーを指定可能です。インストールするサーバーをすべて指定したらNextをクリック

Proxy trust credentialsでは、WAPからADFSサーバーに接続するときの資格情報を入力します。入力したらNextをクリック

AD FS service accountではADFSサーバーのサービスアカウントを指定します。ここでは、group Managed Service Account(グループで管理されたサービスアカウント：gMSA)を使用するので、Create a group Managed Service Accountを選択してNextをクリック

Azure AD Domainでは、シングルサインオン対象となるドメイン名を選択して、Nextをクリック

ここまでで設定は完了です。Installをクリックして構築開始です。

しばらくすると、設定完了します。最後に接続確認を行うので、ウィザード画面のチェックをつけて、Verifyをクリック

接続確認が完了すると、下のような画面が表示されます。Exitをクリックして完了です。

インストールが完了したのち、ADFS管理ツールを開くと、Office365のシングルサインオン設定ができていることが確認できます。

また、シングルサインオンも手動で設定したときと同じようにできていることが確認できます。

以上です。
今までのADFSサーバーの構築手順をご存知の方であれば、ずいぶんと簡単になったことがわかります。
また、ADFSサーバーやWebアプリケーションプロキシの複数台構成も可能ですし、
ディレクトリ同期サーバーとADFSサーバーやWebアプリケーションプロキシは別々のサーバーになるように構成することも可能なので、現実的な運用で利用する構成がAADConnectでできることがわかります。

一方で、ウィザードで構成が出来上がっても、うまく通信できないときのトラブルシューティングを行ったり、この構成をベースにして他のサービスまでシングルサインオン環境を構築したい場合には、ADFSやAzure ADに関する基礎的な知識が必要になることは言うまでもありません。
クリエ・イルミネート社と共同で開催しているOffice365ユーザー認証ベストプラクティストレーニングコースでは、基礎的な知識からじっくり学習していただけるコンテンツと学習環境を整えておりますので、これからOffice365のシングルサインオンを実装される方、Office365に限らずADFSやAzure ADを利用したシングルサインオン環境を構築したい方はご参加いただくことをお勧めします。

皆さんこんにちは。国井です。

以前、クラウドからActive Directoryのパスワードを変更する方法として、
Azure AD Premiumの機能を利用したパスワードリセットの機能を紹介しました。

しかし、この方法はパスワードリセットであって、変更ではない！というご指摘を色々といただきました。
そこで、今回はADFSサーバーを経由してActive Directoryユーザーのパスワードを変更する方法(リセットする方法じゃありませんよ)を紹介します。

この方法を利用して、ADFSサーバーをWebアプリケーションプロキシ経由で公開すれば、インターネット上からでもActive Directoryユーザーのパスワードが変更できるようになりますね。
では、早速見てみましょう！

■　■　■

ADFSサーバー経由でActive Directoryのパスワードを変更するときは、Workplace Joinの設定により、パスワード変更を行おうとするデバイスがActive Directoryに登録されていることが前提です。(ドメイン参加していることではなく、Workplace Joinでデバイス登録していることです。)

Workplace Joinによるデバイス登録方法については、こちらを参考にしてください。

デバイス登録の設定が完了したら、
ADFSサーバーでADFS管理ツールを開き、
エンドポイントの/adfs/portal/updatepassword/を有効にして、ADFSサービスを再起動します。Webアプリケーションプロキシ経由で同じ機能を利用するなら、[プロキシに対して有効にする]も選択しておいてください。

設定はこれだけ。
あとは、https://<フェデレーションサービス名>/adfs/portal/updatepassword/にアクセスし、パスワードを変更するユーザーの名前と、前のパスワード、新しいパスワードをそれぞれ入力することで、

Active Directoryユーザーのパスワードが変更されます。

ちなみに、デバイス登録されていないデバイスからURLにアクセスし、パスワード変更しようとすると、

このようにエラーになります。

その他、有効期間に基づいてパスワード変更を促す設定もありますので、手順がまとまりましたら、改めて紹介したいと思います。

皆さんこんにちは。国井です。

当ブログでも、これまで扱ってきたADFSやAzure ADのトピックをまとめて学習するトレーニングコース、「Office 365認証ベストプラクティス」コースが2015年8月11-12日で開催されます。今回は、従来のOffice365とADFSの組み合わせに加えて、これまでにも要望の高かった、

・Office 365以外でのADFSの活用
・多要素認証・デバイス認証

の内容を充実させて提供する予定です。
上記内容は今までに受講していただいた方々にも、ご紹介してきた内容ですが、
今回はオンプレミスとクラウドのID基盤の融合(以下の図参照)という枠組みの中で、私たちが考えるべきことを意識しながらご紹介していく予定です。

もちろん、当日いただきましたご要望にも合わせて、
様々なカスタマイズをしてまいりますので、
ブログで色々なテクノロジーを見ているけど、実機で体験をしてみたいと考えている方、
業務でOffice365を展開する機会がこれからあるという方、

ご参加をお待ちしております。

トレーニングルームでお会いしましょう！

皆さんこんにちは。国井です。

一方、管理対象となるユーザーをまとめる場合、
ユーザーに属性が割り当てられていると便利です。

たとえば、
部署＝営業だったら、
役職＝部長だったら、
事業所＝東京だったら、
などなど、設定してあると、ユーザーをまとめてグループ化しやすくなります。

現在、Active Directoryで部署、役職、事業所などを
属性として設定していると企業であれば、Active Directoryで設定した
属性をAzure ADでも活用できるようにすることをお勧めします。

しかし、Active Directoryの、どの属性情報がAzure ADに同期されるのでしょうか？
このことを調べるには、いくつかの方法がありますが、ここでは
AADSyncを使って調べる方法を紹介します。

■　■　■

AADSyncをインストールしたサーバーからデスクトップに保存されているDirectorySyncToolアイコンを実行し、

ウィザードを進めていき、[オプション機能]ページで、[Azure ADアプリと属性フィルター]にチェックをつけます。

[Azure ADアプリ]ページでは、特定のアプリで使用する属性だけを同期するように
設定することができます。しかし、ここでは、そのまま次へ

ポイントはここです。
[Azure AD属性]ページで、一覧が表示されます。
実に色々な属性が同期されることがわかります。
たとえば、役職の属性として使われるtitleだったり、
部署の属性として使われるdepartmentだったり、
事業所の属性として使われるphysicalDeliveryOfficeNameだったり。
ユーザーにインストールされた証明書の情報を格納するuserCertificate属性も
同期されることが確認できます。

見ていただくと、実に多彩な情報が同期されることが確認できます。
また、Azure ADに同期された属性情報は、こちらもいくつかの方法で確認できますが、
Graph Explorerは属性名と属性値のセットで表示されるので確認しやすいと思います。
Graph ExplorerはAzure ADに対してGraph APIを利用してクエリを実行することができるサイトですが、
サイトの中で
http://graph.windows.net/<ドメイン名>/users/<ユーザー名@ドメイン名>
のクエリを書き、GETをクリックすると、下の画面のように表示されます。

クエリの書き方はマイクロソフトのWebサイトでも紹介しているので、合わせて参考にしてみてください。

■参考サイト
Jesper Stahle’s Notes From the Field
http://jesperstahle.azurewebsites.net/?p=1542

皆さんこんにちは。国井です。

先日、トレーニングで「ADFSやAzure ADで提供されるデバイス登録サービス(DRS)でデバイスを登録すると何が起きるのですか？」というご質問をいただきました。

答えだけ先に言うと「デバイスを登録すると、Active Directoryにデバイスが登録され、デバイスには証明書が実装される」というのがシンプルな回答になります。

(そもそもデバイス登録サービスってなに？という人はADFSでデバイス認証を実装という投稿がありますので、こちらをどうぞ)

Active Directoryにデバイスが登録される部分については以前の投稿「Windows Server 2012 R2を使ってiOSだけがOffice365にアクセスできるようにする(2) 」と紹介しているので、そちらを見ていただくとして、今日は「デバイスには証明書が実装される」という部分について細かく見ていきたいと思います。

ADFSによるデバイス認証はDRSで事前に登録されているデバイスを対象にアクセスを許可するサービスですが、登録されているデバイスであることを確認するために、DRSで配布された証明書がデバイスにインストールされているかを確認します。
その証に、ADFSによる認可時に証明書をチェックしていることがイベントログから確認できます。
イベントログには「デバイス証明書」という欄があり、証明書の拇印が記載されていることも確認できますね。

証明書の一覧はMMCの証明書スナップインで確認できますが、登録されたデバイスから証明書スナップインを見ると、ユーザーに対して(コンピューターではない)証明書が発行されていることがわかります。(拇印もイベントログに記載されているものと同じですね。)

登録されたデバイスの情報はADFSのDRSでも、Azure ADのDRSでも、最終的にはActive DirectoryのRegisteredDevicesに登録され、一覧表示されます。
それぞれのデバイスのプロパティを開くと、altSecurityIdentities属性で拇印を確認できます。

このようにDRSで登録されたデバイスには証明書が発行され、発行された証明書を持っていることを確認することで、デバイス認証が許可されるのです。逆に言えば、デバイス証明書を削除してしまえば、一度DRSで登録されたデバイスであってもデバイス認証は拒否されます。

そして重要なのが、デバイス証明書はコンピューターではなく、ユーザーの証明書ストアに保存されるってこと。
このことは、デバイス認証では「どのデバイスから認証(認可)しようとしているか？」だけでなく、「どのユーザーから認証(認可)使用としているか？」までチェックしようとしていることがわかります。

2015年8月19日追加
Windows 10では他のOSと異なるプロセスによってデバイス登録を行い、その証に特別なカギ(NGC-Key)をTPMに格納するという仕組みを採用していますが、
これまでのOSと同じように、引き続きデバイス用の証明書をAzure ADから発行し、Windows 10デバイスに格納しています。

皆さん、こんにちは。国井です。

Windows 10の登場とともに新しいブラウザーMicrosoft Edgeが使えるようになりましたね。
企業内でのWindows 10の利用、ましてやMicrosoft Edgeの利用となると、
まだまだ先の話だと思います。しかし、今後、Microsoft Edgeブラウザーを利用して
Office 365のシングルサインオン(SSO)を行う機会が出てきた時のために
どのように利用すべきか、確認しておきましょう。

■　■　■

まずはデフォルトの状態でのMicrosoft EdgeでのSSOの動きを確認しておきましょう。
Office 365のポータルサイトのURL(https://portal.office.com)にアクセスし、
SSOで使用するユーザー名を入力して、Enterキーを押すと

このように別の認証画面が表示されます。
(条件によって表示されたり、されなかったりするのですが、ここでは割愛します)

ところが、パスワードを入力してサインインすると、下の画面が表示されます。
これは何でしょう？？

見た目にはよくわかりませんが、認証自体は完了しているようです。
その証に、URL欄にmail.office365.comと入力してアクセスすると、OWAに
(あらためて認証することなく)アクセスできることがわかります。

しかし、これではSSOではありませんし、そもそもURLをもう一度入れなおすなんて、運用的にはNGじゃないかと思うのです。
そこで、これをきちんとSSOアクセスできるように設定していきましょう。

MVP渡辺さんのブログ「IE以外でADFSにSSOする（2012R2編）」でも紹介しているように、Windows Server 2012 R2のADFSは(Get-AdfsProperties).wiasupporteduseragentsコマンドレットで定義されている、HTTPヘッダーのUser-Agent文字列と同じ文字列のみSSOできるように構成されています。Microsoft Edgeに記載されるUser-Agent文字列はデフォルトで設定されているUser-Agent文字列に含まれないので、Microsoft EdgeのUser-Agent文字列を追加してあげます。ちなみにUser-Agent文字列は

"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.71 Safari/537.36 Edge/12.0"

なので、いずれかを追加してあげれば、SSOのためのADFSサーバー側の設定が整います。
(Microsoft EdgeのUser-Agent文字列って、なんでもアリな文字列ですね)
そのため、渡辺さんが紹介しているWindows PowerShellコマンドレットをそのまま実行すればOKです。

$old=(Get-AdfsProperties).WIASupportedUserAgents
$new=$old+”Mozilla/5.0″
Set-ADFSProperties -WIASupportedUserAgents $new

これでアクセスすると、SSOになるかと思いきや
今度は認証ダイアログが出てきてしまいました。

このようなダイアログが表示される場合、Internet Explorerのときには、ローカルイントラネットゾーンにADFSサーバーのフェデレーションサービス名を含むURLを指定してSSOできるように構成することで解決していました。しかし、Microsoft Edgeにはゾーン設定がそもそもありません。

ところが、Windows 10のInternet Explorerから設定したローカルイントラネットゾーンの設定はMicrosoft Edgeでも利用できるので、Windows 10のInternet Explorerからローカルイントラネットゾーンにフェデレーションサービス名を含むURLを設定して、

Microsoft Edgeブラウザーからユーザー名を入力してEnterキーを押すと、

そのままサイトにアクセスできることが確認できます。

なお、外出先からサインインするときやドメイン参加していないPCからサインインするときは
以上の設定を行っても、今まで通り認証画面が表示され、サインインしてからOffice365サイトにアクセスできるようになります。

皆さんこんにちは。国井です。

Windows 2000 ServerやWindows Server 2003が利用されていた頃、MCP資格取得を目的としてActive Directoryについて学習し、そして現在に至っているという方は多いのではないかと思います。そして、色々な方からよく伺うのが、「私のActive DirectoryのスキルはWindows Server 2003までで止まっている」というお話です。Active Directoryの基本機能は Windows Server 2008になっても、Windows Server 2012になっても変わらないので、[Active Directoryユーザーとコンピューター]管理ツールがなくならない限り、まあ、なんとかなってしまいます。しかし、最近ではクラウドとの融合や移行が進み、クラウドの認証基盤であるAzure ADを無視できなくなる時代が少しずつではありますが、進んでいるように思います。

そこで今日は「ワークグループとドメイン以外の選択肢」というWindows Server 2003時代には考えられなかった選択肢について紹介したいと思います。

■　■　■

これまで、Windowsの認証方法と言えば、ワークグループとドメインという選択肢でしたが、
Windows 10では新しくAzure ADが加わりました。

[Azure ADに参加]という操作を行うと、

・ Azure ADに登録されたユーザー名で認証できる
・ Azure ADを使用するアプリケーションへのアクセスが簡略化される
・ Azure ADに参加したデバイスの情報がAzure ADに登録される
・ (ADFSとの組み合わせによって)登録されたデバイスだけがアプリにアクセスできる
・ (Intuneとの組み合わせによって)Intuneからポリシーを配布できる

などのメリットを享受できます。

このメリットをOffice 365 のサインインで考えてみましょう。
Office 365の場合、ワークグループまたはドメイン参加している、従来のPCであれば、
Office 365(Azure AD)へのサインインは、別途ユーザー名とパスワードを入力する必要がありました。

そこで、Windows Server 2008以降ではADFSという選択肢を用意し、
ドメインにサインインしたユーザーにはOffice 365 (Azure AD)にアクセス可能なトークンを発行し、そのトークンを持ってAzure ADにアクセスしていたので、別途ユーザー名とパスワードを入力する必要がなくなりました。(いわゆるシングルサインオンっていう方法です)
ところが、シングルサインオンの場合、ADFSサーバーを構築するというタスクが待ち受けています。ADFSサーバーを構築することなく、手軽にAzure ADにサインインできる方法はないか？ということで登場したのが[Azure ADに参加]という方法です。

Azure ADに参加すると、Windowsのサインインの時点でAzure ADに登録されたユーザーを利用するので、Office 365にアクセスするためのAzure ADへのサインインは改めて行う必要がないのです。

以上の3つの認証方法を下のように図でまとめてみました。

[Azure ADに参加]設定

それでは、Azure ADに参加の設定を見てみましょう。

Azure ADに参加という選択肢はワークグループか？ドメインか？を選択するときと同じく、Windowsのインストール時に選択できます。

Windowsのインストール後であれば、[設定]-[システム]-[バージョン情報]から選択することができます。

サインイン画面で、Azure ADにあらかじめ登録されたユーザー名とパスワードを入力します。(Azure ADユーザーは、Office365から作成することができます。そのほかの方法で作成するときはAzure管理ポータルを使います。設定方法はマイクロソフトさん提供のドキュメントをご覧ください)
Azure ADに参加完了すると下のように、[設定]-[システム]-[バージョン情報]画面で確認できます。

Azure ADに参加したPCはPIN番号を登録され、次回から登録されたPIN番号でサインインすることになります。毎回サインインのたびにAzure ADユーザーのパスワードを入力しなくてもよくなるので、便利ですね。(なぜパスワードを入力しなくてもサインインできるのかについては、MVP宮川さんが紹介している
「Windows 10 の新機能 Azure AD Domain Join とは」の中でも説明があるので、合わせて参考にしてください)

サインインすると、すでにAzure ADにサインインしている状態(と同じ状態)になりますので、Azure ADへのサインインを必要とするOffice365へのサインインはパスワードを入力しなくてもそのままアクセスできるようになります。(私の環境ではMicrosoft Edgeでも、Internet Explorerでも、そのままアクセスできました)

一方、Azure管理ポータルにはAzure ADに参加したときに使用したデバイスの情報がユーザーのプロパティ情報として確認できます。

Azure ADに登録されたデバイス情報はディレクトリ同期ツールによって、オンプレミスのActive Directoryに同期され、同じくオンプレミスのADFSサーバーによってデバイス認証に利用することができます。デバイス認証については「ADFSでデバイス認証を実装」でも紹介しているので、合わせてごらんください。

Workplace Joinとの違い

Windows 8.1の時にはWorkplace Join(社内参加)という機能があり、Azure ADへのデバイス登録ができました。
では、Workplace JoinとAzure ADの参加は何が違うでしょうか？
Windows 10のAzure ADに参加する機能との違いは認証そのものにAzure ADを使うという点です。Workplace Joinの時はワークグループまたはドメインに参加している状態からデバイスをAzure ADに登録していたので、どちらかというとデバイス登録機能としての使い方がメインだったわけです。
これって、Azure ADの参加とは決定的に違いますよね。

Microsoft アカウントによるサインインとの違い

Windows 8以降では、Microsoft アカウントを利用してサインインし、OneDrive.comやOutlook.comへのサインインが不要になるという、Azure ADに参加機能のコンシューマー版みたいなものがありました。しかし、Microsoft アカウントによるサインインの場合、ワークグループにサインインする機能の拡張機能としてMicrosoftアカウントを利用しているので、Microsoft アカウントによるサインインを選択すると、対応するユーザーがローカルのアカウントデータベースにも作成されます。
それに対して、Azure ADに参加する場合、ワークグループとも、ドメインとも異なる認証方法なので、オンプレミスにユーザーを作ることはありません。

以上、Azure ADに参加機能を利用するときの参考になれば幸いです。

皆さんこんにちは。国井です。

今週はAzure ADとMicrosoft Intune関連の情報を連続して投稿しています。
連投でそろそろ肩が壊れそうです。

今日は、Azure AD Premiumの機能として先日登場したAAD Connect Healthという機能を使ってみましたので、ここにも掲載しておきます。
AAD Connect Healthとは、Azure Active Directory Connect Healthの略で、オンプレミスに実装したADFSサーバーやプロキシの状態をクラウドから監視するだけでなく、ADFSサーバーの利用状況なども併せて確認できる、監視ツールです。

■Azure Active Directory Connect Health
https://msdn.microsoft.com/ja-jp/library/azure/Dn906722.aspx

AAD Connect HealthはMicrosoft Azureの新しいポータルから利用可能なツールで、
[セキュリティ＋ID]-[Azure AD Connect Health]から新しいインスタンスを作成します。

どのAzure ADドメインで利用するかを選択し、

[クイックスタート]をクリックして、

[Download Azure AD Connect Health Agent for ADFS]をクリックして、ツールをダウンロードします。

ダウンロードしたツールはADFSサーバー上で実行し、インストールします。

インストールが完了したら、[今すぐ構成する]をクリックし、

Azure ADの管理者アカウントでサインインすると、

PowerShellスクリプトが実行されて構成されます。

インストールが完了したら、Azure管理ポータルを参照します。すると、エージェントがインストールされたADFSサーバーの台数が表示され、ADFSサーバーの稼働状況が確認できます。
また、画面右下に注目すると、

24時間以内にADFSサーバーを経由して、どのようなアプリケーションへのアクセスがあったかやトークンの発行数などが確認できます。ただし、アプリケーションは名前ではなく、ADFSサーバーに登録されたURNと呼ばれる識別名で表示されるので、少しわかりにくいです。(ちなみに、urn:federation:MicrosoftOnlineというのがOffice365へのシングルサインオンです。)
このあたりはURNではなく、証明書利用者信頼の名前で表示するなど、していただけると、よりわかりやすいかなと。
今後の改善に期待ですね。

なお、アプリケーションへのアクセス状況等は、ADFSサーバーのセキュリティログから情報を抽出して表示しているので、セキュリティログにADFSのアクセスログが残るよう、事前に設定しておく必要があります。この設定についてはMVP渡辺さんのブログで紹介しているので、合わせて参考にしてください。

参考サイト
Monitor your on-premises identity infrastructure in the cloud
https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect-health/

皆さんこんにちは。国井です。

先日、Azure ADのセミナーで、「Azure ADの多要素認証プロバイダーで、モバイルアプリを利用する場合、どのような設定が必要ですか？」というご質問をいただきました。

ざっくりとした回答を申し上げると
「多要素認証プロバイダーのポータルサイトからモバイルアプリのアクティブ化を実行してください」となるのですが、私の環境で実際に構築したところ、うまく動作しないところがありましたので、これについては手順がまとまりましたら、改めてご紹介します。

今日はその前提条件となる多要素認証プロバイダーのポータルサイトが実は様々な管理作業を行うのに、とても便利なので、ポータルサイトそのものの紹介をさせてください。

多要素認証プロバイダーのポータルサイトは、本来Azure管理ポータルやMulti-Factor Authentication Serverの管理ツールから行うような設定をMulti-Factor Authentication ServerのWebサイトからできるようにしたもので、Multi-Factor Authentication Serverに直接アクセスできないような環境のときに利用すると便利だと思います。

例えば、「ユーザーから多要素認証のワンタイムバイパスを行ってほしいと言われたけど、管理者は外出しているので、外出先からワンタイムバイパスの設定を行いたい」などというニーズが考えられます。
そういうときには、Multi-Factor Authentication ServerのWebポータルをインターネットに外部公開しておけば、どこからでもMulti-Factor Authentication Serverの各種設定ができますね。(そのほかにもいろいろな操作が可能で、下のポータルサイトの画面を見てもらえれば、何ができるか確認できると思います。)

また、多要素認証プロバイダーのポータルサイトは「ユーザーポータル」と一般的に呼ばれており、その名前からもわかるように(管理者ではなく)ユーザー自身が多要素認証に関わる各種設定を行うことができます。
(今日はご紹介しませんが、モバイルアプリを利用するときのアクティブ化設定などができます。)

このようなポータルサイト(ユーザーポータル)なのですが、利用するには、次の前提条件があります。

・ユーザーポータルの利用には多要素認証プロバイダーのWebサービスSDKのインストールが必要
・多要素認証プロバイダーのWebサービスSDKのインストールには、IISとIIS6メタベース互換のインストールが必要

では、前提条件をクリアしながら、ユーザーポータルを実装してみましょう。
(ちなみにMulti-Factor Authentication Serverそのもののインストールも必要ですが、それはこちらに記載しました)

■　■　■

まず、IISとIIS6メタベース互換ですが、Multi-Factor Authentication Serverがインストールされたコンピューターに[役割と機能の追加]からインストールしておいてください。

次に、WebサービスSDKのインストールはMulti-Factor Authentication Serverの管理ツールを起動し、[WebサービスSDK]をクリックして、[WebサービスSDKのインストール]を実行して始めます。

[WebサービスSDKのインストール]を実行すると、ウィザードが開始しますが、基本的にはすべて次へで進めていけばOKです。WebサービスSDKで使用するIIS Webサイトのディレクトリ名は自由に指定可能なので、必要に応じて変更してください。ここではディレクトリ名はそのままにしてインストールを完了します。

次に、ユーザーポータルをインストールします。ユーザーポータルのインストールはMulti-Factor Authentication Serverの管理ツールから[ユーザーポータル]をクリックして、[ユーザーポータルのインストール]を実行して始めます。

インストールが完了したら、Multi-Factor Authentication Serverの管理ツールで、ユーザーポータルのURLとして、
https://<多要素認証プロバイダーサーバー名>/MultiFactorAuth/と入力しておきます。
そのほか、各種チェックボックスにチェックをつけておくと、ユーザーポータルにサインインしたユーザーが自分でできる操作を決定できます。
それから[ユーザーにログインを許可する]にチェックをつけておくことをお忘れなく。

[信頼できるIP]タブをクリックし、ユーザーポータルにアクセスするクライアントのIPアドレス範囲を指定します。これにより、指定したIP範囲以外からはポータルサイトにアクセスできないので、社内イントラのIPアドレスを設定したら、ポータルへのアクセスは社内からしかできなくなるので注意が必要です。

[管理者]タブをクリックし、管理者となるユーザーも設定しておきましょう。
管理者を登録し、管理者ができる操作も同時に定義しておきます。

■　■　■

ここまでで設定完了です。
では、早速アクセスしてみましょう。
ポータルサイト(https://<多要素認証プロバイダーサーバー名>/MultiFactorAuth/)にアクセスし、管理者となるユーザーの名前とパスワードを入力すると、

冒頭で紹介したポータルにアクセスできました。
このうち、[ユーザーの管理]という部分が管理者ができる作業項目、[マイアカウント]という部分が自分自身の作業ができる項目です。

では、今回は管理者として、ユーザーの多要素認証のワンタイムバイパスを設定してみましょう。ここでは、[ユーザーの検索]をクリックしてバイパスするユーザーを検索し、
検索結果から、バイパスの操作を行います。([ワンタイムバイパス]というメニューがありますね)

ワンタイムバイパス画面では、バイパスする時間を設定します。ワンタイムバイパスはワンタイムではなく、秒数なのですね。。

設定が完了すると、設定した秒数以内にサインインすると、多要素認証をスキップできます。
実際にサインインしてみると、多要素認証を要求する画面は表示されますが、実行すると、

何も多要素認証の操作を行うことなく、目的のサイトにシングルサインオンできます。

いかがでしょうか？

ワンタイムバイパス以外にも様々な操作ができるようなので、多要素認証プロバイダーの利用を検討している方はぜひご自身で実装し、確認してみてください。

皆さんこんにちは。国井です。

以前、当ブログでAlternate Login ID(代替ログインID)という方法を利用して、Office365(Azure AD)のシングルサインオン(SSO)を構成する方法を紹介しました。
Alternate Login IDを使うとディレクトリ同期やSSOにUPNを使わなくなるので、kunii@example.localのようなUPNでも、代替UPNサフィックスを使わないでSSOができるという、ありがたいお話でした。

しかし、その設定は結構面倒だったのですが、AAD Connectでは驚くほど簡単になっています。今日は備忘録代わりに設定を載せておきます。

■　■　■

AAD Connectを使ってSSO設定を行う際(ウィザードのステップバイステップはこちらに乗せてあります)、
AAD Connectのウィザード設定で[一意のユーザー識別]というページがあるので、[ユーザープリンシパル名]としてuserPrincipalNameではなく、mailを選択するだけ。

これにより、mail属性をベースにAzure ADへディレクトリ同期が行われ、SSOもmail属性ベースで行われるようになります。
(この画面でお気づきになったと思いますが、最近AAD Connectのウィザードが日本語対応になったのですね)

また余談ですが、Synchronization Serverツールから同期された様子を見てみると、userPrincipalNameの値としてActive DirectoryユーザーのUPNではなく、メールアドレスが入っていることも確認できます。

クラウド時代は改善のスピードも桁違いですね。

皆さんこんにちは。国井です。

突然ですけど、AAD Connectのインパクトってすごいですね。

AAD Connectの登場によって、DirSync + ADFSサーバーでOffice365のシングルサインオン環境を運用している企業でも、いずれDirSyncからAAD Connectに入れ替える時が来るのではないかと思います。

私自身も、DirSyncを使ってSSO環境を運用していたのですが、AAD Connectに入れ替えようと思ったら、案外AAD Connectのウィザードが便利なので、「SSO環境を全部壊して、1から作り直したほうが楽なのでは？」と思いました。そこで、既存のサーバーからADFSを削除し、AAD Connectから再度インストールしようとしたのですが、エラーが発生してしまいました。

そうです。
Windows Server 2012 R2のADFSサーバー(ADFS3.0)は一度アンインストールして、もう一度インストールしようとすると、エラーが発生するのです。

以前のバージョンでも、再度ADFSサーバーをインストールしようとすると、エラーが発生し、日本マイクロソフトの安納さんがブログで紹介していた設定を行い、ゴミを手動で削除する必要がありました。

そして、Windows Server 2012 R2のADFSサーバーでは、安納さんが紹介していた設定に加えて、追加で必要な設定があったので、紹介しておきます。

ADFSサーバーのデータベースにSQL Serverを利用している場合には、ブログで紹介している通り、SQL Server Management Studioから残ったデータベースを削除します。

一方、WIDを利用している場合にはC:\Windows\WID\Dataフォルダーにデータベースが残るので、ファイル削除で削除します。下の図を見ればわかる通り、ADFSのデータベースはファイル名がAdfs*.*なので、関連するファイルをすべて削除してしまいましょう。

すると、ADFSサーバーの再インストールは問題なく行えるようになります。

お試しあれ。

皆さんこんにちは。国井です。

Office 365を導入されるお客様で、シングルサインオンも一緒に導入したいと考えるお客様は最近増えてきているように思います。と同時に、お客様からよくご相談を受けるのが「特定のデバイスからのアクセスを制限したい」ということです。

当ブログでは何回かに渡って、このテーマはお話ししていますが、ざっくり言うと、
Windows 8.1の時代にはAzure ADまたはADFSを利用したデバイス登録(DRS)と、
登録されたデバイス情報に基づくADFSサーバーによるデバイス認証機能を利用することで要件を満たしてきました。
(下の図はAzure ADを利用したDRSの仕組み)

つまり、「特定のデバイスからのアクセスを制限したい」というニーズを満たすためには、

・DRSという機能で、事前にデバイスを登録 (Azure ADまたはADFSで登録)
・デバイス認証の機能でアクセス可否を決定 (ADFSで設定)

の2つを行う必要があるのです。

このうち、今日はAzure ADでのデバイス登録の話をします。
Azure ADでのデバイス登録方法とその結果の確認方法は過去のポストでも紹介しましたが、
Azure ADからデバイス登録を行うと、デバイス登録の結果はAzure管理ポータルから確認できます。

しかし、この画面、ユーザーごとにしかデバイスの登録状況を確認できません。
しかも、デバイス登録と登録解除を繰り返すと、過去に登録されたデバイス情報が残り続けるので、ゴミが溜まっていくシステムなのです。

Azure Active Directory PowerShellモジュールの活用

そんな折、最近マイクロソフトではAzure ADをPowerShellで操作するツールの新しいバージョンをリリースしました。
Azure AD PowerShellモジュールはADAL対応により、多要素認証が利用できるようになったことがクローズアップされていますが、私が注目したいのはPowerShellコマンドレットで、Azure ADに登録されたデバイスの管理ができるようになった点です。

新しいAzure AD PowerShell モジュールでは、

Get-MSOLDeviceを使えばAzure ADに登録されているデバイスの一覧表示、
Enable-MSOLDeviceを使えばAzure ADに登録されているデバイスの有効化、
Disable-MSOLDeviceを使えばAzure ADに登録されているデバイスのブロック、
Remove-MSOLDeviceを使えばAzure ADに登録されているデバイスの削除、

をそれぞれ設定できます。

実際に利用してみた様子がこちら。

Get-MsolDevice –Allを実行すると、Azure ADに登録されている、すべてのデバイス情報が一覧で確認できます。単純にGet-MsolDevice –Allと実行してしまうと、リスト形式で表示されてしまい、見にくいので、Get-MsolDevice –All | Ft Displayname, DeviceIdなどと実行すると、見やすく整形してくれていいのと思います。その中から、特定のデバイスだけ取り出して詳細な情報を見たければ、Get-MsolDevice –DeviceId <デバイスID番号>と実行すれば、上の画面のように表示してくれます。ちなみに、Enabled：Trueというところがデバイスの有効化/ブロックに関わるステータス、RegisteredOwnersというところが、デバイスを登録したユーザーの情報です。

では、続いてデバイスの有効化/ブロックを行ってみます。

Disable-MsolDevice –DeviceId <デバイスID> -Forceを実行すると、そのデバイスはブロックの設定になります。

この情報はディレクトリ同期ツールによって、Active Directoryに送られ、ADFSサーバーでアクセス可否を決定するときの材料として利用されるようになります。

特定のユーザーが不正アクセスに遭ったので、そのユーザーのデバイスをとりあえず全部使えないようにしたいということであれば、

Get-MsolDevice –RegisteredOwnerUpn <ユーザーのUPN> |Disable-MsolDevice –Forceを実行すると、すべてのデバイスがブロックされます。

それから削除について。
デバイス登録と登録解除を繰り返すと、ゴミが残るといいましたが、これもGet-MsolDeviceで発見して、Remove-MsolDeviceで削除すればいいのです。

Get-MsolDevice –RegisteredOwnerUpn <ユーザーのUPN>| Ft Displayname, DeviceId,ApproximateLastLogonTimestampと実行し、タイムスタンプが古いものを見つけてきて、Remove-MsolDeviceで削除しています。
(ApproximateLastLogonTimestamp属性はサインインの日時ではないようなのですが、詳細はわかりません。。)

いかがですか？Azure管理ポータルから操作するよりも、まとめて操作しやすい環境が整ったと思いませんか？
(本当はAzure ADだけでデバイス認証もできるようになってくれると、もっとうれしいんだけど）

■　■　■

今日の最後のトピックは、「Windows 10デバイスはWindows8.1と同じようにデバイス認証ができるか？」という点です。
まず、結論から先に言うと、私が検証している限りでは、ADFSのデバイス認証でWindows10のアクセス制御ができないようです。
(このことについては山市さんのブログでも紹介されています)

簡単に引っかかっているポイントをお話しすると、
ADFSのデバイス認証では、ADFSサーバーがトークンを発行するタイミングで
ユーザーがあらかじめ登録されたデバイスからアクセスしているかをチェックし、
登録されたデバイスからのアクセスであれば、isRegisteredUserというクレームにTrueという値を入れ、
そしてisRegisteredUser=TrueならADFSとしてトークンを発行することを許可しましょう(アクセスを許可しましょう)、という流れです。

実際に、このとおりの動きになるのか見てみると、Windows 8.1ではisRegisteredUser=Trueというクレームが発行されるのですが、
Windows 10ではisRegisteredUserクレーム自体、全く発行されません。
デバイス登録自体は問題なくできているし、登録されたデバイス情報のディレクトリ同期もWindows8.1を同じ情報を同期できているので(下記、おまけ参考)、ADFSサーバー側の処理の問題でWindows10にisRegisteredUserクレームが発行されず、デバイス認証がうまく動作しないようです。

結構これってニーズが高いので、何か回避策を早いところ見つけたいものですね。

■　■　■

おまけ – Azure ADのDRSで登録されたデバイスはADにどのような属性が同期されるか？
Windows 10デバイスがADFSでデバイス認証できないのはディレクトリ同期で同期される属性に違いがあるからなのかと思い、
ディレクトリ同期の結果をチェックしてみた結果は以下のとおりです。結果は「違いなし」です。

■Windows 10デバイス(Azure AD参加済み)をAzure AD から同期した時の結果

■Windows 8.1デバイス(ドメイン参加済み＋Workplace Join)をAzure AD から同期した時の結果

■Windows 8.1デバイス(ワークグループ＋Workplace Join)をAzure AD から同期した時の結果

ドメイン参加しているPCの場合、isManaged=Trueになるという結果以外は、OS種類による違いは特にないようです。

皆さんこんにちは。国井です。

今日はADFSのデバイス認証機能のトラブルシューティングについて。

ADFSでデバイス登録/認証機能を利用するとき、

Initialize-AdfsDeviceRegistration
Enable-AdfsDeviceRegistration

の2つのPowerShellコマンドレットを実行していました。詳しくはこちらを参照。

ところが先日、私の環境で設定していたら、こんなエラーが。
「Device Registration ServiceのACLを構成できません。」

Enable-AdfsDeviceRegistration の実行に失敗する場合、ACLのエラーであれば、RegisteredDevicesコンテナーにサービスアカウントに対するアクセス許可が割り当てられていないことが原因です。

その時は、ADSIエディターを開き、構成パーティション(既知の名前付けコンテキスト：構成)に接続し、CN=DeviceRegistrationService,CN=Device Registration Service,CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=xxxxx のプロパティを開いて、サービスアカウントにフルコントロールのアクセス許可を割り当ててあげます。

理論上は以上の手順でエラーが解消され、コマンドレットが実行できるようになるのですが、
私のケースでは複数回Initialize-AdfsDeviceRegistration とEnable-AdfsDeviceRegistration を実行することで解決しました。(なぜ？)

参考になれば幸いです。

皆さんこんにちは。国井です。

以前、特定のデバイスからのアクセスのみADFS経由でのアクセスを許可するデバイス認証の話をしましたが、デバイス認証には事前にデバイス登録(Device Registration Service：DRS)をしておく必要があります。
そして、そのデバイス登録をAzure AD経由で行った場合、Azure ADからオンプレミスのActive Directoryへディレクトリ同期する必要があります。

既にOffice 365のシングルサインオン環境を構築している企業では、ディレクトリ同期にDirSyncを利用しているところも多いかと思いますが、今後、AAD Connectに切り替わっていくことも予想されます。
そして、登録されたデバイスのディレクトリ同期に関わる設定はDirSyncとAAD Connectでは異なるので、今日はAAD Connectでの設定方法を確認してみたいと思います。

■　■　■

DirSync での登録デバイスのディレクトリ同期は以下のようなコマンドレットを実行していました。

Import-Module DirSync
$ADCred=Get-Credential

$AADCred=Get-Credential

Enable-MSOnlineObjectManagement –ObjectTypes Device `
–Credential $ADCred –TargetCredential $AADCred

一方、AAD Connectでは、上記のコマンドレットの代わりにAAD Connectのインストールウィザードで登録デバイスを同期するようにチェックボックスにチェックを入れるだけです。
(その他の作業は以前の投稿で確認してくださいね)

ところが、ウィザードを見てみると、チェックボックスにチェックをつけられない！
([デバイスの書き戻し]という欄です)

初めて実行するときには少し焦るのですが、そこは慌てずに一度ウィザードを完了させてしまい、その後PowerShellコマンドレットから以下のコマンドレットを実行してください。

Install-WindowsFeature –Name AD-DOMAIN-Services –IncludeManagementTools

Import-module ‘c:\Program Files\Microsoft Azure Active Directory Connect\Adprep\AdSyncPrep.psm1’

Initialize-ADSyncDeviceWriteBack –domainname <domain.com> –AdConnectorAccount <ドメイン管理者のUPN>

実行したら、デスクトップに作成されるAAD Connectのアイコンを実行して、ウィザードを起動し、追加のタスクから[同期オプションのカスタマイズ]を選択して、

ウィザードに沿って進めていくと、

ご覧のとおり、[デバイスの書き戻し]にチェックがつけられるようになります。

これから先、DirSyncからAAD Connectへの移行案件が出てくることが予想されますが、そのときに慌てないように今からAAD Connectについて、しっかり準備しておきたいものですね。

皆さんこんにちは。国井です。

昨年、ご質問いただいていた内容ですっかりお答えが滞っていたものがありました。
2016年最初の(技術的な)投稿は、ADFSサーバーの多要素認証に関するご質問をいただいておりましたので、そちらに回答していこうと思います。

前提

ADFSサーバーによる多要素認証について知りたい方は
ADFS+Office365でブラウザーアクセスのみ多要素認証を設定 にて
過去に紹介しておりますので、こちらをご覧ください。

Q1. 証明書利用者信頼ごとに多要素認証を設定したい

この質問の意図は、Office365のシングルサインオンのときには多要素認証を設定したいけど、ADFSサーバーのデバイス登録時には多要素認証を使いたくない、というところです。

答えは簡単です。
ADFS管理ツールの[認証ポリシー]-[証明書利用者信頼ごと]を開けば、
証明書利用者信頼別に多要素認証の設定ができます。

Q2. Office365にブラウザーからアクセスする場合のみ多要素認証を設定したい

前提のところで紹介した投稿でも書きましたが、ADFSサーバーの多要素認証は
要求規則言語を使って詳細な条件設定ができます。
しかし、条件を自分で指定するためには、「Office365にブラウザーからアクセスする場合、どのようなアクセスになるのか？」という特徴を知らなければなりません。以前の投稿では

社内ネットワークからブラウザーを使ってアクセス：/adfs/ls/wia

インターネットからブラウザーを使ってアクセス：/adfs/ls/

というURLを取るので、このことを理解したうえで条件を書けばよいとお話ししました。
では、iOSのSafariからアクセスした場合などはどうなるでしょうか？
結論から言うと、ブラウザーアクセスである限り、
OS種類を問わず、/adfs/ls/または/adfs/ls/wiaになります。
(ただし、iOSやAndroidだと社内ネットワークからのアクセスでも
Windows統合認証にはならないので、/adfs/ls/wiaは使わないと思います。)

そのことを事前に調べたいというときはADFSの監査ログを使って調べるという方法があります。実際にiOSのSafariからOutlook on the Webのサイトにアクセスしたときのログがこちら。

x-ms-endpoint-absolute-pathの欄を見ると、/adfs/ls/になっていることがわかります。補足ですが、OWA for iPhoneからのアクセスも結果的にはブラウザーアクセスですから
x-ms-endpoint-absolute-pathは/adfs/ls/になります。

ADFSの監査ログについてはMVP渡辺さんのブログが役立ちますので、
そちらを参考にしていただければと思いますし、
ログの見かたやアクセス制御に必要な情報収集の仕方、トラブルシューティングなどについてはトレーニングの中でも扱っておりますので、ご興味がありましたらぜひ。

今日はここまでにしましょう。
次回の投稿をお楽しみに。

皆さんこんにちは。国井です。

Azure AD (Office 365) との間でディレクトリ同期やシングルサインオンの設定を行うために使用する Azure AD Connect (AAD Connect) ですが、1回できれいにインストールできない場合があります。

例えば、こんな感じ。

本当だったら、エラー画面でも確認できるとおり、ログが生成されるので、ログを見ながらトラブルシューティングしていきます。

ですが、、

ここから先は私の完全な主観ですが、
一度、Azure AD Connectアンインストール→Azure AD Connect再インストール、という操作を行っていただくと、1回目のインストールと2回目のインストールは同じ操作なのに、2回目は成功するってことがよくあるんですよね。。
(ちなみに、[再試行]でインストールが成功したことは一度もないです。どういうときに役立つのかな？)

あと、特にAzure仮想マシン上で実行すると、この手のトラブルは多い気がします。

なので、もしAzure AD Connectでインストール失敗することがあったら、詳細なトラブルシューティングをするよりも、まずは再インストールを試してみたほうが手っ取り早いかもしれません。

実際、前述のエラー画面では、ログを見てみると

ADFSをインストールしようとしていて、ADFSサーバーのインストール後にできるはずのレジストリキーがないことが原因でAzure AD Connectが終了してしまっていたりするので、「それって単純にタイムアウトしてしまっただけ？」と思うのです。

そんなわけで、Azure AD Connectアンインストールしたのち、Azure AD Connect再インストールし、ウィザードを実行。

すると、2回目もエラーで終了。
ログを見ると、1回目と同じく、インストール後にできるはずのレジストリキーがないことが原因でAzure AD Connectが終了しています。しかし、1回目と異なるのはADFSサーバーのインストールが完了(フェデレーション構成は実行されていないけど)し、ログで指摘していたレジストリキーが後からできていたこと。
(ログで指摘していたレジストリ項目はHKLM\Software\Microsoft\ADFSでした。)

だったら、もう一度Azure AD Connectアンインストール→Azure AD Connect再インストールを実行してみたら、どうなるだろう？ということで、もう一度、Azure AD Connectアンインストールしたのち、Azure AD Connect再インストールし、ウィザードを実行。

すると、3度目にして、ついにAzure AD Connectによるディレクトリ同期ツールとADFSサーバーのインストールが完了しました。

こんな感じで、Azure AD Connectのインストールは、どういうわけか、複数回のインストールによって、インストールがうまくいくことが多いのです。(注：私の主観です)
そのため、Azure AD Connectによって、ADFSサーバーを含めたシングルサインオン環境の構築ができるようになりましたが、今まで通り、ADFSサーバーとWebアプリケーションプロキシを手動で登録する方法を使ったほうが適切なケースもあるように思います。

皆さんこんにちは。国井です。

Azure AD Connectを実行した際に起こるトラブルについて、前回投稿しましたが、
こんなトラブルもありましたよ、というのを備忘録として載せておきます。

Azure AD Connectでは、ディレクトリ同期ツールのインストールだけでなく、
ADFSサーバーやWebアプリケーションプロキシのインストールも同時に行うことができます。
その際、ウィザードの中でADFSサーバーの名前を指定しますが、なぜかサーバーへの接続ができないのです。

この場合、ADFSサーバーとなるコンピューターで

Enable-PSRemoting –Force

を実行してあげることで、Azure AD Connectでのサーバー登録ができるようになりました。

おわり

皆さんこんにちは。国井です。

突然ですけど、Azure AD Premiumで提供されている、パスワードリセットライトバック機能って便利ですよね。

外出先にいるユーザーがパスワードを忘れたときに、クラウド上からパスワードをリセットして新しいパスワードに設定し、さらにはディレクトリ同期でオンプレミスのActive Directoryのパスワードまでリセットしてくれるという優れものです。

しかし、ADFSサーバーを利用してSSO環境を構築している場合って、
パスワードリセットするときの下の画面って、ユーザー名を入力すると、勝手に画面推移して、

ADFSサーバーの認証画面に移動してしまうので、パスワードリセットするときのリンクはどこ？ってことになります。
↓こんな感じ

そんな時はADFSサーバーのサインインページをカスタマイズして、[アカウントにアクセスできない場合]リンクを追加しましょう。
[アカウントにアクセスできない場合]リンクをクリックするとアクセスする先となるURLは
https://passwordreset.microsoftonline.com/
なので、このURLリンクを持つ注釈をWebページに追加してあげればいいのです。

設定方法は、、と書こうと思ったら、Active Directory Team Blogに掲載されていたので、参考にしてみましょう。
最初に、ADFSサーバーのサインインページ群がDefaultという名前のプロファイルで作成されているので、
これをコピーして新しいプロファイルを作成します。

New-ADFSWebTheme -Name PasswordReset -SourceName default

Export-ADFSWebTheme -Name PasswordReset -DirectoryPath C:\Theme

ここまでの操作でC:\Themeフォルダーにプロファイルが保存されました。
(C:\Themeフォルダーは先に作成しておいてくださいね)

続いて、C:\Theme\script\onload.jsファイルをメモ帳で開き、最終行から
Active Directory Team Blogの
Step 2: Tweak onload.js to add the linkに掲載されいているスクリプトをそのままコピーしましょう。
コピーできたら、上書き保存。

後は、カスタマイズしたファイルを含むプロファイルをADFSサーバーに適用するだけです。

Set-AdfsWebTheme -TargetName PasswordReset -AdditionalFileResource @{Uri=’/adfs/portal/script/onload.js’;path=”c:\Theme\script\onload.js”}

Set-AdfsWebConfig -ActiveThemeName PasswordReset

これで完成です。
ADFSサーバーのサインインページにアクセスすると、ご覧のとおり。

リンクをクリックすると、ちゃんとパスワードリセットのページにリダイレクトされます。

ここまでのところでお気づきの方もいらしたかと思いますが、
(Office365のSSOの場合)ADFSサーバーのサインインページが表示されるのは、(基本的に)Webアプリケーションプロキシを経由するときだけです。つまり、ADFSサーバーでサインインページのカスタマイズを行えば、その設定はWebアプリケーションプロキシにも反映されるということです。

では次に、せっかくだから表示も「Can’t access your account?」ではなく、[アカウントにアクセスできない場合]にしましょう。
設定は、onload.jsファイルに追加した内容からCan’t access your account?の文字列を[アカウントにアクセスできない場合]に置き換えるだけです。そうすれば、ご覧のように日本語に切り替わります。

このときに気をつけたいのは、onload.jsファイルを保存するときに、名前を付けて保存でUTF-8形式で保存することです。単なる上書き保存してしまうと、ご覧のように文字化けしますので、ご注意ください。

皆さんこんにちは。国井です。

今日は2016年4月に開催されたOffice365認証ベストプラクティスコースのフォローアップの内容です。
コースの中で、ADFSで使われるクレームルールについて詳しく知りたいというご意見をいただきました。ADFSサーバーを利用して、Office365のシングルサインオン環境を構築しても、トークンの中に含まれるクレームの中身が見えるわけではありません。

そのため、もしクレームの中身を見たいということであれば、私がいつもお勧めしているのは
Windows Identity Foundation SDK 3.5の中に含まれているサンプルアプリケーションを利用することです。

実装方法は、、と説明しようと思ったら、マイクロソフトさんのWebサイトで紹介していたので、ご覧いただくことをお勧めします。

Windows Server 2012 R2 の AD FS 用のラボ環境をセットアップする
https://technet.microsoft.com/ja-jp/library/dn280939.aspx

既にOffice365のシングルサインオン環境が構築されているのであれば、
上記Webサイトの「手順 3:Web サーバー (WebServ1) とサンプルの要求ベースのアプリケーションを構成する」の部分をご覧いただき、手順に沿って進めていただければサンプルアプリケーションを実装できます。
ここでは、Webサイトで紹介している手順のうち、ポイントとなるところをいくつか紹介しておきます。

ポイント1：ADFSサーバーにサンプルアプリケーションをインストールしない

現行のバージョンのADFSはIISを使いません。そのため、ADFSサーバーにIISをインストールし、SSLサイトを構築すると、443番ポートがADFSとIISの2つのアプリケーションから利用することになってしまい、正しく動作しない可能性があります。そのため、ADFSサーバーではないサーバーを別途用意していただくのが賢明でしょう。(ちなみに私の環境はテスト環境なので、ドメインコントローラーにIISをインストールして動作させました)

ポイント2：ユーザープロファイルの読み込みを有効にしておく

IISの設定で、アプリケーションプールの詳細設定を開き、[ユーザープロファイルの読み込み]をTrueにしておきます。私の環境では、この設定を行わない場合、うまく動作しませんでした。

ポイント3：URLの指定は正確に

フェデレーションユーティリティを実行するとき、証明書利用者信頼を設定するとき、それぞれで指定するURLを厳密に見ています。例えば、https://test/claimappとhttps://test/claimapp/は別々のURLとして認識しますので、注意深く設定してください。

以上のポイントを踏まえて、サンプルアプリケーションを実装すれば、ADFSサーバーから発行されたトークン内のクレームがサンプルアプリケーションを通じて確認できるようになります。

こちらは証明書利用者信頼で、クレームを何も設定しなかった場合

こちらは証明書利用者信頼のクレームルールで、Active DirectoryのUPN属性をmailaddressクレームとして設定した場合

ご覧のようにmailaddressクレームにUPNの値「administrator@example.com」と入っていることが分かりますね。

このように、サンプルアプリケーションをADFSサーバーに実装しておけば、クレームルールを設定した時に、どのような結果が得られるのか視覚化できるので、おすすめです。

最後にポイントをもう一つだけ。
トークンは一度取得すると、ブラウザーを終了しない限り、同じトークンを使い続けます。
そのため、証明書利用者信頼でクレームルールの設定を変更したときは、必ずブラウザーを再起動して結果を確認してください。

■追記
Azure ADから発行されたトークンに含まれるクレームの中身を見たい場合は
ブチザッキさんの「Azure Websites の認証/承認機能」や
私の過去の投稿「Azure ADアカウントを利用したADFSのクレームベース認可」を参考にしていただくとよいと思います。

■5月27日追記
Webページがエラーになる場合、IISの設定で、アプリケーションプールの詳細設定を開き、[ID] で指定するアカウントを ApplicationPoolIdentity からNetworkServiceに変更すると動作します。