Hallo, schrieb Dieter Kluenter:
Sven Gehr
writes: schrieb Dieter Kluenter:
Sven Gehr
writes:
eines vorweg:
Nach den nun durchgeführten Änderungen startet saslauthd nicht mehr:
saslauthd[2979]: set_auth_mech: unknown authentication mechanism: ldap
Ein Login als User 'sven' funktioniert natürlich auch nicht mehr. Ich habe das Gefühl ich bewege mich im Kreis?
Irgendwie schon. Ich will das noch einmal zusammenfassen. TLS wird über den Standardport 389 und der URI LDAP:// durchgeführt. SSL wird über Port 636 und der URI LDAPS:// durchgeführt, du mußt dich da entscheiden was du möchtest, du kannst auch beide nehmen, dann sollte der Befehl 'ps ax' etwa folgende Zeilen zeigen
So ich entscheide mich jetz einfach für die Variante TLS also Port 389. Demzufolge muß ich jedoch wieder folgendes ändern: ***/etc/sysconfig*** von: SASL_AUTHMECH = ldap ändern auf: SASL_AUTHMECH = pam von: OPENLDAP_START_LDAPS = yes ändern auf: OPENLDAP_START_LDAPS = no In der Sysconfig gibt es derzeit folgende LDAP-relevanten Werte: BASE_CONFIG_DN = ou=ldapconfig,dc=kundennetz BIND_DN = cn=root,dc=kundennetz FILE_SERVER = yes OPENLDAP_START_LDAPS = no OPENLDAP_START_LDAPI = no OPENLDAP_SLAPD_PARAMS = OPENLDAP_USERS = ldap OPENLDAP_GROUP = ldap OPENLDAP_CHOWN_DIRS = yes OPENLDAP_RUN_DB_RECOVER = no OPENLDAP_LDAP_INTERFACES = OPENLDAP_LDAPs_INTERFACES = sind die alle so ok? *** /etc/saslauthd.conf ** von: ldap_servers: ldaps://testserver.kundennetz ldap_search_base: dc=kundennetz ändern auf: ldap_servers: ldap://testserver.kundennetz ldap_search_base: dc=kundennetz *** /etc/ldap.conf *** von: host 127.0.0.1 base dc=kundennetz ldap_version 3 pam_password md5 pam_filter objectclass=posixAccount nss_base_passwd dc=kundennetz nss_base_shadow dc=kundennetz nss_base_group dc=kundennetz ssl on ändern auf: host 127.0.0.1 base dc=kundennetz ldap_version 3 pam_password md5 pam_filter objectclass=posixAccount nss_base_passwd dc=kundennetz nss_base_shadow dc=kundennetz nss_base_group dc=kundennetz ssl start_tls In dieser Vorlagen-Datei gibt es noch jede Menge PAM- und NSS- Optionen. Sind die, die ich in meiner Config drin habe ausreichend bzw richtig? Desweiteren gibt es in dieser Datei noch folgende, auskommentierte TLS-Optionen: #tls_checkpeer yes #tls_cacertfile /etc/ssl/ca.cert #tls_cacertdir /etc/ssl/certs #tls_ciphers TLSv1 #tls_cert #tls_key Ist noch einer von diesen Parameter notwendig? Ich hoffe das wir hierdurch einen halbwegs einen definierten Zustand *hoff*
Den SASL-Authentifizierungsstring solltest du prüfen, der kann richtig
sein, kann aber auch um den SASL Realm erweitert sein. Ich habe hier auf zwei Systemen auch unterschiedliche Strings
Leider weiß ich nicht einmal was diese drei Zeilen bedeuten. Das macht es für mich schwierig den String zu überprüfen
Unter SASL wird üblicherweise die C API libsasl verstanden, d.h. eine Bibliothek, die in mit C progammierten Programmen eingebunden werden kann. Um einer Anwendung (in diesem Falle slapd) eine erfolgreiche Authentifizierung mitzuteilen, wird eine Zeichenkette erzeugt in der Form eines Distinguished Names, diese Zeichenkette besteht aus der uid, dem Mechanismus und dem Wort auth, gegebenenfalls ist noch der sasl realm in dieser Zeichenkette enthalten. Nachstehend habe ich zwei Bespiele einer solchen Zeichenkette aufgezeigt.
"uid=dieter,cn=avci,cn=GSSAPI,cn=auth" ist eine Variante, die ander ist "uid=dieter,cn=GSSAPI,cn=auth"
Also das bleibt mir irgendwie verwehrt was dieser String macht. Ich habe bisher an dem Testsystem nur root und einen Testuser (sven). Alle Tests, von den wir die ganze Zeit reden, mache ich lokal an diesem Rechner als root. Warum soll ein SASL Realm wie in diesem Beispiel einen User enthalt (hier uid=dieter). Das fehlt mir das Verstännis für.
Weiter unten habe ich ja den Inhalt aus meinem LDAP-Verzeichnis gepostet. Wie müßte das bei mir lauten?
So sieht der Logauszug bei mir aus ,----[ Auszug aus localmessages ]
| [1928]: slap_sasl_regexp: converting SASL name | uid=dieter,cn=gssapi,cn=auth [1928]: slap_sasl_regexp: converted SASL | name to ldap:///o=avci,c=de??sub?uid=dieter [1928]: slap_parseURI: | parsing ldap:///o=avci,c=de??sub?uid=dieter [1928]: getdn: dn:id | converted to cn=dieter kluenter,ou=partner,o=avci,c=de
In /var/log/localmessages sollte sich der SASL String finden.
Also so wirklich fnden tue ich da nichts. Hier das Ende der der Datei. Ich habe nur die LDAP-Meldungen herauskopiert:
slapd[2367]: conn=54 fd=31 ACCEPT from IP=127.0.0.1:32832 (IP=0.0.0.0:389) slapd[2367]: conn=54 op=0 BIND dn="" method=128 slapd[2367]: conn=54 op=0 RESULT tag=97 err=0 text= slapd[2367]: conn=54 op=1 SRCH base="dc=kundennetz" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=root))"
Aha, eine Verbindung über localhost.
Wie gesagt, ich mache alles im Moment lokal an dem Rechner.
hier wird root als Suchfilter benutzt
slapd[2367]: conn=54 op=1 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass
Die obigen Attribute für root werden gesucht
slapd[2367]: conn=54 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= slapd[2367]: conn=54 op=2 SRCH base="dc=kundennetz" scope=2 deref=0 filter="(&(objectClass=posixGroup)(memberUid=root))" slapd[2367]: conn=54 op=2 SRCH attr=cn userPassword memberUid uniqueMember gidNumber slapd[2367]: conn=54 op=2 SEARCH RESULT tag=101 err=0 nentries=0 text= slapd[2367]: conn=54 fd=31 closed
es wurde kein Eintrag für root gefunden, (nentries=0)
slapd[2367]: conn=55 fd=31 ACCEPT from IP=127.0.0.1:32833 (IP=0.0.0.0:389) slapd[2367]: conn=55 op=0 BIND dn="" method=128 slapd[2367]: conn=55 op=0 RESULT tag=97 err=0 text= slapd[2367]: conn=55 op=1 SRCH base="dc=kundennetz" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=root))"
und noch einmal
Und warum nicht?
2. OpenLDAP ist ohne SASL Support kompiliert worden, Da hilft dann 'ldapsearch -H ldap://localhost -b "" -s base + -x' es sollten dir dann alle operationalen Attribute angzeigt werden, auch die Attribute für 'supportedSASLMechanisms'
Ich denke mal da fehlt schon etwas. Dieser Befehl erzeugt die Ausgabe:
supportedFeatures: 1.3.6.1.4.1.4203.1.5.4 supportedFeatures: 1.3.6.1.4.1.4203.1.5.5 supportedLDAPVersion: 3 subschemaSubentry: cn=Subschema
da fehlt einiges, z.b. der folgende Auszug
supportedSASLMechanisms: GSSAPI supportedSASLMechanisms: ANONYMOUS supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: PLAIN
ok, aber was bedeutet das jetzt für mich? Ist die von mir angedachte Vorgehensweis so nicht möglich?
saslauthd ist gestartet. LDAP ist über sysconfig auf Port 636 konfiguriert und /etc/sysconfig/saslauthd_authmech=ldap konfiguriert.
ok, das ist ja wie ganz oben beschrieben (sysconfig) wieder auf pam umgestellt. Viele Grüße Sven