Azure Active Directory とは (事前準備)


こんにちは。

ここでは、Azure Active Directory について、セットアップ方法やプログラム コードなどを開発者の視点で紹介します。(数回にわけて紹介します。)
まず今回は、Azure Active Directory の位置づけと、利用環境に関する基本情報を記載します。

開発者にとっての Microsoft Azure Active Directory

 

Azure Active Directory とは

Windows Server Active Directory (いわゆる Domain Controller, Domain Services) をご存じの方は多いと思いますが、Microsoft Azure Active Directory (Azure AD, AAD) を使用すると、クラウド上で提供されているサービスを使って (つまり、サーバーをインストールすることなく)、ユーザー管理、認証、認可などのアイデンティティ基盤を利用できます。
その一方で、内部実装は、Windows Server Active Directory とはまったく異なっており、例えば、Google Account や Facebook Account を使う場合、そもそも「Windows ドメイン」のような独自な概念は使わず、OpenID Connect や OAuth などのオープンな仕様に基づいて周辺と連携しますが、Azure Active Directory (Azure AD) も、むしろ こうしたクラウド上のオープン プラットフォームを強く意識して設計されています。

補足 : Windows 10 から Azure AD によるマシンの参加 (Azure AD Join) が可能になりました。

Google Account や Facebook Account のように、「Google アプリケーションを使うためのアカウント」、「Facebook アプリケーションを使うためのアカウント」ではなく、特定のアプリケーションとは無関係に、一般の企業や学校などの組織のユーザーと、そこで使用される各種アプリケーションなどを管理できる汎用的なアイデンティティ基盤 (入れ物) として提供されています。
また、クラウドで Microsoft が提供しているもう 1 つのアイデンティティ基盤として Microsoft Account (Microsoft アカウント) がありますが、Azure Active Directory で管理されるアカウントは Organization Account (組織アカウント, Work or School Account, 職場または学校のアカウント) と表現され、管理者不要で使用する Microsoft Account (Microsoft アカウント) とは異なり、組織ごとに「管理者」を立て、そこに属するユーザー (複数) を管理するような使い方を想定しています。

以下に、この Azure Active Directory の特徴を箇条書きします。

  • Identity as a Service :
    サーバーのインストールやセットアップ、プロトコルの開発などもいっさい不要で、契約ベースで利用可能なクラウド上のアイデンティティ基盤です。
    Identity Provider としてユーザーやその属性情報を管理したり、その組織で使う (SSO などで使用可能な) アプリケーションを管理できます。
  • Open, Connective, and Pluggable :
    さまざまな方式 (OpenID Connect など)、さまざまな利用シーン (バックエンド接続など)、さまざまな開発環境 (開発言語など) といった多くの周辺環境における相互利用を意識しています。
    利用者アプリケーション (Relying Party, または SaaS アプリ) の接続プロトコルとしても、現在、WS-Fed, SAML-P, OpenID Connect (ベースの OAuth 含む) をサポートします。
    また、同期可能なアイデンティティ・プロバイダー (Identity Provider) としては、Windows Server Active Directory、Shibboleth、その他のカスタムな Identity Provider (Office 365 Identity program で Certify されたプロバイダー) を選択できます。カスタム Provider の実装手順については「Office 365 SAML 2.0 Federation Implementers Guide」を参照してください。(SAML 2.0、LDAP v3 によるカスタム Provider とのディレクトリー同期も可能です。)
  • クラウド ベースの統一的アイデンティティ基盤 :
    また、Office 365、Dynamics CRM Online、Windows Intune、そして Windows といった Microsoft 製品 (サービス) においても、そのベースとして (統一的な ID 基盤として) Azure AD を使用しています。
    これら Office 365 や Dynamics CRM Online は、あくまで接続されている「アプリケーションの 1 つ」であり、Google Apps、Salesforce など、その他のさまざまなアプリケーションも接続可能です。Azure AD は「Microsoft アプリのアイデンティティ基盤を借りている」のではなく、「皆さん自身の組織におけるアイデンティティ基盤」として周辺アプリと連携して使用できます。

上述の通り、Office 365 を使用している方は、既に Azure AD を使用しており、管理画面などを使って独自のセットアップも可能です。

 

Azure AD の Edition

Azure AD には無償版 (Free) と、有償版の Basic、Premium、さらに Office 365 契約者用 の 4 つの Edition があります。

Azure AD の一般的利用は無償版 (Free) で可能ですが、有償版 (Basic, Premium) を使うことで Enterprise レベルの管理 (Group を使った一括設定、詳細のセキュリティ レポートなど) や追加の高付加価値の機能 (多要素認証、Application Proxy など) が利用できます。

また、Office 365 用の Edition は、無償版 (Free) の全機能はもちろん、有償版の一部の機能 (Self-Service Password Reset, 多要素認証, など) と MDM (Mobile Device Management) の一部機能が Build-in されています。

なお、本連載で紹介する開発・テスト レベルの利用であれば、無償版 (Free) で充分です。

 

Azure Active Directory の管理 (画面の場合)

Azure Active Directory を使用するには、まず、ディレクトリー (テナント) を作成し、ユーザーなどの設定をおこないます。
まず、画面 (UI) を使用した管理方法を簡単に見てみましょう。

Azure Active Directory を画面で管理するには、Microsoft Azure にサインアップ (登録) をおこない、Microsoft Azure Portal を開きます。
前述の通り、多くの機能が無償で使用できるため、ここで紹介するような基本的な確認であれば課金されることはありません。

補足 : Microsoft Account を使用したお持ちの (既存の) Azure サブスクリプションでも、Azure Active Directory で Office 365 のディレクトリーを管理できます。この手順は、「MSDN Subscriber 向け Office 365 API Dev 環境作成」に記載しました。

Azure Portal にログインしたら、ナビゲーションから [Active Directory] を選択します。

Azure や Office 365 を利用すると、そこで使われる Default Directory が既に存在しますが、Directory は複数作成できます。
新しく Directory (使用するテナント) の追加をおこなうには、[New] – [App Services] – [Active Directory] – [Directory] – [Custom Create] を選択します。

作成された Directory をクリックすると、この画面を使って、ユーザー/グループの管理 (作成/編集/削除)、ドメインの管理 (既定は ***.onmicrosoft.com。カスタム ドメインも使用可能)、使用するアプリケーションの管理、Windows Server Active Directory との Sync の設定など、Directory の管理がおこなえます。(画面を見ればわかるので、詳細解説は省略します。)
ここで登録したユーザーやアプリケーションなどは、もちろん、他の Directory からは参照できません。

いずれ紹介しますが、アプリケーションを作成 (プログラミング) して Azure AD で使えるようにするには、事前にアプリケーションを Azure AD に登録しておきます。
アプリケーションを登録するには、[Applications] タブをクリックして [Add] ボタンを押します。

補足 : なお、Office 365 のアカウントを使用して、ここでユーザーの新規作成をおこなっただけでは、Exchange Online のメールボックス (Mailbox) は作成されません。(ライセンスが割り当てられていないためです。) 例えば、Outlook Online でログインして確認する場合は、Office 365 管理センターで、作成したユーザーのメールボックス設定なども追加でおこなう必要があります。

 

Azure Active Directory の管理 (PowerShell の場合)

つぎに、Windows PowerShell を使用した設定方法をみてみましょう。
特に開発者の方は、細かなトラブルシュートなどで Windows PowerShell が必要になることがあるので、この Windows PowerShell のコマンドはおぼえておくと便利です。

Azure Active Directory の管理コマンドは、Microsoft Online Services Module for Windows PowerShell (つまり、Office 365 用の PowerShell 管理モジュール) の追加モジュールとして提供されています。このため、あらかじめ、最新の Microsoft Online Services Sign-In Assistant と Microsoft Azure Active Directory PowerShell Module のインストールをおこなってください。

Azure AD の PowerShell コマンドを使用するには、Windows PowerShell を起動し、下記のコマンドでモジュールを追加します。(下記の通り、Microsoft Online Services の拡張機能として提供されています。)

Import-Module MSOnline
Import-Module MSOnlineExtended

Windows 8 / Windows Server 2012 で使用する場合の注意点 : (2013/06 この不具合は、修正されました)
MSOnlineExtended は、version 2.0 の PowerShell engine が必要です。(MSOnlineExtended.psd1 に記載されています。) このため、コマンドが見つからない場合 (ObjectNotFound の場合) は、下記の通り、Version 2.0 のエンジンを使用してください。

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe  -version 2.0

つぎに、Azure AD の Directory (Microsoft Online Services) に接続します。下記 (Get-Credential) を実行すると UserName と Password を入力する画面が表示されるので、ID / パスワードを入力します。
なお、Office 365 のアカウントをお持ちの方は Office 365 の管理者アカウントでログインすれば OK ですが、Office 365 を使用せず Azure のみから使用する場合には、あらかじめ、上記の画面を使って Global Administrator (全体管理者) の権限を持つユーザーを作成しておき、この Global Administrator (全体管理者) のユーザーでログインしてください。(Azure のログインの際に使用している Microsoft Account ではログインできません。)

$cr=Get-Credential
Connect-MsolService -credential $cr

例えば、この Directory に Application を登録してみましょう。
以降の例では、https://tsmatsuz-test1.cloudapp.net/ のアプリケーションとの間で、SSO などを使用した連携をおこなう Application を新規作成します。Application は、Windows PowerShell では Service Principal という概念を使います。
なお、今回は単一の Address を設定していますが、1 つの Service Principal に複数の Address を設定できます。

$replyAddresses = New-MsolServicePrincipalAddresses -Address “https://tsmatsuz-test1.cloudapp.net/”
New-MsolServicePrincipal -ServicePrincipalNames @(“testapp1/tsmatsuz-test1.cloudapp.net”) -DisplayName “TestApp1” -Addresses $replyAddresses -Type Symmetric

上記を実行すると、下記の通り出力されます。

The following symmetric key was created as one was not supplied woCFy89V5+BX4ZWx7rACJW0HnH7 . . .

DisplayName           : TestApp1
ServicePrincipalNames : {testapp1/tsmatsuz-test1.cloudapp.net, 8ea2fe64-9b46-4858-a58a-85843e12abbf}
ObjectId              : 25e7dbb2-74c8-46b1-9a7e-c40b80894770
AppPrincipalId        : 8ea2fe64-9b46-4858-a58a-85843e12abbf
TrustedForDelegation  : False
AccountEnabled        : True
Addresses             : {Microsoft.Online.Administration.RedirectUri}
KeyType               : Symmetric
KeyId                 : 098ed98d-0a06-4506-9a38-dd33ef34fd99
StartDate             : 2012/09/01 7:07:22
EndDate               : 2013/09/01 7:07:22
Usage                 : Verify

補足 : Symmetric Key について :
ここで出力された Base64 エンコードの Symmetric Key の使用方法については「Azure AD : Backend Server-Side アプリの開発 (Deamon, Service など)」に記載しましたので参照してください。(資格情報の種類 (Type) として、Certificate または Symmetric のいずれかが使用できます。既定では Symmetric に設定されます。)
なお、Symmetric Key は作成時しか取得できないので、このタイミングでコピーしておいてください。(Symmetric Key の再作成が必要な場合は、New-MsolServicePrincipalCredential コマンドを使用します。)

この Directory に登録されている Service Principal をすべて確認するには、以下のコマンドを入力します。
下記の通り、いくつかの Service Principal があらかじめ登録されています。(Office 365 を使用している方は、ここに Exchange や SharePoint なども表示されます。) 例えば、下記の後者の AppPrincipalId (00000002-0000-0000-c000-000000000000) は、Graph API のサービスです。

Get-MsolServicePrincipal -All

ExtensionData         : System.Runtime.Serialization.ExtensionDataObject
AccountEnabled        : True
Addresses             : {Microsoft.Online.Administration.RedirectUri}
AppPrincipalId        : 8ea2fe64-9b46-4858-a58a-85843e12abbf
DisplayName           : TestApp1
ObjectId              : 25e7dbb2-74c8-46b1-9a7e-c40b80894770
ServicePrincipalNames : {8ea2fe64-9b46-4858-a58a-85843e12abbf, testapp1/tsmatsuz-test1.cloudapp.net}
TrustedForDelegation  : False

ExtensionData         : System.Runtime.Serialization.ExtensionDataObject
AccountEnabled        : True
Addresses             : {}
AppPrincipalId        : 00000002-0000-0000-c000-000000000000
DisplayName           : Microsoft.Azure.ActiveDirectory
ObjectId              : 9dd69b4c-3226-4287-ae9b-c9fc33e99209
ServicePrincipalNames : {00000002-0000-0000-c000-000000000000, AzureActiveDirectory/directory_s5.windows.net, AzureActiveDirectory/directory_s4.windows.net, AzureActiveDirectory/directory_s3.windows.net...}
TrustedForDelegation  : False

. . .

なお、特定の Service Principal のみを確認する場合は、以下の通り入力します。

Get-MsolServicePrincipal -AppPrincipalId <your AppPrincipalId>

Directory の Object Id (tenant id と呼ばれるもの) は、下記のスクリプトで取得できます。
この値も、domain の代わりに使用するなど、よく使うのでおぼえておきましょう。

$tenantId = (Get-MsolCompanyInformation).objectId
echo $tenantId

なお、Azure AD の Windows PowerShell コマンド一覧は、下記で取得できます。

get-command -module MSOnlineExtended

CommandType   Name
-----------   ----
Cmdlet   Get-MsolServicePrincipal
Cmdlet   Get-MsolServicePrincipalCredential
. . .
Cmdlet   Set-MsolServicePrincipal
. . .
Cmdlet   New-MsolServicePrincipal
Cmdlet   New-MsolServicePrincipalAddresses
Cmdlet   New-MsolServicePrincipalCredential
. . .
Cmdlet   Remove-MsolServicePrincipal
Cmdlet   Remove-MsolServicePrincipalCredential
. . .

例えば、画面から Application (ServicePrincipal) を登録すると、内部では、ServicePrincipal の作成と、Azure Active Directory Graph (本連載で後述します) の Application 登録の双方がおこなわれます。そして、この画面から登録された ServicePrincipal は、Windows PowerShell のコマンドで変更することはできません。(Set-MsolServicePrincipal コマンドはすべて Error になります。)
つまり、画面での設定と Windows PowerShell による設定には、いくつか相違もあるので注意してください

 

次回以降は、今回設定したテナントを使って、SSO や API 接続の手法を紹介します。

今後も、特に Office 365 の開発者にとっては、Azure のアイデンティティ基盤の理解が重要になってきますので、是非、背景など理解しておいてください。

 

Comments (0)

Skip to main content