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

先日、ADFSのトレーニングにご参加いただいた方とお話をさせていただく中で、
「Office 365のためにADFSを利用する方と、
それ以外のサービスでADFSを利用する方では、
ADFSに対する意識が全く異なる」
という意見をいただきました。

たしかに、Office 365のためにADFSを利用する場合には、
Powershellのコマンドレットをいくつか実行すれば、
必要な設定はすべて自動的に行ってくれるので、
それ以上のことを知らなくても、何とかなってしまいますが、
Google Appsと組み合わせたい、Salesforceと組み合わせたい、
などとなると、そうはいきません。

そのため、前述のトレーニングでも、様々なサービスと組み合わせて利用できるよう、ADFSの仕組みから細かく解説をさせていただいているのですが、それでもすべてをお伝えできないのがトラブルシューティングです。

トラブル事例として起こりうるものは実際に経験してみないと
なかなかお伝えできないですし、教科書的なものだけを教わっても、
実際に役に立たなければ意味がありません。

ということで、前置きが長くなりましたが、
今日はトラブルシューティング事例をひとつご紹介します。

■ ■ ■

ADFSでは様々な種類の証明書を利用しますが、
中でもトークン署名証明書は1年の有効期限が設定されており、
１年経つと証明書自体が新しいものに置き換わってしまい、
通信できなくなるという事例があります。
そのため、トークン署名証明書等で使われる自己署名証明書は
デフォルトの証明書をそのまま使うのではなく、
最初から長い期間を設定しておく運用を実装されるケースが多いです。
(このあたりの詳細はMVP渡辺さんのADFSの自己証明書の期間延長を参考にされるとよいでしょう)
そして、実際に証明書の有効期間を10年に設定し、証明書を入れ替えたものが
以下の画面になります。

Office 365での運用ですと、フェデレーションメタデータを更新すれば
完了ですが、ASP.NET + WIFで作られたWebアプリケーションだと、
以下のようなエラーが発生します。(ID4175 IssuerNameRegistryというエラーです)

なぜ、このようなエラーになるかというと、
WIFのWebアプリケーションの場合、Web.Configファイルの中に
トークン署名証明書のThumbPrintを決め打ちで入れているからなのです。

そのため、Web.Configファイルをメモ帳などのエディターで開き、

あらかじめ、Get-AdfsCertificateコマンドレットで調べたトークン署名証明書のThumbPrintに置き換えれば、出来上がり。

これで、ADFSによるトークン発行とWebアプリケーションへのアクセスが正常に動作するようになります。

皆さん、こんにちは。国井です。
前回、Azure Active Directory 評価ガイドのときにお伝えしていなかったのですが、
私が執筆協力させていただきました、Microsoft Intune評価ガイドも公開されました。

■EMS関連ドキュメント
https://technet.microsoft.com/ja-jp/cloud/dn864741#sec02

上記リンクからアクセスできるページの
「Microsoft Intune評価ガイド」からアクセスできます。

Microsoft Intune は Windows Intune から名称が変更になってから、
モバイル向け(特にiOS)の機能が強化されて、企業でモバイルデバイス管理を
行うために必要な機能がだいぶ揃ったなという印象を私自身持っています。

■　■　■

参考までに、私が好きな機能は「会社のアプリ」という概念です。
Microsoft Intuneから配布されたiOSアプリは、たとえAppStoreで提供されているものであっても、
AppStoreから直接インストールした場合と、
Intune経由でインストールした場合では、
別々のアプリの扱いになります。

Intune経由でインストールしたアプリは「会社のアプリ」となり、
会社のアプリで扱われるコンテンツは、他のアプリへのデータ持ち出しが制限されます。
また、会社のアプリは起動時にPINやパスワードを入力することで、限定されたユーザーだけが利用できるようになるなどのセキュリティが実装されています。

そうした機能を評価ガイドの中で、ひととおり解説しているので、
ぜひご覧いただければと思います。

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

前回の投稿で、Microsoft Intune評価ガイドの話をさせていただきましたが、
Microsoft Intuneは単体で使う方法と、
System Center Configuration Manager (SCCM) を使う方法があります。

「SCCMを利用することによって、組織のデバイスの管理対象を
Windows, iOS, Androidだけでなく、
LinuxやMacOSまで広げることができますし、
デスクトップ系OSの管理機能はIntuneよりも多くのことができますよ」

こんなセールストークを聞いたことがある人もいるかと思います。
しかし、一方でSCCMの情報は日本語化されたものが少なく、
一部のSIerさんからは、SCCMのエンジニアが不足している、
なんて話を聞くぐらい、SCCMを利用するために必要なリソースが少ないのが現状です。

SCCMが必要になった場合、SCCMに明るいエンジニアをどこかから雇うのもひとつの方法ですが、トレーニングを活用して、低コストにSCCMに対応できるようにしてみてはいかがでしょうか？

というわけで、マイクロソフト オフィシャル カリキュラム(MOC)の一環として、
クリエ・イルミネートさんで提供するSCCM 2012 R2のコースに、
2015年6月から私が登壇させていただくことになりました。

■#MSU10747
Administering System Center 2012 Configuration Manager(R2)
http://www.crie-illuminate.jp/Pages/MSU10747.aspx

2015年5月28日追記
2015年6月以降、SCCMトレーニングはグローバルナレッジネットワークさんでの開催に切り替わりました。
私自身は引き続き登壇させていただく予定ですし、これまでよりも開催を増やしていく予定ですので、どうぞよろしくお願いいたします。

■#MSU10747
Administering System Center 2012 Configuration Manager(R2)
https://www.globalknowledge.co.jp/reference/course_details.aspx?code=MSC0542V

コースでは、5日間かけて、SCCMの持つ膨大な機能をひとつずつ丁寧に見ていくことはもちろんのこと、運用管理やトラブルシューティング(←これ、大事なポイント)もご紹介していきます。

SCCMについては私自身、マイクロソフトさん提供の評価ガイドを執筆協力させていただく形で、これまでアウトプットを出してまいりましたが、
ページ数の制約などにより、評価ガイドの中では書けなかったことなども
ご紹介させていただく予定ですので、ご興味がありましたら、ぜひ参加してみてください。

最後に、大事なポイントをひとつ。
このコースは、マイクロソフト オフィシャル カリキュラムのコースなので、
マイクロソフトのソフトウェア アシュアランス(SA)のライセンスをお持ちの会社さんは
SAの特典を利用してトレーニングを受講することができます！
http://www.microsoft.com/ja-jp/licensing/software-assurance/by-benefits.aspx#tab=2

コストを抑えてトレーニングを受講できますので、合わせて検討してみてください。

それでは、クラスルームでお待ちしています！

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

このブログでは、これまでにAzure ADのデバイス登録サービスとADFSのデバイス認証機能について紹介しましたが、Azure ADのデバイス登録サービスへのデバイス登録の方法は、これまでに紹介した方法以外にMicrosoft Intuneから登録する方法があります。

登録方法は簡単。
単純にiOSやAndroidなどのモバイルデバイスをMicrosoft Intuneに登録するだけです。
登録方法についてはMicrosoft Intune評価ガイドを見ていただくとして、
ここでは、登録結果を見てみたいと思います。

Microsoft Intuneからモバイルデバイスを登録したのち、
Azure管理ポータルサイトからAzure ADのユーザー画面にアクセスし、デバイスタブをクリックすると次のような画面が表示されます。

ユーザーが利用するデバイスが登録されていることが確認できますね。
ここまでの情報がAzure ADに登録されると、ディレクトリ同期によってActive Directoryに
デバイス情報が書きこまれます。

実際に書きこまれるデバイス オブジェクトの属性はご覧のように、
Active DirectoryユーザーとコンピューターのRegisteredDevicesコンテナーから確認できます。

Azure ADのデバイス登録機能で登録したデバイスと同じような情報が登録されることがわかります。

■　■　■

もう1回Azure管理ポータルの画面を見てみましょう。

これまでに紹介したデバイス登録と違うところは、属性として[信頼レベル]というのが追加されています(たしか、ADFS/Azure ADのデバイス登録ではなかったかと)。[信頼レベル]はMicrosoft Intuneのコンプライアンスポリシーに準拠しているかを表しているもので、たとえば、複雑なパスワードを設定しているか？など、コンプライアンスポリシーで設定した条件に合致している場合には[信頼レベル]が「適合」となります。
本当だったら、この属性がActive Directoryに同期され、この情報に基づいてADFSのデバイス認証を設定できれば、一番ありがたいのですが、私が確認した限りでは同期されないようです。このあたりは今後に期待ですね。

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

先日、米国シカゴでMicrosoft Ignite 2015というカンファレンスが開催され、私も参加してまいりました。
(帰国後に体調を崩してしまい、投稿が今になってしまいました)

私自身はADFSやAzure AD、そしてAzure ADを含むEnterprise Mobility Suite(EMS)を中心としたセッションを色々と見てまいりました。
セッションはもちろんのこと、スピーカーの方々とのディスカッションを通じて、色々な知識や情報を得ることができ、とても有意義な時間を過ごすことができました。
得た情報は既に私が登壇するセミナーの中でも還元させていただいておりますが、今日はセミナーにご参加のお客様から、よくいただくご質問にお答えするような形で
いくつかのトピックについての私なりの考え、そして将来的な展望を考えてみたいと思います。

今回のトピックはこちら。

会社支給のデバイスだけリソースにアクセスできるよう、デバイス認証を実装したい

これは色々な方から、よくいただく質問です。
現地で、何人かの方とディスカッションをさせていただきましたが、
人によって考え方がまちまちで、決定打がまだないのかな？
(もしくは出すつもりがないのかな？)というのが私の印象です。

マイクロソフトのテクノロジーで実装されているデバイス認証の機能は

・デバイス登録 (DRS)
・デバイス認証

の2つから構成されています。
そして、デバイス登録機能を使って事前に登録されたデバイスからのみ
アクセスを許可するようなアクセス制御を行うのがデバイス認証の機能です。

一見すると、この機能によって私たちの求める要件を満たすように思うのですが、
デバイス登録する時点で、アクセス制御ができていなければ、
どんなデバイスでも登録できてしまい、そしてデバイス認証もできてしまいます。

そのため、デバイス登録をどうやって制御し、会社支給のデバイスだけが登録できるようにするか？がデバイス登録機能のキモとなります。

現時点で、Microsoft Igniteの中で提供されている情報をまとめると、次の3つの方法が有力な方法になると考えられます。

①ADFSのデバイス登録機能を利用し、デバイス登録のアクセス制御を行う
デバイス登録機能には、ADFSのDRSとAzure ADのDRSがあり、
このうちADFSのDRSを利用した場合、証明書利用者信頼に登録されたDRSから
発行承認規則を設定することで、特定の条件を満たすユーザー/デバイスだけがデバイス登録できます。

しかし、この方法での課題は、発行承認規則に設定可能な規則が基本的に(デバイスではなく)ユーザーの情報に基づいてしか規則を設定できない点です。ユーザーの属性をベースにアクセス規則が設定できれば、それで十分という組織もあるでしょうし、いずれにしても組織の要件によって課題と感じるかどうかが決まるでしょう。

②Intuneのデバイス登録機能を利用し、Intuneに登録されたデバイスのみアクセスを許可する
Microsoft Intuneで使用するAzure ADテナントがAzureテナントに関連付けされている場合、
Intuneに登録されたデバイスは自動的にAzure ADにもデバイス登録されます。
ADFSやAzure ADのDRSを無効にしても、Intune経由でのデバイス登録はできるので、
Intuneに登録されたデバイスだけがデバイス認証を許可するようになります。

しかし、この方法の問題点は、Intune にデバイス登録するときの制限があまり柔軟ではない点です。Intuneではデバイス登録するときにユーザーアカウントを指定して登録しますが、そのユーザーアカウントに対して、最大で登録できるデバイス数の上限を設けることができるので、最大登録数を1にして、会社支給のデバイスを登録すれば、会社支給のデバイスだけがデバイス登録されます。
(でも、会社支給のデバイスを登録する前に個人持ちのデバイスを登録されてしまったら、
どうなるのですか？と質問されると、答えに窮するのですよね。。)

③特定のデバイスだけが登録されるように制限することをあきらめ、登録されているデバイスをきちんとウォッチする
登録されたデバイスは、Azure ADのプロパティ画面やActive DirectoryユーザーとコンピューターのRegistered Devicesコンテナーなどから確認できるので、定期的に登録されたデバイスを確認し、不適切なデバイスが登録されていないか確認するという方法に切り替えて運用するという考え方です。

Windows 10が登場すれば、デバイス登録の機能も変わってくることが考えられるので、
今後の情報もウォッチしながら、デバイス登録機能のベストプラクティスを探っていきたいですね。
(ここに書いてある方法以外の方法・アイデアなどありましたら、気軽にご連絡ください)

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

今回も、米国シカゴで開催されたMicrosoft Ignite 2015というカンファレンスから
マイクロソフトのID管理技術について、方向性を見てみたいと思います。
(上の写真はカンファレンスで紹介されたスライドからの1枚です)
御社の今後のID管理技術の実装をする際の参考にしてみてください。
今日のトピックはこちら。

Azure ADがActive DirectoryやADFSの機能を取り込むので、将来的にオンプレミスのActive DirectoryやADFSは要らなくなるのでは？

これも色々な方から、よくいただく質問です。
私が開発しているわけではないので、将来がどうなるかはわかりませんが、
Microsoft Igniteの中で提供されている情報をまとめると、

「将来はわからないけど、今の時点ではActive DirectoryやADFSがAzure ADにとって代わることはない」

というのが答えです。
では、その理由を見てみましょう。

①オンプレミスのアプリを簡単にクラウドへ移行することはできない
今までオンプレミスで稼働させてきたアプリケーションをクラウドへ移行するようなトレンドがありますが、実際にアプリケーションをクラウドに移行することって簡単でしょうか？実際に移行しようと思っても、現時点では断念してしまうことも多いのが実情ではないかと思います。

技術的にクラウドへの移行が可能か？

ということに加えて、会社のセキュリティポリシー的にクラウドへ移行してもよいものか？
など、技術的な部分以外で移行を妨げる要素が色々と思い浮かぶことでしょう。
そう考えると、クラウドが登場しても一定部分はオンプレミスに残すこともあるでしょうし、
一部でもアプリケーションがオンプレミスに残っている限りはActive Directoryを削除することはできない、というのが1つ目の理由です。
(Windows Server 2016でもActive Directoryは継続されますし、
セキュリティ面での新機能がIgniteカンファレンスの中ではクローズアップされていました)

②Windows Server 2016 でもADFSに対する投資が行われているから
今度は技術的なサイドからのアプローチです。
今度新しく登場するWindows Server 2016では、ADFSに対する新機能の実装は予定されています。(このあたりはMVPふじえさんの投稿が役に立つと思います。)
この点だけ、とってみてもADFSは今後も継続して使ってもらおうという意思が感じられます。そして付け加えるならば、ADFSはHybrid IdPを実現するための機能強化に絞ってきていることがわかります。

Hybrid IdPとは、オンプレミスとクラウドのID基盤を連携させて運用する技術のことで、
オンプレミスではActive Directory+ADFS、クラウドではAzure ADをそれぞれ利用して
オンプレミスとクラウドのID基盤を連携させ、シングルサインオンを実装しようというものです。

このように、クラウドだけにすべてのリソースを傾けて、みんなに無理矢理クラウドシフトさせるようなことを強制するのではなく、お使いいただいている自社の環境に合わせて、クラウドのみ、もしくはオンプレミス＋クラウドの構成のいずれかが選択できるようなID基盤の構築方法を今後も残していくのだな、ということがセッションの端々から確認できました。

③デバイス認証はADFSを使わないと実現できないから
今度はもうちょっと各論に入っていきます。
現状、Azure ADで提供されているデバイス登録サービス(DRS)はデバイスを登録できるけれど、登録されたデバイスを使っているときだけアクセスを許可する「デバイス認証」はオンプレミスのADFSを使わなければなりません。
しかし、この問題はWindows 10のデバイス登録機能(Workplace Join)によって解決されるようです。この件については私もアウトラインしかわからないので、詳細は追ってご紹介しますが、少なくとも「ADFSがないとデバイス認証はできない」というのがオンプレミスのサーバーを残さなければならない理由になることは近い将来なくなりそうです。

4．グループポリシーを提供できないから
オンプレミスのActive Directoryにあって、クラウドのAzure ADにない機能として「グループポリシー」があります。
Windows 10でAzure ADにデバイス登録する機能が実装される予定であり、その機能をもって、クラウドに「ドメイン参加」できるようになると謳うメディアもありますが、それでもActive Directoryにあるグループポリシーと全く同じ機能が提供されるわけではありません。今までグループポリシーを利用して組織のデバイス管理を行ってきた経緯を考えると、クラウドシフトするために、グループポリシーを捨てるというのは簡単にできない決断だと思います。

いかがでしたでしょうか？
クラウドに移行すれば、Active Directoryは要らない、オワコンだ、などとする乱暴な論調が目立ちますが、
基本的にオンプレミスにサーバーリソースやクライアントコンピューターが残る限り、
(どのくらい先かはわかりませんが)少なくとも近い将来ではActive Directoryが要らなくなることはないようですね。
今後のアーキテクチャの決定の参考になれば幸いです。

皆さんこんにちは。国井です。
このブログでも多く取り扱っているテクノロジーを提供しているマイクロソフトさんでは、
Microsoft Virtual Academyというe-Learningを提供しており、
無料で様々なコースを提供しています。(しかも貴重な資料までダウンロード可能)

色々なコースがあるので、迷うのですが、
私のお勧めコースは次の2つです。

■クラウド時代の Active Directory 次の一手シリーズ
Active Directoryを利用した管理を行っている会社さんで
今あるActive Directoryをベースに、どのようにクラウドへ
システム拡張を行っていくべきか？という悩みを持っている方は多いと思います。
そんな疑問に答えるような形で、色々なテクノロジーを紹介してくれます。

本ブログでもおなじみのADFSやAzure ADなどのキーワードを絡めた
解説が見られるので、ご興味のある方はぜひ。

■　■　■

■Microsoft Azure インフラストラクチャ ソリューションの実装
Microsoft Azureの仮想マシンを利用したインフラ環境の構築から
Webサイトの構築まで、Microsoft Azureの具体的な利用方法が紹介されています。
Azureって、サービスがいっぱいありすぎて、一体何ができるのか、わかりにくい
という話はよく聞きますが、このコースではそのあたりがすっきりと整理されているので、
入門編として適切ではないかと思います。

また、ID連携の分野でいうと、ADFSサーバーをAzure仮想マシンで
実装するという使い方をするケースも多いので、ADFSをこれから勉強したい
という方にもおすすめです。

このブログ内の内容と共に、みなさんの学習にお役立てください。

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

突然ですが、
「会社の中で、特定のデバイスからのみ社内のアプリケーションへアクセスを許可したい場合、どのような方法で実現しますか？」
という質問を受けた場合、人によって様々な回答が出てくると思いますが、いずれにしても、ぱっと回答を出せると思います。

では、「特定のデバイスからのみクラウドのアプリへのアクセスを許可したい場合、どのような方法で実現しますか？」
と言われたら、いかがですか？少し考えてしまうと思います。

オンプレミスからクラウドへのシフトが起きている中で、私たちが直面している問題のひとつとして、Active Directoryドメインの外にあるリソースへのアクセス制御をどうやって実現するか？というのがあります。

特定のモバイルデバイスだけにクラウドのサービスを利用させる方法については
このブログの中でも、ADFSやAzure ADを使ったデバイス認証による実現方法を
紹介してきましたし、このブログの中でも紹介させていただいた、
クラウド時代の Active Directory 次の一手シリーズの中でも実現方法のひとつを紹介しています。(以下の資料はクラウド時代のActive Directory 次の一手シリーズより。資料は上記サイトよりダウンロード可能です。)

一方、最近ではMicrosoft Intuneを利用して、会社のポリシーを定義し、
ポリシーに準拠するデバイスだけがExchange ActiveSyncの接続を許可するという接続制限の方法などもあります。
(これについてはMicrosoft Intune評価ガイドに書いてありますので、
そちらを参考にしてください。)

こうしたモバイルデバイスに対する適切な接続だけを許可する方法が増えている中で、
今度はOffice365のモバイルデバイス管理(MDM)機能というのが登場しましたので、
少し使ってみたいと思います。

Office365 MDM機能は、Exchange ActiveSyncに接続するモバイルデバイスに対して、
あらかじめOffice365で設定した条件を満たすデバイスだけが接続できるように
接続制御するもので、Microsoft Intuneで提供する接続制御機能(条件付きアクセス機能)の
簡易版という位置づけのようです。

実際に設定をしながら、その特徴を確認してみます。

設定1 MDMの有効化

Office365でMDM機能を有効化します。
2015年5月現在では、プレビュー？の機能として提供しているので、
Office365からプレビューの機能を利用できるように設定し、MDMの機能を有効化します。
設定はOffice365管理センターの[サービス設定]-[更新]から先行リリースを有効にします。

すると、Office365管理センターの画面に[モバイルデバイス]という項目が表示されて
MDM機能の初期設定を始められます。

設定2 APN証明書の実装

APN証明書とはAppleから発行されるモバイルデバイス管理のために必要な証明書で、
iOSデバイスをMDMで管理するのであれば、最初に実装する必要があります。

設定は[モバイルデバイス]画面の[設定]から登録します。
登録自体はウィザードに沿って進めていけば完了です。
(Apple のサイトからAPN証明書の取得方法については
SCCM 2012 SP1からWindows Intuneテナントの管理でも紹介しているので
参考してください。あと、登録にはApple IDが必要です。)

また、APN証明書は1年間有効なので、期限切れにならないように
定期的に同じ手順を繰り返して証明書を再登録してください。

設定3 ポリシーの作成

続いてモバイルデバイスの接続条件をポリシーとして設定します。
設定は[モバイルデバイス]画面の[デバイスのセキュリティポリシーおよびアクセスルールの管理]からアクセスし、

Compliance Center画面のプラスボタンをクリックして、ポリシー作成を始めます。
(なぜか、ここから英語)

ポリシーの作成画面は以下のとおりです。

この画面では、パスワードポリシーの設定を定義しています。
同じような設定はExchange ActiveSyncの設定でもできますが、
JailBreakデバイスの接続制限などはExchange ActiveSyncにはないですね。
(ちなみにデフォルト設定からは[Prevent simple passwords]にチェックをつけて、
複雑なパスワードを強制するように構成してみました)

こちらはパスワード以外のデバイス設定。
クラウドバックアップのブロックや、アプリストアへのアクセス制限などがあります。

この画面では、ポリシーの適用対象を指定しています。
対象の指定はOffice365のグループです。
グループのメンバーとなるユーザーがサインインしたときに
ポリシーに基づくアクセス制御が行われます。
(ユーザーやデバイス単位の指定はできません！)

ポリシーの作成が完了すると、Compliance Center画面に作成したポリシーが表示されます。

設定4 モバイルデバイスの設定

設定3までが完了した状態で、実際にメールボックスにアクセスすると、
条件を満たしていないデバイスの場合、接続が制限されていることを示すメールだけが受信できる状態になります。

受信したメールには、メールを受信できるようにするためのガイダンスが示されており、
そのガイダンスに従って、モバイルデバイスをOffice365に登録します。

最初に行うことはデバイスの登録です。
[1．デバイスを登録]のリンクをクリックすると、デバイス登録画面に移行します。
デバイス登録はMicrosoft Intuneポータルアプリを使うので、
インストールされていない場合、自動的にインストールを促す画面へ、
既にインストールされている場合は、Intuneポータルアプリへ、それぞれ画面推移します。
(ちなみにアプリはiOS用とAndroid用があります)
Intuneポータルアプリでサインインを済ませると、プロファイルをインストールするメッセージが表示されるので、画面の指示に従い、プロファイルのインストールを行います。
インストールが完了すると、アプリまたはブラウザー画面から登録されたデバイスの情報が確認できます。
(LSというのは私のiPhoneのデバイス名です。デフォルトだと●●のiPhoneって表示される名前ですね)

プロファイルのインストールが完了したら、続いてメールのリンクから
[2．このデバイスが準拠しているかどうかを確認するにはここを確認します]をクリックし、ポリシーへの対応状況を確認します。

ポリシーへの対応状況の確認は、リンクをクリックして行う方法のほか、

Intuneポータルアプリを起動し、デバイス名をクリックして確認することもできます。
([同期]をクリックすると準拠状況を確認します)

準拠していることが確認できたら、メールのリンクから
[3．メールをアクティブにするにはここをクリックします]をクリックします。
すると、メールボックスへのアクセス制限が解除され、Exchange ActiveSync経由での
メールボックスへのアクセスができるようになります。

この方法によってOffice365のMDMによるポリシー準拠のチェックをクリアしたデバイスは
Office365管理センターの画面に[モバイルデバイス]項目に表示されます。
万が一、不適切なデバイスが登録された場合には管理者は画面でチェックすることができますし、また、デバイスを紛失したということであれば、ワイプ機能を利用してデバイス内のデータを
消去することも可能です。

それから、Office365のMDM機能はIntuneのMDM機能の簡易版なので、
Intuneと組み合わせて利用ことはできません。

■　■　■

Office365では、Exchange ActiveSyncの機能によって、モバイルデバイスのアクセス制御を行う機能がありましたが、新しく追加されたMDM機能では、Exchange ActiveSyncが元々持っていたポリシー機能よりも多くのチェック項目で準拠状況をチェックすることができるというメリットがあります。

一方、ポリシー設定に準拠していない場合、準拠していないという報告を行うだけで、
ポリシー設定に合わせてモバイルデバイスの設定を自動的に変更してくれるような機能は備わっていません。
このような自動修復機能はMicrosoft Intuneとの組み合わせによって実現するので、
Office365のMDMを使うか、Intuneを使うか、の選択を行うときのひとつの基準になるのは
自動修復を望むか、どうか？というところになりそうです。
(もちろん、Intune自体には他にも色々な管理機能がありますので、
そのあたりも考慮して決定するとよいでしょう)

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

今日はADFSを外部公開するときに使用する、Webアプリケーションプロキシ(WAP)のトラブルシューティングについてです。
WebアプリケーションプロキシはADFSサーバーのプロキシサーバーとして動作するもので、
ADFSサーバーとWAPの間での信頼関係は欠かせません。しかし、信頼関係が何かのトラブルでなくなってしまった場合、トラブルシューティングしようにも、ユーザーインターフェイスが簡易的すぎて、どこを見ればいいか、わかりません。そこで、今回は信頼関係の再構築のケースをもとにトラブルシューティング方法を見てみます。

■　■　■

信頼関係はWebアプリケーションプロキシのインストール後に実行可能な
Webアプリケーションプロキシ構成ウィザードを使って設定します。

このとき、ADFSサーバーとWebアプリケーションプロキシで信頼関係が結ばれると
その証として、「ADFSProxyTrust」という名前の証明書が生成されます。

ADFSProxyTrust証明書は20日程度の短い有効期間の証明書で、
期限が近づく(5日前？)と自動的に証明書をロールオーバーし、有効期間を延長してくれます。

ところが、Webアプリケーションプロキシが何らかの理由でシャットダウンし、
ADFSサーバーと通信できなかった場合、証明書のロールオーバーができないため、
証明書の期限は切れ、信頼関係もなくなってしまいます。
(ちなみに、本稿を執筆している日は4月27日なのですが、4月9日で期限が切れている..)

その様子はWebアプリケーションプロキシの管理ツールである、リモートアクセス管理コンソールから確認できます。(エラーコード 0x8007250Cが特徴です)

こうなったら、信頼関係を結びなおすしかありません。ただし、上の画面でもわかるように、
信頼関係を結びなおすために使うWebアプリケーションプロキシ構成ウィザードを実行できません。

というわけで、PowerShellを使います。
Install-WebApplicationProxyコマンドレットで信頼関係を作り直しているのですが、
このコマンドレットを実行するにはCerticateThumbprintを指定する必要があります。
そのため、事前にWAPにインストールした証明書のThumbprint(拇印)を調べておいてください。

自分のコンピューターにインストールされた証明書はPowerShellから
次のコマンドで確認できます。

cd cert:\
cd LocalMachine\My
dir

実行時の様子と結果はご覧のとおり。
(ワークプレースの警告は無視してください)

すると、信頼関係は再度設定され、ADFSProxyTrust証明書は新しいものが発行され、

そして、 リモートアクセス管理コンソールは元の姿に戻ります。

もうひとつの方法として、信頼関係が失われたWAPのレジストリで
HKLM\Software\Microsoft\ADFSのproxyConfigurationStatusの値を1に設定すると
再び利用できるという技もありますが、こちらは実行すると
これまでにWebアプリケーションプロキシで設定した「公開されたWebアプリケーション」の設定が全部消えるのでご注意を(↓ご覧のとおり)。

皆さんこんにちは。国井です。
300回目の投稿となる今回は、Active DirectoryユーザーのUPNサフィックスをPowerShellから変更する方法についてです。

Office365のシングルサインオンを行う場合、Alternate Login IDを使う場合を除いて、Active Directoryユーザーのユーザープリンシパル名(UPN)を変更し、ディレクトリ同期を行う必要があります。
UPNの変更はActive Directoryドメインと信頼関係からOffice365で使用するドメイン名を登録すること、

そして、UPNの変更をユーザーごとに行う必要があります。

ただし、UPNの変更はユーザーごとに行う必要があるため、従業員規模で1000名を超えてくるようなケースでは、とんでもなく面倒な作業になります。(100ユーザー分でも十分面倒ですが。。)

そこで、PowerShellからまとめてUPNを変更するスクリプトを作成してみました。
(example.comは現在お使いのActive Directoryドメイン名、xxxxxx.jpはOffice365に登録のドメイン名に置き換えてください)

Get-ADUser –Filter {UserPrincipalName –like “*@example.com”} `
–SearchBase “DC=example,DC=com” | ForEach-Object {
$UPN = $_.UserPrincipalName.Replace(“example.com”, “xxxxxx.jp”)
Set-ADUser $_ -UserPrincipalName $UPN
}

Active Directory ドメインコントローラーから実行すれば、まとめて変更できます。
私の環境で実行してみたところ、
Get-ADUserコマンドレットを実行してユーザー一覧を出したときに、example.comとExample.comのように大文字と小文字が混在しているとReplaceメソッドが識別してくれないケースがあるので、その点だけ利用時に注意してください。

よかったら、お使いください。

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

今日は、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 (AADConnect)が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を利用したシングルサインオン環境を構築したい方はご参加いただくことをお勧めします。

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

今日はちょっとしたご報告を。
マイクロソフトさんからMicrosoft MVPという賞を2006年からいただいておりましたが、
今年もいただくことができました。
Microsoft MVPはテクノロジーの分野別に受賞するような制度になっており、
私はDirectory Servicesという分野で10年連続で賞をいただきました。

最初にMicrosoft MVPを受賞させていただいたのは、ちょうど10年前になるのですが、
そのころ、Directory Servicesのテクノロジーの中心はActive Directoryでした。

ですが、10年経過した今ではDirectory Servicesの分野で扱われるテクノロジーは

クラウドのID管理 (Azure AD) であり、
ID連携技術 (ADFS) なわけです。

もちろん今でもActive Directoryは企業の中でインフラの中でも中心的な役割であることに変わりはありませんが、ID管理のあり方はクラウドの登場と共に少しずつ変わりつつあるように思います。

これからも、このブログをはじめ、様々なセミナーやトレーニングなどを通じて、
ひとりでも多くの方に、これからのID管理の仕組みをご紹介できればと思います。

これからもお付き合いのほど、どうぞよろしくお願いいたします。

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

以前、クラウドから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で登録されたデバイスであってもデバイス認証は拒否されます。

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

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

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に参加機能を利用するときの参考になれば幸いです。

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

2015年9月12日に開催されるSystem Center User Group Japan 第13回勉強会に
「SaaSアプリを有効活用するためのAzure AD利用法」というタイトルでお話をすることになりました。

当日は、企業で様々なSaaSアプリを利用するために必要なID管理を効果的に行うためのAzure ADの活用方法とセキュアな運用を実現する方法をそれぞれ紹介する予定です。

Azure ADって何？という人から、クラウドID管理についてオーバービューから学習したい人まで気軽にご参加ください。

お申し込みはhttps://atnd.org/events/68938からどうぞ。