Pierangelo Masarati wrote:
bind_policy soft
^^^ Questa direttiva non e' riconosciuta da OpenLDAP, meglio toglierla
ok, eliminata.
TLS_REQCERT never
TLS_CERT /usr/local/etc/openldap/ldap.client.pem
TLS_KEY /usr/local/etc/openldap/ldap.client.key.pem
^^^ queste due direttive sono ignorate, in quanto sono "user only" (come
indicato in ldap.conf(5) di OpenLDAP), mentre questo e' il file di
sistema. Non ha senso mettere una chiave privata in un file che e'
leggibile globalmente. La chiave privata puo' solo essere definita nel
file specifico di un utente (o di un'applicazione, come nel pam_ldap).
ok, spostate le due direttive in .ldaprc del mio utente ed in quello di
root.
[EMAIL PROTECTED]:~ >cat .ldaprc
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"
Ti faccio notare che l'esecuzione di questo comando, data la
configurazione che hai mostrato, non prevede nessuna validazione, da parte
del server, del certificato del client (in quanto, avendo messp
TLS_CERT/TLS_KEY nell'ldap.conf di sistema, e' come non averli messi
affatto; d'altra parte, il server e' stato configurato per non verificare
il certificato del client.
Allo stesso modo, il client non verifica il certificato del server (anche
se potrebbe, e dovrebbe!) in quanto TLS_REQCERT e' "never".
modificati slapd.conf, ldap.conf (di OpenLDAP) e ldap.conf/nss_ldap.conf
come segue:
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 demand
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
ldap.conf:
-------------
base dc=test,dc=org
uri ldaps://ferret.tomato.lan:636
TLS_REQCERT demand
TLS_CACERT /usr/local/etc/openldap/cacert.pem
ldap.conf/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 yes
#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
ferret# ps -auxww | grep slapd
ldap 27935 0.0 0.7 22900 17136 p4 I+ 12:20PM 0:00.31
/usr/local/libexec/slapd -h ldaps:/// -s-1 -d256 -u ldap -g ldap
ferret# 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
[snip]
# search result
search: 2
result: 0 Success
# numResponses: 12
# numEntries: 11
e dal log di slapd:
conn=11 fd=12 ACCEPT from IP=192.168.1.19:54634 (IP=0.0.0.0:636)
conn=11 fd=12 TLS established tls_ssf=256 ssf=256
conn=11 op=0 BIND dn="" method=128
conn=11 op=0 RESULT tag=97 err=0 text=
conn=11 op=1 SRCH base="dc=test,dc=org" scope=2 deref=0
filter="(objectClass=*)"
conn=11 op=1 SEARCH RESULT tag=101 err=0 nentries=11 text=
conn=11 op=2 UNBIND
conn=11 fd=12 closed
in questo caso, dato che sia lato server che lato client ho
esplicitamente chiesto di verificare i certificati,
posso finalmente dire che i certificati sono ok? Credo di si...
Provando con 'sudo' ottengo questo nei log:
conn=7 fd=11 ACCEPT from IP=192.168.1.19:53271 (IP=0.0.0.0:636)
conn=7 fd=11 TLS established tls_ssf=256 ssf=256
conn=7 op=0 BIND dn="" method=128
conn=7 op=0 RESULT tag=97 err=0 text=
conn=7 op=1 SRCH base="ou=SUDOers,dc=test,dc=org" scope=2 deref=0
filter="(cn=defaults)"
<= bdb_equality_candidates: (cn) index_param failed (18)
conn=7 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
conn=7 op=2 SRCH base="ou=SUDOers,dc=test,dc=org" scope=2 deref=0
filter="(|(sudoUser=piso)(sudoUser=%piso)(sudoUser=%piso)(sudoUser=%piso)(sudoUser=%wheel)(sudoUser=ALL))"
<= bdb_equality_candidates: (sudoUser) index_param failed (18)
<= bdb_equality_candidates: (sudoUser) index_param failed (18)
<= bdb_equality_candidates: (sudoUser) index_param failed (18)
<= bdb_equality_candidates: (sudoUser) index_param failed (18)
<= bdb_equality_candidates: (sudoUser) index_param failed (18)
<= bdb_equality_candidates: (sudoUser) index_param failed (18)
conn=7 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text=
conn=7 op=3 UNBIND
conn=7 fd=11 closed
conn=8 fd=11 ACCEPT from IP=192.168.1.19:55152 (IP=0.0.0.0:636)
conn=8 fd=11 TLS established tls_ssf=256 ssf=256
conn=8 op=0 BIND dn="" method=128
conn=8 op=0 RESULT tag=97 err=0 text=
conn=8 op=1 SRCH base="dc=test,dc=org" scope=2 deref=0
filter="(&(objectClass=posixGroup))"
conn=8 op=1 SRCH attr=cn userPassword memberUid uniqueMember gidNumber
conn=8 op=1 SEARCH RESULT tag=101 err=0 nentries=3 text=
conn=8 fd=11 closed (connection lost)
ed a parte i warning (?!?!) di cui sopra, il comando viene eseguito
correttamente.
Ora, se invece provo ad utilizzare ssh che, ripeto, su 389 funziona
correttamente, ottengo questo:
[EMAIL PROTECTED]:~ >ssh localhost
Connection closed by 127.0.0.1
slapd log:
conn=12 fd=11 ACCEPT from IP=192.168.1.19:58914 (IP=0.0.0.0:636)
TLS: can't accept.
conn=12 fd=11 closed (TLS negotiation failure)
e medesimo comportamento con phpldapadmin:
Error
Warning *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
)
slapd log:
conn=14 fd=11 ACCEPT from IP=192.168.1.19:59245 (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=14 fd=11 closed (TLS negotiation failure)
sudoers_base ou=SUDOers,dc=test,dc=org
pam_groupdn cn=smtp_box,ou=groups,dc=test,dc=org
pam_member_attribute memberUid
Questo attributo e' invalido; ho verificato la documentazione del pam_ldap
e in effetti e' ambigua, ma ti assicuro (dalla lettura del codice) che il
confronto per l'appartenenza ai gruppi avviene tra i valori di
pam_member_attribute e il DN della entry dello user, mentre memberUid e'
un numero, non un DN, quindi la richiesta fallisce sicuramente.
per ora lascio in sospeso un attimo questo problema, preferisco
concentrarmi su ldaps://.
bye,
P.
_______________________________________________
OpenLDAP mailing list
[email protected]
https://www.sys-net.it/mailman/listinfo/openldap
