Inside SharePoint: SharePoint Security Accounts

[アーティクル]
08/25/2016

SharePoint の内部SharePoint のセキュリティアカウント

Pav Cherny

アプリケーションプールとセキュリティアカウント
SharePoint サーバー上でカスタムコードを実行する
Dr. Jekyll と Mr. Hyde について
プロセスの分離とセキュリティアカウント
構成データベースのセキュリティアカウント
セキュリティアカウントと資格情報キー
鉄則を守る

SharePoint のセキュリティアカウントを使用すると、システム構成が脆弱になるリスクが高く、その結果 SharePoint 環境全体が攻撃を受ける可能性があります。マイクロソフトでは、SharePoint サーバーファームを適切に展開してセキュリティで保護できるように、詳細な情報やガイドラインを公開しています。たとえば、Office SharePoint Server のセキュリティに関するガイドでは、300 ページ以上にわたって、サイトとコンテンツの階層の計画と実装、認証方法、セキュリティロール、管理者アカウントとサービスアカウントなど、多くのセキュリティに関する問題を扱っています。また、Windows SharePoint Services のセキュリティアカウントに関する要件が記載されたワークシートでは、セキュリティアカウントの構成に関する基本的な情報を提供しています。セキュリティを重要視する場合は、必ずこのワークシートの要件に準拠してください。

詳細なドキュメントが提供されていても、セキュリティアカウントの構成は難しい作業になる場合があります。実際、1 台のサーバーに SharePoint をインストールする場合、既定の設定は、ワークシートの推奨事項に従っていません。また、Windows SharePoint Services (WSS) 3.0 に付属する E-mail Integration Web サービスなど一部のコンポーネントは、サーバー上で昇格した権限を使用する必要がありますが、この要件はセキュリティに関するマイクロソフトの推奨事項に従っていないだけでなく、セキュリティに関するベストプラクティスや単なる常識とも明らかに食い違っています。SharePoint 3.0 サーバーの全体管理ツールでは、警告を受け取ることなく重要なセキュリティアカウントの構成を適用でき、その結果として生じる脆弱性が Microsoft Baseline Security Analyzer (MBSA) によって検出されないので、やはり SharePoint サーバーファームをセキュリティで保護し、その状態を維持することは難題です。

このコラムでは、SharePoint のセキュリティアカウントについて詳しく解説し、脆弱な構成によって、どのように攻撃者がすべてのサイトコレクションとサイトを完全に制御できるようになるかを説明します。このトピックは少し慎重に扱う必要があります。一方では、私は SharePoint サーバーの構成を取り巻くセキュリティ上の課題を認識できるように、皆さんをお手伝いしたいと考えています。SharePoint 環境を効果的にセキュリティで保護するには、やはり SharePoint 環境の長所と短所の両方を理解する必要があります。

もう一方で、私は悪意のある人物を手助けするつもりはありません。このため、今回のコラムではワークシートやカスタムツールを一切提供せず、ソースコードの説明も、経験豊富な ASP.NET 開発者ならだれでもよく知っている基本的なトピックに限定します。今回のコラムで取り上げるソースコードは、脆弱性の検出には役立ちますが、これを使用して脆弱性を悪用することはできません。プログラミングのスキルがあまりない場合でも、Microsoft Office SharePoint Designer 2007 があれば、今回紹介するコードを使用して、独自の ASP.NET ページを作成できます。

Microsoft Office SharePoint Designer 2007 の試用版は、オンラインで入手できます。好みに応じてテストラボを構成し、できる限りセキュリティで保護してから、検証用のコードスニペットを実行してください。それでは、皆さんの SharePoint サイトがどれぐらいセキュリティで保護されているかを確認しましょう。

アプリケーションプールとセキュリティアカウント

セキュリティアカウントは、SharePoint の要求処理モデルを構成する非常に重要な要素です。このアカウントによって、SharePoint Web アプリケーションを実行する IIS ワーカープロセスのセキュリティコンテキストが定義されます。SharePoint Web アプリケーションを作成する場合、指定する必要がある項目として特に重要なのは、アプリケーションプールとそれに関連するセキュリティアカウントの資格情報、および SharePoint データベースとそれに関連する認証方法です。Windows 認証 (推奨) を使用すると、指定したセキュリティアカウントに、コンテンツデータベースに対する dbOwner 権限が SharePoint によって自動的に付与されるので、SharePoint Web アプリケーションを実行する IIS ワーカープロセスから、このデータベース内でホストされるサイトコレクションやサイトにアクセスできます。他の認証方法を使用する場合は、SQL Server の資格情報を明示的に指定する必要があります。

いずれの場合も、SharePoint サイトコレクションと SharePoint サイトは仮想的な構成要素です。物理的には、これらの要素はデータベースレコードに対応しています。コンテンツデータベースへの直接的な SQL Server 接続を確立するためのアカウント名とパスワードがわかっている場合、SharePoint レベルで定義される権限やアクセス制御に関係なく、そのデータベースのサイトコレクションやサイトへの完全なアクセスが許可されます。データベースサーバーへの直接的な接続が確立されるので、SharePoint はこのアクセスをブロックできません (図 1 参照)。したがって、セキュリティアカウントは攻撃の第一の標的になります。

図 1 SharePoint サイトコレクションおよびサイトを迂回したデータへのアクセス

マイクロソフトでは、セキュリティに関するリスクを軽減するために、認証されたコンテンツや匿名コンテンツを含むサイトコレクション用に別途アプリケーションプール (およびセキュリティアカウント) を構成することによって、パスワードを保存するアプリケーションや、サイトの作成、サイトの管理、およびコンテンツを使用した共同作業をユーザーが自由に行うことができるアプリケーションを分離することを推奨しています。構成に関するこのアドバイスは、攻撃者が 1 つのアプリケーションプールを制御できても、SharePoint ファーム内でホストされるすべてのデータには自由にアクセスできないようにするという考えに基づいています。SharePoint サイトコレクションおよびサイトに関連付けられた Web アプリケーションごとに異なるセキュリティアカウントを使用している限り、他のデータベース内の SharePoint サイトコレクションおよびサイトにはアクセスできません。

マイクロソフトはアプリケーションプールに基づくワーカープロセス分離の概念を IIS 6.0 で最初に導入し、その後 IIS ではセキュリティに関する重大な脆弱性が一度も発見されていないことを発表しています。これは非常に安心できる事実なので、SharePoint ファーム内のアプリケーションプールを活用しましょう。ただし、IIS Web サイトと SharePoint Web アプリケーションは同じものを指しているわけではありません。IIS Web サイトどうしは分離できますが、SharePoint Web アプリケーションどうしは分離できません。

純粋な分離を確立できるのは、Web サイト間でリソースが共有されていない場合のみですが、SharePoint Web アプリケーションは、ファームの構成データベースなど、必ず共通のリソースを使用します。図 2 からわかるとおり、SharePoint のセキュリティアカウントを制御できれば、SharePoint 構成データベースにアクセスできることになります。セキュリティアカウントの保護についてきちんと考慮することなく SharePoint ファームを展開した場合、このようなアクセスのしくみを知ることによって不安が生じると思います。特に、共有環境で内部や外部のさまざまな顧客のサイトコレクションやサイトをホストしている場合、この不安はいっそう強まるでしょう。

図 2 SharePoint Web アプリケーション、構成データベース、およびコンテンツデータベースの関係

SharePoint サーバー上でカスタムコードを実行する

SharePoint では、既定でセキュリティアカウント情報が公開されません。詳細なアカウント情報を入手するには、悪意のあるコードを実行する必要があります。言うまでもなく、セキュリティに関する脆弱性が存在する場合、攻撃者が悪意のあるコードをアップロードできるだけでなく、サーバーに侵入しやすくなることも考えられます。

最も単純なシナリオでは、攻撃者はローカルの SharePoint サーバーにログオンするか、ターミナルサーバー経由で SharePoint サーバーにログオンして、%COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\TEMPLATE\Layouts フォルダに悪意のあるコードをコピーできる可能性があります。SharePoint では、このフォルダが各 SharePoint サイト内の仮想サブフォルダとして使用されることに注意してください。

別のシナリオでは、SharePoint 管理者が適切なテストやコード検証を行うことなく、問題のあるソースからカスタムの SharePoint ソリューションを展開することによって、無意識に悪意のあるコードを取り込んでしまう可能性があります。マスタページやコンテンツページ内に埋め込まれた ASP.NET コードも心配の種です。既定では、サーバー側スクリプトは SharePoint によって処理されませんが、SharePoint Web アプリケーションの web.config ファイルに対する書き込みアクセス権を持つユーザーであれば、サーバー側スクリプトの処理規則を変更できます。必要な操作は、web.config ファイルの <PageParserPaths> セクションに PageParserPath エントリを追加することだけです。では、実際の PageParserPath エントリのしくみについて考えてみましょう。

SharePoint を使用する開発者が皆さんを呼び出して、カスタムの ASP.NET ページの開発中に "このファイルでコードブロックは許可されていません" というエラーメッセージが表示される問題を報告したとします。皆さんはインターネットを検索して、ニュースグループまたはブログサイトで次のような解決策を見つけます。

<PageParserPath VirtualPath="/*" CompilationMode="Always" AllowServerSideScript="true" IncludeSubFolders="true" />

おそらく皆さんがセキュリティ警告を無視したか、セキュリティへの影響が通知すらされなかったのでしょう。いずれの場合も、web.config ファイルに上記の行を追加すれば、問題が解決され、だれもが幸せになります。

ただし、皆さんは知らないうちに、完全に信頼された ASP.NET ページ内でのあらゆるカスタムコードの実行を許可したことになります。ここで攻撃者が悪意のある ASP.NET ページをアップロードした場合、SharePoint 環境は危険にさらされます。図 3 からわかるように、攻撃者がサイトコレクション階層のどの部分にページをアップロードできる権限を持っているかは重要ではありません。一見関係のなさそうな小規模のチームサイトにページがアップロードされた場合でも、同様の危険が生じます。この攻撃は Web アプリケーションに影響を与え、場合によってはサーバーファーム全体に影響を与えることもあります。これは、攻撃者がコンテンツデータベースと構成データベースの両方にアクセスできるからです。

図 3 SharePoint Services Web アプリケーションを侵害する可能性のあるインライン ASP.NET コードの有効化

Dr. Jekyll と Mr. Hyde について

では、攻撃者がセキュリティアカウントの資格情報を正確に把握していない場合、その攻撃者はどのようにしてコンテンツデータベースや構成データベースにアクセスするのでしょうか。実は、このしくみは比較的単純です。SharePoint Web アプリケーションを実行する IIS ワーカープロセスは、SharePoint ユーザーの権限を借用し、取得したスレッドトークンを使用してアクセスの確認を実行します。たとえば、Dr. Jekyll は自分のセキュリティトークンにアクセスが許可されたすべての SharePoint リソースにアクセスできます。ただし、SharePoint Web アプリケーションは IIS ワーカープロセスのプロセストークンも保持します。これは、SharePoint のセキュリティアカウントに割り当てられるセキュリティトークンです。

静的な WindowsIdentity.Impersonate メソッドを呼び出してゼロのポインタを渡し、借用した権限を元に戻すと、Mr. Hyde が現れます (図 4 と図 4a 参照)。Dr. Jekyll はデータベースに直接アクセスできませんが、Mr. Hyde はアクセスできます。この状態から SQL Server に接続し、T-SQL クエリを実行するのは簡単です。

図 4 SharePoint Web アプリケーションが保持する 2 種類のセキュリティコンテキスト (画像をクリックすると拡大表示されます)

図 4a SharePoint Web アプリケーションが保持する 2 種類のセキュリティコンテキストを取得するためのコード

private string GetMrHyde()
{
    string retVal = string.Empty;
    retVal = "Dr Jekyll is: " + WindowsIdentity.GetCurrent().Name + "<br>";

    WindowsImpersonationContext impCtx = WindowsIdentity.Impersonate(IntPtr.Zero);

    retVal += "Mr Hyde is: " + WindowsIdentity.GetCurrent().Name + "<br>";

    impCtx.Undo();
    return retVal;
}

プロセスの分離とセキュリティアカウント

アプリケーションプールとセキュリティアカウントを使用しても、検証されていないコードを実行するように構成された Web アプリケーション内のサイトコレクションやサイトを保護することはできません。アプリケーションプールとセキュリティアカウントを使用する目的は、あるサイトが悪用され、攻撃者が悪意のあるコードをサーバー上に挿入して他のサイトを攻撃できるようになった場合の影響を、プロセスの分離によって軽減することです。プロセスを分離できればこの目的は達成されますが、分離を実現するには、異なるセキュリティアカウントを使用するアプリケーションプール内で実行される別の Web アプリケーション内に、他のサイトを配置する必要があります。

アカウントの資格情報は、適切に保護する必要があります。この資格情報が保護されなければ、構成作業を行う意味がなくなります。このような機密性の高いセキュリティ資格情報を直接悪意のある人物に渡す簡単な方法は、アプリケーションプールアカウントに IIS メタベースへのアクセスを許可することです。IIS メタベースは、E-mail Integration Web サービスの一部である Directory Management Service を実行するために必要です。アプリケーションプールアカウントからメタベースにアクセスできれば、攻撃者は借用した権限を元に戻し、すべてのアカウントとパスワードをクリアテキストで取得できます (図 5 と図 5a 参照)。取得したいずれかのセキュリティアカウントを使用して悪意のあるコードを実行し、すべてのコンテンツデータベースへの SQL Server 接続を確立すると、攻撃者はプロセスの分離による保護を回避できるようになるので、サーバーファーム全体が失われます。

図 5 IIS メタベースからのセキュリティアカウント情報の取得

図 5a IIS メタベースからセキュリティアカウント情報を取得するためのコード

private string GetMetabaseAppPoolIDs()
{
        WindowsImpersonationContext impCtx = WindowsIdentity.Impersonate(IntPtr.Zero);
        string retVal = string.Empty;
        try
        {
            string metabasePath = "IIS://localhost/w3svc/AppPools";
            DirectoryEntry appPools = new DirectoryEntry(metabasePath);
            foreach (DirectoryEntry appPool in appPools.Children)
            {
            switch (int.Parse(appPool.Properties["AppPoolIdentityType"].Value.ToString()))
            {
                case 0: // Local System
                    retVal += "<br>" + appPool.Name
                        + " (Local System)";
                    break;
                case 1: // Local Service
                    retVal += "<br>" + appPool.Name
                        + " (Local Service)";
                    break;
                case 2: // Network Service
                     retVal += "<br>" + appPool.Name
                        + " (Network Service)";
                     break;
                case 3: // Custom 
                    retVal += "<br>" + appPool.Name
                        + " (" + appPool.Properties["WAMUserName"].Value
                        + " [Pwd: " + appPool.Properties["WAMUserPass"].Value
                        + "])";
                    break;
               }
            }
         }
        catch (Exception ee)
         {
        retVal = "Metabase " + ee.Message;
         }

        impCtx.Undo();
}

メタベースへのアクセスを必要としない Directory Management Service ソリューションに興味がある場合は、2008 年 9 月号のコラム「SharePoint のディレクトリ統合」を参照してください。

構成データベースのセキュリティアカウント

規則に従って、アプリケーションプールアカウントに SharePoint サーバーの IIS メタベースに対する管理者権限も、読み取りアクセス権も付与しないようにすれば、図 5 のコードを実行しても、アクセスが拒否されたことを示すメッセージが表示されるだけです。ただし、セキュリティアカウント情報は構成データベースからも入手できます。また、既に説明したように、Mr. Hyde はこのデータベースにアクセスできます。

SharePoint のセキュリティアカウントによる構成データベースへのアクセスは拒否できず、対応する SQL Server 接続文字列が格納されたレジストリキーへのアクセスも拒否できません。SQL Server 2005 Express を使用している場合、この接続文字列をそのまま使用できないこともありますが、現在の SharePoint サイトコレクション (SPContext.Current.Site.ContentDatabase.DatabaseConnectionString)、およびローカルファームの名前 (SPFarm.Local.Name) に対応する構成データベースの名前から正しいデータソースの情報を導き出すことができます。

残念ながら、このようなちょっとした対策では攻撃を防ぐことができません。SQL Server と SQL Server Express のどちらを使用するかに関係なく、Mr. Hyde は図 6 と図 6a に含まれる情報を取得できます。ただし、パスワードは暗号化されているので、攻撃が完全に成功するわけではありません。

図 6 構成メタベースからのセキュリティアカウント情報の取得

図 6a 構成メタベースからセキュリティアカウント情報を取得するためのコード

private string EnumAppPoolAccounts()
{
    string retVal = string.Empty;
    try
    {
       WindowsImpersonationContext impCtx = WindowsIdentity.Impersonate(IntPtr.Zero);

       string regConfigDB = @"SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\Secure\ConfigDB";
       RegistryKey keyConfigDB = Registry.LocalMachine.OpenSubKey(regConfigDB);

       string ConfigDB = (string)keyConfigDB.GetValue("dsn");

       SqlConnection sqlConn = new SqlConnection(ConfigDB);
       sqlConn.Open();

       SqlCommand sqlCmd = new SqlCommand("SELECT Name, Properties FROM Objects"
          + " WHERE ClassId = 'B8369089-08AD-4978-B1CB-C597B5E90F64'", sqlConn);
       sqlCmd.CommandType = System.Data.CommandType.Text;
       SqlDataReader sqlReader = sqlCmd.ExecuteReader();

          while (sqlReader.Read())
          {
             retVal += "<br>" + sqlReader.GetString(0);
             string appPoolXML = sqlReader.GetString(1);
             if (!string.IsNullOrEmpty(appPoolXML))
             {

                 XmlDocument xmlDoc = new XmlDocument();
                 xmlDoc.LoadXml(appPoolXML);

                 XmlElement root = xmlDoc.DocumentElement;
                 XmlNode ndType = root.SelectSingleNode("/object/fld[@name=                   'm_IdentityType']");
                 if (ndType != null && ndType.InnerText.ToLower() != "specificuser")
                 {
                     retVal += " (" + ndType.InnerText + ")";
                 }
                 else
                 {
                     retVal += " (" 
                         + root.SelectSingleNode("/object/sFld[@name='m_Username']").InnerText
                         + " [Pwd: " 
                         + root.SelectSingleNode("/object/fld[@name='m_Password']").InnerText
                         + "])";
                 }
             }
          }
          sqlReader.Close();
          sqlConn.Close();
          impCtx.Undo();
    }
    catch (Exception ee)
    {
          retVal = ee.Message;
    }
    return retVal;
}

パスワードの暗号化を解除しなくても、同じセキュリティアカウントを使用するアプリケーションプールは既にわかる状態になっています。たとえば、図 6 では、SharePoint Central Administration v3、および SharePoint - 80 というアプリケーションプール内で Network Service アカウントが使用されています。SharePoint - 80 が攻撃を受けた Web アプリケーションだとすると、SharePoint Central Administration v3 も攻撃を受けることになります。これに対応するセキュリティアカウントは、サーバーの全体管理アカウントです。このアカウントは、SharePoint サーバー上で昇格した権限を持っています。

この構成を標準的な Web アプリケーションプールに使用することはお勧めしませんが、SharePoint 製品とテクノロジ構成ウィザードでは、1 台のサーバーに SharePoint をインストールするときに、この構成が既定で適用されます。したがって、各自の SharePoint 環境内で使用されるセキュリティアカウントの構成を確認し、必要に応じて変更することが非常に重要です。マイクロソフトサポート技術情報の記事「SharePoint Server 2007 および Windows SharePoint Services 3.0 のサービスアカウントとサービスアカウントのパスワードを変更する方法」では、このトピックに関する詳しい説明が提供されています。

セキュリティアカウントと資格情報キー

では、サーバーの全体管理アカウントのどこに問題があるのでしょうか。最も重要な点は、サーバーの全体管理アカウントを使用すると、通常のアプリケーションプールアカウントを使用する場合とは異なり、セキュリティアカウントに対応するパスワードの暗号化を解除するための資格情報キーが格納されたレジストリ内の場所にアクセスできることです。

図 7 は、このパラメータとその既定の設定を示しています。ご覧のとおり、ローカルの Administrators、WSS_RESTRICTED_WPG グループ (サーバーの全体管理アカウントを含む)、および SYSTEM アカウントはこのキーにアクセスできます。したがって、SharePoint Web アプリケーションでは、ローカルの管理者権限を持つアカウント、サーバーの全体管理アカウント、および SYSTEM アカウントを使用しないようにする必要があります。また、SharePoint Web アプリケーションからこのような資格情報キーにアクセスできないようにする必要があります。

図 7 FarmAdmin レジストリキーにアクセスするためのアクセス許可の割り当て

ただし残念ながら、この対策を実施しても、経験豊富な攻撃者が CredentialKey やセキュリティアカウントのパスワードを特定できなくなる保証はありません。経験豊富な攻撃者は、SYSTEM トークンの乗っ取りやパスワードの解読によってこのような情報を特定できます。また、保護されていない場所に資格情報キーをエクスポートできる悪意のあるコードをマスタページやコンテンツページ内に配置し、ローカルの管理者権限を持つユーザーがサイトにアクセスするまで待機することによって、情報を特定することもできます。おわかりのように、検証されていないコードをサーバー上で許可しないことが重要です。

SharePoint の関連リソース

	SharePoint 製品およびテクノロジ Web サイト
	Windows SharePoint Services TechCenter
	Windows SharePoint Services デベロッパーセンター
	Microsoft SharePoint 製品とテクノロジチームのブログ

SYSTEM トークンの乗っ取りについては、もう少し詳しく説明する価値があります。これは、Network Service などの組み込みのシステムアカウントが SharePoint Web アプリケーションによって使用されないようにすれば、このような攻撃を防ぐことができるからです。事実、Argeniss の創立者兼 CEO の Cesar Cerrudo 氏はこの脆弱性を発見し、アラブ首長国連邦のドバイで開催された HITBSecConf2008 Deep Knowledge Security Conference で攻撃を実演しました。彼は、Network Service アカウントで実行される ASP.NET Web アプリケーションで、リモートプロシージャコール (RPC) 内に DLL を挿入して、SYSTEM の特権レベルで実行される RPC サービス内のスレッドのセキュリティトークンを乗っ取る方法を紹介しました。

このような操作を実行すると、攻撃者は乗っ取った SYSTEM セキュリティアカウントを WindowsIdentity.Impersonate に渡すだけで、CredentialKey レジストリパラメータや保護されているその他のリソースにアクセスできます。この脆弱性はマイクロソフトで確認されているので、Network Service アカウントを SharePoint Web アプリケーションに使用しないようにしてください。

鉄則を守る

「セキュリティに関する 10 の鉄則」はだいぶ前に Microsoft Security Response Center によって公開されましたが、現在でもこれらの鉄則は有効です。最近、Jesper M. Johansson が「セキュリティに関する 10 の鉄則再考」という 3 部シリーズを執筆しました。SharePoint サーバーファームを設計するときは、この鉄則を考慮してください。また、SharePoint のセキュリティに関するガイドラインやワークシートに従って、信頼性の高いセキュリティアカウントの構成を使用することをお勧めします。

鉄則の内容を簡単に述べると、強力なパスワードを使用すること、SharePoint サーバー上で昇格した権限をセキュリティアカウントに付与しないこと、頻繁にパスワード (ファームの資格情報も含む) を変更すること、完全なコンピュータセキュリティが存在しないように、共通のリソースを使用する SharePoint Web アプリケーションどうしを完全に分離する方法も存在しないことを覚えておくことなどがあります。さらに、サーバーのコード実行規則を変更せず、検証されていないアセンブリをサーバー上で使用しないようにし、Windows SharePoint Services のセキュリティアカウントに関する要件が記載されたワークシートに従ってセキュリティアカウントを構成すれば、ある程度は安全な SharePoint 環境が提供されると考えてよいでしょう。

ただし、組織の要件がサイトコンテンツを厳密に分離することである場合は、対応するサイトコレクションを別々のサーバーファーム内、場合によっては別々の Active Directory フォレストや SQL Server 環境内でホストすることをお勧めします。

Pav Cherny は、主にコラボレーションとユニファイドコミュニケーションに関するマイクロソフトテクノロジを扱う IT 専門家であり、IT 関連書籍の執筆も行っています。これまでに、IT の運用とシステム管理についてのホワイトペーパー、製品マニュアル、書籍などを執筆してきました。Pav は、ドキュメント管理とローカライズサービスの専門企業 Biblioso Corporation の代表取締役です。

目次

図 4a SharePoint Web アプリケーションが保持する 2 種類のセキュリティ コンテキストを取得するためのコード

図 5a IIS メタベースからセキュリティ アカウント情報を取得するためのコード

図 6a 構成メタベースからセキュリティ アカウント情報を取得するためのコード

その他のリソース

図 4a SharePoint Web アプリケーションが保持する 2 種類のセキュリティコンテキストを取得するためのコード

図 5a IIS メタベースからセキュリティアカウント情報を取得するためのコード

図 6a 構成メタベースからセキュリティアカウント情報を取得するためのコード