Quantcast
Channel: IdM実験室
Viewing all 771 articles
Browse latest View live

[AzureAD]AAD ConnectとConnect HealthがGAになりました

$
0
0
ついにAzure AD ConnectとConnect Healthが一般公開されました。

公式blog)Azure AD Connect & Connect Health is now GA!
 http://blogs.technet.com/b/ad/archive/2015/06/24/azure-ad-connect-amp-connect-health-is-now-ga.aspx

それぞれを一言で紹介すると以下の通りとなります。
モジュール解説主な機能
Azure AD ConnectAzure ADとオンプレミスADのハイブリッド構成(SSO、ID同期)を構成するためのツール群AD FS/AAD Syncの簡単設定機能
マルチフォレストAD連携、非ADのオンプレミスIdPとのID同期
Connect HealthAD FSのモニタリングツールリクエスト数、ログインエラー数などのモニタリングとグラフィカル表示


今回はAAD Connectの方を中心に紹介したいと思います。


◆AAD ConnectのリリースによりDirSyncおよびAAD Syncの個別リリースが終了

重要なポイントですがAAD Connectがリリースされたことにより、DirSyncおよびAAD Syncについては今後個別のモジュールとしてリリースされることはありません。今後はAAD Connectの更新として提供されることとなります。

Azure AD Connect incorporates the components and functionality previously released as Dirsync and AAD Sync. These tools are no longer being released individually, and all future improvements will be included in updates to Azure AD Connect, so that you always know where to get the most current functionality.

出典)https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect-learn-more/


◆AAD ConnectではActive Directory以外のIDストアもサポート

現状ではまだExpress Settings(簡単設定)を行うためにはActive Directoryが存在する環境でしかAAD Connectの設定はできませんが、今後はActive Directory以外のIDストアをベースにAzure ADと同期を行うことができるようになると思われます。

Ignite 2015のセッションスライド。他のIDストアとの接続が明示されている。



ドメイン参加していないサーバにAAD ConnectをセットアップしようとするとExpress Settingsは使えないもののセットアップ・ウィザードは先に進められる。



オンプレミスのIDストアの設定にDirectory Typeというプルダウンが存在する。(現在はActive Directoryしか選択できないが)



Synchronization Managerの初期状態で管理エージェントとして以下の3種類が選択できる。

  • Active Directory Domain Service
  • Azure Active Directory
  • Extensible Connectivity 2.0(ECMA2.0)





◆その他

ウィザードの最後にドメイン参加したWindows 10のデバイスの情報をAzure ADと同期するためのオプションについての記載もあり、今後のハイブリッドシナリオの拡張を予感させます。



今後はこのツールがAzure ADとのハイブリッドシナリオでは主役となるはずなので、他の拡張要素についても今後紹介していこうと思います。
しかし一昔前に比べてものすごく簡単にセットアップができるようになったもんです・・・。

[MIM]特権アカウント管理機能の概要

$
0
0
リリース目前のMicrosoft Identity Manager(MIM)ですが、なんといっても目玉機能は特権アカウント管理機能(Privileged Access Management / PAM)です。

以前のポストでどのような動きになるのか動画を紹介しましたが、今回は具体的な中身についてみていきたいと思います。

 参考)[MIM]特権アクセス管理のデモ動画
 http://idmlab.eidentity.jp/2015/04/mim.html


◆PAMで何ができるのか?

 現段階のリリース予定では、「Active Directoryの特権アカウントの管理」が可能になります。
 当然これまでもセキュリティ・グループへの追加・変更・削除は出来ましたが、
  ・時間制限付きのメンバシップの管理
  ・申請~承認のフロー
  ・多要素認証の要求
  ・履歴管理
 といった、実際に特権アカウントを管理する上で必要な機能をパッケージ化しています。


◆どのように実現しているのか?

 キーとなるのは以下です。
 ・片方向の信頼関係
 ・シャドーグループによるSID-Historyによる特権の紐づけ

 簡単に図示したのが以下の図です。


 通常、ドメインの移行をする際にリソースへのアクセスを維持するために使用するSID-Historyを使って、業務用ドメインの保護対象リソースへアクセスできるセキュリティ・グループと特権管理ドメイン上に作成した特権ロールの紐づけを実現します。
 このことにより、MIMが特権ロールのメンバシップを更新することにより実際には業務ドメイン上のグループに所属していないユーザでも一時的に保護対象リソースへアクセスすることが可能になります。

 MIMのPAM機能のロール管理は以下のような構造になっています。



◆どのように動くのか?

1.特権を付与する前の保護対象リソースへのアクセス

 今回は単純に共有フォルダへのアクセスをさせてみます。
 特権付与前の状態だと「アクセスが拒否」されます。


2.特権申請をする

 今回はMIMにサンプルで付属している特権管理ポータルを使い、ロールの利用を申請します。
 (REST APIを直接たたいて申請する方法もありますし、申請用のアドオン、PowerShellのコマンドレットが付属しています)
 単純にロール名を選択して[Elevate]をクリックします。


 すると要求の詳細(申請理由と期限)が入力できるので必要であれば入力してSubmitします。


3.申請を承認する

 今度は管理者で特権管理ポータルへログインし、承認を行います。
 誰から、何のために、どのくらいの期限で、という申請情報が来ているので[Approve]をクリックして承認を行います。


4.再び保護対象リソースへのアクセス

 特権申請をしたユーザで新しいセッションを開始して、自身が所属しているグループを確認すると、特権ドメイン上の特権グループおよび業務ドメイン上のグループのメンバになっていることがわかります。

 また、この状態であれば当然、共有フォルダへのアクセスが可能となっています。


 ※今回共有フォルダへのアクセスを例にしたため、PCログインのセッションが残っているので、セッションを切り替えるためにrunas等で新たに特権申請したユーザでのセッションを作成しなおす必要がありましたが、Webリソースなど都度ログインするようなアプリケーションであれば、都度権限チェックがなされるため本当に期間限定でリソースへのアクセスができるように見えます。

5.申請期限後に再び保護対象リソースへのアクセス

 申請した有効期限が過ぎてから再度リソースへアクセスすると最初と同じくアクセスが拒否されます。また、メンバとなっているグループを見ると特権グループから外れていることがわかります。



 ちなみにMIM側のジョブの走るタイミングによると思いますが、期限が切れるタイミングと実際にグループメンバから外れるタイミングには数分のタイムラグがあります。



次回以降、環境の構成方法などもう少し細かい方法を解説していきたいと思います。

[Azure MFA]新Azure AuthenticatorアプリでGoogle2段階認証を使う

$
0
0
Azure Active Directory(AzureAD)やOffice365を使っている方ならみんな使っている(はずの)、多要素認証ですが、SMS、電話、アプリケーションといった選択肢がある中、みなさんどんな方法で多要素認証してますか?


私はもちろん一番手軽な方法であるAzure Authenticatorアプリケーションを使っています。
ログイン時に通知されるのでアプリで[認証]をタップするだけでログインできます。



実はこのAuthenticatorアプリケーションがアップデートされ、ワンタイムパスワードの標準仕様であるOATH(TOTP)に対応しました。
※OATHでは、セットアップ時に決めたシークレットとカウンタ(TOTPの場合、UNIXタイム)を元にハッシュ値を計算してワンタイムパスワードを決めます。

このことにより、同じOATHに対応した多要素認証の仕組みを持つ、GoogleやMicrosoft Accountなどにもこのアプリケーションを使うことができるようになりました。

 公式blog)
 Try the new Azure Authenticator application!

早速やってみました。

◆Googleの2段階認証を設定する

Googleアカウントの2段階認証を有効にし、Authenticatorの登録を行います。


登録画面で通常はGoogle Authenticatorを使ってQRコードを読み取るのですが、ここでAzure Authenticatorを使って読み込んでみます。


うまく読み込めるとGoogleというエントリと6ケタのコードが表示されますので、Google側にcodeを設定してVerifyします。
これで設定は完了です。

次に、2段階認証を設定したユーザでGoogleのサービスへログインします。
するとワンタイムパスワードの入力を求められるので、Azure Authenticatorを開いて表示されている6ケタのコードを入力します。

これでログインできました。


◆逆はどうだ?

ここまでは何のひねりもありませんので、今度はGoogle Authenticatorを使ってAzure ADへログインできるかどうか確認してみます。

手順は先にGoogleでやったのと同じで、Azure ADで多要素認証を有効にし、Authenticatorの登録を行います。少なくともGoogle Authenticatorにはボタン一発認証機能はないので、通知方法には「ワンタイムパスワード」を選択します。
同じようにQRコードが表示されるので、Google Authenticatorで読み込んでみます。
すると、、、、、読み込めませんでした。

逆はダメなんですね。。。。


ちなみにこの後、Ping IdentityのPingIDやIIJのSmartKeyなど同様のアプリケーションを使ってAzure ADの多要素認証用のQRコードを読み込ませてみましたが、どれも一様にエラーをだしました。
残念です。

たとえば、現在Google AppsをGoogle Authenticatorで使っているユーザをAzure ADへ引っ越してもらう、というようなユースケースで利用者の負担を減らせるので良いのになぁ、、と思ってしまいます。

引き続きウォッチですね。

[AzureAD]エンドユーザによるアプリケーション利用申請と承認

$
0
0
※今回紹介する機能にはPreview機能を含みます。今後の機能変更などが発生する可能性があるので、ご注意ください。

こんにちは、富士榮です。

組織のID管理の設計をしていると必ず出てくるのが「アプリケーションの割り当てをどのようなフローで行うか」という課題です。
パターンとして、
①特定のユーザ属性をみて機械的に割り当てる(例えば正社員は自動的に割り当て等)
②管理者による手動割り当て
③既存のワークフローシステムとの統合
④ID管理システム自体に申請~承認フローを組み込む
などがありますが、それなりに複雑化しやすく工数もかさむのでスタート時点では①の方法である程度自動化しておいて②の方法で例外ユーザを登録していく、という形で決着することが経験上は多い気がします。

ただ、アプリケーションが増えてきたり、必ずしも大多数の人が使うとも限らないアプリケーション(例えばプロジェクト専用アプリケーションなど、特定の業務用のもの)では機械的に割り当てるルールを書くのが困難な場合もあります。

そのような場合、利用者自身による利用申請~管理者による承認、という簡易ワークフローのような機能があると重宝します。

Azure Active Directory(AzureAD)にもアプリケーション利用のための簡易ワークフロー機能がPreviewとして提供されています。

早速確認してみます。

◆ユーザ自身が申請ができるようにアプリケーションを構成する

設定はアプリケーション単位で行います。
対象のアプリケーションを開き、[構成]メニューより[セルフサービスアクセス]設定を行います。

設定項目は以下の3点です。
・アプリケーションのセルフ サービス アクセスを許可する
 ⇒許可するかどうかのON/OFF設定
・アクセス権を付与する前に承認を要求します
 ⇒申請に対する承認が必要かどうか。承認が不要であれば、申請した段階で自動的に割り当てられる。
・承認者
 ⇒承認するユーザを選択します。複数人選択することは出来ますが多段階の承認フローなど複雑なことは出来ません。




◆利用申請を行う

アプリケーションパネル(https://myapps.microsoft.com)へアクセス、申請を行うユーザでログインします。
申請可能なアプリケーションがテナントに存在すると[アプリケーションをさらに取得]というアイコンが表示されるようになっているので、クリックして申請を行います。






これで申請は完了です。

◆利用申請を承認する

今度は先ほど承認者として設定したユーザで同じくアプリケーションパネルへログインします。
[承認]というメニューが出てくるのでクリックします。


すると申請一覧が表示されるので、選択して[Approve]をクリックして承認を行います。



◆承認されたアプリケーションが利用できるようになっていることを確認する

先ほど申請したユーザで再度アプリケーションパネルへログインします。
すると、アプリケーション一覧が更新されており、申請したアプリケーションが利用できるようになっています。




ワークフロー単体としてみると機能はかなり限定的ではありますが、一部のアプリケーションにのみ適用するなどすれば管理負荷を下げることができると思います。

[MIM]Active Directoryの特権アカウント管理環境を構築する~環境構築編

$
0
0
こんにちは、富士榮です。

今回は、先日紹介したMicrosoft Identity Manager 2016(MIM)を使ったActive Directoryの特権アカウント/アクセス管理の環境構築について紹介したいと思います。

 参考)
  [MIM]特権アカウント管理機能の概要
  http://idmlab.eidentity.jp/2015/06/mim.html

特権アクセス管理を行うだけであれば、MIMの持っているID同期機能(MIM Synchronization Service)やID管理ポータル(MIM Portal)、パスワード管理機能(Self Service Password Reset / Self Service Password Registration)等のコンポーネントを導入する必要がないので、最低限必要な環境だけを一台のサーバに詰め込んでしまうことも可能です。

 最低限必要な環境
 ・Active Directory Domain Service(新規フォレスト、ドメイン)
 ・Internet Information Service
 ・SQL Server 2012以上(今回は2014を使用)
 ・Microsoft Identity Manager 2016(MIM)
  ・MIM Service
  ・Priviledged Access Management

これらのコンポーネントを一台のサーバに導入して特権管理したい既存のドメインの横に置いておくだけで特に既存の環境に大きな影響を与えることなく特権管理機能だけを追加することができます。

早速構成してみましょう。
※ちなみに全部英語版のOSに設定しています。あくまで経験上ですが、サーバソフトウェアを導入する時は英語版を導入して必要なコンポーネントに日本語Language Packを適用する方が安定します。


◆Active Directory Domain Service(AD DS)の導入

新規インストールしたWindows Server 2012 R2のマシンに、特権管理ドメインを以下の名前で構成します。
・フォレスト/ドメイン名:pyramid.local
・サーバ名:mimpam
・機能レベル:Windows Server 2012 R2


ウィザードを使って構成しても良いですが、面倒なのでPowerShellで構成しました。

・モジュールのインストール
Import-Module ServerManager
Install-WindowsFeature AD-Domain-Services,DNS -restart -IncludeAllSubFeature -IncludeManagementTools

・フォレスト/ドメインの構成
Import-Module ADDSDeployment
Install-ADDSForest -CreateDnsDelegation:$false -DatabasePath "C:\Windows\NTDS" -DomainMode Win2012R2 -DomainName "pyramid.local" -DomainNetbiosName "PYRAMID" -ForestMode Win2012R2 -InstallDns:$true -LogPath "C:\Windows\NTDS" -NoRebootOnCompletion:$false -SysvolPath "C:\Windows\SYSVOL" -Force:$true

◆Internet Information Service(IIS)の導入

特権アカウント管理はREST APIでコントロールするため、APIをホストするWeb Serverの導入を行います。
DドライブにOSのDVDを挿入した状態で以下を実行します。

Import-Module ServerManager
Install-WindowsFeature Web-WebServer,Net-Framework-Features,rsat-ad-powershell,Web-Mgmt-Tools,Application-Server,Windows-Identity-Foundation,Server-Media-Foundation -includeallsubfeature -restart -source d:\sources\SxS

◆必要なユーザアカウントの作成と設定

以下のアカウントが必要です。
尚、それぞれサービスアカウントなのでパスワード期限は無期限にセットしておきます。

用途アカウント名権限備考
MIM Monitoring ServiceMIMMonitor
MIM Component ServiceMIMComponent
MIM ServiceMIMServiceDomain Admins
MIM 管理AgentMIMMA使わないがセットアップに必要なので作成
SQL ServerSqlServer
PAM REST API Web ServicePAMAppPoolDomain Admins


こちらもPowerShellで一括で作ります。
Import-Module activedirectory
$sp = ConvertTo-SecureString "P@ssw0rd" -asplaintext -force
New-ADUser -SamAccountName MIMMonitor -name MIMMonitor -DisplayName MIMMonitor
Set-ADAccountPassword -identity MIMMonitor -NewPassword $sp
Set-ADUser -identity MIMMonitor -Enabled 1 -PasswordNeverExpires 1
New-ADUser -SamAccountName MIMComponent -name MIMComponent -DisplayName MIMComponent
Set-ADAccountPassword -identity MIMComponent -NewPassword $sp
Set-ADUser -identity MIMComponent -Enabled 1 -PasswordNeverExpires 1
New-ADUser -SamAccountName MIMService -name MIMService
Set-ADAccountPassword -identity MIMService -NewPassword $sp
Set-ADUser -identity MIMService -Enabled 1 -PasswordNeverExpires 1
New-ADUser -SamAccountName MIMMA -name MIMMA
Set-ADAccountPassword -identity MIMMA -NewPassword $sp
Set-ADUser -identity MIMMA -Enabled 1 -PasswordNeverExpires 1
New-ADUser -SamAccountName SqlServer -name SqlServer
Set-ADAccountPassword -identity SqlServer -NewPassword $sp
Set-ADUser -identity SqlServer -Enabled 1 -PasswordNeverExpires 1
New-ADUser -SamAccountName PAMAppPool -name PAMAppPool
Set-ADAccountPassword -identity PAMAppPool -NewPassword $sp
Set-ADUser -identity PAMAppPool -Enabled 1 -PasswordNeverExpires 1
Add-ADGroupMember "Domain Admins" PAMAppPool
Add-ADGroupMember "Domain Admins" MIMService


◆その他設定

その他、必要な設定を行います。(必要に応じて再起動します)

・GroupPolicy設定

 デフォルト・ドメイン・コントローラ・ポリシー
 ・コンピュータの管理->ポリシー>Windowsの構成>セキュリティ設定>ローカルポリシー>監査ポリシー
  ・アカウント管理 : 成功/失敗
  ・ディレクトリアクセス : 成功/失敗

 デフォルト・ドメイン・ポリシー
 ・コンピュータの管理>ポリシー>Windowsの構成>セキュリティ設定>ローカルポリシー>ユーザ権限の管理
  ・バッチジョブとしてログオンを拒否する
   MIMMonitor / MIMComponent / MIMService
  ・リモートデスクトップ経由でのログオンを拒否する
   MIMMonitor / MIMComponent / MIMService


・Kerberosの権限移譲

 Active Directoryユーザとコンピュータより委譲設定。
 ・委譲先ユーザ: MIMMonitor / MIMComponent
 ・委譲権限 : ユーザの作成・削除・管理、グループのメンバシップの変更


・Service Principal Name(SPN)の設定

 以下を設定します。
setspn -S FIMService/mimpam.pyramid.local PYRAMID\MIMService
setspn -S http/mimpam.pyramid.local PYRAMID\PAMAppPool
setspn -S http/mimpam PYRAMID\PAMAppPool


・特権管理対象ドメインへの名前解決設定

 後で既存のドメインから信頼関係を結ぶので、既存ドメインの名前解決ができるようにゾーンを構成しておきます。今回は以下の環境に設定をしています。

 既存ドメイン : eidentity.local
 既存ドメインコントローラ(DNSサーバ) : 192.168.5.30

 条件付きフォワーダを設定します。

Add-DnsServerConditionalForwarderZone -name "eidentity.local" -masterservers 192.168.5.30


◆SQL Server 2014 Standard Editionの導入

 メディアを挿入し、以下で最低限必要なコンポーネントを導入します。

.\setup.exe /Q /IACCEPTSQLSERVERLICENSETERMS /ACTION=install /FEATURES=SQL,SSMS /INSTANCENAME=MSSQLSERVER /SQLSVCACCOUNT="PYRAMID\SqlServer" /SQLSVCPASSWORD="P@ssw0rd" /AGTSVCSTARTUPTYPE=Automatic /AGTSVCACCOUNT="NT AUTHORITY\Network Service" /SQLSYSADMINACCOUNTS="PYRAMID\Administrator"


◆Microsoft Identity Manager 2016(MIM)の導入

・MIMコンポーネントの導入

 最低限のコンポーネントしか導入しないため、同期サービス設定などで警告は出ますが、無視しても大丈夫です。

















・Firewall設定

 特権管理ポータル、PAM REST APIへの外部からのアクセスを許可するため、以下のTCPポートをWindows Firewallで解放します。

 ・8086 : PAM REST API
 ・8090 : 特権管理ポータル


・FIMServiceデータベースへのPAM関連サービスアカウントのアクセス権限付与

 MIMComponent / MIMMonitorの各サービスがFIM Serviceのデータベースから必要な情報を読み出すため、SQL Serverへのアカウントの設定を行います。

[System.Reflection.Assembly]::LoadWithPartialName('Microsoft.SqlServer.SMO')
$uc = New-Object -TypeName Microsoft.SqlServer.Management.Smo.Login -ArgumentList "localhost","PYRAMID\mimcomponent"
$uc.LoginType = 'WindowsUser'
$uc.Create()
$um = New-Object -TypeName Microsoft.SqlServer.Management.Smo.Login -ArgumentList "localhost","PYRAMID\mimmonitor"
$um.LoginType = 'WindowsUser'
$um.Create()
$s = New-Object ('Microsoft.SqlServer.Management.Smo.Server') "localhost"
$d = $s.Databases['FIMService']
$uc2 = New-Object ('Microsoft.SqlServer.Management.Smo.User') ($d, "PYRAMID\mimcomponent")
$uc2.Login = "PYRAMID\mimcomponent"
$uc2.Create()
$um2 = New-Object ('Microsoft.SqlServer.Management.Smo.User') ($d, "PYRAMID\mimmonitor")
$um2.Login = "PYRAMID\mimmonitor"
$um2.Create()
$d.Roles['db_datareader'].AddMember("PYRAMID\mimcomponent")
$d.Roles['db_datareader'].AddMember("PYRAMID\mimmonitor")


・特権管理ポータル用Webサイトを構成する

 CTPで提供されているサンプルポータルを使います。最新ビルドだとちょっと改造が必要なので、そのあたりは追々。。

 とりあえずサンプルモジュールを
  C:\Program Files\Microsoft Forefront Identity Manager\2010\Privileged Access Management Portal\
 へ展開し、Webサイトを作成します。

New-WebSite -Name "MIM Privileged Access Management Example Portal" -Port 8090 -PhysicalPath "C:\Program Files\Microsoft Forefront Identity Manager\2010\Privileged Access Management Portal\"



◆既存ドメインとの信頼関係設定を行う

 既存のドメインから特権管理ドメインへの片方向の信頼関係を結びます。

・名前解決設定

 既存のドメインコントローラから特権管理ドメインへの名前解決ができるように既存ドメインのDNSサーバにpyramid.localのスタブゾーンを作ります。(もちろん別の方法でも良いです)


・SAMデータベースへのRPCの有効化

 既存ドメインコントローラで以下のレジストリを設定(PowerShellで設定)します。これでSID Historyをリモートで読み取れるようになります。

New-ItemProperty -Path HKLM:SYSTEM\CurrentControlSet\Control\Lsa -Name TcpipClientSupport -PropertyType DWORD -Value 1


・特権管理サービスのコマンドレットで必要な信頼関係設定を行う

 信頼関係を結ぶのに必要な設定がパッケージ化されたコマンドレットが用意されているので、特権管理サーバ上で以下のコマンドレットを実行します。
 クレデンシャルが求められるので、既存ドメインの管理者アカウントの権限を入力します。

$ca = get-credential
New-PAMTrust -SourceForest "eidentity.local" -Credentials $ca
New-PAMDomainConfiguration -SourceDomain "eidentity" -Credentials $ca


・既存ドメイン上のオブジェクトへの読み込み権限を委譲する

 Active Directoryユーザとコンピュータより特権アカウント管理ドメイン上のユーザ(MIM MonitorサービスおよびDomain Admins)へ既存ドメイン上のユーザ情報の読み取り権限を委譲します。

 ・委譲先ユーザ: MIMMonitor / Domain Admins
 ・委譲権限 : すべてのユーザ情報の読み取り


ここまでで環境の導入は終了です。
次回は必要な特権管理用ユーザ、グループの設定をしてテストをしてみます。

[MIM]Active Directoryの特権アカウント管理環境を構築する~実施編

$
0
0
こんにちは、富士榮です。

今回は、前回に引き続きMicrosoft Identity Manager 2016(MIM)を使ったActive Directoryの特権アカウントの管理についてです。今回はいよいよ管理対象の特権アカウントを登録し、権限管理をしてみます。

 参考)
  [MIM]特権アカウント管理機能の概要
  http://idmlab.eidentity.jp/2015/06/mim.html

  [MIM]Active Directoryの特権アカウント管理環境を構築する~環境構築編
  http://idmlab.eidentity.jp/2015/07/mimactice-directory.html


◆ロール、特権、ユーザの準備

前々回のポストでも紹介した通り、MIMの中で特権アカウントは以下の図の様に扱われます。


つまり、やるべきことはMIM上に①特権ロール(PAM-Role)を定義する、②特権ロールに対応する特権グループ(PAM-Group)の作成と紐づけ、③特権ロールが利用できるユーザ(PAM-User)の作成と紐づけ、の3点です。

以下の通りPowerShellを使って順番に行います。(実際は特権グループの作成、特権利用ユーザの作成、特権ロールの作成と紐づけという順番なので②⇒③⇒①の順で実行します)

・既存ドメインアカウントの準備
 Shadowアカウントを特権アカウント管理サーバ側のドメインに作成するため、[ドメイン名$$$]という名称のセキュリティグループを既存ドメイン上に作成しておきます。

Import-Module ActiveDirectory
New-ADGroup -name ‘EIDENTITY$$$' -GroupCategory Security -GroupScope DomainLocal -SamAccountName ‘EIDENTITY$$$'

 また、既存ドメイン上の特権として利用するセキュリティグループ(ここではCorpAdmins)の作成および特権利用ユーザの元となるユーザ(ここではJen)を作成しておきます。
 特権利用申請をMIMで行うと、ここで作ったセキュリティグループの持つ権限が付与されることになります。

New-ADGroup -name CorpAdmins -GroupCategory Security -GroupScope Global -SamAccountName CorpAdmins
New-ADUser -SamAccountName Jen -name Jen
Add-ADGroupMember -identity CorpAdmins -Members Jen
$jp = ConvertTo-SecureString "P@ssw0rd" -asplaintext -force
Set-ADAccountPassword -identity Jen -NewPassword $jp
Set-ADUser -identity Jen -Enabled 1 -DisplayName "Jen"

・特権アカウント管理サーバ側の準備
※PowerShellのモジュール読み込み、既存ドメインへの接続

Import-Module MIMPAM
Import-Module ActiveDirectory
$ca = get-credential -UserName eidentity\Administrator -Message "eidentity forest domain admin credentials"

・特権グループの作成(既存ドメイン上のCorpAdminsグループのSIDをコピーして作成)
$pg = New-PAMGroup -SourceGroupName "CorpAdmins" -SourceDomain eidentity.local -SourceDC dc.eidentity.local -Credentials $ca

※dc.eidentity.localは既存ドメインの任意のドメインコントローラ
※New-PAMGroupを実行した段階で特権アカウント管理サーバのドメイン上に[ソースドメイン名].[グループ名]というグループオブジェクト(Shadowアカウント)が作成される。

・特権利用ユーザの作成(既存ドメイン上のユーザ/jenをベースに作成)
$sj = New-PAMUser -SourceDomain eidentity.local -SourceAccountName Jen
$jp = ConvertTo-SecureString "P@ssw0rd" -asplaintext -force
Set-ADAccountPassword -identity priv.Jen -NewPassword $jp
Set-ADUser -identity priv.Jen -Enabled 1
Add-ADGroupMember "Protected Users" priv.Jen

※New-PAMUserを実行した段階で特権アカウント管理サーバのドメイン上にPRIV.[ユーザ名]というユーザが自動的に作成される


・特権ロールへ特権グループ、特権利用ユーザの紐づけ
$pr = New-PAMRole -DisplayName "CorpAdmins" -Privileges $pg -Candidates $sj


これで準備は完了です。
Get-PAMRoleコマンドレットで設定状況が確認できます。
(MIMポータルをインストールした場合は、ポータル上からも確認できます)



◆権限を付与してみる

では、実際に特権の付与をしてみましょう。
権限付与に成功すると、既存ドメイン上のCorpAdminsの権限が特権アカウント管理ドメインのpriv.jenに付与される、つまりpyramid\priv.jenユーザがeidentity\CorpAdminsグループに登録されます。
ですから、eidentity\CorpAdminsグループでないとできないことを定義しておき、権限の付与の前後で出来ることが変わっていればOKです。

今回は、他のユーザのパスワードリセット権限を付与してみます。
やり方としては、既存ドメインのActive Directoryユーザとコンピュータより、CorpAdminsグループにパスワードリセット権限を委譲します。



・特権付与前の状態
 既存ドメイン側で「runas /user:priv.jen@pyramid.local powershell」を実行し、特権付与前の状態でpowershellを起動し、MMCを起動、Active Directoryユーザとコンピュータを立ち上げます。
 この状態だとパスワードのリセットができません。


・特権付与と権限の確認
 では、特権を与えてみましょう。
 特権管理ポータルへアクセスし、pyramid\priv.jenでログインします。Edgeを使ってみました(笑)


 特権の利用を申請します。



 再び、「runas /user:priv.jen@pyramid.local powershell」を起動し、Active Directoryユーザとコンピュータを起動します。
 今度はパスワードのリセットが実行できました。



尚、所定の時間が過ぎると特権が取り消され、priv.jenアカウントがCorpAdminsグループのメンバから外れます。この時、MIMサーバのイベントログに以下のエントリが記録されます。(バッチが走るタイミングに依存するので、ロールに設定したTTLより少し遅れ気味になります)


尚、Windows Server 2016からはKerberosの仕様が変更され、TGTのTTLのコントロールができるようになるため、実際のメンバシップ登録・削除ではなく、Foreign Principalとして仮想的にグループメンバとして登録される形になる予定なので、明示的なグループメンバの削除ジョブが実行されることはなくなる見込みです。こうなれば特権が外れるタイミングがTTLとぴったり合うと思われます。

[Windows10]ついにWindows Helloで顔認証!

$
0
0
こんにちは、富士榮です。

ようやくWindows Helloで顔認証ができるようになりました。

以前のポストで紹介したように、これまではIntel RealsenseのDCMがWindows Helloに対応していなかった関係で対応したカメラを持っていてもWindows Helloで顔認証ができませんでした。

 参考)
 [Windows10]Intel RealSense F200でWindows Hello
 http://idmlab.eidentity.jp/2015/06/windows10intel-realsense-f200windows.html

IntelのフォーラムでDCMの次のバージョンを待て、、と言われて1か月少々、ようやくDCM1.4がリリースされました。
 https://software.intel.com/en-us/intel-realsense-sdk/download


ということで早速導入、試してみました。

◆Windows Helloのセットアップ

「顔認証」のメニューが!!

◆セットアップ


痩せました。はい。。。



うまく行きました!
ロック解除に使えるようになっています。


◆ロック解除してみる



一瞬で解除されました。
想像以上に認識が早いです。

素晴らしいです!

[AAD Connect]LDAPからOffice365へID同期する

$
0
0
こんにちは、富士榮です。

先月正式リリースされたAzure Active Directory Connector(AAD Connector)ではOffice365のアイデンティティ基盤であるAzure Active Directory(Azure AD)へのID同期元として、現状はオンプレミスのActive Directoryが利用できます。
また、今後の拡張プランとしてオフィシャルにActive Directory以外のLDAPディレクトリについても同期元として設定できるようになると思われます。(※あくまで想定です)

 参考)
 [AzureAD]AAD ConnectとConnect HealthがGAになりました
 http://idmlab.eidentity.jp/2015/06/azureadaad-connectconnect-healthga.html

ただ、現状においてもユーザ拡張管理エージェントであるExtensible Connectivity 2.0(ECMA2)を使用してユーザ自身でID同期元を定義することが可能なため、自身でECMA2を利用してLDAP接続コネクタを作成すればオンプレミスにデータソースとして使えるActive Directoryが存在しなくてもLDAPを同期元としてOffice365のアカウントを管理することが可能になります。

今回はECMA2ベースでLDAPコネクタを開発してAAD Connectに設定して、、と思いましたがForefront Identity Manager 2010 R2(FIM)用のGeneric LDAP ConnectorがECMA2ベースだったはず、と思いこちらを使ってみました。(自身で拡張エージェントを開発して設定する分にはサポートされる様ですが、このコネクタを使うのは恐らくサポート外だと思われます。実際に使う場合は自身で開発をした方がベターでしょう

◆準備

・LDAPサーバ
今回、OpenDJを用意しました。
こちらは特にセットアップ方法などは省略します。

・LDAP接続用の管理エージェント
こちらからFIM用のGeneric LDAP Connectorは入手できますので、ダウンロードしてAAD Connectサーバへ配置しておきます。

 ダウンロードページ
 http://www.microsoft.com/en-us/download/details.aspx?id=41163

セットアップするとモジュール(dllおよびxml)が展開されますが、あくまでFIMのディレクトリ構造を想定して展開されるので、このままではAAD ConnectのAAD Syncがモジュールを認識できません。

そこで、必要なファイルを手動で移動します。

移動元)
 C:\Program Files\Microsoft Azure AD Sync\Synchronization Service
 ⇒この下にExensions/UIShellというフォルダがあり、必要なファイルがあります。
移動先)
 C:\Program Files\Microsoft Azure AD Sync
 ⇒同じくExtensions/UIShellフォルダがありますので、それぞれファイルを移動します。


◆コネクタの作成

AAD ConnectのSynchronization Service Managerを起動し、[Connectors]メニューより[Create]をクリックして新規コネクタを作成します。

先に用意したOpenDJへの接続情報を入力していきます。

まずは接続情報です。


次に、対象のツリーです。


そして、対象とするオブジェクトの種類(objectType)です。


属性については特に選択しておく必要はありません。


また、作成が終わったら[Configure Run Profiles]で[Full Import]および[Full Synchronizatio]のプロファイルを作っておきます。(今回は同期元として設定するだけなのでこの2つだけで大丈夫です)


◆同期ルールの作成

今度はAAD ConnectのSynchronization Rules Editorを起動し、Inboud Synchronization Ruleを作成します。

まずは接続するコネクタの定義です。
Connected Systemに先に作成したLDAPコネクタを、Object Typeに同じくinetOrgPersonを、今回はユーザ情報の同期なのでMetaverse Object Typeにperson、Metaverse上にユーザを作成するためのルールなのでLink TypeをProvisionに設定します。
※ちなみにPrecedence(優先度)は他の同期ルールと重複しない値を設定する必要があります。



次にScoping filterの定義です。ここではLDAP上のエントリの中でAzure ADに同期するエントリを絞り込むことができます。
ここではmail属性に値が入っているユーザのみを同期対象としています。



次にMetaverse上のオブジェクトとのマッチングするためのルール(Join rules)を定義します。
ここでは、mail属性がMetaverse上のユーザのuserPrincipalNameと同じ値だったら同じオブジェクトとみなすという設定をしています。



最後に各属性のマッピングです。
Azure ADへ同期するためには、accoutName/sourceAnchor/userPrincipalName/accountEnabled/sourceObjectTypeといった属性が必要なので、givenNameなどの一般属性に加えてそれらの属性についても値を設定しています。
ちなみにaccountEnabledには固定でtrueを、sourceObjectTypeには固定でUserを設定します。


これで設定は終了です。


◆実際に同期する

まず、OpenDJに同期対象のユーザを作成します。
同期条件にmail属性に値が入っていること、を設定したのでE-Mailに値を入れています。
また、同じくmail属性をuserPrinicipalNameにしているので、Azure AD/Office365に設定したカスタムドメインとドメインパートを合わせておく必要があります。



ここまで来たら実際に同期します。
実際に運用する時はスクリプトで実行することになりますが、今回は手動でRun Profileを実行します。
まずは、OpenDJからのFull Import/Full Synchronizationを実行します。


うまく行くとOutbound SynchronizationにAzure ADのコネクタへのProvisioning Addsにカウントが出て来ますので、次にAzure ADコネクタのRun ProfileのExportを実行します。
こちらも問題なく終わるとAddsにカウントが表示されます。


ここまで行けばAzure ADの管理コンソールからユーザの確認ができます。
後はOffice365のライセンスを付与するなりなんなりすれば普通に使うことができます。




後は応用なので、例えばOpenDJをレポジトリとしてOpenAMを構成してAzure AD/Office365とFederationすればオンプレミス側はOSSのみで構成ということも可能になります。
※OpenAMとの連携は以下のエントリを参考にしてください。
 本エントリとよく似たことを前回もやっていますが、当時はOutboundを中心に書いていたので、Inboundについては今回のエントリを参考に構成してください。

 [Office365/AzureAD]OpenAMとのID連携①
 http://idmlab.eidentity.jp/2014/11/office365azureadopenamid.html

 [Office365/AzureAD]OpenAMとのID連携②
 http://idmlab.eidentity.jp/2014/12/office365azureadopenamid.html

 [Office365/AzureAD]OpenAMとのID連携③
 http://idmlab.eidentity.jp/2014/12/office365azureadopenamid_25.html


[AzureAD/RemoteApp]AzureADでRemoteAppのアクセス制御を行う

$
0
0
こんにちは、富士榮です。

Azure RemoteAppはいわゆるクラウド上でホストされるVDIサービスで、これを使うとiOSやAndroidを含む組織外のデバイスを使って企業内で使ってきたデスクトップアプリケーションを利用できるようになります。

 詳しくはこのあたりで。
  Microsoft RemoteAppで何ができるの?
  http://www.atmarkit.co.jp/ait/articles/1405/15/news035.html


Azure RemoteAppを利用する際は、Azure Active Directory(Azure AD)を使って認証をすることになるので、多要素認証やアクセスルールを使った制御、さらにActive Directory Federation Services(AD FS)の多要素認証機能やDevice Registration Servie(DRS)と連携したハイブリッドID基盤を構成することでクライアント証明書がインストールされている端末のみアクセスを許可する、など細かなデバイス制御を行うことも可能になります。

と、言うことで今回は先月末に公開されたAzure ADのアクセスルールを使ったアクセス制御を試してみます。

 Active Directory Team Blog
  Azure AD Conditional Access preview update: More apps and blocking access for users not at work
  http://blogs.technet.com/b/ad/archive/2015/06/25/azure-ad-conditional-access-preview-update-more-apps-and-blocking-access-for-users-not-at-work.aspx


◆RemoteAppのセットアップ

 ここはバッサリと省きますが、管理ポータルからRemoteAppコレクションを作ります。今回は素のOSイメージでよかったのでWindows Server 2012R2のテンプレートを使いました。実運用ではAzure VMやHyper-V上に実際の業務アプリケーションをインストールしてsysprepしてカスタムテンプレートを作ります。


 それなりに時間がかかりますが、セットアップが終わるとデフォルトでいくつかアプリケーションが発行されています。



◆ユーザの割り当て

 実際にRemoteAppを利用するユーザを割り当てます。割り当て可能なユーザはAzure ADのディレクトリに登録されているユーザです。
 ※ここがグループベースで割り当てできるようになると良いんですけどねぇ。。。





◆まずはそのまま利用する

 ここまででRemoteAppとしては設定が終わりなので、まずは素の状態で使ってみます。

 PCからだとRemoteAppクライアントは以下のURLからダウンロード出来るので、あらかじめダウンロード・インストールしておきます。

 https://www.remoteapp.windowsazure.com/

 ※ちなみにiOS/AndroidではRemote DesktopアプリケーションからRemoteAppを使えます。
 iOS版:
  https://itunes.apple.com/jp/app/microsoft-rimoto-desukutoppu/id714464092?mt=8
 Android版:
  https://play.google.com/store/apps/details?id=com.microsoft.rdc.android&hl=ja


 起動~開始するとAzure ADのログイン画面になるのでログインします。


 ログインに成功するとアプリケーション一覧が表示され、利用できます。




◆アクセス制御をかける

 いよいよ本題です。
 RemoteAppを構成した段階でAzure ADディレクトリの中のアプリケーション一覧にRemoteAppが追加されます。AzureADから見ると管理対象のアプリケーション(サービス)という扱いになっているんですね。


 早速RemoteAppアプリケーションを開き、構成メニューを見るとお馴染みのアクセス・ルールが構成できます。

 ここでは以前紹介したのと同じように社外からのアクセスだったら多要素認証を要求する、というルールを入れてみます。

 参考)
 [AzureAD]アクセスルールで社外からのアクセスを制御する
 http://idmlab.eidentity.jp/2015/06/azuread.html


 構成後、同じようにRemoteAppを立ち上げてみると多要素認証を要求されるようになります。


 また、この際、社外からのアクセスをブロックするように設定するとエラーメッセージが出てアクセスに失敗します。
 メッセージとしては普通にWebアプリケーションへSSOする時よりも親切なメッセージになっている気がします。



 ちなみにiOS版のRemoteDesktopからだと右上の+メニューよりAzure RemoteAppが追加できます。


 ログオンUIはPCとほぼ同じですね。


 アプリケーション一覧もこんな感じです。



 ただ、アプリを起動するとちょっと寂しいです。





いかがでしょうか?
今回は単純にAzure AD側でアクセス制御をしてみましたが、AD FSと組み合わせるともっと柔軟に制御ができるようになるので、おいおい試してみたいと思います。

[Azure AD/ASP.NET]ユーザ属性を取得する2つの方法

$
0
0

こんにちは、富士榮です。

7/29のWindows10のリリースで盛り上がっていますが、その直前にひそかにリリースされていたVisual Studio 2015ではASP.NETのアイデンティティ関連機能が色々と拡張されています。

概要はVisual Studioの公式blogでアナウンスされているので、そこはそちらに任せておくとして、今回はASP.NET MVC5のプロジェクト・テンプレートが拡張されてGraph APIを使ってAzure ADのユーザ属性の取得がされるように変わっているのでその辺りの解説をしたいと思います。また、以前のバージョンから仕えましたが、SSO時のJWT(JSON Web Token)からClaim(属性)を取り出す方法について解説します。

 参考)Visual Studioの公式blog
  Identity Management Features in Visual Studio 2015
  http://blogs.msdn.com/b/visualstudio/archive/2015/07/22/identity-management-features-in-visual-studio-2015.aspx


◆ASP.NETでAzure ADからユーザ情報を取得する方法

先にも書きましたが、ASP.NETでAzure ADと連携するアプリケーションを開発する場合、以下の2つの方法で認証済みユーザの属性を取得することができます。

1.認証時にAzure ADで発行されるJWTに含まれるClaim(属性)を取得する
2.認証後、Graph APIを使ってディレクトリ(Azure AD)上のユーザ属性を取得する


早速それぞれの方法について解説します。


◆JWTに含まれるClaimを取得する

ASP.NETアプリケーションのプロジェクトを作成する際、認証の構成を設定できます。



ここでAzure ADのテナント情報を入れるとアプリケーション起動時にAzure ADを使って認証が行われるようになります。
その際、内部的な動作としてはOpenID Connectを使ったID連携が行われ、Azure ADからアプリケーションにJWTがPOSTされてきます。

POSTされるid_tokenの中身をJWT Decoderでデコードしてみると、以下のようなClaimが含まれていることがわかります。


{
"aud": "0897xxxxxxxxx65c",
"iss": "https://sts.windows.net/2c6xxxxxxxxxxxx1bfff/",
"iat": 1438609784,
"nbf": 1438609784,
"exp": 1438613684,
"ver": "1.0",
"tid": "2c62f1axxxxxxxxxxxbb1bfff",
"oid": "457ca53xxxxxxxxxe363dc73c",
"upn": "nfujie@xxxxxxxxx.onmicrosoft.com",
"sub": "ILvM1kZdv7kxxxxxxxxiPrw2fPusCk",
"given_name": "Naohiro",
"family_name": "Fujie",
"name": "Naohiro Fujie",
"amr": [
"pwd"
],
"unique_name": "nfujie@xxxxxxxx.onmicrosoft.com",
"nonce": "63574206878.....snip....LTg0YmMtOGFkYmMyZTcwY2Yz",
"c_hash": "QIsD2...snip...fYgA"
}


これを見るとユーザのUPN(userPrincipalName)や姓(surName)、名(giveName)などもid_tokenの中に含まれていることがわかります。
これらの属性をアプリケーションから取得することが出来れば、アプリケーション上でログインIDだけでなく、ユーザ表示名を表示してあげることが出来るようになるはずです。

では、早速取得してみます。
まず、Azure ADを使った認証がプロジェクト・テンプレート上でどのように実装されているのかを見てみます。
ソリューション・エクスプローラからApp_Startフォルダの中のStartup.Auth.csを開くと、Microsoft.Own.Security.OpenIdConnectを使ってAzure ADとのOpenID ConnectでのID連携を実装していることがわかります。


と、いうことは認証後、id_tokenに関する情報はOwinContextに入れられるはずなので、アプリケーションからはOwinContextの中身を検索することでClaim情報が取得できるはずです。

RequestのGetOwinContext()メソッド使ってContextを取得し、その中の認証およびユーザに関する情報をAuthenticationプロパティ/Authentication.Userプロパティから取得します。
あとは、取得したUserオブジェクトのClaimsコレクションからClaimを順番に取り出せばid_tokenの中身が取得できます。

具体的には以下のようなコードを書きます。


var ctx = Request.GetOwinContext();
var user = ctx.Authentication.User;
var response = ctx.Response;
response.ContentType = "text/html";
if (user.Identity.IsAuthenticated){
foreach(var claim in user.Claims){
response.Write(claim.Type + "=" + claim.Value + "<BR>");
}
}




◆Graph APIを使ってAzure ADから属性を取得する

次はGraph APIを使って認証済みユーザの属性をAzure ADへ問い合わせ、取得する方法です。
プロジェクトの認証構成を行う際に、ディレクトリ情報の読み取り許可を与えることでGraph APIを使ってユーザ情報を取得できるようにプロジェクトが構成されます。


アプリケーションを起動し、Azure ADで認証後、画面右上に表示されるログインIDをクリックするとUserProfileが表示されます。



この部分の実装を見るとGraph APIを使ってユーザ属性を取得しています。
対象のソースはControllers以下のUserProfileControllers.csです。GraphClientが使用されていることがわかります。



実際はこのControllerから呼び出されるViewにuserオブジェクトを渡しているので、表示項目の見せ方については対象のViewであるViews/UserProfile/Index.cshtmlを見てみます。ここでは@Model.[属性名]という形で属性を取得してテーブルに埋め込んでいますので、好きな属性を指定してテーブルを拡張していくことで任意の属性を表示させることが可能です。(今回はJobTitle属性を追加しています)




どちらの方法が適しているのかは、どんな属性が必要なのかをベースに考えれば良いと思います。例えば役職や組織情報を使ってアクセス権制御を行いたければGraph APIを使う方法になると思いますし、単に名前を表示させるだけならJWTから取得する方が通信量が少ないので実装としては軽くなります。
※現状のAzure ADではid_tokenに含めるClaimのカスタマイズができないので、id_tokenにない属性を取得したければGraph APIを使うしか方法がありません。


いずれにしてもAzure ADを使った認証や属性取得がかなり楽に実装できるようになっていますので、あまりカスタムで頑張った実装をするよりもテンプレートにある仕組みを使ってアプリケーション開発をしていった方が今後はよさそうですね。

[MIM]Microsoft Identity Manager 2016がリリースされました

$
0
0
ついにForefront Identity Manager 2010(FIM)の後継であるMicrosoft Identity Manager 2016(MIM)が正式にリリースされました。

製品ページ)
 http://www.microsoft.com/en-us/server-cloud/products/microsoft-identity-manager/


以前のポストでも紹介したように、MIMでは以下の機能が目玉となっています。

  • 特権アカウント管理
  • 多要素認証を使ったセルフ・サービス・パスワード・リセット
  • Universal Windowsアプリでの証明書管理クライアントの提供
  • 最新プラットフォームのサポート


※画像はCTP4です。


MSDN等でもダウンロードできるようになっていますし上記製品ページから評価版も入手できるので、是非試してみましょう。

[Azure AD]Cloud App DiscoveryでシャドーITを検知する

$
0
0
こんにちは、富士榮です。

最近の企業の情報システム部門を見ていると、事業部門が使う業務アプリケーションについて、
・セキュリティを担保した上で使ってもらいたい
・そのためには何を使っているのかを把握し統制を効かせたい
・ただ、全部のアプリケーションを情報システム部門で管理する人的リソースがない
という状態になっているように感じます。
その結果として、いわゆる「シャドーIT」とか「野良IT」と言われる各事業部門側が個別にSaaSアプリケーションなどを契約し使っている状態が散見される状態となっている訳です。

本来はIDaaSなどをうまく活用して各SaaSアプリケーションのID部分だけでも情報システム部門で抑え込んでせめて退職済みアカウントでは使えない状態にする、などの統制を効かせる工夫をしたいところですが、すでに利用が始まってしまっているシャドーITの状態を把握するのは大企業になればなるほど困難になります。

※IDaaSの概要と情報システム部門での活用については先日始まった@ITの連載をご覧ください。
 企業のID管理/シングルサインオンの新しい選択肢「IDaaS」の活用:
  第1回 もはや企業のID管理で避けては通れない「IDaaS」とは?
  http://www.atmarkit.co.jp/ait/articles/1508/07/news034.html


と、いうことで今回はすでに業務部門に広まってしまったSaaSアプリケーション利用の状態を把握するために用意されているAzure ADの追加機能「Cloud App Discovery」について解説します。

◆Cloud App Discoveryとは

先に書いた通り、企業内からどのようなSaaSアプリケーションが実際に使われているのかを検出するためのツールで、Azure AD Premiumのライセンスが割り当てられている管理者が機能を使うことが出来ます。

仕組みとしては、組織内のコンピュータにCloud App Discovery用のエージェントをセットアップし、各コンピュータからのSaaSアプリケーションの利用状況をAzure ADに集める、という構成になっています。※エージェントモジュールは各Azure AD/Cloud App Discoveryテナント毎に証明書とセットでダウンロードされるので、System Centerやグループポリシーなどのクライアント構成ツールで各コンピュータに配布します。
※サービス解説ページより


◆Cloud App Discoveryの有効化

Azure Portalのマーケットプレイスより追加します。Azure Portalのマーケットプレイスを開くと「セキュリティ+ID」のセクションに「Azure AD Cloud App Discovery」があるので選択して作成します。




◆Cloud App Discoveryの設定:コンピュータへのエージェント導入

先にも書いた通り、通常はSCCMなどでモジュールを配布することになると思いますが、今回は手動でインストールしてみます。
Azure PortalからCloud App Discovery、クイックスタートを開くと「エージェントのダウンロード」というセクションがあり、ここからエージェントモジュールをダウンロードできます。現段階ではWindows 7以降のコンピュータに対応しているようです。



ダウンロードしたモジュールを解答し、セットアップファイルを実行するとGUIモードでエージェントをインストールできます。特に設定オプションはないのでそのままインストールします。





インストール後、PCのサービスの状態を見ると[SerresEndpointAgent]というサービスが動いていることがわかります。これがエージェントモジュールの実体です。


あとは放っておけばAzure AD上にクライアントが利用したSaaSアプリケーションの情報が集まってくるはずです。


◆Cloud App Discoveryの設定:収集対象アプリケーションの絞り込み

当然このままでも良いのですが、ある程度収集対象とするアプリケーションの種類を絞り込みたい場合もありますので、ポータル側で収集対象アプリケーションの絞り込み設定を行うことができます。

[設定]から[データコレクション]のセクションを開くと対象のアプリケーションの絞り込み設定を行うことが出来ます。
既定では2,100程度のアプリケーションが選択された状態になっていますので、必要なアプリケーションのみに絞り込むことが可能です。




◆収集結果の分析

ある程度データが集まるとCloud App Discovery上のグラフに、
・アプリケーションの利用数
・ユーザ数
・エージェントの導入数
が表示されてきます。

それぞれを展開するとどのようなアプリケーションを使ったのか、誰が使ったのか、どのコンピュータにエージェントが導入されているのかがわかります。





◆非管理対象のアプリケーションをAzure ADで管理する

アプリケーションの利用情報が収集できたら、管理対象にしたいアプリケーションを選択するとAzure ADのアプリケーション管理メニューへ移動できるので、事業部門へアナウンスし、アプリケーションとの連携設定を行い、あとはAzure ADを経由して使ってもらえば、通常のアプリケーションと同様にAzure ADのレポーティングで利用状況のモニタリングが可能になります。




最初からAzure ADなどのIDaaSを使ってすべてのアプリケーションを利用する、というように統制が効かせられる環境であれば特にこのような工夫は必要にはなりませんが、なかなかそのような状況はないと思いますので、まずはこのような形で利用実態を把握するところから始めるのが良いのかもしれません。

[雑記/Azure AD]MSDN特典でサポート・リクエスト作成ができない件

$
0
0
こんにちは、富士榮です。

今回はIdMにあんまり関係ない話題です。

◆概要

Azure Active Directory(Azure AD)に関するテクニカルな問題に関するサポートへの問い合わせをMSDNのアクセスID、契約IDで行おうとして見事にはまった話です。

結論はアクセスID、契約ID(7桁)の頭に「065」をつける必要がある、ということなのですが、どこにもこのような記述がなく、技術的な問い合わせをする前に、問い合わせ方法に関する問い合わせを別途行う必要があった、、という。。。

以下、顛末です。

◆MSDNのアクセスID、契約IDの取得

・MSDNの特典についてるアクセスIDと契約IDはアクティベーション(電話もしくはオンラインチャットのみで可能)を行うことで取得できます。
・即時発行はできないらしく、翌日メールで通知されました。
・通知されてきたアクセスID、契約ID(契約番号)は同じ番号で7桁のものでした。

こんなメールが来ます。

◆Azureの新ポータルより問い合わせ

・Azureに関連する問い合わせは新ポータルより行うことになります。(強制的に新ポータルに飛ばされます)
・今回はAzure ADに関する技術的な問い合わせをしたかったので、以下の順に登録します。
 リクエストの種類 : テクニカル
 サブスクリプション情報 : MSDNのサブスクリプション
 リソース : Active Directory
・次にサポートプランの選択をするのですが、初回問い合わせなので先ほどのアクセスID、契約IDを入力するのですが、上手く入力できません。


なぜかアクセスIDが無効とのこと。


◆途方に暮れた末、サポートに電話、先頭に「065」をつけると良いらしいとの裏技を聞く

・サポートの方と会話したところ、このポータルで入力するアクセスIDは10桁である必要があるそうです。。。
・MSDNから通知されたアクセスIDは7桁でしたので、先頭に「065」をつける必要があるらしいです。
・ちなみにアクセスIDだけでなく、入力上はエラーにならなかった契約IDについても「065」をつけないと[リンク]に失敗します。




◆無事にサポートプランが選択できるようになり、技術問い合わせが可能になる

・リンクに成功すると、サポートプランのプルダウンでプラン選択ができるようになります。






◆結論

・さすがに先頭に「065」をつける裏技があるとは想像すらできませんでした。Azure難しいです。


[Azure AD]OpenID ConnectのUserInfoエンドポイントを使ってユーザ情報を取得する

$
0
0
こんにちは、富士榮です。

今回はAzure Active Directory(Azure AD)からOpenID Connectを使ってユーザの属性情報を取得してみます。

先日のポストではASP.NETアプリケーションから属性を取得する方法として、id_tokenの中身をデコードする方法とGraph APIを使って問い合わせる方法を紹介しましたが、今回はOpenID ConnectのUserInfoエンドポイントから情報を取得します。


◆技術仕様

OpenID Connect1.0の仕様を見ると、UserInfoエンドポイントは以下のように定義されています。

UserInfo Endpoint は, 認証された End-User に関する Claim を返す OAuth 2.0 Protected Resource である. 要求された End-User のクレームを取得するため, クライアントは OpenID Connect Authentication を通して得られた Access Token を用いて UserInfo Endpoint に要求する. これらのクレームは通常, クレームの名前と値のペアのコレクションを含んだ JSON オブジェクトで表現される.


同じく、UserInfoエンドポイントへのアクセスの流れがImplementer's Guideに記載されています。


参考)OpenID Connect Basic Client Implementer's Guide 1.0 日本語訳

今回は、このガイドに従いAzure ADのUserInfoエンドポイントからユーザの属性情報を取得してみます。


◆Azure ADのエンドポイント情報の確認

UserInfoを取得するにあたって必要なAzure ADのエンドポイント情報を/.well-known/openid-configurationエンドポイントで確認します。
普通にブラウザでエンドポイントにアクセスすると各種構成情報がJSON形式で表示され、エンドポイントのアドレスについても以下の通り確認できます。

エンドポイントアドレス
Authorizehttps://login.microsoftonline.com/common/oauth2/authorize
Tokenhttps://login.microsoftonline.com/common/oauth2/token
UserInfohttps://login.microsoftonline.com/common/openid/userinfo


参考)openid-configurationエンドポイント



◆Azure AD上にクライアント登録をする

OAuth2.0のリソースアクセスなので、当然クライアントを事前に登録しておく必要があります。Azure ADにおけるクライアント登録はディレクトリ設定の中のアプリケーションのメニューから行います。
アプリケーションはWebアプリケーションとして登録し、URLの返信(redirect_uri)およびクライアントID(client_id)、キー(client_secret)を取得しておきます。
今回はテスト用なのでredirect_uriは適当にhttp://localhostとかにしておき、あとはChrome ExtensionのAdvanced REST clientを使って動作確認をしています。






◆アクセスしてみる

さて、実際にアクセスしてみたいと思います。
流れとしては、先に紹介した仕様の通り、
1. Authorizationエンドポイントへアクセスしてcodeを取得する
2. TokenエンドポイントへcodeをPOSTしてaccess_tokenを取得する
3. 取得したaccess_tokenをAuthorizationヘッダにつけてUserInfoへアクセス、情報を取得する
という順に行います。


1. Authorizationエンドポイントへアクセスしてcodeを取得する

ブラウザを使って以下のGETリクエストを発行します。(改行は取り除いてください)


https://login.microsoftonline.com/common/oauth2/authorize?
client_id=0856fxxxxxxxxxxx6bd0cf&
response_type=code&
redirect_uri=http%3A%2F%2Flocalhost&
scope=openid&
state=12345


すると、redirect_uriに指定したアドレスにクエリパラメータとしてcodeがついてきますので、値をコピーしておきます。


http://localhost/?
code=AAABAAAAixxxxlWqrLsxILSH6fJ99WvmIAA&
state=12345&
session_state=9fac9xxxxx

尚、codeの有効期限は非常に短いのでこの後の作業は手早く行う必要があります。


2. TokenエンドポイントへcodeをPOSTしてaccess_tokenを取得する

ここからはAdvanced REST clientを使います。
先ほど取得したcodeおよびclient_id、client_secret、redirect_uriと合わせてgrant_typeにauthorization_codeを指定して、TokenエンドポイントへPOSTします。


https://login.microsoftonline.com/common/oauth2/token
grant_type: authorization_code
client_id: 0856fxxxxxxxxxxx6bd0cf
code: AAABAAAAixxxxlWqrLsxILSH6fJ99WvmIAA
redirect_uri: http://localhost
client_secret: WjFotGxxxxxxxxx+imo=


すると、以下の様にaccess_token、refresh_token、id_tokenが返ってきます。


{
expires_in: "3600"
token_type: "Bearer"
expires_on: "1439454521"
access_token: "AAABAAAAixxxxxxxxWC0VQSAA"
refresh_token: "AAABAAAAxxxxxxxx6XIAA"
id_token: "eyJ0eXAiOiJKVxxxxxxxxEqegYSCaCaQrw"
}


もちろん以前紹介したようにid_tokenをデコードすればユーザの属性情報は取得できますが、あえてスルーします。

参考)id_tokenをデコードした結果

{
"aud": "0856fxxxxxxxxxxx6bd0cf",
"iss": "https://sts.windows.net/2c.......fff/",
"iat": 1439450621,
"nbf": 1439450621,
"exp": 1439454521,
"ver": "1.0",
"tid": "2c.........fff",
"oid": "785........4bed4",
"upn": "jbecker@example.net",
"sub": "NnF_CZAQ...............qoOv4",
"given_name": "Jason",
"family_name": "Becker",
"name": "Jason Becker",
"amr": [
"pwd"
],
"unique_name": "jbecker@example.net",
"onprem_sid": "S-1-5-21-.........2-1618"
}



3. 取得したaccess_tokenをAuthorizationヘッダにつけてUserInfoへアクセスする

いよいよUserInfoエンドポイントへアクセスします。
前のステップで取得したaccess_tokenをAuthorizationヘッダにつけてGETリクエストを出せば良いので、同じくAdvanced REST clientでクエリを発行します。


https://login.microsoftonline.com/common/openid/userinfo
Authorization: Bearer AAABAAAAixxxxxxxxWC0VQSAA

結果、以下とおりJSONでユーザの属性情報が取得できます。


{
tid: "2c.........fff"
oid: "785........4bed4"
upn: "jbecker@example.net"
sub: "NnF_CZAQ...............qoOv4"
given_name: "Jason"
family_name: "Becker"
name: "Jason Becker"
}


id_tokenの方が情報が多いですね・・・。

ちなみに、現状Azure ADでは一般的なOpenID ConnectのProviderの様にprofileやemailなどのscopeが使えず、openidのみしか指定できないので、取得するclaim(属性)を指定することは出来ません。


尚、本日アナウンスされたApp Model v2.0用のAPIバージョン(oauth2/v2.0/のエンドポイント)ではUserInfoへのアクセスがまだ使えないので、マイクロソフトアカウントに関する属性情報の取得はできません。

[Azure AD]App Model v2.0を利用して組織内外共用のアプリケーションを開発する

$
0
0
こんにちは、富士榮です。

近年は企業の働き方の変革が進み、業務アプリケーションについても企業組織内だけでなくグループ企業間で共用したり、サプライチェーンの中の関連企業との間で同じアプリケーションを共同利用するようなケースが増えてきています。

そうなってくると、Azure Active Directory(Azure AD)を使って認証するようなアプリケーションについても単一テナントに紐づけるのではなく、他のAzure ADテナントやマイクロソフトアカウントを使ってログインできるようにしたくなるところです。

これまでもマルチテナントアプリケーションとしてAzure AD上にアプリケーションを登録することは可能でしたが、Azureの管理ポータルのようにマイクロソフトアカウントを使ったログインまではできませんでした。今回Public Previewとして登場したApp Model v2.0ではその部分を補完してくれています。尚、中身はOAuth2.0およびOpenID Connectです。

 Active Directory Teamのブログでのアナウンス
  Now in public preview: The Converged Microsoft Account and Azure Active Directory Programming Model
   http://blogs.technet.com/b/ad/archive/2015/08/12/azure-ad-microsoft-account-preview-sign-in-personal-and-work-accounts-using-a-single-stack.aspx

 開発者向けドキュメント
  App Model v2.0 Preview: Auth Protocols - OAuth 2.0 & OpenID Connect
   https://azure.microsoft.com/en-us/documentation/articles/active-directory-v2-protocols/


早速、どのように動くのか確認してみます。

今回は、Azure ADの組織アカウントでも個人のマイクロソフトアカウントでもログインでき、個人のユーザ情報を表示するアプリケーションを作ってみます。尚、アプリケーションはAzure上にホストするWebアプリをVisual Studio OnlineでPHPを使って書いてみます。
ブラウザだけで何でもできるので非常に簡単です。


必要な作業は以下の通りです。
1. Azure App ServiceよりWebアプリを作成する
2. クライアントをアプリケーション登録ポータルから登録する
3. Visual Studio Onlineでアプリケーションを書く


では、準備を進めます。

1. Azure App ServiceよりWebアプリを作成する

この作業の最大の目的はURLを確定させることです。
ここで取得したURLをredirect_uriとしてアプリケーション登録するためです。

中身はなんでもいいので、とりあえずAzureの管理ポータルから簡易作成します。


URLのうちホスト名は[任意の名前].azurewebsites.netとなるので、他と重複しない名前を付けてください。


2. クライアントをアプリケーション登録ポータルから登録する

次にアプリケーションを登録します。
以下よりアプリケーション登録ポータルにログインし、アプリケーションを登録します。尚このポータルへはAzure ADの組織アカウントもしくはマイクロソフトアカウントでログインします。

 https://apps.dev.microsoft.com/

ログインすると右上に[アプリの追加]というボタンがあるので、ここをクリックして登録を開始します。


アプリケーションID(client_id)は自動的に割り当てられるので、まずは任意のアプリケーション名をつけます。



次にプラットフォームの項目より[プラットフォームの追加]をクリックしてアプリケーションのプラットフォームを選択します。今回はWebアプリケーションを選択します。



次にリダイレクトURIの設定を行うので、先に登録したアプリケーションのURLを使います。今回はこの後作成するPHPページをindex.phpとしたので、ここでは先ほどのホスト名+index.phpをリダイレクトURIとして登録しています。



次はアプリケーションシークレットを生成します。これがclient_secretになります。
アプリケーションシークレットの項目の[新しいパスワードを生成]をクリックし、生成されるclient_secretをメモしておきます。




最後にページ下部にある、[保存]をクリックしてアプリケーション登録は完了です。



3. Visual Studio Onlineでアプリケーションを書く

では、実際に動くアプリケーションを書いてみます。
先ほど書いたように今回はVisual Studio Onlineを使ってPHPアプリケーションを書きます。

まずは、先ほど作成したアプリケーションをAzure管理ポータル(今回は新ポータルを使っています)から開き[ツール]-[拡張機能]-[Visual Studio Online]の順に開きます。
※あらかじめ拡張機能としてVisual Studio Onlineを追加しています。


するとエディタが開くので右クリックで新規にindex.phpという名前でファイルを作成し、コードを書いていきます。


実際の使ったコードは以下の通りです(かなり手抜きですが・・・)。単純なcodeフローですね。ちなみにcodeからid_tokenを取得するところでcurlのエラー60番(SSLのVerificationエラー)が出るので、CURLOPT_SSL_VERIFYPEERをfalseにセットしています。マイクロソフト内部の通信のはずなんですが・・・。

<?php

// パラメータ類
$authorization_endpoint = 'https://login.microsoftonline.com/common/oauth2/v2.0/authorize';
$token_endpoint = 'https://login.microsoftonline.com/common/oauth2/v2.0/token';
$client_id = '1ae7xxxxxxxxxxxx2b99';
$client_secret = 'ErxxxxxxxxxxxxxxW0jp';
$redirect_uri = 'https://pharaohphp.azurewebsites.net/index.php';
$response_type = 'code';
$state = 'hogehoge'; // 手抜き
$nonce = 'fogafoga'; // 手抜き

// codeの取得(codeがパラメータについてなければ初回アクセスとしてみなしています。手抜きです)
$req_code = $_GET['code'];
if(!$req_code){
// 初回アクセスなのでログインプロセス開始
// GETパラメータ関係
$query = http_build_query(array(
'client_id'=>$client_id,
'response_type'=>$response_type,
'redirect_uri'=> $redirect_uri,
'scope'=>'openid',
'state'=>$state,
'nonce'=>$nonce
));
// リクエスト
header('Location: ' . $authorization_endpoint . '?' . $query );
exit();
}

// POSTデータの作成
$postdata = array(
'grant_type'=>'authorization_code',
'client_id'=>$client_id,
'code'=>$req_code,
'client_secret'=>$client_secret,
'redirect_uri'=>$redirect_uri
);

// TokenエンドポイントへPOST
$ch = curl_init($token_endpoint);
curl_setopt( $ch, CURLOPT_SSL_VERIFYPEER, false);
curl_setopt( $ch, CURLOPT_POSTFIELDS, http_build_query($postdata));
curl_setopt( $ch, CURLOPT_RETURNTRANSFER, true );
$response = json_decode(curl_exec($ch));
curl_close($ch);

// id_tokenの取り出しとdecode
$id_token = explode('.', $response->id_token);
$payload = base64_decode(str_pad(strtr($id_token[1], '-_', '+/'), strlen($id_token[1]) % 4, '=', STR_PAD_RIGHT));
$payload_json = json_decode($payload, true);

// 整形と表示
print<<<EOF
<html>
<head>
<meta http-equiv='Content-Type' content='text/html; charset=utf-8' />
<title>Obtained claims</title>
</head>
<body>
<table border=1>
<tr><th>Claim</th><th>Value</th></tr>
EOF;
foreach($payload_json as $key => $value){
print('<tr><td>'.$key.'</td><td>'.$value.'</td></tr>');
}
print<<<EOF
</table>
</body>
</html>
EOF;

?>



書いたコード自動的に保存されるので、これで準備はこれで終了です。


◆テストしてみる

いよいよ動かしてみます。
Azure ADの組織アカウントとマイクロソフトアカウントの両方でログインできて、ユーザ情報が取得できていればOKです。


まずはマイクロソフトアカウントでログインしてみます。

アプリケーションのURLを開くと、ログイン画面が出てくるのでログインアカウントの欄にマイクロソフトアカウント(メールアドレス)を入力します。


すると自動的にマイクロソフトアカウントのログインページに遷移が始まります。


ここでパスワードを入力してサインインします。



すると初回アクセスだとアプリケーションによるアクセス許可の同意画面が出てくるのでアクセスを許可します。



上手く動けばアプリケーションに遷移し、id_tokenに含まれるclaim(属性情報)が一覧で表示されます。




次はAzure ADの組織アカウントを使って同じことをしてみます。

先ほどと同じくアプリケーションを開き、今度はAzure AD上のアカウントを入力すると、Azure ADのログイン画面へ遷移しますので、パスワードを入れてサインインします。



すると同じく同意画面が出てきますのでアクセスを許可します。



同じく上手く動けばアプリケーションに遷移し、claim一覧が表示されます。マイクロソフトアカウントとAzure AD組織アカウントでは取得できる情報が若干異なるようです。




いかがでしょうか?
まだPreviewということでscopeが制限されていたりしますが、とりあえずログインまでは問題なく動くようですので、今後、外部アカウントと共同で業務を行う場合などはこのようなモデルでアプリケーションを開発するのも一つの選択肢となるかも知れません。

[AADSync/MIM]プロキシサーバ経由でID同期を行う

$
0
0
こんにちは、富士榮です。

企業内からOffice365などのSaaSアプリケーションをAzure Active Active Directory(Azure AD)経由で使う場合、オンプレミスのActive Directory上のアカウントをAzure AD Sync(AADSync)やMicrosoft Identity Manager 2016(MIM)のAzure AD Connectorを使って同期するのが一般的なシナリオです。

しかし、ほとんどの企業のネットワークには厄介なことにプロキシサーバが配置されており、AADSyncなどクラウド上のサービスに直接通信を行うサーバーを導入する際、どこに配置するのか非常に悩んだり、面倒な申請を上げてプロキシのバイパス設定や、場合によってはネットワーク機器のフィルタリングやルーティング設定を変更する必要性が出てきたりします。

本格導入をする場合は、その辺りの環境の洗い出しや構成変更についても覚悟をもって構築作業をするのでしょうが、開発環境やテスト環境として使う場合はそこまで大掛かりな準備をする手間がかけられず、困ることが多いと思います。

そのようなケースにおいてAADSyncやMIMがプロキシサーバを参照して動作するための設定を行う必要があります。

ケースとして以下の3つのパターンに対応することが可能です。
1. 認証なしのプロキシサーバを使っている
2. BASIC認証が必要なプロキシサーバを使っている
3. NTLM認証が必要なプロキシサーバを使っている

それぞれについてどのように対応するか解説していきます。


1. 認証なしのプロキシサーバを使っている

このケースは比較的簡単です。
マイクロソフトのサポートサイトにも情報が記載されており、具体的には「C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config」にプロキシサーバに関するエントリを追加して再起動するだけです。

 サポートサイト
 https://support.microsoft.com/en-us/kb/3013032

以下のエントリをConfigurationブロックの最後に追記します。


<system.net>
<defaultProxy>
<proxy
usesystemdefault="true"
proxyaddress="http://[Proxyサーバアドレス]:[ポート番号]"
bypassonlocal="true"
/>
</defaultProxy>
</system.net>


2. BASIC認証が必要なプロキシサーバを使っている

ここからが少しトリッキーになってきます。
先のmachine.configには認証に使うユーザIDやパスワードを記載することが出来ないので、認証プロキシとAADSync/MIMの中間に認証なしのプロキシサーバを挟み、上位プロキシへフォワードさせる際に中間のプロキシサーバから認証情報をつける、ということを行います。


上位のプロキシサーバがBASIC認証を使う場合は、squidを使うことで対応することが可能です。
※尚、中間プロキシサーバの要件としては①http/httpsを上位プロキシサーバへフォワード出来ること、②フォワード時にBASIC認証に対応できることの2点なので、squid以外でも対応できるものがあるかもしれません。

今回はAADSyncサーバにWindows版のsquidを同居させました。

 Windows版squidのダウンロード

C:\squid以下にダウンロードしたモジュールを展開し、etcフォルダ以下のmime.conf.defaultをmime.confへリネームし、以下の内容のsquid.confを新規作成します。
(今回は限定的な用途なので、最低限のエントリだけしか記載していません。ログなど出したければsquid.conf.defaultを参考に追記してください)


acl all src all
acl localhost src 127.0.0.1/32
acl SSL_ports port 443
acl Safe_ports port 80
acl Safe_ports port 443
acl CONNECT method CONNECT
acl SSL method CONNECT
never_direct allow SSL
http_access deny !Safe_ports
http_access allow localhost
http_access deny all
http_port 8080
cache_peer [上位プロキシサーバのアドレス] parent [ポート番号] 0 login=[ユーザID]:[パスワード]


これでsquidを起動し、先のmachine.configのプロキシサーバ設定にlocalhostを指定すればAADSync/MIMはsquidを、squidは本来のプロキシを参照する形でインターネットへ接続できるようになります。


3. NTLM認証が必要なプロキシサーバを使っている

最後が、Windows統合認証を使っている認証プロキシです。ISAとかですね。(古)
この場合も考え方は同じですが、squidがWindows統合認証に対応していないので、Cntlmというフリーウェアを使うことで対応している例があるようです。

 Cntlmダウンロードページ

細かい方法は今回は省略しますが、Cntlmの設定ファイル(iniファイル)に認証に使うユーザ名、ドメイン名、パスワードを記載してサービスを起動、上位プロキシサーバを参照させる、という方法をとります。

旧Forefront Identity Manager(FIM)、現Directory ServicesのMVPも在籍しているオーストラリアのkloudという会社のblogで紹介されているので、詳しくはそちらを見てください。

 kloudのblog



尚、上記で紹介したのはあくまで開発・テスト時の使用にとどめておいた方が良いと思います。障害ポイントを増やすだけですし、思わぬトラブルが発生した時に切り分けが難しくなる場合もあると思われますので。

[AD FS]OpenID Connectに対応した次期AD FSを試す

$
0
0
こんにちは、富士榮です。

先日3回目のTechnical Previewが公開された次期Windows ServerであるWindows Server 2016のActive Directory Federation Services(AD FS)はOpenID Connectに対応しています。
実は前回のTechnical Preview 2からOpenID Connectには対応しており、すでに色々と試してあったのですが、情報をまとめる暇がなくblogに投稿していなかったのですが、とりあえず新しいPreviewも出たので、軽く動作確認をした結果を公開したいと思います。

参考)
 [AD FS]Windows Server Technical Preview 2のAD FSファーストレビュー(管理GUI編)
  http://idmlab.eidentity.jp/2015/05/ad-fswindows-server-technical-preview.html


尚、インストール方法やASP.NETアプリケーションでの動作についてはVittorioがまとめているのでそちらも参考にしてみてください。
 OpenId Connect Web Sign On with ADFS in Windows Server 2016 TP3
  http://www.cloudidentity.com/blog/2015/08/21/OPENID-CONNECT-WEB-SIGN-ON-WITH-ADFS-IN-WINDOWS-SERVER-2016-TP3/


今回はとりあえずの動作確認ということで先日Azure Active Directory(Azure AD)のApp Model v2.0の紹介をした際に使ったphpアプリケーションをそのまま使います。

 [Azure AD]App Model v2.0を利用して組織内外共用のアプリケーションを開発する
  http://idmlab.eidentity.jp/2015/08/azure-adapp-model-v20.html


では、早速試してみます。


◆AD FSへアプリケーションを登録する

新しいAD FSではアプリケーション登録をGUIからできるようになっています。(Windows Server 2012 R2ではOAuthクライアントはPowerShellのコマンドレットからしか登録できませんでしたので、とっても便利です)

新しいメニューとしてApplication Groupsという項目が出来ているので、ここにアプリケーションを登録します。


任意の名前を付けてアプリケーションの種類を選択します。
今回はWebアプリケーションなので、「Server application or Website」を選択します。


client_idが生成されるのでメモしておきます。
また、redirect_uriにこれから作成するアプリケーションのURLを登録しておきます。


次のページでGenerate a shared secretにチェックを入れるとclient_secretが生成されるので、こちらの値もメモしておきます。


後はウィザードを先に進めればアプリケーションの登録は完了です。


◆アプリケーションにAD FSの情報を登録する

次はアプリケーション側にAD FSのエンドポイントの情報や先ほどのclient_id/client_secretを登録していきます。

まず、authorizeおよびtokenエンドポイントを確認するために、.well-known/openid-configurationにアクセスしてみます。
rootにあるべき.well-knownが/adfs以下にあるのは微妙ですが、以下のようなURLになっています。(Technical Preview 2の時にフィードバックしたんですが結局治らないんでしょうねぇ)

 https://adfs.example.com/adfs/.well-known/openid-configuration


{
"issuer":"https://adfs.example.com/adfs",
"authorization_endpoint":"https://adfs.example.com/adfs/oauth2/authorize/",
"token_endpoint":"https://adfs.example.com/adfs/oauth2/token/",
"jwks_uri":"https://adfs.example.com/adfs/discovery/keys",
"token_endpoint_auth_methods_supported":
[
"client_secret_post",
"client_secret_basic",
"private_key_jwt",
"windows_client_authentication"
],
"response_types_supported":
[
"code",
"id_token",
"code id_token",
"token id_token"
],
"response_modes_supported":
[
"query",
"fragment",
"form_post"
],
"grant_types_supported":
[
"authorization_code",
"refresh_token",
"client_credentials",
"urn:ietf:params:oauth:grant-type:jwt-bearer",
"implicit",
"password",
"srv_challenge"
],
"subject_types_supported":
[
"pairwise"
],
"scopes_supported":
[
"openid",
"profile",
"email",
"logon_cert",
"aza",
"vpn_cert",
"user_impersonation"
],
"id_token_signing_alg_values_supported":
[
"RS256"
],
"token_endpoint_auth_signing_alg_values_supported":
[
"RS256"
],
"access_token_issuer":"http://adfs.example.com/adfs/services/trust",
"claims_supported":
[
"aud",
"iss",
"iat",
"exp",
"auth_time",
"nonce",
"at_hash",
"c_hash",
"sub",
"upn",
"unique_name",
"pwd_url",
"pwd_exp"
],
"microsoft_multi_refresh_token":true,
"userinfo_endpoint":"https://adfs.example.com/adfs/userinfo"
}


これを見ると、
Authorizeエンドポイントは
 https://adfs.example.com/adfs/oauth2/authorize/
Tokenエンドポイントは
 https://adfs.example.com/adfs/oauth2/token/
であることがわかります。


この情報を前回作ったphpアプリケーションに設定します。


これで準備は完了です。


◆動作確認

早速、アプリケーションにアクセスしてみます。
すると、AD FSのログイン画面に飛ばされますので、ログインします。


ログインに成功するとid_tokenがアプリケーションにわたるので、前回と同じくClaimとValueが取得できます。




いかがでしょうか?
Discoveryの課題はあるものの、かなり手軽に自前のOpenID Provider(OP)を立てることが出来るようになったと思うので、今後はテスト用のOPとしても使えるかも知れませんね。

[告知]9月はイベント三昧。ID&IT Management ConferenceとJapan SharePoint Group

$
0
0
こんにちは、富士榮です。

9月にある2つのイベントに登壇することになったので、告知です。

1.ID&IT Management Conference 2015

世界3大アイデンティティ・イベントの一つである「ID&IT Management Conference」が9月18日に開催されます。今年で5回目になるんですね。

私もなんだかんだでほぼ毎年関わらせていただいているんですが、今年もパネル・セッションにパネリストとして参加させていただきます。

私は「エンタープライズIDの正しい捉え方、活用方法」というセッションでNTTデータの山田さん、NIIの中村先生、エクスジェンの江川さんと一緒にパネルディスカッションをする予定です。社内管理部門、学認、パッケージ、SIerという複数の立場からエンタープライズにおけるアイデンティティのあり方みたいな話ができると思います。

以下、セッション概要(イベントページより引用)です。
エンタープライズIDの正しい捉え方、活用方法 (パネルセッション)
認証基盤システム整備のための予算を確保するのに苦労する組織は、大変多いのではないでしょうか。
これは認証基盤整備が、セキュリティ確保や内部統制を主目的とし、また既に稼働中の基盤システムに対する再構築である場合が多く、利益増を主目的とする企業にとっては優先課題にはなりづらいからではないでしょうか。
IDを適切に運用、管理することで実現される理想像を描けているにも関わらず、我々には乗り越えないといけない様々な現実的な(技術論ではない)問題が多くあります。大規模認証基盤システム構築事例を元に、パネリストがそれぞれの立場から、様々な壁を乗り越える策を議論します。

以下のURLから申し込みが可能なので、お早めに!
 http://nosurrender.jp/idit2015/index.html



2.Japan SharePoint Group

2つ目はこれまでもたまにお手伝いさせていただいておりますMVP山崎さんが主宰しているJapan SharePoint Groupで9月12日に開催されます。こちらも20回目の開催になるんですね。

同日にSystem Center User Group Japanが品川で開催され、そちらがActive Directory特集ということなので、スピーカー不足ということで招集がかかりましたw

SharePointグループということでどちらかというと情報系アプリケーションの開発者の方や社内管理者の方が多く参加されると思いますので、テクニカルというよりもハイブリッドな認証/ID管理基盤の基礎的な話、プロジェクトの進め方、Windows 10のAzure AD Joinなんかの話が出来ればいいかな、と考えています。

こちらも以下のURLから申し込みが可能です。
 http://jpsps.com/event/20150912/

時間的に国井さんのセッションとダダ被りですね。。。。

[顔認証]ChromebookでWindows Helloっぽくログインする

$
0
0
こんにちは、富士榮です。

Windows 10の新機能であるWindows Helloでは顔や指紋などの生体情報を使ってOSへログインすることが出来ます。

 関連ポスト)
  [Windows10]ついにWindows Helloで顔認証!
  http://idmlab.eidentity.jp/2015/07/windows10windowshello.html


一方で他のOS/デバイスではどうなのかと言いますと、iOSにおけるTouchIDのあるAppleや、SAMSUNGやdocomoがFIDO Allianceに参加しているAndroidなどもメーカ実装として生体認証に対応してきています。

こうなってくると気になるのがGoolgeの出しているChromebookです。
(気になるのはごく一部の人だとは思いますが)

と、いうことで確認してみます。


◆準備
今回は以下の2つの機能を使ってChromebookへのログイン/ロック解除時の顔認証を目指します。
1.Smart Lock for Chromebook
2.Smart Lock for Androidの顔認識機能


1.Smart Lock for Chromebook
まずはChromebook側のSmart Lockです。
ChromebookにはSmart Lock for ChromebookというAndroidを使ったログイン/ロック解除機能が存在します。

 Android スマートフォンで Chromebook のロックを解除する
 https://support.google.com/chromebook/answer/6070209?hl=ja

簡単に言うとあらかじめBluetoothでペアリングされた、Smart Lockに対応した端末(Android 5.0以降)がChromebookの近く(Bluetoothの有効範囲)にあるとパスワード入力をスキップして端末へのログインやロック解除を行うことが出来る、という機能です。

この機能を使うには、BluetoothをONにした状態で、Chromebookの設定からSmart Lockの設定を行います。


設定時、同じくBluetoothをONにしたSmart Lock対応のAndroid端末が近くにあると、自動的にデバイスを検出します。




2.Smart Lock for Androidの顔認識機能
次にAndroid端末側です。

こちらも端末の設定のセキュリティ項目からSmart Lockの設定を行います。


今回は顔認証を行うので、「認識済みの顔」を選択し顔を登録します。




◆テストする
ここまでで、Chromebook⇒Android端末⇒顔という信頼関係が構築されました。

早速Chromebookを起動、もしくはロックします。
Android端末側のロックを解除していない状態だと、以下のようなメッセージが表示され、ロック解除を促されます。



Android端末側を起動すると、ロック画面の一番下に顔マークが表示され、信頼済みの顔を探します。



正常に顔を認識すると顔マークがロック解除マークに代わり、画面をスワイプするとパスワードを入れなくても端末ロックを解除できます。




Android端末のロックを解除すると連動してChromebookのロックも解除され、Chromebookのロック画面がロック解除状態になり、写真をクリックすれば同じくパスワードを入れなくても端末ロックを解除できます。




Windows 10のWindows Helloと異なり、PC(+カメラ)単体での顔認証とは行きませんが、Android端末側のロック解除方法によって認証のバリエーションが変えられるので、利用者の状況に合わせた柔軟かつ安全な運用を行うことができると思います。
※そのような意味で、生体認証付きの多要素認証ログインという方が的確なのかもしれません。

[告知]ID連携入門セミナーが大阪で開催されます

$
0
0
こんにちは、富士榮です。

今年はID&IT Managementカンファレンスも東京だけ、となかなかホットにならない大阪のID市場ですが、何とか活気が出てくるとうれしいなぁ、と思う今日この頃です。
(実際、大阪でID専任で仕事をしてる身としてはそれなりに忙しいんですけど・・・)

そんな中、2270万人の近畿地方のID愛好家のみなさんに朗報です。

「ID連携入門セミナ in 大阪」の開催が決定しました。

内容的には8月末に東京で開催された「OpenID Technight vol.13」+少しエンタープライズ要素を強めという感じです。

思い起こせば前回の大阪でのOpenID Technightから早4年。当時はフェデレーションって話をしても全然響かなかったのに、最近では普通に「フェデレーションを検討してます(キリッ」という話も増えてきて、ようやく大阪でもブームが来たか、と感無量だったりします。

というわけで、概要です。

開催日:2015年10月9日(金)
受付開始:15:00
講演開始:15:30(18:00終了予定)
場所:伊藤忠テクノソリューションズ株式会社 大阪支店

申し込みURL:
 http://www.openid.or.jp/news/2015/09/id109.html


今回、私は会社としての取り組みの話をする予定ですが、OpenID Foundation Japanのエバンジェリスト達やEnterprise Identity Working Groupの江川さんや八幡さんがID連携の基礎的な話やエンタープライズでの活用について話をしてくれますので、この機会に基本から勉強したい、という方はぜひご参加ください。
Viewing all 771 articles
Browse latest View live