Hallo Leute An unserer Schule wollen wir einen neuen Fileserver aufsetzen. Einer der beiden Informatik-Administratoren moechte ihn gerne unter Linux laufen lassen, und ich versuche, ihm dabei zur Hand zu gehen. Da wir zur Zeit nur Windows-Clients haben, in Zukunft aber vielleicht zumindest Dual-Boot mit Linux und Windows anbieten wollen, soll natuerlich Samba darauf laufen und vielleicht auch NFS. Deshalb habe ich vorgeschlagen, fuer die Benutzerverwaltung einen LDAP-Server einzurichten und angeboten, ihn aufzusetzen. Nur leider will mir das nicht so recht gelingen :-(( Auf der Maschine habe ich SuSE 9.0 aufgesetzt, die Updates heruntergeladen und zwei Benutzer eingerichtet. Den LDAP-Server lasse ich mit folgender sldap.conf laufen (gekuerzt): ==================================================================== include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/rfc2307bis.schema include /etc/openldap/schema/samba.schema include /etc/openldap/schema/yast2userconfig.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read access to attribute=userPassword,lmPassword,ntPassword by dn="cn=Manager,dc=ksobwalden,dc=ch" write by anonymous auth by self write by * none access to * by dn="cn=Manager,dc=ksowbwalden,dc=ch" write by * read database ldbm suffix "dc=ksobwalden,dc=ch" rootdn "cn=Manager,dc=ksobwalden,dc=ch" rootpw <hash-Passwort> index objectClass eq ===================================================================== Ich habe das Verzeichnis mit ein paar grundlegenden Daten gefuellt (gekuerzt) ===================================================================== dn: dc=ksobwalden,dc=ch objectClass: dcObject objectClass: organization o: KSOW dc: ksobwalden description: Kantonsschule Obwalden structuralObjectClass: organization dn: cn=Manager,dc=ksobwalden,dc=ch objectClass: organizationalRole cn: Manager description: Verzeichnis-Manager structuralObjectClass: organizationalRole dn: ou=ldapconfig,dc=ksobwalden,dc=ch objectClass: organizationalUnit ou: ldapconfig structuralObjectClass: organizationalUnit ==================================================================== Im Yast-Dialog zum Starten des LDAP-Client habe ich als LDAP-base-DN dc=ksobwalden,dc=ch eingetragen, als Adresse des LDAP-Servers localhost angegeben und LDAP TLS/SSL aktiviert. In der erweiterten Konfiguration habe ich Dateiserver aktiviert als Konfigurations-Base-DN ou=ldapconfig,dc=ksobwalden,dc=ch und als Bind-DN cn=Manager,dc=ksobwalden,dc=ch eingetragen. In der Benutzerverwaltung von Yast kann ich nun LDAP-Nutzer anlegen und sie werden mir auch beim naechsten Aufruf angezeigt. Sie sind auch im Verzeichnis vorhanden. Beispiel eines Benutzers und seiner Gruppe (gekuerzt): ===================================================================== dn: uid=viktor,dc=ksobwalden,dc=ch cn: Viktor Bieri gidNumber: 500 givenName: Viktor homeDirectory: /home/viktor loginShell: /bin/bash objectClass: top objectClass: posixAccount objectClass: shadowAccount objectClass: inetOrgPerson shadowExpire: 0 shadowLastChange: 12484 sn: Bieri uid: viktor uidNumber: 504 dn: cn=lehrerIn,dc=ksobwalden,dc=ch cn: lehrerIn gidNumber: 500 objectClass: top objectClass: posixGroup objectClass: namedObject structuralObjectClass: namedObject ====================================================================== Ich erwarte jetzt eigentlich, dass ich mich unter dieser Kennung am System anmelden kann. Doch das geht nicht. getenv passwd zeigt mir auch die LDAP-Nutzer nicht. Und wenn ich jetzt mit su Superuser werden will, so bleibe ich der gleiche (ohne eine Fehlermeldung bei Eingabe des richtigen Passwortes). In var/log/warn aber erhalte ich den Eintrag: Mär 9 13:38:18 schola su: pam_ldap: ldap_starttls_s: Connect error Mär 9 13:38:18 schola su: pam_ldap: ldap_result Can't contact LDAP server Ich erhalte aber da keinen Eintrag, wenn ich mich als viktor anmelden will. Wo liegt mein Fehler? Gruss Beda
Hallo,
"Beda Szukics"
Hallo Leute [...]
Dein Hauptproblem ist die start_tls Funktion, da du keine Zertifikate erzeugt hast und auch keine TLS Konfiguration in slapd.conf und vermutlich auch ldap.conf vorgenommen hast. Nimm in /etc/ldap.conf (das ist die Konfiguration für PAM) den Eintrag ssl start_tls; oder ssl on je nachdem welcher Eintrag aktiviert wurde,heraus, vermutlich ist auch ein TLS Eintrag in smb.conf, den auch entfernen.
eingerichtet. Den LDAP-Server lasse ich mit folgender sldap.conf laufen (gekuerzt): [...] argsfile /var/run/slapd/slapd.args access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read access to attribute=userPassword,lmPassword,ntPassword by dn="cn=Manager,dc=ksobwalden,dc=ch" write by anonymous auth by self write by * none access to * by dn="cn=Manager,dc=ksowbwalden,dc=ch" write
Die access Regeln werden dir auch Kopfschmerzen bereiten, aber das ist dann der zweite Schritt. Setze diese am besten zurück auf ,----[ access rules ] | access to dn.base="" by * read | access to dn.base=cn=Subschema by * read | access to * | by users read | by anonymous auth `---- Wenn du access Regeln verstanden hast, kannst du das wieder sinnvoll ändern.
database ldbm
Ich rate dir dringend, die Databasedefinition auf database bdb zu setzen. Dazu mußt du aber den Verzeichnisdienst vollständig neu aufsetzen. [...]
Ich erwarte jetzt eigentlich, dass ich mich unter dieser Kennung am System anmelden kann. Doch das geht nicht. getenv passwd zeigt mir auch die LDAP-Nutzer nicht. Und wenn ich jetzt mit su Superuser werden will, so bleibe ich der gleiche (ohne eine Fehlermeldung bei Eingabe des richtigen Passwortes). In var/log/warn aber erhalte ich den Eintrag: Mär 9 13:38:18 schola su: pam_ldap: ldap_starttls_s: Connect error Mär 9 13:38:18 schola su: pam_ldap: ldap_result Can't contact LDAP server Ich erhalte aber da keinen Eintrag, wenn ich mich als viktor anmelden will. Wo liegt mein Fehler?
Steht doch in der Logdatei, PAM kann den Ldapserver nicht erreichen, da dieser kein ldap_start_tls ausführen kann (mangels Zertifikat). Lies erst einmal http://www.openldap.org/doc/admin21/ dann setze den Server neu auf, wenn ein Minimalsystem läuft, dann beschäftige dich mit der Samba-Integration und zum Schluß mit TLS. -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter(at)dkluenter.de http://www.avci.de
Hi Dieter, Dieter Kluenter wrote:
Die access Regeln werden dir auch Kopfschmerzen bereiten, aber das ist dann der zweite Schritt. Setze diese am besten zurück auf
,----[ access rules ] | access to dn.base="" by * read | access to dn.base=cn=Subschema by * read | access to * | by users read | by anonymous auth `----
Aua, das tut ja weh!!! Du erlaubst damit jedem, die NT und LM-Hashes der Passwörter auszulesen. Unter Sicherheit verstehe ich etwas anderes. Dann lieber das, was er schon geschrieben hatte. Wo bitte siehst du da etwas, was Kopfschmerzen verursachen könnte? Grüße, tobi -- Universitätsklinik für Allgemeine Chirurgie Tübingen Telefon: (07071) - 29 86592 Nach 16.30 Uhr: (07071) - 29 70335 http://www.medizin.uni-tuebingen.de/~tsheide/
Hallo Tobia,
Tobias Heide
Hi Dieter,
Dieter Kluenter wrote:
Die access Regeln werden dir auch Kopfschmerzen bereiten, aber das ist dann der zweite Schritt. Setze diese am besten zurück auf ,----[ access rules ] | access to dn.base="" by * read | access to dn.base=cn=Subschema by * read | access to * | by users read | by anonymous auth `----
Aua, das tut ja weh!!! Du erlaubst damit jedem, die NT und LM-Hashes der Passwörter auszulesen. Unter Sicherheit verstehe ich etwas anderes.
Das stimmt so nicht, 'users' bedeutet, daß sich der Anwender authentifizieren muß, bevor er lesen darf, also wenigstens ein simple bind initiieren muß. Die Regel 'anonymous auth' bedeutet, daß ein Prozess durch Präsentation des userdn und Paßwortes ein OK von slapd bekommt, sofern daß Paßwort richtig ist, entspricht in etwa dem compare, es wird also kein Paßwort ausgelesen. Ich habe nicht von Sicherheit gesprochen. Mir ging es darum, erst einmal ein funktionsfähiges System zu bekommen und dann sukzessive restriktivere access Regeln anzuwenden.
Dann lieber das, was er schon geschrieben hatte. Wo bitte siehst du da etwas, was Kopfschmerzen verursachen könnte?
Die Kopfschmerzen kommen spätestens dann, wenn an den access Regeln nichts geändert wird, da DSAbase nicht gelesen werden konnte und der Aufbau der Regeln aufsteigend und nicht absteigend konstruiert war. -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter(at)dkluenter.de http://www.avci.de
Hi Dieter, Dieter Kluenter wrote:
Tobias Heide
writes: Aua, das tut ja weh!!! Du erlaubst damit jedem, die NT und LM-Hashes der Passwörter auszulesen. Unter Sicherheit verstehe ich etwas anderes.
Das stimmt so nicht, 'users' bedeutet, daß sich der Anwender authentifizieren muß, bevor er lesen darf, also wenigstens ein simple bind initiieren muß.
Okay, "jedem" war unklar ausgedrückt. Ich meinte schon jeden Benutzer. Da die meisten Angriffe aber eh von innen kommen (gerade bei einer Schule), ist das meiner Meinung nach auch nicht so relevant. Sobald ein Benutzer authentifiziert ist, hat er Lesezugriff auf *alles*. Find ich nicht gut, auch nicht für ein Testsystem.
Ich habe nicht von Sicherheit gesprochen. Mir ging es darum, erst einmal ein funktionsfähiges System zu bekommen und dann sukzessive restriktivere access Regeln anzuwenden.
Solange die Testdaten nur Versuchs-Daten sind, die im Produktivsystem nicht verwendet werden, habe ich damit kein Problem. Wobei ich eher Anhänger der Richtlinie "Nichts außer dem explizit erlaubten" bin. Fehler in den ACLs sind in den Fehlermeldungen zum Glück meist einfach erkennbar.
Dann lieber das, was er schon geschrieben hatte. Wo bitte siehst du da etwas, was Kopfschmerzen verursachen könnte?
Die Kopfschmerzen kommen spätestens dann, wenn an den access Regeln nichts geändert wird, da DSAbase nicht gelesen werden konnte und der Aufbau der Regeln aufsteigend und nicht absteigend konstruiert war.
Was verstehst du unter einer DSAbase? Meinst du den rootDSE? Der ist mit den ursprünglichen ACLs IMHO ohne Probleme lesbar. Grüße, tobi -- Universitätsklinik für Allgemeine Chirurgie Tübingen Telefon: (07071) - 29 86592 Nach 16.30 Uhr: (07071) - 29 70335 http://www.medizin.uni-tuebingen.de/~tsheide/
participants (3)
-
Beda Szukics
-
Dieter Kluenter
-
Tobias Heide