認証を構成する (Office SharePoint Server)

  • [アーティクル]

この章の内容 :

認証とは、クライアントの ID を検証するプロセスのことであり、通常は指定された機関を使用して行います。Web サイト認証は、Web サイトのリソースへのアクセスを試みているユーザーを認証済みエンティティとして確認できることを確立するのに役立ちます。 認証アプリケーションは、Web サイトへのアクセスを要求しているユーザーから資格情報を取得します。資格情報は、ユーザー名、パスワードなど、さまざまな形式の ID です。認証アプリケーションは、資格情報を認証機関に照らして検証します。資格情報が有効である場合、その資格情報を提出したユーザーは、認証済み ID と見なされます。

Office SharePoint Server の認証

使用に最も適した Office SharePoint Server 認証機構を判断するには、次の点を考慮します。

  • Windows 認証機構を使用するには、信頼された機関により認証されるユーザー アカウントをサポートする環境が必要です。

  • Windows 認証機構を使用する場合、オペレーティング システムにより、ユーザー資格情報管理タスクが実行されます。フォーム認証など、Windows 以外の認証プロバイダを使用する場合、資格情報管理システムを計画および実装し、ユーザー資格情報を格納する場所を決める必要があります。

  • ユーザーのオペレーティング システム レベルでのセキュリティ コンテキストを層にまたがって渡すことができる偽装/委任モデルを実装する必要がある場合があります。これにより、オペレーティング システムでユーザーを偽装し、ユーザーのセキュリティ コンテキストを次のダウンストリーム サブシステムに委任できるようにになります。

Microsoft Office SharePoint Server は、フロントエンド Web サーバー層、アプリケーション サーバー層、およびバックエンド データベース層の 3 つの層に論理分割される分散アプリケーションです。各層は、信頼されるサブシステムであり、各層へのアクセスに対して認証を要求できます。 資格情報の検証には、認証プロバイダが必要です。認証プロバイダは、特定の認証機構をサポートするソフトウェア コンポーネントです。Office SharePoint Server 2007 認証は、ASP.NET 認証モデルに基づいて構築されており、次の 3 つの認証プロバイダを含みます。

  • Windows 認証プロバイダ

  • フォーム認証プロバイダ

  • Web SSO 認証プロバイダ

Active Directory ディレクトリ サービスを認証に使用するか、Microsoft SQL Server データベース、LDAP (ライトウェイト ディレクトリ アクセス プロトコル) ディレクトリ、ASP.NET 2.0 メンバシップ プロバイダを備える他の任意のディレクトリなど、他のデータ ストアに対してユーザー資格情報を検証するように環境を設計することができます。メンバシップ プロバイダは、使用するデータ ストアの種類を指定します。既定の ASP.NET 2.0 メンバシップ プロバイダは、SQL Server データベースを使用します。Office SharePoint Server 2007 には LDAP v3 メンバシップ プロバイダが含まれており、ASP.NET 2.0 には SQL Server メンバシップ プロバイダが含まれています。

複数の認証プロバイダを展開して、たとえば Windows 認証を使用してイントラネット アクセスを有効にし、フォーム認証を使用してエクストラネット アクセスを有効にすることもできます。複数の認証プロバイダを使用するには、複数の Web アプリケーションを使用する必要があります。各 Web アプリケーションは、指定された領域と、単一の認証プロバイダを備える必要があります。

認証プロバイダは、Active Directory、SQL Server データベース、または Active Directory 以外の LDAP ディレクトリ サービス (NDS など) に格納されたユーザーおよびグループの資格情報に対して認証を行うために使用されます。ASP.NET メンバシップ プロバイダの詳細については、「ASP.NET アプリケーションの設定によるメンバシップの使用」(https://go.microsoft.com/fwlink/?linkid=87014&clcid=0x411) を参照してください。

Windows 認証プロバイダ

Windows 認証プロバイダは、次の認証方法をサポートします。

  • 匿名認証

    匿名認証では、ユーザーは認証資格情報を入力しなくても、Web サイトの公開エリアにあるリソースを参照できます。インターネット インフォメーション サービス (IIS) は、IUSR_computername アカウントを作成し、Web コンテンツ要求を行う匿名ユーザーを認証します。IUSR_computername アカウント (computername は、IIS を実行しているサーバーの名前) は、IUSR アカウントのコンテキストでリソースへの匿名ユーザー アクセスを許可します。有効な Windows アカウントを使用するように匿名ユーザー アクセスをリセットすることもできます。 スタンドアロン環境では、IUSR_computername アカウントはローカル サーバー上に作成されます。このサーバーがドメイン コントローラである場合、IUSR_computername アカウントは、そのドメインのアカウントとして定義されます。 既定では、匿名アクセスは Web アプリケーションの新規作成時に無効化されます。匿名アクセスの無効化により、IIS は匿名アクセス要求を処理前に拒否するようになるので、セキュリティのレイヤが追加されます。

  • 基本認証

    基本認証を行うには、ユーザー アクセス用の事前に割り当てられた Windows アカウント資格情報が必要です。基本認証により、Web ブラウザは HTTP トランザクション中に要求を送信する際に資格情報を提供できるようになります。ユーザー資格情報はネットワーク送信用に暗号化されず、プレーンテキストでネットワーク上で送信されるので、セキュリティ保護されていない HTTP 接続を通じた基本認証の使用はお勧めしません。基本認証を使用する場合は、SSL (Secure Sockets Layer) 暗号化を有効にする必要があります。

  • ダイジェスト認証

    ダイジェスト認証は基本認証と同じ機能を提供しますが、セキュリティが強化されています。ユーザー資格情報はネットワーク上にプレーンテキストで送信されず、暗号化されます。ユーザー資格情報は MD5 メッセージ ダイジェストとして送信され、元のユーザー名とパスワードは解読できません。ダイジェスト認証ではチャレンジ/レスポンス プロトコルが使用され、認証の要求者は、サーバーからのチャレンジに応じて有効な資格情報を提示するように求められます。サーバーに対して認証を行うには、クライアントは共有シークレット パスワードの文字列の含まれるレスポンスとして、MD5 メッセージ ダイジェストを提供する必要があります。MD5 メッセージダイジェスト アルゴリズムについては、Internet Engineering Task Force (IETF) RFC 1321 で詳細に説明されています (http://www.ietf.org)。

    ダイジェスト認証を使用するには、次の要件を確認してください。

    • ユーザーおよび IIS サーバーは、同じドメインのメンバであるか、同じドメインにより信頼されている必要があります。

    • ユーザーは、ドメイン コントローラの Active Directory に格納されている有効な Windows ユーザー アカウントを所有している必要があります。

    • ドメインで Microsoft Windows Server 2003 ドメイン コントローラを使用する必要があります。

    • ドメイン コントローラに IISSuba.dll ファイルをインストールする必要があります。このファイルは Windows Server 2003 のセットアップ中に自動的にコピーされます。

  • 統合 Windows 認証

    統合 Windows 認証は、NTLM または制限付きの Kerberos 委任を使用して実装できます。制限付きの Kerberos 委任は、最も安全な認証方法です。統合 Windows 認証は、ユーザーが Windows ドメイン アカウントを保持するイントラネット環境でうまく機能します。統合 Windows 認証では、ブラウザが現在のユーザーの資格情報をドメイン ログオンから使用することを試み、それが失敗した場合、ユーザー名およびパスワードを入力するように求められます。統合 Windows 認証を使用する場合、ユーザーのパスワードはサーバーに送信されません。ユーザーがローカル コンピュータにドメイン ユーザーとしてログオンしている場合、そのドメイン内のネットワーク コンピュータにアクセスするときに、認証を再び行う必要はありません。

  • Kerberos 認証

    この方法は、Microsoft Windows 2000 Server またはそれよりも新しいバージョンの Windows 上で Active Directory を実行しているサーバー用です。Kerberos は、チケット認証をサポートする安全なプロトコルです。Kerberos 認証サーバーは、有効なユーザー資格情報を含むクライアント コンピュータ認証要求に応じて、チケットを発行します。クライアント コンピュータは、そのチケットを使用してネットワーク リソースにアクセスします。Kerberos 認証を有効にするには、クライアント コンピュータおよびサーバー コンピュータがドメインのキー配布センター (KDC) への信頼関係接続を保持していることが必要です。さらに、クライアント コンピュータおよびサーバー コンピュータは、Active Directory にアクセスできる必要があります。Kerberos 認証を使用するように仮想サーバーを構成する方法の詳細については、マイクロソフト サポート技術情報の記事「Kerberos 認証を使用するように Windows SharePoint Services の仮想サーバーを構成する方法および Kerberos 認証から NTLM 認証に戻す方法」(https://go.microsoft.com/fwlink/?linkid=115572&clcid=0x411) を参照してください。

  • 制限付きの Kerberos 委任

    制限付きの認証は、複数のアプリケーション層の間で通信を行うための最も安全な構成です。制限付きの委任を使用して、元の呼び出し元の ID を複数のアプリケーション層を通じて渡すことができます。たとえば、Web サーバーからアプリケーション サーバーに渡し、さらにデータベース サーバーに渡すことができます。制限付きの Kerberos 委任はまた、アプリケーション サーバーからバックエンド データ ソースにアクセスするための最も安全な構成です。 偽装により、スレッドを、そのスレッドを所有するプロセスのコンテキスト以外のセキュリティ コンテキストで実行することができるようになります。フロントエンド Web サーバーとアプリケーション サーバーが異なるコンピュータ上で実行されるほとんどのサーバー ファーム展開では、偽装を使用するために、制限付きの Kerberos 委任が必要です。

  • 偽装と Kerberos 委任

    Kerberos 委任により、認証済みエンティティで同じフォレスト内のユーザーまたはコンピュータの資格情報を偽装できるようになります。偽装を有効にすると、偽装するエンティティは、偽装されるユーザーまたはコンピュータに代わってタスクを実行するために資格情報を使用できます。

    偽装中に、別の認証済みエンティティの資格情報を使用して ASP.NET アプリケーションを実行できます。既定では、ASP.NET の偽装は無効になっています。ASP.NET アプリケーションに対して偽装を有効にした場合、そのアプリケーションは、IIS が ASP.NET に渡すアクセス トークンの資格情報を使用して実行されます。このトークンは、ログインしている Windows ユーザーのトークンなどの認証済みユーザーのトークンであるか、または IIS が匿名ユーザーのために提供するトークン (通常は、IUSR_computername ID) である可能性があります。

    偽装が有効な場合、偽装されたユーザーのコンテキストで実行されるのはアプリケーション コードのみです。アプリケーションのコンパイルと、構成情報の読み込みは、ASP.NET プロセスの ID を使用して行われます。

    偽装の詳細については、「ASP.NET の偽装」(https://go.microsoft.com/fwlink/?linkid=115573&clcid=0x411) を参照してください。

  • NTLM 認証

    この方法は、ドメイン コントローラ上で Active Directory を実行していない Windows サーバー用です。NTLM 認証は、Kerberos 認証をサポートしないクライアント コンピュータから認証要求を受信するネットワークで必要です。NTLM は、ユーザー資格情報の暗号化とネットワーク上での送信をサポートする安全なプロトコルです。NTLM では、ユーザー名とパスワードを暗号化してからネットワークに送信します。NTLM 認証は、サーバーが Kerberos 認証をサポートしないクライアント コンピュータから要求を受信するネットワークで必要です。 NTLM は、Windows NT Server、Windows 2000 Server ワークグループ環境、および多くの Active Directory 展開で使用される認証プロトコルです。NTLM は、Windows NT システムを認証する必要がある混在 Windows 2000 Active Directory ドメイン環境で使用されます。Windows 2000 Server を、下位レベルの Windows NT ドメイン コントローラが存在しないネイティブ モードに変換すると、NTLM は無効になります。そして Kerberos が企業のための既定の認証プロトコルになります。

フォーム認証プロバイダ

フォーム認証プロバイダは、Active Directory 内に格納されている資格情報、SQL Server データベースなどのデータベースに格納されている資格情報、または Novell eDirectory、Novell Directory Services (NDS)、Sun ONE などの LDAP データ ストア内に格納されている資格情報との照合による認証をサポートします。フォーム認証では、ログオン フォームに入力された資格情報の検証に基づいてユーザー認証を行うことができます。認証されていない要求はログオン ページにリダイレクトされ、このページでユーザーは有効な資格情報の入力とフォームの送信を求められます。要求が認証されると、その後の要求で使用する ID を再確立するためのキーを含む Cookie が発行されます。

Web シングル サインオン (SSO) 認証プロバイダ

Web SSO は、ネットワーク境界にまたがる安全な通信をサポートすることから、フェデレーション認証または委任認証とも呼ばれます。

SSO は、ユーザー資格情報の認証が 1 回成功した後に、セキュリティ保護された複数のリソースへのアクセスを可能にする認証方法です。SSO 認証の実装にはいくつかの種類があります。Web SSO 認証は、1 つの組織内で認証されたユーザーが別の組織内の Web アプリケーションにアクセスできるようにすることで、ネットワーク境界にまたがる安全な通信をサポートします。Active Directory フェデレーション サービス (ADFS) は、Web SSO をサポートします。ADFS のシナリオでは、2 つの組織で、一方の組織のユーザーが他方の組織によって制御される Web ベース アプリケーションにアクセスできるようにするフェデレーション信頼関係を作成できます。ADFS を使用して Web SSO 認証を構成する方法の詳細については、「ADFS を使用して Web SSO 認証を構成する (Office SharePoint Server)」を参照してください。 この手続きを Stsadm コマンドライン ツールを使用して実行する方法の詳細については、「Authentication : Stsadm 操作 (Office SharePoint Server)」を参照してください。

このブックをダウンロードする

このトピックは、簡単に読んだり印刷したりできるように、次のダウンロード可能なブックに収められています。

入手できるすべてのブックの一覧については、Office SharePoint Server のテクニカル ライブラリを参照してください。