2013年7月30日火曜日

[FIM2010/WAAD] Azure Active Directory コネクタ Pre-Release 版が Connect に登場

ようやく出てきました。

先日来、ちょこちょこアップデートについて投稿していた Office365 / Windows Azure Active Directory へ Forefront Identity Manager 2010(FIM)から直接接続するためのコネクタの Pre Release 版が Connect で公開されました。(ちなみに ECMA2.0 ベースのようです)


ダウンロードは以下 URL より(Connect への登録が必要です)

Windows Azure Active Directory Connector
 https://connect.microsoft.com/site433/Downloads/DownloadDetails.aspx?DownloadID=50509


尚、今後も基本的にはディレクトリ同期ツールを使うことが推奨されるようですが、特殊なルールの適用をしたい場合や規模が大きい場合、フォレスト・ドメイン構成が複雑な場合などはこちらを使うことになりそうです。


関連ポスト
[Office365]新ディレクトリ同期ツールはFIM2010R2ベース
 http://idmlab.eidentity.jp/2013/06/office365fim2010r2.html
[FIM2010]ついにディレクトリ同期ツールにビルド番号が追いつきました
 http://idmlab.eidentity.jp/2013/06/fim2010.html

2013年7月20日土曜日

[WAAD] OAuth2.0 への対応状況まとめ&ちょこっと OpenID Connect も

まず初めにお断りしておきますが、公式リソースでは Windows Azure Active Directory の OAuth2.0 への対応自体はアナウンスされていますが、内容について明確には言及がない状態なので、あくまで今日時点で色々と探索した結果を書いており、間違いや今後の変更などは高い確率で発生すると思われます。あくまで、エンドポイントを探して叩いてみたらこんな結果が返ってきた、という状態であるとご理解ください。


さて、始めます。

WAAD でアプリケーションを追加すると様々なエンドポイントが付与されます。


その中には OAuth2.0 のトークン・エンドポイントも含まれており、OAuth2.0 プロトコルで使う client_id や client_secret の取得、redirect_uri 等の設定もアプリケーションの構成の中で行うことが出来ます。


さらに、現状ではプレビュー提供ですが protected resource として同じく WAAD 上に構成したアプリケーションを登録することも可能であり、OAuth2.0 を使って WAAD 上のアプリケーション(API)をマッシュアップしていくことも可能になっています。



基本的には WAAD Authentication Library(AAL)を使ってアクセストークンなどを取得することが前提のようですが、折角そこに OAuth のエンドポイントがあるので叩いてみたいと思います。

まず、叩き方ですが、先日日本語訳がされた OAuth2.0 の仕様(RFC6749)に定義されている各種フローをそれぞれ試してみます。

 The OAuth 2.0 Authorization Framework(OpenID Foundation Japan 翻訳 WG 訳)
 - http://openid-foundation-japan.github.io/rfc6749.ja.html


試したのは、
・認可コードグラント
・インプリシットグラント
・リソースオーナーパスワードクレデンシャル
・クライアントクレデンシャル
です。

それぞれやってみます。


◆認可コードグラント

仕様上は、ざっくりいうと
1.クライアントが認可エンドポイントから認可コードを取得
2.トークンエンドポイントで認可コードとアクセストークンを交換
という流れになります。

ここで疑問。先ほど出てきた WAAD の OAuth2.0 エンドポイントにはトークンエンドポイントはありましたが、認可エンドポイントが出てきていませんでした。

トークンエンドポイントのアドレスが
 https://login.windows.net/<テナントID>/oauth2/token?api-version=1.0
だったので、token ⇒ authorize に変えたら行けるかな?ということで
 https://login.windows.net/<テナントID>/oauth2/authorize?api-version=1.0
を試してみます。意外と行けるもんです(笑)


ということで以下を試します。
1.認可コードの取得

 エンドポイント:認可エンドポイント
 メソッド:GET
 パラメータ:
  ・response_type : code
  ・client_id : <WAADで取得した client_id>

 こんなクエリになります。

 GET /<テナントID>/oauth2/authorize?api-version=1.0&response_type=code&client_id=<client_id> HTTP/1.1
 Host: login.windows.net

 仕様上は HTTP 302 が返ってきて Location に redirect_uri?code=xxx という形で認可コードが返ってくるはずです。

 結果、Microsoft Online アカウントでの認証が実行された後、ちゃんと認可コードが返ってきました。







2.認可コードとアクセストークンの交換

 次は取得した認可コードをトークンエンドポイントへ投げてアクセストークンを取得します。

 エンドポイント:トークンエンドポイント
 メソッド:POST
 パラメータ:
  ・grant_type : authorization_code
  ・code : <取得した認可コード>
  ・resource : アクセス対象の保護リソースの URI(WAAD 上で指定した WebAPI のURI)。今回は Graph API の URI(https://graph.windows.net)を指定します。

 ※OAuth2.0 の仕様上は resource パラメータは存在しませんが、WAAD の OAuth2.0 エンドポイントへアクセスする場合は必ず resource パラメータを要求されます。

 POST /<テナントID>/oauth2/token HTTP/1.1 Host: login.windows.net
 Content-Type: application/x-www-form-urlencoded grant_type=authorization_code&code=<取得した認可コード>&resource=https%3A%2F%2Fgraph.windows.net

 結果、残念ながら、「unsupported_grant_type」が返ってきてしまいました。
 エラーの説明として「ACS70003: The access grant 'authorization_code' is not supported」とあるので、現状は認可コードグラントは使えない、ということです。




◆インプリシットグラント

次はインプリシットグラントです。こちらは非常に単純なフローで、認可エンドポイントに対してアクセストークンを直接要求します。

 エンドポイント:認可エンドポイント
 メソッド:GET
 パラメータ:
  ・response_type : token
  ・client_id : <WAADで取得した client_id>

 こんなクエリになります。

 GET /<テナントID>/oauth2/authorize?api-version=1.0&response_type=token&client_id=<client_id> HTTP/1.1
 Host: login.windows.net

 仕様上は HTTP 302 が返ってきて Location に redirect_uri#access_token=xxx&token_type=xxx という形でフラグメントにアクセストークンが返ってくるはずです。

 しかし、これも残念。「unsupported_response_type」といわれてしまいます。こちらも使えない、といことです。



◆リソースオーナーパスワードクレデンシャル

続いてリソースオーナーパスワードクレデンシャルです。こちらも単純でリソースオーナーのユーザ名とパスワードをクエリに埋め込んでアクセストークンを要求します。

 エンドポイント:トークンエンドポイント
 メソッド:POST
 パラメータ:
  ・grant_type : password
  ・username : <WAADのユーザ名>
  ・password : <WAADのパスワード>
  ・resource : https://graph.windows.net

 こんなクエリになります。

 POST /<テナントID>/oauth2/token HTTP/1.1 Host: login.windows.net
 Content-Type: application/x-www-form-urlencoded grant_type=password&username=<WAADのユーザ名>&password=<WAADのパスワード>&resource=https%3A%2F%2Fgraph.windows.net

 こちらもうまくいけば HTTP 200 でアクセストークンが返ってくるはずです。

 しかし、同じくこちらも残念ながら「unsupported_grant_type」です。なかなかうまく行かないもんです。



◆クライアントクレデンシャルグラント

最後はクライアントクレデンシャルグラントです。こちらはトークンエンドポイントへ直接トークンを要求します。

 エンドポイント:トークンエンドポイント
 メソッド:POST
 パラメータ:
  ・grant_type : client_credentials
  ・client_id : <取得した client_id>
  ・client_secret : <取得した client_secret>
  ・resource : https://graph.windows.net

 ※こちらも仕様上は grant_type 以外のパラメータは必須ではありませんが、認証を行うことが必要なフローなので、WAAD では client_id と client_secret を投げてクライアント認証を行っているようです。

 こんなクエリになります。

 POST /<テナントID>/oauth2/token HTTP/1.1 Host: login.windows.net
 Content-Type: application/x-www-form-urlencoded grant_type=client_credentials&client_id=<取得した client_id>&client_secret=<取得した client_secret>&resource=https%3A%2F%2Fgraph.windows.net

 うまくいけば HTTP 200 でアクセストークンが返ってくるはずです。

 こちらは、、、、、うまく行きました。

{
 "token_type":"Bearer",
 "access_token":"eyJ0eX........(略)",
 "expires_in":"43199",
 "not_before":"1374294762",
 "expires_on":"1374337962",
 "resource":"https://graph.windows.net"
}



と、いうことで結果をまとめると下記の通りとなります。
まぁ、まだまだですねぇ。

フロー結果備考
認可コードグラント×Code requetは成功
Token requestでunsupported_grant_type
インプリシットグラント×unsupported_response_type
リソースオーナーパスワードクレデンシャル×unsupported_grant_type
クライアントクレデンシャルグラント以下のパラメータが要求される
Resource
Client_id
Client_secret







◆おまけ(OpenID Connect)

ここからはおまけですが、WAAD も OpenID Connect に対応するという話があります。OpenID Connect は OAuth2.0 ベースなので少し試してみました。
試したのはインプリシットのみで、結果的に言うと id_token の取得が出来てしまいました。が、仕様への対応状況はまだかなり怪しい感じです。

 エンドポイント:認可エンドポイント
 メソッド:GET
 パラメータ:
  ・response_type : id_token token
  ・client_id : <WAADで取得した client_id>
  ・scope : openid profile
  ・nonce : <任意の文字列>

 こんなクエリになります。

 GET /<テナントID>/oauth2/authorize?api-version=1.0&response_type=id_token%20token&client_id=<client_id>&scope=openid%20profile&nonce=<任意の文字列> HTTP/1.1
 Host: login.windows.net

 仕様上は HTTP 302 が返ってきて Location に redirect_uri#id_token=xxx&access_token=xxx&token_type=xxx という形でフラグメントに ID トークンとアクセストークンが返ってくるはずです。

 しかし、先に述べたように response_type に token を指定するとエラーになるので、今回は response_type = id_token のみを指定してみました。

 すると、フラグメントではなく、パラメータで id_token が返ってきました。

 返ってきた id_token を BASE64 URL デコードしてみると、
{
 "typ":"JWT",
 "alg":"RS256",
 "x5t":"NGTFvdK-fythEuLwjpwAJOM9n-A"
}

{
 "aud":"<取得した client_id>",
 "iss":"https://sts.windows.net/<テナント ID>/",
 "nbf":1374284435,
 "exp":1374313235,
 "ver":"1.0",
 "tid":"<テナントID>",
 "oid":"<WAAD 上のユーザのオブジェクトID>",
 "upn":"xxx@<テナントドメイン>.onmicrosoft.com",
 "sub":"vqrPXdoNdGPRd5DBnH...(略)",
 "family_name":"富士榮",
 "given_name":"尚寛",
 "nonce":"hoge"
}

 という形になりました。
 sub に入っている値が何なのか、Graph API 等で探ってみたのですが、利用者に見えるところには出てこない識別子のようです。

まだ、これで何か出来るわけではありませんが、Office Web App の開発リファレンスを見ているとトークンのデコードや検証のためのサンプルコードが出ていたりするので、同じ仕組みを使うことが出来るようです。

今回、色々と課題はあるものの WAAD が着々と OAuth2.0 や OpenID Connect に対応してきていることが見えてきました。
今後は社内の Active Directory と AD FS ⇒ WAAD を経由して OpenID Connect RP への認証連携なども実現できるようになってきそうなので、ますますコンシューマ系のサービスとの接続が容易になってくるのかも知れません。

引き続き目が離せないところです。

[Office365]PowerShellを使った自動化を行う際のTIPS

Office365 の管理を自動化する際、PowerShell を使うのが一般的かと思います。

例えば、Forefront Identity Manager(FIM)を使って Office365 のアイデンティティ管理を行う場合も海外の事例を見ているとデンマークの FIM MVP の Soren が提供している PowerShell MA と Office365 用のスクリプトを組み合わせて対応している例が多いようです。

 PowerShell Management Agent

しかし、実際に PowerShell を使って Offie365 の管理の自動化を行う際に一番最初に引っかかるのが Connect-MsolService コマンドレットでの ID / パスワードのポップアップです。



バックグラウンドで使おうと思うとこのようなユーザ・インタラクションは回避したいところです。

ということで、今回は PowerShell で Credential 情報をポップアップせずに入力する方法の紹介です。

まず、問題になるのはパスワードの扱いです。Connect-MsolService 自体は -Credential オプションに PSCredential 型のオブジェクトを渡してあげることでポップアップせずに実行することが出来ますが、この PSCredential 型のオブジェクトを作成する際に使うパスワードが普通の文字列ではなく、SecureString という型なので、平文をそのまま渡してもうまくいきません。

ということでひと工夫です。

まず、SecureString として入力したパスワードをファイルに保存します。
> Read-Host -AsSecureString | ConvertFrom-SecureString | Out-File pwd.txt
******* <- p="">
結果出来上がったファイル(pwd.txt)の中にはハッシュ化されたパスワードが保存されます。
> cat .\pwd.txt
01000000d08c9ddf0115d1118c7a00c04fc297eb01000000c40a300be3002b4a9920bd16c95a674b000000000200000000001066000000010000200000002a7eb8f2b74a57c5a22ab44b53c3b4d685d1c227575e9ee3ceb7f8eb16d1a2e3000000000e8000000002000020000000ca45d7964ca3162a30dcb5d680490235a9899cf1a72ef55c3271982e22d307ab20000000ed0adf53a7ce(以下、略)

これでパスワードを保存できましたので、変数に入れておきます。
> $password = cat .\pwd.txt | ConvertTo-SecureString

これを元にクレデンシャル情報を生成します。
> $cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList user@xxx.onmicrosoft.com,$password

これのクレデンシャル情報を使って Offie365 へ接続します。
> Connect-MsolService -Credential $cred


これでポップアップなしに Office365 へ接続できますので、バックグラウンドでの処理を行うことが出来ます。

ちょっとした小ネタでした。

2013年7月15日月曜日

[WAAD]Active Authenticationプロバイダを利用した多要素認証を構成する

最近 Windows Azure Active Directory(WAAD)周りの更新が激しすぎて色々と試せていないことがあるんですが、順番に試して行こうと思います。

今回は、現在 Preview リリースされている Active Authentication による多要素認証の設定です。(2013/6/12にアナウンスされたものです)

 Windows Azure Active Authentication: Multi-Factor for Security and Compliance
 - http://blogs.technet.com/b/ad/archive/2013/06/12/windows-azure-active-authentication-multi-factor-for-security-and-compliance.aspx


まずは準備作業として Windows Azure 管理ポータルよりディレクトリを作成しておきます。(しかし管理ポータルの「すべてのアイテム」から作成したディレクトリを見ると「名簿」となっているのは何とかしてもらいたいもんです)


早速設定していきます。

Active Authentication プロバイダを作成します。


ここで出てくる使用モデルには「認証ごと」もしくは「有効化されたユーザごと」が選択できますが、これは課金のされ方の違いです。
「認証ごと」だと認証10回毎に\83.04、「有効化されたユーザごと」だとユーザあたり一月\83.04という金額体系になっています。

 参考)料金プラン
 - http://www.windowsazure.com/ja-jp/pricing/details/active-directory/



次に作成したディレクトリをリンクします。


うまくいくと Active Authentication プロバイダが作成されます。



次に対象とするユーザのプロパティから多要素認証を有効化します。



早速そのユーザでログオンしてみます。今回は対象アプリケーションとして Office365 を使っていますが、WAAD で認証するアプリケーションであれば何でも大丈夫です。

普通に ID / PWD でログオンすると初回は多要素認証のセットアップを要求されます。



携帯電話や Active Authentication アプリなどを使った認証の設定を自身で設定していきます。



ちなみに Active Authentication アプリの構成をクリックすると QR コードが出てくるのでアプリから読み込んでアプリを構成します。



今回は Android 版のアプリを使います。先日マイクロソフトが買収した「PhoneFactor」の名前がまだ残っています。



アプリをインストールしたら QR コードを読み込みます。



うまくいけば構成が終わるので、次回のログイン時の追加認証としてアプリへ認証要求がプッシュされます。



なんだか文字化けしていますが、こんな画面が出てくるので[認証]をタップします。



うまくいけば認証が完了し、ブラウザ側も自動的にリフレッシュされて Office365 へアクセスできます。



ちなみに、携帯電話への SMS 通知だとこんな感じです。




ブラウザに通知されたコードを入力すると認証完了です。



今回は Office365 を例に Active Authentication を行いましたが、先にも述べたように WAAD で認証を行うアプリケーションならこの機能を使うことが出来ます。
つまり、先日紹介した Google Apps や Salesforce.com などの SaaS へのログオンにもこの機能を使うことが出来ますし、同じく以前紹介した Windows Server 2012 R2 の AD FS の認証についても WAAD を使うことが出来るようになるらしいので、オンプレミスのアプリケーションについても手軽にこれらの機能を使うことが出来るようになってきます。
いよいよ本格的に IDaaS と MBaaS の機能を Windows Azure が担うようになってきた、ということですね。

2013年7月14日日曜日

[FIM2010]Google Apps MA 1.1.1 をリリースしました

かなり久しぶりの更新になりましたが、先ほど codeplex にモジュールをアップロードしました。

 Google Apps MA
 - https://fim2010gapps.codeplex.com/



といってもバグフィックスです。
しかも直したのは半年以上前という、、単にアップロードをサボってただけです。

修正ポイントは、
「インポート処理時にページングがうまく実装出来ていなかったので実装した」
の1点のみです。

FIM は CS へインポートする際に MA に設定したページサイズ分のエントリを読み込み終わると一旦 GetImportEntries メソッドを抜け、再度エントリが無くなるまで同メソッドを繰り返し呼ぶ、という動きをするのですが、この際に最後のエントリを読み込み終わったことを FIM 側へ自分で伝えてあげる必要があります。
そのためのプロパティが importReturnInfo.MoreToImport というプロパティで、最後のエントリを読み込み終わったらこの値を true にしてあげれば FIM はすべての Import が完了したという判断をして処理を終わります。

小規模のシステムとの接続であれば MA の設定で大きめの数値をページサイズとして設定してあげれば一回の GetImportEntries 処理で完了するので問題ないのですが、MA に設定できる最大サイズを超えるようなエントリーをインポートする必要がある場合は上記のようなページング処理を実装してあげる必要があります。

ちなみに次の実装予定は
1. Google Provisioning API が 5月に新しい API (Google Directory API)へ変わったのでそこへの対応
2. 合わせて API 認可を現状 ClientLogon(管理者 ID とパスワードを MA に設定する方式)にしているのを OAuth 2.0 に対応させる
の2点を予定していますが、1. の API 変更が結構な大手術になりそうなのでぼちぼちやっていく形になりそうです。
まぁ、これを実装しちゃえば Windows Azure Active Directory の Graph API も SCIM もほぼ同じコードで流用できちゃうので早く実装したいとは思っているのですが、、

ではでは。。

2013年7月10日水曜日

[WAAD] IDaaS としての機能が充実してきた

ここのところ Windows Azure Active Directory(WAAD)の機能拡充が加速しているようです。
今回は以前に紹介した Intel Cloud SSO(現McAfee Cloud SSO)の様ないわゆる Identity as a Service(IDaaS)の持つ、クラウド・サービスのアイデンティティ管理基盤としての機能である「アプリケーション・アクセス」が追加されました。(現行 Preview)

公式 blog によると、以下のような機能が追加されたということです。

  • A gallery of pre-integrated SaaS apps including top apps like Office 365, Box.com, Salesforce.com, Concur, DropBox & Gmail (plus 40 more).
  • Easy SSO configuration using SAML federation or secure password mangement.
  • User provisioning integration with top SaaS apps like Box, Salesforce.com and Gmail.
  • Simple security reports reporting user logins and suspicious logins.
  • A browser based end-user access panel which makes it easy for employees to find the SaaS apps you're organization provides them and to Single Sign On (SSO) to those applications.


要するに、Office365 とか Box.com とか Salesforce.com など40種類以上の SaaS アプリケーションへの接続がプリセットで用意されていて、SAML もしくはパスワードの管理による SSO とユーザ・プロビジョニングが実行できて、利用者向けのアクセスパネルを使って各アプリケーションへの SSO アクセスが出来る、ということのようです。

Active Directory Team の blog でのアナウンス
 http://blogs.msdn.com/b/active_directory_team_blog/archive/2013/07/07/application-access-enhancements-for-windows-azure-active-directory.aspx


早速、Preview 機能を有効化して Azure 管理ポータルからディレクトリ・サービスを見ると、アプリケーションの追加のオプションで「アプリケーションへのアクセスの管理」を選べるようになっています。


設定を始めると確かに色々なアプリケーションへのアクセスをギャラリーから選択することが出来ます。


今日現在で以下の 75 個のサービスが使えるようです。

  • Adnovate
  • ADP Background Checking
  • ADP Easy Pay
  • ADP eTime
  • ADP Flex Direct
  • ADP HR/Benefits
  • ADP RUN
  • ADP VirtualEdge Recruitment
  • Amazon Web Services (AWS)
  • Annotag
  • Appetas
  • AppPoint
  • Aravo
  • Barium Live
  • Base Camp
  • Bentley Systems
  • Birst Agile Business Analytics
  • B-kin
  • Box
  • Cisco Webex
  • Citrix GoToMeeting
  • ClearlyInventory
  • Click2Translate
  • Concur
  • Dpcisign
  • DropBox for Business
  • Egnyte
  • ElasticWCM
  • Evernote
  • FabaSoft Folio Cloud
  • GitHub
  • Google
  • Google Apps
  • GT Nexus
  • Heroku
  • Hubwoo
  • IBM SmartCloud for Social Business
  • IBM Sterling Commerse Customer Center
  • iMedidata
  • Intacct
  • Intuit
  • litmus
  • LogMeln Rescue
  • LongJump
  • Microsoft Account (Windows Live)
  • Microsoft Bing Ads
  • Microsoft Developer Network (MSDN)
  • Microsoft Office365 Exchange Online (Outlook)
  • Microsoft Office365 SharePoint Online
  • Microsoft SkyDrive
  • MongoHQ
  • MySaasPlace
  • Netsuite
  • New Relic
  • Oracle Taleo
  • pingdom
  • Replicon
  • Saba Meeting
  • Sage North America
  • Salesforce
  • SDL Click2Translate
  • Skype
  • SpringCM
  • SuccessFactors
  • Sunwapta PenForms
  • Syncplicity
  • Thomson Reuters
  • TimeOffManager
  • Ultimate Software UltiPro
  • UPS
  • US Postal Service
  • Volusion
  • WorkflowMax
  • Yammer
  • YouSendIt



試しに Google Apps を追加すると、

  • シングルサインオンの構成
  • アカウントの同期の構成
  • ユーザーアクセスの構成

という3点の構成が出来るようです。


それぞれ、簡単に機能を紹介します。

◆シングルサインオンの構成

WAAD からアプリケーションへのシングルサインオンを行う方法として下記の2つのオプションが提供されています。
1. ユーザーは Windows Azure AD のアカウントを使用して認証
 ⇒SAML を使ったフェデレーションです。
2. ユーザーは既存のアプリケーションアカウントを使用して認証
 ⇒ブラウザに SSO プラグインを導入しての疑似シングルサインオンです。Enterprise SSO のように各サービスのログイン URL の ID / PWD 入力フォームへ WAAD 上のアカウントに紐づけて記憶させた ID / PWD を自動的に入力して Submit してくれます。
 (現状、IE と Chrome 用の SSO プラグインが提供されています)



ちなみに何故かフェデレーションを使った SSO の設定をしようとすると予期せぬエラーが出てしまうので、今のところ 2. のプラグインを使った SSO しか試せていません。


◆アカウントの同期の構成

WAAD のアカウントを各サービスへプロビジョニングする機能です。
これには前提があり、
・WAAD に独自ドメインを追加しておく必要がある
 ⇒ドメイン名は Google Apps で使っているドメインと同じドメインを追加
・Google Apps 側で API アクセスを許可しておく必要がある
 ⇒ Provisioning API を使うために必要
という条件を満たす必要があります。

これさえクリアすれば、設定が完了し、次項で紹介するユーザーアクセスの構成が住んでいるユーザを自動的にサービス側へプロビジョニングしてくれます。

尚、設定する際に Google Apps の管理者ユーザの ID とパスワードを入力させられることから API 認可に OAuth を使わずにレガシーな ClientLogin を使っている?ようでちょっと微妙です。



◆ユーザーアクセスの構成

設定が終わったら WAAD 上のユーザがアプリケーションを使えるようにします。
これは簡単で、ユーザの一覧からユーザを選んで「アクセスの有効化」をクリックするだけです。


これで対象のユーザが Google Apps へプロビジョニングされます。(しばらく時間がかかります)


尚、プロビジョニングしただけのユーザのパスワードは初期状態で WAAD のパスワードが同期されているわけではないので、一旦は Google Apps 側へ直接ログインしてパスワードを変更しておく必要があります。
(フェデレーションを使う場合は不要)




設定としては以上なので、実際に試してみます。

WAAD のアプリケーション・ポータルへ対象のユーザでログインすると設定したアプリケーションが見えます。

 アプリケーション・ポータル
 https://account.activedirectory.windowsazure.com/applications



アイコンをクリックするとプラグインのインストールを促されますので、インストールを実行します。(フェデレーション設定をした場合はことなるはずです)


- IE の場合


- Chrome の場合(Chrome Web Store からのインストール)





プラグインを有効化してブラウザを再起動すると、今度はアプリケーション・アイコンをクリックすると初回は Google Apps 側の ID / PWD を求められます。


ここで入力した値が WAAD アカウントに紐づけられて、ブラウザのプラグインが対象サービスのログインフォームへ自動的に入力してくれる仕組みになっています。

ということで、うまくいけば Gmail のページにアクセスできるようになっているはずです。

まだフェデレーションでのアプリケーション・アクセスの設定が上手く言っていないので何とも言えませんが、これでローカルの AD FS と WAAD のフェデレーション設定がされている環境であれば、各サービス毎にローカル AD FS へ証明書利用者信頼の設定をしなくて済むので証明書の管理など非常に楽になる可能性があり、コスト面でもかなり優位なものになるのではないでしょうか?
(Ping Federate と Ping One の関係のようなイメージでクラウド連携が出来るようになると思われます)

2013年7月3日水曜日

[AD FS]Windows Server 2012 R2 Preview の AD FS ②

先日のポストに引き続き Windows Server 2012 R2 Preview での AD FS の話です。

今回は AD FS でデバイス認証を有効にして、ドメインに参加していないデバイス(今回は iPhone)で AD FS と連携したサービス(証明書利用者信頼として登録した Google Apps)へのシングルサインオンを行ってみます。

これは Directory Services の MVP 国井さんが紹介してくれているとおり、「BYODで活用されるデバイスの管理をActive Directoryから行える」という Windows Server 2012 R2 Preview の Active Directory の新機能を使って実現します。

国井さんの blog ポスト:Windows Server 2012 R2 PreviewのActive Directory(1)
- http://sophiakunii.wordpress.com/2013/07/02/windows-server-2012-r2-preview%E3%81%AEactive-directory1/


実現するには、まずデバイスを Active Directory 上に登録して、AD FS の認証をデバイスで実行できるようにする必要があります。

まずはデバイスを登録する。登録サービス(Device Registration Service/DRS)の認証は AD FS を使い、ドメインユーザで実行する。


AD FS でデバイス認証を行いアプリケーションを利用する。


デバイス認証を使うと登録されたデバイスではドメイン環境にある PC と同じように ID / パスワード等でのユーザ認証を受けなくてもアプリケーション(AD FS の証明書利用者信頼)を利用できるようになります。

実際に試してみます。具体的には以下のステップを実行します。
1.DRS を実行できるように AD FS を構成する
2.DRS を使ってドメインに参加していないデバイスを Active Directory 上に登録する
3.AD FS の認証手段としてデバイス認証を有効にする
4.AD FS でデバイス認証を受けサービス(証明書利用者信頼)へアクセスする


◆1.DRS を実行できるように AD FS を構成する

AD FS の役割を追加した状態でも最初から DRS が証明書利用者信頼として登録されていますが、サービスとしては DRS は停止しています。
この状態から DRS を実行するためには、
・デバイスを AD DS に登録できるように AD DS のスキーマを拡張する
・DRS が AD FS で認証するように構成する
という作業が必要です。

具体的には、PowerShell で以下のコマンドレットを実行します。

 Enable-AdfsDeviceRegistration -PrepareActiveDirectory

これで、AD DS のスキーマ拡張等の準備が整いますので、DRS を有効化します。

 Enable-AdfsDeviceRegistration

うまくいけば DRS が開始しているはずです。


◆2.DRS を使ってドメインに参加していないデバイスを Active Directory 上に登録する

次に実際にデバイスを登録します。
現状では Windows 8.1 および iOS が登録可能ですが、今回は iOS を使います。

iPhone の safari で https://<AD FSサーバ>/EnrollmentServer/otaprofile へアクセスします。
AD FS へリダイレクトされ、ユーザ認証が完了するとプロファイルがダウンロードされますので、インストールを実施します。




AD DS の拡張表示を有効にした状態で Active Directory のユーザとコンピュータを見ると Registered Devices というコンテナの下にオブジェクトが登録されているのがわかります。


オブジェクトのプロパティを見ると確かに「iOS」との記載があり、先ほど登録をした iPhone であることがわかります。



◆3.AD FS の認証手段としてデバイス認証を有効にする

次は AD FS 側の設定です。
AD FS 管理コンソールからグローバル認証ポリシーの中のデバイス認証の有効化設定を行います。(Windows Server 2012 R2 Preview からの新しいメニューです)


これで AD FS 側の設定も完了です。再起動なども不要です。


◆4.AD FS でデバイス認証を受けサービス(証明書利用者信頼)へアクセスする

では、実際にアプリケーションへアクセスしてみます。
今回は AD FS の証明書利用者信頼として Google Apps を登録してみました。
先ほどの iPhone から Google Apps へアクセスしたときに、デバイス認証でシングルサインオンが実行されれば成功です。

結果ですが、想定の通り初回ドメインユーザで認証を行えば2回目以降は ID / パスワードを入れることなくアクセスできます。(ブラウザを落として再度アクセスしても大丈夫)
デバイス認証を行わないケースだとブラウザを落とすと毎回 ID / パスワードを聞いてくるのでそれに比べれば非常に簡単なオペレーションになります。


尚、この状態を解除するには、
・iPhone 側でプロファイルを削除する
 ⇒ユーザが自分でワークスペース参加を辞めたい場合
・AD DS 上でデバイスオブジェクトを削除する
 ⇒管理者側が端末の利用を停止させたい場合
・デバイスに配布している証明書を失効させる
 ⇒同上
などが考えられますが、こうなると System Center 等を使ったデバイス管理ソリューションと合わせて運用を行うことでよりセキュアで便利な状態が実現できそうな気がします。
また、多要素認証と組み合わせることで登録してあるデバイスでも追加認証が必要、というようなシナリオも考えられますし、今回は iOS で実験しましたが、例えば Windows RT のようなドメインに参加できないようなデバイスをビジネスで利用する、ということも考えられます。

しかし前回のポストでも述べましたが、Windows Server 2012 R2 では AD FS の役割がこれまで以上に大きな位置を占めるようになっているように感じます。TechEd や Build を見ていると AD FS を活用したシナリオが数多く用意されていますし、AD DS から AD FS への認証機能の大きなシフトチェンジが起きているような予感がします。
引き続き AD FS からは目が離せないですねぇ。

参考URL)
Solution Guide: Join to Workplace from Any Device for SSO and Seamless Second Factor Authentication Across Company Applications
- http://technet.microsoft.com/en-us/library/dn280945.aspx