Office365は、ADFSを利用すると、シングルサインオン風にログインができます。

というのも、通常はログイン画面でログオンIDを手動で入力して、出てくるリンクをクリックするという手間が発生するからです。（ログオンIDは前回入力した値が保存できるので、毎回毎回入れなくても大丈夫ですが）

最初にポータル画面にアクセスすると、まず以下のような画面になります。Microsoft Online Service IDの欄に、AD FSで設定した普段利用しているActive Directoryのログイン名（user@domain形式）を入力します。

入力が終わると下のパスワード入力欄がグレーアウトし、新たに現れる「xxxxxにサインインする」というリンクをクリックすることにより、（4回くらいのリダイレクトを経て）Office365にログインされます。

これは、Office365のログインサイトは各ユーザ共通であり、ここのフォームでパスワードも入れて入力するアドレス（クラウドID）か、パスワードはOffice365側では持っておらずAD FSサーバにリダイレクトして認証処理を行うアドレスか（フェデレーションID）が最初の時点では判断が付かないからというのが原因です。

ここの@以下の値（realm）をポータル側でチェックして、フェデレーションドメインだった場合はリンクを出す処理をしています。

リンクをクリックした後のアクセスの流れですが、かなり端折って話をすると①Office365 ⇒ ②AD FS ⇒ ③Office365の順にアクセスをすることになります。が、前の記事にも書きましたが、ここで入力したメールアドレスは②の認証では実は利用されていません。

よって、①でログインIDを入力してサインインするをクリックするという工程は、実は省略しても良いのでは？と邪推してしまいます。という訳で早速実験してみましょう。「xxxxxにサインインする」のリンクをクリックして飛ぶurlを取得します。

https://sts.example.com/adfs/ls/cbcxt=out&vv=&username=hoge@example.com&mkt=&…

どうやら、入力したユーザ名や戻り先のサイトの情報を一緒に付けて送ってきているようです。urlエンコードしているみたいですが、%2526などのように二重でurlエンコードされている物も有りそうです。

とりあえずこれをデコードしつつ整理します。その後、1つ1つ省略してアクセスできるかどうかを試してみました。

結構省略できそうです。結果的に、以下のurlに社内のポータルサイトからリンクを張ってアクセスすることにより、シングルサインオン環境が実現できました。（無理無理感は有りますが…）

https://sts.example.com/adfs/ls/?wa=wsignin1.0&wtrealm=urn:federation:MicrosoftOnline&wctx=wreply%3Dhttps:%252F%252Fportal.microsoftonline.com

※AD FSサーバのアドレス（上記の例だとsts.example.com）がイントラネットサイトとして認識されている必要がありますので、必要に応じてIEのゾーンの設定をする必要があります。

※手元の環境だと、これを使ってログインした後にOWAを表示させると画面表示が崩れるという事象が発生することがありましたが、その場合は「Office デスクトップ アプリケーションのセットアップと構成」を実行することにより正常な状態に戻りました。

AD FS環境だと、ポータルではログインIDを入れるのみでパスワードは入力せず、そのままイントラネットのAD FSサーバにリダイレクトされ、そこで認証されてOffice365へのアクセスが行われます。

これはこれで便利な機能なのですが、運用上、他のアカウントでOffice365へのアクセスを実施する必要が出てくる場合が有ります。例えば、外部受付用の共有アカウントでの作業や、退職者のバックアップ作業などの場合です。

testuseroneというアカウントでWindowsにログインしていて、shared-userというアカウントでOffice365に接続しようとするシチュエーションを考えます。まず、ポータルで、普通にログインをしようとしてみます。

あれ…testuseroneのアカウントのままログオンされてしまいました。

どうやら、AD FS側ではOffice365ポータルで入力したユーザアカウントの値は特に検証せず、Active Directoryにログオン出来るかどうかのみを判断してOffice365側にチケットを発行しているようです。

普通に解決しようとするなら、AD FSのクレーム発行ルールを変更して…ということになるのだとは思うのですが、まだ勉強不足なので、今回は他のやり方を考えてみます。

• まず、FirefoxでのOffice365へのシングルサインオン で紹介したとおり、Firefoxはデフォルトではログイン情報をWebサイトに飛ばしませんので、共用アカウントでのログオンにはFirefoxを利用してID/PASS入力で入る。
• または、IEもゾーンが「イントラネットサイト」に無い限りログイン情報を飛ばさないので、これを起動前に明示的に他「例：信頼済みサイト」に変更してあげて、終了後必要に応じて戻す

Option Explicit
Dim WSHShell
Set WSHShell = CreateObject("WScript.Shell")
WSHShell.RegWrite "HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionInternet SettingsZoneMapDomainsexample.comstshttps", 2, "REG_DWORD"

これで、一応ID/PASSの入力画面がポップアップしてきて、指定のアカウントでログインができるようになります。

う～ん、でもあまり美しくない。上手いやり方は無いものだろうか…

FirefoxでのOffice365へのシングルサインオンの記事では、各クライアントサイドのセキュリティ設定の緩和によって、シングルサインオンの機能を実現しました。ただ、この手法は全クライアントにレジストリの変更を強いることになるので、あまりスマートな実装ではございません。

今回、サーバサイドの設定変更でシングルサインオンが出来ないか試してみたいと思います。

Continue reading →

 Office365の リリースノート にも記載がありますが、Windows7もしくは「認証に対する保護の強化」をインストールしたXP,Vistaにおいて、FirefoxやChromeでAD FS環境でのシングルサインオンを実施しようとするには少し設定変更が必要になります。(7/2追記修正)

試しにアクセスをしようとしてみると、

Continue reading →