こんにちは、富士榮です。
久しぶりの紙媒体です。
今週頭に発売された日経ネットワーク 2016年1月号でAzure Active Directory特集を書かせていただきました。
Azure ADの存在自体をご存じない方を含めターゲットにしているため、内容的には「Azure ADとは?」などの基礎的な部分から、実際にアプリケーションとのID連携(SSO/プロビジョニング)を行う方法のウォークスルーまで、と広く浅く10ページ程度でまとめています。
尚、日経ネットワークって書店ではほとんど扱っておらず、定期購読していない場合は、以下の直販サイトから購入できますので、よろしければどうぞ。
日経ネットワーク 2016年1月号
http://ec.nikkeibp.co.jp/item/backno/NN0189.html
以下、ゲラの編集中のイメージです。
2015年12月30日水曜日
2015年12月22日火曜日
[告知]1月は「企業及びクラウドにおけるアイデンティティ管理セミナー」
こんにちは、富士榮です。
最近なんだかんだで毎月イベントに呼んで頂いていますね。
(カレンダーを見たら9月から毎月登壇してました・・・)
1月は以前からお世話になっている日本ネットワークセキュリティ協会(JNSA)のID管理ワーキンググループの創立10周年記念イベント「企業及びクラウドにおけるアイデンティティ管理セミナー」が開催されます。
(今週頭の段階ですでに定員の半分以上の申込があるので、興味のある方はお早めに!!)
申込サイト
http://www.jnsa.org/seminar/2016/0121/
以前も紹介しましたが、本ワーキンググループは2005年から活動をしており、主要な成果物として「クラウド環境におけるアイデンティティ管理ガイドライン」や「ロール管理ガイドライン」などを出版しています。
今回のセミナーでは10年の歩みを振り返りつつ、これまで作成してきた各種成果物の概要を解説しますので、かなり凝縮された濃い内容になると思います。
ちなみに私は上記アイデンティティ管理ガイドラインの中で紹介している「ID管理プロジェクトの進め方」について解説するセッションを担当しますが、他にも特権ID管理やロール管理に関するセッション、クラウドやID管理に取り組む上で避けて通れないEUデータ保護指令とどのように付き合うべきか、改正個人情報保護法とID管理に関連したセッション、本ワーキンググループが様々なベンダやコンサル、SIから構成されている特色が良く出るであろうパネルディスカッションも予定されています。
また、セミナー自体は2016年に食い込んでしまっていますが、今年2015年はActive Directoryの15周年にあたる年でもありますので、日本マイクロソフトの安納さんによるActive Directoryを振り返るセッションも予定されています。
いずれもかなり濃い内容になると思いますので、早めにお申し込みください!
最近なんだかんだで毎月イベントに呼んで頂いていますね。
(カレンダーを見たら9月から毎月登壇してました・・・)
1月は以前からお世話になっている日本ネットワークセキュリティ協会(JNSA)のID管理ワーキンググループの創立10周年記念イベント「企業及びクラウドにおけるアイデンティティ管理セミナー」が開催されます。
(今週頭の段階ですでに定員の半分以上の申込があるので、興味のある方はお早めに!!)
申込サイト
http://www.jnsa.org/seminar/2016/0121/
以前も紹介しましたが、本ワーキンググループは2005年から活動をしており、主要な成果物として「クラウド環境におけるアイデンティティ管理ガイドライン」や「ロール管理ガイドライン」などを出版しています。
今回のセミナーでは10年の歩みを振り返りつつ、これまで作成してきた各種成果物の概要を解説しますので、かなり凝縮された濃い内容になると思います。
ちなみに私は上記アイデンティティ管理ガイドラインの中で紹介している「ID管理プロジェクトの進め方」について解説するセッションを担当しますが、他にも特権ID管理やロール管理に関するセッション、クラウドやID管理に取り組む上で避けて通れないEUデータ保護指令とどのように付き合うべきか、改正個人情報保護法とID管理に関連したセッション、本ワーキンググループが様々なベンダやコンサル、SIから構成されている特色が良く出るであろうパネルディスカッションも予定されています。
また、セミナー自体は2016年に食い込んでしまっていますが、今年2015年はActive Directoryの15周年にあたる年でもありますので、日本マイクロソフトの安納さんによるActive Directoryを振り返るセッションも予定されています。
いずれもかなり濃い内容になると思いますので、早めにお申し込みください!
2015年12月21日月曜日
[Azure AD/IDaaS]Web記事連載が一息つきました
こんにちは、富士榮です。
夏から続けていた@ITへのIDaaS(Identity as a Service)関連の連載が先日終了したので、ラップアップをしてみます。
連載は以下でご覧いただけます。
全体をとおしてのテーマは「IDaaS」です。最近Azure ADはもちろん、OneLoginやPingOneなど各社のIDaaSが国内でも採用されてきているので、何故ここにきて「IDaaS」が注目されているのか?を「クラウド」、「モバイル」、「グループ&グローバル」の3つのキーワードで解説をしています。
また、第2回~第3回ではIDaaSの実装例としてAzure ADを例に何ができるのか?を「認証」、「ID管理」、「監査」の3つの側面から紹介しています。この中でAzure ADのアプリケーション連携のSSOやプロビジョニング機能、レポート機能の概要を解説しています。
最後は少し毛色を変えてWindows 10とAzure ADを組み合わせた場合を例に、IDaaSの別の一面であるデバイス管理について紹介しています。この中で、Microsoft Passportの仕組みをオンプレミスADでの統合Windows認証と対比しながら解説しています。
全体を通して、なるべく入門レベルを目指して書いているので、まず全体像を把握するための活用して頂けると幸いです。
尚、別の媒体(紙)でもAzure ADについて解説記事が近々公開される予定なので、また紹介したいと思います。
夏から続けていた@ITへのIDaaS(Identity as a Service)関連の連載が先日終了したので、ラップアップをしてみます。
連載は以下でご覧いただけます。
- 第1回 もはや企業のID管理で避けては通れない「IDaaS」とは?
- 第2回 IDaaSの実装をAzure ADで理解する(前編)
- 第3回 IDaaSの実装をAzure ADで理解する(後編)
- 最終回 Windows 10によるAzure Active Directory活用の最大化
全体をとおしてのテーマは「IDaaS」です。最近Azure ADはもちろん、OneLoginやPingOneなど各社のIDaaSが国内でも採用されてきているので、何故ここにきて「IDaaS」が注目されているのか?を「クラウド」、「モバイル」、「グループ&グローバル」の3つのキーワードで解説をしています。
また、第2回~第3回ではIDaaSの実装例としてAzure ADを例に何ができるのか?を「認証」、「ID管理」、「監査」の3つの側面から紹介しています。この中でAzure ADのアプリケーション連携のSSOやプロビジョニング機能、レポート機能の概要を解説しています。
最後は少し毛色を変えてWindows 10とAzure ADを組み合わせた場合を例に、IDaaSの別の一面であるデバイス管理について紹介しています。この中で、Microsoft Passportの仕組みをオンプレミスADでの統合Windows認証と対比しながら解説しています。
全体を通して、なるべく入門レベルを目指して書いているので、まず全体像を把握するための活用して頂けると幸いです。
尚、別の媒体(紙)でもAzure ADについて解説記事が近々公開される予定なので、また紹介したいと思います。
2015年12月11日金曜日
[Azure AD]PowerShellを使ってユーザの多要素認証設定を変更する
こんにちは、富士榮です。
Azure ADで多要素認証を使う場合、ユーザ毎に有効/無効/強制の設定を行う必要があるため非常に面倒です。(CSVで一括設定することも可能ですが、リストファイルを作成して管理コンソールからアップロードする必要があるので、ユーザが増えてくると結果確認などを考えると結構面倒です)
そういう場合のPowerShellです。
早速方法を紹介します。
手順は割愛しますが、まずはConnect-MSolServiceで全体管理者の権限を持つユーザでAzureへ接続します。
※Azure PIM(特権ID管理)をうまく使ってヘルプデスクユーザへ一時的に権限を与えてスクリプトを実行させるとセキュアで便利です。この辺りはそのうち細かく紹介したいと思います。
うまく接続できたら、早速設定をしてみます。
◆有効
以下を実行します。
管理コンソールで確認すると有効化されていることがわかります。
◆無効
同様に無効化です。
@()で空の配列をStrongAuthenticationRequirementsに渡してあげます。
管理コンソールを見ると無効化されていることがわかります。
◆強制
最後に強制です。
少しトリッキーです。$auth.StateにEnforcedをセットします。
管理コンソールで確認します。
尚、設定結果の取得ですが、上記では管理コンソールでの目視をしましたが、もちろん以下のようにGet-MsolUserを使って確認することも可能です。
Azure ADで多要素認証を使う場合、ユーザ毎に有効/無効/強制の設定を行う必要があるため非常に面倒です。(CSVで一括設定することも可能ですが、リストファイルを作成して管理コンソールからアップロードする必要があるので、ユーザが増えてくると結果確認などを考えると結構面倒です)
そういう場合のPowerShellです。
早速方法を紹介します。
手順は割愛しますが、まずはConnect-MSolServiceで全体管理者の権限を持つユーザでAzureへ接続します。
※Azure PIM(特権ID管理)をうまく使ってヘルプデスクユーザへ一時的に権限を与えてスクリプトを実行させるとセキュアで便利です。この辺りはそのうち細かく紹介したいと思います。
うまく接続できたら、早速設定をしてみます。
◆有効
以下を実行します。
PS C:\> $auth = New-Object -TypeName Microsoft.Online.Administration.StrongAuthenticationRequirement PS C:\> $auth.RelyingParty = "*" PS C:\> Set-MsolUser -UserPrincipalName mfa@xxxx.onmicrosoft.com -StrongAuthenticationRequirements @($auth)
管理コンソールで確認すると有効化されていることがわかります。
◆無効
同様に無効化です。
PS C:\> Set-MsolUser -UserPrincipalName mfa@xxxx.onmicrosoft.com -StrongAuthenticationRequirements @()
@()で空の配列をStrongAuthenticationRequirementsに渡してあげます。
管理コンソールを見ると無効化されていることがわかります。
◆強制
最後に強制です。
PS C:\> $auth = New-Object -TypeName Microsoft.Online.Administration.StrongAuthenticationRequirement PS C:\> $auth.RelyingParty = "*" PS C:\> $auth.State = "Enforced" PS C:\> Set-MsolUser -UserPrincipalName mfa@xxxx.onmicrosoft.com -StrongAuthenticationRequirements @($auth)
少しトリッキーです。$auth.StateにEnforcedをセットします。
管理コンソールで確認します。
尚、設定結果の取得ですが、上記では管理コンソールでの目視をしましたが、もちろん以下のようにGet-MsolUserを使って確認することも可能です。
PS C:\> $user = Get-MsolUser -UserPrincipalName mfa@xxxx.onmicrosoft.com PS C:\> $auth = $user.StrongAuthenticationRequirements PS C:\> $auth | fl
この辺りをうまく使ってAzure ADの管理体制を上手に運用していけるといいですね。
※本当は全体管理者権限ではなく、もう少し細かい権限がほしいところです・・・
2015年11月28日土曜日
[AD FS]Windows Server 2016 Technical Preview 4/TokenエンドポイントのBASIC認証
こんにちは、富士榮です。
先日Windows Server 2016のTechnical Preview 4が出たので、AD FSがどうなったのかを見ていきたいと思います。
まずOpenID ConnectのRP(Relying Party)を作る上で個人的に一番気になっていたTokenエンドポイントのクライアント認証を見てみました。
一般的なRPの開発ドキュメントを見ているとOAuth2.0のCode Flowを使う際、code取得後にTokenエンドポイントへのPOST時のクライアント認証はBASIC認証で実装されていることが多いですし、RFCのサンプルもそうなっているのですが、Azure Active DirectoryやAD FSのTokenエンドポイントはBASIC認証をサポートしていませんでした。
Windows Server 2016ではこのあたりが改修されることになっており、前回のTechnical Preview 3の.well-known/openid-configurationを見ると以下のようにclient_secret_basicもサポートされていることがわかります。
しかし、Technical Preview 3で実際にTokenエンドポイントでBASIC認証を使おうとすると、invalid_clientと言われてHTTP 400が返ってきてしまいました。
ということで、今回出たTechnical Preview 4ではどこまで治ったのかを見てみます。
codeを取得した後、TokenエンドポイントへのPOST時のAuthorizationヘッダにclient_idとclient_secretを":"で接続してbase64エンコードした文字列をBasicに続けて設定します。
結果、いけました!
これでこれまで他のOpenID Provider向けに作ったクライアントをAD FS用に変更する必要がなくなりましたね。
ただ、現状までAzure ADはまだclient_secret_postとprivate_key_jwtしかサポートしていないみたいです。今後に期待ですね。。
先日Windows Server 2016のTechnical Preview 4が出たので、AD FSがどうなったのかを見ていきたいと思います。
まずOpenID ConnectのRP(Relying Party)を作る上で個人的に一番気になっていたTokenエンドポイントのクライアント認証を見てみました。
一般的なRPの開発ドキュメントを見ているとOAuth2.0のCode Flowを使う際、code取得後にTokenエンドポイントへのPOST時のクライアント認証はBASIC認証で実装されていることが多いですし、RFCのサンプルもそうなっているのですが、Azure Active DirectoryやAD FSのTokenエンドポイントはBASIC認証をサポートしていませんでした。
Windows Server 2016ではこのあたりが改修されることになっており、前回のTechnical Preview 3の.well-known/openid-configurationを見ると以下のようにclient_secret_basicもサポートされていることがわかります。
"token_endpoint_auth_methods_supported":["client_secret_post","client_secret_basic","private_key_jwt","windows_client_authentication"],
しかし、Technical Preview 3で実際にTokenエンドポイントでBASIC認証を使おうとすると、invalid_clientと言われてHTTP 400が返ってきてしまいました。
ということで、今回出たTechnical Preview 4ではどこまで治ったのかを見てみます。
codeを取得した後、TokenエンドポイントへのPOST時のAuthorizationヘッダにclient_idとclient_secretを":"で接続してbase64エンコードした文字列をBasicに続けて設定します。
結果、いけました!
これでこれまで他のOpenID Provider向けに作ったクライアントをAD FS用に変更する必要がなくなりましたね。
ただ、現状までAzure ADはまだclient_secret_postとprivate_key_jwtしかサポートしていないみたいです。今後に期待ですね。。
2015年11月23日月曜日
[Windows 10]Intuneを使ったMobileデバイスの消去
こんにちは、富士榮です。
前回、前々回とWindows 10 MobileデバイスをAzure Active Directory(Azure AD)へ参加させる方法について解説をしてきました。
この際、Azure ADとMicrosoft Intuneを連携させておくと、Azure ADに登録されたデバイス情報が自動的にIntuneに同期され、ポリシーの適用やリモート・ロック、ワイプなどの管理を行うことができるようになります。
しかし実際にワイプされるところを見ることも少ないだろうなぁ、ということでChannel 9に動画をアップしておきました。
実際は結構時間がかかるんですが、勝手にデバイスがシャットダウンされ、初期化されていく姿をご覧いただけると思いますので、ぜひご覧ください。
Azure ADへのWindows 10 Mobile参加とIntuneによるリモートワイプ
https://channel9.msdn.com/Blogs/IdM-Lab-Annex-MVP-for-Directory-Services-Naohiro-Fujie/Azure-ADWindows-10-MobileIntune
前回、前々回とWindows 10 MobileデバイスをAzure Active Directory(Azure AD)へ参加させる方法について解説をしてきました。
この際、Azure ADとMicrosoft Intuneを連携させておくと、Azure ADに登録されたデバイス情報が自動的にIntuneに同期され、ポリシーの適用やリモート・ロック、ワイプなどの管理を行うことができるようになります。
しかし実際にワイプされるところを見ることも少ないだろうなぁ、ということでChannel 9に動画をアップしておきました。
実際は結構時間がかかるんですが、勝手にデバイスがシャットダウンされ、初期化されていく姿をご覧いただけると思いますので、ぜひご覧ください。
Azure ADへのWindows 10 Mobile参加とIntuneによるリモートワイプ
https://channel9.msdn.com/Blogs/IdM-Lab-Annex-MVP-for-Directory-Services-Naohiro-Fujie/Azure-ADWindows-10-MobileIntune
[Windows 10]MobileでもMicrosoft Passport~企業デバイス編(Azure AD参加)
こんにちは、富士榮です。
前回は個人所有のWindows 10 Mobileの端末に対して職場または学校のアカウント(Azure ADアカウント)を追加してMicrosoft Passportが動作するイメージを紹介しました。
今回はそもそも企業が用意したデバイスをAzure ADに直接参加させて利用・管理するシナリオです。デスクトップOSでいうところのAzure ADへの参加するシナリオに当たります。
まず、デバイスを初期化するところから始めますので、試す方はそれなりの準備をしてから試してください。
初期化をして最初のセットアップ時のアカウント設定を行います。
ここで職場のアカウントでサインインを選択します。
いろいろ説明が出てきますが、次へ進みます。
サインイン画面が出てくるので、Azure ADアカウントでログインします。
何やら設定をしているようです。
ここでPINの設定を求められます。
なぜかこのタイミングで多要素認証が求められました。
多要素認証が完了するとPINの登録です。
一応これでアカウント設定は完了です。
引き続きアプリケーションの設定が行われます。
完了をしばし待ちます。
終わった、と思ったらもう少しありました。
ようやく終わりみたいです。
ええ、Lumiaを選びましたとも、、、安かったので。
ようやくデスクトップ画面にたどり着きます。
綺麗ですね。
とりあえずEdgeを起動してアクセス・パネル(https://myapps.microsoft.com)を起動します。
当然ですが、シングルサインオンされます。
Azure ADの管理画面で見ると「AAD参加済み」デバイスとして認識されています。
もちろんIntuneでもデバイスは見えます。
種別は「企業」になっていますね。ビルドは10.0.13058なんですね。
前回も書きましたが、Windows 10ではデスクトップでもモバイルでもかなりシームレスに管理ができる様になってきています。デバイスさえそろって来れば、企業で使うには一番管理しやすいデバイスになってくるかもしれませんね。
前回は個人所有のWindows 10 Mobileの端末に対して職場または学校のアカウント(Azure ADアカウント)を追加してMicrosoft Passportが動作するイメージを紹介しました。
今回はそもそも企業が用意したデバイスをAzure ADに直接参加させて利用・管理するシナリオです。デスクトップOSでいうところのAzure ADへの参加するシナリオに当たります。
まず、デバイスを初期化するところから始めますので、試す方はそれなりの準備をしてから試してください。
初期化をして最初のセットアップ時のアカウント設定を行います。
ここで職場のアカウントでサインインを選択します。
いろいろ説明が出てきますが、次へ進みます。
サインイン画面が出てくるので、Azure ADアカウントでログインします。
何やら設定をしているようです。
ここでPINの設定を求められます。
なぜかこのタイミングで多要素認証が求められました。
多要素認証が完了するとPINの登録です。
一応これでアカウント設定は完了です。
引き続きアプリケーションの設定が行われます。
完了をしばし待ちます。
終わった、と思ったらもう少しありました。
ようやく終わりみたいです。
ええ、Lumiaを選びましたとも、、、安かったので。
ようやくデスクトップ画面にたどり着きます。
綺麗ですね。
とりあえずEdgeを起動してアクセス・パネル(https://myapps.microsoft.com)を起動します。
当然ですが、シングルサインオンされます。
Azure ADの管理画面で見ると「AAD参加済み」デバイスとして認識されています。
もちろんIntuneでもデバイスは見えます。
種別は「企業」になっていますね。ビルドは10.0.13058なんですね。
前回も書きましたが、Windows 10ではデスクトップでもモバイルでもかなりシームレスに管理ができる様になってきています。デバイスさえそろって来れば、企業で使うには一番管理しやすいデバイスになってくるかもしれませんね。
2015年11月22日日曜日
[Windows 10]MobileでもMicrosoft Passport~個人デバイス編(WorkPlace Join)
こんにちは、富士榮です。
そう言えばWindows 10 Mobileにもバージョン1511/ビルド10586が落ちてきていたので、Microsoft Passportが使えるようになっているはず、ということで試してみます。
(久しぶりに通電~充電したLumia 430のめったに無い出番です)
##今回はBYODシナリオです。最初から組織アカウントでデバイスを設定する方法は次回解説します##
とりあえず充電しつつソフトウェア更新をかけて、バージョンが1511になりました。
ということで、Azure AD(Azure Active Directorry)へ参加させてみます。
オペレーションとしてはデスクトップOSと同じく、設定~アカウント~職場のアクセスを開きます。
先日紹介したBYOD端末でのAzure AD参加と同じようなオペレーションですね。
参考)[Windows 10]TH2新機能 - BYOD(WorkPlace Join)でMicrosoft Passportを使う
http://idmlab.eidentity.jp/2015/11/windows-10th2-byodworkplace.html
この画面で「職場用または学校用のアカウントの追加と削除」をタップするとアカウント設定の画面へ遷移するため、アカウントを追加していきます。
「職場または学校アカウントを追加」をタップすると、Azure ADのログイン画面へ遷移するのでAzure ADのアカウントでログインします。
通常のログインと同様にサインインを行います。今回は多要素認証が有効なアカウントだったので、モバイルへの通知がされました。
これで設定は完了です。
早速、Edgeを立ち上げてアクセスパネル(https://myapps.microsoft.com)へアクセスしてみます。
すると、ログイン画面が一瞬みえますが、そのままアクセスパネルが表示されます。
もちろんアプリケーションへのログオンもそのままシングルサインオンされます。
うまくMicrosoft Passportが動いてくれています。
もちろんAzure ADの管理画面を見るとデバイスが登録されていることがわかります。
このようにWindows 10においてはデスクトップ用OSでもモバイル用OSでもアカウント管理の面においてはほぼ共通の実装になっていることがよくわかります。
Lumia 950も米国ではリリースされたようですし、あとはモバイルデバイスでWindows Helloを早く試してみたいところです。
そう言えばWindows 10 Mobileにもバージョン1511/ビルド10586が落ちてきていたので、Microsoft Passportが使えるようになっているはず、ということで試してみます。
(久しぶりに通電~充電したLumia 430のめったに無い出番です)
##今回はBYODシナリオです。最初から組織アカウントでデバイスを設定する方法は次回解説します##
とりあえず充電しつつソフトウェア更新をかけて、バージョンが1511になりました。
ということで、Azure AD(Azure Active Directorry)へ参加させてみます。
オペレーションとしてはデスクトップOSと同じく、設定~アカウント~職場のアクセスを開きます。
先日紹介したBYOD端末でのAzure AD参加と同じようなオペレーションですね。
参考)[Windows 10]TH2新機能 - BYOD(WorkPlace Join)でMicrosoft Passportを使う
http://idmlab.eidentity.jp/2015/11/windows-10th2-byodworkplace.html
この画面で「職場用または学校用のアカウントの追加と削除」をタップするとアカウント設定の画面へ遷移するため、アカウントを追加していきます。
「職場または学校アカウントを追加」をタップすると、Azure ADのログイン画面へ遷移するのでAzure ADのアカウントでログインします。
通常のログインと同様にサインインを行います。今回は多要素認証が有効なアカウントだったので、モバイルへの通知がされました。
これで設定は完了です。
早速、Edgeを立ち上げてアクセスパネル(https://myapps.microsoft.com)へアクセスしてみます。
すると、ログイン画面が一瞬みえますが、そのままアクセスパネルが表示されます。
もちろんアプリケーションへのログオンもそのままシングルサインオンされます。
うまくMicrosoft Passportが動いてくれています。
もちろんAzure ADの管理画面を見るとデバイスが登録されていることがわかります。
このようにWindows 10においてはデスクトップ用OSでもモバイル用OSでもアカウント管理の面においてはほぼ共通の実装になっていることがよくわかります。
Lumia 950も米国ではリリースされたようですし、あとはモバイルデバイスでWindows Helloを早く試してみたいところです。
2015年11月19日木曜日
[Windows 10]Azure ADに参加したPCへリモートデスクトップ接続する
こんにちは、富士榮です。
Windows 10がリリースされてから、Azure ADへの参加やHybrid構成など検証したいことはたくさんあるのですが、いかんせんクライアントOSなので都度手元の端末をセットアップしなおして、、というのが非常に煩雑です。
そんな時のAzure VMなのですが、Windows 10のイメージをVMで作っても接続がリモートデスクトップになるので、Azure ADへの参加するところまでは行けてもAzure AD上のユーザでどうやってログインしたら???という疑問がわいてきます。
単純にAzure AD上のユーザを入力してもログインできません。
と、いうことで、今回はちょっとした工夫をしてみます。
(Morgan Simonsen氏が検証していましたのでその方法の紹介です)
◆接続先コンピュータでの作業
流れとしては、リモート接続設定の構成変更およびAzure ADユーザで接続できるように権限設定を行っておきます。
リモートデスクトップの接続許可の「Allow connections only from computers running Remote Desktop with Network Level Authentication」のチェックを外します。
次に、「Select Users」を開いて「Authenticated Users」を追加します。
これで接続先コンピュータでの作業は終わりです。
(もちろん事前にAzure ADへの参加はしておいてください)
◆接続元コンピュータでの作業(RDPファイルの編集)
今度は接続元での作業です。
Azure VMを作成し接続するとRDPファイルがダウンロードされますので、こちらを直接編集していきます。
具体的にはメモ帳などでRDPファイルを開いて、以下の2行を追記します。
enablecredsspsupport:i:0
authentication level:i:2
編集後、保存します。
これで準備は整いました。
◆接続する
では接続するので、RDPファイルをダブルクリックで開いてみます。
すると、通常はRDPを開いた段階で認証が走るのですが、接続先コンピュータのログイン画面が表示されます。
ここまで行けば、通常のローカルコンピュータと同じでAzure ADのユーザをログインを行います。
尚、ユーザ名には「Azure AD\hogehoge@xxxx.onmicrosoft.com」という形で入力します。
※接続先コンピュータがTH2であれば、UPN(hogehoge@xxxx.onmicrosoft.com)だけでもログインできます。
無事にリモートログインできました。
ブラウザを起動してAzure AD連携しているアプリケーションにアクセスすると無事にMicrosoft Passportも動作しており、シングルサインオンできます。
ネタ元)
http://morgansimonsenblog.azurewebsites.net/2015/11/06/connecting-to-an-azure-ad-joined-machine-with-remote-desktop/
Windows 10がリリースされてから、Azure ADへの参加やHybrid構成など検証したいことはたくさんあるのですが、いかんせんクライアントOSなので都度手元の端末をセットアップしなおして、、というのが非常に煩雑です。
そんな時のAzure VMなのですが、Windows 10のイメージをVMで作っても接続がリモートデスクトップになるので、Azure ADへの参加するところまでは行けてもAzure AD上のユーザでどうやってログインしたら???という疑問がわいてきます。
単純にAzure AD上のユーザを入力してもログインできません。
と、いうことで、今回はちょっとした工夫をしてみます。
(Morgan Simonsen氏が検証していましたのでその方法の紹介です)
◆接続先コンピュータでの作業
流れとしては、リモート接続設定の構成変更およびAzure ADユーザで接続できるように権限設定を行っておきます。
リモートデスクトップの接続許可の「Allow connections only from computers running Remote Desktop with Network Level Authentication」のチェックを外します。
次に、「Select Users」を開いて「Authenticated Users」を追加します。
これで接続先コンピュータでの作業は終わりです。
(もちろん事前にAzure ADへの参加はしておいてください)
◆接続元コンピュータでの作業(RDPファイルの編集)
今度は接続元での作業です。
Azure VMを作成し接続するとRDPファイルがダウンロードされますので、こちらを直接編集していきます。
具体的にはメモ帳などでRDPファイルを開いて、以下の2行を追記します。
enablecredsspsupport:i:0
authentication level:i:2
編集後、保存します。
これで準備は整いました。
◆接続する
では接続するので、RDPファイルをダブルクリックで開いてみます。
すると、通常はRDPを開いた段階で認証が走るのですが、接続先コンピュータのログイン画面が表示されます。
ここまで行けば、通常のローカルコンピュータと同じでAzure ADのユーザをログインを行います。
尚、ユーザ名には「Azure AD\hogehoge@xxxx.onmicrosoft.com」という形で入力します。
※接続先コンピュータがTH2であれば、UPN(hogehoge@xxxx.onmicrosoft.com)だけでもログインできます。
無事にリモートログインできました。
ブラウザを起動してAzure AD連携しているアプリケーションにアクセスすると無事にMicrosoft Passportも動作しており、シングルサインオンできます。
ネタ元)
http://morgansimonsenblog.azurewebsites.net/2015/11/06/connecting-to-an-azure-ad-joined-machine-with-remote-desktop/
2015年11月18日水曜日
[Azure AD]カスタム・アプリケーション向けプロビジョニングにSCIM2.0のサポート
こんにちは、富士榮です。
IDaaSの主要機能の一つに連携しているアプリケーション向けのプロビジョニング機能がありますが、Azure Active Directory(Azure AD)もGoogle Appsやsalesforce.com、BoxなどメジャーなSaaSアプリケーション向けのプロビジョニングをサポートしてきました。
今回、アプリケーション向けのプロビジョニング機能の強化の一環としてSCIM 2.0(System for Cross-domain Identity Management)のサポートが発表されました。
Active Directory Teamのblog
Azure AD Premium now supports SCIM 2.0!
http://blogs.technet.com/b/ad/archive/2015/11/17/azure-ad-premium-now-supports-scim-2-0.aspx
このニュースを見て、標準ではプロビジョニングできないSaaSアプリケーションでもSCIMをサポートしていればID管理できる!!と思ったのですが、現状はいろいろと制限があります。。。。
(PingOneとかSCIMをサポートしている別のIDaaSへのID同期に使えるかと思ったのですが・・・)
以下が現状の制限事項として大きい点です。
1.SCIMのエンドポイントの保護をAzure ADが行っているサービスのみに対応
※Azure ADが発行したOAuth2.0 Bearerトークンを使ってアクセスできるSCIMサーバのみなので、実質自分で開発したアプリケーションしか対象はありません。
2.Azure AD自体がSCIMサーバになった訳ではないので、Azure ADのID管理にSCIMは使えない
※これまで通り、Graph APIを使ってID管理をしましょう。
参考)[Office 365 & WAAD] Graph API を利用したアイデンティティ管理
http://idmlab.eidentity.jp/2012/12/office-365-waad-graph-api.html
使い方としては、Azure AD Premiumライセンスが割り当たっているユーザでギャラリーからカスタムアプリケーションを追加すると、「アカウント プロビジョニングの構成」メニューが出てくるので、SCIMエンドポイントの設定を行います。
先にも書いたようにSCIMサーバのエンドポイントはAzure ADによって保護されている必要があるため、client idやsecretなどOAuth関連のパラメータを入れる余地はありません。
SCIMサーバの作り方はこのあたりに書いてあります。
https://azure.microsoft.com/en-us/documentation/articles/active-directory-scim-provisioning/
SCIM用のライブラリも用意されていて、nugetでダウンロードできます。
https://www.nuget.org/packages/Microsoft.SystemForCrossDomainIdentityManagement/
本当はサードパーティアプリケーションやAzure AD自体へSCIMを使ってプロビジョニングができるようになると良いなぁ、と思いますので今後に期待です。
IDaaSの主要機能の一つに連携しているアプリケーション向けのプロビジョニング機能がありますが、Azure Active Directory(Azure AD)もGoogle Appsやsalesforce.com、BoxなどメジャーなSaaSアプリケーション向けのプロビジョニングをサポートしてきました。
今回、アプリケーション向けのプロビジョニング機能の強化の一環としてSCIM 2.0(System for Cross-domain Identity Management)のサポートが発表されました。
Active Directory Teamのblog
Azure AD Premium now supports SCIM 2.0!
http://blogs.technet.com/b/ad/archive/2015/11/17/azure-ad-premium-now-supports-scim-2-0.aspx
このニュースを見て、標準ではプロビジョニングできないSaaSアプリケーションでもSCIMをサポートしていればID管理できる!!と思ったのですが、現状はいろいろと制限があります。。。。
(PingOneとかSCIMをサポートしている別のIDaaSへのID同期に使えるかと思ったのですが・・・)
以下が現状の制限事項として大きい点です。
1.SCIMのエンドポイントの保護をAzure ADが行っているサービスのみに対応
※Azure ADが発行したOAuth2.0 Bearerトークンを使ってアクセスできるSCIMサーバのみなので、実質自分で開発したアプリケーションしか対象はありません。
2.Azure AD自体がSCIMサーバになった訳ではないので、Azure ADのID管理にSCIMは使えない
※これまで通り、Graph APIを使ってID管理をしましょう。
参考)[Office 365 & WAAD] Graph API を利用したアイデンティティ管理
http://idmlab.eidentity.jp/2012/12/office-365-waad-graph-api.html
使い方としては、Azure AD Premiumライセンスが割り当たっているユーザでギャラリーからカスタムアプリケーションを追加すると、「アカウント プロビジョニングの構成」メニューが出てくるので、SCIMエンドポイントの設定を行います。
先にも書いたようにSCIMサーバのエンドポイントはAzure ADによって保護されている必要があるため、client idやsecretなどOAuth関連のパラメータを入れる余地はありません。
SCIMサーバの作り方はこのあたりに書いてあります。
https://azure.microsoft.com/en-us/documentation/articles/active-directory-scim-provisioning/
SCIM用のライブラリも用意されていて、nugetでダウンロードできます。
https://www.nuget.org/packages/Microsoft.SystemForCrossDomainIdentityManagement/
本当はサードパーティアプリケーションやAzure AD自体へSCIMを使ってプロビジョニングができるようになると良いなぁ、と思いますので今後に期待です。
2015年11月13日金曜日
[Windows 10]TH2新機能 - BYOD(WorkPlace Join)でMicrosoft Passportを使う
こんにちは、富士榮です。
Windows 10初の大型アップデートである「Threshold 2」が公開されましたので、早速新機能を順番に見ていきたいと思います。
なんといってもアイデンティティ屋さんにとっての一番大きなアップデートはBYODシナリオにおけるMicrosoft Passportのサポートです。
これまではAzure AD JoinのシナリオでしかMicrosoft Passportが使えず、職場のアカウントを追加(WorkPlace Join)してもOffice 365などへのシングルサインオンはできませんでしたが、今回のビルドからはMicrosoft Passportが使えるようになったので、BYODシナリオでもしっかりシングルサインオンしてくれます。
では、早速設定してみます。
今回は、ローカルアカウントを使ってPCにログインしていますが、その状態でアカウントの設定を開き、職場のアクセスメニューを開くと、これまでのビルドとは大きく異なるメニュー構成となっていますので、Azure ADにサインインをしてみます。
すると、なぜかメールとアカウントの画面に飛ばされるので、「他のアプリで使われるアカウント」から「職場または学校アカウントを追加」をクリックします。
お決まりのAzure ADへのログイン画面が出てくるのでサインインしていきます。
多要素認証が必要なので、通知が飛ばされます。
ポリシーが適用されていきます。
このあたりのポリシーの中身はIntuneなんかで設定します。
作業PINの作成が要求されます。
作業PINなのか職場用PINなのかいまいちわかりませんが、気にせずPINを登録します。
作成が終わると準備完了!と言われます。
アカウントが追加されていることが確認できます。
さて、ここまでで準備は完了ですので、早速ログインしてみます。
そのままブラウザを起動し、アクセスパネルなどAzure ADと連携しているアプリケーションを立ち上げると、Microsoft Passportが有効になり、シングルサインオンされます。
なお、Azure AD上に登録されたデバイスを確認してみると、WorkPlace Join端末であることがわかります。
今後、Windows Server 2016も出てきますので、Microsoft Passportの適用範囲もさらに広がってくると思いますので、非常に楽しみな分野です!
Windows 10初の大型アップデートである「Threshold 2」が公開されましたので、早速新機能を順番に見ていきたいと思います。
なんといってもアイデンティティ屋さんにとっての一番大きなアップデートはBYODシナリオにおけるMicrosoft Passportのサポートです。
これまではAzure AD JoinのシナリオでしかMicrosoft Passportが使えず、職場のアカウントを追加(WorkPlace Join)してもOffice 365などへのシングルサインオンはできませんでしたが、今回のビルドからはMicrosoft Passportが使えるようになったので、BYODシナリオでもしっかりシングルサインオンしてくれます。
では、早速設定してみます。
今回は、ローカルアカウントを使ってPCにログインしていますが、その状態でアカウントの設定を開き、職場のアクセスメニューを開くと、これまでのビルドとは大きく異なるメニュー構成となっていますので、Azure ADにサインインをしてみます。
すると、なぜかメールとアカウントの画面に飛ばされるので、「他のアプリで使われるアカウント」から「職場または学校アカウントを追加」をクリックします。
お決まりのAzure ADへのログイン画面が出てくるのでサインインしていきます。
多要素認証が必要なので、通知が飛ばされます。
ポリシーが適用されていきます。
このあたりのポリシーの中身はIntuneなんかで設定します。
作業PINの作成が要求されます。
作業PINなのか職場用PINなのかいまいちわかりませんが、気にせずPINを登録します。
作成が終わると準備完了!と言われます。
アカウントが追加されていることが確認できます。
さて、ここまでで準備は完了ですので、早速ログインしてみます。
そのままブラウザを起動し、アクセスパネルなどAzure ADと連携しているアプリケーションを立ち上げると、Microsoft Passportが有効になり、シングルサインオンされます。
なお、Azure AD上に登録されたデバイスを確認してみると、WorkPlace Join端末であることがわかります。
今後、Windows Server 2016も出てきますので、Microsoft Passportの適用範囲もさらに広がってくると思いますので、非常に楽しみな分野です!