こんにちは、富士榮です。
ようやく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月12日日曜日
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
・委譲権限 : すべてのユーザ情報の読み取り
ここまでで環境の導入は終了です。
次回は必要な特権管理用ユーザ、グループの設定をしてテストをしてみます。
2015年7月5日日曜日
[AzureAD]エンドユーザによるアプリケーション利用申請と承認
※今回紹介する機能にはPreview機能を含みます。今後の機能変更などが発生する可能性があるので、ご注意ください。
こんにちは、富士榮です。
組織のID管理の設計をしていると必ず出てくるのが「アプリケーションの割り当てをどのようなフローで行うか」という課題です。
パターンとして、
①特定のユーザ属性をみて機械的に割り当てる(例えば正社員は自動的に割り当て等)
②管理者による手動割り当て
③既存のワークフローシステムとの統合
④ID管理システム自体に申請~承認フローを組み込む
などがありますが、それなりに複雑化しやすく工数もかさむのでスタート時点では①の方法である程度自動化しておいて②の方法で例外ユーザを登録していく、という形で決着することが経験上は多い気がします。
ただ、アプリケーションが増えてきたり、必ずしも大多数の人が使うとも限らないアプリケーション(例えばプロジェクト専用アプリケーションなど、特定の業務用のもの)では機械的に割り当てるルールを書くのが困難な場合もあります。
そのような場合、利用者自身による利用申請~管理者による承認、という簡易ワークフローのような機能があると重宝します。
Azure Active Directory(AzureAD)にもアプリケーション利用のための簡易ワークフロー機能がPreviewとして提供されています。
早速確認してみます。
◆ユーザ自身が申請ができるようにアプリケーションを構成する
設定はアプリケーション単位で行います。
対象のアプリケーションを開き、[構成]メニューより[セルフサービスアクセス]設定を行います。
設定項目は以下の3点です。
・アプリケーションのセルフ サービス アクセスを許可する
⇒許可するかどうかのON/OFF設定
・アクセス権を付与する前に承認を要求します
⇒申請に対する承認が必要かどうか。承認が不要であれば、申請した段階で自動的に割り当てられる。
・承認者
⇒承認するユーザを選択します。複数人選択することは出来ますが多段階の承認フローなど複雑なことは出来ません。
◆利用申請を行う
アプリケーションパネル(https://myapps.microsoft.com)へアクセス、申請を行うユーザでログインします。
申請可能なアプリケーションがテナントに存在すると[アプリケーションをさらに取得]というアイコンが表示されるようになっているので、クリックして申請を行います。
これで申請は完了です。
◆利用申請を承認する
今度は先ほど承認者として設定したユーザで同じくアプリケーションパネルへログインします。
[承認]というメニューが出てくるのでクリックします。
すると申請一覧が表示されるので、選択して[Approve]をクリックして承認を行います。
◆承認されたアプリケーションが利用できるようになっていることを確認する
先ほど申請したユーザで再度アプリケーションパネルへログインします。
すると、アプリケーション一覧が更新されており、申請したアプリケーションが利用できるようになっています。
ワークフロー単体としてみると機能はかなり限定的ではありますが、一部のアプリケーションにのみ適用するなどすれば管理負荷を下げることができると思います。
こんにちは、富士榮です。
組織のID管理の設計をしていると必ず出てくるのが「アプリケーションの割り当てをどのようなフローで行うか」という課題です。
パターンとして、
①特定のユーザ属性をみて機械的に割り当てる(例えば正社員は自動的に割り当て等)
②管理者による手動割り当て
③既存のワークフローシステムとの統合
④ID管理システム自体に申請~承認フローを組み込む
などがありますが、それなりに複雑化しやすく工数もかさむのでスタート時点では①の方法である程度自動化しておいて②の方法で例外ユーザを登録していく、という形で決着することが経験上は多い気がします。
ただ、アプリケーションが増えてきたり、必ずしも大多数の人が使うとも限らないアプリケーション(例えばプロジェクト専用アプリケーションなど、特定の業務用のもの)では機械的に割り当てるルールを書くのが困難な場合もあります。
そのような場合、利用者自身による利用申請~管理者による承認、という簡易ワークフローのような機能があると重宝します。
Azure Active Directory(AzureAD)にもアプリケーション利用のための簡易ワークフロー機能がPreviewとして提供されています。
早速確認してみます。
◆ユーザ自身が申請ができるようにアプリケーションを構成する
設定はアプリケーション単位で行います。
対象のアプリケーションを開き、[構成]メニューより[セルフサービスアクセス]設定を行います。
設定項目は以下の3点です。
・アプリケーションのセルフ サービス アクセスを許可する
⇒許可するかどうかのON/OFF設定
・アクセス権を付与する前に承認を要求します
⇒申請に対する承認が必要かどうか。承認が不要であれば、申請した段階で自動的に割り当てられる。
・承認者
⇒承認するユーザを選択します。複数人選択することは出来ますが多段階の承認フローなど複雑なことは出来ません。
◆利用申請を行う
アプリケーションパネル(https://myapps.microsoft.com)へアクセス、申請を行うユーザでログインします。
申請可能なアプリケーションがテナントに存在すると[アプリケーションをさらに取得]というアイコンが表示されるようになっているので、クリックして申請を行います。
これで申請は完了です。
◆利用申請を承認する
今度は先ほど承認者として設定したユーザで同じくアプリケーションパネルへログインします。
[承認]というメニューが出てくるのでクリックします。
すると申請一覧が表示されるので、選択して[Approve]をクリックして承認を行います。
◆承認されたアプリケーションが利用できるようになっていることを確認する
先ほど申請したユーザで再度アプリケーションパネルへログインします。
すると、アプリケーション一覧が更新されており、申請したアプリケーションが利用できるようになっています。
ワークフロー単体としてみると機能はかなり限定的ではありますが、一部のアプリケーションにのみ適用するなどすれば管理負荷を下げることができると思います。
2015年7月2日木曜日
[Azure MFA]新Azure AuthenticatorアプリでGoogle2段階認証を使う
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へ引っ越してもらう、というようなユースケースで利用者の負担を減らせるので良いのになぁ、、と思ってしまいます。
引き続きウォッチですね。
2015年6月28日日曜日
[MIM]特権アカウント管理機能の概要
リリース目前の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側のジョブの走るタイミングによると思いますが、期限が切れるタイミングと実際にグループメンバから外れるタイミングには数分のタイムラグがあります。
次回以降、環境の構成方法などもう少し細かい方法を解説していきたいと思います。
以前のポストでどのような動きになるのか動画を紹介しましたが、今回は具体的な中身についてみていきたいと思います。
参考)[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側のジョブの走るタイミングによると思いますが、期限が切れるタイミングと実際にグループメンバから外れるタイミングには数分のタイムラグがあります。
次回以降、環境の構成方法などもう少し細かい方法を解説していきたいと思います。
登録:
投稿 (Atom)














































