ADFSを利用してAWSにシングルサインオンする方法

みなさんこんにちは、国井です。

ADFSを使ってシングルサインオンを実現する方法として、ADFS+Office 365というのが有名ですが、ADFSサーバーを利用して実現できるシングルサインオンは何もOffice 365だけではありません。

ということで、今日は国井が担当しているADFSトレーニングでも扱っている、ID連携の手法のひとつである、ADFSとAmazon Web Services(AWS)を組み合わせて、Active DirectoryでサインインしたユーザーがADFSから発行されたトークンを利用してAWSにシングルサインオンする設定というのを見てみたいと思います。
(ちょっとだけ宣伝させてもらうと、ADFSトレーニングではOffice 365に限らず、お客様の要望に合わせて様々なクラウドサービスとのシングルサインオンの実装方法とその運用(デバイス認証/2要素認証、トラブルシューティングなど)を紹介しているので、ご興味があれば気軽にご参加ください。)

 

■ADFS+AWSの処理フロー
AWSのシングルサインオンにはSAMLプロトコルのIdp Initiatedプロファイルを使うため、Office 365のシングルサインオンのように、Office 365のサイトにアクセスしてからシングルサインオンを始めるのではなく、ADFSのサイトにアクセスしてからAWSにアクセスするという処理フローになります。
(そういえば、SalesforceのシングルサインオンもIdp Initiatedでしたね)

フロー図を書こうと思ったのですが、AWSのWebサイトの中で既に図が書かれていたので、
そちらを参考にしていただくとよいでしょう。

・オフィシャルアナウンスメント
http://aws.typepad.com/aws/2013/11/aws-identity-and-access-management-using-saml.html

 

なお、今回参考にさせてもらったWebサイトはAWSのWebサイトになります。こちらのサイトにも手順が掲載されているのだけれど、英語だったこと、ADFS2.0を使っていること、そして何よりも手順の中で何をしているかを自分自身がより深く知りたかったから、ということがあって今回の投稿を書いてみました。

■作業全体のながれ
1.ADFS→AWSへのフェデレーションメタデータのアップロード
2.AWSにグループを作成
3.Active Directoryにグループを作成
4.証明書利用者信頼とクレームルールの作成

さあ、早速始めましょう。

 

■フェデレーションメタデータの取得とアップロード
AWSとADFSの間で信頼関係を設定するにはフェデレーションメタデータの交換が必要ですので、最初にADFSサーバーのフェデレーションメタデータをAWSにアップロードします。

ADFSサーバーのフェデレーションメタデータ(https://<ADFSサーバー名>/federationmetadata/2007-06/federationmetadata.xml)にアクセスし、表示されたXMLファイルを名前を付けて保存します。(ちなみにIE11だと表示の関係上、無意味な文字列のように見えますが、互換表示設定でADFSサーバー名を追加すれば、ちゃんとXMLファイルの中身が確認できます)

image

image

そして保存したフェデレーションメタデータをAWSに登録します。

AWS Management ConsoleからIdentity & Access Managementを開き、Identity ProvidersからCreate SAML Providerでプロバイダを作成します。

image

プロバイダの作成画面で、プロバイダタイプにSAML、プロバイダ名にADFSと設定し、Metadata Documentの欄でメタデータをアップロードします。

image

ここまでで、SAMLプロバイダの作成とメタデータのアップロードが完了しました。

image

作成したSAMLプロバイダを開くと、Provider ARNという文字列が入っていますが、これはSAMLプロバイダの識別子であり、後で必要になるので、控えておきましょう。

image

 

■AWSのグループ作成
続いてAWSに権限が割り当てられたグループを作ります。
通常、ADFSによるID連携ではユーザー名で2つのシステムを連携させますが、AWSではグループを連携させます。ここでは画面のように、ADFS-DevとADFS-Productionsという2つのグループを作成しました。名前は何でもよいのですが、後ほどの手順の関係上、必ずADFS-で始まる名前にしてください。

image

グループのプロパティを開き、Trust RelationshipでTruested Entitiesに先ほど控えておいた識別子を登録しておきます。(ここの関係性がうまく説明できないのですが、ご存知の方がいたら、ご連絡いただけるとありがたいです)
2014年12月5日追記 Amazonの方からコメント欄でご説明をいただきました(感謝!)。ぜひご一読ください。

image

また、必要に応じてグループにはAWS内での操作権限を割り当てておいてください。

 

■Active DirectoryにAWS用のグループを作成
Active DirectoryにAWS用のグループを作成します。グループは必ずAWS-で始まる名前であること、それから、-(ハイフン)の後ろがAWSで作ったグループの名前と同じであることが必要です。
そこで、私はAWS-DevとAWS-Productionという名前のグループを作成しました。
また、グループにはAWSを利用するユーザーを追加しておくことも忘れずに。

 

■証明書利用者信頼の作成
操作はADFSサーバーに移って、証明書利用者信頼を作成し、AWSのフェデレーションメタデータの登録とAWSに渡すトークンに含まれるクレームの定義を行います。

ADFS管理ツールから証明書利用者信頼を右クリックし、[証明書利用者信頼への追加]をクリック。

image

[証明書利用者信頼の追加ウィザードの開始]画面で、開始をクリック

image

[データソースの選択]画面で、[フェデレーションメタデータのアドレス]欄に
「https://signin.aws.amazon.com/static/saml-metadata.xml」と入力します。
残りの画面はすべて次へをクリックして完了します。
(AWSのフェデレーションメタデータは公開されているので、URLを登録するだけでADFSサーバーが自動的に取りに行ってくれます。)

AWS003

証明書利用者信頼の追加ウィザードの最後で、チェックが付いたままの状態で完了すると、

AWS008

要求規則の編集画面が登場します。発行変換規則を追加します。

AWS009

要求規則テンプレートには[入力方向の要求を変換]を選択して、

AWS011

入力方向:Windowsアカウント名
出力方向:名前ID
出力方向の名前IDの形式:永続ID
となるようにクレームの設定をし、適当な要求規則名を入力して、完了をクリックします。

AWS012

再び、規則を追加します。

AWS013

要求規則テンプレートに[LDAP属性を要求として送信]を選択し、

AWS010

属性名:Active Directory
LDAP属性:E-Mail-Addresses
出力方向の属性の種類:https://aws.amazon.com/SAML/Attributes/RoleSessionName
となるようにクレームの設定をし、適当な要求規則名を入力して、完了をクリックします。

AWS014

再び、規則を追加します。

AWS015

要求規則テンプレートに[カスタム規則を使用して要求を送信]を選択し、

AWS017

クレームルールとして、次の内容を記述します。

c:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname&#8221;, Issuer == “AD AUTHORITY”] => add(store = “Active Directory”, types = (“http://temp/variable&#8221;), query = “;tokenGroups;{0}”, param = c.Value);

また、適当な要求規則名を入力して、完了をクリックします。

再び、規則を追加します。

AWS019

要求規則テンプレートに[カスタム規則を使用して要求を送信]を選択し、

AWS017

クレームルールとして、次の内容を記述します。

c:[Type == “http://temp/variable&#8221;, Value =~ “(?i)^AWS-“] => issue(Type = “https://aws.amazon.com/SAML/Attributes/Role&#8221;, Value = RegExReplace(c.Value, “AWS-“, “arn:aws:iam::123456789012:saml-provider/ADFS,arn:aws:iam::123456789012:role/ADFS-“));

このルールにより、AWSに作ったAWS-で始まるグループとActive Directoryに作ったADFS-で始まるグループのマッピングがなされます。それから、arn:aws:iam::123456789012:saml-provider/ADFSの部分ですが、必ずAWS Management Consoleで確認した識別子に置き換えておいてください

また、適当な要求規則名を入力して、完了をクリックします。

AWS020

すべての画面を閉じて設定は完了です。

 

■アクセスの確認

ここまでできたら、アクセスを確認してみましょう。
SAML Idp Initiated用のURLである
https://<ADFSサーバー名>/adfs/ls/IdpInitiatedSignOn.aspx
にアクセスして、サインインすると、

image

自動的にAWS Management Consoleにリダイレクトされます。
ADFS-DevとADFS-Productionの両方のグループに所属しているユーザーの場合には、
どちらのグループとしてAWSに入るか、選択する画面が表示されます。

image

image

以上です。
AWSのシングルサインオンの場合、ユーザーを連携させるのではなく、
グループを連携させるという連携方法を採用しています。
このことは、ユーザーアカウントを同期させる手間が不要という意味で非常に便利なものだと思います。

また、ADFS経由でAWSにアクセスさせることで、ADFSお得意のデバイス認証や2要素認証などと組み合わせて利用できるということですので、この点も組織での効果的なシングルサインオンの実装を検討している方は見逃せないポイントですね。

Azure ADアカウントを利用したADFSのクレームベース認可

こんにちは、国井です。

ADFSでクレームベース認証(認可)を行う場合、Active Directoryユーザーで認証を済ませていることが前提でした。つまり、ADFSを利用する場合、Active Directoryは必須だったわけです。
(だからこそ、ADFS = Active Directoryフェデレーションサービスと呼んでいたわけですね)

ところが、Windows Server 2012 R2 の次のバージョンからADFSの認証に利用するディレクトリサービスとして、 Active Directory以外のディレクトリサービスが利用できることが発表されました。
これにより、とても選択肢が広がると思います。

しかし、現行のバージョンのADFSでも、実はActive Directoryを使わなくても、
サインイン認証を済ませて、ADFSからトークンを発行できるのをご存知でしたか?

本来はActive Directoryにサインインしたユーザーに対してトークンを発行していましたが、

image

Microsoft Azure Active Directory(Azure AD)で認証を行えば、ADでサインインしていないユーザーでもADFSからトークンが発行できるのです。

image

こんな感じで、認証画面でADとAzure AD、どちらでサインインするか選べるのです。

image

Azure ADでサインインしたユーザーを使ってADFS経由でサービスにアクセスできるようになれば、
私たちのサービス利用の選択肢も広がってくるというものです。
では、設定を見てみましょう。

 

ADFSサーバー側の設定

ADFSサーバー側では[要求プロバイダー信頼]を設定します。

ADFS管理ツールから[要求プロバイダー信頼]-[要求プロバイダー信頼の追加]をクリックします。

image

[要求プロバイダー信頼の追加ウィザード]が起動します。

image

[データソースの選択]で、[オンラインまたはローカルネットワークで公開されているプロバイダーについてのデータをインポートする]を選択し、フェデレーションメタデータとして、https://login.windows.net/<Azure ADドメイン名>/Federationmetadata/2007-06/Federationmetadata.xmlと入力します。

image

[表示名の指定]で、表示名となる名前を適当に入力します。

FSAzure004

ウィザードの残りの画面はすべてそのままで完了します。

image

FSAzure006

[要求規則の追加]画面が表示されるので、要求規則を追加します。

FSAzure007

[規則テンプレートの選択]で、[カスタム規則を使用して要求を送信]を選択します。

FSAzure008

[規則の構成]で、クレームルール言語を利用して規則を記述します。今回は、クレームルール言語として、すべてのクレームをそのまま発行するように、とりあえずc:[]=>Issue(claim=c);と書きました。
そのほか、[要求規則名]に適当な名前を入力して完了します。

FSAzure009

[OK]をクリックして完了です。

FSAzure010

(2014年11月17日追記)
証明書利用者信頼から要求変換規則を開き、要求規則として、受け付け変換規則と同じ
c:[]=>Issue(claim=c);を設定しておいてください。
これでADFS側の設定は完了です。

image

 

Azure側の設定

Azure AD側ではADFSサーバーとの間での信頼関係を設定します。
事前にMicrosoft Azure管理ポータルからAzure ADドメインが操作できるよう、ドメインの登録をしておいてください。 (具体的な登録方法はSEの雑記さんの「Azure のサブスクリプションを起点として Windows Azure Active Directory のディレクトリ同期を設定」を参考にしていただくと良いでしょう。)
その上で、ドメインのアプリケーションを追加します。

image

追加ボタンを押すと出てくる[実行する作業を選択してください]から[組織で開発中のアプリケーションを追加]をクリックします。

image

[アプリケーション情報の指定]で、適当な名前を付けて次へ進みます。

image

[アプリケーションのプロパティ]で、
サインオンURLに

https://<ADFSサーバー名>/adfs/ls/

アプリケーションIDに

http://<ADFSサーバー名>/adfs/services/trust

をそれぞれ入力します。

 

image

ここまでで設定は完了。では、サインインを試してみましょう。
(今回は証明書利用者信頼に Windows Indetity Foundation SDKの
サンプルWebサイトを登録しています。)
WebサイトのURLを入力してアクセスすると、サインイン先の選択画面が表示されます。
この画面で、Azure ADを選択すると、

image

Azureのサインイン画面に推移し、Azure ADのユーザー名とパスワードの入力を求められます。

image

サインインが完了すると、Webページにアクセスできました。

無題

(2014年11月17日追記)
証明書利用者信頼に規則を追加しておくのを忘れたため、トークンにクレームが何も入っていないという状態が起きました。そりゃそうですよね。ああ、恥ずかしい!

ところが、Windows Identity Foundation SDKのサンプルページを見るとわかりますが、
トークンに何もクレームが入っていない!のです。
Azure ADでサインインしたユーザーに、どうやってクレームを追加するか?
この部分についてはもうちょっと調べてみたいと思います。

■ ■ ■

なお、Active Directoryで認証してから、Azure ADの属性情報を要求規則の中で使いたいというニーズもあるでしょう。その場合には、ADFSのクレームにSQL Serverデータベースを使う方法でも紹介したように属性ストアを設定します。
ただし、デフォルトで選べる属性ストアにAzure ADはありません。そのため、Visual Studioでdllファイル(ライブラリ)を作りこんであげる必要があります。この点についてはマイクロソフトのWebサイトで手順が紹介されています。

■How to create a Custom Attribute Store for Active Directory Federation Services 3.0
http://blogs.technet.com/b/cloudpfe/archive/2013/12/27/how-to-create-a-custom-attribute-store-for-active-directory-federation-services-3-0.aspx

Using Windows Azure Active Directory as an Attribute Store in AD FS
http://blogs.technet.com/b/cloudpfe/archive/2014/03/25/using-windows-azure-active-directory-as-an-attribute-store-in-ad-fs.aspx

ただ、この中で紹介されているMicrosoft.WindowsAzure.ActiveDirectory.GraphHelperという名前空間、名前が変わってしまって今では使えなくなっているようなのですよね。。

今日はここまで。

2014年11月のイベント・セミナー登壇予定

最近、Azure AD/ADFS情報をなかなか書けていない国井です。

今日は告知です。
2014年11月29日にCLR/Hさんの勉強会に登壇させていただくことになりました。
タイトルは「クレームルール言語Deep Dive」です。

ADFSサーバーを利用したアクセス制御を行う場合、クレームルール言語をどれだけ
駆使できるかが組織のニーズにあったアクセス制御を行う上での重要なポイントになります。

今回は、クレームルール言語の書き方から様々なクレームルールの例まで
クレームルールづくしの50分で紹介します。

勉強会では、ID管理関連のセッションからハンズオンまで盛りだくさんだそうなので、
ご興味のある方はぜひ参加してみてください。

参加申し込みはこちらからどうぞ。
http://clrh.connpass.com/event/9464/

Azure Active Directory Premiumまとめ(インフラ技術編)

こんにちは、国井です。
最近、私の周りで色々な人とお話ししていると、Microsoft Azure Active Directoryって、Active Directoryと何が違うの?って話をよく聞きます。そんなところに、Microsoft Azure Active Directory Premium(以下、Azure AD Premium)なるものが出てきて、もう頭の中がバクハツしそうなんて話も聞くようになってきました。

そこで、今回はAzure AD Premiumって、何ができるの?をNAVERまとめ風にまとめてみました。
ちなみに、ここではインフラ担当のエンジニアの方にとって使うことがあるのでは?という機能に絞ってます。

 

Azure ADには3つのバージョンがある

 

“普通(無償)のAzure ADは、むちゃくちゃ乱暴に言えばOffice 365を契約するとついてくるユーザー管理機能”


”Active Directory Basic edition is a paid offering of Azure AD and includes the following features:Company branding, Group-based application access, Self-service password reset, Enterprise SLA of 99.9%”
(Azure AD Basicは有償で、無償のAzure ADに加えて、組織に合わせたサイトのカスタマイズ、グループベースのアクセス制御、ユーザーによるパスワードリセット、99.9%のSLAがついてくる)
出展:Azure Active Directory Premium and Basic

”Active Directory Premium edition is a paid offering of Azure AD Basic and includes the following features:Self-service group management, Advanced security reports and alerts, Multi-Factor Authentication, Microsoft Forefront Identity Manager (MIM), More features coming soon”
(Azure AD Premiumは有償で、Azure AD Basicに加えて、ユーザーによるグループ管理、レポートとアラート機能、多要素認証、FIMがついてくる。これからも増えるよ。)
出展:Azure Active Directory Premium and Basic

 

Azure ADはクラウド用ID管理サービス

Azure ADの基本機能として、ユーザー名とパスワードを作って保存できる。
そして、Azure ADのサイトにサインインできる。

出展:Windows Azure Active Directoryのアプリケーション連携

 

Azure ADのサイトにサインインできて、何がうれしいかといえば、
FacebookやGoogle Appsなど、2000以上のサイトにクリックひとつにできる!


出展:Windows Azure Active Directoryのアプリケーション連携

 

出先からActive Directoryのパスワードを変えることも可能

定期的にパスワードを変えないといけない会社は多いけど、しばらくオフィスにいない人はパスワード変更が難しい。こういうときに外出先からActive Directoryユーザーのパスワードを変えられるのはうれしい。

出展:クラウドからActive Directoryのパスワードを変更する方法

 

多要素認証機能のアップグレード

ADFSを使っている組織なら、ADFSの多要素認証機能をアップグレードできる。
これにより、ADFSと組み合わせて、モバイルアプリで認証、通話で認証などが可能。

出展Windows Azure Multi-Factor Authenticationを利用したADFSの多要素認証の設定(1)

 

特定のデバイスでのアクセスのみを許可!という設定も可能

Azure ADのデバイス認証機能はADFSと組み合わせることで、
Azure ADでデバイス認証+ADFSでユーザー認証という使い方が可能

出展:ADFSでデバイス認証を実装

 

組織のDMZをクラウドに提供

オンプレミスのサーバーを外部公開するときに、Remote Access as a Service (RAaaS)として、DMZへの入り口のサービスを提供。これにより、オンプレミスのDMZを隠ぺいする効果がある。(もっと言えばDMZは不要?)

image
出展:Microsoft TechEd North America 2014 PCIT-B327

 

評価ガイドも提供されている!

モバイルデバイス環境の評価ガイド
(Webページ内の「モバイルデバイス環境の評価ガイド」というところからダウンロードできます)
http://www.microsoft.com/ja-jp/server-cloud/products/enterprise-mobility-suite/try.aspx#fbid=RoWXOJmEKjx

 

続々機能増加中

今このまとめを書いている間にも、[ユーザーアクセス]なんて機能が増えています。
image

新しい機能も含めてAzure AD Premiumは評価版が試せるので、
活用してみたい機能があれば、Microsoft Azureポータルサイトから契約できる
評価版を使ってみることをお勧めします。

2014年10月のイベント・セミナー登壇予定

皆さん、こんにちは。国井です。

2014年10月25日にSystem Center Users Group Japanさんの勉強会に登壇させていただくことになりました。
タイトルは「クラウドで始めるActive Directory」です。

Microsoft Azureで提供するサービスを利用してActive Directoryを運用する場合、いくつかのパターンが存在します。
勉強会の中ではクラウドに展開されるActive Directoryについて整理をし、どのような使い分けをするべきかについて、参加される方々と一緒に考える機会にしたいと考えています。

勉強会では、私の話のほかにもActive Directoryの話がたくさんあるそうなので、
ご興味のある方はぜひ参加してみてください。

参加申し込みはこちらからどうぞ。
https://atnd.org/events/56167

もうひとつのID連携 ~ Microsoft Azure Active Directoryとは?

これまで当ブログでは、ADFSを利用したID連携(フェデレーション)について、色々と紹介してきました。
そして、ADFSは「Active Directoryフェデレーションサービス」の略であることからもわかるように、Active Directoryドメインを保有していることを(基本的に)前提としたID連携の仕組みでした。

一方、Active Directoryドメインを持っていないという組織でもID連携を行いたいというニーズも世の中には存在します。既存の仕組みとしてTwitterやFacebookで認証して、様々なサービスにアクセスするという方法はありますが、組織で使うIDとしては管理者が一元管理できないという点でいかがなものか?という疑問があります。

そこで、
Active Directoryドメインはないけど、管理者がまとめてID管理できる仕組みは欲しい
というニーズに応える形でMicrosoft Azure Active Directoryというキーワードが最近私の周りで出てくるようになりました。

■ ■ ■

イメージとしては、こんな感じです。
ADFSを利用してID連携する場合、Active Directory(ADDS)で認証を行い、
ADFSでトークンを発行(認可)してもらい、
トークンを使ってアプリ(クラウドのサービス)にアクセスする、
という流れでしたが、

image

Microsoft Azure Active Directoryでは、
自社内にActive Directoryを持っていなくても、Microsoft Azure Active Directory自身が
ディレクトリサービスとなるため、
Microsoft Azure Active Directoryのユーザー名とパスワード入力して認証すれば、
あとはOffice365でも、Salesforceでも、Google Appsでも、どこへでも行けます。
例えば、Salesforceの場合、Microsoft Azure Active Directoryで認証すると、
Salesforceにアクセスするためのトークンを発行(認可)してもらい、
トークンを使ってSalesforceにアクセスする、 という流れになります。

image

 

繰り返しになりますが、
Microsoft Azure Active Directoryを使えば、クラウド上に組織のユーザーアカウントをすべて作成しておくことができ、ユーザーはMicrosoft Azure Active Directoryに保存されているユーザー名とパスワードを入力するだけで、Microsoft Azure Active Directoryに関連付けられた様々なクラウドサービスにアクセスできるようになるというメリットがあります。
(一般にシングルサインオンと呼ばれる仕組みですね)

クラウド化に伴い、「もう会社にサーバーを置きたくない」というニーズは様々なところで聞きますが、
ID管理に関してはMicrosoft Azure Active Directoryを利用することによって、これまでActive Directory+ADFSで提供していたような機能の一部(全部じゃありません!)が
サーバーレスで実現できるようになるわけです。

 

※実装の参考サイト
Office365のシングルサインオン(by MVP渡辺さん)
http://blog.o365mvp.com/2013/09/29/adfs_install_manual_win2k12r2/

Microsoft Azure Active Directoryと関連付けて利用するクラウドサービスの設定
– Windows Azure Active Directoryのアプリケーション連携

https://sophiakunii.wordpress.com/2013/10/15/windows-azure-active-directory%e3%81%ae%e3%82%a2%e3%83%97%e3%83%aa%e3%82%b1%e3%83%bc%e3%82%b7%e3%83%a7%e3%83%b3%e9%80%a3%e6%90%ba/

Azure ADのアプリケーション連携 ~ Google Apps編
https://sophiakunii.wordpress.com/2013/10/17/azure-ad%e3%81%ae%e3%82%a2%e3%83%97%e3%83%aa%e3%82%b1%e3%83%bc%e3%82%b7%e3%83%a7%e3%83%b3%e9%80%a3%e6%90%ba-%ef%bd%9e-google-apps%e7%b7%a8/

■ ■ ■

Microsoft Azure Active Directoryは持っている機能があまりにたくさんあるので、
すべてをまとめて解説しているようなドキュメントを読むと、結局迷子になってしまう、
なんて話はよく聞く話です。
そのため、まずは上記のような違いがあるという認識から入るといいと思います。

そして、実際に使ってみようという段階になったら、もっと調べることになるでしょうし、
そのときに色々な機能があるってことを知れば良いのでは?と思い、
今回の投稿を書いてみました。

 

最後に、すごく聞かれるMicrosoft Azure Active Directoryの質問と私の回答をまとめておきます。

Microsoft Azure Active Directoryはおいくら?

無料です。
Microsoft Azure Active Directory Premiumという有償サービスも用意されています。
詳細については機会を改めて。

 

Microsoft Azure Active DirectoryとWindows Server 2012 R2のActive Directory
何が違う?

Windows Server 2012 R2のActive Directory(Windows Server Active Directory)はオンプレミスのサーバーにインストールして利用する、いわゆるActive Directoryと呼ばれる機能であるのに対して、Microsoft Azure Active Directoryはクラウドで提供されるディレクトリサービスです。では、Windows Server Active Directoryのクラウド版がMicrosoft Azure Active Directoryなのか?というと、それは違います。
色々あるけど、一番大きな違いはWindows Server Active Directoryはグループポリシーを提供するけど、Microsoft Azure Active Directoryにはグループポリシーはありません
ということで、Microsoft Azure Active Directoryを利用しても社内のコンピューターやユーザーの管理をすべて一元化するものではない、ということです。

image

 

Microsoft Azure Active Directoryを作ったつもりはないのに勝手にできている?

Office365やWindows Intuneなどは、認証・認可の機能にMicrosoft Azure Active Directoryを使います。なので、Office365やWindows Intuneを契約するとMicrosoft Azure Active Directoryの契約(テナント)が同時に作られます。

 

Microsoft AzureとMicrosoft Azure Active Directory、何が違う?

Microsoft Azure Active DirectoryはMicrosoft Azureで提供される機能の一部です。Microsoft Azure自体は有償のサービスなので、無償で使えるMicrosoft Azure Active Directoryとごっちゃになると思うのですが、
クレジットカード番号まで入力して作ったMicrosoft Azureのテナントも、
Microsoft Azure管理ポータルサイト上でMicrosoft Azure Active Directoryしか使わなければお金はかかりません。

 

Microsoft Azure Active Directoryはどこから管理する?

基本的にMicrosoft Azure 管理ポータルサイトから管理しますが、
Office365やWindows Intuneなどの管理ポータルサイトからも簡単なユーザー管理は可能です。

 

以上、お客様とお話をしていて、よく出てくる質問だったので、まとめてみました。
参考になればうれしいです。

 

追伸

投稿の中で登場するアイコン、SharePointを学習したことのある方なら、どこかで見たことがあると思います。そうです、SharePointのトレーニングを開催しているクリエ・イルミネートさんのアイコンです。
クリエ・イルミネートさんで開催しているADFSトレーニングは2014年9月よりリニューアルし、Microsoft Azure Active Directoryにも対応したトレーニングになっております。

実際にマイクロソフトのテクノロジーを利用したID連携を検討している方は、短い時間で知識を習得する良い機会だと思いますので、ぜひトレーニングの参加も検討してみてください。

ADFSまとめページ作りました

当ブログで最初にADFSの投稿から3年、数にして50を超える投稿をさせていただきました。
雑多な感じになってきたので、ADFSのまとめページを作っておきました。

古くなってしまった投稿は無視して、今でも使えそうなものだけをピックアップして、
一言コメントと共に並べておきました。
よろしければ、ご覧下さい。

ADFSまとめ
https://sophiakunii.wordpress.com/adfs%e3%81%be%e3%81%a8%e3%82%81/