AD FS2.0 で Office365 への認証連携を行う

# はじめに
# ベータ版の Office365 をベースに実験した結果ですので正式版で使える情報とは限りません。

長らく待った Office365 のベータがやっと使えるようになったので早速 AD FS2.0 を使った認証連携を設定してみました。
細かい手順は ブチザッキさんで紹介されているので、基本的にはそちらを参照してもらえれば良いと思いますが、今回は以前紹介した制限事項の確認がポイントです。

以前のポストで紹介した制限（前提）事項は以下の2点でした。
１．オンプレミスのActive DirectoryのUPN属性がインターネットから解決出来る必要がある
　→下手に.localドメインで社内ADを構築しているとかなり大幅な変更になるかも知れません。他のアプリケーションへの影響もあるでしょうし。。FIM2010などの自動化ツールは必須かも知れません。
２．Office365からのドメインの正当性確認を受ける必要がある
　→LiveIDとのFederationの時にもはまりましたが、Office365というかMFG（Microsoft Federation Gateway）が認めてくれる必要があります。証明書の発行元はシビアです。。


結論から言いますと両方とも気にする必要はありますが回避することができます。

まず簡単な方の２からお話しをしますが、こちらは実際には「ドメインの所有確認さえできれば良い」です。つまり AD FS2.0 が使う証明書が信頼できる証明機関からの発行であろうと自己署名の証明書であろうと関係ない、ということです。
これは Google Apps を独自ドメインでホストするのと同じ考え方なのですが、シングルサインオン（認証連携）を設定する際には Office365 を独自ドメインで運用することになりますので、手持ちのドメインの CNAME レコードに Office365 が指定する値を設定することでドメインの所有確認を行います。


次に１の UPN 属性問題です。既に運用している Active Directory の UPN 属性を変更するのは非常に困難です。

図：UPN のドメインパート（@以下）は固定されている









※4/19追記（MSの方にご指摘をいただきました） ここに記載されている方法でドメインにUPNサフィックスを追加することによって各ユーザのUPNを変更することができるようになります。ただし、結局は各ユーザのUPNを変更することにはなるので、他のアプリケーションへの影響などを十分にテストするか、今回紹介する方法でUPNを変えずに運用できる方法を検討することになりそうです。

こうなると UPN 属性を変更するためには FIM2010 などの IdM ツールが必要になってしまいますし、動いているドメインの UPN 属性を変更することの影響度の調査などなかなかハードルが高い話になってしまいます。

では、UPN 属性を変えずに既存ドメインユーザを使った認証連携を行うにはどうすればよいのでしょうか？

そのためにはまず Office365 との認証連携において UPN 属性がどのように使われているのか？を理解する必要があります。
認証連携を行うための環境を構築するためには Microsoft Online Services ID フェデレーション管理ツールをインストールして、
　convert-MSOLDomainToFederated -DomainName <ドメインのFQDN>
というコマンドレットを実行します。
このコマンドレットを実行すると AD FS2.0 の Relying Party として Microsoft Federation Gateway が自動的に登録されるのですが、その RP の要求規則ルールを見ると以下のように設定がされています。

【ルール１】
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]
=> issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/claims/UPN", "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"), query = "samAccountName={0};userPrincipalName,proxyAddresses,objectGUID;{1}", param = regexreplace(c.Value, "(?[^\\]+)\\(?.+)", "${user}"), param = c.Value);

【ルール２】
c:[Type == "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"]
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Value = c.Value, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified");


ルール１を見ると userPrincipalName を加工して UPN クレームとしてトークンを発行していることがわかります。( 4/15 修正：nameidentifier には ObjectGUID が入ります )
では、逆に言うと userPrincipalName ではない別の属性に Office365 で使うカスタムドメインのユーザ名を設定してこのルール１の要求規則を変更してやれば大丈夫、という話になります。

今回は例えばカスタムドメインに adfs20.net 、オンプレミスの Active Directory ドメインを adfs20.local という環境で構築します。
本来は UPN に user@adfs20.net という値が入っていないと認証連携はできませんが、この環境で普通にユーザを作ると UPN には user@adfs20.local という値が入ってしまいます。

では、代わりに 電子メールアドレス属性に Office365 が期待する UPN に相当する値である user@adfs20.net を入れてみます。
次にこの電子メールアドレス属性をクレームとして発行するように要求規則を変更します。

上のルール１を以下のように変更します。

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]
=> issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/claims/UPN", "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"), query = "samAccountName={0};mail,proxyAddresses,objectGUID;{1}", param = regexreplace(c.Value, "(?[^\\]+)\\(?.+)", "${user}"), param = c.Value);

・オリジナルのルール

・カスタマイズしたルール

こうすることで実際に UPN がローカルドメイン名であっても Office365 との認証連携が実現できます。

ただし、この手法がサポートされるかどうかは全く別問題なので、実際に利用する際はその点をよく確認して環境を構築することをおすすめします。