Office 365 を ADFS 2.0 認証で構成する

公的証明書をゲットできたので、社外からOffie 365に接続する場合にADFS 2.0 フェデレーション認証でシングルサインオンを構成する方法について記載します。

実際に試してみた際のメモ書きになります。また検証した環境はベータになりますので正式サービスリリース時には変更されているかもしれませんので注意が必要です。

 

構成のポイントとしては以下の3点かと思います。

・公的証明書をADFS構築前に取得しておく方が楽

・Office 365 でカスタムドメインの設定が必須

・オンプレADのUPN属性値が外部ネットワークから名前解決ができること

 

この辺りについては、以下のブログで綺麗にまとまってますのでご参考頂ければと思います。

 

IdM実験室: Office365とAD FS2.0の認証連携

Office 365 (beta) を ADFS 2.0 フェデレーション認証に対応させる « ブチザッキ

#Office365 and #ADFS2.0, how does it work? « 360on365’s Blog

シングル サインオンで使用するために Active Directory フェデレーション サービス 2.0 を計画して展開する – Office 365 for enterprises

 

今回ここで記載するのは、第三者機関から取得した公的証明書をADFSに導入し、スマートフォン等からSSOを可能にするメモになります。

ドメイン内からの接続等、ブラウザベースのフェデレーション認証については、ADFSに接続可能であれば、Office 365 に対してのSSOはオンプレのCAで発行した証明書でも利用する事は可能でした。

しかし、ActiveSyncや、EWSを経由するアプリケーションの場合は、公的証明書を設定することで、利用可能となってました。

 

ADFS 2.0 への証明書導入

 

本来であればインストール時に、公的証明書を設定しておけばこの作業は不要かと思います。(試せてないので不明)

以下のKBを参考に、全てのADFSサーバーに証明書を導入します。

それを過ぎると、ADFS 2. 0 サービスの通信の証明書を変更する方法

※ADFSサービスアカウントが秘密キーへの読み取り許可権限の付与忘れに注意

 

AD FS 2.0 管理の証明書設定にて、トークン署名、トークン暗号化解除、サービス通信の証明書を追加します。

「AD FS 自動証明書ロールオーバー機能が有効な場合、証明書を変更することはできません」と警告が表示された場合は、証明書の自動更新処理をオフにする必要があります。

 

トークン署名で利用する証明書を更新した後は、以下のコマンドを実行しOffice 365 – ADFSの信頼済みのプロパティを更新する必要があります。

Microsoft Online Service ID フェデレーション管理ツールにて、以下のコマンドを実施します。

 

  • $cred=Get-Credential (Office 365 で管理されている管理者アカウント資格情報を使用します)
  • Set-MSOLContextCredential-MSOLAdminCredentials $cred
  • Update-MSOLFederatedDomain –DomainName ***.co.jp

 

信頼済みプロパティの確認

 

信頼済みプロパティが更新されるには少し時間がかかってました。

Microsoft Online Service ID フェデレーション管理ツールから、正しく証明書が登録されているかを確認する事ができます。

Get-MSOLFederatedDomain –DomainName ***.co.jp

出力結果から、TokenSigningCertificate の値を確認しそこに上記で設定した証明書の拇印が表示されていることを確認できれば、正しく設定は完了してます。

広告

[Tech・ED][T1-304] 次期Microsoft Online Service のID およびアクセス管理 ~AD FS 2.0によるシングルサインオンの実現1~

BPOSへのSSOはどうするか?

BPOS サインインツールがある

→サインインツールはXPのhomeは不可 Pro以上である必要がある

→サインインツールでログオンしているのみで、IE当からSSOでBPOS MOSSに接続できる

 

サインインツールは毎回認証が出ないようにする利便性の拡大
社内のAD、BPOSのID管理が必要になる

 

□ディレクトリ同期ツール
→同期対象は選択不可能
→同期後アカウントは無効で登録される、アクティブ化が必須
→AD以外のx86マシン、且つドメイン参加マシンで実行する必要あり
→同期したアカウントは、管理センターからプロパティの変更ができない

 

PowerShellが利用可能
→現行ではユーザーしか利用できない。配布グループ、連絡先は不可(時期バージョンで可能になるもよう)

管理センターからのインポートでは、CSVの差分インポートができない(注意)

 

SQL Azure を利生したID管理
→ 端末からのアクセス制御が可能(社内からしか利用できないなど)

 

■次期バージョンADFS 2.0

ネットワークを超えた認証を手助けを行う

ADFSサーバーを構築し認証を手助けする

トークン/クレーム形式の認証 (クレーム:属性、トークン:クレームをまとめたもの)

これまでの人相形式だと、認証可否の判別のみ

トークン形式だと、一度の認証でさまざまま情報を扱える(クレーム)

→管理者は企業内のIDの管理の一本化

 

◆アクセス制御ができるようになる

ユーザー制御、社内外でアクセス可否の制御
フェデレーション信頼を別途オンラインで作成する必要あり

→BPOSと社内ADFSサーバー?

 

外部からのアクセスはADFSプロキシサーバーが必要。。。

→ADFSプロキシが社内のADFSに接続させる

→社内のみの場合はプロキシは不要

 

次期バージョンでは、OnlineID、フェデレーションID二者択一(これはいい!)

シングルフォレストのみ対応

 

<内部ドメインの場合は要注意>

UPNは、@外部ドメインの形式のみサポートする・・・

 

ADFSを利用する場合は、ADFSの障害でBOPSログオン不可になる

ADFSはNLB対応、DBはクラスタで可用性をもたすのがベター

[Tech・ED][T3-304] 次期Microsoft Online Service のID およびアクセス管理 ~AD FS 2.0によるシングルサインオンの実現2~

identityはハイブリッドなテクノロジー

ITPro、Devの架け橋となる役割

 

STS セキュリティトークンサービス

Federation Gateway

AD Federation Service

→ ここの話 App Fabric Access Control Service(ACS)

 

■STS

セキュリティートークンの発行と管理を行う

認証はAD DS

ユーザーはSTSからトークン発行してもらいアプリケーションに渡す

 

疑問

クラウド、STSからのトークンを無条件で受け取ってる?

そうではなく、アプリケーションはSTSを信頼する設定がある

STS間の信頼 オンプレークラウド

 

3種類のSTS

ADFS.ACS,MFG

共通はADとのシングルサインオンを実現するSTS

→ ユーザーエージェントで通信を行う

→ ユーザーはなにもしなくてもいい

→ 自動的にリダイレクト処理が行われる

 

信頼とは?

メタデーター/証明書/暗号化キーの情報をお互いに交換する

WIF (Windows Identity Foundation) を使用して セキュリティー トークンからクレームを取り出す

WIF は WS-Federation/WS-Trust をサポート

 

ロールはすでに含まれているのでアプリケーションが軽くなる

→ コードを書く必要は一切なし

 

空の属性はクレームに含まれない

→ ゆえにトークンにも含まれない

→ 安易に「既定値」を使用すると後でとんでもないことに・・・<注意>

証明書利用者:リライニングパーティ

□クレームパイプライン

受付→承認→発行

承認:発行承認規則でOKかNGを判別

→アプリケーション側で実装する必要がない

 

要求規則(AD FSで作成)

入力された情報をルール (規則) に沿って処理し出力する

処理されたクレームは既定のパイプラインを通る

 

クレームは、要求規則で置き換えることが可能

要求規則はテンプレートが用意されている

ほかはカスタムルールで作成する(高機能)

 

■一部 まとめ

AD FS 2.0 を使用すると

【利用者】

オンプレミスの Identity でクラウド上のアプリケーションに SSO可能

 

【ITPRO】

クラウド アプリ用の Identity を個別に管理する必要が無い

※今まで通り Active Directory で

【開発者】

アプリケーションは ID/ロール管理から解放されるため、Identity 関連のビジネス ロジック変更に影響を受けない

企業間の相互運用にもつかえる

■AppFabric と ADFS

あるサービスのアクセスを制限したくなった場合

アプリケーションを変更する?

→ ADFSのクレームを変更する

 

ACSのトークン発行条件

パスワード、トークン、SWT

 

ACSの構成情報

Scope

Issuer;どのトークンからか

Rule:要求規則(ADFSよりは弱い機能)

 

SWT シンプルWebトークン

ACS から発行されたトークンは検証後、 HTTP Authorization ヘッダーに格納して REST Service に POST する

アプリケーション側は?

 

■まとめ ACS

Passive SSOには未対応

→アプリケーション側が少し大変

クラウド上に用意された STS (ACS) により、[オンプレミス]-[クラウド] の フェデレーションを実現

ACS は発展中。。
現時点で AD FS 2.0 とのフェデレーションが可能

 

V2 でサポート予定の機能

主要 IdP とのフェデレーション信頼

AD FS 2.0(対応済)

Live ID, Facebook,Yahoo!,Google

主要プロトコルの実装

WS-Trust, WS-Federation OpenID

IdP の選択画面とそのカスタマイズ

 

覚えておく
==========

AD FS 2.0 がサポートする SAML 2.0 操作モード

IdP Lite, SP Lite, eGov Profile 1.5

==========

操作モードは、機能の集合体

Enhanced Client/Proxy は未対応 オプション?

SAML対応という表記でも互換性が必ずあるわけではない → カスタマイズが必要

 

SSOの鍵は信頼関係

まずは社内のディレクトリサービスの整理が必要

STS信頼で必要になってくるかも?

相互運用はMSの重点課題!

%d人のブロガーが「いいね」をつけました。