Active Directoryのパスワードに特定の文字の利用を禁止する

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

先日紹介したAzure ADの新機能「Azure AD Password Protection for Windows Server Active Directory」を使うとブラックリストに載っているパスワードを使うことを禁止することは出来る様になりますが、特定の文字だけを禁止することは今のところ出来なさそうです。

エンタープライズのレガシーなID管理のシナリオだと未だにCSV万能説な文化なので、パスワードに特定の文字を使えなくしたい、というニーズがそこそこあります。
例えば、「,」（カンマ）とか「”」（ダブルクォート）とか「’」（シングルクォート）とかですね。なぜなら、平文パスワードをCSVに載せてFTPで送りつける、ということをしようとすると、この辺りの記号が邪魔をするんですよね・・・。

この辺りに起因する不具合を防止するために、CTRL＋ALT＋DELを使ったパスワード変更をグループポリシーで禁止して、ID管理パッケージの持つパスワード管理画面からしかパスワードを変更させない様に構成、ID管理システムではパスワードに利用できない文字を定義する、というのが従来の王道パターンでした。

しかし、やはりWindowsの標準の仕組みでパスワード変更を許可したい、というニーズは根強く、各社パスワード・フック用のモジュールをリリースしていたり、という状況です。

当ブログでもほぼ10年前に紹介した「Active Directoryのパスワード変更をフックする」という記事へのアクセスが以外と息が長く、今でもアクセス数トップ3くらいには入っていたりして、何とかしてADのパスワードを引っこ抜いてやろう、という人々が数多く存在するんだな～（違）と感じている今日この頃です。


最近も某所でCSVにパスワードを出力したいからカンマを使えない様にしたい、と言う雑談をしていたりしたので、良し悪しはおいておいてちょっと書いてみました。

この辺りにおいてあります。
　https://github.com/fujie/pwdpol

Visual Studio 2017でC++のDLLを書く、というのも最近は中々無い経験なので新鮮な感じです。

ちゃちゃっと書いたので、エラーハンドリングやログ出力などもありませんし、Visual Studio 2017 on Windows 10 Proで作って、Windows Server 2012 R2で動作確認をしたので、VC++のランタイムのバージョンを合わせるのが面倒だったので、必要なDLL（msvcp140d.dll、vcruntime140d.dll、ucrtbased.dllの3つ）をC:\Windows\System32へコピーするとか強引なことをしてますが、皆さんはちゃんと必要なランタイムの再配布用パッケージをダウンロードして使ってください。

使い方は、ドメインコントローラ上で
・必要なDLLをC:\Windows\System32へ配置
・レジストリへの登録
・再起動
という3ステップですが、こちらは昔の記事と何も変わらないので、こちらをご参照ください。
https://idmlab.eidentity.jp/2018/06/azure-ad-ngad.html

こんなコードです。
＜本体：pwdpol.cpp＞

#include "stdafx.h"
#include <ntsecapi.h>
#include <regex>

#ifndef STATUS_SUCCESS
#define STATUS_SUCCESS ((NTSTATUS)0x00000000L)
#endif

using namespace std;

// initialize
BOOLEAN NTAPI InitializeChangeNotify(void) {
    return TRUE;
}

// evaluate filter
BOOLEAN NTAPI PasswordFilter(
    PUNICODE_STRING AccountName,
    PUNICODE_STRING FullName,
    PUNICODE_STRING Password,
    BOOLEAN SetOperation) {

    BOOLEAN ret;

    // filter in regular expression
    const wchar_t* pattern = LR"([\"\',])";

    // convert PUNICODE_STRING to wstring
    std::wstring pwd(Password->Buffer, Password->Length / sizeof(WCHAR));
    
    // search filtered charactors
    regex_search(pwd, wregex(pattern)) ? ret = FALSE : ret = TRUE;

    // clear buffer
    SecureZeroMemory((PVOID)pwd.c_str(), pwd.size());

    return ret;
}

// notify change
NTSTATUS NTAPI PasswordChangeNotify(
    PUNICODE_STRING UserName,
    ULONG RelativeId,
    PUNICODE_STRING NewPassword) {

    // nop
    return STATUS_SUCCESS;
}

＜定義：pwdpol.def＞

LIBRARY "pwdpol"
EXPORTS
    InitializeChangeNotify
    PasswordFilter
    PasswordChangeNotify

DLLの配置をして再起動すると上手くいけばポリシーが有効になります。
管理者がカンマを含むパスワードでリセットしようとしても

ユーザが自分でしようとしても、

ダメです。弾かれます。

これでパスワードをCSVに出力し放題です。何も気にすることはありません。どんどん出力してFTPでばらまきましょう。ファイルサーバにおいてCIFSで共有するのもいいアイデアです。

良い子はマネしちゃいけませんよ。

[Internet Weekフォローアップ]デモ環境の作り方③

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

前回に引き続きInternet Weekのフォローアップです。

今回はいよいよG Suite（Google Apps）とID連携を行い、SSO出来るようにしてみます。

• 第1回：環境の説明、OpenAMの認証を社内ADで行う
• 第2回：OpenAMのデータストアとして社内ADを利用する
• 第3回（今回）：OpenAMとG SuiteのID連携を行う
• 第4回：OpenAMでDesktop SSOを設定する
• 第5回：Azure ADとOpenAMと連携したままのG Suiteを連携する
• 第6回：G SuiteのID連携先をOpenAMからAzure ADへ切り替える

◆G Suite（旧Google Apps）とのID連携を設定する

いよいよ佳境です。

利用部門で勝手に契約したG Suiteを、勝手に立てたOpenAMと接続していきます。

OpenAMでは初めからG Suiteとの接続が組み込まれているため非常に簡単です。

　手順としては、

　＜OpenAM側＞

　　・OpenAMをSAML IdPとして構成する

　　・トラストサークルを作成する

　　・G SuiteをSAML SPとして登録しトラストサークルへ組み込む

　＜G Suite側＞

　　・OpenAM側のSSOサービスのエンドポイントとアサーション署名用の証明書を登録する

という非常にシンプルなものです。

順番に実施していきます。

・OpenAMをSAML IdPとして構成する

作成したレルムのトップ画面から[Create SAMLv2 Providers]をクリックしてSAML関連の設定画面を開きます。

OpenAM自体をSAML IdPにしたいので[Create Hosted Identity Providers]をクリックして開きます。

メタデータ設定のレルムに先ほど作成したレルムを選択し、名前にはhttpdでリバースプロキシしたURL（実際は任意なのでなんでもよい）、署名鍵は[test]を選択します。

※実際は署名用の証明書をちゃんと作って設定してください。

また、トラストサークルには「新しいトラストサークル」の欄に任意の名前を設定し、トラストサークルを作成します。

SAML IdPの設定が完了するとGoogle Appsの設定が出来ますので、ここで[Google Appsを設定する]をクリックしてGoogle Apps用の設定を行います。

Google Apps側のドメイン名を指定する箇所がありますので、「google.com/a/ドメイン名」という形で契約したドメイン名を指定します。

するとGoogle Apps側に指定すべきURLと署名検証に利用する証明書のダウンロードが出来る画面へ遷移しますので、それぞれの項目をメモ、ダウンロードしておきます。

・G SuiteへOpenAMの情報を登録する

ここまで来たらもう一息です。

先ほどメモしたOpenAMの情報をG Suite側のSSO設定画面へ登録していきます。

セキュリティの設定ページを開き、「サードパーティのIDプロバイダでSSOを設定する」にチェックを入れ、ログインページのURL、ログアウトページURL、パスワード変更URLのそれぞれに先にOpenAM上で取得したURLを設定していきます。

この際に注意なのですが、OpenAMはhttpdでSSL化およびリバースプロキシされているのでOpenAMのURLを読みかえてG Suite側へ設定する必要があります。

変更すべき点はhttp⇒https、およびポートが:8080⇒なしです。

例えば、

　　http://openam.adfs20.net:8080/openam

は

　　https://openam.adfs20.net/openam

となります。

また、[ドメイン固有の発行元を使用]にはチェックを入れておいてください。

・OpenAMで発行されるSAMLアサーションのNameIDをGoogle向けにカスタマイズする

ここまででID連携の設定は完了しているのですが、シングルサインオンを実現するには、社内ADから取得したID情報と、Google上のID情報のマッチング（紐づけ）が出来る必要があります。

Googleは識別子としてメールアドレスを要求していますので、社内AD上の属性よりメールアドレスを取得してGoogle向けの識別子（NameID）としてSAMLアサーションを構成してあげる必要があります。

OpenAMの管理画面の上部より[FEDERATION]メニューを開きます。

すると先に設定したSAML IdPがエンティティプロバイダとして出てきますので、クリックして設定を変更します。

具体的な変更箇所は[NameID値マップ]で初期状態では

　　urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified=uid

となっている行を削除して、

　　urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified=mail

を追加します。

これは、Googleからの認証要求としてNameIDのフォーマットがunspecifiedという指定が来るので、OpenAMはunspecifiedのフォーマットで値を返そうとします。その際に設定する値としてuidではなく、mail属性の値を入れてあげる、という設定です。

・G SuiteへOpenAMを使ってログインする

ここまでくるとG SuiteへのログインはOpenAMへリダイレクトされるようになっていますので、例えば「https://mail.google.com/a/カスタムドメイン名」へアクセスするとOpenAMのログイン画面が表示されます。

ここで社内ADのユーザ名とパスワードを入力すると認証が行われ、G Suiteのサービスが利用できるようになります。

ここまでで、野良認証システムと野良クラウドが情シスの全く感知しないところで構成できたわけです。

次回は後々情シスへ巻取りをしてもう、そして利用者が利便性高く使うためにはもう一工夫しておきます。テーマはDesktop SSOです。

[Internet Weekフォローアップ]デモ環境の作り方②

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

前回に引き続きInternet Weekのフォローアップです。

今回はOpenAMのデータストアとして社内ADを使えるようにしてみます。

• 第1回：環境の説明、OpenAMの認証を社内ADで行う
• 第2回（今回）：OpenAMのデータストアとして社内ADを利用する
• 第3回：OpenAMとG SuiteのID連携を行う
• 第4回：OpenAMでDesktop SSOを設定する
• 第5回：Azure ADとOpenAMと連携したままのG Suiteを連携する
• 第6回：G SuiteのID連携先をOpenAMからAzure ADへ切り替える

◆OpenAMのデータストアとして社内ADを指定する

前回までで認証は出来るようになりましたので、ユーザデータの格納場所（データストア）として社内ADを参照する様に設定を行います。この設定を行うことにより、認証が完了したのち、ユーザの属性を取得してSAMLアサーションに乗せる、などということが可能になります。（G Suiteとの接続時、メールアドレスをNameIdとして指定するので、この設定を入れておく必要があります）

実施することは先の認証モジュールに対して社内ADの情報を設定していったのとほぼ同様です。

まずは、左側のナビゲーションから[Data Stores]を開きます。データストアの設定画面はOpenAM 13からのモダンなUIではなく12までのクラシックなUIになっており、いきなり古臭い感じの設定画面が表示されます。

ここで、[新規]をクリックして新規データストアを作成してきます。

データストア名称は任意で問題ありませんが、タイプには[Active Directory]を選択しておきます。

認証モジュールの時と同じように社内ADに関する情報を設定していきます。

設定項目	設定値	備考
LDAP サーバー	dc.eidentity.adfs20.net	ドメインコントローラのFQDN。複数台設定することも可能
LDAP バインド DN	CN=test user01,OU=Users,OU=Managed Objects,DC=eidentity,DC=adfs20,DC=net	接続するユーザのDN。一般ユーザで問題なし
LDAP 組織 DN	OU=Users,OU=Managed Objects,DC=eidentity,DC=adfs20,DC=net	ユーザを格納していると思われるコンテナ
LDAP ユーザー検索属性	sAMAccountName	認証モジュールに指定した「ユーザープロファイルの取得に使用する属性」と同じ値
LDAP ピープルコンテナネーミング属性	空白	デフォルトの値を消す
LDAP ピープルコンテナ値	空白	デフォルトの値を消す
認証ネーミング属性	sAMAccountName	ログインIDとして使用するAD上の属性名
LDAP グループ検索属性	sAMAccountName	グループへの所属を探す際に利用する属性名（使用しないが、ログインIDの属性と合わせておく）
LDAP グループコンテナネーミング属性	空白	デフォルトの値を消す
LDAP グループコンテナ値	空白	デフォルトの値を消す
持続検索ベース DN	OU=Users,OU=Managed Objects,DC=eidentity,DC=adfs20,DC=net	ユーザを格納していると思われるコンテナ

ここまで設定が出来たら元から存在している[embedded]というデータストアを削除してしまいます。

対象のタブを開き、AD上のユーザ一覧が取得できていることを確認します。

ここで再度テストをしてみたいので、認証されたユーザとデータストア上のユーザが紐づいているかどうか確認するためにプロファイルの紐づけ設定を行います。

先に[無視]と設定したAuthenticationのSettingsのプロファイルタブです。

先ほどと同様にAD上のユーザで以下のURLよりログオンします。

　http://openamserver:8080/openam/XUI/#login/&realm=AD

すると今度はログイン後にユーザのプロファイルが表示されます。

これでOpenAMへのログインとユーザデータの取得を社内ADと連携することが出来ましたので、一旦先ほどのプロファイル紐づけを解除しておきます。G Suiteへのログイン時のアサーション取得を行う際にプロファイル紐づけをしておくとエラーが起きることがあるためです。単に属性のマッピングをさぼっているだけなんですが・・・

◆OpenAMをSSL化する

少し寄り道です。

ここまでのOpenAMの設定はデフォルトの8080番ポートでのhttpでtomcatへ直接接続してきました。ところが、後々一般ユーザへOpenAMの利用を開放しようとするとhttpsでのアクセスをきちんとさせておきたいところです。

そこで、OpenAMの前段にApacheのHTTPサーバを置き、mod_sslでhttps化を行った上で、mod_proxyを利用してOpenAMに対するリバースプロキシを構成します。

やることはいたってシンプルで、「yum install mod_ssl」でmod_sslを組み込み、証明書と秘密鍵をしかるべき手法で取得、サーバ上へ配置してssl.confの設定をしてhttpdへ読み込ませます。

ファイルを配置したのち、ssl.confに以下を設定しています。

　サーバ証明書

　　SSLCertificateFile /etc/pki/tls/certs/server.crt

　秘密鍵

　　SSLCertificateKeyFile /etc/pki/tls/private/server.key

また、リバースプロキシはhttpd.confに以下の設定を入れてすべての通信を単純にOpenAMへ流しています。

　ProxyRequests Off

　ProxyPass / http://openam.adfs20.net:8080/

　ProxyPassReverse / http://openam.adfs20.net:8080/

上手く設定できていれば、http://openamserver:8080/openamではなく、https:/openamserver/openam」でもログイン画面が表示されるようになるはずです。

次回はいよいよG Suiteと連携してみます。

[Internet Weekフォローアップ]デモ環境の作り方①

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

Internet Weekの資料と実施したデモの完成形の動画を先日公開させてもらいましたが、今回はデモ環境の作り方の説明です。

長いので以下のように分割してお届けしたいと思います。

• 第1回（今回）：環境の説明、OpenAMの認証を社内ADで行う
• 第2回：OpenAMのデータストアとして社内ADを利用する
• 第3回：OpenAMとG SuiteのID連携を行う
• 第4回：OpenAMでDesktop SSOを設定する
• 第5回：Azure ADとOpenAMと連携したままのG Suiteを連携する
• 第6回：G SuiteのID連携先をOpenAMからAzure ADへ切り替える

また、当日およびデモ動画ではOpenAM 12.0を使いましたが、さすがに古いので今回の手順はOpenAM 13.0をベースに再構成しています。（ほとんど手順は変わりませんが）

◆環境の説明

OpenAMサーバ）
　CentOS 7
　OpenAM 13.0　※Forgerock社のサイトよりダウンロード
　その他ミドルウェア：
　　Apache : yum install httpd
　　Apache mod_ssl : yum install mod_ssl
　　tomcat : OSバンドル
　　OpenJDK : OSバンドル

ドメインコントローラ）
　Windows Server 2016

PC）
　Windows 10 Pro
　ブラウザ : Internet Explorer 11

◆デモシナリオとゴール

これは当日お話ししましたが、

• 現場はSaaS（今回はG Suite。旧Google Apps）を導入したい
• 情シスは人手が足らないのでダメ

とういう対立構造の中で、現場が勝手（なるべく情シスにばれないように）にSaaS契約するが、なるべく管理の手間を減らしたい、というシナリオです。（今考えると酷いシナリオですね）

このシナリオでは現場の要件は、現場の担当者の少しの良心の元、以下の通りです。

• 利用者の利便性を上げたい
• IDとパスワードは情シスで管理しているADと合わせたい
• 出来るなら統合Windows認証でDesktopSSOしたい
• 後々情シスへ管理を移管する際に利用者の切り替えが発生しないようにしたい
• 退職者は使えないようにしたい
• IDの管理は情シスで管理しているADと合わせたい
• Google側のIDは個別で作っても良いが、最低限退職したら使えなければよい

これを実現するために今回のデモでは次の1～3にステップ分割してシステムを構成しています。

STEP１）
　フロントでとりあえず認証基盤を作ってクラウドサービス利用を開始
　OpenAMを構築、社内AD連携
　G Suiteを連携

STEP2）
　情シスがAzure ADを契約
　G SuiteをAzure ADへ追加
　SSOは既存認証システム（OpenAM）を利用する様に構成

STEP3）
　アプリを情シスが巻き取る
　G SuiteのSSOをAzure ADへ切り替え

では、早速始めていきます。

＜STEP 1＞

◆OpenAMの導入

まずはOpenAMを構築します。今回はデモなので雑に構成をしましたが、本番環境で使うときはちゃんと可用性なども考えて構成しましょう。

ダウンロードしてきたOpenAMのwarファイルをopenam.warというファイル名に変更してtomcatのwebappsディレクトリへ配置すると自動的にデプロイしてくれます。

デプロイ完了後、ブラウザで「http://openamserver:8080/openam」へアクセスするとセットアップ画面が表示されるので、デフォルト設定を作成してしまいましょう。

途中、デフォルトユーザのパスワードを設定するところでは管理者（amAdmin）のパスワードとポリシーエージェントユーザ（UrlAccessAgent）のパスワードは別のものを設定する必要があります。今回ポリシーエージェントは使わないので、こちらのパスワードは忘れてしまっても大丈夫です。

しばらくすると設定が完了するのでログインへ進みます。非常に簡単です。

管理者（amAdmin）でログインできればOKです。

◆社内ADを使った認証設定

社内のADで認証をするためには、OpenAMに以下の設定を行う必要があります。

• OpenAMが社内ADで認証する（認証モジュール設定）
• OpenAMが社内ADのユーザを参照する（データストア設定）

その前に、今回は情報システム部門と交渉が決裂しているので、なるべく情シスに知られることなく、上記を達成する必要があります。

となると、

• 自社のADサーバのホスト名
• ユーザ情報の格納場所

など一般に公開されていない事項も多々あります。

まずはそれらの情報を探索するところから作業を開始する必要があります。

・社内ADのFQDNを知る

社内ドメインに参加しているPCであればコマンドプロンプトから以下の環境変数の値からホスト名とドメイン名が取得できるので、ドメインコントローラのFQDNを知ることが出来ます。

• ホスト名：LOGONSERVER
• ドメイン名：USERDNSDOMAIN

この例では、FQDNが「dc.intra.ems.adfs20.net」であることが上記の結果よりわかります。


ただし、この方法では自分のPCがたまたまログインに使用していたドメインコントローラのホスト名しかわからないので、DNSを参照することにより他のドメインコントローラについても取得することが可能です。

具体的には、nslookupを利用してLDAPサービスを提供しているサーバをSRVレコードから探すことでドメインコントローラの一覧を割り出します。

検索対象のSRVレコードは「_ldap._tcp.DomainDnsZones.＜先のドメイン名＞」です。下記のスクリーンショットでは1台しかドメインコントローラがない環境なので1レコードしか出ていませんが、通常の環境であれば複数台のドメインコントローラが出てきます。

また、他の方法として探し出した最初の一台のドメインコントローラへLDAP検索をかける、という方法もあります。

通常のActive Directoryドメインであれば、ドメインコントローラのコンピュータオブジェクトは「OU=Domain Controllers,DC=ドメイン名」というコンテナ配下に配置されているはずなので、ここをBaseDNとしてobjectClass=computerフィルタをつけてオブジェクト一覧を探しだします。

使うクエリは以下の通りです。
注意点としてLDAPにsimple bindで接続するユーザのIDはAD上のDNではなく、userPrincipalNameを使う必要があります。（username@domainname形式）
　ldapsearch -h dc.intra.ems.adfs20.net -p 389 -D "naohiro.fujie@intra.ems.adfs20.net" -w P@ssw0rd -b "ou=Domain Controllers,dc=intra,dc=ems,dc=adfs20,dc=net" objectClass=computer cn

ここでコンピュータオブジェクトのDNおよびCNが取得でき、CNがコンピュータ名です。


・ユーザ情報の格納場所を探す

次に、認証する対象のユーザがドメインツリー上のどの場所（OU）に格納されているのかについて情報を収集します。

先のドメインコントローラを探す方法の最後に紹介したLDAPクエリをかける方法を使います。
今回はBaseDNに先ほど取得したドメイン名をドメインコンポーネント（DC）毎に分割した値を指定します。例えば、intra.ems.adfs20.netだったらdc=intra,dc=ems,dc=adfs20,dc=netとなります。

次に、コンテナの階層が下位に存在することを想定して検索Scopeにsubを指定し、下位のコンテナ（OUなど）の下も検索する様にします。

最後にfilterとして、自分自身のユーザ名（sAMAccountName）を指定します。今回はユーザオブジェクトが格納されているOUを探すことが目的なので、全てのユーザを取得しなくても自分だけわかればある程度推測できるためです。

例えば、以下のようなクエリを使います。
　ldapsearch -h dc.intra.ems.adfs20.net -p 389 -D "naohiro.fujie@intra.ems.adfs20.net" -w P@ssw0rd -b "dc=intra,dc=ems,dc=adfs20,dc=net" -s sub sAMAccountName=naohiro.fujie cn

この結果、自分自身のDNがわかりますので、格納されているコンテナが推測できます。上記の図の例だと、「OU=User,OU=AADObjects,DC=intra,DC=ems,DC=adfs20,DC=net」がユーザオブジェクトが格納されているコンテナだと思われます。


・OpenAMの認証モジュールとして社内ADを指定する

ここまでくれば後は、OpenAMに取得した社内ADの情報を指定していくだけです。ちなみに、OpenAMはADに対して検索さえできればドメイン管理者権限などは無くても認証設定を行うことが出来ます。（AD側でアクセスの監査などをしていると怪しいアクセス記録が残るので疑われはすると思いますが）

ということで、パスワードの有効期限さえ気を付けていれば利用部門の管理者の方の個人ユーザ権限でADに接続する様にOpenAMを構成してしまっても問題はありません。


まず、先にセットアップを行ったOpenAMへ管理者でログオンし、[New Realm]をクリックしてレルム（認証領域）を作成します。トップレベルのレルムに設定を行っても問題はありませんが、管理者ページへのアクセスを除外するなど設定が面倒になるので、新規にレルムを構成する方が後から楽です。

レルム名は任意のもので大丈夫ですが、ここでは[AD]という名称を付けています。

作成が終わるとレルムが表示されるので、クリックして開いて詳細な設定を入れていきます。

左側のナビゲーションから[Authentication]-[Modules]を開き認証モジュールの構成を行います。

ここでもモジュール名は任意で構いませんので、[AD]という名称を付けていますが、Typeの項目では[Active Directory]を選択する様にします。

ここで、先に取得したADの情報を入力していきます。

設定項目	設定値	備考
プライマリ Active Directory サーバー	dc.eidentity.adfs20.net	ドメインコントローラのFQDN。2台設定する場合はセカンダリドメインコントローラとして設定をすることも可能
ユーザー検索の開始 DN	OU=Users,OU=Managed Objects,DC=eidentity,DC=adfs20,DC=net	ユーザを格納していると思われるコンテナ
バインドユーザー DN	CN=test user01,OU=Users,OU=Managed Objects,DC=eidentity,DC=adfs20,DC=net	接続するユーザのDN。一般ユーザで問題なし
ユーザープロファイルの取得に使用する属性	sAMAccountName	後述するデータストアとのマッチングに使用する属性名
認証するユーザーの検索に使用する属性	sAMAccountName	OpenAMでのログインIDとして使用するAD上の属性名

次に認証チェインの設定を行います。OpenAMは認証モジュールを複数指定するプラグインモデルを採用しているので、実際に認証を行うためにどのモジュールを使うのかを認証チェインとして指定します。

左側のナビゲーションからChainsを開くと初期状態でldapServiceという認証チェインが設定されているので、ペンのアイコンをクリックして編集を行います。

初期状態でDataStoreが指定されているのですが、遠慮なく編集をしてしまいます。

設定画面の[Select Module]という項目で認証モジュールを選択することが出来るので、ここに先ほど作成した認証モジュール[AD]を指定して保存します。

これで認証設定は完了です。

いったんテストをしてみたいので、[Settings]-[ユーザプロファイル]を開き、ユーザプロファイルとの紐づけを[無視]に設定をします。まだデータストア設定をしていないので、認証後のデータストア内のユーザと紐づけることが出来ないためです。

ここまで来たら、ブラウザで
　　http://openamserver:8080/openam/XUI/#login/&realm=AD
へアクセスし、AD上のユーザ名とパスワードでログイン出来るかどうかの確認ができます。（URLの最後にrelam=ADという形で作成したレルム名をつけます）


うまくいくと画面上部に「You have been successfully logged in」というメッセージが表示されます。

長くなってきたので、今回はここまでです。
次回はデータストアの設定を行うところから開始します。

[Azure AD]Azure AD Domain Servicesが正式リリース（GA）

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

ちょうど1年前にPublic Previewが公開されたAzure AD Domain Services（AADDS）が正式にリリースされました。

　公式Blog
　#AzureAD Domain Services is now GA! Lift and shift to the cloud just got WAY easier!
　https://blogs.technet.microsoft.com/enterprisemobility/2016/10/12/azuread-domain-services-is-now-ga-lift-and-shift-to-the-cloud-just-got-way-easier/

◆AADDSとは何か

要するにオンプレミスのActive DirectoryのDomain ServiceがAzure VMで提供されている、というヤツです。Azure IaaS上のVNETにAADDSをくっつければ、VNETに紐づけたIaaS上のサーバをドメイン参加させたり、Express Route経由で社内とつなげば社内のPCやサーバも同じくドメイン参加ができるので、自前でドメインコントローラを持ちたくない小規模な企業にはおすすめ、というサービスです。

詳しくはPreview段階の記事ではありますが、山市良さんがアットマークITに書いてくれているので、そちら参照ということで。

　クラウドでもWindowsドメイン認証とグループポリシー管理が可能になる――Azure ADドメインサービス (1/3)
　http://www.atmarkit.co.jp/ait/articles/1511/06/news018.html

◆使用上の制限事項など

同じくPreview段階で確認した事項で、今回のGAでも解消はされなかった（おそらく永遠に解消されないと思いますが）制限事項として完全なるIaaSではないので、Domain Adminsグループそのものが利用者に公開されるわけではないので、「Domain Admins」というグループを必要とするサービスをメンバサーバにインストールすることが出来ません。

　[AzureAD]Azure AD Domain Servicesを使って既存サービスをクラウド上へ移行する際の注意事項
　http://idmlab.eidentity.jp/2015/10/azureadazure-ad-domain-services.html

もちろん他にもオンプレのドメインコントローラではできていたことがすべて実現できるわけではないので（サービスなので当然ですが）、十分に検証してから導入すべきでしょう。

◆Preview版からの強化点

公式アナウンスによると、以下の点がプレビュー時より強化されています。

• LDAPのサポート
• カスタムOUのサポート
• DNSの構成が可能に（普通にWindows DNSサーバの構成ツールが使える様に）
• Linuxのドメイン参加のサポート
• Azure ADテナントとの同期の改善
• パスワードを無期限にする属性のサポート
• Azure ADと同期時にグループ名がおかしくなる不具合の修正
• オンプレADとのSIDHistoryの同期
• VNET Peeringのサポート

特にオンプレADからSIDHistoryが同期できるのはありがたいですね。

今のオンプレドメイン完全撤廃の実現可能性も見えてきたりすると思います。

またおいおい触ってみたいと思います。

[Azure AD]AAD Connect Health for AD DSでオンプレミスのADを監視する

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

Azure Active Directory（Azure AD）やPing ONEをはじめとしたクラウド上のID基盤（IDaaS）が流行ってきていますが、どのソリューションも現状はオンプレミスにActive Directoryが存在していることを前提として構成が組み立てられています。

これは、2014年のVittorio Bertocci氏へのインタビューでもオンプレミスのActive Directoryの普及率は95%を超えている、という発言があるとおり、エンタープライズ分野へIDaaSを適用する際は既存のActive Directoryを避けて通れず、どのようにシームレスにオンプレミスからクラウドへ橋渡しをするか？がフォーカスされているため決して不自然なことではありません。

しかし、こうなってくるとクラウド側の基盤がグローバルでレプリケーションされていて高い可用性を持っていたとしても、システム全体を見た時にはオンプレミスのActive Directoryがボトルネックや障害発生ポイントとなってしまいます。

と、いうことでマイクロソフトはハイブリッドID基盤をなるべく一か所で監視・管理できるようにしたり、セキュアに運用できるように色々と関連ソリューションを出しています。

脅威／リスク	対象	ソリューション
稼働状況監視	AD FS	Azure AD Connect Health for AD FS
	AD DS	Azure AD Connect Health for AD FS
不正アクセス検知	AD DS	Advanced Threat Analytics
特権ID管理	AD DS	Microsoft Identity Manager 2016

今回は、新たにPublic Previewが公開されたAzure AD Connect HealthによるActive Directory（AD DS）の稼働状況のモニタリングについて見てみたいと思います。

　公式Blogでの発表
　Introducing #AzureAD Connect Health for Windows Server AD
　https://blogs.technet.microsoft.com/enterprisemobility/2016/07/19/introducing-azuread-connect-health-for-windows-server-ad/


仕組みとしては、監視用のエージェントをAzure PortalのAzure AD Connect HealthからダウンロードしてオンプレミスのAD DSサーバへインストール・構成するだけなので非常に簡単です。

◆エージェントを入手する

新ポータル（https://portal.azure.com）のダッシュボードにAzure AD Connect Healthがない人は追加しておきましょう。

Azure AD Connect Healthを開くとAgent for AD DSのダウンロードができるようになっていますので、Get toolsをクリックしてAgentモジュールをダウンロードします。

◆エージェントをインストールする

次は、監視対象のドメインコントローラへログインしてモジュールをインストールします。
ダウンロードしたモジュールをドメインコントローラへコピーしてインストーラを実行します。

この際、以下の前提事項があるので準備をしておいてください。。

• ドメインコントローラ上でビルトインアカウントによるInternet Exploreが実行できること
• microsoftonline.com、microsoftonline-p.com、micorosoft.com、windows.netのCookieを受け入れる設定になっていること（windows.netはいらないかも）
• Azure ADテナント上でグローバル管理者権限を持つ組織アカウント（マイクロソフトアカウントではなく）が存在していること
• ドメインコントーローラからAzureへの上り通信がブロックされていないこと

特に、Windows Server 2016では、IEの設定が厳しいのでCookieの受け入れの設定を確実にしておかないとエージェントのセットアップに失敗します。


ダウンロードしたファイルを実行すると、インストールが始まります。

インストール自体は非常にシンプルなのですぐに終わります。

◆エージェントを構成する

インストールが完了したらAzure ADのテナントへ接続し、エージェントを登録します。

うまくIEの構成がされていれば、Azure ADへのログインダイアログが起動してきますので、「組織アカウント」でログインします。（マイクロソフトアカウントだとエラーが出ます）

以下、エラーになった場合のメッセージです。
＜Cookieの受け入れ設定が出来ていない場合＞

＜マイクロソフトアカウントでログインした場合＞

うまく構成ができると、以下のメッセージが出ます。

◆ポータルより状態を監視する
インストールが完了するとドメインコントローラに関する情報がエージェントによりAzure AD Connect Healthへアップロードされます。

各種状態を確認することが出来ます。
＜FSMO、サイト、GCなど＞

＜機能レベルなどのプロパティ＞

＜認証要求数、レプリケーションステータスなど＞

ちなみに監視対象のドメインコントローラを停止すると以下のようにアラートが表示されます。
（検知するまでにしばらく時間がかかります）

これでHybrid ID基盤のオンプレミス側の構成要素であるAD DSの状態監視もクラウドから実行できますので、別途監視ツールや運用ツールを用意する必要性がぐっと下がりますので、安心して基盤の運用ができますね。