2012年12月23日日曜日
[Azure]新ポータルから Access Control 名前空間を作成可能に
Windows Azure のポータルが2012年5月にリニューアルされてからも Access Control(ACS)だけは旧ポータルからしか管理できませんでしたが、ようやく新ポータルからも管理できるようになりました。
新しい名前空間を作成することも可能になっています。
作成後、アクティブ化が完了するのを待ちます。
管理画面に遷移した後は以前と変わりません。
あとは、実現しなさそうですが、このプラットフォームの管理ポータルと、ディレクトリサービスの管理ポータル、オンラインサービスの管理ポータルの統合ですかねぇ。。
少なくとも同じサービス名がついてしまっている Windows Azure Active Directory(WAAD)の管理が複数のサブスクリプション、管理インターフェイスに分かれているので、もう少しシンプルになれば、と思います。
2012年12月4日火曜日
[Office 365 & WAAD] Graph API を利用したアイデンティティ管理
Office 365 Advent Calendar および Windows Azure Advent Calendar 用のポストです。
まず、最初に何故 2 つの Advent Calendar へのクロスポストなのか?というあたりを解説するために、Office 365 と Windows Azure Active Directory の関係を解説して置くと、単純に Office 365 の アイデンティティ基盤が Windows Azure Active Directory だからです。
[図:Office 365 と Windows Azure Active Directory の関係]
Office 365 のユーザやグループの管理を行ったり、シングルサインオンを行う際は実際は Office 365 そのものではなく、Windows Azure Active Directory に対して操作をしている、ということです。
[表:Office 365 から見た Windows Azure Active Directory]
機能 | Office 365 から見た WAAD |
---|---|
シングルサインオン | 信頼するアイデンティティ・プロバイダ ⇒ここで認証されたユーザは信頼できる |
ユーザ/グループ管理 | アイデンティティ・ストア ⇒このデータベースに保持されるユーザ情報(属性など)を利用する |
さて、本日のお題です。
■Office 365 のユーザ管理の限界
これまで、Windows Azure Active Directory 上のアカウントを管理(追加・変更・削除・ライセンス割り当て等)を行おうと思うと、マイクロソフト公式のディレクトリ同期モジュールを使うか、個別に PowerShell で管理を行うしか方法はありませんでした。
参考:@IT / Office 365 とのアイデンティティ連携を実現する
http://www.atmarkit.co.jp/ait/articles/1211/14/news069.html
ディレクトリ同期ツールを使って Office 365 へのユーザ同期を行う
http://idmlab.eidentity.jp/2011/04/office365.html
しかし、このディレクトリ同期ツール、現状ではそれなりに制限事項があります。
例を挙げると、以下のような事項が挙げられます。
・社内の Active Directory がマルチフォレスト構成だった場合、同期用のドメインを別途構築し、必要なアカウント情報を同期用ドメインに集める必要がある
・不要な(Office 365 を利用しない)ユーザでも同期してしまう(除外ルールの融通が利かない)
・ライセンス割り当ては個別に実施する必要がある
・50,000 オブジェクトまでの同期しかサポートされない
・メンバ数が 15,000 を超えるグループは同期出来ない
・認証プロキシサーバ以下の環境では使えない
※認証不要な Proxy 環境化では netsh コマンドで https プロキシ設定をすれば OK
・(当然ですが)Windows Server でしか動かない
結果として、ディレクトリ同期を行った後、Office 365 の管理コンソールで不要なユーザを消したり、PowerShell でライセンス割り当てをしたり、、、とそれなりに管理者には負荷がかかるのが現実だと思います。
そこで登場したのが Windows Azure Active Directory Graph API です。
現在はまだプレビューですが、Graph API は RESTful な API なのでプラットフォームに依存せずに利用することができますし、各アイデンティティ管理製品のカスタムアダプタとして容易に実装することが可能となります。
先日、本 blog でもこの API を利用して Windows Azure Active Directory 上のユーザ情報を取得する方法を紹介しましたが、今回は
・ユーザの作成
・ユーザの更新
・ライセンスの割り当て
・ユーザの削除
を紹介したいと思います。
参考:[WAAD] REST Client で Graph API を直接実行する
http://idmlab.eidentity.jp/2012/09/waad-rest-client-graph-api.html
■Graph API を利用するための準備
Graph API を利用して Windows Azure Active Directory 上のアカウントを管理するためには、
・サービスプリンシパルの作成
・テナント ID の取得
・作成したサービスプリンシパルへ適切な権限の付与
という 2 つの作業が必要です。
まず、サービスプリンシパルを作成します。
MSOnline / MSOnlineExtended の 2 つのモジュールを読み込んだ状態の PowerShell (Microsoft Online Services Module for Windows PowerShell)から
> Connect-MsolService
で MSOnline へ接続します。
その状態で、
> New-MsolServicePrincipal -DisplayName "<任意の名前>" -ServicePrincipalNames @("<任意の名前>") -Type Symmetric -Usage Verify - StartDate
と実行します。
すると、以下のような結果が取得できます。
The following symmetric key was created as one was not supplied
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
DisplayName : <指定した名前>
ServicePrincipalNames : {<指定した名前>,
ObjectId : BBBBBBBBBBBBBBBBBBBBBBBB
AppPrincipalId : CCCCCCCCCCCCCCCCCCCCCCCCC
TrustedForDelegation : False
AccountEnabled : True
Addresses : {}
KeyType : Symmetric
KeyId : DDDDDDDDDDDDDDDDDDDDDDDD
StartDate : 2012/12/03 8:00:00
EndDate : 2015/12/03 8:00:00
Usage : Verify
この中で必要なのが、実行結果内の
・AppPrincipalId
・SymmetricKey
・ObjectId
の 3 つです。
次に、作成した Office 365 テナントの ID を取得します。
これも同じく PowerShell で
> (Get-MsolCompanyInformation).objectId
を実行して Guid を取得します。
さらに作成したサービスプリンシパルへの適切な権限を付与します。
Windows Azure Active Directory を操作するための権限は複数存在しますが、ユーザを管理するために必要な権限は User Account Administrator というロールが持っていますので、作成したサービスプリンシパルをこのロールメンバに追加します。
同じく PowerShell で
> Add-MsolRoleMember -RoleMemberType ServicePrincipal -RoleName "User Account Administrator" -RoleMemberObjectId <サービスプリンシパルの ObjectID>
と実行します。
ここまでそろえばあとは Graph API を実行するだけなのですが、実行するために必要なアクセストークンを取得する必要があります。
ここも RESTful API を使って取得することも可能ですが、今回は面倒なので Windows Azure Authentication Library (AAL) を使ってアクセストークンを取得するプログラムを書いてみます。
参考:Windows Azure Authentication Library
http://msdn.microsoft.com/en-us/library/windowsazure/jj573266.aspx
※ちなみに AAL を使わずにアクセストークンを取得する方法は先に挙げたポストを参照してください。
[WAAD] REST Client で Graph API を直接実行する
http://idmlab.eidentity.jp/2012/09/waad-rest-client-graph-api.html
今回は簡単なプログラムを書きました。
using System; using Microsoft.WindowsAzure.ActiveDirectory.Authentication; namespace GetAccessToken { class Program { static void Main(string[] args) { string TenantDomainName = "<取得したテナントドメイン名>.onmicrosoft.com"; string TenantId = "<取得したテナントID>"; string AppPrincipalId = "<取得した AppPrincipalId"; string SymmetricKey = "<取得した SymmetricKey>"; AuthenticationContext context = new AuthenticationContext( "https://accounts.accesscontrol.windows.net/" + TenantDomainName); SymmetricKeyCredential credential = new SymmetricKeyCredential( AppPrincipalId + "@" + TenantId, Convert.FromBase64String(SymmetricKey)); AssertionCredential assertion = context.AcquireToken( "00000002-0000-0000-c000-000000000000/directory.windows.net@" + TenantId, credential); System.Console.WriteLine("auth:" + assertion.CreateAuthorizationHeader()); } } }
このプログラムをコンパイルして実行すると Windows Azure Active Directory から Graph API 実行に必要なアクセストークンを取得し、コンソールに表示してくれますので、メモしておきます。
いよいよ Graph API の実行です。今回も先のポストと同様に Chrome Extension の Advanced Rest Client を使いました。
■Graph API でユーザを作成する
まずはユーザの作成です。
実行するクエリをまとめると以下の表になります。
設定 | 値 | |
---|---|---|
エンドポイント | https://graph.windows.net/advent2012.onmicrosoft.com/Users | |
メソッド | POST | |
ヘッダ | Authorization | 取得したアクセストークン |
x-ms-dirapi-data-contract-version | 0.8 | |
Content-Type | application/atom+xml | |
ボディ | <entry xmlns="http://www.w3.org/2005/Atom" xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices" xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata"> <content type="application/xml"> <m:properties> <d:ObjectType>User</d:ObjectType> <d:AccountEnabled m:type="Edm.Boolean">true</d:AccountEnabled> <d:DisplayName>織田信長</d:DisplayName> <d:GivenName>信長</d:GivenName> <d:Surname>織田</d:Surname> <d:UserPrincipalName>nobunagao@<テナントドメイン名>.onmicrosoft.com</d:UserPrincipalName> <d:MailNickname>nobunagao</d:MailNickname> <d:Password>P@ssw0rd</d:Password> </m:properties> </content> </entry> |
うまくいくと HTTP 201 created が返され、作成されたユーザエントリの情報が XML (Accept ヘッダを application/json にしておけば JSON )で返ってきます。
■Graph API でユーザを更新する
次に作成したユーザの属性を更新してみます。
作成時に UsageLocale を指定しなかったので、次のライセンス割り当てで問題が起きるため、UsageLocale 属性を更新してみます。(ライセンス割り当てにはユーザの所在地の指定が必要)
今回は PATCH メソッドを利用します。
設定 | 値 | |
---|---|---|
エンドポイント | https://graph.windows.net/advent2012.onmicrosoft.com/Users(‘<対象ユーザ名>@<テナントドメイン>.onmicrosoft.com’) | |
メソッド | PATCH | |
ヘッダ | Authorization | 取得したアクセストークン |
x-ms-dirapi-data-contract-version | 0.8 | |
Content-Type | application/atom+xml | |
ボディ | <entry xmlns="http://www.w3.org/2005/Atom" xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices" xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata"> <content type="application/xml"> <m:properties> <d:UsageLocation>JP </d:UsageLocation> </m:properties> </content> </entry> |
うまくいくと HTTP 204 no-content が返されます。
■Graph API でライセンスを割り当てる
作成したユーザにはまだライセンスを割り当てていないので、ライセンスの割り当てを行います。
今回は Office 365 のプラン E3 を使ったので、該当する SkuId である「6fd2c87f-b296-42f0-b197-1e91e994b900」を割り当てます。
設定 | 値 | |
---|---|---|
エンドポイント | https://directory.windows.net/<取得したテナントドメイン>.onmicrosoft.com/Users('<割り当てるユーザID>@<取得したテナントドメイン>.onmicrosoft.com')/AssignLicense | |
メソッド | POST | |
ヘッダ | Authorization | 取得したアクセストークン |
x-ms-dirapi-data-contract-version | 0.8 | |
Content-Type | application/json;odata=verbose;charset=utf-8 | |
ボディ | {"AddLicenses": [ { "__metadata": {"type":"Microsoft.WindowsAzure.ActiveDirectory.AssignedLicense"}, "DisabledPlans": {"__metadata": {"type":"Collection(Edm.Guid)"}, "results":[]}, "SkuId":"6fd2c87f-b296-42f0-b197-1e91e994b900" } ], "RemoveLicenses":null } |
うまくいくと HTTP 200 ok が返され、アサインされたライセンスを含むユーザエントリ情報が XML もしくは JSON で返ってきます。
よく見ると RMSOnline なんていう文字列も見えるので、Office 365 の管理ポータルから見える以外のライセンスの準備も進んでいることがよくわかります。
■Graph API でユーザを削除する
最後に作成したユーザを削除してみます。
以下のクエリを実行します。
設定 | 値 | |
---|---|---|
エンドポイント | https://graph.windows.net/advent2012.onmicrosoft.com/Users(‘<作成したユーザID>@<テナントドメイン>.onmicrosoft.com’) | |
メソッド | DELETE | |
ヘッダ | Authorization | 取得したアクセストークン |
x-ms-dirapi-data-contract-version | 0.8 | |
Content-Type | application/x-www-form-urlencoded? |
こちらもうまくいくと HTTP 204 no-content が返ってきます。
いかがでしたでしょうか?
まだまだプレビューですので、色々と検証してみる必要はありそうですが、上記のように公式のディレクトリ同期ツールを使わなくても Graph API を実行することによりアイデンティティ管理を柔軟に行うことが可能になることがわかりました。
私も Forefront Identity Manager 2010 用の Windows Azure Active Directory 用のカスタム管理エージェントを作ってみようとしているところなので、また完成したら公開したいと思います。
以上で私のポストはおしまいですが、明日は各 Advent Calendar は以下の予定になっているそうなので、引き続き参考にしてみてください。
・Office 365 : Office 365 MVP 中村 和彦さん / http://simplesso.jp/
・Windows Azure : Kentaro AOKIさん / http://kentablog.cluscore.com/
2012年12月2日日曜日
IdM プロジェクトの進め方
先日のオラクルセキュリティセミナでお話した事例紹介のプレゼンの中から IdM プロジェクトの進め方の部分だけ抜粋して公開しました。
今後 IdM プロジェクト管理をする方に少しはお役に立てれば、と。(& JNSA の宣伝込みw)
まぁ、言いたいことはゼロから手探りでプロジェクトを進めるんじゃなくて、先人の知恵を利用しましょう、ということと、段階導入をする上で合理的な効果測定をしていったほうが良いですよ、という話です。
今後 IdM プロジェクト管理をする方に少しはお役に立てれば、と。(& JNSA の宣伝込みw)
まぁ、言いたいことはゼロから手探りでプロジェクトを進めるんじゃなくて、先人の知恵を利用しましょう、ということと、段階導入をする上で合理的な効果測定をしていったほうが良いですよ、という話です。
[WAAD] ACS および コア機能が無償で提供
これは結構大きなニュースです。
これまで本当はいつから課金されるのかよくわからなかった 旧 AppFabric Access Control / Windows Azure Active Directory ですが、ようやく明確なアナウンスがありました。
- Windows Azure Team の blog
Windows Azure Active Directory: Making it easier to establish Identity Management in the cloud
- Vittorio の blog
Access Control & Core Directory Available at No Charge
以下の 2 つのコア機能については無償!ということです。素晴らしい。
前者(ACS)についてはこれまでトランザクション課金でしたが無償化、後者(WAAD)については現在プレビュー提供ですが、GA後も無償のまま、ということです。
ちなみにこれまでの課金に関する表記。若干混乱気味でした。
これまで本当はいつから課金されるのかよくわからなかった 旧 AppFabric Access Control / Windows Azure Active Directory ですが、ようやく明確なアナウンスがありました。
- Windows Azure Team の blog
Windows Azure Active Directory: Making it easier to establish Identity Management in the cloud
- Vittorio の blog
Access Control & Core Directory Available at No Charge
以下の 2 つのコア機能については無償!ということです。素晴らしい。
- アクセス制御(旧 Access Control Service)
- Facebook 連携やオンプレミスの Active Directory などとの連携機能
- コア・ディレクトリおよび認証
- シングルサインオン、ユーザ・グループ管理、ディレクトリ同期、フェデレーション機能
we are announcing today that two key features of Windows Azure Active Directory are available at no charge.
- Access control provides centralized authentication and authorization by integrating with consumer identity providers, such as Facebook, or using on-premises Windows Server Active Directory. By having Access Control available you can create a single application that can allow users to login with both their Organizational Credentials stored in Windows Azure AD or Windows Server AD, or to login in using popular consumer service identity services like Microsoft Account, Facebook, Google, or Twitter. Historically, Access Control has been priced based on the number of transactions. We are now making it free.
- Core Directory & Authentication enables capabilities such as single sign-on, user and group management, directory synchronization and directory federation. These features are currently free in the Windows Azure AD Developer Preview and will remain free after it reaches general availability.
前者(ACS)についてはこれまでトランザクション課金でしたが無償化、後者(WAAD)については現在プレビュー提供ですが、GA後も無償のまま、ということです。
ちなみにこれまでの課金に関する表記。若干混乱気味でした。
2012年11月24日土曜日
[FIM2010]製品ロードマップ?
ソースが Directions on Microsoft で、こんなネタが。。(といっても 2011年4月なので古い情報でしょうけど)
既に CY2012 も終わろうとしていますが、Forefront Identity Manager 2012 なんていう話は出てきていないので、R2 のことかも知しれませんね。
誰か Directions on Microsoft のアカウント買ってる人がいらっしゃれば最新情報を!
元スライドはこちら。
2012年11月23日金曜日
[WAAD]Windows 8 の PowerShell で ServicePrincipal 関連の操作を行う
既出情報ですが、意外と引っかかるのでメモとして書いておきます。
Windows 8 / Windows Server 2012 では Microsoft Online Services Module for PowerShell をインストールして ServicePrincipal 関連のコマンドレット(例えば Get-MsolServicePrincipal)を実行しても ObjectNotFound と言われてしまいます。
これは ServicePrincipal 関連のコマンドレッドが含まれるモジュール(MSOnlineExtended)を実行するのに PowerShell 2.0 のエンジンが必要なためです。※コントロールパネルの Windows の機能から見ると PowerShell 2.0 とありますが実際は Version 3.0 が実行されているからです。(プロンプトから $PSVersionTable を実行すると PSVersion の値が 3.0 となっているが確認できます)
この状態を解消するには、 powershell.exe の引数に -version 2.0 をつけて明示的に Version 2.0 で PowerShell を起動し、MSOnline モジュールおよび MSOnline Extended モジュールをインポートする必要があります。
コマンドプロンプトから以下を実行します。
> C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -version 2.0
PowerShell が起動したら以下を実行します。
PS > Import-Module MSOnline
PS > Import-Module MSOnlineExtended
ただ、副作用があり Windows 8 用の Version 2.0 の PowerShell ISE が用意されていないので、Out-GridView などの機能が使えなくなります。。。
早く PowerShell 3.0 用の MSOnlineExtended モジュールがリリースされないかな。。。
2012年11月21日水曜日
Kerberos 認証の設定を確認する
Forefront Identity Manager 2010 (FIM 2010)に限らず Microsoft の製品群は Active Directory を使った Kerberos 認証を多用しています。
こいつです↓(違
図:ケルベロス(笑)
これは、いわゆる「ダブルホップ」と言われる認証の委任を行うことが多いためです。
※もちろん他の理由もありますが。
ダブルホップを知らない方に向けたおさらいですが、Windows ネットワークの世界での認証は一般に NTLM 認証と Kerberos 認証が利用されます。そして、Windows サーバで構成される Web システムといえば、IIS -> SQL Server での2層構造が主流です。
※ブラウザから IIS へアクセスし、IIS が SQL Server へアクセスするという形でホップが2重になっていることからダブルホップと呼ばれます。
この時、NTLM 認証を使っているとクライアントの資格情報を2段階目のホップ(IIS -> SQL Server)へ引き継ぐ(委任)ことが出来ないため、IIS のアプリケーションプールに指定したアカウントを使って SQL Server へアクセスすることになります。アプリケーションプールに指定したユーザアカウントが SQL Server に対して正しくアクセスできる状況であればこの構成でも問題はありませんが、本来はアクセスしてきたユーザの個人アカウントの権限に基づいて SQL Server にアクセスさせたいところです。
図:NTLM 認証フロー
そこで、SharePoint や FIM 2010 をはじめとする Windows で構成された Web システムでは Kerberos 認証を利用します。Kerberos 認証ではユーザの資格情報を委任することが可能となるため、元々のユーザの資格情報を引き継いでバックエンドのサービスへアクセスできます。
図:Kerberos 認証フロー
尚、ダイアグラム内に出てくる SPN(Service Principal Name)については国井さんの blog の以下のエントリを参照してください。
Service Principal Name (SPN) について
と、ここまでは前段なのですが、SPN や Kerberos の設定って往々にして間違えやすいのと間違っていても場合によっては気が付きにくい、という特性があるので、実際のユーザアクセスの中でちゃんと Kerberos 認証が利用できているのか?を確認する必要があります。
そんな時に有用なのが
Kerberos Authentication Tester
http://blog.michelbarneveld.nl/michel/archive/2009/12/05/kerberos-authentication-tester.aspx
です。
簡単に言うと Web リクエストの中で使われた認証方式や Kerberos 認証で使われた SPN などの情報を出力してくれるツールです。
起動して、Url の欄に FIM Portal のアドレスを入れて [Test] をクリックしてみます。
上手く Kerberos 認証を使うように設定できていれば、Authentication type に Kerberos と表示されるはずです。
また、details のリンクをクリックすると更に細かい情報も表示されます。
SharePoint や FIM 2010 を構築した後にとりあえずこのようなツールを使って確認してみると良いと思います。
また、最近は象クラスタの人からも Kerberos が人気なようなので改めて Kerberos 自体のおさらいをしてみるのも良いかも知れません。
2012年11月4日日曜日
VS2012 用の Identity and Access Tool が RTM
遅ればせながら 10月23日にリリースされた Visual Studio 2012 用の Windows Identity Foundation Tools を試してみます。
まず、機能面の紹介です。
基本的には以前の WIF の Federation Utility と変わりませんが、個人的には下記が大きなポイントだと思います。
1.Identity Provider を ローカル STS、ビジネス Identity Provider(AD FS2.0)、Windows Azure Access Control Service から選択できるようになった。
⇒以前は、新しい STS を作成するか、既存の STS を利用するかの選択だった。
2.管理者として Visual Studio を実行しなくても Identity and Access Tool が利用できるようになった。
⇒以前は管理者として Visual Studio を実行しないと Federation Utility が実行できなかった。
3.ACS 側の設定を自動的に作成してくれるようになった。
⇒以前は ACS 上に RP の作成およびクレーム・ルールの作成を手動で行う必要があった。
4.認証されていないリクエストに対するアクションを選択できるようになった。
⇒以前は単純に STS にリダイレクトするだけだったが、今回から加えて controller を生成することが出来るようになった。
特に3番目、4番目については開発者にとって非常に有用な機能なのではないでしょうか?
では、早速試してみます。
■モジュールのダウンロードとインストール
モジュールは vsix 形式で提供されていますので、ダウンロード、実行すると Visual Studio の拡張機能が有効になります。
Identity and Access Tool のダウンロード URL
http://visualstudiogallery.msdn.microsoft.com/e21bf653-dfe1-4d81-b3d3-795cb104066e
■プロジェクトの作成
Controller の自動生成を試してみたいので、今回は MVC4 のプロジェクトを作ってみます。もちろん Visual Studio は管理者で実行しなくても大丈夫です。
テンプレートから web -> ASP.NET MVC 4 Web アプリケーションを選択し、適当な名前を付けてプロジェクトを作成します。
OK をクリックするとプロジェクト テンプレートの選択画面が出てきますが、デフォルトで選択されている[インターネット アプリケーション]を選んだまま OK をクリックします。
■Identity and Access Tool の設定
プロジェクトの作成が終わったら、ソリューションエクスプローラからプロジェクト名を右クリックして表示される[Identity and Access]を開きます。
Choose where your users are from でどの STS を使うのか選択できます。今回は ACS の自動設定を試してみたいので、[Use the Windows Azure Access Control Service]を選択します。
すると、Select one or more providers from the ones configured in the ACS Namespace: で使用する ACS の Namespace の設定を行うリンクが表示されるので、クリックします。
Configure ACS namespace のダイアログが表示されるので、ACS namespace および management key を入力します。
ここで設定する management key は ACS の管理ポータルの管理サービスのパスワードです。
設定が完了し、ダイアログを閉じると ACS 上に設定されている IdP 一覧が取得されて表示されるので、このアプリケーションで利用したい IdP を選択し、一旦 OK をクリックし Identity and Access Tool を閉じます。
ちなみに、このとき ACS 管理ポータルを見ると 証明書利用者アプリケーションとして作成したアプリケーションが登録されていることがわかります。
同様に規則グループも自動生成されます。内容は単なるパススルーなので、必要に応じて編集をしてあげる必要はあります。
■Controller の自動生成
次は、これまた新機能である Controller の自動生成を試します。
再び Identity and Access Tool を起動し、今度は[Configuration]タブを開きます。
すると、Choose how to handle unauthenticated requests という項目があるので、[Generate a controller in your project to handle the authentication experience at the following address]を選択します。
これで、認証されていないリクエストに対応する Controller が生成されましたので、実際に認証が必要なリクエストを行うように設定を行います。
今回はデフォルトの About 画面を認証が必要な画面として定義してみます。
方法は簡単で、HomeController.cs の About() に対して [Authorize] を追加するだけです。
■アプリケーションの実行
では、F5 キーを押して実際にアプリケーションを実行してみます。
起動してきたら[バージョン情報]をクリックします。
すると、ログインページが表示されます。ホームレルム ディスカバリ先として、先ほど ACS から取得してきた IdP 一覧が表示されるのがわかります。
今回は Google を選択してみます。Google アカウントへリダイレクトされ、Account Chooser が表示されるので、使いたいアカウントをクリックします。
認証が終わると、ホーム画面へ戻り、ユーザ名が取得できているのがわかります。
いかがだったでしょうか?非常に単純なサンプルだったので実際は色々とカスタマイズが必要にはなるでしょうが、ほぼノンコードでここまで出来るようになっている、という意味で以前のツールに比べてもかなりの進化を遂げていることがわかります。
ACS を使って多くの外部 IdP ユーザを対象にしたアプリケーションを簡単に開発できるので、EC サイトなど B2C シナリオではかなり有用な機能になるのではないかと思います。
2012年10月31日水曜日
[告知]オラクルセキュリティフォーラムで登壇します
今回はちょっとお仕事の話を。
この blog では流れ上 Forefront Identity Manager ( FIM ) の話をすることが多いのですが、お仕事では FIM に限らず色々なお客様で色々なベンダのソリューションを扱っていたりします。
また、ロールとしては製品やプロトコルなどの技術はあくまで手段なので、プロジェクト管理やアーキテクチャの検討などが実は仕事の中心だったりします。
その意味で、日本ネットワークセキュリティ協会(JNSA)のアイデンティティ管理WGでやっているようなID管理プロジェクトの進め方のベストプラクティスなんていうのが実際のプロジェクトの中でやっていることの実態です。具体的な進め方やノウハウは以下の本の中で紹介しているので、よろしければどうぞ。
- クラウド環境におけるアイデンティティ管理ガイドブック
と、少し話がそれましたが、11月26日に大阪、28日に東京で開催されるセミナで私が実際に担当したプロジェクトの事例を紹介することになりました。(東京開催分のサイトはまだ完成していない様なので、できたらまた紹介します)
東京分は諸事情で先送りになりました。年が明けたらやる可能性がありますので、その時はまた告知すると思います。
- オラクルセキュリティフォーラム in 大阪
http://www.sbbit.jp/eventinfo/14998?ref=rss
http://www.oracle.com/goto/jpm121126
プロジェクトでは Oracle Identity Manager 及び Oracle Enterprise Single Sign On を使っているのですが、セミナで話をするのは主にID管理プロジェクトの円滑な遂行方法のノウハウ、という話になると思います。
エンタープライズID管理を検討している企業情報システム部門の方やSIerの方向けですが、お近くの方は宜しければどうぞ。
この blog では流れ上 Forefront Identity Manager ( FIM ) の話をすることが多いのですが、お仕事では FIM に限らず色々なお客様で色々なベンダのソリューションを扱っていたりします。
また、ロールとしては製品やプロトコルなどの技術はあくまで手段なので、プロジェクト管理やアーキテクチャの検討などが実は仕事の中心だったりします。
その意味で、日本ネットワークセキュリティ協会(JNSA)のアイデンティティ管理WGでやっているようなID管理プロジェクトの進め方のベストプラクティスなんていうのが実際のプロジェクトの中でやっていることの実態です。具体的な進め方やノウハウは以下の本の中で紹介しているので、よろしければどうぞ。
- クラウド環境におけるアイデンティティ管理ガイドブック
と、少し話がそれましたが、11月26日に大阪
東京分は諸事情で先送りになりました。年が明けたらやる可能性がありますので、その時はまた告知すると思います。
- オラクルセキュリティフォーラム in 大阪
http://www.sbbit.jp/eventinfo/14998?ref=rss
http://www.oracle.com/goto/jpm121126
GSユアサのID管理・シングルサインオン導入事例 株式会社GSユアサ 情報システム部 活用推進グループ グループマネージャー 小川 敏宏 氏 伊藤忠テクノソリューションズ株式会社 西日本システム技術部 システム技術第2課 課長 富士榮 尚寛 氏 |
講演内容 : 導入の背景やOracle Identity Management 製品を使用した実際のシステム化による効果を様々な視点から紹介し、本システムを利用した今後の展開を紹介します。 また、今回導入したシステムの概要や、ID管理・シングルサインオン プロジェクトを円滑に進めていくためのポイントをご紹介します。 |
プロジェクトでは Oracle Identity Manager 及び Oracle Enterprise Single Sign On を使っているのですが、セミナで話をするのは主にID管理プロジェクトの円滑な遂行方法のノウハウ、という話になると思います。
エンタープライズID管理を検討している企業情報システム部門の方やSIerの方向けですが、お近くの方は宜しければどうぞ。
2012年10月17日水曜日
[FIM2010]Google Apps MA 1.1.0 をリリースしました
先日リリースした ECMA2.0 用の Google Apps MA をバージョンアップしました。
ダウンロードURL:
http://fim2010gapps.codeplex.com/
改修内容は以下の通りです。
ダウンロードURL:
http://fim2010gapps.codeplex.com/
改修内容は以下の通りです。
- PCNSを使ったパスワード同期をサポート
- プロキシサーバ配下の環境での動作をサポート
- プロキシ認証をサポート
- 属性の更新が値によって失敗するバグを修正
是非使っていただきフィードバックを!
2012年10月15日月曜日
[FIM2010] XMA/ECMA1.0 から ECMA2.0 へ
MIIS や ILM、無印 FIM 2010 時代からのユーザにとっては対応の検討が必要となる情報です。
これまで独自に管理エージェント(MA)を作成する場合に利用されてきたXMA(Extensible Management Agent)/ECMA1.0(Extensible Connectibity Management Agent 1.0)が今後は使われなくなり、最新のフレームワークである ECMA2.0 のみが使われていくことになりました。
With the release of ECMA 2.0, this feature has been depricated and will be removed in future versions. You should use the Extensible Connectivity 2.0 Management Agent Reference for Connector development going forward.
- http://msdn.microsoft.com/en-us/library/ms698807(v=vs.100).aspx
製品から機能が実際に削除されたりサポートが終了するのは少し先になるとは思われますが、以前のフレームワークで開発をしたモジュールを今のうちに ECMA2.0 に対応させていく計画の立案、および可能な限り早い段階での着手をしておく必要がありそうです。
ちなみに私の作成している FIM 用 GoogleApps 管理エージェントは以前の ECMA1.0 版から ECMA 2.0 版へ作り変えが完了しています。
一緒にソースコードも公開しているので、これから ECMA2.0 を使う人は参考にしてみてください。
FIM 2010 GoogleApps MA
- http://fim2010gapps.codeplex.com/
尚、現在バグフィックスおよび機能追加(プロキシ環境での動作、PCNSでのパスワード同期)をしている最中なので、もうすぐ更新版をリリースできると思いますので、ぜひ使ってみてください。
2012年10月14日日曜日
OAuth 2.0 が RFC に!!
最後は draft 31 までになり、出る出る詐欺とか言われ続けてきた OAuth 2.0 ですが、Core と Bearer がようやく RFC になりました。
RFC 6749 - The OAuth 2.0 Authorization Framework
- http://tools.ietf.org/html/rfc6749
RFC 6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage
- http://tools.ietf.org/html/rfc6750
振り返ると OpenID Foundation Japan で翻訳した約1年前にはまだ draft 22 でしたから1年でかなりリビジョンアップされてきたことになります。
参考)OpenID Foundation Japan 翻訳・教育 Working Group での翻訳
OAuth 2.0 core draft 22
- http://openid-foundation-japan.github.com/draft-ietf-oauth-v2-draft22.ja.html
OAuth 2.0 Bearer Token
- http://openid-foundation-japan.github.com/draft-ietf-oauth-v2-bearer-draft11.ja.html
また、途中で Eran Hammer が仕様策定から外れたり、
OAuth 2.0 and the Road to Hell
- http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/
OAuth 3.0 なんていうことを言い始める人が出てきたり、
OAuth 3.0: The Sane and Simple Way To Do It
- http://tav.espians.com/oauth-3.0-the-sane-and-simple-way-to-do-it.html
「今はOpenIDなどセキュリティを外付けにすることが多いが、これは危ない。特にツイッターやFacebookは外部アプリが多いので、変なのがまぎれこんでもわからない。セキュリティだけは内部でやってほしい。」なんて言い始める人が出てきたり(違)と、、、紆余曲折がありましたがようやくの RFC 化、ということで各サービスもようやく重い腰を上げる時が来たかな?と思います。
Windows Azure Active Directory も、、、WRAP 0.9 とか draft-13 を使ってる場合じゃないですね。早くちゃんと対応をしてもらえると。。
まぁ、WAAD 自体は JWT なのでまだこれからなところもありますが、 Mike Jones も書いているように今回の RFC 化が関連仕様を加速すると思われるので、ちゃんとしたものになるのもそれほど遠い先ではないのかもしれません。
2012年9月26日水曜日
[WAAD] REST Client で Graph API を直接実行する
# 一部ご指摘をいただきましたので若干修正(Base64 encode ⇒ Base64 url encode)
Windows Azure Active Directory をアプリケーションから利用する際、 Windows プラットフォームであれば、Windows Azure Authentication Library(AAL)を利用することになると思いますが、折角 RESTful な Graph API があるので、汎用 REST Client を使って API へアクセスしてみたいと思います。
■準備
TenantContextID、AppPrincipalId、SymmetricKey が必要となります。前回同様、CreateServicePrincipal.ps1を使って必要な値を取得します。
用意が出来たらいよいよアクセスしますが、今回やろうとしていることの全体像を簡単に図にしておきます。
まず Graph API を利用するために必要な認可を ACS で受け、ACS から取得した Access Token を持って Graph API を利用する、という流れになります。
実際にやってみると以下のような手順になります。
■Graph API を利用するための Access Token を取得する(REST Client ⇒ ACS)
初めに、Graph API へのアクセスを行うために必要な Access Token を ACS から取得する必要があります。
そのためには ACS へ JSON Web Token(JWT)形式でリクエストを投げる必要があります。
リクエスト先および内容は以下の通りです。
Assertion の部分を作り方は少々面倒ですが、下記の通りです。
・ヘッダ部分を Base64 でエンコード
文字列「{"alg": "HS256","typ": "JWT"}」をこのあたりのツールで Base64 URL エンコードします。
結果、「eyJhbGciOiAiSFMyNTYiLCJ0eXAiOiAiSldUIn0」という文字列が得られます。
・ボディ部分を作成
JWT を構成する、nbf(Not Before / 有効開始時刻)、exp(Expiration Time)クレームは UNIX 時刻(1970年からの経過秒数)で表すため、このあたりのツールを使って現在時刻および現在時刻+1時間を変換した値を取得します。
例えば、2012年9月25日23時00分00秒~2012年9月26日00時00分00秒まで有効なトークンを作成するには、
"nbf" : "1348581600",
"exp" : "1348585200"
というクレームを設定します。
結果、以下の様な JWT ボディを作成します。
{
"aud": "00000001-0000-0000-c000-000000000000/accounts.accesscontrol.windows.net@[TenantContextId]",
"iss": "[AppPrincipalId]@[TenantContextId]",
"nbf": "1348581600",
"exp": "1348585200"
}
・ボディ部分を Base64 でエンコード
先ほどのヘッダ部分と同様に生成した JWT のボディも Base64 URL エンコードします。
結果、「eyJleHAiOiIxMzQ4NTU5MTY4IiwiYXVkIjoiM(以下略)」といった文字列が得られます。
・ヘッダ+ボディを連結した raw token と SymmetricKey でデジタル署名を生成
ヘッダ部分とボディ部分を"."(ピリオド)で連結した raw token を作成し、SymmetricKey を Base64 デコードした文字列を使ってデジタル署名を生成します。
良いオンラインツールがなかったので、以下の Java コードを作成し、署名を生成しました。
※Java であることに深い意味はありません。手元に eclipse が起動していた&Java のサンプルがあった、というだけです。
※どなたか良いオンラインツールがあれば教えてください。
・Assertion の生成
生成した署名文字列を先ほどの raw token の後に同じく"."(ピリオド)で連結します。
このようにして作成した Assertion を他のパラメータと一緒に ACS へ POST します。
リクエストの POST は Chrome Extension の Advanced Rest Client を使いました。
以下の様にパラメータをセットし、[Send request]ボタンをクリックします。
うまくいくと、HTTP 200 が返ってきて、JSON 形式で Access Token が取得できます。
■取得した Access Token で Graph API を利用する(REST Client ⇒ Graph API)
いよいよ Graph API を使います。
リクエスト先および内容は以下の通りです。
先ほどと同様に Advanced Rest Client にパラメータをセットして、[Send request]ボタンをクリックします。
うまくいくと、HTTP 200 が返ってきて、ユーザ一覧が取得できます。
尚、書き込みを行う場合はロール設定が必要になるので、このあたりは次回以降で。。
Windows Azure Active Directory をアプリケーションから利用する際、 Windows プラットフォームであれば、Windows Azure Authentication Library(AAL)を利用することになると思いますが、折角 RESTful な Graph API があるので、汎用 REST Client を使って API へアクセスしてみたいと思います。
■準備
TenantContextID、AppPrincipalId、SymmetricKey が必要となります。前回同様、CreateServicePrincipal.ps1を使って必要な値を取得します。
用意が出来たらいよいよアクセスしますが、今回やろうとしていることの全体像を簡単に図にしておきます。
まず Graph API を利用するために必要な認可を ACS で受け、ACS から取得した Access Token を持って Graph API を利用する、という流れになります。
実際にやってみると以下のような手順になります。
■Graph API を利用するための Access Token を取得する(REST Client ⇒ ACS)
初めに、Graph API へのアクセスを行うために必要な Access Token を ACS から取得する必要があります。
そのためには ACS へ JSON Web Token(JWT)形式でリクエストを投げる必要があります。
リクエスト先および内容は以下の通りです。
Target Endpoint | https://accounts.accesscontrol.windows.net/tokens/OAuth/2 | |
---|---|---|
Method | POST | |
Request Header | Content type | application/x-www-form-urlencoded |
Request Body | grant_type | http://oauth.net/grant_type/jwt/1.0/bearer |
assertion (実際は Symmetric Key でデジタル署名したもの) | { "alg": "HS256", "typ": "JWT" } { "aud": "00000001-0000-0000-c000-000000000000/accounts.accesscontrol.windows.net@[TenantContextId]", "iss": "[AppPrincipalId]@[TenantContextId]", "nbf": "[UNIX 時間で現在の時刻]", "exp": "[UNIX 時間でTokenの有効期限]" } | |
resource | resource : 00000002-0000-0000-c000-000000000000/directory.windows.net@[テナントID] |
Assertion の部分を作り方は少々面倒ですが、下記の通りです。
・ヘッダ部分を Base64 でエンコード
文字列「{"alg": "HS256","typ": "JWT"}」をこのあたりのツールで Base64 URL エンコードします。
結果、「eyJhbGciOiAiSFMyNTYiLCJ0eXAiOiAiSldUIn0」という文字列が得られます。
・ボディ部分を作成
JWT を構成する、nbf(Not Before / 有効開始時刻)、exp(Expiration Time)クレームは UNIX 時刻(1970年からの経過秒数)で表すため、このあたりのツールを使って現在時刻および現在時刻+1時間を変換した値を取得します。
例えば、2012年9月25日23時00分00秒~2012年9月26日00時00分00秒まで有効なトークンを作成するには、
"nbf" : "1348581600",
"exp" : "1348585200"
というクレームを設定します。
結果、以下の様な JWT ボディを作成します。
{
"aud": "00000001-0000-0000-c000-000000000000/accounts.accesscontrol.windows.net@[TenantContextId]",
"iss": "[AppPrincipalId]@[TenantContextId]",
"nbf": "1348581600",
"exp": "1348585200"
}
・ボディ部分を Base64 でエンコード
先ほどのヘッダ部分と同様に生成した JWT のボディも Base64 URL エンコードします。
結果、「eyJleHAiOiIxMzQ4NTU5MTY4IiwiYXVkIjoiM(以下略)」といった文字列が得られます。
・ヘッダ+ボディを連結した raw token と SymmetricKey でデジタル署名を生成
ヘッダ部分とボディ部分を"."(ピリオド)で連結した raw token を作成し、SymmetricKey を Base64 デコードした文字列を使ってデジタル署名を生成します。
良いオンラインツールがなかったので、以下の Java コードを作成し、署名を生成しました。
※Java であることに深い意味はありません。手元に eclipse が起動していた&Java のサンプルがあった、というだけです。
※どなたか良いオンラインツールがあれば教えてください。
import javax.crypto.spec.SecretKeySpec; import javax.crypto.Mac; import org.apache.commons.codec.binary.Base64; public class GenerateSignature { private static byte[] signData(String signingKey, String rawToken) { SecretKeySpec secretKey = null; secretKey = new SecretKeySpec(Base64.decodeBase64(signingKey), "HmacSHA256"); Mac mac; byte[] signedData = null; try { mac = Mac.getInstance("HmacSHA256"); mac.init(secretKey); mac.update(rawToken.getBytes("UTF-8")); signedData = mac.doFinal(); } catch (Exception e) { System.out.println("signData error"); } return signedData; } /** * @param args */ public static void main(String[] args) { String signingkey = "Li7Awy53cq(以下略。SymmetricKey文字列)"; String rawToken = "eyJhbGciOiJ(以下略。ヘッダ部分)).eyJleHAiOiIxMzQ4(以下略。ボディ部分)"; String signature = Base64.encodeBase64String(signData(signingkey,rawToken)); System.out.println(signature); } }
・Assertion の生成
生成した署名文字列を先ほどの raw token の後に同じく"."(ピリオド)で連結します。
このようにして作成した Assertion を他のパラメータと一緒に ACS へ POST します。
リクエストの POST は Chrome Extension の Advanced Rest Client を使いました。
以下の様にパラメータをセットし、[Send request]ボタンをクリックします。
うまくいくと、HTTP 200 が返ってきて、JSON 形式で Access Token が取得できます。
■取得した Access Token で Graph API を利用する(REST Client ⇒ Graph API)
いよいよ Graph API を使います。
リクエスト先および内容は以下の通りです。
Target Endpoint | https://directory.windows.net/[テナントドメイン名].onmicrosoft.com/Users | |
---|---|---|
Method | GET | |
Request Header | Authorization | 取得した Access Token 文字列(bearer 以降) |
x-ms-dirapi-data-contract-version | 0.8 |
先ほどと同様に Advanced Rest Client にパラメータをセットして、[Send request]ボタンをクリックします。
うまくいくと、HTTP 200 が返ってきて、ユーザ一覧が取得できます。
尚、書き込みを行う場合はロール設定が必要になるので、このあたりは次回以降で。。
2012年9月23日日曜日
[FIM] Active Directory への同期に必要な権限
昨日は .NET ラボさんの勉強会で FIM / AD FS2.0 のハンズオンを実施しました。
回線の混雑具合や時間配分的な問題で用意していたシナリオを終えることは無理があったのですが、いずれリベンジをしたいと思っています。
さて、ハンズオン環境を作る上で一つ入れ忘れていた設定があり参加者の方にご迷惑をかけた点があり、結構忘れがちな設定でもあるのでこの機に書いておこうと思います。
FIM をはじめアイデンティティ管理ツールを使って Active Directory 上のユーザを作成・変更・削除する、というシナリオは企業内ではごく一般的なものだと思います。
その際に、Active Directory 上のオブジェクトをメンテナンスするためのユーザとその権限をどうするのか?というポイントは慎重に検討する必要があります。
実際には Active Directory の管理者とアイデンティティ管理システムの管理者が同じ人や組織なので何も考えずに Domain Admins の権限を持ったユーザや Administrator ユーザそのものをアイデンティティ管理システム上に設定してしまったりしている例も多いと思いますが、出来れば必要最低限の権限を持ったユーザを使いたいところです。
結論から書くと、FIM の場合は以下の2つの権限が必要になります。
・デフォルトネーミングコンテキストに対するディレクトリ・レプリケーションの権限
・管理対象オブジェクトを格納する OU および子オブジェクトに対するフル・コントロール
※デフォルトネーミングコンテキストとは、LDAP 文字列でいうところの DC=xxx,DC=xxx にあたる部分です。
もちろん手動で Active Directory ユーザとコンピュータ から権限を設定することも可能ですが、特にディレクトリ・レプリケーション権限は特殊権限なので設定をするのが面倒です。
そこで通常は DSACLS.EXE を使った以下のようなスクリプト(PowerShell の例)を実行して一気に設定を入れてしまいます。
勉強会でも話をしましたが、 FIM の設定は周辺を含め非常に面倒です。
このようなスクリプトをネタとして持っておいて使いまわす、というのがベストプラクティスなのだと思います。
回線の混雑具合や時間配分的な問題で用意していたシナリオを終えることは無理があったのですが、いずれリベンジをしたいと思っています。
さて、ハンズオン環境を作る上で一つ入れ忘れていた設定があり参加者の方にご迷惑をかけた点があり、結構忘れがちな設定でもあるのでこの機に書いておこうと思います。
FIM をはじめアイデンティティ管理ツールを使って Active Directory 上のユーザを作成・変更・削除する、というシナリオは企業内ではごく一般的なものだと思います。
その際に、Active Directory 上のオブジェクトをメンテナンスするためのユーザとその権限をどうするのか?というポイントは慎重に検討する必要があります。
実際には Active Directory の管理者とアイデンティティ管理システムの管理者が同じ人や組織なので何も考えずに Domain Admins の権限を持ったユーザや Administrator ユーザそのものをアイデンティティ管理システム上に設定してしまったりしている例も多いと思いますが、出来れば必要最低限の権限を持ったユーザを使いたいところです。
結論から書くと、FIM の場合は以下の2つの権限が必要になります。
・デフォルトネーミングコンテキストに対するディレクトリ・レプリケーションの権限
・管理対象オブジェクトを格納する OU および子オブジェクトに対するフル・コントロール
※デフォルトネーミングコンテキストとは、LDAP 文字列でいうところの DC=xxx,DC=xxx にあたる部分です。
もちろん手動で Active Directory ユーザとコンピュータ から権限を設定することも可能ですが、特にディレクトリ・レプリケーション権限は特殊権限なので設定をするのが面倒です。
そこで通常は DSACLS.EXE を使った以下のようなスクリプト(PowerShell の例)を実行して一気に設定を入れてしまいます。
# Active Directory からネーミングコンテキストを取得 $RootDse = [ADSI] "LDAP://RootDSE" $DefaultNamingContext = $RootDse.defaultNamingContext # 対象ユーザの SID を取得 $UserPrincipal = New-Object Security.Principal.NTAccount("<NetBOISドメイン名>", "<利用するユーザ名>") $SID = $UserPrincipal.Translate([System.Security.Principal.SecurityIdentifier]).Value # ディレクトリ・レプリケーション権限を付与 DSACLS "$DefaultNamingContext" /G "$($SID):CA;Replicating Directory Changes"; # 対象 OU および子オブジェクトへのフル・コントロール権限を付与 DSACLS "<対象 OU 名>,$DefaultNamingContext" /G "$($SID):GA" /I:T
このようなスクリプトをネタとして持っておいて使いまわす、というのがベストプラクティスなのだと思います。
2012年9月13日木曜日
[WAAD]スタンドアロンのテナントが作成可能に
これまでは Windows Azure Active Directory(WAAD) を使おうとすると、Office365 など WAAD をアイデンティティ基盤として利用するサービスを登録する必要がありましたが、今回まだプレビューですが直接 WAAD のみにサインアップすることが可能になりました。
これまで WAAD を使うのに何度も Office365 の評価版のサインアップをしていたのでこのように単体でサインアップできるようになったのは非常に便利です。
サインアップは以下のURLから実施します。
http://g.microsoftonline.com/0AX00en/5
ようやく Graph API を検証し始めているので、そのうち情報をアップしたいと思います。
2012年9月11日火曜日
[WAAD] Preview ポータルのLook & Feel
Windows Azure Active Directory の管理ポータルの Preview 版が出てきています。
https://activedirectory.windowsazure.com
今後はこのポータルから Office 365 などを含むアカウントの管理や設定を行うことになると思いますので、新しいポータルに慣れておきたいところです。
ということで、新旧ポータルの画面を単純に並べて比較しておきます。
(旧: Office365 の管理者ポータル。新: Windows Azure Active Directory 管理ポータル Preview)
トップ画面
【旧】
【新】今は Office365 の情報しか出ていませんが、今後は他のサービスに関する情報も表示されることになるんでしょうか。 ※ Windows Intune / Dynamics Online は触ったことがないので、今でもここに出てくるかは不明です。どなたか知ってますか?
ユーザ
【旧】
【新】シングルサインオンやディレクトリ同期が別メニューへ移動したので非常にシンプルになっています。
セキュリティグループ
【旧】
【新】
ドメイン
【旧】
【新】この辺りはあんまり変わりません。
シングルサインオンなど
旧ポータルではユーザの管理の中にあったメニューが「統合」メニューに別出しされています。
【新】すっきりしました。
と、ざっと並べてみました。
今後は新しいポータルで管理を行うことになると思いますので、早めに慣れておきましょう。
(という程違いはありませんが。。)
https://activedirectory.windowsazure.com
今後はこのポータルから Office 365 などを含むアカウントの管理や設定を行うことになると思いますので、新しいポータルに慣れておきたいところです。
ということで、新旧ポータルの画面を単純に並べて比較しておきます。
(旧: Office365 の管理者ポータル。新: Windows Azure Active Directory 管理ポータル Preview)
トップ画面
【旧】
【新】今は Office365 の情報しか出ていませんが、今後は他のサービスに関する情報も表示されることになるんでしょうか。 ※ Windows Intune / Dynamics Online は触ったことがないので、今でもここに出てくるかは不明です。どなたか知ってますか?
ユーザ
【旧】
【新】シングルサインオンやディレクトリ同期が別メニューへ移動したので非常にシンプルになっています。
セキュリティグループ
【旧】
【新】
ドメイン
【旧】
【新】この辺りはあんまり変わりません。
シングルサインオンなど
旧ポータルではユーザの管理の中にあったメニューが「統合」メニューに別出しされています。
【新】すっきりしました。
と、ざっと並べてみました。
今後は新しいポータルで管理を行うことになると思いますので、早めに慣れておきましょう。
(という程違いはありませんが。。)
登録:
投稿 (Atom)