Hi Forum!

Kennt sich jemand mit ldap aus?

Ich habe einen slapd laufen - der antwortet auch....denke auch, wie er soll:
ein diff der suchabfragen nach (objectclass=*), sagt, die Antworten beider Server
waeren identisch.

Nun versuche ich mich an ldap.alt zu authentifizieren: Klappt und geht!

Nun versuche ich es an ldap.neu - geht nicht.

Log-message bei loglevel 4:
-----------------------------------SNIPP--------------------------------------------
Jan 25 17:46:44 localhost slapd[2579]: slapd starting
Jan 25 17:48:38 localhost nscd: nss_ldap: reconnecting to LDAP server...
Jan 25 17:48:38 localhost slapd[2581]: connection_get(11)
Jan 25 17:48:38 localhost slapd[2587]: send_ldap_result: err=0 matched="" text=""
Jan 25 17:48:38 localhost slapd[2581]: connection_get(11)
Jan 25 17:48:38 localhost slapd[2587]: SRCH "dc=ct,dc=dom" 2 0
Jan 25 17:48:38 localhost slapd[2587]: 1 0 0
Jan 25 17:48:38 localhost slapd[2587]: filter: (&(objectClass=posixAccount)(uid=sgl))
Jan 25 17:48:38 localhost slapd[2587]: attrs:
Jan 25 17:48:38 localhost slapd[2587]: uid
Jan 25 17:48:38 localhost slapd[2587]: userPassword
Jan 25 17:48:38 localhost slapd[2587]: uidNumber
Jan 25 17:48:38 localhost slapd[2587]: gidNumber
Jan 25 17:48:38 localhost slapd[2587]: cn
Jan 25 17:48:38 localhost slapd[2587]: homeDirectory
Jan 25 17:48:38 localhost slapd[2587]: loginShell
Jan 25 17:48:38 localhost slapd[2587]: gecos
Jan 25 17:48:38 localhost slapd[2587]: description
Jan 25 17:48:38 localhost slapd[2587]: objectClass
Jan 25 17:48:38 localhost slapd[2587]:
Jan 25 17:48:38 localhost slapd[2587]: bdb_idl_fetch_key: [b49d1940]
Jan 25 17:48:38 localhost slapd[2587]: bdb_idl_fetch_key: [5941c014]
Jan 25 17:48:38 localhost slapd[2587]: bdb_idl_fetch_key: [2907f48c]
Jan 25 17:48:38 localhost slapd[2587]: send_ldap_result: err=0 matched="" text=""
Jan 25 17:48:38 localhost nscd: nss_ldap: reconnected to LDAP server after 1 attempt(s)
-----------------------------------SNIPP--------------------------------------------

Ideen?

Waere sehr dankbar!

Kind regards,
Bernd

Moechte einfach mal die Loesung präsentieren.

Ich habe die notwendigen Einstellungen in der /etc/ldap/slapd.conf erst nachdem ich
die Daten bei laufendem slapd (Soll man nicht) umgezogen habe - angepasst. Daher gab es keine Indizes.

Habe das ganze behoben, indem ich "slapindex" aufgerufen habe - und siehe da....geht.



Kind regards,

Bernd Schwaegerl

Nachdem einige Hits bez. dieses Topics zu verbuchen sind - hoffe ich, dass es Jemandem helfen moege.

Hi all,

da stellt sich trotzdem noch eine Frage:

Vielleicht die Vorgeschichte, ich habe hier etliche LDAP-Clients am Laufen. Wie beschrieben, geht es nun auch auf meinem neuen Server...wenn es nicht die Worte...
BIS AUF ...gäbe....

BIS AUF ssh.

Bei ssh fragt das Ding den LDAP-Daemon (schon mal gut):
Jan 26 15:58:08 localhost slapd[1906]: connection_get(16)
Jan 26 15:58:08 localhost slapd[1945]: SRCH "dc=ct,dc=dom" 2 0
Jan 26 15:58:08 localhost slapd[1945]: 1 0 0
Jan 26 15:58:08 localhost slapd[1945]: filter: (&(objectClass=shadowAccount)(uid=sgl))
Jan 26 15:58:08 localhost slapd[1945]: attrs:
Jan 26 15:58:08 localhost slapd[1945]: uid
Jan 26 15:58:08 localhost slapd[1945]: userPassword
Jan 26 15:58:08 localhost slapd[1945]: shadowLastChange
Jan 26 15:58:08 localhost slapd[1945]: shadowMax
Jan 26 15:58:08 localhost slapd[1945]: shadowMin
Jan 26 15:58:08 localhost slapd[1945]: shadowWarning
Jan 26 15:58:08 localhost slapd[1945]: shadowInactive
Jan 26 15:58:08 localhost slapd[1945]: shadowExpire
Jan 26 15:58:08 localhost slapd[1945]: shadowFlag
Jan 26 15:58:08 localhost slapd[1945]:
Jan 26 15:58:08 localhost slapd[1945]: bdb_idl_fetch_key: [b49d1940]
Jan 26 15:58:08 localhost slapd[1945]: bdb_idl_fetch_key: [64a68d50]
Jan 26 15:58:08 localhost slapd[1945]: bdb_idl_fetch_key: [2907f48c]
Jan 26 15:58:08 localhost slapd[1945]: send_ldap_result: err=0 matched="" text=""

Stelle ich nun die selbe Frage (shadow.... + uid) dann erhalte ich auch Antwort von dem betreffenden Server - nur leider..... ...leider:
login as: sgl
sgl@10.10.150.91's password:
Access denied

=> Das Password habe ich nun schon 29320380923 getippt, somit sei ausgeschlossen, dass ich mich jedesmal vertippt habe....

/etc/pam.d/ssh muesste o.k. sein - in der sshd_config habe ich auch "UsePAM yes"
stehen und PasswordAuthentification yes (tunneled cleartext-passwords...

:/

Finde derzeit keinen Ansatzpunkt -habe alles genauso eingestellt, wie bei einem debian-client hier....auf dem geht's....

Weiss Jemand Rat - oder Einstellungen die man checken sollte?

Hi Michael,

der filter bringt sehr wohl ein Ergebnis (siehe unten). Selbst wenn ich den (bald) alten fileserv eintrage, komme ich zum selben Ergebnis (ssh-login fuer Ldap-User geht nicht)....

Wo wuerde man den Filter eintragen? (Wohlgemerkt - es sieht mir nach einem "client-problem" aus....)

LDAPSEARCH:
-------------------------SNIPP-----------------------
ldapsearch -x "(&objectclass=shadowaccount)(uid=sgl))" -h <HOSTIP>
# Bernd Schwaegerl, nbg, users, ct.dom
dn: cn=Bernd Schwaegerl,ou=nbg,ou=users,dc=ct,dc=dom
objectClass: top
objectClass: person
objectClass: posixAccount
objectClass: shadowAccount
objectClass: inetLocalMailRecipient
cn: Bernd Schwaegerl
sn: Schwaegerl
description: // DELETED //
uid: sgl
uidNumber: 553
gidNumber: 100
homeDirectory: /home/sgl
loginShell: /bin/bash
mailLocalAddress: // DELETED //

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1
-------------------------SNIPP-----------------------

Hi Michael,

konnte das Problem nun einkreisen. Und glaube, dass mir ein bisschen Wissen bezueglich Zertifikaten fehlt.

Ich habe von unserem alten Server das CA-Cert übernommen, habe dann einen
key generiert...mit:
openssl dsaparam 4096 -out dsaparams
openssl gendsa -out ../keys/$1.key dsaparams
dann einen Request erstellt:
...mit....
openssl req -days 1500 -new -key ../keys/$1.key -out ../requests/$1.csr -config ../openssl.cnf
und dann auf dem neuen Server mit der CA des alten Servers den request gesigned
mit:
openssl x509 -req -in ../requests/$1.csr -CA /etc/ssl/certs/CT-Cacert.pem -CAkey /sysadmin/administration/keys/CT-CAkey.pem -CAcreateserial > ../signed/$1.pem

Wobei $1 immer der Servername mit voller Domain war.

Wenn ich nun versuche vom Rechner selbst die Daten zu überprüfen, erhalte ich
folgendes:
fsmirror02:~# openssl s_client -connect fsldap02.nbg.ct.dom:636 -showcerts CONNECTED(00000003)
1990:error:14077410SL routinesSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:473:

Aeh.....und das selbe erhalte ich mit ldapsearch an die ldaps-Adresse.....

?????????????????????????????????

Zum Fehler habe ich gefunden: "Sie arbeiten mit einer fremden CA ist doch klar!"

- Nun stellt sich die Frage, wie ich den Rechner dazu bringen kann mit der fremden
CA zu arbeiten (es geht ja nur noch drum dem SSH beizubringen, dass es das o.k. findet) - oder aber welche Schritte zu unternehmen sind, damit es laeuft

....dabei stellt sich aber die Frage (die ich nicht beantworten kann) - wieviele Dienste die Antwort unter dieser CA... erwarten....

Klingt planlos - stimmt auch einigermassen....

Ich habe keine Ahnung, welche Seiteneffekte es hat, wenn ich mit einer anderen CA das Ganze ersetze.

Kind regards,

Bernd

Mhh, ist ein gewisses Eigeninteresse dabei - ich habe eine Site gefunden, da ist EXAKT mein Problem beschrieben - aber leider nur, was das Problem ist ("ist doch klar....") - aber nicht die zwei Lösungen, die sich ergeben dürften.

(Die wären z.B.:
1. Du willst die alte/fremde CA nutzen, dann mach das:....
2. Du willst eine neue erstellen, dann mach' das.

2. weiss ich denke ich - ich will aber 1. (((
)

Da auf der Site nichts mehr steht, weiss ich nicht, wie 1. anzupacken ist. Ausserdem weiss ich nicht, ob das bloed ist. Ausserdem langweilt es mich mit so einem Mist mittlerweile den dritten Tag zu verbringen...... :/

@*# LDAP!