ID連携の花形!MIM 2016やってみる?(1) - IDaaS と MIMの関係


イントロ

こんにちは。本コラムをご覧いただき、ありがとうございます。

こちらにアクセスいただいた方は、おそらくIDaaSやID連携にご興味をお持ちか、実際にMIM 2016を扱う必要から情報収集をされている方が多いのではないでしょうか。

実は私自身、IDaaSやID連携に対する知識はある程度持ち合わせているものの、ある種その花形ソフトウェアであるMIM 2016の利用方法をあまり知らずに来てしまっておりました。ある日、お客さまに「MIMってID連携ソフトがあるみたいだけど、簡単な使い方わかるかな?」と素で聞かれてしまい、情報収集や答えに大変手間取った苦い思い出があります。

MIMのインストール方法や使用方法は、マイクロソフトからWebベースで公開(https://docs.microsoft.com/ja-jp/microsoft-identity-manager/microsoft-identity-manager-deploy)されているのですが、前提となるシステム構成が古かったり、英語の情報がほとんどのため、正確な情報収集はかなり大変なものでした。と書くと詳しい方からは、そんなことはない!とお叱りを受けるかもしれません。私自身もそうですが、詳しい方は間違いなく「IdM実験室」(http://idmlab.eidentity.jp/)をチェックされていると思います。このサイトの情報量と正確さは国内のリファレンスレベルと思いますが、専門家向けの内容が主なので、実際には私自身で構築や検証を行ったうえ、お客さまへは技術的なトランスレーションや「まとめ」を行ってお伝えしました。

本コラムの目的ですが、上記の「個人的な思い出」を皆さんには味わっていただきたくないため、そのノウハウをちょっとだけ共有させていただきたい、というのが正直なところです。具体的には、Active Directoryの仕組み程度は知っているけど、ID連携やMIMについては知らない...、という方向けに、最小限の機能とその使い方をお伝えしたいと思います。なお後述しますが、マイクロソフトのクラウド認証製品(Azure Active Directory)をハイブリット構成で使う際に必要な「Azure AD Connect」の動作を理解するうえ、MIMを知ることは重要だったりするのです。

申し遅れましたが、私は当社で、Active Directoryを中心としたマイクロソフト製品システムの提案・設計・構築を業務としており、お客さま先システムでのトラブル解析などもあわせて行っています。また個人的な活動ですが、Microsoft Technetフォーラムへの投稿などのコミュニティ活動を評価いただき、Microsoft Most Valuable Professional(MSMVP) Enterprise Mobility (2017~2018)を受賞させていただきました。ちなみにMSMVP表彰プログラムとは15年ほどの付き合いとなります。

MIMには割と複雑な部分があり、どうしても分量が多くなってしまうと思いますが、よろしければお付き合いください。

ID連携とプロビジョニングとは?そのメリットや必要性とは?

「ID連携」というと、クラウドベースのIDaaS(IDentity as a Service)を思い浮かべる方も多いと思いますが、実際には、異なるID間でシングルサインオンを行うための「IDフェデレーション」(これがID連携の中心となる技術です)のほか、異なるID間の情報を連携して変更する「IDプロビジョニング」技術が背後に必要になることがあります。

皆さんもご存じの「Office365」ですが、実はID認証にAzure Active Directory(Azure AD)が使われていて、Office365の管理ポータル画面から表示されるユーザーは、Azure ADから情報を呼び出しているのです。

ハイブリット環境の場合、Office365側のAzure ADに対して同期を行いますが、これは単に「オンプレADのIDとパスワードをOffice365に送りつけている」わけではないのです。

ハイブリッド環境では、オンプレミスのActive Directoryで認証されたIDを使って、AD FSによるフェデレーション認証を行います。フェデレーション認証とはなにか、を簡単にいうと、アプリケーションが(オンプレADにより)認証済みユーザーの受け入れ条件を審査して、利用を許可するか決めることです。これを「認可」といい、SAMLを使用する場合、アサーションと呼ばれる「審査に必要な情報」をオンプレ側から送るのですが、「ObjectGUID」という対象ユーザー個体を示す属性(正確にはBASE64でエンコーディングしたもの)と「UserPrincipalName」という認証IDを示す属性が含まれています。

Office365側で条件を満たしているか審査する際、Azure ADデータベースから引いた該当の属性値が「合致している」ことで判断します。つまり、オンプレActive Directoryの情報とAzure ADの情報が「整合性が取れて」いなければ、前提条件が崩れてしまいます。だから、両者での「同期」が必要なのです。どちらも中身はLDAPデータベースですが、システムが違うのでActive Directory同期のような機能は使えません。ですから、異なるシステムのIDに「IDプロビジョニング」技術を使って同期を行います。

SAML2.0によるOffice365の「認可」

上の例では、Active Directoryの「ObjectGUID」の値が、Azure AD側では「SourceAnchor」という別の属性に「Base64でエンコードされた値」として同期しています。また「UserPrincipalName」属性は、Active DirectoryとAzure ADで同じ属性に同じ値を同期しています。このようにIDプロビジョニングでは、「別システム間のID同士でオブジェクトや属性が紐づけ(マッピング)されている」「マッピングには個別にルールがあり、計算式で表現が可能である」といったかたちで、定義できると思います。

実際には、「姓(Sn)」「名(GivenName)」「表示名(DisplayName)」「メールアドレス(Mail)」などを含め、多くの属性情報が同期の対象となります。Azure ADの性格上「Active Directoryのクラウド版」というコンセプトのため、Office365以外のアプリケーションでもフェデレーション認証に利用できるようにするためです。Office365上でも、ユーザー情報の管理を容易にするため、これらの情報を管理ツールから表示することができます。

Office365との連携の際にはAzure AD Connectを必ずインストールしますが、これはActive Directory→Azure ADのIDプロビジョニングの専用ツールになっていることが理由です。

上記をまとめると、ID連携を行うためには、認証側(Active Directory)とアプリケーション側(Office365)で、別々に利用しているID情報の紐づけが「認可」のためには必要で、それを行うのがIDプロビジョニング、というわけです。

上の例は、2システム間のIDプロビジョニングですが、ID連携の場合、1対多システム間のIDプロビジョニングが必要なケースも多いです。Office 365以外のWebアプリケーションともID連携させたい場合、そのシステムのIDデータベースにActive Directoryの属性マッピングを行う必要があり、Office365と同時に行うことになります。

システム管理者側からみると、この作業を手作業で行った場合、煩雑さが増すことで作業間違いが発生しますし、非効率なことこのうえない状態になります。また、これらの作業を「正しく実行した」証拠ログが、ID監査の目的などで必要になることもあるのです。こういった作業を、全自動で行うシステムがあれば、作業間違いも発生せず、効率的ですね。

IDプロビジョニングにおけるマイクロソフトのソリューションは?

上でご紹介したAzure AD Connectツールの基となっており、今回ご紹介するのが「Microsoft Identity Manager 2016(MIM 2016)」というソフトウェアになります。MIM 2016はいくつかのコンポーネントから構成されていますが、MIM Synchronization Services(MIM同期サービス)というコンポーネントをカスタマイズしたものが、Azure AD Connectツールとして使われています。

MIM 2016の機能については後でお話ししますが、サーバー管理製品でありながら、例えばSCCMのように有名でない理由として、利用目的がニッチであり、特定の状況でしか利用されてことなかったことが挙げられます。ただ、もっと大きな理由として、インストールや構成が簡単にできない、という事情があるためだと、個人的には思っています。

実際に触れたことがある方ならお分かりかと思いますが、MIMを導入する場合、インストールの段階で「日本語版が存在しない」、という点に驚かれると思います。ユニバーサル版なのではなく、本当に英語版しかありません。おそらく、ニッチな目的で作成された経緯から、多言語化されていないと思われますが、UIもすべて英語です。MIMポータルという、MIM設定やデータ登録を行うWebアプリケーションだけは、日本語化されていますが、初めての方にはかなり敷居が高いと思います。

もう一つの理由として、構成に当たって「(過去のバージョンでは)プログラミングスキルが必要」という点があると思います。別の回に触れますが、プロビジョニングに必要な「ルール拡張」(MIMで情報をインポート/エクスポート同期する際のルール記述)をVisual BasicやC#のプログラミング文法で記載する必要があり、アプリケーション開発スキルが必要でした。これについては、FIM 2010 SP1(MIMの1世代前の製品)以降であれば、ルール拡張にあたる設定を、プログラミングせずにある程度行うことができるようになりました。

なお、MIMという名前ですが、MIMはもともとMIIS(Microsoft Identity Integration Server 2003)からスタートし、ILM(Identity Lifecycle Manager 2007)→FIM(Forefront Identity Manager 2010)→MIM(Microsoft Identity Manager 2016)と、製品名が転々と変更された、珍しいソフトウェアとなっています。理由はわからないのですが、Active Directoryのように「ブランド化」しようとしたがうまくいかず、サーバー管理製品のカテゴリー(Forefrontブランド)に入れたもののブランド名が消滅してしまって追い出されたり、と流転の運命をさまよっているようにも見えます。Microsoft Identity製品一覧など興味のある方は、以下のマイクロソフトのページ(https://blogs.technet.microsoft.com/iamsupport/idmbuildversions/)をご覧になってみてください。

MIMでなにができる?

MIMは「ID統合」を行うための製品として位置付けられており、特に「IDのライフサイクル管理を行う」ことで、管理者の作業・監査における省力化を目的としています。ID統合(IDプロビジョニングもこの機能のひとつです)では、IDプロビジョニングに必要な操作をできるだけ自動化する、ということが第一の目的となります。それ以外に、たとえば新規ユーザー作成依頼やパスワード忘れによるリセット依頼、といったヘルプデスク対応についても、ユーザー自身で対応できるしくみも用意されています。ちなみにこれらのしくみはワークフローで管理・実行されており、IDに対してどのような作業を行ったかは、きちんと記録に残るようになっています。

実際の機能としては、上記でご説明した「IDプロビジョニング」や「パスワード同期」機能のほかに、「MIMポータルでのセルフマネージメント」「MIMセルフパスワードリセット」「証明書マネージメント」「Privileged Access Management(PAM)」になります。

「MIMポータルでのセルフマネージメント」機能は、MIMポータルと呼ばれるWebサイト上で、ユーザーが自分自身の情報を変更管理できる機能です。MIMポータルには各種管理画面があり、ユーザー管理画面では各ユーザーが自分自身の情報を変更したり、新規にユーザーやグループを追加することができます。この機能を利用すれば、ユーザーが自分自身で情報を管理でき、ことあるごとに管理者に依頼する手間や時間がはぶけます。

「セルフパスワードリセット」とは、ユーザーが自分自身でパスワードをリセットできる機能です。ユーザーはこの機能で用意された、セルフパスワード登録サイトから「秘密の質問」を事前に登録しておき、パスワードを忘れてしまった場合、セルフパスワードリセットサイトから、新しいパスワードを自分自身でリセットします。この機能で、ユーザーがパスワードを忘れたとき、ヘルプデスクに申告せずに簡単にパスワードを再取得できます。

「証明書マネージメント」とは、ユーザーが使用する証明書を自分自身で登録できる機能です。たとえばスマートカード発行には、専用証明書のインストールが必要ですが、スマートカードを自宅に忘れたユーザーが、自分自身で空のスマートカードに証明書をインストールし、臨時のスマートカードを発行することができるようになります。

「Privileged Access Management(PAM)」とは、ユーザーのグループ権限管理を行う機能で、管理者権限にあたるグループを必要時のみ一般ユーザーに割り当てるためのしくみです。管理目的で利用するユーザーについて、必要時に一時的に管理者権限(管理者グループのユーザー)として登録し、それ以外は一般ユーザー権限で運用するよう、ワークフロー管理を行うことができます。こうすることで、悪意ある管理者権限の不正使用といった、セキュリティ問題を防ぐことができます。

この際、管理者グループと利用ユーザーを別フォレストに隔離して運用する「要塞フォレスト」を構成することで、管理者アカウントをより安全に利用することもできます。この機能に関しては、マイクロソフトのページ(https://docs.microsoft.com/ja-jp/microsoft-identity-manager/pam/privileged-identity-management-for-active-directory-domain-services)に詳しく載っています。

今回ですが、IDプロビジョニングは「異なるID間での属性マッピング」であること、IDプロビジョニングを自動化するためのソリューションとしての、MIMの役割について、お伝えしました。

本コラムは5回程度の構成を予定していますが、次回は、MIMを実際に使用するための仕組みの整理、そしてインストールの具体的方法について、お伝えできればと思っています。



ID連携の花形!MIM 2016やってみる?(1) - IDaaS と MIMの関係