Freigeben über

Windows Azure で Windows Server Active Directory のフェデレーションのサポートを開始

  • Artikel

このポストは、11 月 29 日に投稿された Windows Azure now supports federation with Windows Server Active Directory の翻訳です。

先日、ブログ記事「Windows Azure Active Directory (AD) が 2,000 億回の認証を処理」を公開しましたが、本日はこの Windows Azure AD の機能を活用する､Windows Azure の ID 関連機能の強化点をご紹介します｡Windows Azure の ID 管理機能について､ユーザーの皆様から最もご要望が多かったのが、オンプレミスの Windows Server AD の企業 ID を使用した Windows Azure 管理ポータルへのシングル サインオン (SSO) アクセスと､ユーザー アクセスの一元管理に関するものでした。こうしたご要望にお応えするために、このたび Windows Azure 管理ポータルを Windows Azure AD と統合し、オンプレミスの Windows Server AD のフェデレーションをサポートしました。またこの統合により、数百を超える Office 365 ユーザーの皆様にも、Office 365 と同じテナントと ID と使用して、サインオンの管理や Windows Azure へのアクセスを実行していただけるようにしました。

Windows Azure のフェデレーションを活用することで、さまざまなメリットが得られるようになります。たとえば、IT プロフェッショナルの方には、以下のようなメリットがあります。

  • Windows Azure のサブスクリプション管理を従業員の状況と連携させることができます。従業員が退職した場合には、オンプレミスの Windows Server AD から非アクティブ化または削除して、Windows Azure 管理ポータルへのフェデレーション アクセスをオフにすることができます。
  • 社内の管理者が Windows Server AD を介して、パスワード ポリシー、ワークステーションの制限、2 要素認証要件、ロックアウトの制御などの設定を含む、Windows Azure 管理ポータルの資格情報ポリシーを管理できます。
  • Windows Azure の資格情報セットを複数覚える必要がなくなります。SSO およびフェデレーションを使用することにより、PC や社内ネットワーク、Windows Azure に同一の資格情報セットを使用できるため、従業員が自身の資格情報を忘れてしまうリスクを回避できるほか、管理の一元化、パスワードのリセットの簡素化、コスト削減に役立ちます。
  • ユーザーのパスワードがオンプレミスの Windows Server AD から移行することはありません。ユーザー ログインには、オンプレミスの Windows Server AD フェデレーション サーバーが利用され、ID と資格情報はオンプレミスで作成、有効化されるため､パスワードがクラウドに移行されることはありません。
  • ユーザー名とパスワードによる標準の認証に加え､スマートカードと PIN、RSA SecureID などによる多要素認証を設定することも可能です。

管理ポータルにアクセスする開発者やオペレーターには、以下のようなメリットがあります。

  • ドメインに参加している Windows PC にログインする場合、Windows Azure 管理ポータルでシームレスに認証されます。
  • 自宅の個人用デバイスなど、ドメインに参加していないコンピューターからログインする場合も、仕事用の PC で使用しているのと同じ会社の資格情報を使用できます。
  • 会社用のメール アドレス経由で Windows Azure サービスの通知メールを受信できます。

まとめると､フェデレーションを活用することによって、企業のクラウド資産や知的財産のセキュリティを大幅に強化することができます。

既存の組織アカウントで Windows Azure にアクセス
Windows Azure AD を利用して、既存の組織アカウントで Windows Azure に簡単にサインインする方法は 2 つあります。これには、Office 365 ログインに使用している組織アカウントも含まれます。

1. Windows Azure サインインページを使用する

標準の Windows Azure サインイン ページを使用して、Windows Azure 管理ポータルにアクセスできます。Office 365 の組織アカウントでサインインするには、[Already use Office 365?(日本語:Office 365のアカウントを使用してサインアップする)] というリンクをクリックします (以下の図を参照)。

2. Windows Azure サインイン ページを経由しない

一方、サインイン ページを経由しない方法もあります。フェデレーションされた既存の企業ドメイン名を Windows Azure 管理ポータルの URL の末尾に入力してサインインします。たとえば、ドメインに参加しているコンピューターのブラウザーに https://windows.azure.com/contoso.com と入力します。既に Windows Azure AD のフェデレーションをセットアップしている、または Office 365 にログインしている場合、Windows Azure に自動でログインできます。

Identity365.net という架空の企業で働くユーザー Andrew を例に、このしくみを見ていきましょう。この企業は既に Office 365 サブスクリプションを所有しており、Windows Azure AD のフェデレーションもセットアップ済みであると仮定します。

Windows Azure にアクセスするため、Andrew はまずドメインに参加している自分の PC にログインします。次に Windows Azure の URL の末尾に企業のドメイン名を付け足して「https://windows.azure.com/identity365.net」と入力します。

Windows Azure AD は、identity365.net がフェデレーションされたドメインであることを認識し、自動的に Andrew をオンプレミスの Active Directory フェデレーション サービス (AD FS) サーバーにリダイレクトします。Andrew の勤める企業は、カルテ管理に携わっており、HIPPA に準拠する義務があるため、AD FS サーバーを構成して多要素認証を要求します。

次に､Andrew はスマートカードを挿入し、リストから自分の名前を選択します。すると、スマートカード PIN の入力を要求されます。

スマートカード PIN を入力すると、管理ポータルに自動でサインインされます。

Andrew がスマートカードを挿入しなかったり、正しい PIN を入力しなかった場合には、企業の Windows Server AD FS は Andrew のアクセスを拒否します。サインイン時に不適切な資格情報を送信すると、既定で Windows Server AD FS は、「HTTP 403 Forbidden」という標準応答コードを表示しますが、よりユーザーにわかりやすいようにカスタマイズすることもできます。

Windows Azure のフェデレーション アクセスのしくみ

ここからは、Windows Azure AD、Windows Azure 管理ポータル、Windows Server AD FS、企業のオンプレミス Windows Server AD の間でのフェデレーション アクセスのしくみについて説明します。

ステップ 1: ユーザーがローカルのドメインに参加している企業 PC にログインする

以下の操作が自動実行されます。

  • ローカル ドメイン コントローラーが、ユーザーの資格情報を検証します。
  • ドメイン コントローラーが、X 時間有効な Kerberos チケット保証チケットを生成します。既定は 600 分間 (10 時間) ですが、ローカルの IT 管理ポリシーから構成可能です。
  • あるいは、ローカル デスクトップへのログインに、ローカル IT 管理ポリシーで多要素認証を要求する方法もあります。その場合、Kerberos チケット保証チケットは多要素要求を記録します。

ステップ 2: ユーザーが Windows Azure 管理ポータルに企業名を入力する

ユーザーが「https://windows.azure.com/fabrikam.com」と入力

以下の操作が自動実行されます。

  • Windows　Azure 管理ポータルが URL を解析し、ドメイン名「fabrikam.com」を抽出します。
  • その後、管理ポータルがWindows Azure AD へのリダイレクトを実行し、要求されたホーム領域をクエリ文字列 (whr=fabrikam.com) として渡します。

ステップ 3: Windows Azure AD が検索を実行し、リダイレクトする

以下の操作が自動実行されます。

  • WindowsAzure AD が、既に fabrikam.com ホーム領域に構成されたオンプレミスの AD　FS サーバーの DNS 名を検索します。
  • その後、クライアント PC は、要求された AD FS サーバーの DNS 名 (sts.fabrikam.com)にリダイレクトされます。

ステップ 4: オンプレミスの AD FS が、 SAML トークンベースの認証チャレンジを送信する

以下の操作が自動実行されます。

  • オンプレミスの AD FS サーバーが、認証を要求してクライアント PC にチャレンジを送信します。
  • クライアント PC のブラウザーが、生成済みの Kerberos チケット保証チケットをオンプレミスのチケット保証サーバー　(KDC) に渡し、サービス チケットを要求します。
  • KDC が、クライアントに多要素要求を含むサービス チケットを発行します (ここではデスクトップ ログイン時にスマートカード認証を必要とする ITポリシーを前提としており、これに該当しない場合、AD FS は Windows Azure 管理ポータルのログイン手順においてスマートカードの提示を課すことができます)。
  • クライアント PC は、AD FS にサービス チケットを提示します。AD FS は Kerberos チケットを検証し、次に､Windows Azure AD 用の署名済み SAML トークンを生成します。資格情報が有効な場合、AD FS は署名済み SAML トークンのみを送信します。

ステップ 5: AD FS が Windows Azure AD にリダイレクトする

以下の操作が自動実行されます。

  • AD　FS は、Windows Azure AD に戻すフォーム ポストとして署名済みSAML を要求し、リダイレクトを実行して資格情報の有効性を証明します。
  • SAML　要求には、企業の資格情報は含まれません。実際のユーザー資格情報はローカル サイトから移行することはありません。

ステップ 6: AD FS が認証チャレンジを実行する

最後のステップとして、以下の操作が自動実行されます。

  • Windows Azure AD が、AD FS の SAML トークンを Windows Azure 管理ポータル用の署名済み ID 要求に変換します。
  • その後、Windows Azure 管理ポータルにポストバックを実行します。
  • Windows Azure 管理ポータルが Windows Azure AD 要求を復号化してユーザーのローカル ID ポインターを抽出し、その ID を基にユーザーの Windows Azure サブスクリプションを検索します。
  • これでユーザーは、多要素認証により Windows Azure 管理ポータルに認証されました。

企業のオンプレミス ディレクトリと Windows Azure AD 間でのシングル サインオンのセットアップ方法に関する詳細については､こちらのページをご参照ください。

Office 365 など、Windows Azure AD の機能に支えられているマイクロソフトのクラウド サービスをお使いの企業では、企業 ID を使用して新規の Windows Azure サブスクリプションをご購入いただくことで、すぐにご利用を開始していただけます。サブスクリプションを購入するには、https://account.windowsazure.com/お客様の企業名.com にアクセスしてください (「お客様の企業名」の部分をお客様の DNS 名で置き換えてください)。

以下のコメント欄にご意見、ご感想、ご質問をぜひお寄せください。 よろしくお願いいたします。

Alex Simons Active Directory 部門 プログラム管理担当ディレクター