OpenLDAP läuft, aber kein Zugriff möglich...

[Yoda]

Hi Leute,
ich bin nach der QuickStart-Anleitung auf openldap.org vorgegangen:
http://www.openldap.org/doc/admin23/quickstart.html

Danach sollte es ja ganz einfach sein....

Naja, im Detail hab ich folgendes gemacht:

Folgende PKGs sind installiert:
- openldap
- openldap-clients
- libldap
- libsasl
- cyrus-sasl
- cyrus-sasl-plugins
und natürlich alle Abhängigkeiten.

mkdir -p /home/openldap/data
cp /var/lib/openldap/openldap-data/DB_CONFIG.example /home/openldap/data/DB_CONFIG

vi /etc/openldap/ldap.conf
BASE dc=domain, dc=de
URI ldap://fritz.domain.de
SIZELIMIT 12
TIMELIMIT 15
DEREF never

vi /etc/openldap/slapd.conf
include /etc/openldap/schema/core.schema
pidfile /var/run/slapd.pid
argsfile /var/run/slapd.args
database bdb
suffix dc=domain,dc=de
rootdn cn=Manager,dc=domain,dc=de
rootpw secret
directory /home/openldap/data
index objectClass eq
loglevel -1
schemacheck on

slaptest
config file testing succeeded

/etc/rc.d/slapd start
netstat -an | grep 389
tcp 0 0 0.0.0.0:389 0.0.0.0:* LISTEN
tcp 0 0 :::389 :::* LISTEN

Also nach diesen Ausgaben sollte eigentlich alles klar sein.
Aber das nächste geht schon nicht:

ldapsearch -x -b '' -s base '(objectclass=*)' namingContexts
ldap_bind: Can't contact LDAP server (-1)

Das folgende hab ich zwar noch versucht, funktionierte aber natürlich auch nicht:

vi test.ldif
dn: dc=domain,dc=de
objectclass: dcObject
objectclass: organization
o: Interactive Data Managed Solutions
dc: domain
dn: cn=Manager,dc=domain,dc=de
objectclass: organizationalRole
cn: Manager

cat /home/fritz/test.ldif | ldapadd -x -D cn=Manager,dc=domain,dc=de -W
ldap_bind: Can't contact LDAP server (-1)

Dann hab ich mir noch den grafischen LDAP-Browser gesaugt, der in Java geschrieben wurde.

http://www-unix.mcs.anl.gov/~gawor/ld...
tar -xf Browser282b2.tar.gz
cd ldapbrowser/
sh lbe.sh

Die Testseite funktionierte auch, aber mein LDAP-Server war einfach nicht erreichbar, obwohl er online ist....

Und den Gnome-LDAP-Client "lat" hab ich dann auch installiert um vielleicht noch etwas mehr zu sehen, aber nix...

der FQDN fritz.domain.de ist im DNS eingetragen und erreichbar. Es ist aber trotzdem meine lokale Maschine.


in der Logdatei /var/log/auth.log kamen beim Start vom LDAP-Server folgende Meldungen:

Dec 1 12:15:28 fritz slapd[15699]: sql_select option missing
Dec 1 12:15:28 fritz slapd[15699]: auxpropfunc error no mechanism available
Dec 1 12:15:28 fritz slapd[15699]: _sasl_plugin_load failed on sasl_auxprop_plug_init for plugin: sql
Dec 1 12:15:28 fritz slapd[15699]: auxpropfunc error invalid parameter supplied
Dec 1 12:15:28 fritz slapd[15699]: _sasl_plugin_load failed on sasl_auxprop_plug_init for plugin: ldapdb



Weis einer was ich jetzt machen muss???

 

[theton]

_sasl_plugin_load failed on sasl_auxprop_plug_init for plugin: sql

Wozu auch immer, aber es sieht so aus, als würde dir libsasl2-modules-sql fehlen. Andererseits... muss die base-dn nicht mit der URI übereinstimmen?

BASE dc=fritz, dc=domain, dc=de
URI ldap://fritz.domain.de

Bin mir da nicht ganz sicher, aber ich mache das zumindest immer so. Der letzte LDAP-Server ist schon eine Weile her bei mir und ICH HASSE LDAP. Es gibt nichts schlimmeres. *find* (ausser Windows natürlich ) Jedes Mal muss ich mich neu einlesen, weil das einfach nicht in meinem Kopf bleiben will.

 

[Yoda]

_sasl_plugin_load failed on sasl_auxprop_plug_init for plugin: sql

Wozu auch immer, aber es sieht so aus, als würde dir libsasl2-modules-sql fehlen. Andererseits... muss die base-dn nicht mit der URI übereinstimmen?

BASE dc=fritz, dc=domain, dc=de
URI ldap://fritz.domain.de

Bin mir da nicht ganz sicher, aber ich mache das zumindest immer so. Der letzte LDAP-Server ist schon eine Weile her bei mir und ICH HASSE LDAP. Es gibt nichts schlimmeres. *find* (ausser Windows natürlich ) Jedes Mal muss ich mich neu einlesen, weil das einfach nicht in meinem Kopf bleiben will.

Danke!
Ja, Du hast recht. LDAP bereitet ganz schöne Schmerzen....

Das mit dem Modul, kann eigentlich nicht sein, denn für meine Distribution gibt es nur drei SASL-PKGs und die hab ich schon alle installiert.

Das mit dem "base-dn" verstehe ich nicht so ganz. BASE und URI sind bei mir doch gleich, oder gibt es zwischen BASE und BASE-DN einen Unterschied?

 

[theton]

Evtl. stimmen sie jetzt überein. Bei deinem letzten Post taten sie das nicht:

vi /etc/openldap/ldap.conf
BASE dc=domain, dc=de
URI ldap://fritz.domain.de
SIZELIMIT 12
TIMELIMIT 15
DEREF never

 

[Yoda]

Evtl. stimmen sie jetzt überein. Bei deinem letzten Post taten sie das nicht:

Achso, das meinst Du!
Jetzt verstehe ich....

Ja, das steht bei mir nicht richtig drin, werd ich gleich mal machen.

 

[Yoda]

wenn ich in der "/etc/openldap/ldap.conf" die Zeile
BASE dc=domain, dc=de
gegen
BASE dc=fritz, dc=domain, dc=de
austausche, läst sich OpenLDAP nicht mehr starten....

Vielleicht noch eine andere Idee?

 

[theton]

Hmm, also das einzige, was mir jetzt noch spontan auffällt ist der fehlende Module-Path in deiner slapd.conf und das vollständige Fehlen von Zugriffsbestimmungen.

 

[Yoda]

Hmm, also das einzige, was mir jetzt noch spontan auffällt ist der fehlende Module-Path in deiner slapd.conf und das vollständige Fehlen von Zugriffsbestimmungen.

Es gibt einen auskommentierten 'modulepath' in der Conf-Datei, allerdings gibt es diesen im ganzen System nicht. Ich konnte auch keine Dateien mit der Endung "*.la" finden, die zu OpenLDAP gehören (nur zu KDE und vmware-player).

Ich habe zwei Module mal aktiviert:

# Load dynamic backend modules:
# modulepath /usr/sbin/openldap
moduleload back_bdb.la
# moduleload back_ldap.la
# moduleload back_ldbm.la
moduleload back_passwd.la
# moduleload back_shell.la

Er startet und meckert nicht....


Wie müssten den die Zugriffsbestimmungen aussehen?

 

[theton]

Beispiel für Zugriffskontrolle:

access to dn.base=""
        by * read

access to dn.base="cn=Subschema"
        by * read

access to *
        by * read