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

[MIM]特権アクセス管理のデモ動画

$
0
0
今年リリースされる予定のForefront Identity Manager 2010R2(FIM)の後継バージョンである、Microsoft Identity Manager 2015(MIM)の一番の目玉機能はなんといっても「特権アクセス管理(Privileged Access Management/PAM)です。

この機能を使うとActive Directory上のユーザに一時的に特権を付与することが出来ます

このことにより、

  • 個人アカウントで管理をすることが出来るので、いつ、だれが、何をしたのか?について正確にロギング出来る
  • 必要な時に必要な権限を付与するので、不要な権限を与えることによる事故が起きにくい
  • ビルトインAdministratorなどの特権ユーザを管理者や運用者間で共有する必要がなくなるので、システム管理を安全に行うことが出来る
など様々なメリットを享受することが出来ます。

特に仮想化テクノロジを使ってグループ企業向けのプライベート・クラウドを提供しているような環境においては管理者アカウントの管理は非常に重要な意味合いを持つので、今後ますます厳重に管理をしていくべき対象となることでしょう。
これまでActive Directory上の特権アカウントの管理は非常に面倒だったので、今回のMIMのリリースは今後のシステム管理を行う上での重要な意味を持つものになると考えられます。


と、ここまで書きましたが文字ばかりだとイメージがつきにくいと思います。
そんな方に朗報です。

私と同じFIM MVPのEihab Isaac氏がPAMのデモ動画をYouTubeにアップロードしてくれています。
3分程度と非常に短いながらも非常にわかりやすいので是非ご覧ください。





[FIM/MIM]ビルトインの管理ポリシールールの拡張

$
0
0
今年夏にリリースされる予定のMicrosoft Identity Manager 2015(MIM)では特権アカウント管理に関する各種の機能拡張が行われています。

今回はMIM Serviceの管理ポリシールール(Management Policy Rule/MPR)が現行バージョンであるForefront Identity Manager 2010R2 SP1(FIM)とどのように変わったのかを見てみます。
※MIM 2015 CTP3とFIM 2010R2 SP1を比較していますので、リリースまでに変わる可能性があります。

以下のスクリプトで定義されているMPR一覧が取得できるので、変化点を見てみましょう。

Add-PSSnapin FIMAutomaion
$curObject = Export-FIMConfig -Uri http://localhost:5725/resourcemanagementservice -OnlyBaseResources -CustomConfig ("/ManagementPolicyRule")
foreach ($fimobject in $curObject)
{
$attributes = $fimobject.ResourceManagementObject.ResourceManagementAttributes
$displayName = $attributes | where {$_.AttributeName -eq 'DisplayName'}
write-host $displayName.Value
}

結果、以下の通りとなりました。
色を付けた部分のセルが新規追加になっているMPRです。
PAM(Privilege Access Management/特権アカウント管理)部分だけですね。
MPR一覧
Administration - Schema: Administrators can change selected attributes of non-system attribute type descriptionresources
Administration - Schema: Administrators can change selected attributes of non-system binding description resources
Administration - Schema: Administrators can change selected attributes of non-system schema related resources
Administration - Schema: Administrators can change selected attributes of schema related resources
Administration - Schema: Administrators can create attribute type description resources
Administration - Schema: Administrators can create binding description resources
Administration - Schema: Administrators can create resource type description resources
Administration - Schema: Administrators can delete non-system schema related resources
Administration: Administrators can control requests
Administration: Administrators can control synchronization configuration resources
Administration: Administrators can delete non-administrator users
Administration: Administrators can read all resources
Administration: Administrators can read and update Users
Administration: Administrators can update synchronization filter resources
Administration: Administrators control configuration related resources
Administration: Administrators control management policy rule resources
Administration: Administrators control set resources
Administration: Administrators control synchronization rule resources
Administration: Administrators control workflow definition resources
Administrators have full control over filter scope resources
Anonymous users can reset their password
Button viewable management: Members could read all attributes of the sets in all button viewable sets
Distribution list management: Owners can read attributes of group resources
Distribution list management: Owners can update and delete groups they own
Distribution list Management: Users can add or remove any members of groups subject to owner approval
Distribution list management: Users can add or remove any members of groups that don't require owner approval
Distribution List management: Users can create Static Distribution Groups
Distribution list management: Users can read selected attributes of group resources
General workflow: Filter attribute validation for administrator
General workflow: Filter attribute validation for non-administrators
General workflow: Registration initiation for authentication activity
General: Users can read non-administrative configuration resources
General: Users can read schema related resources
Group management workflow: Group information validation for dynamic groups
Group management workflow: Group information validation for static groups
Group management workflow: Owner approval on add member
Group management workflow: Validate requestor on add member to open group
Group management workflow: Validate requestor on remove member
Group management: Group administrators can create and delete group resources
Group management: Group administrators can read attributes of group resources
Group management: Group administrators can update group resources
[新規]PAM: Administrators control PAM Requests
[新規]PAM: Administrators control PAM Roles
[新規]PAM: User can read Pam Roles that he can request
[新規]PAM: User can see PAM requests that he created
[新規]PAM: Users can create a PAM Request
Password reset users can read password reset objects
Password Reset Users can update the lockout attributes of themselves
Reporting Administration: Administrators can control reporting binding resources.
Reporting Administration: Administrators can control reporting job resources.
Request management: Request approvers can read their approval resources
Request management: Request approvers can read their approval response resources
Request management: Request creators can cancel their requests
Request management: Request creators can read related approval response resources
Request management: Request creators can read their approval resources
Request management: Request creators can read their request resource
Request management: Request participants can read related approval resources
Request management: Request participants can read related approval response resources
Request management: Request participants can read their request resource
Security group management: Owners can read selected attributes of group resources
Security group management: Owners can update and delete groups they own
Security group management: Users can add or remove any member of groups subject to owner approval
Security Group management: Users can create Static Security Groups
Security group management: Users can read selected attributes of group resources
Security groups: Users can add and remove members to open groups
Synchronization: Synchronization account can delete and update expected rule entry resources
Synchronization: Synchronization account can read group resources it synchronizes
Synchronization: Synchronization account can read schema related resources
Synchronization: Synchronization account can read synchronization related resources
Synchronization: Synchronization account can read users it synchronizes
Synchronization: Synchronization account controls detected rule entry resources
Synchronization: Synchronization account controls group resources it synchronizes
Synchronization: Synchronization account controls synchronization configuration resources
Synchronization: Synchronization account controls users it synchronizes
Temporal policy workflow: Impending group resource expiry notification
User management: Users can read attributes of their own
User management: Users can read selected attributes of other users
Users can create registration objects for themselves
Users can modify registration objects for themselves

[GoogleApps/AD FS]iOS8.3でのアカウント管理の改善

$
0
0
手元のiPadのOSを順番に8.3にアップデートしている中で気が付いたのですがiOSのメール・カレンダーなのでアカウントにSSO設定がされたGoogle Appsアカウントの設定が出来るようになっています。
地味なアップデートですが、エンタープライズでGoogle Appsを利用しているユーザにとっては実は大きな意味を持つアップデータなので、これまでの課題と本アップデートによる今後のID運用の可能性について考えてみたいと思います。

◆これまでの課題
ネイティブアプリにアプリケーション・パスワードを使いたいのに、SSOユーザではアプリケーション・パスワードは使えない!

実際設定してしまえば動くのですが、SSOと2段階認証の同時設定はサポートされていません

https://support.google.com/a/answer/175197?hl=ja


このことにより、iOS標準のアプリケーションを始め、OutlookなどのネイティブアプリケーションをSSOが有効なユーザでは使うことが出来ず、スマホからでもブラウザを使うか、Google製のGMailアプリケーションを使う必要がありました

当然スマホからブラウザベースでサービスを使うとオフラインでのアクセスが出来なかったり、ユーザ・インターフェイスの面でかなりの苦痛があったりと実用性の面ではかなりの課題がありました。
(そのためにSecure Browserソリューションが流行っているんだと思います)

また、Google製のアプリケーションを使う場合、あくまでブラウザベースでのログイン(Cookieベース)なので、紛失した端末だけ強制ログアウトする、ということが出来ず、すべてのブラウザセッションを無効化することになってしまいます。(他の端末やPCのブラウザを含めすべてログオフされてしまう)


◆iOS8.3での改善
⇒標準メール・カレンダー等のアカウントへの外部IdPでの認証がサポートされ、認可がOAuthベースとなったことにより、SSOユーザでも標準アプリケーションが利用できる!

・認証)外部IdPのサポート
 ⇒Google側での2段階認証を使わなくてもIdP側で多要素認証を実装することでより柔軟な構成が可能

・認可)OAuthのサポート
 ⇒クライアント(アプリケーション)単位で権限委譲を取り消すことが可能なので、アプリケーション・パスワードと同じく、端末やアプリケーション単位で利用を不可能に出来る。(全セッションをクリアする必要がなくなる)


◆実際の動作と設定
早速試してみます。

まず、iOSの設定からGoogleアカウントを追加します。


Googleのログイン画面が出てくるので、SSOが有効なドメインのユーザ名のみを入力して[ログイン]をクリックします。


するとGoogle Appsに設定してある外部IdP(今回はAD FS)のログイン画面に遷移するのでIdPにログインします。
必要に応じて外部IdPに多要素認証を設定するとよりセキュアです。


認証に成功すると、iOSに対して認可をするかどうかの同意画面が表示されるので必要な権限を委譲します。



これでSSOユーザで標準アプリケーションが利用可能となります。



では、今度は端末を紛失したことを想定し、アプリケーションを利用できない様にしてみます。
方法としては、管理者による取り消しと利用者自身による取り消しの両方が可能ですが、今回は利用者自身で権限を取り消してみます。
ブラウザでサービスにログインした状態で画面右上のアカウント設定を開き、接続されたアプリとサービスのアカウント権限をクリックします。



すると、アクセス権を与えたiOSが出てきますので、[アクセス権を取り消す]をクリックします。



アプリケーションで送受信などの操作をするとエラーが表示され、再度認証をするように求められるためアプリケーションが利用できなくなります。


※ただし、すでにローカルにダウンロードしてしまったコンテンツについては引き続き閲覧可能なので、リモート・ワイプなどとの組み合わせは必要です(アプリケーション・パスワードの場合も同様)


これまではGoogle製のアプリケーションを別途導入したり、サードパーティのソリューションを使う必要があったことを考えると端末管理の観点からもかなり有効な解決策となっていると思います。

課題は各端末をiOS8.3にアップデートするところになるとは思いますが・・・

[Google]4/20を迎えてAPIはどうなった?

$
0
0
GoogleのIdentityに関与している人なら少なからず気にしていた2015年4月20日を遂に迎えたわけですが、実際移行し忘れた人たちがどうなったのか、、、を確認してみたいと思います。

OpenID 2.0のサポート終了関連
 ⇒ Azure Access Control Services 2.0(ACS)

 関連ポスト)
  GoogleのOpenID 2.0サポート終了による影響いろいろ(Azure ACS編)
  http://idmlab.eidentity.jp/2015/03/googleopenid-20azure-acs.html

ClientLoginおよびProvisioning APIのサポート終了関連
 ⇒ Forefront Identity Manager(FIM)用のGoogle Apps管理エージェント(旧版)

 関連ポスト)
  [FIM]汎用REST管理エージェントをリリースしました
  http://idmlab.eidentity.jp/2015/03/fimrest.html


結論、4/21現在両方ともまだ使えました(笑)
(Azure ACSについては元々2015/6/1までは使える、と言っているので使えて当然ですが)


◆OpenID 2.0

ACSを使うサービスでログオンするとOpenID 2.0を使って認証しているのがわかります。


◆ClientLoginおよびProvisioning API

ClientLoginでGoogle Appsの管理者IDとパスワードを投げ込んでGoogle Auth Tokenを取得し、Provisoning APIへクエリを投げてユーザ一覧の取得が出来ています。





まぁ、いつ使えなくなってもおかしくないので早めに移行した方が良いですね。
(旧版のGoogle Apps管理エージェントのサポートがあるので、使えなくなったらどんな動きをするのか早く把握したい・・・)

[MIM]新しいPublic Previewがリリース、MIM2016へ

$
0
0
新しいMicrosoft Identity Manager(MIM)のPreviewがリリースされました。
都合CTP4になりますが、公式Blogによるとベータ・クォリティとの記述があるので、ほぼ完成の域に近づいてきた、ということだと思います。

Active Directory Team Blog
 Microsoft Identity Manager Public Preview Updated
 http://blogs.technet.com/b/ad/archive/2015/04/21/microsoft-identity-manager-public-preview-updated.aspx

更新されたポイントはやはり特権アクセス管理(Privilege Access Manage/PAM)回りが中心ですが、Azure ADと連携したレポーティング機能についても更新されています。
(こちらはPrivate Preview)
また、今回のリリースからForefront Identity Manager 2010R2(FIM)からのインプレース・アップデートが出来るようになっているようなので、その点も注目です。

  1. Manual approval of elevation requests
  2. The ability to require a Multi-Factor Authentication challenge as part of an elevation request
  3. Improved security monitoring of your privileged forest
  4. Azure AD based reporting capabilities in the cloud


個人的には2番目の特権アクセスを多要素認証で取得するあたりがとても良い機能だと思います。


Connectサイトに登録すれば誰でもダウンロードできるので、FIM使いの方は是非試してみましょう。

[Office365]Officeクライアントで多要素認証(Outlook編)

$
0
0
昨年末に発表されたOffice2013 Windowsクライアント(Outlookなど)の多要素認証対応が2015年3月にPublic Previewになった、という話を書きましたが、ようやく試してみましたので簡単に紹介します。

関連ポスト)
・Office2013 Windowsクライアントが多要素認証とSAML IdPサポート
 http://idmlab.eidentity.jp/2014/11/office2013-windowssaml-idp.html
・[Office Preview]Outlook等の多要素認証サポート
 http://idmlab.eidentity.jp/2015/03/office-previewoutlook.html


簡単に言いますとOfficeクライアントがADAL(Active Directory Authentication Library)に対応した、というだけなのですが、Office Teamの公式Blogなどでは「Office Modern Authentication」なんて呼んでいます。

◆準備
以下の2点を事前に実施する必要があります。

①Office365のテナントに対してModern Authenticationを有効にしてもらう
 ⇒現在実施中のPublic Previewプログラムに参加する必要があります。参加するにはMicrosoft Connectサイトへの登録とアンケートへの回答が必要です。

②OfficeクライアントをインストールするPCのレジストリを変更する
 ⇒以下のキーを追加する必要があります。

レジストリ・キータイプ
HKCU\SOFTWARE\Microsoft\Office\15.0\Common\Identity\EnableADALREG_DWORD1
HKCU\SOFTWARE\Microsoft\Office\15.0\Common\Identity\VersionREG_DWORD1
HKCU\SOFTWARE\Microsoft\Office\15.0\Common\Debug\TCOTraceREG_DWORD3

  詳細は以下のURLに記載されています。
  https://support.office.com/en-us/article/Enable-Modern-Authentication-for-Office-2013-on-Windows-devices-7dc1c01a-090f-4971-9677-f1b192d6c910?ui=en-US&rs=en-US&ad=US


※詳細は公式blogをみてください。
 http://blogs.office.com/2015/03/23/office-2013-modern-authentication-public-preview-announced/


◆Outlookにアカウントを追加する
準備が出来たら早速試してみます。
今回は多要素認証を有効、かつAD FSとID連携しているアカウントを使ってExchange Onlineに接続してみます。

①Outlookを起動し、アカウント情報を入力する。
 この際、パスワードを入れずに[次へ]をクリックします。



②AD FSのログイン画面が表示されるのでログインする。


③多要素認証を行う。
 今回はOffice365側の多要素認証を有効にしているアカウントなので、Microsoft Azure Authenticatorアプリケーションで追加認証をします。


④アカウント設定が完了する
 これで設定は完了です。Outlookを再起動して使い始めましょう。



通常の使用についてはこれで問題ないと思うのですが、セキュリティ面からはOutlookを起動する都度認証をしたいところです。
ところが、アカウントの設定⇒セキュリティ設定で[ログオン情報を毎回入力する]を設定しようとしたのですが、グレーアウトされており設定できませんでした。


今のところ端末を紛失したら困りますね。。。発行したトークンの無効化をする様な画面も見当たらないですし。。
このあたりは少し改善が必要なポイントかも知れません。
(公式blogのコメント欄で同じ質問している人がいますが回答はないみたいです)

[Azure/SAML]Azure Webアプリにお手軽テスト用SAML SPをデプロイする

$
0
0
Azure Active Directory(AzureAD)やActive Directory Federation Service(AD FS)を始めとしたSAMLに対応したIdentity Provider(IdP)を構築すると、どうしても必要になるのがテストに使うアプリケーション(Service Provider/SP)です。

個人的には設定が超お手軽なGoogle Appsをテスト用SPとして使ったりすることが多いのですが、もう少し簡単なアプリケーションが欲しいなぁ、、と思うことも多くオンプレの環境にはPHPアプリケーション用のPHPライブラリであるSimpleSAMLphpをセットアップしてあったりします。
※WIFとかADALがちゃんとSAMLを喋れればいいんですが、ws-federation/OpenID Connectなんで実はSAML SPってぽっかり穴が空いています。

今回はもう少しお手軽にいつでも試せる環境を、ということでAzure WebアプリにSimpleSAMLphpをデプロイしてみます。

尚、考えることはみんな一緒で日本マイクロソフトの松崎さんも同じようなことを考えていらっしゃったようです。
http://blogs.msdn.com/b/tsmatsuz/archive/2014/01/30/azure-ad-and-php-application-sso-federation-using-simplesamlphp.aspx

松崎さんがblogを書かれた段階ではAzure WebsiteにはうまくSimpleSAMLphpが導入できなかった様なのですが、現在は割と素直に導入できました。


では、さっそくやってみます。

◆Azure Webアプリ(WebSite)の作成

ギャラリーから空のサイト(PHP)を選択し、Webサイトを作成します。



◆SimpleSAMLphpのダウンロードと展開

以下のURLから最新のSimpleSAMLphpをダウンロードし、ローカルの任意のフォルダにtar.gzを展開します。

 SimpleSAMLphp
 https://simplesamlphp.org/


◆Azure Webアプリへのデプロイ

Azureへのデプロイ方法はFTPなど色々とありますが、今回は先ほどモジュールを展開でぃたフォルダをGitのローカルレポジトリに設定してデプロイしました。

まずは、作成したWebアプリの「ソース管理の統合」メニューの「ソースコードの位置」で「ローカルGitレポジトリ」を選択します。



そして、ローカルのGitレポジトリを設定します。
※Gitクライアントなどのセットアップ方法は省略します。

Git Bashでモジュールを展開したフォルダへ移動し、以下を打ち込みます。
git init
git add .
git commit -m "initial commit"
git clone https://naohiro@samlsp1.scm.azurewebsites.net:443/samlsp1.git
git remote add azure https://naohiro@samlsp1.scm.azurewebsites.net:443/samlsp1.git
git push azure master


これでモジュールがAzure上にデプロイされました。


◆仮想ディレクトリの設定

デプロイしたモジュールへ外からアクセスするための仮想ディレクトリを設定します。
SimpleSAMLphpでは/simplesamlという仮想ディレクトリに[展開先]/simplesamlphp/wwwをマッピングする必要がありますので、以下のような仮想ディレクトリを設定します。


◆SimpleSAMLphpへのSP登録

テスト用なのでデフォルトで登録されているSPを使います。
SP設定は[展開先]/config/authsources.phpファイルに存在するので、ローカルで対象ファイルを編集します。
ファイルの中に'default-sp'というブロックがあるので、その中を修正します。

変更点は、以下の3点です。

  • entityID : 何でも構わないんですが、一般にSPのURLを設定するので、「http://samlsp1.azurewebsites.net」の様に設定しました。
  • idp:ここは設定しなくても良いのですが、デフォルトで使うIdPとしてPingIdentityのPingOneを使いたかったので、PingOneの自分のテナントのURLを指定します。
  • NameIDPolicy:SimpleSAMLphpは初期値でtransientが設定されるので、何が来ても良いようにNULLにしておきます。


こんな感じで設定しました。
'default-sp' => array(
'saml:SP',

// The entity ID of this SP.
// Can be NULL/unset, in which case an entity ID is generated based on the metadata URL.
'entityID' => 'http://samlsp1.azurewebsites.net',

// The entity ID of the IdP this should SP should contact.
// Can be NULL/unset, in which case the user will be shown a list of available IdPs.
'idp' => 'https://pingone.com/idp/xxxxxx',

// nameid
'NameIDPolicy' => NULL,



ローカルでauthsources.phpを更新したので、GitでAzure上へデプロイしておきます。
git add --all
git commit -m "sp config"
git push azure master


この段階で念のためAzure Webアプリの再起動をしておきましょう。


◆IdP(PingOne)へのSP登録

今回はテスト用IdPとしてPingOneを指定しました。

まずは先にSimpleSAMLphpの管理ページにアクセスし、[連携]タブより登録したSPのメタデータを取得します。

http://samlsp1.azurewebsites.net/simplesaml/
という形でsamplesamlという名前で作成した仮想ディレクトリへアクセスするとSimpleSAMLphpの管理画面が開きますので、[連携]タブよりメタデータを表示を選択するとメタデータのURLが表示されるので、このURLをメモしておきます。後でこれをPingOneに設定するので。




次にPingOneの管理コンソールにアクセスします。

 PingOne管理コンソール
 https://admin.pingone.com/

この[Application]タブを開くとアプリケーションの追加が出来ます。
[Add Application]より[New SAML Application]を選択しアプリケーション名、説明などを設定して行きます。
重要なのは、先のSPメタデータを[Upload Metadata]に指定することと、SAML Metadataの項目でIdP側のメタデータをダウンロードしておくことです。





またSAML Assertionに含める属性とPingOneのレポジトリ内の属性とのマッピングを設定することも可能です。



これでIdPの設定は終わりです。



◆SPへのIdP登録

再度SimpleSAMLphpの管理画面を開き、[連携]メニューより[XMLをsimpleSAMLphpメタデータに変換]を選択し、先ほどダウンロードしたPingOneのIdPメタデータをSimpleSAMLphp用の設定ファイルへ変換します。


メタデータパーサにダウンロードしたIdPメタデータを張り付けて[パース]をクリックするとSimpleSAMLphpに設定する内容が表示されます。


ここで出来上がった設定をローカルの[展開先]/metadata/saml20-idp-remote.phpのphpタグの間に貼り付け、保存して先ほどと同じようにgit pushし、Azure Webアプリを再起動します。


◆動作テスト

これで設定は完了ですが、すこしわかりやすいアプリケーションを作ってSAML Assertionの中身を見えるようにしてみます。
基本は松崎さんのblogに上がっているphpアプリケーションでモジュールのパスを変えただけです。

<?php
require_once("simplesamlphp/lib/_autoload.php");
$as = new SimpleSAML_Auth_Simple('default-sp');
$as->requireAuth();
$attributes = $as->getAttributes();
?>
<div style="font-weight: bold;">Test SAML SP</div>
<table border="1">
<?php foreach ($attributes as $key => $value): ?>
<tr>
<td><?=$key;?></td>
<td><?=$value[0];?></td>
</tr>
<?php endforeach;?>
</table>


これをローカルの[展開先]ディレクトリ直下にindex.phpとして配置し、git pushします。


これで、アプリケーションも含めすべての準備が整いました。
早速アプリケーションにアクセスすると、PingOneのログイン画面が表示されるのでログインすると、アプリケーションが表示されます。



多少手間ではありますが、これで無償で常時稼働出来るSAML SPが完成しました。
設定もgitで管理できるので新しいIdPを作った際に少し修正して、戻して、、といったことが簡単に出来るようになります。

[FIM]最新HotFixでPCNSがようやくWindows Server 2012 R2に対応

$
0
0
ようやくPCNS(Password Change Notification Service)がWindows Server 2012 R2のドメインコントローラに対応しました。

これでPCNSがネックでドメインコントローラをWindows Server 2012 R2へアップデート出来なかった人たちも一安心です。(どれだけいるかは・・・ですが)

ちなみにPCNSは、Active Directoryドメイン上の全ドメインコントローラ上にインストールするモジュールで、各PCや管理者によるActive Directoryのパスワード変更をフックしてFIMに通知・連携するためのモジュールです。これを使うとctrl+alt+delなどで変更したパスワードをFIMと連携している他のアプリケーションへも連携することが出来ます。

今回のForefront Identity Manager(FIM)のHotFixでは実際にPCNSのモジュールが更新されているわけではなく、FIMに同梱されているActive Directory Management Agentが更新されているところを見ると、これまでもWindows Server 2012 R2からのパスワード変更通知は受け取れていたようですが、(おそらくパスワード自体の)ハンドリングが上手く出来ていなかった、というあたりを改修したように思われます。
(パッチのリリースノートを見ても、PCNSからの通知をFIM Synchronization Serviceが受け取った際のLsaLookupNames2 APIをコールする際のドメイン・フォーマットに起因する不具合の修正が含まれていますので、このあたりがWindows Server 2012 R2対応した部分だと思われます)

他にもFIM Sync/FIM CM周りでも修正は入っているようなので、現在FIM 2010R2 SP1を運用している方は早めの適用が推奨されています。


◆前提/注意事項
と、ここまで書きましたが、今回のHotFix適用にあたり、以下の注意事項があります。

  1. Windows Server 2012 R2に対応したのはあくまで「PCNS」
  • ⇒FIMを導入するサーバはWindows Server 2012無印までしか対応していません。MIMを待ちましょう。
  • カスタムの管理エージェントを導入している人は互換性に関する不具合が出ることがあります。
    • 管理エージェントをコンパイルした時のMicrosoft.MetadirectoryServicesEx.dllのバージョンによってはno-start-maエラーが出る場合があるので、その場合は.configファイルにバージョン互換に関する記載を追記しましょう。詳細はHotFixのダウンロードページに記載されています。
    • ちなみに私の環境では拙作Generic REST API Management Agentは何もしなくても問題なく動きました。


    - HotFixダウンロードページ
     https://support.microsoft.com/en-us/kb/3048056
    - HotFix適用によるビルド・バージョン
     FIM : 4.1.3634.0
     BHOLD : 5.0.2959.0

    [AD FS]Windows Server Technical Preview 2のAD FSファーストレビュー(管理GUI編)

    $
    0
    0
    先日第2弾が公開された次期Windows ServerのTechnical PreviewのAD FSがどう変わったのか確認してみたいと思います。

    第一印象ですが、かなり便利・かつ高機能になっている印象です。

    私なりのポイントですが、以下の5点だと思います。(まだ触り切れていないのでどこまで使えるかは微妙ですが)

    1. PowerShellでしか出来なかった操作がかなりの範囲でGUIで操作できるようになった(OAuthのクライアント登録とかScope登録とか)
    2. OpenID Connect Discoveryに対応した(限定的ではありますが)
    3. Microsoft Azure MFAが最初から組み込まれた
    4. VPNアクセス用の証明機関としての機能が付いた(?)
    5. Web Application Proxyの管理GUIが統合された(?)

    ※?マークはそれっぽいメニューが存在するだけなので、どう動くのかはまだわかっていません。

    また、結局Blogには投稿できませんでしたが、前回のPreviewから

    • OpenID Connectへの対応
    • OAuth2.0への対応の改善(Implicit、Client Credentialへの対応)

    がなされています。
    (検証結果をまとめている時間がなかっただけなので、まとめたら改めて公開したいと思います)


    ということで今回は管理ツール周りを見ていきたいと思います。

    ◆メニュー構成
    管理GUIの左ペインを見ると以下の5項目でメニューが構成されています。

    • Service
    • Access Control Policies
    • Relying Party Trusts
    • Claims Provider Trusts
    • Clients



    Windows Server 2012R2では

    • サービス
    • 信頼関係
    • 認証ポリシー

    の3項目でした。
    サービスはそのまま、以前は信頼関係メニューの中にあったRelying Party Trust(証明書利用者信頼)とClaims Provider Trusts(要求プロバイダー信頼)がトップレベルに昇格、Access Control PoliciesとClientsが新規に追加され、認証ポリシーが消えた、という感じです。

    では、それぞれ順番に見ていきます。


    ◆Serviceメニュー
    以下の9項目のサブメニューで構成されています。

    • Attribute Store
    • Authentication Methods
    • Certificate Authority
    • Certificates
    • Claim Descriptions
    • Device Registration
    • Endpoints
    • Scope Descriptions
    • Web Application Proxy



    それぞれ簡単に解説しておきます。
  • Attribute Store
  • 以前は信頼関係の配下にあったものが移動されています
  • Authentication Methods
  • 以前はトップメニューにあった認証ポリシーがServiceの配下に来ています
  • Certificate Authority 
  • 新規に追加された項目です。VPNアクセス用の証明書の発行をする機能のようです。




    • Certificates
      • 変化なしです。
    • Claim Descriptions
      • 変化なしです。
    • Device Registration
      • 新規に追加されています。Windows Server 2012R2ではPowerShellで設定していたものがGUIで出来るようになっています。(前回のPreviewより)
    • Endpoints
      • 変化なしです。
    • Scope Descriptions
      • 新規に追加されています。OAuth/OpenID ConnectのScope設定が出来ます。これも以前はPowerShellで設定していたものがGUIで出来るようになっています。

    • Web Application Proxy
      • 新規に追加されています。WAPを構成した場合にここで管理できるようになるのかも知れません。




    ◆Access Control Policiesメニュー
    新規に追加されたメニューです。
    これまでClaimルールで頑張って書いていたような認可ポリシーがある程度テンプレートとして用意されています。



    ◆Relying Party Trustsメニュー
    あらかじめ以下のRelying Partyが定義されています。

    • VPN Server(無効化状態)
    • UserInfo




    Windows Server 2012R2ではここにDevice Registration Serviceが登録されていましたが、初期状態では存在しません。
    また、ここにはSAMLやws-federationのRelying Partyだけではなく、OAuthの保護リソースも登録されるため、OpenID ConnectのUserInfoがここに最初から登録されています。


    ◆Claims Provider Trustsメニュー
    ここは何も変わりません。初期値ではActive Directoryだけが登録されています。



    ◆Clientsメニュー
    新しく出来た項目です。
    ここで、OAuthのクライアント管理を行うことが出来ます。
    ちなみに、Windows Server 2012R2ではPublic Clientしか登録することが出来ませんでしたが、次期バージョンからはConfidentialも登録できるようになっています。(つまり、client_secretの発行が出来、Client Credentialなどのフローで使えます)



    初回なので、今回はここまでにしておきますが、次回以降でもう少し細かい部分や動きを確認していきたいと思います。

    【参考】
     Windows Server Technical Preview 2のISOファイルやVHDファイルは以下よりダウンロードできます。
      https://technet.microsoft.com/ja-jp/evalcenter/dn781243.aspx
     ※もしくはMicrosoft Azure上で仮想マシンとしての提供されていますので、そちらを使うことも可能です。
      今回は手元にISOファイルから新規インストールしました。

     尚、最初に公開されたバージョンのTechnical PreviewのAD FSについては以下のポストで紹介しています。
     [AD FS]Windows Server Technical Previewで追加された機能~PowerShell編
      http://idmlab.eidentity.jp/2015/03/ad-fswindows-server-technical.html
     [AD FS] Windows Server Technical PreviewのAD FSを試す
      http://idmlab.eidentity.jp/2014/10/ad-fs-windows-server-technical.html

    [Windows10]デバイス&サービス間のシングルサインオンの仕組み

    $
    0
    0
    ※ご注意
    ・現在公開されている情報+Fiddler等でWindows10の動きを解析した結果からの推測です。
     (そのうちMSDNあたりに確かな情報も公開されると思います)
    ・Windows10 Insider Preview(Build 10074)をベースに確認しています。
    ・細かい話は今月末(5/27)に開催されるidcon(別名fidcon)で話をする予定です。



    今回はこれまで紹介してきたWindows10のクラウド・ドメイン参加(Cloud Domain Join/CDJ)によるPCログオンとOffice365等のアプリケーションの間のシングルサインオンの動作の仕組みについて考えてみます。

    その前におさらいです。

    ◆CDJとは
    簡単にいうと、Windows10のデバイス(PC)へのログオンにAzure Active Directory(AzureAD)を使う、つまりオンプレミスのActive Directoryへのドメイン参加ではなく、クラウド上のAzureADへドメイン参加する機能のことです。

    <関連ポスト>
     [Windows10/AAD]クラウド・ドメイン参加を試す
     http://idmlab.eidentity.jp/2015/02/windows10aad.html

     [Windows10/AAD]OOBEでクラウド・ドメイン参加
     http://idmlab.eidentity.jp/2015/03/windows10aadoobe.html


    ◆CDJを使ったTrue SSOとは
    これまでWebアプリケーション間のSSOはAD FSやAzureADなどSAMLやws-federationの実装により割と容易に実現出来ました。また、社内のPCの様にActive Directoryドメインに参加している環境においてはAD FSへの統合Windows認証をすることによりPCログオンとWebアプリケーションとの間でのSSOを実現してきました。
    しかし、あくまで統合Windows認証に依存する仕組みのため、社外からのアクセスなどドメイン・ネットワークの境界を超えると途端にSSO出来なくなる、という非常に限定的な仕組みでもありました。


    しかし、CDJを使いPCログオンをAzureADで行うことによりドメイン・ネットワークの境界の外にある社外PCについてもPCログオンとWebアプリケーションのSSOを実現することが出来るようになりました。


    <関連ポスト>
     [Windows10/AAD]Technical Preview Build 10041のCDJでOffice365とのSSOを実現
     http://idmlab.eidentity.jp/2015/03/windows10aadtechnical-preview-build.html

     ※ちなみにBuild 10074ではOffice365とのSSOは上手く動かず、代わりにAzureの新管理ポータル(https://portal.azure.com/)へSSO出来るようになっています。



    さて、本題です。
    では、CDJを使いWindows10のPCではどのようにデバイスとアプリケーションの間のSSOを実現しているのでしょうか?

    CDJではざっくり言うと以下の処理が実行されます。
    ①AzureADへのデバイス登録
     ⇒秘密鍵のダウンロード、TPMへの保存
    ②ユーザ認証
     ⇒秘密鍵を使ってAzureADからプライマリ・リフレッシュ・トークン(PRT)の取得
    ③アプリケーションへのアクセス
     ⇒AzureADでPRTをアクセス・トークンへ交換し、アプリケーションへ提示

    PINや顔認証でPCにログインできるようになるのは、CDJでAzureADの信頼済みデバイスとして登録された後、TPM上にストアされた秘密鍵にアクセスすることが出来ることでユーザを認証することが可能なためです。
    (この秘密鍵にアクセスするためのパスフレーズとしてPINやバイオメトリクスを使っているのが噂のWindows Helloです)


    このあたりは、先日のJapan SharePoint Groupでデモを交えつつ話をした内容です。
    当日のスライドはこちら。後半でNext Generation Credentials/NGC(現在はPassportって言ってるやつです)のフローを解説しています。



    特にこの辺のスライドですね。


    で、実際SSOを実現するには、この中で出てくるPRTをアプリケーション向けのアクセス・トークンに交換する必要がありますが、この部分を担当しているコンポーネントがWindows10から導入された「Web Account Manager」および「AAD Token Broker Plugin」です。

    Web Account Managerは現在.NETやJava Script向けに提供されているActive Directory Authentication Library(ADAL)の後継(?)となるコンポーネントで、バックエンドで認証やアクセストークンの取得などの処理を行うものです。ただ、ADALが各アプリケーションに組み込むライブラリとして提供されていたのに対して、Web Account ManagerはWindows10/Windows Phone10に組み込まれた独立したモジュールとなっています。

    OpenID ConnectのRPとして実装されたWebアプリケーションは、AzureAD上に登録する必要があり、登録の際のredirect_uriに「ms-appx-web://Microsoft.AAD.BrokerPlugIn/[アプリケーションのsid]」を指定することでWeb Account Managerを呼び出すことが出来ます。(ネイティブアプリケーションからはRequestTokenAsyncなどのAPI経由で呼び出します)

    Build 2015のセッションより


    単純にWeb Account Managerを使うだけだとAzureADで個別に認証をしてアクセス・トークンを受け取る必要がありますが、先にCDJで取得したPRTがあると、AAD Token Broker PluginがPRTをAzureADへ渡してアクセス・トークンを取得するのだと思われます。

    これで、PCへのログオンとWebアプリケーションへのログオンのSSOの出来上がりとなります。


    ちなみにAzureAD上にリソースとして登録していないWebサイトからの認証要求が来ると、AADのイベントログにID1098、1097が記録されるので、PRTの交換に失敗していることがわかります。




    一番上にも書きましたが、5/27のidconでもう少し深く仕組みの紹介をしたいと思います。
    ※CDJの各フェーズで実際にどのような通信が発生しているのかをfiddlerで可能な限り取得した結果などもお見せできれば、、と思います。仕組み上、ログイン中に発生している通信も多いので、全部がトレースできる訳ではありませんが。。。

    [Build 2015]アイデンティティ関連セッションリスト

    $
    0
    0
    4月~6月にかけて海外では各種イベントが続々と開催され、アイデンティティに関しても新しい情報が出てきたりするので目が離せません。

    ・Microsoft
     Build 2015
     http://www.buildwindows.com/

     Ignite 2015
     http://ignite.microsoft.com/

    ・Kuppinger Cole
     Europian Identity & Cloud Conference 2015(EIC 2015)
     https://www.id-conf.com/

    ・Ping Identity
     Cloud Identity Summit 2015
     http://www.cloudidentitysummit.com/


    今回は先日サンフランシスコで開催されたMicrosoftのBuild 2015よりアイデンティティ関連のセッションをピックアップしました。
    スライドとビデオが公開されているので、Azure Active Directory(AzureAD)、Office365 API、Windows 10のPassport/Windows Hello関連に興味のある方は必見です。

    ◆AzureAD連携アプリケーション開発関連
    Azure Active Directory: Identity Management as a Service for Modern Applications
    http://channel9.msdn.com/Events/Build/2015/2-738

    Cloud Authentication Troubleshooting and Recipes for Developers
    http://channel9.msdn.com/Events/Build/2015/2-740

    Develop Modern Web Applications with Azure Active Directory
    http://channel9.msdn.com/Events/Build/2015/2-753

    Develop Modern Native Applications with Azure Active Directory
    http://channel9.msdn.com/Events/Build/2015/2-769


    ◆AzureADとOffice365 API関連
    Get Your Hands Dirty with the Office 365 APIs, Authentication and SDKs
    http://channel9.msdn.com/Events/Build/2015/4-630


    ◆Passport/Windows Hello関連
    Single Sign-On with Secure Authentication
    http://channel9.msdn.com/Events/Build/2015/2-709

    Managing Mobile Devices and Applications in an Enterprise
    http://channel9.msdn.com/Events/Build/2015/3-654

    Microsoft Passport and Windows Hello: Moving Beyond Passwords and Credential Theft
    http://channel9.msdn.com/Events/Build/2015/2-639

    Building Universal Windows Apps with Office 365 APIs
    http://channel9.msdn.com/Events/Build/2015/3-767

    App-to-App Communication: Building a Web of Apps
    http://channel9.msdn.com/Events/Build/2015/3-765



    尚、セッションデータを一括ダウンロードするスクリプトが公開されているので、上手く活用をして効率的にマテリアルをダウンロードすると良いでしょう。
    https://gallery.technet.microsoft.com/All-Videos-and-Slides-from-64a86489


    ちなみにこのスクリプト(というよりもChannel9のRSSフィード)には不具合があり、一部修正が必要です。

    以下のステップで修正をします。
    1.RSSフィードを直接ダウンロードする
      以下のURLをブラウザで直接開いて表示された内容を保存します。
      http://channel9.msdn.com/Events/Build/2015/RSS/slides


    2.ダウンロードしたフィードを修正する
      1287行目のitunes:summaryの行に不具合があるので、この行を丸ごと消してしまいましょう。


    3.スクリプトがローカルにダウンロード・修正したRSSフィードを読み込むように修正する
      ダウンロードしたスクリプトがインターネット上のRSSフィードではなく、上記2で修正したフィードを読み込むように以下の様に修正します。
      (修正前)


      (修正後)


    後は保存してPowerShellを実行すればごっそりファイルのダウンロードが出来ます。
    ※スライドだけでも1.7GBくらいあるので空き容量に注意が必要です。

    [FIM/MIM]CTP4へのインプレースアップデート(Sync Engine編)

    $
    0
    0
    4月下旬にconnectサイトにリリースされたMicrosoft Identity Manager 2016 CTP4ですが、今回のバージョンからインプレース・アップデートに対応しています。
    ※現状FIM CMについてはバグがありアップデート出来ないようですが。

    参考)
     [MIM]新しいPublic Previewがリリース、MIM2016へ
     http://idmlab.eidentity.jp/2015/04/mimpublic-previewmim2016.html

    今回はSynchronization Serviceのインプレース・アップデートを行ってみます。

    ◆結果
    今のところ何の問題もなく、HotFixを適用するのと同じ程度の手間でアップデートが出来ました。
    (特にSyncエンジンは殆ど何も変わっていないので、当たり前ですが)
    また、ECMA2で作成したGeneric REST MAについても簡単な確認をした限りでは問題なく使えていそうです。


    ◆アップデート手順
    まず、アップデート前のバージョンを確認しておきます。


    2つ前のHotFixが適用されたForefront Identity Manager 2010 R2 SP1(FIM2010R2)ですね。

    早速connectからダウンロードしたCTP4を解凍し、Synchronization Serivceフォルダ以下のsetup.exeを実行します。



    ちゃんとUpdateとして認識してくれているようです。



    まだ、バージョン番号がMicrosoft Identity Manager 2015のままですね。



    アップデートなので基本的な設定は引き継いでくれます。




    色々と注意事項がでますがセットアップを継続です。




    セットアップはすぐに終ります。
    特に問題なくセットアップフェーズは進みました。


    ◆確認
    早速Synchronization Managerを起動します。


    起動時のロゴがMicrosoft Identity Managerになっていますね。

    しかし、バージョン情報を見ると相変わらずFIMのままです。
    ビルド番号は流石に4.1.1790.0と新しくなっていますが。

    この状態で簡単に管理エージェントを動かしてみましたが、特に問題なく動きました。


    ここまでです。Synchronization Serviceについては何の問題もありませんでした。

    次回はFIM Servive/Portalのアップデートをやってみまたいと思います。
    (こちらはそれなりに変な動きをしてくれています。流石にモジュール構成の変更が多いので難しい部分だったのだと思います)




    [FIDO/Windows10]idcon vol.20(別名fidcon)が開催されました

    $
    0
    0
    先日のポストで紹介させていただいた通り、Identity Conference / idcon の記念すべき20回目が開催され、私も Windows 10 の FIDO(First IDentity Online)実装である Microsoft Passport および Windows Hello について話をさせていただきました。

    参考)
     Identity Conferenceのページ
     https://idcon.doorkeeper.jp/events/23320

     FIDO Allianceのページ
     https://fidoalliance.org/


    ◆当日の流れと様子
    詳しくは @novさんが togetterにまとめてくれていますが、当日は以下の順番で講演が行われました。

    1. Token Binding と FIDO / レピダム 前田さん(@mad_p




    OAuth の Token や Cookie などの Bearer Token はその名の通り、Bearer(持って来た人が使えてしまう)なトークンなので、認証等のセキュリティが求められるトランザクションには不向きです。Token Binding は Token を行使できる相手の ID と Token を関連付けて管理していこう、という取組みです。今回前田さんに紹介いただいたのは tls-unique を使って TLS セッションと Token を関連付け、TLS セッションが生きている間は Token を有効にする、という仕組みでした。
    また、この Token Binding を安全にやり取りする仕組みとして、id_token 内に入れて署名する方法や、今回のテーマでもある FIDO を使って署名する方法が紹介されました。


    2. FIDO in Windows 10 / ふじえ(@phr_eidentity




    2番目が私のパートでした。
    基本的にはこれまで本ブログで書いてきたことばかりではありますが、マイクロソフトが Windows 10 と Microsoft Azure Active Directory で目指している True SSO 環境=「どこからでも、どんなデバイスからでも、デバイス~アプリケーション間での SSO を実現できる環境」と構成する要素である Microsoft Passport / Windows Hello の概要の説明、そして Azure AD Join を行った環境におけるデバイス登録~ログイン~アプリケーション利用までのフローの解説をさせてもらいました。
    FIDO との関係としては、デバイスの登録およびPCへのログインの部分の仕組みが正に FIDO、そのあとのアプリケーション利用の仕組みは OpenID Connect ってあたりです。


    3. Yahoo! JAPAN の FIDO への取り組み / ヤフー 五味さん




    このセッションが一番最初だったら良かったんじゃ、、と思いました。
    パスワードの課題~ FIDO の概要・仕組みに関する説明が抜群にわかりやすかったので、このスライドを見た後に、Azure AD Join のフローを見るとどこが FIDO なのか?についてより理解できると思いました。
    FIDO の本質はデバイス登録~信頼により、認証サーバが登録済みデバイスによって行われたユーザ認証結果を信頼する、という流れでユーザ認証に関するやり取りがネットワーク上を流れなくする=クレデンシャルを保護しやすくなる、というのが一番のキモですね。


    4. パスワードレス認証 M-Pin の概要 / CertiVox 尾崎さん

    NTTソフトさんの Trust Bind との組み合わせソリューションとして最近日本でも活動を始めた英国の CertiVox 社のパスワードレス認証の仕組み「M-Pin」の紹介でした。
    FIDO のような標準化を目指した仕組みではなく、独自の仕組みではありましたが、銀行 ATM の暗証番号入力のようなユーザ・インターフェイスは使いやすそうで、一般の利用者に多要素認証を使わせるにはハードルが低いのではないか?と思いました。

    https://www.certivox.com/





    ◆おまけ
    ちなみに、セッションを引き受けた時は Windows Hello が5月末には使えるようになっているだろうなぁ、、、という微かな期待の元、インテルの Real Sense (3D/赤外線カメラ)を買って準備していたんですが、残念ながらセッション当時リリースされていた Windows 10 Technical Preview Build 10074 / 10122 ではまだ Windows Hello は実装されていませんでした・・・。昨日あたらしく 10130 がリリースされていたので、そちらで試してみてまた別途レポートします。。

    製品ページ
     http://www.intel.co.jp/content/www/jp/ja/architecture-and-technology/realsense-overview.html
    Amazon
     http://amzn.to/1LPbBbW



    [Windows10]Intel RealSense F200でWindows Hello

    $
    0
    0
    ついに2015/07/29にリリースされる発表されたWindows10ですが、やはり気になるのはWindows Helloによる生体認証です。

    そして今回は最新のInsider PreviewでWindows Helloを試して玉砕した話です。

    これまで中々Preview版に搭載されてこなかったので、どのようなデバイスが対応するのか?どのように動くのか?については情報が少なかったのですが、Build 10130でようやく実装されてきました。
     公式blog
     https://blogs.windows.com/bloggingwindows/2015/05/29/announcing-windows-10-insider-preview-build-10130-for-pcs/

    なお、私は以下のPOSTを信じてIntel RealSense 3D Camera F200の開発者キットを購入済みでした。
     公式blog
     https://blogs.windows.com/bloggingwindows/2015/03/17/making-windows-10-more-personal-and-more-secure-with-windows-hello/

    We’re working closely with our hardware partners to deliver Windows Hello capable devices that will ship with Windows 10 and we are excited to announce that all OEM systems incorporating the Intel® RealSense™ 3D Camera (F200) will support the facial unlock features of Windows Hello, including automatic sign-in to Windows, and support to unlock “Passport” without the need for a PIN.



    http://click.intel.com/intel-realsense-developer-kit.html


    さっそくHelloの設定を!と思いましたが、肝心のセットアップボタンが出てきません。


    カメラがうまく認識されていないのか、と思いF200のSDKに付属のユーティリティで赤外線カメラの動作状況を確認してみます。


    うまく動いているようです。ひどい写真・・・

    ちなみにWindows Helloの生体登録画面を検索機能で直接呼び出すこともできるので直接起動してみると無反応の黒い画面が起動します。
    (英語版でBio Enrollmentという名前のアプリケーションです。しばらく前からこれは何なんだ??って某所で話題になっていたやつです。「生体登録」という名前で検索すると起動できます)



    ちょっと状況を確認してみましょう。

    まずはイベントログを見てみます。
    対象のログは「アプリケーションとサービスログ\Microsoft\Windows\BiometricsのOperational」です。
    初期状態ではログが無効化されているので有効にしてOSを再起動するか、ローカルサービスより「Windows Biometric Serive」を再起動するとデバイスの再認識が走るので状況が記録されます。


    初期化に失敗しているようですね。
    さらに深堀してみましょう。

    レジストリエディタを開いて該当するエントリを探します。
    ありました。
    HKLM\SYSTEM\ControlSet001\Services\WbioSrvcです。


    顔認証をさせたかったので、FacialFeaturesのVirtual Sensorsあたりを見るとモジュール情報が入っていますが、SerialNumberがTBDとかおしゃれな感じです。さらに探っていくと、DatabaseIdというエントリが見つかりました。


    これがWbioSrvc直下のDatabases以下のエントリと紐づいているようです。実際にDatabasesの該当するキーを見るとFilePathで物理ファイルとの紐づきを管理しているようです。



    ここまで来これば、直接ファイルの状態を見てみるしかありません。


    ・・・ありませんでした。
    登録に失敗しているのですから当然ですね。

    と、あまり実りのないことを深堀りしましたが、その後Intelの開発者フォーラムで以下のPOSTを発見しました。
    https://software.intel.com/en-us/forums/topic/559166

    Q: Curious if this camera with drivers installed compatible with Windows Hello in the latest builds of Windows 10?
       If it is - any tricks to making it work?
    A: It's not yet. With the next DCM release for the user facing camera and SDK version, it is planned to be supported.


    なるほど。次のバージョンのDCM(Depth Camera Manager)を待て、、と。

    とりあえず顔認証はしばらくお預けですね。

    ちなみに、私の周りの方の試したデバイスと結果は以下のような感じです。
    ・Lenovo ThinkPad X1 Carbon内蔵指紋認証デバイス : ○
    ・UPEK Eikon USB外付け指紋認証デバイス : ○
    ・RATOC SREX-FSU2 : ×
    ・Kinect/Kinect v2 : ×

    なかなか厳しいですね。
    LenovoのPCなど指紋認証デバイスがついているPCではちゃんとWindows Helloが動いているようなので、おそらくこのままバグフィックスをして製品としてはローンチされるんですかね。Intelの対応が待ち遠しいです。

    [AzureAD]入門コンテンツ - クラウド時代のActive Directory次の一手シリーズ

    $
    0
    0
    今でこそ一般名詞になってしまった「Active Directory」ですが、Windows 2000 Serverが出てきた当時は、いったい何がどうアクティブなのかさっぱり・・・でした。
    (私は当時ActiveXのコンポーネント開発なんかをやっていたので、「最近のマイクロソフト的なブームはアクティブなのか~」と思っておりました。当時はMicrosoft DNAとか色々と有りましたねぇ)

    と、まぁ昔話をしても仕方がないのですが、Active Directoryも進化・多様化が進み、AD LDSやらAD RMSやらAD CSやらAD FS、ついにはAzure ADなんていうものまで出てきて、いわゆるNTドメインとはかけ離れたものになってきています。

    どうやらここら辺でActive Directoryシリーズについてのおさらいと、今後Active Directoryがどうなっていくのか?について簡単におさらいをしておく必要がありそうです。

    そんな方には「Microsoft Virtual Academy(通称MVA)」です。
    色々なオンライン・トレーニングコンテンツが無償で公開されており、ユーザ登録をしなくても参照が可能ですし、ユーザ登録をすれば学習の進捗に合わせてポイントをためたり、コンテンツのダウンロードができたりします。

    今回はMS安納さんが公開している「クラウド時代のActive Directory次の一手」シリーズを紹介します。
    現在第4回まで公開されており、概要からAD FSの構築の部分まで動画で確認することができます。

    • 第 1 回 Active Directory の位置づけ
    • 第 2 回 Active Directory ドメイン サービスの新しい役割
    • 第 3 回 Active Directory フェデレーション サービスの役割 解説編
    • 第 4 回 Active Directory フェデレーション サービスの役割 構築編


    こんな感じで、スライドを使ったプレゼン動画が参照できます。

    1回あたり30分程度なので、それほど時間も取られませんし、簡単に参照もできるのでこの機会に基本的なところからおさらいをしてみると良いかも知れませんね。

    [Google/ACS]6/1を迎えてAzureACSのGoogle IDプロバイダーはどうなった

    $
    0
    0
    2015/04/20をもってGoogleのOpenID 2.0のサポートが終了し、マイクロソフトもAzure ACS(アクセス制御サービス)のGoogle IDプロバイダー設定を6/1までに変更するようにアナウンスを出していました。

    関連ポスト)
     GoogleのOpenID 2.0サポート終了による影響いろいろ(Azure ACS編)
     http://idmlab.eidentity.jp/2015/03/googleopenid-20azure-acs.html

     [Google]4/20を迎えてAPIはどうなった?
     http://idmlab.eidentity.jp/2015/04/google420api.html


    と、いうことで6月を超えたのでACSがどうなったのかを確認してみました。
    結果、まだOpenID 2.0が動いています。結構しぶといです。
    (人によって動いていない、という話もあるようなので環境に依存するのかもしれません)

    これまで通りの動きです。
    1.アプリケーションの認証の設定を行います。

    2.実行するとレルムディスカバリ画面がでます。

    3.Googleアカウントでログインします。

    4.認可をおこないます。

    5.アプリケーションからGoogleの属性が取得できています。




    このように中々しぶとい状況ですが、MSDNには以下のアナウンスが出ています。
    https://msdn.microsoft.com/ja-jp/library/azure/dn927169.aspx

    2015 年 6 月 1 日 - ACS 名前空間は Google の OpenID 2.0 実装の使用を停止します。この日までに、ACS 名前空間の移行を完了して、Google OpenID Connect を使用する必要があります。この日までは、移行中に問題が発生しても、OpenID 2.0 にロールバックできます。
    ほとんどの場合、アプリケーション コードの変更は必要ありません。アプリケーションに関連付けられているルール グループに ID プロバイダーとしての Google に対して "すべての要求をパススルーする"というルールが存在する場合は、コードの変更が必要になる場合があります。これは、移行によって Google からの新しい要求の種類 (サブジェクト) が ACS で利用可能になることから、アプリケーションが新しい要求の種類の存在を適切に処理できるようにコードを変更する必要が生じる場合があるためです。移行を正常に完了させるうえで、アプリケーションで新しい要求の種類を処理する必要はありません。
    2017 年 1 月 1 日 - Google の OpenID 2.0 と OpenID Connect の実装では、Google ユーザーを一意に識別するのに、異なる識別子を使用します。ACS 名前空間の移行後は、現在の OpenID 2.0 識別子と新しい OpenID Connect 識別子の両方をアプリケーションで使用できるようになります。この日までにバックエンド システムでユーザーの識別子を OpenID Connect 識別子に切り替え、以降は OpenID Connect 識別子のみを使用する必要があります。これには、アプリケーション コードの変更が必要です。



    ACS側の移行が終わっても次は2017/01/01までに従来のOpenID 2.0で使っていた識別子(nameidentifier)ではなく、OpenID Connectの識別子(subject)を使うようにアプリケーションの改修を行う必要があるようです。
    ACS側でのクレームのマッピングを修正する形にしたほうが柔軟な気もしますので、私ならACSのクレームマッピング(規則グループ)を変えますが。。
    ※この図のnameidentifierとsubjectのマッピングを合わせてあげる形にします。既存アプリケーションはnameidentifier属性を見ているはずなので、OpenID Connect対応した際にGoogleから取得できるようになるsubject属性を出力側のnameidentifier属性にマッピングしてあげればアプリケーションを改修する必要はありません。


    まだまだ余裕はありますが、こちらの改修も早めに実施しておいたほうがよさそうですね。

    ※使えなくなる瞬間どうなるのかを確認したいので、あえてACSの設定を移行せずに残してあるのですが、中々使えなくならないので、今後も引き続きウォッチしていきたいと思います。

    [Windows10]K-Byte Fingerprint Security ReaderでWindows Hello

    $
    0
    0
    先日のポストでIntel RealSense F200でWindows Hello(顔認証)を試して玉砕した話は書きましたが、今度は指紋認証デバイスを試してみます。

     前回のポスト:[Windows10]Intel RealSense F200でWindows Hello
     http://idmlab.eidentity.jp/2015/06/windows10intel-realsense-f200windows.html


    今回使ったのは、K-ByteのFingerprint Security Readerです。
    日本のAmazonでは売っていないので、USのAmazon.comで探すとたったの$12で購入することができます。(USからの送料を入れると$33ちょっとで購入できます。Express Shippingを使ったので5日くらいで届きました)



    こちらから購入できます。
    http://amzn.to/1S7fFYr

    特にドライバをインストールする必要もなく、生体認証デバイスとして認識されます。


    デバイスを正しく認識できれば、アカウント設定のサインインオプションのWindows Helloのところに指紋認証のセットアップメニューが出てきます。


    さっそくセットアップをしてみます。

    Windowsのご挨拶。。。。なかなか素敵な翻訳です。

    「開始する」をクリックするとPINの入力を求められます。


    次に指紋の登録を求められるので、数回スキャンをします。

    何度かスキャンします。


    うまく行くと登録が完了しますので、さっそくログアウトしてみます。


    ログイン画面にサインインオプションとして指紋が追加されます。
    ※画面ショット取得の都合上、ここから英語OSの画面を掲載しています。
     (単純にログイン画面の画面ショットを撮るためにVM上に構成したのですが、手元のVMが英語版しかなかったので。。。設定は物理マシン上の日本語OSで画面ショットを取得しています)

    ここで指紋をスワイプし、うまく認識されるとログインできます。


    ちなみに、うまく認識できないと以下のようなエラーが出ます。



    単純に指紋認証だとWindows8.1のころとそれほど変化がないので、個人的にはやはり早く顔認証を使ってみたいなぁ、、と思います。


    追記)
     尚、現状だとMicrosoftアカウントもしくはローカルアカウントだとWindows Helloが使えますが、AAD JoinしたAzureAD上のアカウントでログインするとBioEnrollmentHost.exeがクラッシュしてWindows Helloのセットアップができません。
    (バグなのか、環境が悪いのかはわかりませんが)

    [IdM全般]アイデンティティ管理プロジェクトに必要なスキル(Active Directory/Azure AD編)

    $
    0
    0
    以下のblogにアイデンティティ・アクセス管理プロジェクトを実行する上で強みとなるスキルのリストが挙げられています。

     Killer Skills for an Identity and Access Management (IAM) Project
     http://blog.avatier.com/killer-skills-for-identity-and-access-management-project/


    Red hot identity and access management skillsということで色々なスキルのリストが上がっていますが、PCが燃えあがる絵は単純に炎上プロジェクトに見えてしまいますね。

    さて、書かれている内容ですが、テクニカルに寄ってはいますが、非常に基本的なスキルセットが羅列されているので新入社員を育てる上では参考になるかもしれません。
     ※ちょうど、社内でどうやって技術者を育てるのか考える時期に来ている人も多いはず。
     ※ちなみに私も参画しているJNSAのアイデンティティ管理WGのテーマとしても人材育成がテーマ候補として挙がっていたりします。


    必要なスキルとして挙がっているのは以下の通りです。
    ・LDAP関連の知識
    ・データベースに関する知識/SQL関連の知識
    ・認証/認可のモデルに関する理解
    ・スクリプト言語


    私の経験的に言うと、一般的な開発経験者にプロジェクトに入ってもらう際にまず第一にハードルになるのが実は最初に挙がっているLDAP関連、特にActive Directoryに関する知識・スキルだと思っています。
    エンタープライズ領域においてアイデンティティ管理プロジェクトはやはり開発プロジェクトになることが多いので開発者をアサインするのですが、反面LDAPやActive Directoryはインフラ領域(下手するとネットワーク領域)にあるので、開発者からすると非常にハードルが高いようです。
    また、インフラ系のエンジニアにとってもクラウド上のAzure ADに関してはやはり基礎から理解をしておきたい分野です。

    そんな方にはマイクロソフトが用意している教育コンテンツのMVA(Microsoft Virtual Academy)、ということでActive Directory/Azure AD関係のコンテンツをまとめてみました。
    一部英語のコンテンツもありますが、日本語の字幕があるのはうれしいですね。


    カテゴリタイトルURL
    基礎Active Directory を理解するhttp://goo.gl/jHgGn4
    クラウド時代の Active Directory 次の一手シリーズ第 1 回 Active Directory の位置づけhttp://goo.gl/nAFcX0
    第 2 回 Active Directory ドメイン サービスの新しい役割http://goo.gl/Sp6hBF
    第 3 回 Active Directory フェデレーション サービスの役割 解説編http://goo.gl/1uEyS9
    第 4 回 Active Directory フェデレーション サービスの役割 構築編http://goo.gl/VHgHoN
    Azure Active DirectoryMicrosoft Azure Active Directory の概要http://goo.gl/4UzIWO
    (MCP 70-533 対応) Microsoft Azure インフラの実装 ~ Part 2 Azure Active Directory の実装編http://goo.gl/mykkL0
    Azure Multi-Factor Authenticationhttp://goo.gl/Yk7Ne5
    Office 365Office 365 Identity Managementhttp://goo.gl/8bfJfl

    [AzureAD]アクセスルールで社外からのアクセスを制御する

    $
    0
    0
    ※現在Public Previewとして提供されている機能なので、今後の機能変更などが発生する可能性があります。

    Office365やGoogleApps等のSaaSアプリケーションのメリットはどこからでも(社内からも、社外からも)アクセスできるところにあります。
    ただ、企業の情報システム部門としてはいつでも、どこでもアクセス出来るからと言って、自宅のPCやネットカフェなどの安全ではない端末からIDとパスワードだけでアクセスされるのはちょっと、、ということもあり、オンプレミスのAD FSなどと組み合わせて信頼できるネットワークからのみのアクセス出来るようにしたり、多要素認証を強制したり、と安全性を何とか確保しようと日々努力をしています。

    たとえば以下のような方式です。
    ・社内ネットワークからしかアクセス出来ないようにする
     方法1:VPNで社内ネットワークへ参加しないとAD FSに到達できないように構成する
     方法2:AD FSのクレーム・ルールを書いてクライアントIPによって承認を制御する 
    ・社内ネットワーク以外からのアクセスであれば多要素認証を要求する
     方法1:AD FSの多要素認証を構成し、社外ネットワークの場合の認証ポリシーを構成する

    これまで、これらの方法はいずれもAD FSが必要でしたが今回紹介するアクセスルールを使うとAzure Active Directory(Azure AD)だけで実装ができるようになるので、より手軽に実装が可能になります。

    ちなみに話はそれますが、個人的にはAD FSとWeb Application Proxy(WAP)を使って社内のIdPをDMZに配置してインターネットからでも利用できるようにするくらいなら、素直にAzure ADで認証をしてしまった方が良いと考えています。セキュリティの専門家を自社に抱えていて、DMZのIdPを守る努力を日々継続的に実行できるなら話は別ですが、なかなかあることではないので、Azure ADなりOktaなりの外部のIDaaSに任せてしまった方が安全なのではないかと思います。(さらに多要素認証を使えばより強固になりますし)
    この辺りはまた別の機会に書いていこうと思います。


    本題に戻ります。

    現在、Azure ADのアプリケーション・アクセスルールで出来ることは以下の通りです。

    アプリケーション単位で、
    ・必ず多要素認証を要求する
    ・社外からのアクセスなら多要素認証を要求する
    ・社外からのアクセスをブロックする
    ことができる。
    その際、
    ・ルール適用対象のグループ
    ・ルール適用除外のグループ
    を設定することができる。


    では早速やってみたいと思います。

    今回、テスト用アプリケーションにはGoogle Appsを利用し、多要素認証のON/OFF、ルール適用除外グループへの参加/不参加、社内/社外からのアクセスの各パターンでの挙動を確認します。
    (ちなみに必ず多要素認証を要求する、というルールは単純すぎるので除外しています。単に多要素認証が要求されるだけなので)

    初めに書いてしまいますが、結果は以下の表のようになります。
    ※External Usersというグループについてルールの適用を除外するように設定をしています。
    ルールアクセス元所属グループ多要素認証結果
    作業中でない場合、多要素認証が必要です
    - 除外:External Users
    社内ネットワークExternal UsersYesOK
    NoOK
    Google UsersYesOK
    NoOK
    社外ネットワークExternal UsersYesOK
    NoOK
    Google UsersYesOK
    NoNG
    ※多要素認証設定が要求される
    作業中でない場合、アクセスをブロック
    - 除外:External Users
    社内ネットワークExternal UsersYesOK
    NoOK
    Google UsersYesOK
    NoOK
    社外ネットワークExternal UsersYesOK
    NoOK
    Google UsersYesNG
    NoNG



    では、順番に行きます。
    まずは、「作業中でない場合、多要素認証が必要です」というルールを使います。
    ※「作業中=社内ネットワークからのアクセス」ととらえてください。翻訳・・・


    社内ネットワークの定義は多要素認証プロバイダの管理コンソールで行います。



    まずは多要素認証が設定されているユーザでアクセスします。


    当然ですが、社内からでも社外からでもアプリケーションが利用できます。


    次に、多要素認証が設定されていないユーザで社内ネットワークからアクセスしてみます。
    こちらも当然問題ありません。

    一方で同じユーザを使って社外ネットワークからアクセスしてみます。
    今回は多要素認証が必要となるので、ログオン時に多要素認証のセットアップを要求されます。


    ただ、この同じユーザを除外対象のグループ(External Users)へ参加させて再度アクセスすると今度は問題なくアプリケーションが利用できます。


    次に、「作業中でない場合、アクセスをブロック」というルールを使います。



    ルールに適合するケースは単にアクセス出来てしまうだけなので、条件に適合しない場合の挙動を確認します。
    除外対象グループメンバに所属していないユーザが、社外からアクセスした場合が該当しますので試してみます。



    見事にブロックされました。
    エラーメッセージをよく見ると、「User account 'アカウント名' does not satisfy Access Policy」とある通り、アクセス条件を満たさなかったのでエラーが出ていることがわかります。

    内勤の人など、業務上に社外からアクセスする必要がない人についてはこのようなルールを適用して安全にアプリケーションを使う、というのも良いシナリオかも知れませんね。

    [IdM全般]トレーニングコンテンツ色々/プロジェクトの進め方~モバイルデバイス管理~開発まで

    $
    0
    0
    最近のポストで2回ほど紹介したMicrosoft Virtual Academy(MVA)というオンライントレーニングコースですが、その後もアイデンティティ関連のコースを探索していたら何個か面白いものが出てきたので紹介したいと思います。

    参考)これまで紹介したポスト
    [IdM全般]アイデンティティ管理プロジェクトに必要なスキル(Active Directory/Azure AD編)
    [AzureAD]入門コンテンツ - クラウド時代のActive Directory次の一手シリーズ



    今回紹介させて頂くコンテンツの一つ目は「ID とアクセス管理の全体像」シリーズです。

    基本はMicrosoft Conference 2014の中のセキュリティ~ID管理系のコンテンツを集めたシリーズになっており、以下の6つのコンテンツ+セットアップ手順書のセットになっています。
    • 基本から見直すセキュリティ~標的型攻撃の実態と取り組むべきセキュリティ対策~
    • Dynamic Identity Framework~クラウド時代適応のためのID管理手法~
    • ハイブリッドな認証基盤で生産性を高めるために必要な基礎知識
    • モバイルの企業活用を支えるデバイス統合管理ソリューション
    • Azure Rights Managementによる社外ユーザーとのセキュアのコンテンツ共有の実現
    • 多要素認証Deep Dive~ハイブリッド認証基盤だからこそ実現できる柔軟で高機能な多要素認証~

    特に2つ目のDynamic Identity Framework(DIF)のセッションでは実際のコンサルティングプロジェクトで企業のID管理の現状分析と課題の洗い出しを行う方法論について語られているのでプロジェクトにかかわる方には参考になるかもしれません。

    もちろんそのような方には、JNSAのアイデンティティ管理WGの出している「改訂版クラウド環境におけるアイデンティティ管理ガイドライン」もあわせておすすめです。(宣伝)



    二つ目に紹介するMVAコンテンツはAndroid / iOSのようなモバイルデバイスを管理するためのソリューションセット「Enterprise Mobility Suite(EMS)」に関する「Taming Android and iOS with Enterprise Mobility Suite」というコンテンツです。
    URL:http://goo.gl/8IOhcm

    基礎的な部分からAndroid / iOSそれぞれについての具体的な仕組みや設定についてデモを交えて紹介しています。


    最後は開発系コンテンツの「Customizing ASP.NET Authentication with Identity」です。
    URL:http://goo.gl/t95rEu

    OAuth/ソーシャルアイデンティティ連携から多要素認証まで、ASP.NET Identityでどうやって実装するのか、具体的な実装方法に関する紹介をしています。


    私を含めBlogやTechnet / MSDNなどだと都度都度情報が分散してしまっているので、こういう形でまとめてあると基礎から勉強しなおすにはいいですね。


    Viewing all 771 articles
    Browse latest View live