2014年10月2日木曜日

[AD FS] Windows Server Technical PreviewのAD FSを試す

世の中 Windows 10 という流れですが、いつもの通り Server OS がどうなるかの方が気になってしまうので早速確認してみました。
こういう時、Azure VM は便利ですね。一瞬で試せる環境が手に入ります。

Windows Server Technical Preview のデスクトップ
Server Version は Windows Server 2012 R2 のままです。


ちゃんとスタートメニューも復活しています。



外観は良いとして、確認してみたのは AD FS がどう変わったのか?です。

結論は「そんなに変わっていないけど、便利な機能がついてるっぽい」という感じなので、早速見ていきます。


■インストール
ここははっきり言って何も変わっていません。
見慣れた画面です。



■構成ウィザード
ここも全く変わりません。


■管理コンソール
ちょっと変わってます。

◇メニュー
移動したメニュー、見慣れないメニューがあります。
 ・Device Registration がメニューとして独立、Service の中に入っています。
 ・Policy Templates メニューが追加されています。


◇バージョン
6.4.0.0になってます。
※Windows Server 2012 R2 では 6.3.0.0 でした。


■管理コンソールで変わった部分の詳細

変わった部分をちょっと詳しく確認します。

◇DRS ( Device Registration Service )
 DRS を有効にするには Device 情報を Active Directory 上に登録出来るように PowerShell より「Enable-AdfsDeviceRegistration -PrepareActiveDirectory」 としてスキーマ拡張をする必要がありましたが、今回からウィザードで構成出来るようになっています。

ちなみにウィザードを使うにはちゃんとした(AD DSのドメインサフィックスとAD FSが使う証明書のCNのサフィックスが同じ)サーバ証明書を入れる必要があるので、今回は試せてません。
(適当な証明書で AD FS を構成したので...orz)

◇Policy Templates
 完全に新しい機能っぽいので、まだ使い方がよく分かっていませんが、クレームの要求ルールを作成するのを補助してくれるツールっぽいです。

こんな感じのルールエディタがついています。
(例えばメールアドレスがあれば、、みたいなルールが書けそうです)



テンプレートを作成すると一覧に In use by RP とあるので、適用する RP がどこかで選択できるような気がするんですが、現状該当する設定箇所を見つけられていません。。。
見つけたら更新します。。



■SAML 2.0 IdP として使ってみる
軽く Google Apps とつないでみます。
当然ですが何も変わりません。







まだまだ Technical Preview の段階なので何とも、、ですが、ポリシーの部分が楽になりそうなので、今後が楽しみです。

2014年9月17日水曜日

ID&IT Management Conference 2014が開催されます

本日と明後日、東京と大阪それぞれで今年もID & IT Management Conferenceが開催されます。

 http://nosurrender.jp/idit2014/




昨年はJNSAのアイデンティティ管理WGとしてID管理システム導入時の要求定義のポイントについてパネルディスカッションを担当させてもらいましたが、今年は標準化が熱い!ということでグローバルスタンダードについてのパネルに出演させていただきます。

特に昨年~今年はOAuth2.0のRFC化やOpenID Connectの正式リリースなどアイデンティティに関する標準化に伴い、Microsoft Azure ADやSalesforce.com Identity、Ping IdentityのPing Oneなどの主要なIDaaS(Identity as a Service)ベンダが相次いで標準をサポートした年でした。
ただ、実際の導入の現場では標準かどうか?よりも各社に固有の事情に対応することの方が当然優先されるわけで、中々標準に目が行くことはありません。ということでSIer目線でID管理プロジェクトの現場ではどんなことを考えているか?という話をしようと思います。



 ※ちなみに昨年度の話はこちら


当日になってしまいましたが、お手隙の人は是非いらしてください。

私も午後から大阪へ向かいます...orz )某所のホテルの部屋にて。。

2014年9月7日日曜日

続Azure ADのSAML対応(IdP編)~SP Initiatedに対応

前回のPOSTで現状Azure Active DirectoryのSAML IdP対応はIdP Initiatedだけ、という話をしましたが、直近(9/3)のアップデートでSP Initiatedに対応しました。

 TechnetのActive Directory Teamのブログ
 - 50+ SaaS Apps and growing now support federation with Azure AD!
  http://blogs.technet.com/b/ad/archive/2014/09/03/50-saas-apps-now-support-federation-with-azure-ad.aspx

ブログ本文の本筋はたくさんのSaaSアプリケーションがAzure ADとのフェデレーションに対応したよ、ということなんですが下の方にちょろっとSP Initiated対応!と書いてあります。
これでようやくアプリケーションポータルを経由しなくてもSaaSアプリを使うことが出来ます。

と、言うことで試してみます。
と言っても設定はこれまでと何ら変わりません。今回もGoogle Appsを使います。

①Azure ADの管理コンソールからGoogle Appsを追加し、構成を行います。

 まずはGoogle Appsのドメインを指定します。

 Google Appsに設定する情報が出てくるので、証明書のダウンロードします。


②Google Appsのセキュリティ設定からシングルサインオン設定を行います。
 先ほどダウンロードした証明書のアップロード、各種URLの設定を行います。
 この時、「ドメイン固有の発行元を使用」にチェックを入れておくことを忘れないようにしてください。(前回はこれを入れていなかったからダメだっただけかも知れません。。)

③Azure ADのコンソールでGoogle Appsを使うユーザを追加、選択します。
 ※アプリケーションの構成でプロビジョニングを有効にしておく必要があります。
 Google Appsと同じドメインをAzure ADにも追加し、対象のドメインにユーザを作り、割り当てを行います。


④Google AppsへアクセスするとAzure ADのサインイン画面へリダイレクトされるので、先ほど追加したユーザでサインインします。


すると、無事にGoogle Apps(今回はGmail)が利用できます。




同じようなやり方でカスタムアプリや他のサービスも使えると思いますので、エンタープライズにおける利活用の選択肢がだいぶ拡がったと思います。


2014年8月1日金曜日

Azure ADのSAML対応(IdP編)

Azure Active DirectoryのIdentity Providerとしての機能について、先日の.NETラボ勉強会で話をしましたが、そういえば説明してなかったなぁ、、と思うのがSAMLの対応状況です。

当日の勉強会資料はこちら
 


実は、現状ではAzure ADをSAML IdPとして使う際はIdP起動(IdP Initiated)のユースケースしか対応していません。

つまり、例えばGoogle AppsのようなサービスとのID連携が出来るようになったと言っても、これまで@ITなどで紹介してきた様に、
①サービス(SP)へアクセス
②AzureAD(IdP)へリダイレクト
③認証後、サービスへ戻って利用開始
という流れではサービス利用が出来ない、ということです。

参考)クラウド・サービスと社内システムとのID連携
  第4回 Google AppsとのID基盤連携を実現する
  http://www.atmarkit.co.jp/ait/articles/1301/16/news122.html



実際にGoogle AppsをAzure ADで認証するように構成して、https://mail.google.com/a/<テナントドメイン>へアクセスすると以下のようなエラーが発生します。


Azure ADのアプリケーションアクセス権限はもちろん割り当てているのですが、何とも分かりにくいエラーが出ます。




通信をトレースしてみると、以下のような流れになっています。


①サービスへアクセス
 GET https://mail.google.com/a/<テナントドメイン>/ HTTP/1.1
 ⇒HTTP 302
  Azure ADへリダイレクト

②Azure ADへの認証要求
 GET https://login.windows.net/25461215-0c1f-4dc2-bffc-63e6e6f3f759/saml2?SAMLRequest=xxx&RelayState: https://www.google.com/a/<テナントドメイン>/ServiceLogin?service=mail&passive=true&rm=false&continue=https%3A%2F%2Fmail.google.com%2Fa%2F<テナントドメイン>%2F&ss=1&ltmpl=default&ltmplcache=2&emr=1 HTTP/1.1

 実際のSAML Requestは以下の通り
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
                    ID="eafkldjajjdlncljdmnihogjokolljjfdooaboee"
                    Version="2.0"
                    IssueInstant="2014-07-31T14:34:01Z"
                    ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
                    ProviderName="google.com"
                    IsPassive="false"
                    AssertionConsumerServiceURL="https://www.google.com/a/domain/acs"
                    >
    <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">google.com</saml:Issuer>
    <samlp:NameIDPolicy AllowCreate="true"
                        Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
                        />
</samlp:AuthnRequest>


 ⇒HTTP 302
  Azure ADの認証サービスへリダイレクト(ws-federationでID連携)

③login.microsoftonline.comへ認証要求
 GET https://login.microsoftonline.com/login.srf?wa=wsignin1.0&wreply=https%3a%2f%2flogin.windows.net%2f<テナントID>%2fwsfedisvacs&wp=MBI_FED_SSL&wctx=xxx HTTP/1.1

 ⇒ログイン画面表示

④ID/パスワードでログイン
 POST https://login.microsoftonline.com/ppsecure/post.srf?wa=wsignin1.0&wreply=https%3a%2f%2flogin.windows.net%2f<テナントID>%2fwsfedisvacs&wp=MBI_FED_SSL&wctx=xxx HTTP/1.1

⑤SAMLトークンを受け取り、Azure ADへPOST(ws-federationプロトコル)
 POST https://login.windows.net/<テナントID>/wsfedisvacs HTTP/1.1

 ⇒HTTP 400 Bad Request
  エラー!!先ほどの画面が表示される。



なかなか一筋縄ではいきません。
現状の解としてはアプリケーション・パネル(https://myapps.microsoft.com)からアプリケーションを立ち上げてIdP-InitiatedでID連携をすることとなります。

アプリケーション・パネル




ここからアプリケーション(Google Apps)を選択すると同じくSAMLを使ったID連携が行われて、サービスへログインできます。



このパターンの連携の流れは以下の通りです。

①アプリケーション・アイコンをクリック
 GET https://account.activedirectory.windowsazure.com/applications/redirecttofederatedapplication.aspx?Operation=SignIn&applicationId=<アプリケーションID>&ApplicationConstName=googleapps&SingleSignOnType=Federated&ApplicationDisplayName=Google+Apps HTTP/1.1

②SAML認証要求を発行
 GET https://login.windows.net/<テナントID>/saml2?SAMLRequest=xxxx&RelayState=https%3a%2f%2fwww.google.com%2fa%2facs%2fServiceLogin%3fservice%3dmail%26passive%3dtrue%26rm%3dfalse%26continue%3dhttps%253A%252F%252Fmail.google.com%252Fa%252Facs%252F%26ss%3d1%26ltmpl%3ddefault%26ltmplcache%3d2 HTTP/1.1

 この時のSAMLリクエストは以下の通り
<samlp:AuthnRequest xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
                    ID="ide478f3cb10e54fd2882a3c68d24cd34a"
                    Version="2.0"
                    IssueInstant="2014-07-31T15:07:18.210Z"
                    IsPassive="false"
                    AssertionConsumerServiceURL="https://www.google.com/a/domain/acs"
                    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
                    >
    <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://google.com</Issuer>
    <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" />
</samlp:AuthnRequest>


③login.microsoftonline.comへ認証要求(シングルサインオン)
 GET https://login.microsoftonline.com/login.srf?wa=wsignin1.0&wreply=https%3a%2f%2flogin.windows.net%2f<テナントID>>%2fwsfedisvacs&wp=MBI_FED_SSL&wctx=xxx HTTP/1.1


④SAMLトークンをAzure ADへPOST(ws-federationプロトコル)
 POST https://login.windows.net/<テナントID>/wsfedisvacs HTTP/1.1


⑤SAMLトークンを発行し、Google AppsのACS(SP)へPOST
 POST https://www.google.com/a/<ドメイン>/acs HTTP/1.1

 POSTするSAML Responseは以下の通り
<samlp:Response ID="_cfa4d9a3-07f2-43b3-8721-ec009a314a42"
                Version="2.0"
                IssueInstant="2014-07-31T15:20:21.298Z"
                Destination="https://www.google.com/a/domain/acs"
                InResponseTo="ide478f3cb10e54fd2882a3c68d24cd34a"
                xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
                >
    <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">https://sts.windows.net/tenant/</Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
            <ds:Reference URI="#_cfa4d9a3-07f2-43b3-8721-ec009a314a42">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
                    <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
                <ds:DigestValue>vldBy5BDCPN1SosH0pbBECXLspqjexOKf/CzGfvwhhA=</ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>SlEnVqcu--snip--cPDdkxuJMmg==</ds:SignatureValue>
        <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
            <ds:X509Data>
                <ds:X509Certificate>MIIDPjC--snip--Lg4rOBcXWLAIarZ</ds:X509Certificate>
            </ds:X509Data>
        </KeyInfo>
    </ds:Signature>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
    </samlp:Status>
    <Assertion ID="_28c961d7-b93e-4c21-88d9-62977d2ce849"
               IssueInstant="2014-07-31T15:20:21.298Z"
               Version="2.0"
               xmlns="urn:oasis:names:tc:SAML:2.0:assertion"
               >
        <Issuer>https://sts.windows.net/tenant/</Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
                <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
                <ds:Reference URI="#_28c961d7-b93e-4c21-88d9-62977d2ce849">
                    <ds:Transforms>
                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
                        <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
                    </ds:Transforms>
                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
                    <ds:DigestValue>swSVM5OvOHWnGp105KYZbMer4xuiJ0O9knGGBP4g/Us=</ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>V2Sbe7Ww--snip--okg==</ds:SignatureValue>
            <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
                <ds:X509Data>
                    <ds:X509Certificate>MIID--snip--arZ</ds:X509Certificate>
                </ds:X509Data>
            </KeyInfo>
        </ds:Signature>
        <Subject>
            <NameID>ieyasut@domain</NameID>
            <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
                <SubjectConfirmationData InResponseTo="ide478f3cb10e54fd2882a3c68d24cd34a"
NotOnOrAfter="2014-07-31T15:25:21.298Z"
Recipient="https://www.google.com/a/domain/acs"
/>
            </SubjectConfirmation>
        </Subject>
        <Conditions NotBefore="2014-07-31T15:20:21.005Z"
                    NotOnOrAfter="2014-07-31T16:30:21.005Z"
                    >
            <AudienceRestriction>
                <Audience>http://google.com</Audience>
            </AudienceRestriction>
        </Conditions>
        <AttributeStatement>
            <Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname">
                <AttributeValue>ieyasu</AttributeValue>
            </Attribute>
            <Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname">
                <AttributeValue>tokugawa</AttributeValue>
            </Attribute>
            <Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name">
                <AttributeValue>ieyasut@domain</AttributeValue>
            </Attribute>
            <Attribute Name="http://schemas.microsoft.com/identity/claims/tenantid">
                <AttributeValue>tenant</AttributeValue>
            </Attribute>
            <Attribute Name="http://schemas.microsoft.com/identity/claims/objectidentifier">
                <AttributeValue>4ce14587-d409-420e-82a2-7957867c6d20</AttributeValue>
            </Attribute>
            <Attribute Name="http://schemas.microsoft.com/identity/claims/identityprovider">
                <AttributeValue>https://sts.windows.net/tenant/</AttributeValue>
            </Attribute>
        </AttributeStatement>
        <AuthnStatement AuthnInstant="2014-07-31T15:15:13.000Z"
                        SessionIndex="_28c961d7-b93e-4c21-88d9-62977d2ce849"
                        >
            <AuthnContext>
                <AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</AuthnContextClassRef>
            </AuthnContext>
        </AuthnStatement>
    </Assertion>
</samlp:Response>



⑥Google Appsへのログイン処理(シングルサインオン)
 GET https://www.google.com/accounts/ContinueSignIn?sarp=1&continue=https%3A%2F%2Fmail.google.com%2Fa%2Facs%2F&plt=xxx&scc=0&service=mail HTTP/1.1

 ⇒Gmail画面の表示



いかがでしょうか?
単純にSAMLプロトコルに対応した、と言ってもどこまで対応しているかを知っておかないと利用イメージが違う、、という話になりかねないので、しっかりと押さえておかないといけませんね。

2014年7月23日水曜日

エンタープライズロール管理解説書(第2版) がJNSAアイデンティティ管理WGよりリリース

エンタープライズロール管理解説書の第1版がリリースされてから約1年、改版されたロール管理解説書がリリースされました。

エンタープライズロール管理解説書(第2版)
 http://www.jnsa.org/result/2014/idm_guideline/index.html


JNSAのアイデンティティ管理WGでも「パンドラの箱」と言われ続けてきたロール管理ですが、前回、今回と議論が深まり、企業内でより活用しやすい形にまとまっていると思います。

以下、目次です。

  • ロール管理の定義
  • ロール管理の意義
  • ロール管理導入の流れ
  • ロール管理導入における課題
    • 現状調査・企画フェーズ
    • ロール設計フェーズ
    • 実装方式設計フェーズ
    • 実装・移行・展開フェーズ
  • ロール管理の適正な運用の重要性
    • ロール管理運用の観点
    • トリガイベント分類ごとのロール管理運用のガイドライン
  • 金融業の仮想企業におけるロール管理導入事例


ロールとは何なのか?ビジネスロールとITロールの分け方や関連など概念的な話から実際にロール管理を実装する各フェーズにおいて考えるべき事項、運用面での注意点、そして最後に仮想企業における導入イメージなどこれからロール管理を検討しようとしている企業にとって非常に有用な内容になっていると思いますので、是非ダウンロードして読んでみてください。





2014年6月17日火曜日

[告知]登壇予定(Office365、AAD、Identity)

最近はblogの更新もままならないほど忙しい日々なんですが、そんな中2本ほどイベントでお話をさせていただきます。いずれもAzure AD/Office365関係のアイデンティティ管理・フェデレーションの話の予定です。


■6/21(土)@大阪
SQL Worldさん
http://sqlworld.org/event/20140621/

タイムテーブルはこんな感じです。
時間内容スピーカー
13:05 -開場 
13:15 -ご挨拶 
20分 程度O365 概要(仮)SQLWorld 遥佐保
50分 程度O365 SharePointSQLWorld リシュ ジミー
20分 程度PowerBI + O365 の紹介SQLWorld お だ
10分 程度おやつタイム 
50分 程度運用を見据えた失敗しないOffice365導入(仮)Office365 MVP 渡辺元気 さん
50分 程度Office365とアイデンティティ(仮)FIM MVP 富士榮尚寛 さん


Office365、というかAADの話(ID管理、ID連携)をGraphAPIとかフェデレーションの仕組みの話とかをさせていただく予定です。


■6/28(土)@東京
.NETラボさん
http://www.dotnetlab.net/dnn/2014/05/net%E3%83%A9%E3%83%9C-%E5%8B%89%E5%BC%B7%E4%BC%9A-2014%E5%B9%B46%E6%9C%88-2/


こちらのタイムテーブルはこんな感じ。
■タイムテーブル
13:00 開場
13:15-13:30 「.NETラボ紹介」(.NETラボ スタッフ)
13:30-14:00「認証系を勉強する1日を企画したわけ」(Microsoft MVP for Client App Dev 高尾 哲朗)
14:00 – 17:00 「Office365の認証回りの仕様の移り変わりと運用上の苦労話」(Microsoft MVP for Office365 渡辺 元気)
「ADFS+Office365によるセキュリティ強化 デバイス認証、多要素認証編」(Microsoft MVP for Directory Services 国井 傑)
「AADとIdentity管理」(Microsoft MVP for Forefront Identity Manager 富士榮 尚寛)
Microsoft エバンジェリスト 安納さん(調整中)
17:00-17:30 「ライトニングトーク&ディスカッションタイム」
17:30 「グリーティングアワー」
18:00 終了


まぁ、似たような話をします。
ちょっと開発寄りな話になるかも知れません。


資料が全然できていないので、頑張って作ろうと思いますので、お時間のある方は是非・・・

2014年6月14日土曜日

[AAD/Office365]AAD Sync Betaを試す

しばらく時間が経ってしまいましたが、5月末に現在のディレクトリ同期ツール(DirSync)の後継となるAzure Active Directory Sync(AADSync)のベータ版がConnectサイトに公開されました。

 ダウンロードサイト(要登録)
 https://connect.microsoft.com/site433/Downloads/DownloadDetails.aspx?DownloadID=53361

 関連ポスト:
 [AAD/Office365]AAD Sync(次世代ディレクトリ同期)でクラウドのパスワードをオンプレミスへ
 http://idmlab.eidentity.jp/2014/04/aadoffice365aad-dync.html


基本は現在のディレクトリ同期と同様にForefront Identity Manager 2010 R2(FIM)ベースですが、より簡単に同期ルールを設定できるようなツールも付属しています。
これでディレクトリ同期ツールの手軽さとFIMの柔軟さの両方の良いところを活かすことが出来るようになります。
また同時にかねてからの課題であったマルチフォレスト環境への対応や.localドメインなどの課題へも対応できるようになっています。

今回は簡単にインストール~同期をした結果を載せてみます。


まず、注意事項ですが日本語環境ではBeta版のインストールは出来ませんので、英語環境にしてください。(OSインストールは日本語でも構いませんが、言語の追加で英語を追加し、表示言語を英語にした状態でインストールする必要があります)

ちなみに、当然のことながら事前にAzure AD上にディレクトリ同期を有効にしておく必要があります。

では始めます。

■インストール
モジュールをダウンロードして実行するとモジュールの展開・インストールが行われて自動的に設定が開始されます。

まずはAADへの接続情報の入力です。ここで入力するユーザはテナントの全体管理者の権限を持っている必要があります。


続いてオンプレミスのADDSの情報です。注目すべきはAdd Forestボタンです。
ここで複数のフォレストの情報を登録することでマルチフォレスト環境でもディレクトリ同期が出来ます。


設定したフォレスト情報が表示されているのがわかります。


次に2つの設定を行います。

一つ目はAcount Joinです。
これは複数のフォレストを同期する場合にアカウントを一意に識別してあげる必要があるのですが、その際に使用する属性を選択します。今回はシングルフォレスト構成なので、「My users are only represented once across all forests」を選択します。

二つ目はIdentity federationです。
AzureADとフェデレーションを行う場合にどの属性を使ってアカウントを紐づけるか?という設定です。AzureAD側ではImmutableIdという属性を使います。
これまでのディレクトリ同期ではobjectSidをBase64エンコードした値を使っていましたので、ShibbolethなどAD FS以外のSAML2.0 Identity Providerと接続する際は結構面倒だったのですが、今回からAAD側と紐づけをするための属性を自分で選択できるようになりました。

今回はUserPrincipalNameを選んでいます。


これまで通りHybrid環境のExchangeがある場合の設定もできます。


ここまで来たらもうすぐです。

完了です。その場で同期するならチェックしたままでFinishをクリックします。

とりあえず初期同期が走ります。

何の設定もしていないので、AADSyncを実行するユーザが同期されています。

ついでにグループも同期されています。これもゴミグループですね。。。



■同期ルール設定
これまではサポート外になるのを承知でmiisclientを使って同期ルールを編集することはできましたが、今回からは公式に同期ルールを編集するための簡易ツールがついてきます。

Synchronization Rule Editorが追加される。Synchronization Serviceは従来のmiisclient。


インバウンドとアウトバウンドの同期ルールが一覧で表示されるので、必要なモノを選択してEditをクリックすると編集できます。

ちなみにアウトバウンドはこんな感じ。AADへ連絡先、グループ、ユーザを同期するための設定が並んでいます。


試しにアウトバウンドのルールの編集をしてみます。

同期スコープも編集できます。これで特定のグループのユーザだけ同期する、なんていうことも簡単にできます。

このあたりがAADとオンプレミスのアカウントの紐づけです。どの属性で紐づけるかを選択できるので、例えばオンプレミスが.localドメインだった場合でもメールアドレスなどの属性を使って紐づけることが出来るようになります。

属性の接続など変わったことも出来ます。


ちなみに従来のmiisclientもSynchronization Serviceを開くと使えます。

ちなみにバージョン情報を見てもFIMの面影は消し去られています。。。


先日のOffice365の新機能発表でAzure AD Premiumの有償オプションだった多要素認証についてもMFA for Office365という形でサブスクライバへ無償提供されることが発表されていますし、このようにFIMを使わなくてもかなり柔軟にディレクトリ同期が出来るようになってきている、ますます簡単で便利な環境が提供されてきているので今後の展開が非常に楽しみです。