この文章は auth_lda 1.6のドキュメントを 私が勝手に和訳したものです。
apache 1.3時代のものです。現在はapacheに内蔵されています

The auth_ldap Module for Apache

これは LDAPディレクトリーをもちいて HTTPクライアントを認証する機能をApacheに提供する Apache用の認証モジュールです。
現在の安定バージョンは1.6.1 最新の開発リリースは1.7.0 最新バージョンと変更履歴はいつでも http://www.rudedog.org/auth_ldap/. で参照できます。

auth_ldapには以下の特徴があります:

Contents

モジュールの構築

このモジュールはApache 1.3.x用です。 SSL拡張を利用するにはNetscape SDKを利用する必要があります。 TLSを利用するにはOpenLDAP 2.xSDKを利用する必要があります。

UNIX環境では,auth_ldapは Apache's apxsプログラムをもちいて DSO (Dynamic Shared Object)として構築できます。 Configureを利用する古いスタイルの構築方法もありますが、 私は個人的にはその方法を使っていません、 だから私はこのやりかたを保証できません。 この章ではauth_ldapをDSOとして構築する方法を紹介します。

Windows NTのもとで構築のためにVisual C++5.0用のmakefileが提供されていることに注意して下さい。

  1. Makefileを生成するために configureスクリプトを走らせてください。 configureは以下のオプションを受け付けます。
    オプション コメント
    --with-apxs=/path/to/apxs Apacheのapxsコマンドのパスを指定します。提供されなければconfigureが探すでしょう
    --with-ldap-sdk=sdk LDAP SDKを指定します。 OpenLDAPの場合openldap. Netscapeの場合netscape. それ以外ならother. デフォルトはopenldapです.
    --with-sdk-headers=/path/to/headers LDAP SDKのインクルードファイルのあるディレクトリを指定。
    --with-sdk-libs=/path/to/libs LDAP SDKライブラリのあるディレクトリを指定.
    --with-ssl SSLサポートでauth_ldapを構築する.
    --with-shared-cache LDAPのキャッシュの共有をサポートします。 デフォルトでは共有キャッシュが可能になります。 これを行わないためには--without-shared-cacheを指定します。 共有キャッシュを利用するには ApacheがMMをサポートするように構築されている必要があります。 ApacheがMMをサポートしていなければ、有効になっていてもこのオプションは何もしません, このオプションは無視するのが安全です。
    --with-activate インストール時にApacheのhttpd.conf を書き換えてauth_ldapを有効にする。
    --with-frontpage Include support for the FrontPage hack.
  2. モジュールをインストールするために make; make install を走らせてください。
  3. モジュールをロードするには以下のLoadModuleディレクティブを httpd.conf に設定します。
    # Unix用
    LoadModule   auth_ldap_module    libexec/auth_ldap.so
    
    # Windows NT用
    LoadModule   auth_ldap_module    modules/AuthLDAP.dll

私がNTにあまり簡単に触れられないので、 このモジュールはWindowsNTではあまりテストされていません、 NTのApacheはスレッド化されているので、多くの競合があります。 私は、ほとんどの競合を処理しました ロックがきれいなにもかかわらず粗悪な粒を有します。 と私は考えます。 もしあなたがどんなモジュールがWindows NTのもとでのよいまたは悪い経験でも持っていれば、 どうか知らせてください、それで私は、これらの命令とモジュールを改善することができます。 私は、NTのためのコード改善を受けることに特にオープンです。

オペレーション

ユーザーにアクセス権限を与えるまでには2つの段階があります。 第一段階は認証(Authentication)です,ユーザの認証情報が有効かどうかを確かめます。 この段階はsearch/bind段階とも呼ばれます。 第二段階は権限付与(authorization)です, 認証されたユーザがリソースにアクセス可能かどうかを決定します。 これはcompare段階として知られています。

認証(Authentication)段階

認証(Authentication)段階では, auth_ldapは HTTPクライアントから渡されたユーザ名と一致するエントリーをディレクトリから検索します。 検索結果が1件だけのときにはauth_ldapは 検索で見つかった識別名(DN)と HTTPクライアントから渡されたパスワードをつかって ディレクトリーサーバーにbindをしようと試みます。 検索してバインドするので,search/bind段階と呼ばれます。 Here are the steps taken during the search/bind phase.

  1. AuthLDAPURLで与えられた属性およびフィルターと HTTPクライアントから送られてきたユーザ名と を組み合わせて検索フィルターを生成します。
  2. 生成されたフィルターを使ってディレクトリを検索します。 もし検索結果が1件出なかったら、アクセスを拒否します。
  3. 検索結果のエントリーから識別名(DN)を取り出します。 そのDNとHTTPクライアントから送られてきたパスワードを使って LDAPサーバにbindします。 bindが不成功ならば,アクセスを拒否します。

以下のディレクティブはsearch/bind段階で使います。

AuthLDAPURL LDAPサーバー、検索のベースDN、検索で使う属性,拡張の検索フィルターを指定します。
AuthLDAPBindDN search段階でのbind時にもちいるDN
AuthLDAPBindPassword search段階でのbind時にもちいるパスワード

権限付与(Authorization)段階

権限付与段階の間に、auth_ldapは、ユーザーが資源にアクセスする権利があるかを決定するように試みます。 多くのこれらのチェックは、LDAPサーバーでauth_ldapに比較操作をするように要求します。 これがなぜこの段階がしばしばcompare段階と呼ばれるかの理由です。 auth_ldapは以下の requireディレクティブ directives を受け入れます:

compare段階ではauth_ldapは以下のディレクティブを利用します。

AuthLDAPURL require user操作のために URLに指定されている属性がcompare操作で使われる
AuthLDAPCompareDNOnServer require dnディレクティブの振る舞いをきめます
AuthLDAPGroupAttribute 比較のために使うべき属性を決めますrequire groupディレクティブ用
AuthLDAPGroupAttributeIsDN ユーザDNまたはユーザ名のどちらを利用するかを指定します。require groupディレクティブ用

Auth_ldapのディレクティブ

auth_ldapモジュールで利用するディレクティブの完全なリストです。

AuthLDAPAuthoritative

Syntax: AuthLDAPAuthoritative < on(default) | off >
Context: directory, .htaccess
Override: AuthConfig
Status: Extension
Module: auth_ldap

offにすると ユーザを認証がこのモジュールでは失敗して このモジュールが他の認証モジュールを利用しようと試みる (クライアントから渡された)ユーザ名がDNかルールになかった場合 コントロールは、下位のモジュールに単に渡されます。


AuthLDAPBindDN

Syntax: AuthLDAPBindDN distinguished-name
Context: directory, .htaccess
Override: AuthConfig
Status: Extension
Module: auth_ldap

LDAPを検索するためのbindに利用するDNを指定します。 与えられなければanonymous bindで検索します。


AuthLDAPBindPassword

Syntax: AuthLDAPBindPassword password
Context: directory, .htaccess
Override: AuthConfig
Status: Extension
Module: auth_ldap

bindのDNとともに使うべきbindのパスワード。 bindのパスワードがたぶん敏感なデータであって、 そして適切に保護されるべきことに注意して下さい。 あなたは、もしディレクトリーを検索に必要がある場合にだけ AuthLDAPBindDNAuthLDAPBindPassword を使うべきです。


AuthLDAPCacheSize

Syntax: AuthLDAPCacheSize size
Context: server config
Override: Not Applicable
Status: Extension
Module: auth_ldap

メインLDAPキャッシュの最大サイズを指定します。 キャッシュには成功したsearch/bindが入っています。 search/bindキャッシュを無効にするには0を設定してください。 デフォルトは1024の受け取った検索です。 完全な情報はauth_ldapのキャッシュの章を参照してください。


AuthLDAPCacheTTL

Syntax: AuthLDAPCacheTTL time
Context: server config
Override: Not Applicable
Status: Extension
Module: auth_ldap

search/bindキャッシュの有効時間を秒数で指定します。 デフォルトは600秒です 0はキャッシュが無効にならないという意味になります。


AuthLDAPCertDBPath

Syntax: AuthLDAPCertDBPath /path/to/cert7.db/directory
Context: server config
Override: Not Applicable
Status: Extension
Module: auth_ldap

auth_ldapがどのディレクトリーで証明書当局データベースを探すべきかを指定します。 cert7.dbという名前のファイルの存在するディレクトリ名です。 (NetscapeのSDKでsslを行う時に必要cert7.dbはネットスケープのユーザディレクトリに存在します)


AuthLDAPCompareDNOnServer

Syntax: AuthLDAPCompareDNOnServer < on(default) | off >
Context: directory, .htaccess
Override: AuthConfig
Status: Extension
Module: auth_ldap

セットするとauth_ldapはDNを比較するためにLDAPサーバを利用します。 この方法はDNを比較するための分かりやすい方法です。 auth_ldapはrrequire dnディレクティブで指定されたDNをディレクトリで検索します。 DNを取得し,それをユーザエントリから取得したDNと比較します このディレクティブがoffならば auth_ldapは単に文字列を比較します この方法で偽の反対が分かりますがこちらのほうが高速です。 auth_ldapキャッシュほとんどの状況でがDN比較を高速化することを気にとめてください。


AuthLDAPDereferenceAliases

Syntax: AuthLDAPDereferenceAliases never | searching | finding | always
Context: directory, .htaccess
Override: AuthConfig
Status: Extension
Module: auth_ldap

このディレクティブはLDAP操作においていつauth_ldapがaliasesを再参照するかを指定します。 デフォルトはalwaysです。


AuthLDAPEnabled

Syntax: AuthLDAPEnabled < on(default) | off >
Context: directory, .htaccess
Override: AuthConfig
Status: Extension
Module: auth_ldap

auth_ldapを明示的に無効にします 親ディレクトリでauth_ldapが有効でも子ディレクトリで無効にしたい場合に利用します


AuthLDAPFrontPageHack

Syntax: AuthLDAPFrontPageHack < on | off(default) >
Context: directory, .htaccess
Override: AuthConfig
Status: Extension
Module: auth_ldap

using Microsoft FrontPageの章を参照してください


AuthLDAPGroupAttribute

Syntax: AuthLDAPGroupAttribute attribute
Context: directory, .htaccess
Override: AuthConfig
Status: Extension
Module: auth_ldap

グループのメンバーをチェックするのに利用するLDAP属性を指定します。 最大10個の属性を複数述できます。 設定しないとmemberuniquemember属性を利用します。


AuthLDAPGroupAttributeIsDN

Syntax: AuthLDAPGroupAttributeIsDN < on(default) | off >
Context: directory, .htaccess
Override: AuthConfig
Status: Extension
Module: auth_ldap

onの場合,このディレクティブは クライアントユーザ名の識別名(DN)グループの メンバー確認に利用する。 offの場合,ユーザ名が利用される。 例えば、 クライアントがユーザ名bjensonを送ってきたと仮定します bjensenのLDAP識別名は cn=Babs Jenson, o=Airiusです。 onであればauth_ldapはgroupがcn=Babs Jenson,o=Airiusをmemberに持っているか調べます。 offであればauth_ldapはgroupがbjensonをmemberに持っているか調べます。


AuthLDAPOpCacheSize

Syntax: AuthLDAPOpCacheSize size
Context: server config
Override: Not Applicable
Status: Extension
Module: auth_ldap

auth_ldapがLDAP比較操作で利用するキャッシュのサイズを指定します。 デフォルトでは1024エントリーです。 0をセットするとオペレーションキャッシュは無効になります。


AuthLDAPOpCacheTTL

Syntax: AuthLDAPOpCacheTTL time
Context: server config
Override: Not Applicable
Status: Extension
Module: auth_ldap

オペレーションキャッシュの有効時間を秒で指定します。 デフォルトは600秒です。


AuthLDAPRemoteUserIsDN

Syntax: AuthLDAPRemoteUserIsDN < on | off(default) >
Context: directory, .htaccess
Override: AuthConfig
Status: Extension
Module: auth_ldap

このディレクティブがonであれば,REMOTE_USER環境変数の値に認証されたユーザの識別名が 入ります。 そうでなければクライアントから渡されたユーザ名が入ります。 デフォルトはoffです、この動作は以前のバージョンのauth_ldapの動作と同じです。


AuthLDAPStartTLS

Syntax: AuthLDAPStartTLS < on | off(default) >
Context: directory, .htaccess
Override: AuthConfig
Status: Extension
Module: auth_ldap

このディレクティブがonであれば, auth_ldapはLDAPサーバに接続後にセキュアなTLSセッションを開始します LDAPサーバがTLSをサポートしている必要があります。


AuthLDAPUrl

Syntax: AuthLDAPUrl url
Context: directory, .htaccess
Override: AuthConfig
Status: Extension
Module: auth_ldap

LDAPの検索パラメータを指定するのに利用する RFC 2255 URLです URLの構文は

ldap://host:port/basedn?attribute?scope?filter

ldap 通常のldapにはldapという文字を指定します。 セキュアなLDAPにはldapsを指定します。 セキュアなLDAPはauth_ldapがSSLをサポートした状態でコンパイルされている場合 にのみ有効です。
host:port

LDAPサーバの名前/ポート番号です (デフォルトではldapの場合localhost:389 ldapsの場合localhost:636です). 冗長構成をとっている複数のLDAPサーバを指定するには スペースで区切って複数のサーバを記述してください。 auth_ldapは接続が成功するまでそれぞれのサーバに接続を試みます。

コネクションが一度確立すべば, その接続はhttpdプロセスの生きている間または LDAPサーバが死んでしまうまで有効になります。

もしLDAPサーバが死んで、接続が死んでしまったら、 auth_ldapは再接続を試みます, プライマリーサーバから開始し 冗長化のためのサーバへの接続を試みます これはラウンドロビンではないことに注意してください。

basedn 全ての検索をおこなうための起点となる枝の識別名を指定します。 あなたのディレクトリー・ツリーの頂点を指定してもよいのですが サブツリー指定することもできます。
attribute 検索に利用する属性です。RFC 2255ではカンマで区切って複数の属性を記述できます、 どのように多くが提供されるかにかかわらず。 最初の属性だけが使用されます、 指定しないとuidになります。 これはあなたの利用するサブツリーにおいて一意の属性であるのでよいアイデアです。
scope 検索する深さを指定します,one(1階層のみ検索)またはsub(下位の階層も検索)です. baseというscopeもRFC2255では規定されていますがこのモジュールではサポートしません scopeが与えられなかった場合のデフォルトはsubです
filter 検索のLDAPフィルターです, デフォルトは(objectClass=*)です, これはツリー上の全てのオブジェクトを検索します。 フィルターは約8000文字以内に制限されています。 (ApacheのソースコードのMAX_STRING_LENで定義). これはどんなアプリケーションにとっても十分です。

検索を行う時には, フィルターとHTTPクライアントから与えられた ユーザ名パスワードが結合されて以下のような検索フィルタが作成されます。 (&(filter)(attribute=username)).

例えば,このURL ldap://ldap.airius.com/o=Airius?cn?sub?(posixid=*). クライアントが Babs Jensonのユーザ名で接続を試みたとき ,結果として検索フィルターは (&(posixid=*)(cn=Babs Jenson))になります.

下のAuthLDAPURL URLsの例を見てください.


require ディレクティブ

Apacheのrequireディレクティブは ユーザがリソースにアクセスできることを確認する 権限付与段階で利用されます。

require valid-user

require userディレクティブはどのユーザ名が資源にアクセス可能か決定します。

require user

require userディレクティブはどのユーザ名が資源にアクセス可能か決定します。 Once auth_ldap has retrieved a unique DN from the directory, it does an LDAP compare operation using the username specified in the require user to see if that username is part of the just-fetched LDAP entry. スペースで区切って複数のユーザを1行も記述することで複数のユーザにアクセス権限を与えます。 もしユーザ名にスペースが含まれていれば、1行に1ユーザしか記述できません。 この場合,require userディレクティブを複数行記述します 例えばAuthLDAPURLldap://ldap/o=Airius?cn であれば (cn属性をsearchに利用), 以下のようにアクセス制限を記述します:

require user Barbara Jenson
require user Fred User
require user Joe Manager

Because of the way that auth_ldap handles this directive, Barbara JensonBarbara Jensonとしてサインオンします Babs Jenson or any other cn that she has in her LDAP entry. Babs Jenson または他の cnthat she has 彼女のLDAPエントリ内の. たった一つのrequire user行が ユーザのエントリ内の属性の全ての値 をサポートするために必要です

もしuid属性が上記のURLでcn属性のかわりに使われたら、 上記の3つの行をまとめることが出来ます。

require user bjenson fuser jmanager

require group

このディレクティブは、アクセスを許可されたメンバーのLDAPグループを指定します。 LDAPグループの識別名を記述します。 例えば, 以下のLDAPディレクトリーに以下のエントリがあると仮定して:

dn: cn=Administrators, o=Airius
objectClass: groupOfUniqueNames
uniqueMember: cn=Barbara Jenson, o=Airius
uniqueMember: cn=Fred User, o=Airius

以下のディレクティブはFredとBarbara両方にアクセス権限を与えます:

require group cn=Administrators, o=Airius

このディレクティブの振舞いは AuthLDAPGroupAttribute AuthLDAPGroupAttributeIsDN で変更可能です。

require dn

require dnディレクティブは 管理者に識別名(DN)でアクセスを与えることを可能にします。 それは、アクセスを許される識別名(DN)と一致するものを指定します。 ディレクトリサーバからとってきた識別名と require dnで指定した識別名が一致したら権限が与えられます。

以下のディレクティブはアクセス権を特定のDNに与えています:

require dn cn=Barbara Jenson, o=Airius

このディレクティブの振舞いは AuthLDAPCompareDNOnServer ディレクティブで カスタマイズ可能です。

auth_ldapのキャッシュ

高速化のために、auth_ldapは LDAPサーバにコンタクトしなくてはいけない回数へらす 、攻撃的なキャッシュ戦略を使います。 キャッシングはauth_ldapで保護されたページのスループットをいとも簡単に 2〜3倍にします。 LDAPサーバーの負荷も著しく減るでしょう。

auth_ldapは、 search/bind段階で利用されるsearch/bind キャッシュと 比較段階で利用される2つのオペレーションキャッシュ の2種類のLDAPキャッシュをサポートします。 サーバーによって使われるそれぞれのLDAP URLは、それ自身のこれらの3つのキャッシュのセットを持っています。

search/bind キャッシュ

検索とbindお過程は、LDAP操作の最も時間がかかる状況です、 特にディレクトリーが大きい場合。 directory is large. search/bind キャッシュは成功した検索をキャッシュします。 ネガティブな結果(例、失敗した検索,bindに成功したが結果が返ってこない) はキャッシュしません。 この判断の論理的な根拠は 接続における無効な認証情報の比率は低いことです。 無効な認証情報をキャッシュしないことでキャッシュのサイズを減らせます。

auth_ldapはユーザ名を蓄え,ユーザ名は DNを持ってきます パスワードはbindに使われます。 bindした時間がキャッシュに保存されます。 Whenever a new connection is initiated with the same username, もし接続が同じユーザ名だたら auth_ldapはキャッシュの中のパスワードと比較します。 パスワードが一致して,キャッシュが古くなければ、 auth_ldapはsearc/bind段階を飛ばしてしまいます。

searchとbindのキャッシュは AuthLDAPCacheSize AuthLDAPCacheTTL ディレクティブで制御します.

オペレーションキャッシュ

比較段階で,auth_ldapは 比較オペレーションをキャッシュするために 2つのオペレーションキャッシュを使います。 1つめの比較キャッシュは require userrequire groupディレクティブのための 比較結果をキャッシュします。 2つめの比較キャッシュは require dnディレクティブの比較結果をキャッシュします。

両方のキャッシュの振舞いは AuthLDAPOpCacheSize AuthLDAPOpCacheTTL ディレクティブで制御できます。

キャッシュの監視

auth_ldapは管理者にキャッシュの動作を監視できるコンテントハンドラーを持ています。 コンテントハンドラーの名前は auth-ldap-infoです,以下のディレクティブが auth_ldapのキャッシュ情報にアクセスするのに使われます。:

<Location /server/cache-info >
 SetHandler auth-ldap-info
</Location>
管理者は http://servername/server/cache-info でauht_ldapのキャッシュの状態のリポートを参照できます。 もしApacheがMM-styleシェアードメモリーをサポートしていなければ それぞれのhttpdインスタンスがおのおのにキャッシュを持つことになる。 URLをリロードすることによって得られる結果は それぞれの時間ごとに どのhttpdインスタンスがリクエストに答えるかに依存して 毎回変わってします。

ベンチマーク

これらのベンチマークはキャッシュの設定によるパフォーマンスの違いを比較しています。 これらはベンチマークが完了するまでの時間とLDAPサーバに対して実際に行われたオペレーション の数を列挙しています。 全てのベンチマークはApache1.3.4で実行しました。 WWWクライアントとディレクトリサーバは全て同じです。

Note! これらのベンチマークは 異なるキャッシュのアルゴリズムを持つauth_ldap 1.4で行われました, だからベンチマークの意味はあまりありありません auth_ldapの最新バージョンは、ほとんどの状況ではるかに能率的な戦略を使います、 それで、ベンチマークは、単に歴史的な理由のためにあります。

最初のベンチマークは、同じページの10,000の情報検索をしました。 access.confの<Location> specificationでページを保護しています それは1つのrequire userディレクティブを含みます。

LDAP Operations
キャッシュLevel 実行時間 接続 bind 検索 比較 合計
None 6:04 6 60,006 30,000 30,000 120,012
Search 4:53 6 60,006 6 30,000 90,018
Search, bind 2:20 6 18 6 30,000 30,030
Search, bind, compare 1:46 6 18 6 6 36

2つめのベンチマークは 同じページを 10,000回参照しています。 しかし、ユーザ名は1000個の中から接続ごとにランダムに選んでいます。 ページはaccess.conf<Location>の中に require valid-userディレクティブを指定して保護しています。 この場合LDAPの比較操作が必要ないので, このベンチマークには3番目のレベルのキャッシュ (search, bind and compare)を含んでいません.

LDAP Operations
キャッシュLevel 実行時間 接続 bind 検索 合計
None 5:47 7 60,002 30,001 90,009
Search 5:00 7 60,002 9,970 69,979
Search, bind 2:51 7 9,672 9,968 19,647

これらのベンチマークはキャッシングがいかにパフォーマンスを改善するかという アイデアを与えているに過ぎない。 クライアントもサーバも砂場にいるので、 実世界での条件を忠実に再現しているわけではない。

TLSの利用

TLSを利用するためには,AuthLDAPStartTLSをonに設定するだけです。 他にすることはありません (あなたのLDAPサーバをTLSの設定にすることを除いては).

SSLの利用

auth_lapは サーバが既知の認証局(CA)から署名をうけた証明書を持っていない限り SSLサーバと通信できない auth_ldapをSSLサポートつきで構築すれば、 auth_ldapは既知のCAを含んだデータベースがどこにあるのかという情報が必要となります。 このデータベースのフォーマットはNetscapeコミュニケ−ターの cert7.dbデータベースと同一です。 もっとも簡単にこのファイルを取得する方法は Netscapeの新鮮なコピーを開始して, $HOME/.netscape/cert7.dbファイルをつかむことです。

セキュアなLDAPサーバを指定するために, AuthLDAPURLディレクティブの中で ldap://の変わりにldaps://を使ってください

Microsoft FrontPageをauth_ldapと共に使う

一般的に,FrontPageはFrontPage-web-specificユーザ/グループファイルを (例, the mod_authモジュール)を全ての認証に用います。 不幸なことに, それがFrontPageクライアントでパーミッションを壊すので 適切な指令を加えることによって LDAP認証に変えることは、可能ではありません、 それらは標準のテキストによる権限付与ファイルを書き換えようとします。

FrontPageをauth_ldapと共に利用するには, auth_ldapが-DAUTH_LDAP_FRONTPAGE_HACKとともにコンパイルされるということを確認して下さい -DAUTH_LDAP_FRONTPAGE_HACK. 詳細はMakefileを見てください.

一旦FrontPageウェブが作られたら、 それにLDAP認証を加えることは、ウェブで作られるevery.htaccessファイルに以下のディレクティブを加えることの問題です

AuthLDAPURL            the url
AuthLDAPAuthoritative  off
AuthLDAPFrontPageHack  on

AuthLDAPAuthoritative は グループ認証を下落させるためにoffにしなくてはならない それで、Apache、グループメンバーを調べるためのファイル認証へをするでしょう。 これはFrontPageが管理するグループが利用されることを許可します。

どのように動作するのか

FrontPageは require valid-userディレクティブを .htaccessファイルに加えることで Webへのアクセスを制限します。 もし AuthLDAPFrontPageHackがonでなければ, require valid-user ディレクティブは、LDAPに関する限り妥当などんなユーザーのために成功するでしょう。 これはLDAPディレクトリにエントリーがあるユーザはだれでも有効なユーザであることを意味します。 ところが、FrontPageは、ローカルのユーザー・ファイルのそれらの人々だけが、妥当だと考えます。 hackの目的は ApacheにLDAPに変わって ローカルユーザファイル(それはFrontPageによって管理される) を認めるように強制します require valid-userディレクティブを指定したときには.

ディレクティブが上のように追加されれば, FrontPageユーザは全ての管理操作を FrontPageクライアントから行えるようになります。

警告

感謝

以下の方々に感謝します

著作権

Copyright (C) 1998, 1999, Enbridge Pipelines Inc.
Copyright (C) 1999-2001, Dave Carrigan
All rights reserved.

このモジュールはフリーソフトウェアです; あなたは、それを再配布して、および/またはアパッチ自身と同じ条件の下にそれを修正することができます。 このモジュールは、それが役に立つだろうことを願って配布されます、しかしどんな保証もなしで; 市場性あるいは特定の目的に対する適合性に関して、どんな保証もしません 。このモジュールの著作権所有者は、モジュールの使用から生じているどんな一般の、特別な、ついでのまたは重要な被害にも対する責任を問われることができません。


<dave@rudedog.org>