[Azure AD/Office365]Azure AD Connectでカスタムコネクタを使用する

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

先日公開したAzure AD ConnectとCDATA API Serverを組み合わせたSalesforce.comへのプロビジョニングや、3年ほど前に公開したAzure AD ConnectからOpenAMのレポジトリとして構成したOpenDJへのプロビジョニングの記事では、Azure AD ConnectのMicrosoft Identity ManagerのSynchronization Serviceとしての機能を使ってカスタムのコネクタ（ECMA2エージェント）や組み込みのGeneric LDAP Connectorを使って「無理やり」、ADやAzure AD以外のシステムとの同期を実現していました。
※Azure AD ConnectにGeneric LDAP Connectorなどが同梱され始めたのは1年くらい前ですね。

実はこの構成、オフィシャルに公開されていなかっただけで、Premierサポートとの契約があれば使うことは出来たんですが、なかなかハードルが高いので、これまであまり言及してきませんでした。

しかし、Azure Active Directory PoCプレイブックの中に、しれっとGeneric LDAP Connectorを使ったオンプレミスLDAPとAzure ADの同期のシナリオが記載されていることに気が付いてしまいました（笑）

Generic LDAPコネクタ構成
https://docs.microsoft.com/ja-jp/azure/active-directory/active-directory-playbook-building-blocks#generic-ldap-connector-configuration

流石に、こんな注意書きが添えられていてハードルを上げまくっています。まぁ、やってみるとそれほど難しくはありませんが。

これは高度な構成で、FIM/MIM に関する知識を必要とします。 運用環境で使用されている場合、この構成に関するご質問については、Premier サポートを使ってお問い合わせください。

Azure AD ConnectがGAしたタイミングで公開されたドキュメントに書いてある構成が徐々に実現してきている、ということですね。

ちなみに以下のドキュメントを見ると、オンプレミスのLDAPなどへAzure AD Connectを使って接続する構成はFR（今後サポート）となっており、正式にサポートされたわけではないので、実際に利用する場合はPremierサポートと十分に協議をすることをお勧めします。

ハイブリッド ID ディレクトリ統合ツールの比較
https://docs.microsoft.com/ja-jp/azure/active-directory/active-directory-hybrid-identity-design-considerations-tools-comparison

[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

[Office365/AzureAD]OpenAMとのID連携③

注意事項）
今回のポストでの構成内容は非サポートの構成を含んでいますので、実環境への適用は避けてください。動作上、ライセンス上の問題が発生しても当方は責任を負いかねます。また、本稿はForefront Identity Manager（FIM）に関する知識をある程度持っている方を対象として書いていますので、細かいFIMの使い方については本blogの他のポストなどを参考にしてください。

ここまでシングルサインオンを中心にOpenAMを使ったOffice365とのID連携（フェデレーション）の解説をしてきましたが、今回はそのバックエンドのプロビジョニングについて解説します。

これまでのポスト
・[Office365/AzureAD]OpenAMとのID連携①
・[Office365/AzureAD]OpenAMとのID連携②

今回も全体の図の中で枠線で囲っている部分の解説をしていきたいと思います。

AADSyncを使ってオンプレミスのAD DS上のアカウントをAzureADおよびOpenAMのレポジトリであるOpenDJにプロビジョニングしています。
早速構成していきましょう。

◆OpenAMのユーザとOffice365のユーザを紐づけるための準備
最初に大前提として、Office365とのID連携を実現するためには「SAML AsserionとAzureAD上のユーザの以下の属性が一致すること」が必要となります。

属性名		属性値
SAML Assertion	AzureAD
NameID	ImmutableId	任意の値（AD FS/AADSync構成の場合の初期値はAD DS上のアカウントのObjectSidをBase64エンコードした値）
IDPEmail	UserPrincipalName	メールアドレス形式の値（AD FS/AADSync構成の場合の初期値はAD DS上のアカウントのUserPrincipalName属性の値）

通常AD FS/AADSync（もしくはDirSync）を使うと自動的に上記要件を実現する様に設定が行われますが、今回はAD FSの代わりにOpenAMをIdentity Provider（IdP）として使いますので、OpenAMがSAML Assertionとして発行する値とAzureAD上のユーザの属性を一致させるように、OpenAMのユーザレポジトリであるOpenDJおよびAzureADを構成する必要があります。

IDPEmailについては既に前回OpenAMのリモートサービスプロバイダーを設定する際にIDPEmailとOpenAMのmail属性をマッピングするように設定をしてありますので、追加の設定は不要ですので、NameID/ImmutableIdの値をどうするか考える必要があります。
通常、AD DSアカウントを使うのでObjectSid属性を元にImmutableIdを生成しAzureADへプロビジョニングすることになるのですが、OpenAMのレポジトリであるOpenDJにAD DSのObjectSidを持っていくのもナンセンスなので、今回は簡易的になりますが、AD DS上のsAMAccountName属性とOpenDJ上のuidとAzureAD上のImmutableIdにマッピングすることでOpenAMとAzureADが共通の値を使えるようにします。

◆AzureADとの同期設定
何はともあれAADSyncをダウンロードしてセットアップします。

　ダウンロードページ（2014/12/18に最新版がリリースされています）
　http://www.microsoft.com/en-us/download/details.aspx?id=44225

セットアップを行う際、AzureADとAD DSのアカウントのマッチングに関する設定を行う画面が出てきますので、ここを以下のように設定します。
・sourceAnchor attribute : sAMAccountName
・userPrincipalName attribute : mail

このsourceAnchorがAzureAD上のImmutableIdと紐づく属性となるので、先に述べたようにsAMAccountNameを設定します。また、userPrincipalNameについては.localなどのローカル名前空間でAD DSを構成している環境においてはAzureADのメールアドレスと正しく紐づかないので、別属性（ここではメールアドレス属性）にAzureAD上のメールアドレスの値を設定することにします。

◆OpenDJとの同期設定
まず、AADSyncはAD DSとAzureADの同期しかサポートされませんので、当然のことながらそのままではOpenDJにユーザをプロビジョニングすることはできません。
そこで、非サポートですがForefront Identity Manager（FIM）用のGeneric LDAP Connectorを無理やりAADSyncで使えるように構成します。

　Generic LDAP Connector for Forefront Identity Managerのダウンロードページ
　https://www.microsoft.com/en-us/download/details.aspx?id=41163

無理やり、と言っても基本的にDirSyncもAADSyncもエンジンはFIM Synchronization Serviceなので、コネクタをインストールしてフォルダ構成を合わせれば認識してしまいます。

Generic LDAP Connectorをインストールすると実体のDLLは以下のフォルダに展開されます。
　C:\Program Files\Microsoft Azure AD Sync\Synchronization Service\Extensions

これをAADSyncが利用するコネクタ用のフォルダへコピーします。
　C:\Program Files\Microsoft Azure AD Sync\Extensions

同様にパッケージコネクタの定義ファイルもコピーします。
　元）C:\Program Files\Microsoft Azure AD Sync\Synchronization Service\UISHELL\XMLs\PACKAGEDMAs
　先）C:\Program Files\Microsoft Azure AD Sync\UIShell\XMLs\PackagedMAs

後は、Synchronization Managerから管理エージェントを作成し、Run Profileを定義します。
作成するRun ProfileはとりあえずFull Import/Delta Import/Full Synchronization/Delta Synchronization/Exportで大丈夫です。

諸々の設定が終わると、こんな状態になります。

後はAADSyncのSynchronization Rules Editorを使って属性のマッピングを行うのですが、その前に一つ大事な考慮事項があります。
AzureADとOpenAMのID連携設定を行うと、AzureADからOpenAMへ以下の認証要求がSAMLプロトコルで飛んできます。

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
                    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
                    ID="_142f225c-9a69-4f38-b585-ba4956b17e32"
                    IssueInstant="2014-12-25T06:49:39Z"
                    Version="2.0"
                    AssertionConsumerServiceIndex="0"
                    >
    <saml:Issuer>urn:federation:MicrosoftOnline</saml:Issuer>
    <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" />
</samlp:AuthnRequest>

重要なのはこの要求の中のNameIDPolicy Formatの部分です。
意味合いとしては「Office365/AzureADにログインするには"urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"というフォーマットでNameIDを発行して欲しい」、ということなので、OpenAM側で該当するフォーマットでアサーションを発行してあげるように設定する必要があります。
もちろんOpenAMの全体設定として必ず当該フォーマットでの認証要求があったらNameIDの値に特定の値（ここではuid）を渡す、という設定を行うことも可能ですが、あまりにも汎用性がない構成となってしまいますので、AzureADからの"urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"形式での要求があった場合にはuidの値をNameIDとして発行する、という設定を行いたいと思います。

OpenAMでは上記のようなSP毎に発行するNameIDの値を定義するために、ユーザの以下の属性を使います。
※OpenAMの前身であるOpenSSOの更に前身であるSun Access Managerの時代を彷彿とさせる属性名です。
・sun-fm-saml2-nameid-info
・sun-fm-saml2-nameid-infokey

それぞれの属性には以下のような値を設定する必要があるので、AADSyncのExpression Ruleでマッピングを定義します。

属性	値	例
sun-fm-saml2-nameid-info	"OpenAMのIdP EntityID"|"SP(AzureAD)のEntityID"|"発行する値"|"OpenAMのIdP EntityID"|"NameID Format"|"発行する値"|"SP(AzureAD)のEntityID"|IDPRole|false	https://openam.example.com/OpenAM-11.0.0|urn:federation:MicrosoftOnline|kenshinu|https://openam.example.com/OpenAM-11.0.0|urn:oasis:names:tc:SAML:2.0:nameid-format:persistent|kenshinu|urn:federation:MicrosoftOnline|IDPRole|false
sun-fm-saml2-nameid-infokey	"OpenAMのIdP EntityID"|"SP(AzureAD)のEntityID"|"発行する値"	openam.example.com/OpenAM-11.0.0|urn:federation:MicrosoftOnline|kenshinu

また、上記属性を使うため、OpenDJ上のアカウントのスキーマ（objectClass）設定として以下を設定します。
・inetOrgPerson
・inetUser
・sunFMSAML2NameIdentifier

AADSyncのSynchronization Rules Editorでマルチバリュー属性を設定する場合は面倒ですが、複数のルールを定義し、joinをしていく必要があるので、追加するobjectClassの値ごとにルールを追加します。


ここまでを踏まえて定義したルールが以下です。
①ベースの作成

ページ	設定
Description	項目	値
	Name	Out to OpenDJ - Base Identity
	Connected System	OpenDJ
	Connected System Object Type	inetOrgPerson
	Metaverse Object Type	person
	Link Type	provision
	Soft Delete Expiry Interval	0
	Precedence	0
Scoping filter	Attribute	Operator	Value
	mail	ENDSWITH	@example.com
Transformations	FlowType	Target Attribute	Source	Apply Once	Merge Type
	Expression	dn	uid=" & [accountName] & ",ou=people,dc=example,dc=com	○	Update
	Direct	sn	sn	-	Update
	Direct	givenName	givenName	-	Update
	Direct	mail	mail	-	Update
	Constant	userPassword	P@ssw0rd	○	Update
	Expression	sun-fm-saml2-nameid-info	https://openam.example.com/OpenAM-11.0.0|urn:federation:MicrosoftOnline|" & [accountName] & "|https://openam.example.com/OpenAM-11.0.0|urn:oasis:names:tc:SAML:2.0:nameid-format:persistent|" & [accountName] & "|urn:federation:MicrosoftOnline|IDPRole|false	○	MergeCase
	Expression	sun-fm-saml2-nameid-infokey	"openam.example.com/OpenAM-11.0.0|urn:federation:MicrosoftOnline|" & [accountName]	○	MergeCase
	Constant	objectClass	inetOrgPerson	○	MergeCase
	Direct	cn	cn	-	Update

尚、objectClass、sun-fm-saml2-nameid-info、sun-fm-saml2-nameid-infokey属性はOpenDJ上でマルチバリュー属性となっているのでMergeTypeはMergeCaseを設定する必要があります。

②objectClassの追加（inetUser）

ページ	設定
Description	項目	値
	Name	Out to OpenDJ - objectClass inetUser
	Connected System	OpenDJ
	Connected System Object Type	inetOrgPerson
	Metaverse Object Type	person
	Link Type	join
	Precedence	0
Transformations	FlowType	Target Attribute	Source	Apply Once	Merge Type
	Constant	objectClass	inetUser	○	MergeCase

③objectClassの追加（sunFMSAML2NameIdentifier）

ページ	設定
Description	項目	値
	Name	Out to OpenDJ - objectClass sunFMSAML2NameIdentifier
	Connected System	OpenDJ
	Connected System Object Type	inetOrgPerson
	Metaverse Object Type	person
	Link Type	join
	Precedence	0
Transformations	FlowType	Target Attribute	Source	Apply Once	Merge Type
	Constant	objectClass	sunFMSAML2NameIdentifier	○	MergeCase

ここまでで設定が完了するので、AADSyncを使ってAD DS上のユーザをAzureADおよびOpenDJへ実際に同期をしてみます。

◆AD DS上のユーザ作成と同期の実行
今回、ローカルドメイン（.local）としてAD DSを作成したので、userPrincipalNameの代わりにメールアドレスを使う設定を行いましたので、ユーザのメールアドレス属性にAzureADで使うメールアドレスを設定します。

これで準備が整ったので、タスクスケジューラ上のAADSyncスケジュールを有効化して実行します。
尚、OpenDJへの同期についてはAADSyncのスケジューラには組み込まれていませんので手動で実行します。

結果、OpenDJ上に以下のようなユーザが作成され、OpenAMでOffice365/AzureADへシングルサインオン出来るようになります。

dn: uid=kenshinu,ou=people,dc=example,dc=com
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
objectClass: inetUser
objectClass: top
objectClass: sunFMSAML2NameIdentifier
givenName: Kenshin
uid: kenshinu
cn: Kenshin Uesugi
sun-fm-saml2-nameid-info: https://openam.example.com/OpenAM-11.0.0|urn:
 federation:MicrosoftOnline|kenshinu|https://openam.example.com/OpenAM-
 11.0.0|urn:oasis:names:tc:SAML:2.0:nameid-format:persistent|kenshinu|urn:federa
 tion:MicrosoftOnline|IDPRole|false
sn: Uesugi
userPassword: {SSHA}udJ1bXXYdNu2KlpMgXseHxSQnum7i6weFAndjw==
mail: kenshinu@example.com
sun-fm-saml2-nameid-infokey: openam.example.com/OpenAM-11.0.0|urn:fede
 ration:MicrosoftOnline|kenshinu

繰り返しになりますが、今回はAADSyncを使いましたが、Forefront Identity Managerを使えばちゃんとサポートされた構成を作ることが出来ますので、マネはしないでください。
ただ、今後AADSyncでも他のレポジトリとの同期をサポートしていく予定もあるようなので、Synchronization Rules Editorの使い方を中心にAADSyncの使い方をマスターしておくと良いと思います。

参考）Directory Integration Tools（DirSync/AADSync/FIMの機能比較）
　http://msdn.microsoft.com/en-us/library/azure/dn757582.aspx

このページを見るとAADSyncでは様々な機能がCS（Comming Soon）となっており、DirSyncやFIMがAADSyncに統合されていく姿が見えてくると思います。

と、言うことで今後もAADSyncについては目が離せませんね。


尚、今回まででOpenAMを使ったOffice365とのID連携については終わりですが、次回以降で最初の全体構成図の他のパートについても解説をしていこうと思います。

[FIM2010]ECMA2.2と各種対応コネクタがベータリリース

そう言えば先日の FIM2010 R2 用の SP1 と共に 2.1 へとバージョンが上がった EMCA（Extensible Connectivity：拡張管理エージェント）ですが、早くも 2.2 のベータ版が Connect サイトに上がっています。

https://connect.microsoft.com/site433/Downloads/DownloadDetails.aspx?DownloadID=48615
※要登録

今回のバージョンの目玉はなんといっても「同期エンジンなしで実行できる様になったこと」です。この機能により、Visual Studio を使って単体で管理エージェントのテストやデバッグを実行できるようになりました。

他にも、
・コネクタを作成する際、機能のロードをユーザに情報を入れさせてから実行できるようになった。（例えば、SQL Server などから動的にスキーマを取得するようなコネクタを作ろうとした場合、これまでは SQL Server へ接続するユーザ情報を入力する前に機能をロードしようとして失敗していた）
・アンカー属性として LDAP の DN 形式をサポートした。
・delta import の際に object type の更新/削除できなくした。
という拡張がされています。


また、同時に EMCA2.2 に対応した以下のコネクタのベータ版もリリースされています。
・PowerShell MA
　もともと MCS(Microsoft Consulting Service)が個別で開発して使っていたコネクタのようですが、製品としてリリースされることになりました。
・SharePoint User Profile MA
　SharePoint のユーザプロファイルを管理するコネクタです。
・Generic LDAP MA
　汎用の LDAP コネクタです。XMA1.0 のサポート終了に伴い、コミュニティベースで公開されていた OpenLDAP XMA の代わりに使うことになりそうです。

最近特に FIM 関連の製品更新が多いので、なかなかついていけてません。。。

どうなる？Sun IdM ( 2010/1/30 追記 )

2010/1/30更新

SunのシニアソフトウェアアーキテクトのSébastien Stormacq氏のblogにまとまっているので少々修正です。（@tkudoさんに感謝）

そろそろ眠気がピークですが、なんとかIdM部分だけは、、と思って頑張ってます。

というわけで、日本時間1/28 2:00-7:00という極東に住んでいることを後悔するようなスケジュールで開催されている「Oracle + Sun Strategy Update」ですが、IdM部分について軽く紹介しておきます。
（眠いので間違っている可能性ありです。気づいたら直します）

結果から書きますが、基本的な方針としては「Oracle製品に統合」です。
















細かく分野ごとに見ていくとこんな感じです。

分野	方針	旧Sun製品	Oracle製品
Directory Services	Oracle Internet DirectoryとSun Directory Serverの両方をサポートする。OpenDSへの投資は継続する。	Sun Java System Directory Server	Oracle Internet Directory
Role Management	Sun Role ManagerはSuiteから切り出されてIdentity Analyticsへ	Sun Role Manager	Oracle Role Manager
Provisioning/Lifecycle Management	Oracle Identity Managerを戦略製品として継続させる。Sun Identity ManagerはSPMLアダプタとしてOracle Identity Managerへ統合される。Sun Identity ManagerはOracle Wavesetへリネーム。Sun Identity Managerからのマイグレーションツールを提供する予定。	Sun Identity Manager	Oracle Identity Manager
Access Management	Oracle Access Managerを戦略製品として継続させる。OpenSSOからのマイグレーションツールを提供する予定。OpenSSO STS機能を取り込みエンハンス。	OpenSSO	Oralce Access Manager
Virtual Directory	Oracle Virtual Directoryを戦略製品として継続させる	Sun Java System Directory Server EE	Oracle Virtual Directory
eSSO	Oracle Enterprise Single Sign-On Plusを戦略製品として継続させる	-	Oralce Enterprise Single Sign--On Plus
権限管理（Entitlement Management）	Oracle Entitlements Serverを戦略製品として継続させる	-	Oracle Entitlements Server
Identity Federation	Oracle Identity Federationを戦略製品として継続させ、OpenSSOのfedletを取り込む。OpenSSOからのマイグレーションツールを提供する予定。	OpenSSO	Oracle Identity Federation

※ちなみにSun Java System Directory Server Enterprise Editionに入っていたIdentity Synchronization for Windowsはどうなるんだろう？？LDAP-ADのお手軽同期ツールとしては良かったんですけどねぇ。

尚、サポートに関しては統合後も継続されるようですので、既存ユーザは保護されるようです。

とりあえずまた追加情報などあればアップデートしていきます。

ILM/FIMとRODC

ILM2007がWindowsServer2008環境に対応という話はILMチームのblogにあがっていましたが、RODCがいた場合ってどうなっちゃうのかな？というのが今回の実験です。

結論から言うと、RODCに対して更新クエリを投げた場合はreferral(紹介：「自分はダメなので他を紹介します！」）が返ってきてエラーになります。
一般的なLDAPクライアントはだいたいreferral対応の実装をするものなのですが、ILM（MIIS）は対応していないことが原因です。（ちなみにldp.exeはOK）

こんな感じで進めました。

■設定
ADMAのConfigure Directory Partitions画面でDomain controller connection settingsの中の
Only use preferred domain contorollersにチェックを入れます。














このPreferred Domain ControllersにはRODCが指定されています。

















■テスト
この状態でADへのExportを実行するとこのようにcd-errorが返ってきます。
















具体的なエラー内容を見ると、見事に「紹介」が返ってきています。















ちなみにPreferred Domain Contorollersの設定を変更して普通の2008DCにするとちゃんと更新が成功します。
















ということで、RODCが存在する環境下ではRODCを見に行かないようにPreferred Domain Controllers設定をきちんと行う必要があります。

ActiveDirectoryのunicodePWDをLDAPSで変更する

とあるIdM製品ベンダの知り合いの方から「ADのunicodePWD属性ってLDAPSで変更できますよね？」と言われて、そういえば以前やったことあるな～というのを思い出しました。
　
3年ほど前に別blogに書いたネタがあるので転記しておきます。（いささか古いネタなので最近の環境での動作は微妙？）

■タイトル
　ActiveDirectoryのunicodePWD属性の変更をSolarisから行なう
■内容とサンプルスクリプト（当時のまま転記）

簡単に書くと、
１．サーバ証明書の発行（Windows証明書サービスで実施）
２．証明書をSolarisへインストール
３．Perl等のスクリプトでLDAPS接続して属性更新
となる。
注意点は、Windowsで証明書を発行する際に「Webサーバ」のテンプレートを使用して証明書を発行することくらい。

尚、必要物は以下のとおり。
【Windows側】
・ActiveDirectory
・証明書サービス
・IIS（証明書サービス用）
【Solaris側】
・OpenSSL
・Perl::LDAPSモジュール

【サンプルPerlスクリプト】
#!/usr/bin/perl -wuse strict;
use Net::LDAPS;

my($Ad, $mesg, $uid, $pass, $npass, $dn, $rtn);
$uid = "test";
$pass = "hoge";

print "Trying to set $uid to password $pass\n\n";
# Bind to the AD server
$Ad = Net::LDAPS->new("server.hoge.local",port => 636,capath => '/usr/local/ssl/certs/cacert.pem') or print "error connecting ad\n", exit 2;
$Ad->bind("CN=Administrator,CN=Users,DC=hoge,DC=local",password=>"password") or print "Unable to bind to AD server\n", exit 2;

# Do a AD lookup to get the dn for this user
# then change their password.
$mesg = $Ad->search(base => "ou=test,dc=hoge,dc=local", scope => "sub", filter => "(CN=test)");
if($mesg->count != 1) {
print "AD lookup failed for user $uid\n";
exit 3;
}
$dn = $mesg->entry(0)->dn;
map { $npass .= "$_\000" } split(//, "\"$pass\"");
print $dn;
$rtn = $Ad->modify($dn,replace=>["unicodePwd",$npass]);
if($rtn->{'resultCode'} != 0) {
print "User $uid, setting password failed\n";
exit 2;
}
print "Password for $uid changed in AD\n";
exit 0;