Archiv verlassen und diese Seite im Standarddesign anzeigen : openldap-server einrichten...probleme
Hallo,
ich verscuhe schon seit einiger zeit einen openldap server auf einer suse linux prof 9.1-kiste aufzusetzen. die installation des servers ist kein problem. alles dort, wo es sein soll.
nun möchte ich ein organigramm im ldap abbilden. dazu habe ich mir eine datei mit der struktur (struct.ldif--->departments) angelegt und eine datei mit den angehörigen personen zur abteilung.
ich habe die slapd.conf und ldap.conf so weit ich es aus den x tutorials entnehmen konnte, konfiguriert.
wenn ich perldapadd -x -D "cn=root,dc=altana_HIT,dc=de" -W -f struct.ldif etwas hinzufügen möchte, erscheint:
deecm01:/etc/openldap # ldapadd -x -D "cn=root,dc=altana_HIT,dc=de" -W -f struct.ldif
Enter LDAP Password:
adding new entry "dc=altana_HIT, dc=de"
ldapadd: update failed: dc=altana_HIT, dc=de
ldap_add: Naming violation (64)
additional info: naming attribute 'dc' is not present in entry
hier mal die beiden config-files:
ldap.conf:
ldap_version 3
BASE dc=altana_HIT, dc=de
pam_password crypt
#URI ldap://ldap.example.com ldap://ldap-master.example.com:666
HOST deecm01.dekon.ap.altana
#SIZELIMIT 12
#TIMELIMIT 15
#DEREF never
TLS_REQCERT allow
und slapd.conf:
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/yast2userconfig.schema
#include /etc/openldap/schema/struct.schema
#include /etc/openldap/schema/department.schema
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org
#allow bind_v2
pidfile /var/run/slapd/run/slapd.pid
argsfile /var/run/slapd/run/slapd.args
# Load dynamic backend modules:
modulepath /usr/lib/openldap/modules
# moduleload back_ldap.la
# moduleload back_meta.la
# moduleload back_monitor.la
# moduleload back_perl.la
# Sample security restrictions
# Require integrity protection (prevent hijacking)
# Require 112-bit (3DES or better) encryption for updates
# Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64
# Sample access control policy:
# Root DSE: allow anyone to read it
# Subschema (sub)entry DSE: allow anyone to read it
# Other DSEs:
# Allow self write access
# Allow authenticated users read access
# Allow anonymous users to authenticate
# Directives needed to implement policy:
#access to dn.base="" by * read
#access to dn.base="cn=Subschema" by * read
#access to *
# by self write
# by users read
# by anonymous auth
#
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn. (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!
################################################## #####################
#
# bdb database definitions
################################################## #####################
database bdb
checkpoint 1024 5
cachesize 10000
suffix "dc=altana_HIT,dc=de"
rootdn "cn=root,dc=altana_HIT,dc=de"
# Cleartext passwords, especially for the rootdn, should
# be avoid. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
rootpw sun234
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory /var/lib/ldap
# Indices to maintain
index objectClass eq
danke schonmal :)
Hallo,
das Problem liegt in der struct.ldif - Datei. Hier soll ein neues dc-Objekt (dc=altana_HIT) angelegt werden. Für jedes Objekt können bzw. müssen Attribute angegeben werden. Für ein dc-Objekt muß ein dc-Attribut angegeben werden, etwa so:
# Container altana_HIT,de
dn: dc=altana_HIT,dc=de
dc: altana_HIT
objectclass: dcObject
objectclass: organization
o: altana
Gruss Olaf
[QUOTE=foruni.de]Hallo,
...
wenn ich perldapadd -x -D "cn=root,dc=altana_HIT,dc=de" -W -f struct.ldif etwas hinzufügen möchte, erscheint:
deecm01:/etc/openldap # ldapadd -x -D "cn=root,dc=altana_HIT,dc=de" -W -f struct.ldif
Enter LDAP Password:
adding new entry "dc=altana_HIT, dc=de"
ldapadd: update failed: dc=altana_HIT, dc=de
ldap_add: Naming violation (64)
additional info: naming attribute 'dc' is not present in entry
hallo,
danke olaf! ich werde es baldmöglichst ausprobieren!
viele grüsse
martin
hi,
ich habe den container, den du im quote geschrieben hast, mal in eine datei blub.ldif eingetragen und wollte diese einfügen.
folgender fehler erschien dann:
deecm01:/etc/openldap # ldapadd -x -D "cn=root,dc=altana_HIT,dc=de" -W -f blub.ldif
Enter LDAP Password:
adding new entry "dc=altana_HIT,dc=de"
ldapadd: update failed: dc=altana_HIT,dc=de
ldap_add: Already exists (68)
ldapsearch gibt das aus:
deecm01:/etc/openldap # ldapsearch -x
# extended LDIF
#
# LDAPv3
# base <> with scope sub
# filter: (objectclass=*)
# requesting: ALL
#
# search result
search: 2
result: 0 Success
# numResponses: 1
kein plan :( :)
danke schonmal :)
Hallo,
da der Container schon existiert, bricht ldapadd ab. Damit ldapadd aber mit dem nächsten Eintrag weitermacht, muß man einfach die Option -c setzen.
Gruss,Olaf
danke für den tipp... :)
ich muss aber noch weiter nerven :D
nun erhalte ich folgendes:
deecm01:/etc/openldap # ldapadd -xc -D "cn=root,dc=altana_HIT,dc=de" -W -f struct.ldif
Enter LDAP Password:
adding new entry "dc=altana_HIT,dc=de"
ldapadd: update failed: dc=altana_HIT,dc=de
ldap_add: Already exists (68)
adding new entry "dc=altana_HIT,dc=de"
ldapadd: update failed: dc=altana_HIT,dc=de
ldap_add: Object class violation (65)
additional info: attribute 'dc' not allowed
daaaaanke für die hilfe :)
Hallo,
na, wir nähern uns doch der Lösung.:-)
Das Attribut "dc" ist nur in der Objektklasse "dcObject" vorhanden.
Mögliche Lösung:
Ergänze im Eintrag für dc=altana_HIT... noch die Zeile
objectclass=dcObject.
Eventuell muß auch noch die Objektklasse "top" eingebunden werden (müßte ich aber erst in der Schema-Definition nachsehen). Du wirst ja sehen, ob er (sie oder es) danach verlangt.
Gruss Olaf
HI,
danke für die Ausdauer!
so, in der Datei struct.ldif steht:
# Container altana_HIT,de
dn: dc=altana_HIT,dc=de,objectclass=dcObject
dc: altana_HIT
objectclass: dcObject
objectclass: organization
o: altana
dn: dc=altana_HIT,dc=de
objectclass: organization
dc: altana_HIT
cn: ALTANA Pharma
objectclass: top
o: ALTANA Pharma
l: KN
wenn ich dieses adden will, erhalte ich folgendes:
ldapadd -xc -D "cn=root,dc=altana_HIT,dc=de,objectclass=dcObject" -W -f struct.ldif
Enter LDAP Password:
ldap_bind: Invalid DN syntax (34)
additional info: invalid DN
langsam kapier ich nix mehr :( ich habe einfach nur ein organigramm nach einer beispielstruktur aus dem internet angelegt. die frage, die ich mir stelle: in den .schema dateien sind ja die "attribute" wie telephone festgelegt - sind die angaben (attribute), die ich benutze schon implementiert?
ich muss doch sicher eine weitere schema-file anlegen (oder eine erweitern), wenn ich weitere (eigene) attribute hinzufügen möchte?
anbei zur übersicht hänge ich nochmal die beiden config-dateien im quote an!
ldap.conf:
ldap_version 3
BASE dc=altana_HIT, dc=de
pam_password crypt
#URI ldap://ldap.example.com ldap://ldap-master.example.com:666
HOST deecm01.dekon.ap.altana
#SIZELIMIT 12
#TIMELIMIT 15
#DEREF never
loglevel 255
TLS_REQCERT allow
slapd.conf
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/yast2userconfig.schema
#include /etc/openldap/schema/struct.schema
#include /etc/openldap/schema/department.schema
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org
#allow bind_v2
pidfile /var/run/slapd/run/slapd.pid
argsfile /var/run/slapd/run/slapd.args
# Load dynamic backend modules:
modulepath /usr/lib/openldap/modules
# moduleload back_ldap.la
# moduleload back_meta.la
# moduleload back_monitor.la
# moduleload back_perl.la
# Sample security restrictions
# Require integrity protection (prevent hijacking)
# Require 112-bit (3DES or better) encryption for updates
# Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64
# Sample access control policy:
# Root DSE: allow anyone to read it
# Subschema (sub)entry DSE: allow anyone to read it
# Other DSEs:
# Allow self write access
# Allow authenticated users read access
# Allow anonymous users to authenticate
# Directives needed to implement policy:
#access to dn.base="altana_HIT" by * read
#access to dn.base="cn=Subschema" by * read
access to *
by self write
by users read
# by anonymous auth
#
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn. (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!
################################################## #####################
#
# bdb database definitions
################################################## #####################
database bdb
checkpoint 1024 5
cachesize 10000
suffix "dc=altana_HIT,dc=de"
rootdn "cn=root,dc=altana_HIT,dc=de"
rootpw secret
# Cleartext passwords, especially for the rootdn, should
# be avoid. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory /var/lib/ldap
# Indices to maintain
index objectClass eq
dankeschön (ich weiss, ich nerve :(:))
Die Objektklassen, denen ein Objekt angehören soll, müssen in separaten Zeilen angegeben werden (also nicht mit in die dn:-Zeile schreiben)
# Container altana_HIT,de
dn: dc=altana_HIT,dc=de
dc: altana_HIT
objectclass: dcObject
objectclass: organization
o: altana
cn: ALTANA Pharma
objectclass: top
Die Attribute, die hier verwendet werden, sind in den eingebundenen Schemata schon definiert.
Man kann natürlich auch eigene Schemata mit eigenen Attributen definieren, dafür gibt es aber genaue Regeln, die man einhalten muß.
Aber vielleicht versuchst Du erst mal, das System mit den vorhandenen Schemata zum Laufen zu bekommen.;-)
hi,
danke :)
klar, ich versuche natürlich die fehlerquellen so klein wie möglich zu halten. ich habe es zu anfang mit der "quick-and-dirty" variante versucht ^^ nun wollte ich einfach diese fehlerquelle mit den schema's abklopfen und noch etwas tiefer gehen, da es so "oberflächlich" nicht geht :D
naja dann muss ich es wohl mit trial-and-error versuchen :D
...hatte ein problem noch beschrieben, welches sich erledigt hat
hi,
juhuu, endlich gehts :D ich konnte ein paar departments per shell einfügen. nun habe ich mir einen ldapbrowser heruntergeladen und mich erfolgreich zum server connected.
ich habe mir eine datei gebacken, worin mitarbeiter zu finden sind, welche zu einer abteilung gehören. wenn ich diese adde meldet ldap, dass das attribut uid nicht erlaubt ist:
dn: uid=ke, ou=HIT_CSS, dc=altana_HIT, dc=de
objectclass: person
ou: HIT_CSS
objectclass: organizationalperson
cn: Kai E.
sn: E
uid: kelsner
l: Konstanz
postalcode: 78462
#streetadress: F-W
#telephonenumber: 0190 222222
ergebnis aus der shell:
adding new entry "uid=ke, ou=HIT_CSS, dc=altana_HIT, dc=de"
ldapadd: update failed: uid=ke, ou=HIT_CSS, dc=altana_HIT, dc=de
ldap_add: Object class violation (65)
additional info: attribute 'uid' not allowed
da die standard-einstellungen (wenn keine gesetzt sind) auf read stehen, möchte ich die rechte nun ändern, damit ich schreiben kann.
ich habe einfach mal ein:
access to * by * write
in die slapd.conf eingefügt. nur ändert sich ncihts (nach dem neustart des dämons)
der browser ermöglicht mir, mich auch per user/pass zu authentifizieren. nur wie ? :D ich habe einen user mit uid=admin angelegt, aber ohne passwort.
thx :D
Hallo,
Das Problem, dass das Objekt uid=ke... nicht eingefügt werden kann, liegt an der LDIF-Datei. Das Attribut "uid" ist ein Attribut der Objektklasse "inetOrgPerson", die wiederum das Vorhandensein anderer Objektklassen erfordert.. Binde also für das Objekt uid=ke... mal folgende Objektklassen ein:
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
Solange Du keine User im LDAP-Verzeichnis angelegt hast, kannst Du den User verwenden, den Du in der slapd.conf unter rootdn definiert hast. Dieser User hat immer alle Rechte im LDAP-Verzeichnis, egal, welche ACL's Du noch so mit access definiert hast.
Welchen LDAP-Browser verwendest Du? Ich habe gq im Einsatz.
Gruss, Olaf
hi olaf,
ich habe "objectClass: inetOrgPerson" in meine ldif eingebunden, in der der Datensatz steht.
Dann hat es auch geklappt (ldapsearch liefert die Datensätze korrekt zurück).
Ich habe mir den normalen "ldapbrowser" angeschaut, bin aber bei JXplorer gelandet. Von den Features her kann ich nicht viel sagen - JXplorer ist vom "look-and-feel" her sehr angenehm (gibt es auch für Windows ^^ - keine Lust immer hin und her zu rennen :D)
danke :)
Martin
hi,
ich mal wieder :)
OpenLDAP-Server schnurrt gemütlich vor sich hin. Ich wollte nun zum Testen mal ein paar ACLs einrichten, um die Benutzerrechte mal einzuschränken und ein paar Use-Cases damit durchspielen.
Aus Selflinux@LDAP (http://www.selflinux.org/selflinux/html/ldap04.html) eine Regel:
# Das eigene userPassword kann von einem Benutzer geaendert
# werden. Die anderen Nutzer koennen es vergleichen (d.h. prüfen)
access to attr=userpassword
by self write
by group="cn=IT,dc=altana_HIT,dc=de" write
by * compare
Beim Neustart erhalte ich vom Server selbst direkt in die Konsole keinen Fehler, die Messages-Logfile gibt folgendes wieder:
Oct 13 10:02:01 deecm01 slapd[13873]: /etc/openldap/slapd.conf: line 33: unknown directive "by" inside backend database definition (ignored)
Oct 13 10:02:01 deecm01 slapd[13873]: /etc/openldap/slapd.conf: line 34: unknown directive "by" inside backend database definition (ignored)
Oct 13 10:02:01 deecm01 slapd[13873]: /etc/openldap/slapd.conf: line 35: unknown directive "by" inside backend database definition (ignored)
Klingt, als ob der Syntax nicht stimmt... :confused:
Thx 4 reading
martin
Hallo,
schön zu hören, dass der Server läuft.
Tja, so auf den ersten Blick kann ich keinen Fehler erkennen. Aber vielleicht will der Server jeweils einen Tabulator vor dem "by", um zu erkennen, dass dass alles zu einer access-Direktive gehört.
Gruss, Olaf
Hi,
was soll ich sagen: genau das wars!
Danke! (mal wieder) :)
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.