ラベル Forefront Identity Manager の投稿を表示しています。 すべての投稿を表示
ラベル Forefront Identity Manager の投稿を表示しています。 すべての投稿を表示

2017年9月20日水曜日

[FIM/MIM]Forefront Identity Managerのメインストリームサポートは2017年10月10日まで

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

そういえばForefront Identity Manager 2010/2010 R2/2010 R2 SP1のメインストリームがもうすぐ終了します。
https://blogs.technet.microsoft.com/iamsupport/2017/02/22/warning-forefront-identity-manager-fim-mainstream-support-is-ending-10102017/



まだFIMを使っている人もいないとは思いますが、まだの場合はMicrosoft Identity Managerへのアップデートが必要ですね。
MIMが出たての頃はアップデートするのにかなり苦労しましたが、最近はちゃんと設定関係の引継ぎもできるようになっているので、ぜひアップデートしましょう。

ちなみに拡張サポートは2022年10月11日までですが、バグフィックスなどの提供がベストエフォートになってしまいますので、自己責任運用になりますね。

ちなみに私の開発環境の一部がまだFIMなので・・・・面倒だけどこの際アップデートします。

2017年8月23日水曜日

[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



2017年8月14日月曜日

APIゲートウェイでSaaSのIDを簡単に管理する②

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

前回に引き続き、CDATA API ServerとID管理システムを使ってSaaS(今回はSalesforce.com)へのプロビジョニングを簡単に行う、という仕組みを作っていきます。

前回は、API ServerをSalesforce.comのUserテーブルへ接続し、ユーザの取得をしましたが、今回はいよいよID管理システム(今回はAzure AD Connect)を使ってユーザを作成します。

やることは非常に単純で、API Serverで定義されたリソース(実際はSalesforce.comのUserテーブル)に対してJSON形式で作成したいユーザの情報をPOSTするだけです。

◆投げ込むJSONを確認する

Salesforce.comの開発者ドキュメントを見ると、Userテーブルに新規レコード(つまり新規ユーザ)を作成する際に必須となる属性を確認します。

 SOAP API開発者ガイド)User
 https://developer.salesforce.com/docs/atlas.ja-jp.api.meta/api/sforce_api_objects_user.htm

これを見ると、以下の属性が必須との事です。
  • Username :ユーザ識別子。メールアドレス形式
  • Alias :ユーザの別名
  • Email :ユーザのメールアドレス
  • LastName :ユーザの姓
  • EmailEncodingKey :メールの文字コード
  • LanguageLocaleKey :ユーザの言語
  • LocaleSidKey :ユーザのロケール
  • ProfileId :ユーザのプロファイルのID
  • TimeZoneSidKey :ユーザのタイムゾーン
  • UserPermissionsOfflineUser :オフラインエディションの使用可否
  • UserPermissionsMarketingUser :キャンペーン管理の可否

ユーザを作成するには、最低限これらの値をJSON形式でAPI ServerのリソースへPOSTすればよい、ということなので、まずは直接POSTしてみます。

ただ、EmailEncodingKeyやProfileIdなど、何を値として設定すれば良いのかよくわからない属性もあるので、まずはSalesforce.com上に手動で作成したユーザをGETし、各属性にどのような値が入っているのかを確認すると以下のような値が入っていることがわかるので、この例をテンプレートにPOSTするデータを作成します。

属性
Usernamexxxxx@example.com
AliasFujie
Emailxxxxx@example.com
LastNameFujie
EmailEncodingKeyISO-2022-JP
LanguageLocaleKeyja
LocaleSidKeyja_JP
ProfileId(Chatter Free Userの場合)00e7F000001LotXQAS
TimeZoneSidKeyAsia/Tokyo
UserPermissionsOfflineUserfalse
UserPermissionsMarketingUserfalse


以下のようなJSONを作成し、Chrome ExtensionのAdvanced REST Clientを使ってAPI Serverに定義したリソースエンドポイントへPOSTをします。
{
  "Username": "test999@eidentity.jp",
  "Alias": "test999",
  "Email": "test999@eidentity.jp",
  "LastName": "Test",
  "EmailEncodingKey": "ISO-2022-JP",
  "LanguageLocaleKey": "ja",
  "LocaleSidKey": "ja_JP",
  "ProfileId": "00e7F000001LotXQAS",
  "TimeZoneSidKey": "Asia/Tokyo",
  "UserPermissionsOfflineUser": "false",
  "UserPermissionsMarketingUser": "false"
}


上手くいくと、HTTP 201 Createdが返ってきて実際にユーザが作成されます。


Salesforce.comの管理画面からユーザを確認すると実際に作成されていることがわかります。


◆管理エージェントの作成

投げ込むJSONがわかったところで、あとはID管理システムでJSONの生成からPOSTを自動化するだけです。

やることはFIM/MIM向けのECMA2エージェントとして以前公開したGeneric REST API Management Agentとよく似たようなことなので、このコードをカスタマイズしてみます。

細かいECMA2エージェントの開発方法は別エントリでそのうち解説しますが、以下の手順でGeneric REST API Management Agentを改造します。

1.スキーマ定義(GetSchemaメソッド)
 先にリストアップした必須属性を定義します。Username属性をAnchor属性として設定をしています。こんなコードになります。
                SchemaType personType = SchemaType.Create("Person", false);
                personType.Attributes.Add(SchemaAttribute.CreateAnchorAttribute("Username", AttributeType.String));
                personType.Attributes.Add(SchemaAttribute.CreateSingleValuedAttribute("Alias", AttributeType.String));
                personType.Attributes.Add(SchemaAttribute.CreateSingleValuedAttribute("Email", AttributeType.String));
                personType.Attributes.Add(SchemaAttribute.CreateSingleValuedAttribute("LastName", AttributeType.String));
                personType.Attributes.Add(SchemaAttribute.CreateSingleValuedAttribute("EmailEncodingKey", AttributeType.String));
                personType.Attributes.Add(SchemaAttribute.CreateSingleValuedAttribute("LanguageLocaleKey", AttributeType.String));
                personType.Attributes.Add(SchemaAttribute.CreateSingleValuedAttribute("LocaleSidKey", AttributeType.String));
                personType.Attributes.Add(SchemaAttribute.CreateSingleValuedAttribute("ProfileId", AttributeType.String));
                personType.Attributes.Add(SchemaAttribute.CreateSingleValuedAttribute("TimeZoneSidKey", AttributeType.String));
                personType.Attributes.Add(SchemaAttribute.CreateSingleValuedAttribute("UserPermissionsOfflineUser", AttributeType.Boolean));
                personType.Attributes.Add(SchemaAttribute.CreateSingleValuedAttribute("UserPermissionsMarketingUser", AttributeType.Boolean));
                Schema schema = Schema.Create();
                schema.Types.Add(personType);
                return schema;

 こうすることで管理エージェントで管理対象属性を選択できるようになります。


2.パラメータ定義(GetConfigParametersメソッド)
 API Server上のリソースURIや接続に使うAPI ServerユーザのAuthTokenを指定できるようにします。こんなコードになります。接続パラメータの部分だけで良いのでConnectivityの部分にパラメータを追加しています。
                switch (_page)
                {
                    case ConfigParameterPage.Capabilities:
                        break;
                    case ConfigParameterPage.Connectivity:
                        _configParametersDefinitions.Add(ConfigParameterDefinition.CreateLabelParameter("Connection parameters"));
                        _configParametersDefinitions.Add(ConfigParameterDefinition.CreateStringParameter(ConstDefinition.CFG_RESOURCE_URI, ""));
                        _configParametersDefinitions.Add(ConfigParameterDefinition.CreateStringParameter(ConstDefinition.CFG_AUTH_TOKEN, ""));
                        break;
                    case ConfigParameterPage.Global:
                        break;
                    case ConfigParameterPage.Partition:
                        break;
                    case ConfigParameterPage.RunStep:
                        break;
                    case ConfigParameterPage.Schema:
                        break;
                }

尚、テストなので、ValidateConfigParametersについては処理を入れておらず、指定されたパラメータの値の確認などは行っていません。

これで、管理エージェント設定画面で接続関連のパラメータを指定することが出来るようになります。ここにAPI ServerのリソースURIとAuthTokenを指定します。

3.インポート処理関連(OpenImportConnection/GetImportEntriesメソッド)
 まずはOpenImportConnectionで、設定パラメータからリソースURIとAuthTokenの値を取り出し、後続のGetImportEntriesで使えるようにグローバル変数にセットしておきます。
                resource_uri = _configParameters[ConstDefinition.CFG_RESOURCE_URI].Value.ToString();
                auth_token = _configParameters[ConstDefinition.CFG_AUTH_TOKEN].Value.ToString();

 次に、API Server(を経由してSalesforce.com)からユーザ情報を取得するGetImportEntriesです。やることはシンプルで、API ServerのリソースURIへAuthToken付きのGETリクエストを投げ、取得したJSONをパースしてConnector Space上のエントリに追加していくだけです。尚、本来はページング処理などをする必要があるのですが、今回はテストなので省略しています。
                var _csentries = new List<CSEntryChange>();
                string _importEntriesJSON = utils.GetContentsWithAccessToken(resource_uri, auth_token, null);
                var _getImportEntriesByObjectTypeResult = JObject.Parse(_importEntriesJSON).SelectToken("value").ToString();
                var _importObjectJSONArray = JArray.Parse(_getImportEntriesByObjectTypeResult);
                foreach (var _importObjectJSON in _importObjectJSONArray)
                {
                    var _csentryChange = CSEntryChange.Create();
                    _csentryChange.ObjectModificationType = ObjectModificationType.Add;
                    _csentryChange.ObjectType = "Person";
                    _csentryChange.AttributeChanges.Add(AttributeChange.CreateAttributeAdd("Alias", _importObjectJSON["Alias"].ToString()));
                    _csentryChange.AttributeChanges.Add(AttributeChange.CreateAttributeAdd("Email", _importObjectJSON["Email"].ToString()));
                    _csentryChange.AttributeChanges.Add(AttributeChange.CreateAttributeAdd("Username", _importObjectJSON["Username"].ToString()));
                    _csentryChange.AttributeChanges.Add(AttributeChange.CreateAttributeAdd("LastName", _importObjectJSON["LastName"].ToString()));
                    _csentryChange.AttributeChanges.Add(AttributeChange.CreateAttributeAdd("EmailEncodingKey", _importObjectJSON["EmailEncodingKey"].ToString()));
                    _csentryChange.AttributeChanges.Add(AttributeChange.CreateAttributeAdd("LanguageLocaleKey", _importObjectJSON["LanguageLocaleKey"].ToString()));
                    _csentryChange.AttributeChanges.Add(AttributeChange.CreateAttributeAdd("LocaleSidKey", _importObjectJSON["LocaleSidKey"].ToString()));
                    _csentryChange.AttributeChanges.Add(AttributeChange.CreateAttributeAdd("ProfileId", _importObjectJSON["ProfileId"].ToString()));
                    _csentryChange.AttributeChanges.Add(AttributeChange.CreateAttributeAdd("TimeZoneSidKey", _importObjectJSON["TimeZoneSidKey"].ToString()));
                    _csentryChange.AttributeChanges.Add(AttributeChange.CreateAttributeAdd("UserPermissionsOfflineUser", false));
                    _csentryChange.AttributeChanges.Add(AttributeChange.CreateAttributeAdd("UserPermissionsMarketingUser", false));
                    _csentries.Add(_csentryChange);
                }
                var _importReturnInfo = new GetImportEntriesResults();
                _importReturnInfo.MoreToImport = false;
                _importReturnInfo.CSEntries = _csentries;
                return _importReturnInfo;

utils.GetContentsWithAccessTokenの中ではx-cdata-authtokenヘッダにAuthTokenをセットし、リソースURIにGETリクエストを投げているだけです。
                _httpClient.DefaultRequestHeaders.Add("x-cdata-authtoken", _accessToken);
                return await _httpClient.GetStringAsync(_url);


4.エクスポート処理関連(OpenExportConnection/PutExportEntriesメソッド)
 こちらは先のインポートとは逆で、実際にAPI Serverへユーザを出力(プロビジョニング)する処理です。
 OpenExportConnectionではインポート時と同じくリソースURIとAuthTokenを設定から取得し、PutExportEntriesでConnector Space内のプロビジョニング対象ユーザを取得してJSON形式に整形してリソースURIへPOSTを行います。
                foreach (CSEntryChange _csentryChange in _csentries)
                {
                    // build json to POST
                    var _attr = new Dictionary<string, string>();
                    // anchor attribute
                    _attr.Add("Username", _csentryChange.DN.ToString());
                    switch (_csentryChange.ObjectModificationType)
                    {
                        case ObjectModificationType.Add:
                        case ObjectModificationType.Update:
                        foreach (string _attribName in _csentryChange.ChangedAttributeNames)
                        {
                            var _attributeChange = _csentryChange.AttributeChanges[_attribName];
                            var _valueChanges = _attributeChange.ValueChanges;
                            if (_valueChanges != null)
                            {
                                foreach (var _valueChange in _valueChanges)
                                {
 if (_valueChange.ModificationType == ValueModificationType.Add)
 {
// new value
_attr.Add(_attribName, _valueChange.Value.ToString());
break;
}
 }
                                }
                            }
                            // build json
                            string _exportDataJSON = JsonConvert.SerializeObject(_attr);
                            string _exportResult = utils.PostContentsWithAccessToken(resource_uri, auth_token, _exportDataJSON, null);

                            _exportEntriesResults.CSEntryChangeResults.Add(
                                CSEntryChangeResult.Create(_csentryChange.Identifier,
_csentryChange.AttributeChanges,
MAExportError.Success));
                                break;
                            case ObjectModificationType.Delete:
                                // NOT Implemented
                                break;

先ほどと同じく、utils.PostContentsWithAccessTokenではAuthTokenをヘッダにつけてJSONをリソースURIへPOSTしています。

大きくはこれで終わりです。
後はビルドしてAzure AD Connectが読み込めるようにExtensionsフォルダ(初期値はC:\Program Files\Microsoft Azure AD Sync\Extensions)へDLLファイルをコピーしておきます。

参考までにソースは以下のレポジトリにあげておきます。
https://github.com/fujie/apiserver

◆管理エージェントの設定

*繰り返しになりますが、Azure AD ConnectへカスタムManagement Agentを組み込む場合、所定の手続きを踏まないとサポート対象外となります。今回は手元にちょうどあった環境を使ったのでAzure AD Connectを使いましたが、本番環境ではMIM(Microsoft Identity Manager)やExgen LDAP Managerなど汎用的なID管理ツールを使ってください。
次は、Azure AD ConnectのSynchronization Serviceに開発したECMA2エージェントを設定します。
コネクタの種類にExtensible Connectivity 2.0を選択し、DLLをロードします。



後は、先に示した画面の様に接続設定でリソースURI、AuthTokenを設定し、管理対象の属性を選択すれば管理エージェント自体の構成は終了です。

次は、Run Profileの設定です。これを設定しないとAzure AD Connectはインポート、同期、エクスポートの各処理を実行してくれません。また、プロファイルの名前をFull Import、Full Synchronization、Export、など決められた名称にしておかないと30分に一回の自動処理の流れに乗せてくれず処理がスタックするので命名は大事です。
尚、今回作った管理エージェントにはDelta Importの処理を実装していないので、プロファイルの定義は行えません。イベントログにDelta Importの定義が無いのでスキップしますよ~という警告が出ますが特に影響はないので無視します。


これでSynchronization Service側の設定は完了です。

◆同期ルールを定義する

後は実際のMetaverse上のデータと先ほど作成した管理エージェントのConnector Space上のエントリの属性のマッピング(同期ルール)の設定を行います。FIMやMIMではポータルでISR/OSRを定義してルールを設定するのですが、今回はAzure AD ConnectなのでSynchronization Rules Editorを使います。個人的にはFIM/MIMの設定画面よりもこのルールエディタの方が使いやすいので好きだったりします。

今回はプロビジョニングだけでいいので、アウトバウンド同期ルールを定義します。
DirectionはOutbound、Connectorは先ほど作成したAPI Serverを選択してAdd new ruleをクリックしてルールを作成します。(以下は作成後の画面)

LinkTypeにprovisionを選択することで新規にユーザを作成するためのルールとして扱われます。

MetaverseとConnector SpaceのユーザのマッチングはUserprincipalNameおよびUsernameを使うので、Join rulesは以下のように設定しています。

後は、本命の属性のマッピングです。
エンコードやロケール、プロファイルIDなどは面倒なので固定値を入れて、ユーザ固有の値だけMetaverseの情報をマッピングします。

これでSaveをするとすべての設定が完了です。

◆テスト

後は、ローカルのAD上にユーザを作成、Azure AD Connectの同期ジョブが動くと、Azure ADへのユーザ作成に加えて、API Serverを経由してSalesforce.comへもユーザが作成されます。

この辺りは前回も紹介したデモの動画を見てもらった方が早いと思います。



Azure AD Connectを使った関係で色々とトリッキーなこともしていますが、少なくともID管理システム側でSalesforce.com自体の存在を殆ど意識せずに構成をすることが出来ていることはご理解いただけるのではないでしょうか?
スキーマの設定についても動的に取得する様に管理エージェントを構成すれば、API Serverの先にあるのがSalesforce.comだろうがDynamics365だろうが基本設定を変える必要は全くなく、API Serverが上手くハンドリングをしてくれますので、従来の個別開発に比べて相当簡単に各種SaaSなどへのプロビジョニングを構成することが可能になります。

今後、クラウド・サービスの活用がますます増えてくると思われますので、既存のID管理システムを効率よく対応させていくための一つの選択肢として、API Serverのようなデータ統合プラットフォームを活用するのはアリかも知れませんね。

2017年6月30日金曜日

[Office365]Azure AD Connectの脆弱性?と最新版へ更新後の運用上の変化点

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

先日、Azure AD Connectに関するセキュリティ・アドバイザリが発表され、脆弱性対応版として最新版がリリースされました。
脆弱性対応のためとはいえ、一部ヘルプデスク運用が変わってくるので、Office365やAzure ADの管理者の方は十分に注意して運用マニュアルの修正などを行う必要があります。

 セキュリティ・アドバイザリ 4033453
  Azure AD Connect の脆弱性により特権が昇格される
  https://technet.microsoft.com/ja-jp/library/security/4033453

 最新ビルド(1.1.553.0)
  https://www.microsoft.com/en-us/download/details.aspx?id=47594

しかし、発表された内容を見ていると、どちらかというと脆弱性というよりも単に不適切な運用をしているだけじゃ、、、という話なので内容を解説してみたいと思います。

また、アドバイザリの中では対応策として、最新ビルドにバージョンアップすることが推奨されていますが、単にバージョンアップしただけでは環境によっては不具合が出ることもあるので、その辺りも解説しておきます。

最後に、Azure AD Connectの話としてアドバイザリが出ていますが、構成によってはFIM(Forefront Identity Manager)/MIM(Microsoft Identity Manager)にも当てはまる内容なので、FIM/MIMを使っている場合の構成の見直しポイントも簡単に。

◆脆弱性?の概要

簡単に言うと、パスワード書き戻しが有効になっているテナントにおいて、同期元のローカルActive Directory上で管理者権限を持っているユーザのパスワードをAzure ADやOffice 365上でリセットすると当然の事ながらローカルActive Directory上の管理者権限を持ったユーザのパスワードもリセットされてしまうので、悪意のあるAzure AD管理者がクラウド上でパスワードリセットを行うことによりローカルActive Directoryの管理者権限の奪取が可能になってしまう、という話です。

色々と前提があるので整理をしておきましょう。

  • 環境
    • パスワード書き戻しが有効になっていること
    • 管理者権限のあるユーザをAzure ADへ同期していること
    • 同期を実行しているユーザに特権ユーザに対するパスワードリセットの権限を付与していること(以下が典型的なケースです)
      • Domain AdminsやEnterprise Adminsのメンバにしている
      • 同期対象のOUの管理権限を同期ユーザへ委譲し、AdminSDHolderコンテナにパスワードリセット権限を付与している
  • 脆弱性利用者
    • 悪意のある管理者。オンプレミスのリソース(AD配下)へアクセスが可能なこと

※AdminSDHolerの話は国井さんのブログ記事を参照してください。
 

こうやって見ていくと当たり前すぎて、製品の不具合というより構成の問題という気がしてきます。
基本的に同期対象となっているOUに管理者権限を持ったユーザが存在するのは、、、ということです。同期してOffice365にログインするユーザなのであれば、恒常的にローカルActive Directoryの管理者権限を与える必要もないはずですし。

◆実際どうなるのか?

では、管理者権限を持ったローカルActive Directory上のユーザをAzure Active Directoryへ同期させてみて、パスワード・リセットをしてみます。

まずは、同期されたユーザ自身によるパスワード変更のパターンです。
アクセスパネルのプロフィール変更画面よりパスワードを変更します。

当然ですが、パスワードがオンプレミスに書き戻され、新しいパスワードでログインできるようになります。(試しにリモートデスクトップしてみるとちゃんとログインできます。当たり前ですが)


次に、SSPR(セルフ・サービス・パスワード・リセット)のシナリオを見てみます。いわゆる秘密の質問や認証用電話・メールなどを使ってパスワードを忘れた際に回復する、というシナリオです。
ログイン画面からパスワード忘れの場合のリンクをクリックすると回復画面に遷移するので、CAPTCHAを入力します。

秘密の質問への回答をします。


無事にパスワードがリセットされ、ローカルActive Directoryへパスワードが書き戻されます。

悪意のあるユーザが秘密の質問を推測してしまうケースは結構あるそうなので、第3者によってパスワードのリセットがされ、ローカル管理者の権限が奪取される、ということもあり得ますね。


最後に、管理者によるリセットです。
Azure AD Portalからユーザを選んでパスワードをリセットするやつですね。

これも管理者がリセットを行い、一時パスワードが割り当てられた段階でローカルActive Directoryのパスワードも変更されるので、一時パスワードでローカルリソースへアクセスできてしまいます。

そう、パスワード書き戻しの機能を普通に使っているだけです。
単に対象となっているユーザの中に管理者権限を持っているユーザが存在しただけです。

これが脆弱性なのか、と・・・。


◆Azure AD Connectのバージョンアップと注意点

どのみち、今後のバージョンのAzure AD Connectにはこの改修が入ってしまうので、仕方がないので対応版である1.1.553.0へバージョンアップします。

バージョンアップによる具体的な変更内容は、アドバイザリのサイトにもあるように以下の2点です。

  • 対象ユーザのadminCount属性の値を見てNullもしくは0なら一般ユーザとみなし、パスワード書き戻しを許可する
  • 対象ユーザが特権ユーザだった場合、パスワードリセットを要求したAzure ADユーザが、対象ユーザと同じユーザだった場合は書き戻す(メタバース上で要求したユーザと対象ユーザの関係を確認する)
    • この部分が原文・翻訳ともにものすごくわかりにくいです。
      • 日本語「要求したユーザーが対象のオンプレミス AD アカウントのオーナーであるかどうかを検証します。それは、対象のオンプレミス AD アカウントと、要求したユーザーの Azure AD アカウントの関係をメタバースで確認します。要求したユーザーがオーナーの場合、Azure AD Connect はパスワード ライトバック要求を許可します。そうではない場合、要求は拒否されます」
      • 原文「it then validates whether the requesting user is the owner of the target on-premises AD account. It does so by checking the relationship between the target on-premises AD account and the Azure AD account of the requesting user in its Metaverse. If the requesting user is indeed the owner, Azure AD Connect permits the Password writeback request. Otherwise, the request is rejected」
    • このオーナー(is the owner)というのが何を指すのか、が全く分からず、ローカルAD上のOUや対象ユーザのセキュリティ構成でオブジェクトのオーナーにしてみたり、と色々とやったのですが、結局オーナー=自身のアカウント、というオチだと思います。#違ったらご指摘ください。


早速バージョンアップを行います。


無事に1.1.553.0になりました。


この状態でユーザ自身でのパスワード変更をAzure AD側で行います。


ここは問題なく変更、書き戻しされます。

同様に自身によるパスワード・リマインドでも問題なく変更、書き戻しされます。

次に管理者によるリセットです。
見事に失敗します。

この時、イベントログには特権ユーザに対するパスワードリセットが拒否された旨、記録されます。
このAdminUpnとうのがリセットを要求した管理者ユーザ、そのあとのUserPrincipalNameが対象のユーザでこの2つのUPNが合致しないとリセット・書き戻しは行われません。


ちなみに、対象ユーザが一般ユーザの場合は従来通り問題なく管理者によるパスワード・リセットを行うことが可能です。

つまり、今後は運用を行う上で、ローカルActive Directory上で管理者権限を持っているユーザについては自分自身でしかパスワード・リセットが出来ない、ということになりますので、従来のヘルプデスク等の運用を変えなければなりません。
この点が最大の注意点です。


◆最後に。FIM/MIMユーザへ

今回「脆弱性」として取り上げられた仕組みは基本的にFIM/MIMにおいても同じですので、管理者権限を持つアカウントのパスワードを、悪意のある別の管理者がリセットすることが出来ます。これを製品の脆弱性や不具合と呼ぶのは微妙ですが、FIM/MIMにおいては今回Azure AD Connectが行った対応は入っていませんので、管理者権限を持つユーザについては自分自身でしかパスワードを更新できない様にMPRを工夫する、などの対応が必要となります。


2017年4月29日土曜日

[MIM]3月のアップデートでサポートプラットフォームの大幅な改善+α

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

色々と追い付いていなかったので、改めてまとめておきます。

3月にMicrosoft Identity Manager 2016 SP1 (MIM)向けのホットフィックスがリリースされ、特にサポートされるプラットフォームが大幅に追加されました。

個人的には、プラットフォームサポート周りでは「SQL Server 2016 Always Onのサポート」が非常に熱いトピックスでしたが、他にもSCSM 2016がサポートされたり、Visual Studio 2017が使えるようになったり、など色々とエンハンスが行われています。

MIM 2016でサポートされるプラットフォーム一覧
https://docs.microsoft.com/en-us/microsoft-identity-manager/plan-design/microsoft-identity-manager-2016-supported-platforms


他にも以下が新しく使えるようになった代表的なシナリオです。



こちらからダウンロード可能なので、MIM使いの皆さんは適用しておきましょう。

2016年9月27日火曜日

[MIM]Microsoft Identity Manager 2016 SP1がリリースされました

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

2016年に入ってから細かくPreviewビルドが公開されてきたMicrosoft Identity Manager 2016(MIM)ですが、ついにService Pack 1がRTMとなりました。

これまでのリリースの履歴。3月、4月、6月にPreview版が出ていました。
 [MIM]June CTPで遂にExchange Onlineをサポート
 http://idmlab.eidentity.jp/2016/06/mimjune-ctpexchange-online.html

 [MIM]Microsoft Identity Manager April 2016 Previewが公開
 http://idmlab.eidentity.jp/2016/04/mimmicrosoft-identity-manager-april.html

 [MIM]Microsoft Identity Manager March 2016 Previewが公開
 http://idmlab.eidentity.jp/2016/03/mimmicrosoft-identity-manager-march.html


ConnectサイトやMSDNには先行して公開されていましたが、Igniteに合わせてリリースノートを含め正式に公開されました。ざっくり触った感じでは、これまでのPreview版の総まとめになっており、目玉は以下の点くらいです。(あとはPAMフォレストの構成とかコマンドレットの追加などです)
  • ワークフロー用のメールボックスにExchange Onlineのサポート
  • Chrome/Firefoxのサポート
  • 新バージョンのOS、SQL Server、SharePointのサポート

リリースノートはこちら
https://docs.microsoft.com/en-us/microsoft-identity-manager/understand-explore/microsoft-identity-manager-2016-sp1-release-notes

取り敢えずインストールして動作を見てみました。

バージョン表記は「4.4.1237.0」となっています。
しかし相変わらずForefront Identity Manager 2010 R2のままなんですね・・・
<Synchronization Service>


<Portal>



インストール中のメールボックス指定。Exchange Onlineが選択できるようになっています。



Chromeでのアクセス。Webページダイアログが以前とは変わっており、IE以外でも使えるようになっています。


Firefoxだと若干怪しいです。




後は色々とバグフィックスなどはありますが、その辺りはリリースノートを参照ということで。

2016年6月6日月曜日

[MIM]June CTPで遂にExchange Onlineをサポート

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

前回の4月版のCTPに続き、6月度のプレビュー版が公開されました。

 公式アナウンス
  Now Available MIM 2016 June Preview
  https://blogs.technet.microsoft.com/iamsupport/2016/06/03/now-available-mim-2016-june-preview/

 ダウンロードはこちら(要登録)
  https://connect.microsoft.com/site433/Downloads


なんといっても今回の目玉は、MIM Serviceの承認用メールにExchange Onlineが使えるようになった、という点です。

このエンハンスリクエストはずいぶん前から上がっていたのですが、なかなか実装されなかったので、待っていた人も多く、早く正式版にも実装してもらいたい機能ですね。

他には、

  • セルフサービス・グループ管理やプロファイル管理ページのChromeやスマホブラウザの対応
  • Windows Server 2016 Technical Preview、SQL Server 2016、SharePoint 2016への対応
  • Windows Server 2016の新機能に対応した特権アクセス管理用のコマンドレットの追加

が更新ポイントとして挙げられています。

更新のペースが速いのでなかなかテストができませんが、触ってみないと。。。

2016年6月1日水曜日

[Azure AD Connect]汎用LDAPやSQLなどの管理エージェントが同梱

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

全然気が付いていなかったのですが、先日のAzure AD Connectの最新バージョン(1.1.180)から以下の管理エージェントが同梱されています。


  • Generic LDAP
  • Generic SQL
  • PowerShell
  • Web Service


これが何を意味するか、というとこれまではあくまでオンプレミスのActive DirectoryからAzure Active DirectoryへのID同期を行うためのツールであったAzure AD Connectが「LDAPやSQLなど他のデータ・ソースを含めID同期を行うことが出来るようになった」、ということです。

Azure AD Connectにディレクトリ同期ツールが統合された際に、カスタムシステムとの接続を将来サポートする、という宣言はありましたが、ようやく第一歩を踏み出した、ということです。

 参考)カスタムシステムとのID同期は「FR(将来的にサポート)」となっています。
 https://azure.microsoft.com/ja-jp/documentation/articles/active-directory-hybrid-identity-design-considerations-tools-comparison/


Synchronization Managerで管理エージェントを作成すると、Azure ADとAD以外への接続を行う管理エージェントが出てきます。


拙作のカスタムのエージェントを導入してみました。
 汎用REST API管理エージェント
 https://restmafim.codeplex.com/



現状まだオフィシャルの文書は出てきていませんが、今後はAzure AD Connectを中心としたハイブリッドID管理がますます拡大していくことになると思いますので、FIM/MIMの知識がようやく?必要な世の中が来たのかも知れませんね。(ハードル高!)



2016年4月17日日曜日

[MIM]Microsoft Identity Manager April 2016 Previewが公開

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

先月に引き続き、Microsoft Identity Manager 2016の2016年4月版のCTPが公開されています。

※先月はこちら。
 [MIM]Microsoft Identity Manager April 2016 Previewが公開
 http://idmlab.eidentity.jp/2016/03/mimmicrosoft-identity-manager-march.html

先月は、環境面では、IE以外のブラウザのサポート、機能面では特権ID管理フォレストの既存のユーザ、グループをPAMロールへ追加することが出来る、という拡張でしたが、今月は新しいプラットフォームへの対応です。


  • MIM Sync/MIM ServiceデータベースとしてWindows Server 2012 R2上のSQL Server 2016 RC2をサポート
  • MIM Sync/MIM Serviceが使うメールサーバとしてWindows Server 2012 R2上のExchange Server 2016をサポート
  • MIM Portalのインストール先としてWindows Server 2012 R2上のSharePoint Server 2016をサポート
  • MIM Add-inのインストール先として、Windows 10上のOutlook 2016をサポート

まぁ、SharePoint Server 2016をサポート、と言っても互換レベルは15なので、2013相当のWebサイトを作るだけなんですけどね。

いずれにしても、製品が定期的に更新されていることが見えるのは使う側からすると安心ですね。投資が継続していることが見えるので。

2016年1月8日金曜日

[MIM/FIM]間違ったオブジェクト削除を防ぐための仕組み

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

ID管理システムを本番環境で運用していると一番気を遣うのが、人事システムからわたってくるデータの間違いへの対応です。

ID管理システム自体はデータを生成するわけではないので、人事システムなどの信頼できるデータソースから従業員や組織に関する元情報を受け取り、そのデータをあらかじめ決めたポリシーに従ってActive Directoryやアプリケーションなどへ渡していきます。

つまり、ID管理システムが正しく動作するためにはデータソースから正しいデータがわたってきていることが大前提となっているわけです。

しかし、人事システムもあくまで人が運用しているシステム。社員情報を登録するのも人なわけで、必ず入力ミスは起きますし、データの受け渡しをするインターフェイスにバグが絶対に無いとは誰も言い切れるものではありません。

そのような前提を踏まえてID管理システムを設計~構築する時は、入力データのバリデーションをするための前処理を入れる検討をするなど、色々と気を使います。

その際に、まだ氏名の漢字間違い等であれば、あまり影響はないのですが、役職や組織などアクセス権に関する属性の間違い(これが意外と多いんです!)や、データの欠損を含む在籍状態の間違いなど、非常にインパクトの大きな間違いがしばしば発生するのも事実です。
間違って退職扱いになってしまい、各アプリケーションからIDが消えてしまったりするとリカバリを行うのに非常に大きな手間がかかりますし、特にActive DirectoryではObjectSidでIDを識別しているので、同じ名前でユーザを再作成すればよい、というものではなく大惨事を招いてしまいがちです。


各社のID管理製品は特にこのようなデータ削除に関する保護措置を用意しているものが多く、Microsoft Identity Manager(MIM)においてもあらかじめ設定した閾値を超えたオブジェクトの削除が一気に発生するとジョブを停止する機能「Specify number of deletions to process」が用意されています。
(昔からある機能なので、当然まだForefront Identity Manager(FIM)を使っていてもこの機能は使えます)


早速みてみます。

シナリオとしては、以下を想定してみます。

  • ユーザデータをCSVからMIMに取り込んでいる
  • 前日までの取り込みで現在MIM上に10,000ユーザが存在している
  • 人事システムとのインターフェイスの不備で取り込むCSVの大多数のレコードが消えてしまった


◆入力データ

 正しい入力データ(前日のデータ)はこちら。10,000件レコードが存在します


 しかし、当日2レコードしかないCSVがわたってきてしまいます。



 データ取り込み前まではMIM上に10,000件データが取り込めています。



◆何も考えずにデータを取り込む

 インポートすると、当然のことながら9,998件がDelete対象として認識されてしまいます。このままMetaverseへの同期処理を実行すると本気であちこち消えていきます。。。


◆一括削除防止機能を設定する

 インポート処理で削除が一定の件数を超えたら処理を止めるための設定を行いますので、CSV取り込み用のConnector SpaceのRun ProfilesのImport処理の中に設定項目が存在します。
 Thresholdの項目の中の「Specify number of deletions to process」にチェックを入れて、とりあえず10に設定してみます。
 ちなみにこの設定、一度設定~保存しても、再度設定の編集画面を開くと保存した内容が「表示上」はクリアされてしまいます。キャンセルを行えば設定は残るのですが、間違えて保存をすると本当に設定がクリアされてしまうので、注意が必要です。(昔からのバグですね)


◆取り込んでみる

 先の間違ったデータを取り込んでみます。
 すると、Statusが「stopped-deletion-limit」でジョブが停止しているのがわかります。


 削除対象としてマークされた件数も先ほど設定した10件になっていることがわかります。


 このようにジョブが異常終了してくれるので、後続で同期ジョブを流す前にConnector Spaceの段階でリカバリができ、大惨事を防ぐことが可能になります。

特に期初の大規模人事異動時などはこのような機能をうまく使って、上手にID運用をしていくとよいと思います。

2016年1月6日水曜日

[AAD Connect]特定のドメインコントローラからIDを同期する

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

Azure AD Connect(AAD Connect)を使ってオンプレミスのActive DirectoryからAzure Active Directory(Azure AD)へIDを同期する際、実環境においては同期元となるADドメイン上に複数のドメインコントローラが複数サイトに配置されている場合が多いと思います。

そのような場合、同期元とするドメインコントローラをある程度固定することでレプリケーションのタイムラグなどによる無用なトラブルを回避することが可能です。

※Forefront Identity Manager(FIM)やMicrosoft Identity Manager(MIM)を使っている方なら普通に行う設定ですが、AAD Connectについても考え方は同様で、正式にサポートされている方法です。


早速設定方法を見てみます。

◆AAD Connectの初期状態

複数ドメインコントローラが存在する環境にAAD Connectをインストールした状態です。
今回はds1-addsとds2-addsという2台のドメインコントローラを用意し、ds2-addsにAAD Connectを同居させているので、初期状態では自動的にds2-addsが同期元として選択されました。(基本的にネットワーク的に近い(ICMPのレスポンスが早い)サーバが自動選択される仕組みのはずです)

Synchronization Service Managerを開いて同期履歴を見ると使われたドメインコントローラがわかります。


AD DSの管理エージェントの設定の[Last used]を見ても確認できます。



◆同期元とするドメインコントローラを設定する

いよいよ同期元となるドメインコントローラを設定します。
同じくSynchronization Service ManagerのConnectorsメニューよりAD DS管理エージェントの設定を開き、[Only use preferred domain controllers]にチェックを入れ、[Configure]を開きます。


ここで使用するドメインコントローラのFQDNを入力・設定します。



この設定を行うことにより、設定したドメインコントローラからのみIDが同期されるようになります。

再度同期ジョブを流すと設定したドメインコントローラが使われることがわかります。



◆優先ドメインコントローラが停止している場合の動作

先に設定した状態だと、優先設定したドメインコントローラからのみしか同期が行われないため、設定したドメインコントローラが停止していると同期エラーが発生してしまいます。


この事態を回避するためにはPreferred DCに複数のドメインコントローラを設定するか、[Only use preferred domain controllers]のチェックを外しておきます。


こうすることで優先ドメインコントローラが停止していたら、他のドメインコントローラを使って同期ジョブが実行されるため、同期が停止することはありません。



まとめると、以下のような動作となりますので環境に応じて設定を変更してうまく運用していきましょう。
DC1DC2Preferred DCOnly use preferred domain controllers同期ジョブ
起動起動DC1チェックONDC1を利用して同期実行
停止起動DC1チェックON同期エラー
起動起動DC1チェックOFFDC1を利用して同期実行
停止起動DC1チェックOFFDC2を利用して同期実行


2015年10月12日月曜日

[MIM]同期方法(ポリシーベース、Scope Filterベース)を比較する

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

Microsoft Identity Manager 2016(MIM)を使って外部システムへIDをプロビジョニングするためには2つの方法があります。(コードベースを合わせると正確には3つですが、ここでは開発を伴う方法は除外して考えます)


◆2つの同期方式
①ポリシーベースのプロビジョニング
一つ目は、Forefront Identity Manager 2010から実装された管理ポリシールール(Management Policy Rule / MPR)、セット(SET)、アクションワークフロー(Action Workflow / WF)、送信同期規則(Outbound Synchronization Rule / OSR)を組み合わせて行う方法です。

ざっくり説明すると、
・一定の条件に当てはまるリソース(ユーザなど)を
・同期規則に割り当てる
ことによって外部システムへプロビジョニングを行います。

この条件をSET、外部システムとの同期するためのルール(属性マッピングなど)をOSR、同期規則へ割り当てるアクションの定義をWF、全体をまとめてMPR、と呼びます。

内部的には、以下の処理が行われます。

  1. 人事などからリソースがFIM(CS)へインポートされる
  2. Metaverseへ同期されるタイミングでISRによりFIM ServiceのCSへ同期される
  3. FIM ServiceへExportされる
  4. リソースがSETの条件に当てはまるかどうか評価される
  5. FIM Service上でリソース毎にExpected Rules Entry(ERE)が生成され、リソースに参照型の属性としてEREが割り当てられる
  6. FIM Service上のリソースとEREがImportされ、Metaverseに同期される
  7. EREによりMetaverse上のリソースとOSRが紐づけられて外部システム用のConnector Spaceへ同期される
  8. 外部システム用のMAでExportを行うことで外部システム上にプロビジョニングされる




キモはリソースがMetaverseに同期されたタイミングでリソースのERE属性が参照しているEREを見て適用するOSRを設定する、という部分です。(処理7の部分)


②Scope Filterベース
こちらはForefront Identity Manager 2010 R2から実装された少しシンプルな同期方法です。

OSRを適用するための条件(Scope Filter)を定義しておくことにより、Metaverseにリソースが同期された段階で条件にマッチすると即OSRが適用され、対象の外部システム向けのCSへリソースが同期されます。
ポリシーベースの同期ではEREオブジェクトがリソースとOSRの間を取り持っていたのに対して、とりあえずMetaverse上のすべてのリソースに対してScope Filterへの適合を確認する、という点で非常にシンプルです。





◆同期方式の機能面での比較
最大の違いは、デプロビジョニング(外部システムからリソースを削除する)ができるか、できないか、です。
ポリシーベースではSET条件に当てはまらなくなった場合に何を行うか?についても定義ができるので、デプロビジョニングするためのWFを作成し、MPRを定義しておけば外部システムからリソースを削除する、などの細かい制御を行うことが可能です。

ざっくりまとめると以下のような比較になります。

比較項目ポリシーベースScope Filterベース
プロビジョニング条件判断MPR、SET、WFの組み合わせにより適用するOSRを決定するOSR自体に設定された条件(Scope Filter)に合致するすべてのMetaverse上のリソースにOSRを適用する
複雑な条件の設定可能
(SETの条件はかなり柔軟、かつ手動でメンバ追加を行うことも可能)
不可能
(基本はリソースの属性の値による判断で、複数の条件を設定する場合はすべてAND条件となる)
FIM Service上へのリソースの同期の要否必要不要
生成されるオブジェクトの数多い(EREオブジェクトが必要)少ない
デプロビジョニング可能
(デプロビジョニング用のMPRとWFを定義することで外部システムからリソースを削除できる)
不可能
(Scope Filterに合致しなくなったリソースに関しては同期されなくなるだけで外部システムからリソースは消えない)
管理面FIM Portal上のユーザに対して適用する予定のルール(ERE)と実際に適用されたルール(DRE)が割り当てられるので、トラブルシュートが楽FIM Portal上で対象ユーザにどの同期規則が適用されているのかの判断がしづらい(FIM Serviceへユーザを同期しないことも可能になってしまうため。FIM Serviceへ同期されたユーザについてはDREを設定することで状態確認は可能)



◆同期方式を性能面で比較
これは圧倒的に差があります。
ポリシーベースだと一旦FIM Serviceにリソースが入ってからでないとリソース割り当ての判断ができないため、処理的にはかなりのオーバーヘッドとなります。また、リソースとは別にERE自体がオブジェクトとして生成され、Metaverse上へ同期されるため、オブジェクト数が外部システムの数分増えていくため、データベースの性能を圧迫します。

一方でScope FilterベースだとリソースがMetaverse上に同期された段階でScope Filterが評価され、適用されるOSRの判断が行われるので無駄がありません。

実際の性能測定をすると以下のような結果となります。
ADにユーザがプロビジョニングされて使えるようになるまで、という条件ですが10,000ユーザで1時間以上の差がついています。


属性条件
・Macbook Air上のVMware Workstationで計測
・ホストスペック
 OS : Windows 10 Pro x64
 CPU : Core i7-4650U 2.3GHz
 メモリ : 8GB
 ディスク : SSD
 VM : VMware Workstation 10
・ゲストスペック
 OS : Windows Server 2012 R2
 CPU : 1vCPU(2core)
 メモリ : 4GB
・ミドルウェア(すべて1台に同居)
 SQL Server 2014 Standard SP1
 SharePoint Foundation 2013 SP1
 Active Directory Domain Service
 Microsoft Identity Manager 2016
 - Synchronization Service
 - MIM Service
 - MIM Portal
・同期条件
 入力(HR相当):CSVファイル
 出力:ADDS
 ユーザ件数:10,000
 同期属性:
 - Account Name
 - Display Name
 - First Name
 - Last Name
 - Department
 同期条件:Department属性値がEIDENTITYとなっていること


◆どちらの方式を使うべきなのか
ケースバイケースなので、なんとも言えませんが例えばActive Directoryなど、ほぼ全員がプロビジョニングされてデプロビジョニングすることがない(無効化はするが実削除はしない)ようなケースであればScope Filterベースがあっていると思います。
今回のテスト環境は非常にプアな環境だったこともあり、データベースでロックが発生してしまい10,000ユーザをポリシーベースで同期しようとしただけでエラーが発生してしまったりしていることもあり、まずはScope Filterベースで設計できないかどうかを検討した上で、どうしても問題がある場合に限ってポリシーベースを使うというのが良いのかもしれません。

2015年10月10日土曜日

[MIM]同一サーバにMIM Service/PortalとSynchronization Serviceを同居する際の注意点

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

本番環境ではMicrosoft Identity Manager(MIM)Synchronization ServiceとMIM Service/Portalは分離すると思うので、あまり問題になることはありませんが、開発や検証環境では一台のサーバ上に環境を作ることも多いと思います。

しかし、本番環境になるべく近い構成にするためにMIM Service/PortalのベースとしてStandard/Enterprise EditionのSharePointをインストールすると、同梱されているUser Profile Service(実体はFIM Synchronization Service)がインストールされてしまいます。

このことにより、MIM Synchronization Serviceの構成が壊れてしまうので、検証環境等でMIM Synchronization ServiceとMIM Service/Portal(およびベースとなるSharePoint)を同一のサーバにインストールする場合は注意が必要です。
(SharePoint FoundationにはUser Profile Serviceが入っていないので問題は起きません)


Microsoft Identity Manager 2016 のポータル


早速見ていきましょう。

◆発生条件
・MIM Synchronization ServiceとMIM Service/Portalを一台のサーバに同居する
・Standard/EnterpriseエディションのSharePointを利用する

◆発生する不具合
・MIM Synchronization Serviceをインストールした後でSharePointをインストールするとSynchronization Service Managerが起動しなくなる。
 ・サービス実行ファイルのパスがSharePoint側のFIM Synchronization Serviceになってしまう


 ・サービス実行アカウントが「\」となってしまう


 ・サービス起動設定が無効化となってしまう
 ・アカウントをSynchronization Service用に設定しなおしてもAccess Deniedエラーが出てサービスが起動しない


◆対策
結局のところ、サービスの設定のパス関係がすべて置き換わってしまっているので修正をする必要があります。
レジストリをガンガン触りますので、基本自己責任です。

①レジストリのサービス関連ファイルのパス修正

対象キー①
HKLM\SYSTEM\CurrentControlSet\Services\FIMSynchronizationServive\ImagePath

修正前)
"C:\Program Files\Microsoft Office Servers\15.0\Synchronization Service\Bin\miiserver.exe"
修正後)
"C:\Program Files\Microsoft Forefront Identity Manager\2010\Synchronization Service\Bin\miiserver.exe"



対象キー②
HKLM\SYSTEM\CurrentControlSet\Services\FIMSynchronizationServive\Parameters\Path

修正前)
C:\Program Files\Microsoft Office Servers\15.0\Synchronization Service\
修正後)
C:\Program Files\Microsoft Forefront Identity Manager\2010\Synchronization Service\

※その他、Management Agent関連のパスも修正が必要になる場合もあります。


②サービス実行ユーザの修正
「\」となっているのでSynchronization Service実行ユーザに変更する



③パーミッションの変更
上記①、②でサービス自体の修正は終わりなのですが、どうやらPeopleILMなどSharePoint側の設定で消えないものがあるらしく、Synchronization Service起動ユーザにSharePoint側のSynchronization Serviceのパスへの読み取り・実行権限を与える必要があります。

C:\Program Files\Microsoft Office Servers\15.0\Synchronization Service\



一応ここまでで使えるようになります。


◆他の解決方法
インストールする順番をSharePoint⇒MIM Synchronization Serviceの順にすることでSharePoint側の設定を逆にMIMが上書きするのでレジストリの修正は不要になります。
が、やはりPeopleILM関係の問題は出るので、上記③の権限付与は必要です。


◆根本的な解決方法
「SharePoint Foundationを使う」。これに限ります。
基本は同居構成の場合はSharePoint Foundationを使いましょう。