ASP ページの認証問題のトラブルシューティング

Windows ベースのアプリケーションまたはコマンド ライン アプリケーションでは動作するが、ASP.NET アプリケーションに転送すると動作しないアプリケーションがある場合、その問題にはセキュリティが関係している可能性があります。System.DirectoryServices 名前空間は、Active Directory サービス インターフェイス (ADSI : Active Directory Services Interfaces) を使用して、異なる ADSI プロバイダを通じて個別のディレクトリ サービスにアクセスします。このトピックでは、アプリケーションの開発者は、ディレクトリへのアクセスが ASP.NET Web ユーザーのセキュリティ コンテキストで行われることを意図していると想定しています。そのセキュリティ コンテキストでアクセスしない場合、つまりこのトピックで説明する解決方法を実行しない場合は、クラス コンストラクタを使用して DirectoryServices コードに資格情報を渡すか、Username および Password プロパティを使用することによってこれらの問題を回避できます。

プライマリ トークンとは

Active Directory ドメイン サービスは、Windows 2000 Server のセキュリティ機構に依存しています。Active Directory ドメイン サービスの大部分のデータにアクセスするには、Active Directory ドメイン サービス データの要求時に Windows 2000 Server に資格情報を提供します。資格情報はプライマリ トークンの形式で提供する必要があります。つまり、IIS サーバーが Active Directory ドメイン サービスに渡すパスワードのハッシュではなくパスワードを保持している必要があります。

コードが、Web サーバーである開発コンピュータから参照すると正常に実行されるが、他の Web クライアントからページにアクセスすると正常に実行されない場合、次のようなエラー メッセージが表示されることがあります。

"Failed: System.Runtime.InteropServices.COMException 
(0x80005000): Unknown error (0x80005000) at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail)"
"The specified directory service attribute or value does not exist" 

このエラーは、プライマリ トークンがなかったことを意味します。

プライマリ トークンの取得方法

Web.config ファイルで、identity impersonate="true"/ および authentication mode="Windows" を設定した場合、次のように設定した匿名アカウントを使用します。

匿名アカウントを使用してトークンを取得するには

  1. ASPX ページで、セキュリティ機構を "匿名のみ" に設定します。

  2. [IIS によるパスワードの管理を許可する] チェック ボックスをオフにします。

  3. 匿名アカウントをドメイン ユーザーに設定します。

Web.config と Machine.config を次のように設定した場合

構成設定を使用してトークンを取得するには

  1. Web.config で identity impersonate="false"/ および authentication mode="Windows" を設定した場合。

  2. Machine.config で processModel username=<domain>\<username>、password=<password> と設定した場合。Web.config ファイルで identity impersonate="false"/ を指定した場合、基本プロセスの資格情報が使用されます。ドメイン ユーザーとパスワードを提供すると、IIS から AD DS にプライマリ トークンを渡すことができます。

ダブルホップの問題

ダブルホップの問題は、ASPX ページが IIS サーバーとは別のサーバー上に存在するリソースを使用しようとしたときに発生します。この場合、Web ブラウザ クライアントから IIS ASPX ページへが 1 番目の "ホップ"、そこから Active Directory ドメイン サービスへが 2 番目のホップです。Active Directory ドメイン サービスはプライマリ トークンを要求します。したがって、IIS サーバーは、Active Directory ドメイン サービスにプライマリ トークンを渡すためには、クライアントのパスワード情報を保持している必要があります。IIS サーバーにセカンダリ トークンがある場合、NTAUTHORITY\ANONYMOUS アカウントの資格情報が使用されます。このアカウントはドメイン アカウントではないため、Active Directory ドメイン サービスへのアクセスが大幅に制限されます。

セカンダリ トークンを使用するダブルホップが発生するのは、たとえば、ブラウザ クライアントが NTLM 認証を使用して IIS ASPX ページに対して認証される場合です。この例では、NTLM を使用した結果、IIS サーバーはハッシュされたバージョンのパスワードを保持しています。IIS が Active Directory ドメイン サービスに資格情報を渡す場合、IIS はハッシュされたパスワードを渡します。Active Directory ドメイン サービスではそのパスワードを検証できないため、代わりに、NTAUTHORITY\ANONYMOUS LOGON を使用して認証します。

ブラウザ クライアントが基本認証を使用して IIS ASPX ページに対して認証される場合は、IIS サーバーにクライアントのパスワードが保持されているため、プライマリ トークンを作成して Active Directory ドメイン サービスに渡すことができます。Active Directory ドメイン サービスは、そのパスワードを検証し、ドメイン ユーザーを認証できます。

ダブルホップの問題のトラブルシューティング

ダブルホップの問題のトラブルシューティングには次の方法のいずれかを使用します。

これがアクセス許可の問題かどうかをすばやく判断するには、次の手順を行います。

アクセス許可の問題について確認するには

  1. ASPX ページのセキュリティ機構を、基本認証のみを使用するように設定します。

  2. クライアントを使用して ASPX ページを参照し、要求されたらドメインの資格情報を入力します。

    この方法で正常に実行される場合、原因はダブルホップの問題であると考えられます。

Active Directory ドメイン サービスへのアクセス時に発生する IIS ASPX の問題をトラブルシューティングするためのもう 1 つのテスト方法は、ASPX コードを IIS 環境から取り出し、IIS サーバー上でスクリプト ファイルとして実行することです。この方法を使用するには、次の手順を実行します。

コードをテストするには

  1. ブラウザで使用しようとしていたのと同じドメイン アカウントで IIS サーバーにログオンした後、そのコードを実行します。

    このテストでは、環境から IIS サーバーが除外されるため、問題のトラブルシューティングに役立ちます。

  2. 問題がダブルホップ問題かどうかを判断するには、ディレクトリ サービス オブジェクトの監査を有効にします。ログを有効にすると、イベントがセキュリティ イベント ログに書き込まれます。

    ダブルホップ問題である場合は、セキュリティ イベント ログで次のようなイベントが見つかります。

    Event Type: Success Audit
    Event Source: Security
    Event Category: Directory Service Access 
    Event ID: 565
    Date:  3/27/2002
    Time:  3:21:41 PM
    User:  NT AUTHORITY\ANONYMOUS LOGON
    Computer: TESTDC
    Description:
    Object Open:
      Object Server: DS
      Object Type: user
      Object Name: CN=Users,DC=corp,DC=com
      New Handle ID: 0
      Operation ID: {0,68019232}
      Process ID: 264
      Primary User Name: TESTDC$
      Primary Domain: TESTDOM
      Primary Logon ID: (0x0,0x3E7)
      Client User Name: ANONYMOUS LOGON
      Client Domain: NT AUTHORITY
      Client Logon ID: (0x0,0x40DE417)
      Accesses  READ_CONTROL 
    
      Privileges  -
    
     Properties: 
    
    ms180891.note(ja-jp,VS.90).gifメモ :
    ディレクトリ サービスへのアクセスが、匿名ユーザーとして実行されています。これは、Web ユーザーの資格情報をディレクトリ サービスに正しく渡すことができないためです。

ASP .NET 基本アカウント

既定では、すべての ASP.NET アプリケーションは基本プロセス アカウントである MACHINENAME\ASPNET で実行されます。これは、Active Directory ドメイン サービス内のオブジェクトに対するアクセス許可を持たないローカル アカウントです。IIS に渡される資格情報を使用して Active Directory ドメイン サービスにアクセスするには、Web.config ファイルを変更して、identity impersonate="true" と authentication mode="Windows" のパラメータを含める必要があります。この 2 つのパラメータが存在すると、ASP.NET では IIS から渡された資格情報でコードが実行されます。

ms180891.note(ja-jp,VS.90).gifメモ :
これは、従来の ASP の現在の処理方法に似ています。高分離アプリケーションまたはアウト プロセス (OOP : Out-of-Process) アプリケーションは、実際には独立した DllHost プロセスで実行されます。DllHost の基本プロセスは IWAM_machinename です。この OOP に対して呼び出しが行われると、OOP は IIS によって認証されたユーザーを偽装します。ASP.NET では、ページも独立したプロセスで実行されます。このプロセスが Aspnet_wp.exe です。アプリケーション デザイナは、identity impersonate タグを使用して、偽装を行うかどうかを制御します。

ASP.NET 基本アカウントが正しく設定されていない場合に表示される可能性のあるエラー

ASP.NET 基本アカウントが正しく設定されていないと、次のいずれかのエラー メッセージが表示されることがあります。

Cannot contact the specified domain or domain does not exist
Logon Failure: Unknown Username or bad password

ASP.NET 基本アカウントのトラブルシューティング

この問題をトラブルシューティングするには、次の問題について確認します。

  • 偽装を使用するように Web.config ファイルを変更しても、DirectoryServices コードが正常に実行されず、同じエラーが表示される場合は (詳細については、この記事で前に述べたエラーを参照)、IIS の既定の動作が原因で問題が発生している可能性があります。既定では、IIS の新しい仮想ディレクトリ セットアップによって匿名認証が有効になっています。これを解決するには、インターネット サービス マネージャを開き、仮想ディレクトリの認証方法を変更し、[匿名認証] チェック ボックスをオフにします。

  • Invoke を実行して、基になる ADSI インターフェイスで SetPassword (または公開されているその他のメソッド) を呼び出しても、次のメッセージが表示されます。

    The Active Directory property cannot be found in the cache
    

    返されるエラー番号は 0x8000500D ではありません。期待される動作は、この説明と共にエラー番号 0x8000500D が返されることです。
    次に例を示します。

    COMException (0x80020006): The Active Directory property cannot be found in the cache
    

    混乱するのは、エラー番号によって示されるこのエラーの原因とエラーの説明とが対応していない場合があることです。このエラーの原因はエラー番号によって示されており、エラーの説明によってではありません。通常、問題の解決方法は、エラーの説明からではなく、エラー番号から判断できます。この例では、エラー番号は DISP_E_UNKNOWNNAME に対応しています。

  • IIS サーバーがドメイン コントローラまたはバックアップ ドメイン コントローラで実行されている場合は、既定の基本アカウントが機能せず、エラーが表示されることがあります。

  • 基本 IIS サーバーに、ルート Web サイトに対する読み取り、実行、および一覧のアクセス許可がない場合、Web ページを参照するときにエラーが発生します。

ADSI スキーマ キャッシュ

ADSI では、Active Directory ドメイン サービスからスキーマをキャッシュしようとします。スキーマキャッシュは、属性キャッシュから属性を読み取る方法の判断に使用されます。ADSI でスキーマをキャッシュできない場合は、V2 バージョンのスキーマが使用されます。V2 バージョンのスキーマには、ごく少数の属性が含まれています。

ADSI では、プロセスごとに 1 回だけスキーマのキャッシュが試みられます。Windows 2000 では、ASP.NET がシングル aspnet_wp.exe プロセスで実行されます。つまり、IIS サービスがシャットダウンされ、再開されるまで、スキーマが再度キャッシュされることはありません。

その後のスキーマ キャッシュへのアクセスは、そのサーバー上の ADSI を使用する ASP.NET ページを最初に実行したユーザーのユーザー権限に依存する場合があります。

多くの場合、管理者は Web ブラウザをローカルで起動して、アプリケーションが正常に実行されることを確認します。その後 Web サイトは実稼動に移され、サーバーが再起動されるか、Web サービスが再開されるまでの間、機能します。

ADSI によりスキーマが正常にキャッシュされていないため、この時点で、ASP.NET アプリケーションは正常に実行されなくなります。Web サイトに最初にアクセスするユーザーが、スキーマを正常にキャッシュするための資格情報を確立できない場合、この問題が発生することがあります。これが起こりやすいのは、この記事の前半で説明したダブルホップ問題が発生しているときです。"アクセス許可が拒否されました" または "Property not Found in Cache" のようなエラーメッセージは表示されないことがあるため、この問題が発生していることにすぐに気付かない場合があります。これは、Active Directory ドメイン サービスのインストール方法が原因の場合もあります。ドメイン内で最初のドメイン コントローラを昇格するときには、DCPromo ウィザードで、ドメインに Windows NT 4 との互換性が必要か、Windows 2000 とのみ互換性があればよいかを選択します。NT4 と互換性のある既定の設定を受け入れると、EVERYONE セキュリティ プリンシパルが Pre-Windows 2000 Compatible Access という組み込みグループに追加されます。これには大きな意味があります。それは、Pre-Windows 2000 Compatible Access グループには、既定で、ディレクトリ内の多くのオブジェクトに対する [内容の一覧表示] のアクセス許可および [すべてのプロパティの読み取り] のアクセス許可が付与されるからです。匿名ユーザーは EVERYONE としてディレクトリ サービスにアクセスするので、匿名ユーザーには、クエリで多くの属性が返され、多くの属性が属性キャッシュに読み込まれます。

ADSI で使用されるスキーマは、スキーマ名前空間の cn=Aggregate オブジェクトに格納されます。Pre-Windows 2000 Compatible Access 組み込みグループおよび EVERYONE プリンシパルはどちらもこの集約オブジェクトに対するアクセス許可がありません。したがって、スキーマ情報にはアクセスできません。その結果、ADSI で認識されないサーバーから取得したプロパティが属性キャッシュに存在することになります。ADSI ではそのデータ型を判断できないため、次に説明するエラーが表示されます。

ADSI スキーマ キャッシュ エラー

エラーが発生することがあります。サーバーを再起動した後、Web アプリケーションが応答しないと次のエラー メッセージが表示されることがあります。

0x8000500C, "The property in cache cannot be 
converted from native datatype"

このエラーは、ADSI で Active Directory ドメイン サービス スキーマを適切にキャッシュできないことを意味します。

ADSI スキーマ キャッシュの問題の訂正

  • レジストリ キーが存在する場合は、それらを削除し、IIS を停止してから再起動し、Web ページを参照します。
  • キーが作成されていないかファイルが書き込まれていない場合、サーバーからスキーマ キャッシュをダウンロードするアクセス許可を持っていないか、ファイルに書き込むアクセス許可またはレジストリ キーを作成するアクセス許可を持っていません。書き込まれている場合は、次回 IIS が再起動するときまでそのページが正常に実行されることを期待できます。この問題を解決するには、ダブルホップの問題を解決する必要があります。

関連項目

リファレンス

System.DirectoryServices
DirectoryEntry

概念

ASP.NET からの Active Directory ドメイン サービス認証

Send comments about this topic to Microsoft.

Copyright © 2007 by Microsoft Corporation. All rights reserved.