Title: Inhalte
- Support für das OpenLDAP SDK (1.x und 2.x), das Novell LDAP SDK und das iPlanet SDK (Netscape).
- Komplexe Authorisierungsrichtlinien mit LDAP-Filtern.
- Zugriffskontrolle für Microsoft FrontPage-Nutzer auf ihre Web-Sites unter Beibehaltung von LDAP für die Benutzerauthentifizierung.
- Extensives Caching von LDAP-Operationen über mod_ldap.
- LDAP-Support für SSL (setzt das Netscape-SDK voraus ) oder TLS (setzt das OpenLDAP 2.x- oder das Novell LDAP-SDK voraus).
Der Benutzerzugriff wird in zwei Phasen gewährt. Die erste
Phase ist die Authentifizierung, in der
Während der Authentifizierungsphase sucht das Modul
- Durch Kombination der Attribute und Filter der
AuthLDAPURL -Direktive mit dem vom HTTP-Client übergebenen Benutzernamen wird ein Suchfilter erzeugt. - Mit dem erzeugten Filter wird im Verzeichnis gesucht. Liefert die Suche keinen übereinstimmenden Eintrag, wird der Zugriff verweigert oder abgelehnt.
- Mit dem DN des Suchergebnisses und dem vom HTTP-Client übergebenen DN sowie dem Passwort wird versucht, eine Bindung zum LDAP-Server herzustellen. Kommt die Bindung nicht zustande, wird der Zugriff verweigert oder abgelehnt.
Die folgenden Direktiven werden in dieser Phase benutzt:
| Gibt den LDAP-Server, den Ausgangs-DN, das Attribut für die Suche sowie weitere Filter an. | |
| Ein optionaler DN für die Bindung während der Suchphase. | |
| Ein optionales Passwort für die Bindung während der Suchphase. |
Mit den
Ist die Anweisung vorhanden, gewährt
Die require user-Direktive gibt an, welche
Benutzernamen auf die Ressource zurgreifen können. Hat
require user angegebenen Benutzernamen durchgeführt,
um festzustellen, ob dieser Benutzername Teil des gerade ermittelten
LDAP-Eintrags ist. Werden mehrere Benutzernamen getrennt durch
Leerzeichen angegeben,
kann mehreren Benutzern der Zugriff gewährt werden.
Enthält ein Benutzername ein Leerzeichen, dann muss dieser in doppelte
Anführungszeichen gesetzt werden. Mehreren Benutzern kann auch
Zugriff gewährt werden, wenn mehrere
require user-Anweisungen mit einem Benutzer pro Zeile
kodiert werden. Mit der ldap://ldap/o=Airius?cn (d.h., cn wird
für die Suche benutzt) können beispielsweise folgende require-Direktiven
den Zugriff regeln:
require user "Fred User"
require user "Joe Manager"
Aufgrund der Art und Weise, in der cn aus ihrem LDAP-Eintrag anmelden. Nur diese
einzige require user-Zeile ist erforderlich, um alle Werte
des Attributs aus dem Benutzereintrag zu ermöglichen.
Würde das Attribut uid an Stelle des Attributs
cn in dieser URL verwendet, würden sich die drei oben
aufgeführten Zeilen auf
Diese Direktive gibt eine LDAP-Gruppe an, deren Mitglieder Zugriff haben. Sie benutzt den DN der LDAP-Gruppe. Angenommen, das LDAP-Verzeichnis enthält folgenden Eintrag:
objectClass: groupOfUniqueNames
uniqueMember: cn=Barbara Jenson, o=Airius
uniqueMember: cn=Fred User, o=Airius
Mit der folgenden Direktive erhalten dann sowohl Fred als auch Barbara Zugriff:
Das Verhalten dieser Direktive kann mit den Direktiven
Mit der require dn-Direktive kann der Administrator
Zugriff über die Distinguished Names gewähren. Sie gibt einen DN an,
der übereinstimmen muss, damit Zugriff gewährt wird. Stimmt der im
Verzeichnisserver gefundene DN mit dem DN in require dn
überein, wird der Zugriff gewährt.
Mit der folgenden Anweisung wird einem bestimmten DN Zugriff gewährt:
Das Verhalten dieser Direktive wird von der Direktive
-
Jedem aus dem LDAP-Verzeichnis Zugriff gewähren und die UID
für die Suche benutzen:
AuthLDAPURL "ldap://ldap1.airius.com:389/ou=People, o=Airius?uid?sub?(objectClass=*)"
require valid-user -
Das folgende Beispiel stimmt mit dem letzten überein,
allerdings wurden Felder mit sinnvollen Voreinstellungen
weglassen. Beachten Sie außerdem
die Verwendung eines redundanten LDAP-Servers.
AuthLDAPURL "ldap://ldap1.airius.com ldap2.airius.com/ou=People, o=Airius"
require valid-user -
Auch das nächste Beispiel gleicht den vorangegangenen,
verwendet aber den CN (Common Name) an Stelle der UID. Das kann
problematisch sein, wenn mehrere Personen des Verzeichnisses den
gleichen
cnbesitzen, weil eine Suche nach demcngenau einen Eintrag zurückliefern muss. Daher ist diese Vorgehensweise nicht empfehlenswert: Es ist sinnvoller, ein Attribut zu wählen, das garantiert einmalig im Verzeichnis ist, beispielsweise das Attributuid.AuthLDAPURL "ldap://ldap.airius.com/ou=People, o=Airius?cn"
require valid-user -
Jedes Mitglied der Gruppe
Administratorserhält Zugriff. Der Benutzer muss sich mit der UID authentifizieren.AuthLDAPURL "ldap://ldap.airius.com/o=Airius?uid"
require group cn=Administrators, o=Airius -
Im nächsten Beispiel wird davon ausgegangen, dass jedes
Airius-Mitglied mit einem alphanumerischen Pager ein LDAP-Attribut
qpagePagerIDbesitzt. Es erhalten nur diejenigen über ihre UID Zugriff, die alphanumerische Pager besitzen:AuthLDAPURL "ldap://ldap.airius.com/o=Airius?uid??(qpagePagerID=*)"
require valid-user -
Das folgende Beispiel zeigt die Leistungsfähigkeit von Filtern bei komplizierten administrativen Aufgaben. Ohne Filter wäre es notwendig, eine neue LDAP-Gruppe einzurichten und sicherzustellen, dass die Gruppenmitglieder mit den Pager-Benutzern synchronisiert sind. Mit Filtern ist diese Aufgabe leicht zu lösen. Es soll jeder mit einem Filter sowie Joe Manager, der keinen Pager besitzt, aber die gleiche Ressource benötigt, Zugriff erhalten:
AuthLDAPURL "ldap://ldap.airius.com/o=Airius?uid??(|(qpagePagerID=*)(uid=jmanager))"
require valid-userDas letzte Beispiel mag auf den ersten Blick verwirrend erscheinen, daher kann es hilfreich sein, auszuwerten, wie der Suchfilter wie unten auf zwei Verbindungen basierend aussieht. Der blau gesetzte Text ist der Teil, der über das in der URL angegebene Attribut eingesetzt wird. Der rote Text wurde nach Anwendung des in der URL angegebenen Filters eingesetzt. Der grüne Text wurde mit Hilfe der vom HTTP-Client ermittelten Informationen ergänzt. Stellt
Fred Userdie Verbindung alsfuserher, dann sieht der Filter wie folgt aus:(&(|(qpagePagerID=*)(uid=jmanager))(uid=fuser)) Die Suche ist nur erfolgreich, wenn fuser einen Pager besitzt. Stellt Joe Manager die Verbindung als jmanager her, sieht der Filter so aus:
(&(|(qpagePagerID=*)(uid=jmanager))(uid=jmanager)) Die Suche ist erfolgreich, unabhängig davon, ob jmanager einen Pager besitzt oder nicht.
Mehr zur Verwendung des Protokolls TLS finden Sie
unter den
Mehr zur Verwendung des Protokolls SSL finden Sie unter den
Ein sicherer LDAP-Server wird in der
Normalerweise verwendet FrontPage
(bzw. das
Wurde ein FrontPage-Server eingerichtet, kann die
LDAP-Authentifizierung nach Einfügen der folgenden Direktiven
in alle .htaccess-Dateien verwendet werden:
AuthLDAPURL "die URL" AuthLDAPAuthoritative off AuthLDAPFrontPageHack on
AuthLDAPAuthoritative muss auf
off gesetzt werden, damit
mod_auth_ldap die Gruppenauthentifizierung ablehnt
und der Apache auf die Dateiauthentifizierung zur Überprüfung
der Gruppenmitgliedschaft zurückfällt. Auf diese Weise können von
FrontPage verwaltete Gruppendatei benutzt werden.
Funktionsweise
FrontPage kontrolliert den Web-Zugriff über die zusätzliche
require valid-user-Direktive in den
.htaccess-Dateien. Wird AuthLDAPFrontPageHack nicht
aktiviert, ist die require valid-user-Direktive
für jeden Benutzer erfolgreich, der gemäß LDAP zulässig ist.
Daraus folgt, dass jeder, der einen Eintrag im
LDAP-Verzeichnis besitzt, als zulässiger Benutzer gilt,
während FrontPage davon ausgeht, dass nur Benutzer aus der lokalen
Benutzerdatei zulässig sind. Der Hack soll den Apache zwingen, die
lokale Benutzerdatei (die von FrontPage verwaltet wird) und nicht LDAP
zu Rate zu ziehen, wenn die require valid-user-Anweisung
ausgeführt wird.
Wurden die Direktiven wie oben beschrieben hinzugefügt,
sind FrontPage-Benutzer in der Lage, alle Management-Operationen
für den FrontPage-Client durchzuführen.
Einschränkungen
- Wird die LDAP URL gewählt, dann sollte sich das Attribut
für die Authentifizierung
auch für eine
mod_auth -Benutzerdatei
eignen, was beispielsweise für die UID gilt.
- Werden Benutzer über FrontPage hinzugefügt, sollten die
FrontPage-Administratoren aus nahe liegenden Gründen
Benutzernamen wählen, die bereits im LDAP-Verzeichnis vorhanden
sind. Das vom Adminstrator in das Formular einegegebene Passwort
wird ignoriert, da der Apache die Authentifizierung mit dem Passwort
aus der LDAP-Datenbank und nicht mit dem Passwort aus der
lokalen Benutzerdatei durchführt. Dies kann zu Irritationen
beim Web-Administrator führen.
- Der Apache muss mit dem
mod_auth -Modul
kompiliert werden, damit FrontPage unterstützt wird. Ursache
hierfür ist die Tatsache, dass der Apache weiterhin die
mod_auth -Gruppendatei für die Ermittlung
der Zugangsberechtigung eines Benutzers für die
FrontPage-Website benutzt.
- Die Direktiven müssen in die
.htaccess-Dateien
eingefügt werden. Der Versuch, sie in die Direktiven
Location oder Directory aufzunehmen, schlägt fehl, weil das
Modul mod_auth_ldap auf die
AuthUserFile -Anweisung
in den .htaccess-Dateien von FrontPage
zugreifen muss, um die Liste der gültigen Benutzer finden zu können.
Befinden sich
die mod_auth_ldap -Anweisungen nicht in der gleichen
.htaccess-Datei wie die FrontPage-Direktiven, funktioniert
der Hack nicht, weil mod_auth_ldap keine
Möglichkeit hat, die .htaccess-Datei zu verarbeiten
und die von FrontPage verwaltete Benutzerdatei nicht finden kann.
Wird der Wert off gesetzt, können andere
Authentifizierungsmodule eine Benutzerauthentifizierung durchführen, falls
dieses Modul fehlschlägt. Dies ist nur möglich, wenn kein DN oder keine
Regel mit dem vom Client übergebenen Benutzernamen übereinstimmt.
Ein optionaler DN der bei der Suche nach Einträgen die Bindung an
den Server herstellt. Wird er nicht angegeben,verwendet
Das Passwort, das für den bindenden DN benutzt wird.
Da es sich bei diesem Passwort um vertrauliche Daten handeln
kann, sollte es gut geschützt sein. Die Direktiven
Die charset.conv mit den üblichen Zuordnungen für
Zeichensätzen zu Sprachcodes aus.
Diese Datei enthält Zeilen im Format:
Beim Sprachcode werden Groß- und Kleinbuchstaben nicht unterschieden.
Leere Zeilen sowie Zeilen, die mit einem Hash (#) beginnen,
werden ignoriert.
Wird dieses Attribut auf on gesetzt,
benutzt das require dn angegebenen
Verzeichnis nach dem DN und vergleicht diesen mit dem DN aus dem
Benutzereintrag. Wird die Voreinstellung zurückgesetzt, führt das Modul
Über diese Direktive wird definiert, wann das Modul
always geschieht dies immer umgehend.
Wird diese Direktive auf off gesetzt, ist das Modul
Weitere Informationen finden Sie unter
Microsoft FrontPage und
Diese Anweisung gibt an, welche LDAP-Attribute für die
Überprüfung der Gruppenmitgliedschaft benutzt werden.
Mit mehreren Anweisungen kann das Attribut mehrfach gesetzt werden.
Wird es nicht angegeben, verwendet das Modul
member und uniquemember.
Wenn on gesetzt wird, verlangt diese Direktive
die Verwendung des DN des Client-Benutzernamens für die Überprüfung der
Gruppenmitgliedschaft. Andernfalls wird der Benutzername benutzt. Hat der
Client beispielsweise den Benutzernamen bjenson gesendet,
der dem LDAP-DN cn=Babs Jenson,
o=Airius entspricht, dann überprüft das Modul
cn=Babs Jenson, o=Airius Gruppenmitglied ist. Wird diese
Direktive nicht angegeben, überprüft das Modul
bjenson
Gruppenmitglied ist.
Wird diese Direktive auf on gesetzt, entspricht
die Umgebungsvariable REMOTE_USER
dem vollständigen DN des authentifizierten Benutzers und nicht nur dem
vom Client übergebene Benutzernamen. Standardmäßig ist off
vorgegeben.
Eine URL nach RFC 2255, die die LDAP-Suchparameter angibt. Die Syntax lautet:
- ldap
- Für reguläres LDAP wird die Zeichenfolge
ldapangegeben, für gesichertes LDAPldaps. Gesichertes LDAP steht nur zur Verfügung, wenn der Apache mit einer LDAP-Bibliothek mit SSL-Unterstützung gebunden wurde. - Host:Port
-
Name/Port des LDAP-Servers (Voreinstellung:
localhost:389forldapundlocalhost:636forldaps). Um mehrere redundante LDAP-Server anzugeben, werden alle Server getrennt durch Leerzeichen angegeben. Das Modulmod_auth_ldap versucht der Reihe nach eine Verbindung zu jedem Server herzustellen, bis eine Verbindung zustandekommt.Konnte eine Serververbindung eingerichtet werden, bleibt diese für die Lebensdauer des
httpd-Prozesses oder so lange gültig, bis der LDAP-Server heruntergefahren wird.Wird der LDAP-Server heruntergefahren oder eine bestehende Verbindung unterbrochen, versucht das Modul
mod_auth_ldap die Verbindung wiederherzustellen, wofür der primäre Server gestartet und ein Verbindungsaufbau zu jedem redundanten Server versucht wird, was sich von einem echten Rundruf unterscheidet. - BasisDN
- Der DN des Verzeichniszweiges, in welchem alle Suchen beginnen sollen. Im äußersten Fall muss dies die Spitze des Verzeichnisbaumes sein, es kann aber auch ein Unterzweig angegeben werden.
- Attribut
- Das zu suchende Attribut. Das RFC 2255 erlaubt zwar
eine durch Komata getrennte Attributliste, es wird aber nur das erste
Attribut benutzt, unabhängig davon, wie viele angegeben werden. Werden
keine Attribute angegeben, wird standardmäßig
uidverwendet. Es ist sinnvoll, ein Attribut zu wählen, das für alle Einträge im Unterzweig eindeutig ist. - Bereich
- Der Suchbereich. Angegeben werden kann
oneodersub. Gemäß RFC 2255 wird zwar auch der Bereichbaseunterstützt, was jedoch nicht für dieses Modul gilt. Wird kein Bereich oder der Bereichbaseangegeben, gilt die Voreinstellungsub. - Filter
- Ein zulässiger LDAP-Suchfilter. Ohne Angabe gilt die Voreinstellung
(objectClass=*), bei der nach allen Objekten gesucht wird. Die Länge der gesamten Filterangabe darf 8192 Zeichen nicht überschreiten (genäß derMAX_STRING_LEN-Definition im Apache-Quellcode), was generell aureichen sollte.
Bei der Durchführung von Suchanfragen werden das Suchattribut,
die Filterangabe und der vom HTTP-Client übermittelte Benutzername
kombiniert und ein Suchfilter der folgenden Form erzeugt:
(&(Filter)(Attribut=Benutzername)).
Versucht bespielsweise ein Client für die URL
ldap://ldap.airius.com/o=Airius?cn?sub?(posixid=*) eine
Verbindung mit dem Benutzernamen Babs
Jenson herzustellen, dann ergibt sich folgende Filterangabe:
(&(posixid=*)(cn=Babs Jenson)).
Beispiele zu
Dieses Modul implementiert die HTTP Digest-Authentifizierung. Da sie noch nicht ausführlich getestet wurde, befindet sie sich noch in einem experimentellen Zustand.
Die Verwendung der MD5 Digest-Authentifizierung ist sehr einfach.
Die Authentifizierung wird mit den Direktiven
AuthType Digest und
AuthType Basic und
Eine entsprechende Benutzerdatei im Textformat kann mit dem Programm htdigest eingerichtet werden.
AuthName "private area"
AuthDigestDomain /private/ http://mirror.my.dom/private2/
AuthDigestFile /web/auth/.digest_pw
Require valid-user
Bei der Digest-Authentifizierung sind die Passwörter sicherer als bei der Basic-Authentifizierung, allerdings muss der Browser dieses Verfahren unterstützen. Seit November 2002 unterstützen die wichtigsten Browser die Digest-Authentifizierung, unter anderem die Browser Opera, MS Internet Explorer (nicht in Verbindung mit einer Abfragezeichenfolge), Amaya, Mozilla und Netscape ab Version 7. Da die Digest-Authentifizierung noch nicht soweit verbreitet wie die Basic-Authentifizierung ist, sollte sie nur in überschaubaren Umgebungen verwendet werden.
Mit der
Diese Datei verwendet ein spezielles Format und kann mit dem Programm
htdigest aus dem Unterverzeichnis
support/ der Apache-Distribution erstellt werden.
Mit der
Jede Zeile der Gruppendatei enthält einen Gruppennamen auf den nach einem Doppelpunkt die durch Leerstellen voneinander getrennte Liste der Benutzernamen folgt. Ein Beispiel:
Beachten Sie, dass eine Suche in umfangreichen Textdateien nicht effektiv ist.
Achten Sie darauf, dass die
Die auth werden nur Benutzername und
Passwort überprüft. Bei der Einstellung auth-int findet
bei der Authentifizierung zusätzlich eine Integritätsprüfung der Daten statt.
Hierbei wird ein MD5-Hash über die Daten gebildet und geprüft.
Beim Argument none wird der alte Digest-Algorithmus nach
RFC-2069 benutzt (der keine Integritätsprüfung vornimmt). Werden sowohl
auth als auch auth-int angegeben,
entscheidet der Browser, welche Prüfung durchgeführt wird.
Das Argument none sollte nur benutzt werden, wenn der
Browser aus irgendwelchen Gründen die Server-Challenge
nicht erfüllen kann.
auth-int ist noch nicht implementiert.
Die stale=true zurück. Ist der Wert von If seconds
größer als 0, dann gibt er die Gültigkeitsdauer des Nonce-Wertes an.
Der Wert sollte niemals kleiner als 10 Sekunden sein.
Ist der Wert kleiner als 0, verliert der Nonce-Wert niemals seine Gültigkeit.
Die
MD5-sess ist zur Zeit noch nicht korrekt implementiert.
Mit der
Diese Direktive sollte immer angegeben werden und
mindestens den oder die Root-URI(s) für diesen Bereich angeben. Werden
keine Angaben gemacht, sendet der Client den Autorisierungsheader
mit jeder an diesen Server gesendeten Anfrage. Das steigert
nicht nur den Umfang der Anfragen sondern kann sich auch negativ auf
die Performance auswirken, wenn
Die angegebenen URIs können auch auf unterschiedliche Server verweisen. Clients, die damit umgehen können, nutzen dann ohne wiederholte Nachfrage beim Benutzer die gleichen Benutzernamen/Passwörter für mehrere Server.
Die 0 und werten Sie die Fehlermeldung
beim Serverstart aus.
Die Größe wird normalerweise in Bytes angegeben.
Ein K oder M steht für kByte bezw.
MBytes. Die folgenden Anweisungen sind demnach alle
gleichbedeutend:
AuthDigestShmemSize 1024K
AuthDigestShmemSize 1M
<?xml version="1.0"?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.de.xsl"?>
<modulesynopsis metafile="mod_auth_dbm.xml.meta">
<name>mod_auth_dbm</name>
<description>Benutzerauthentifizierung mit DBM-Dateien</description>
<status>Erweiterung</status>
<sourcefile>mod_auth_dbm.c</sourcefile>
<identifier>auth_dbm_module</identifier>
<compatibility>Verfügbar bis zur Version 2.1</compatibility>
<summary>
<p>Dieses Modul wird für die HTTP Basic-Authentication verwendet, bei
der
die Benutzernamen und Passwörter in DBM-Datenbankdateien gespeichert
werden.
Sie bieten eine Alternative zu den einfachen Textdateien des Moduls
<module>mod_auth</module>.</p>
</summary>
<seealso><directive module="core">AuthName</directive></seealso>
<seealso><directive module="core">AuthType</directive></seealso>
<seealso><directive module="core">Require</directive></seealso>
<seealso><directive module="core">Satisfy</directive></seealso>
<directivesynopsis>
<name>AuthDBMGroupFile</name>
<description>Gibt den Namen der Datenbankdatei mit der Liste der
Benutzergruppen
für die Authentifizierung an.</description>
<syntax>AuthDBMGroupFile <var>Dateipfad</var></syntax>
<contextlist><context>directory</context><context>.htaccess</context>
</contextlist>
<override>AuthConfig</override>
<usage>
<p>Die <directive>AuthDBMGroupFile</directive>-Direktive nennt den Namen
der DBM-Datei
mit der Liste der Benutzergruppen für die Authentifizierung. Als
<var>Dateipfad</var> wird der
absolute Pfad zur Gruppendatei angegeben.</p>
<p>Die Benutzernamen stehen verschlüsselt in der Gruppendatei. Der
Eintrag für einen Benutzer
besteht aus einer durch Komata getrennten Liste der Gruppen, denen der
Benutzer angehört.
Dieser Eintrag darf weder Leerstellen noch Doppelpunkte enthalten.</p>
<p>Achtung: Stellen Sie sicher, dass die
<directive>AuthDBMGroupFile</directive>-Datei außerhalb des
Dokumentverzeichnisses
des Webservers untergebracht wird. Legen Sie sie <em>niemals</em> in dem
Verzeichnis ab,
das geschützt werden soll, da sie sonst von Clients heruntergeladen
werden kann, falls
sie nicht anders geschützt ist.</p>
<p>Kombination von User- und Group-Datei: In manchen Situationen ist es
einfacher,
eine einzige Datenbank zu unterhalten, die sowohl die notwendigen Angaben
zum Benutzer
als auch zur Gruppe verwaltet. Das erleichtert Programmen das Schreiben:
Auf diese Weise müssen sie nur in eine einzige DBM-Datei schreiben und
nur diese eine Datei
blockieren. Das wird dadurch erreicht, dass
das User- und Group-Datei auf die gleiche DBM-Datei verweisen:</p>
<example>
AuthDBMGroupFile /www/userbase<br />
AuthDBMUserFile /www/userbase
</example>
<p>Der Schlüssel für eine DBM-Datei ist der Benutzername. Das
Format sieht folgendermaßen aus:</p>
<example>
<var>verschlüsseltes_Passwort</var>:<var>Gruppenliste</var>[:(ignoriert)]
</example>
<p>Der Passwortabschnitt enthält wie zuvor das verschlüsselte
Passwort gefolgt von einem Doppelpunkt
und der durch Komata getrennten Gruppenliste. Nach einem weiteren
Doppelpunkt können
weitere Daten folgen, die jedoch vom Authentifizierungsmodul ignoriert
werden. So ist die kombinierte
Passwort- und Gruppendatenbank von www.telescope.org aufgebaut.</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>AuthDBMUserFile</name>
<description>Gibt den Namen der Datenbankdatei mit der Benutzerliste und
den Passwörtern für die Authentifizierung an.</description>
<syntax>AuthDBMUserFile <var>Dateipfad</var></syntax>
<contextlist><context>directory</context><context>.htaccess</context>
</contextlist>
<override>AuthConfig</override>
<usage>
<p>Die <directive>AuthDBMUserFile</directive>-Direktive gibt den Namen der
DBM-Datei mit der Benutzerliste und den Passwörtern für die
Authentifizierung an.
Der <var>Dateipfad</var> ist der absolute Pfad zur Benutzerdatei.</p>
<p>Der Schlüssel der Benutzerdatei ist der Benutzername. Der Eintrag
für einen Benutzer
besteht aus dem verschlüsselten Passwort, auf das optional ein
Doppelpunkt sowie
beliebige Daten folgen können. Der Doppelpunkt und die folgenden Daten
werden vom Server nicht beachtet.</p>
<note type="warning"><title>Achtung:</title>
<p>Achten Sie darauf, dass die
<directive>AuthDBMUserFile</directive>-Datei
außerhalb des Dokumentverzeichnisses des Webservers gespeichert
wird. Bringen Sie die Datei
<em>nicht</em> in dem zu schützenden Verzeichnis unter, da sie sonst
von den Clients heruntergeladen
werden kann..</p>
</note>
<p>Wichtiger Hinweis zur Kompatibilität: Die Implementierung von
"dbmopen()" in den Apache-Modulen liest die Länge der Zeichenkette der
Hash-Werte
aus der DBM-Datenstruktur, anstatt darauf zu vetrauen,
dass die Zeichenfolge mit einem NULL-Byte endet. Einige Anwendungen wie zum
Beispiel der
Netscape-Webserver verlassen sich darauf, dass die Zeichenfolge mit einem
Null-Byte endet, was
was bei Verwendung von DBM-Dateien unter Umständen Probleme bereiten
kann.</p>
<p>Mit dem Perl-Skript
<a href="../programs/dbmmanage.html">dbmmanage</a> können Sie
Passwortdateien im DBM-Format
für die Verwendung mit diesem Modul erzeugen und bearbeiten .</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>AuthDBMType</name>
<description>Gibt den Typ der Datenbankdatei an, in der Passwörter
gespeichert werden.</description>
<syntax>AuthDBMType Voreinstellung|SDBM|GDBM|NDBM|DB</syntax>
<default>AuthDBMType Voreinstellung</default>
<contextlist><context>directory</context><context>.htaccess</context>
</contextlist>
<override>AuthConfig</override>
<compatibility>Verfügbar ab Version 2.0.30</compatibility>
<usage>
<p>Gibt den Typ der Datenbankdatei an, in der die Passwörter
gespeichert werden.
Die Voreinstellung wird beim Kompilieren festgelegt. Die
Verfügbarkeit anderer Datenbankdateitypen hängt auch von den
Einstellungen beim
<a href="../install.html#dbm">Kompilieren</a> ab.</p>
<p>Es ist äußerst wichtig, dass das Programm, mit dem Sie die
Passwortdateien erstellen,
so konfiguriert ist, dass es den gleichen Datenbanktyp verwendet.</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>AuthDBMAuthoritative</name>
<description>Legt fest, ob vom Authentifizierungsmodul nicht gefundene User-IDs
an Module mit niedriger
Priorität weitergereicht werden.</description>
<syntax>AuthDBMAuthoritative On|Off</syntax>
<default>AuthDBMAuthoritative On</default>
<contextlist><context>directory</context><context>.htaccess</context>
</contextlist>
<override>AuthConfig</override>
<usage>
<p>Wird die <directive>AuthDBMAuthoritative</directive>-Direktive explizit
auf
<code>Off</code> gesetzt, werden die Authentifizierungsdaten
an Module auf niedrigerer Ebenen weitergereicht (wie in der Datei
<code>modules.c</code> definiert),
wenn <strong>keine User-ID</strong> oder <strong>Regel</strong> für
die angegebene User-ID
zutrifft. Ist eine entsprechende User-ID und/oder Regel angegeben, werden
die üblichen
Passwort- und Zugriffsüberprüfungen durchgeführt und beim
Fehlschlag die Meldung
"Authentication Required" zurückgegeben.</p>
<p>Taucht eine User-ID in der Datenbank mehrerer Module auf oder trifft
eine gültige
<directive module="core">Require</directive>-Direktive für mehr
als ein Modul zu, dann
überprüft das erste Modul die Zugangsdaten und reicht keine
Zugriffsrechte weiter, unabhängig davon,
wie die Einstellungen der Direktive
<directive>AuthDBMAuthoritative</directive> lauten.</p>
<p>Dies kommt häufig in Verbindung mit einem der Grundmodule wie
<module>mod_auth</module>
zum Einsatz. Dieses DBM-Modul bietet eine Vielzahl von Möglichkeiten
zur Benutzerprüfung.
Einige wenige (administrative) Zugriffe fallen bei einer gut
geschützten <code>.htpasswd</code>-Datei
auf eine niedrigere Ebene durch.</p>
<p>Gemäß Voreinstellung wird die Kontrolle nicht weitergereicht
und ein unbekannter Benutzername oder
eine unbekannte Regel führen zur Antwort "Authentication Required".
Wird keine Angabe gemacht, bleibt das System daher
geschützt und erzwingt ein NCSA entsprechendes Verhalten.</p>
<note type="warning"><title>Achtung:</title>
<p>Beachten Sie die damit verbundenen Implikationen, wenn Sie zu lassen,
dass ein Benutzer in seiner .htaccess-Datei durchrutscht und
überprüfen Sie, ob das tatsächlich gewollt ist.
Im Allgemeinen ist es einfacher, eine einzelne .htpasswd-Datei an Stelle
einer Datenbank
zu schützen.</p>
</note>
</usage>
</directivesynopsis>
</modulesynopsis>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
