こんにちは、富士榮です。
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と組み合わせるともっと柔軟に制御ができるようになるので、おいおい試してみたいと思います。
2015年7月23日木曜日
2015年7月13日月曜日
[AAD Connect]LDAPからOffice365へID同期する
こんにちは、富士榮です。
先月正式リリースされた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
先月正式リリースされた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
2015年7月12日日曜日
[Windows10]ついにWindows Helloで顔認証!
こんにちは、富士榮です。
ようやく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://downloadcenter.intel.com/download/25044/Intel-RealSense-Depth-Camera-Manager-DCM-
ということで早速導入、試してみました。
◆Windows Helloのセットアップ
「顔認証」のメニューが!!
◆セットアップ
痩せました。はい。。。
うまく行きました!
ロック解除に使えるようになっています。
◆ロック解除してみる
一瞬で解除されました。
想像以上に認識が早いです。
素晴らしいです!
ようやく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://downloadcenter.intel.com/download/25044/Intel-RealSense-Depth-Camera-Manager-DCM-
ということで早速導入、試してみました。
◆Windows Helloのセットアップ
「顔認証」のメニューが!!
◆セットアップ
痩せました。はい。。。
うまく行きました!
ロック解除に使えるようになっています。
◆ロック解除してみる
一瞬で解除されました。
想像以上に認識が早いです。
素晴らしいです!
2015年7月11日土曜日
[MIM]Active Directoryの特権アカウント管理環境を構築する~実施編
こんにちは、富士榮です。
今回は、前回に引き続き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アカウントを特権アカウント管理サーバ側のドメインに作成するため、[ドメイン名$$$]という名称のセキュリティグループを既存ドメイン上に作成しておきます。
また、既存ドメイン上の特権として利用するセキュリティグループ(ここではCorpAdmins)の作成および特権利用ユーザの元となるユーザ(ここではJen)を作成しておきます。
特権利用申請をMIMで行うと、ここで作ったセキュリティグループの持つ権限が付与されることになります。
・特権アカウント管理サーバ側の準備
※PowerShellのモジュール読み込み、既存ドメインへの接続
・特権グループの作成(既存ドメイン上のCorpAdminsグループのSIDをコピーして作成)
※dc.eidentity.localは既存ドメインの任意のドメインコントローラ
※New-PAMGroupを実行した段階で特権アカウント管理サーバのドメイン上に[ソースドメイン名].[グループ名]というグループオブジェクト(Shadowアカウント)が作成される。
・特権利用ユーザの作成(既存ドメイン上のユーザ/jenをベースに作成)
※New-PAMUserを実行した段階で特権アカウント管理サーバのドメイン上にPRIV.[ユーザ名]というユーザが自動的に作成される
・特権ロールへ特権グループ、特権利用ユーザの紐づけ
これで準備は完了です。
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とぴったり合うと思われます。
今回は、前回に引き続き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とぴったり合うと思われます。
[MIM]Active Directoryの特権アカウント管理環境を構築する~環境構築編
こんにちは、富士榮です。
今回は、先日紹介した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で構成しました。
・モジュールのインストール
・フォレスト/ドメインの構成
◆Internet Information Service(IIS)の導入
特権アカウント管理はREST APIでコントロールするため、APIをホストするWeb Serverの導入を行います。
DドライブにOSのDVDを挿入した状態で以下を実行します。
◆必要なユーザアカウントの作成と設定
以下のアカウントが必要です。
尚、それぞれサービスアカウントなのでパスワード期限は無期限にセットしておきます。
こちらもPowerShellで一括で作ります。
◆その他設定
その他、必要な設定を行います。(必要に応じて再起動します)
・GroupPolicy設定
デフォルト・ドメイン・コントローラ・ポリシー
・コンピュータの管理->ポリシー>Windowsの構成>セキュリティ設定>ローカルポリシー>監査ポリシー
・アカウント管理 : 成功/失敗
・ディレクトリアクセス : 成功/失敗
デフォルト・ドメイン・ポリシー
・コンピュータの管理>ポリシー>Windowsの構成>セキュリティ設定>ローカルポリシー>ユーザ権限の管理
・バッチジョブとしてログオンを拒否する
MIMMonitor / MIMComponent / MIMService
・リモートデスクトップ経由でのログオンを拒否する
MIMMonitor / MIMComponent / MIMService
・Kerberosの権限移譲
Active Directoryユーザとコンピュータより委譲設定。
・委譲先ユーザ: MIMMonitor / MIMComponent
・委譲権限 : ユーザの作成・削除・管理、グループのメンバシップの変更
・Service Principal Name(SPN)の設定
以下を設定します。
・特権管理対象ドメインへの名前解決設定
後で既存のドメインから信頼関係を結ぶので、既存ドメインの名前解決ができるようにゾーンを構成しておきます。今回は以下の環境に設定をしています。
既存ドメイン : eidentity.local
既存ドメインコントローラ(DNSサーバ) : 192.168.5.30
条件付きフォワーダを設定します。
◆SQL Server 2014 Standard Editionの導入
メディアを挿入し、以下で最低限必要なコンポーネントを導入します。
◆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へのアカウントの設定を行います。
・特権管理ポータル用Webサイトを構成する
CTPで提供されているサンプルポータルを使います。最新ビルドだとちょっと改造が必要なので、そのあたりは追々。。
とりあえずサンプルモジュールを
C:\Program Files\Microsoft Forefront Identity Manager\2010\Privileged Access Management Portal\
へ展開し、Webサイトを作成します。
◆既存ドメインとの信頼関係設定を行う
既存のドメインから特権管理ドメインへの片方向の信頼関係を結びます。
・名前解決設定
既存のドメインコントローラから特権管理ドメインへの名前解決ができるように既存ドメインのDNSサーバにpyramid.localのスタブゾーンを作ります。(もちろん別の方法でも良いです)
・SAMデータベースへのRPCの有効化
既存ドメインコントローラで以下のレジストリを設定(PowerShellで設定)します。これでSID Historyをリモートで読み取れるようになります。
・特権管理サービスのコマンドレットで必要な信頼関係設定を行う
信頼関係を結ぶのに必要な設定がパッケージ化されたコマンドレットが用意されているので、特権管理サーバ上で以下のコマンドレットを実行します。
クレデンシャルが求められるので、既存ドメインの管理者アカウントの権限を入力します。
・既存ドメイン上のオブジェクトへの読み込み権限を委譲する
Active Directoryユーザとコンピュータより特権アカウント管理ドメイン上のユーザ(MIM MonitorサービスおよびDomain Admins)へ既存ドメイン上のユーザ情報の読み取り権限を委譲します。
・委譲先ユーザ: MIMMonitor / Domain Admins
・委譲権限 : すべてのユーザ情報の読み取り
ここまでで環境の導入は終了です。
次回は必要な特権管理用ユーザ、グループの設定をしてテストをしてみます。
今回は、先日紹介した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 Service | MIMMonitor | ||
MIM Component Service | MIMComponent | ||
MIM Service | MIMService | Domain Admins | |
MIM 管理Agent | MIMMA | 使わないがセットアップに必要なので作成 | |
SQL Server | SqlServer | ||
PAM REST API Web Service | PAMAppPool | Domain 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
・委譲権限 : すべてのユーザ情報の読み取り
ここまでで環境の導入は終了です。
次回は必要な特権管理用ユーザ、グループの設定をしてテストをしてみます。