2016-04-23 4 views
0

Mein Ziel ist es, die LDAP-Authentifizierung über die Befehlszeile zu testen. Ich habe versucht, ldapsearch dafür zu verwenden.ldapsearch - Ungültige Anmeldeinformationen

Ich verwende Centos 6.7

Auch wenn ich die richtigen Anmeldeinformationen bin mit dem folgenden Befehl fehlschlägt

[[email protected] html]# ldapsearch -x -h localhost -p 3389 -b "uid=john.martin,ou=Users,dc=company,dc=com" -W 
Enter LDAP Password: 
ldap_bind: Invalid credentials (49) 

Der folgende Befehl funktioniert ohne das Passwort-Feld.

ldapsearch -x -h localhost -p 3389 -b "uid=john.martin,ou=Users,dc=company,dc=com" 

Gibt es etwas, das mir fehlt, während ich versuche, das Passwort einzugeben? Könnte ich bitte um Hilfe bitten, um das Problem zu lösen?

AKTUALISIERT

Hier ist die Struktur eines Benutzerkontos

ldapsearch -x -h 127.0.0.1 -p 3389 -b "ou=Users,dc=company,dc=com" -s sub | more 

# john.martin, Users, company.com 
dn: uid=john.martin,ou=Users,dc=company,dc=com 
uid: john.martin 
objectClass: account 
objectClass: posixAccount 
objectClass: top 
objectClass: shadowAccount 
objectClass: ldapPublicKey 
shadowLastChange: 13306 
shadowMax: 99999 
shadowWarning: 7 
loginShell: /bin/bash 
uidNumber: 509 
homeDirectory: /home/john.martin 
mail: [email protected] 
gecos: john martin 
sshPublicKey:: some key 
gidNumber: 87 
cn: John Martin 

Hier ist die Abfrage von einer bestimmten cn

ldapsearch -h 127.0.0.1 -p 3389 -x -b "dc=company,dc=com" "(&(objectClass=posixGroup)(cn=member_of_this_group))" 

# extended LDIF 
# 
# LDAPv3 
# base <dc=company,dc=com> with scope subtree 
# filter: (&(objectClass=posixGroup)(cn=member_of_this_group)) 
# requesting: ALL 
# 

# member_of_this_group, groups, company.com 
dn: cn=member_of_this_group,ou=groups,dc=company,dc=com 
objectClass: posixGroup 
objectClass: top 
cn: member_of_this_group 
description:: some characters bla bla 
memberUid: john.martin 
memberUid: kyle.miller 
memberUid: robert.dangie 
memberUid: smith.collins 
memberUid: ian.bell 
gidNumber: 54787 

# search result 
search: 2 
result: 0 Success 

# numResponses: 2 
# numEntries: 1 
+0

Was Sie vermissen ist das richtige Passwort. Vielleicht hat der Account keinen. – EJP

+0

Hallo - Danke. Der Account hat ein Passwort. Wenn ich einen ssh auf den Server mit dem Benutzernamen versuche, akzeptiert es das Passwort. Es ist eine LDAP-Authentifizierung. Allerdings, wenn ich versuche LDAP-Suche akzeptiert es nicht das gleiche Passwort – usert4jju7

Antwort

2

Suche Wenn Sie nach einem Kennwort fragt nicht als der Client führt eine anonyme Bindung aus (deshalb sehen Sie in dem Beispiel, das nicht p ruf für das Passwortfeld).

Beachten Sie im ersten Beispiel, dass das Argument -b die Suchbasis und nicht den Bind-DN ​​festlegt. Sie müssen das Argument -D (für den Bind-DN) verwenden. Dies mag verwirrend klingen, aber das Befehlszeilentool ldapsearch führt im Wesentlichen eine LDAP-Verknüpfung aus, gefolgt von einer LDAP-Suche (daher die beiden Argumente).

+0

Danke Bertold. Ich habe die folgenden 2 Dinge ausprobiert: 'ldapsearch -x -h localhost -p 3389 -D 'uid = john.martin, ou = Benutzer, dc = company, dc = com" -W ", die sich immer noch über ungültige Anmeldedaten beschwert. 'ldapsearch -x -h localhost -p 3389 -D" uid = john.martin, ou = Benutzer, dc = company, dc = com "' throws 'nicht authentifizierte Bindung (DN ohne Kennwort) unzulässig'. Kann ich sonst noch etwas geben? – usert4jju7

+1

Sind Sie der Benutzer, dass der Bind-DN ​​korrekt ist? Ist "john.martin" in "ou = Users" oder ist es in ** cn = Users **? Es ist normal, wenn ein LDAP-Server ungültige Anmeldeinformationen für Fälle zurückgibt, in denen der Bind-DN ​​nicht existiert. –

+0

Danke Bertold. Ja, der Benutzer existiert. Ich habe einige Details in der Frage im Abschnitt "AKTUALISIERT" aktualisiert. Könnten Sie bitte einen Blick darauf werfen? – usert4jju7