Pierangelo Masarati wrote:
Quello che intendo dire e' che i files
/usr/local/etc/ldap.conf
/usr/local/etc/nss_ldap.conf
nonostante abbiano LDAP nel nome non hanno molto a che fare con OpenLDAP;
sono i files di configurazione di due client che usano LDAP.
ok, come suggerito in lista, ho utilizzato ktrace (tool simile ad
strace) per vedere quali file di cfg
venivano effettivamente cercati dalle librerie OpenLDAP, ed ho scoperto
che il file di configurazione
ldap.conf veniva cercato in /usr/local/etc/openldap/ldap.conf (e non
/usr/local/etc/ldap.conf come
pensavo io).
Dopo aver creato un file ldap.conf adeguato, sono (finalmente) riuscito
ad utilizzare ldapsearch
su ldaps.
/usr/local/etc/openldap/slapd.conf:
include /usr/local/etc/openldap/schema/core.schema
include /usr/local/etc/openldap/schema/cosine.schema
include /usr/local/etc/openldap/schema/nis.schema
include /usr/local/etc/openldap/schema/inetorgperson.schema
include /usr/local/etc/openldap/schema/openldap.schema
include /usr/local/etc/openldap/schema/sudo.schema
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
modulepath /usr/local/libexec/openldap
moduleload back_bdb
database bdb
suffix "dc=test,dc=org"
rootdn "cn=Manager,dc=test,dc=org"
rootpw {SSHA}FNoRa4/LVSCsUBLKz6LQjLcayzvMfOw/
directory /var/db/openldap-data
index objectClass eq
index uid pres,eq,sub
TLSVerifyClient never
#TLSCipherSuite HIGH:MEDIUM:+SSLv2
TLSCACertificateFile /usr/local/etc/openldap/cacert.pem
TLSCertificateFile /usr/local/etc/openldap/servercrt.pem
TLSCertificateKeyFile /usr/local/etc/openldap/serverkey.pem
#access to *
#by self write
#by users read
#by anonymous auth
/usr/local/etc/openldap/ldap.conf:
base dc=test,dc=org
uri ldaps://ferret.tomato.lan:636
bind_policy soft
TLS_REQCERT never
TLS_CERT /usr/local/etc/openldap/ldap.client.pem
TLS_KEY /usr/local/etc/openldap/ldap.client.key.pem
TLS_CACERT /usr/local/etc/openldap/cacert.pem
#TLS_CIPHER_SUITE HIGH:MEDIUM:+SSLv2
[EMAIL PROTECTED]:~ >ps -auxww | grep slapd
ldap 17893 0.0 1.4 45940 35800 p4 S+ 4:30PM 0:00.78
usr/local/libexec/slapd -h ldapi://%2fvar%2frun%2fopenldap%2fldapi/
ldap:/// ldaps:/// -s-1 -d256 -u ldap -g ldap
[EMAIL PROTECTED]:~ >ldapsearch -b "dc=test,dc=org"
# extended LDIF
#
# LDAPv3
# base <dc=test,dc=org> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# test.org
dn: dc=test,dc=org
dc: test
objectClass: top
objectClass: domain
objectClass: domainRelatedObject
associatedDomain: test.org
# groups, test.org
dn: ou=groups,dc=test,dc=org
objectClass: top
objectClass: organizationalUnit
ou: groups
# people, test.org
dn: ou=people,dc=test,dc=org
objectClass: top
objectClass: organizationalUnit
ou: people
# StupidTest User, people, test.org
dn: cn=StupidTest User,ou=people,dc=test,dc=org
cn: StupidTest User
sn: Dummy
objectClass: top
objectClass: person
objectClass: posixAccount
objectClass: shadowAccount
uid: testuser
gecos: TestUser
homeDirectory: /home/test
uidNumber: 1999
loginShell: /bin/csh
userPassword:: e1NTSEF9MzY2Z2w1OTZIMmhERlFUSTVTNjE1VmdhOU55ZzM4TDY=
gidNumber: 1666
# smtp_box, groups, test.org
dn: cn=smtp_box,ou=groups,dc=test,dc=org
objectClass: top
objectClass: posixGroup
gidNumber: 1666
cn: smtp_box
memberUid: cn=StupidTest User,ou=people,dc=test,dc=org
# testozzo, groups, test.org
dn: cn=testozzo,ou=groups,dc=test,dc=org
cn: testozzo
memberUid: test
memberUid: testuser
objectClass: top
objectClass: posixGroup
gidNumber: 1999
# testazza, groups, test.org
dn: cn=testazza,ou=groups,dc=test,dc=org
cn: testazza
memberUid: test
memberUid: testuser
objectClass: top
objectClass: posixGroup
gidNumber: 666
# SUDOers, test.org
dn: ou=SUDOers,dc=test,dc=org
objectClass: top
objectClass: organizationalUnit
ou: SUDOers
# defaults, SUDOers, test.org
dn: cn=defaults,ou=SUDOers,dc=test,dc=org
objectClass: top
objectClass: sudoRole
cn: defaults
description: Default sudoOption's go here
# piso, SUDOers, test.org
dn: cn=piso,ou=SUDOers,dc=test,dc=org
objectClass: top
objectClass: sudoRole
cn: piso
sudoUser: piso
sudoHost: ALL
sudoRunAs: ALL
sudoCommand: ALL
sudoOption: !authenticate
# testuser, SUDOers, test.org
dn: cn=testuser,ou=SUDOers,dc=test,dc=org
cn: testuser
objectClass: top
objectClass: sudoRole
sudoHost: ALL
sudoOption: !authenticate
sudoRunAs: ALL
sudoUser: testuser
sudoCommand: ALL
# search result
search: 2
result: 0 Success
# numResponses: 12
# numEntries: 11
log di slapd:
conn=32 fd=14 ACCEPT from IP=192.168.1.19:56098 (IP=0.0.0.0:636)
conn=32 fd=14 TLS established tls_ssf=256 ssf=256
conn=32 op=0 BIND dn="" method=128
conn=32 op=0 RESULT tag=97 err=0 text=
conn=32 op=1 SRCH base="dc=test,dc=org" scope=2 deref=0
filter="(objectClass=*)"
conn=32 op=1 SEARCH RESULT tag=101 err=0 nentries=11 text=
conn=32 op=2 UNBIND
conn=32 fd=14 closed
Da questo deduco che:
-ldaps/certificati funzionano
-il server e' configurato correttamnente per ricevere
richieste da eventuali client
Ora pero' il mio problema si e' spostato sui client (ad esempio pam/nss)
i quali non ne vogliono
sapere di funzionare su ldaps:
/usr/local/etc/ldap.conf - /usr/local/etc/nss_ldap.conf:
base dc=test,dc=org
#uri ldaps://ferret.tomato.lan:636
uri ldap://ferret.tomato.lan
bind_policy soft
sudoers_base ou=SUDOers,dc=test,dc=org
pam_groupdn cn=smtp_box,ou=groups,dc=test,dc=org
pam_member_attribute memberUid
tls_checkpeer no
tls_cacertfile /usr/local/etc/openldap/cacert.pem
tls_cert /usr/local/etc/openldap/ldap.client.pem
tls_key /usr/local/etc/openldap/ldap.client.key.pem
utilizzando la 389 ssh funziona correttamnente e mi posso collegare con
utente testuser e/o utilizzando l'utente definito sulla mia macchina in
/etc/passwd.
Al contrario, se decommento la riga "#uri ldaps://ferret.tomato.lan:636"
nel file sopra citato, ssh smette di funzionare in tutti i sensi:
[EMAIL PROTECTED]:~ >ssh [EMAIL PROTECTED]
Connection closed by 127.0.0.1
[EMAIL PROTECTED]:~ >
slapd log:
conn=41 fd=14 ACCEPT from IP=192.168.1.19:58542 (IP=0.0.0.0:636)
TLS: can't accept.
conn=41 fd=14 closed (TLS negotiation failure)
medesima cosa accade se configuro phpldapadmin per usare ldaps al posto
di ldap:
phpldapadmin:
*Could not connect to "ldaps://ferret.tomato.lan" on port "636"*
*Backtrace*
*PHP Version* 5.2.3
*PLA Version* 1.0.2
*PHP SAPI* apache2handler
*Web Server* Apache/2.2.4 (FreeBSD) DAV/2 PHP/5.2.3 with
Suhosin-Patch mod_ssl/2.2.4 OpenSSL/0.9.8e
*File* /usr/local/www/phpldapadmin/lib/server_functions.php (353)
*Function* pla_error
Array
(
[0] => Could not connect to "ldaps://ferret.tomato.lan" on port "636"
)
*File* /usr/local/www/phpldapadmin/htdocs/login.php (125)
*Function* connect
Array
(
[0] => 1
[1] => user
[2] => 1
)
log slapd:
conn=47 fd=14 ACCEPT from IP=192.168.1.19:63045 (IP=0.0.0.0:636)
TLS: can't accept.
TLS: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca
s3_pkt.c:1053
conn=47 fd=14 closed (TLS negotiation failure)
Infine, se la lista e' dedicata esclusivamente ad OpenLDAP (come la
controparte 'ufficiale') mi scuso anticipatamente dell'OT,
ma pensavo che qualcuno di voi si fosse gia' imbattuto in problemi
simili e quindi ho pensato di chiedere lo stesso.
bye,
P.
_______________________________________________
OpenLDAP mailing list
[email protected]
https://www.sys-net.it/mailman/listinfo/openldap
