[Date Prev][Date Next] [Chronological] [Thread] [Top]

Clarification on SSL/TLS and GQ problem



Hello,


I'm attempting to do what it seems like everyone else on this list. Do
the single sign on auth via LDAP. I've read a ton of documentation and
have been able to get simple authentication working with pam-ldap. I'm
going to eventually implement postfix and courier as well. However,
before that I want to protect the traffic being passed back and forth.
I've read all sorts of docs on ssl, sasl, tls, ldap and ldaps, and to be
quite honest I'm very confused as to how each fits in. I've gone through
the mailing list archives and it seems I'm not alone. Perhaps a security
guru can take the time to explain how all these fit together in the
context of openldap, I for one would really benefit. As it stands now I
think I've got tls working, I apt-get source'd the debian packages and
changed them to with-tls, read up on openssl docs, which I must admit
I'm a newbie at as well, but I think I got it done. I created the
certificates, hurdled the CN= issue gracefully and managed to start my
slapd with all sorts of wonderful TLS options. I apt-get source'd the
ldap-utils package and rebuilt it with tls on my mailserver. Did a
ldapsearch with -ZZ and got a success message however..... 

I run tcpflow -i eth0 -c port 389 on my directory server and attempt to
browse the directory, much to my dissapointment I can cleary read
strings and values in the tcpflow window. My password is of course
prefixed with {crypt} and is infact crypted, but I don't think I'm
getting tls security. Pursuing the ldaps:// business it appears
something is listening on 636, however netstat -a --numeric-ports | grep
389 and 636 yeild the following:
rauru:~# netstat -a --numeric-ports | grep -i  389
tcp        0      0 0.0.0.0:389             0.0.0.0:*              
LISTEN
tcp        1      0 127.0.0.1:33266         127.0.0.1:389          
CLOSE_WAIT
tcp        0      0 127.0.0.1:33566         127.0.0.1:389          
ESTABLISHED
tcp        0      0 127.0.0.1:33564         127.0.0.1:389          
ESTABLISHED
tcp        0      0 127.0.0.1:33572         127.0.0.1:389          
ESTABLISHED
tcp        0      0 127.0.0.1:33570         127.0.0.1:389          
ESTABLISHED
tcp        0      0 127.0.0.1:33569         127.0.0.1:389          
ESTABLISHED
tcp        1      0 127.0.0.1:33501         127.0.0.1:389          
CLOSE_WAIT
tcp        1      0 127.0.0.1:33498         127.0.0.1:389          
CLOSE_WAIT
tcp        1      0 127.0.0.1:33499         127.0.0.1:389          
CLOSE_WAIT
tcp        0      0 127.0.0.1:389           127.0.0.1:33564        
ESTABLISHED
tcp        0      0 127.0.0.1:389           127.0.0.1:33566        
ESTABLISHED
tcp        0      0 127.0.0.1:389           127.0.0.1:33569        
ESTABLISHED
tcp        0      0 127.0.0.1:389           127.0.0.1:33570        
ESTABLISHED
tcp        0      0 127.0.0.1:389           127.0.0.1:33572        
ESTABLISHED
rauru:~# netstat -a --numeric-ports | grep -i  636
tcp        0      0 0.0.0.0:636             0.0.0.0:*              
LISTEN
rauru:~#

Can anyone clarify this issue for me or point me to a link that
describes how all the security mechanisms interact with one another.

 Also,

I have a similar problem to the fellow with the gq issue. I can use
ldapmodify from localhost, but gq from my laptop fails wihen I bind with
the correct dn and password. Whats interesting is when I do properly
authenticate with the admin  password I see the users field. When I
don't I see the users information minus the password field. Doesn't this
mean that the authentication as the admin is successful and I should be
able to modify entries instead of getting the insufficient access error.

My acls are as follows:
access to attr=userPassword
        by dn="cn=admin,dc=sterlingcrane,dc=ca" write
        by anonymous auth
        by self write
        by * auth
                                                                                
access to *
        by dn="cn=admin,dc=sterlingcrane,dc=ca" write
        by self write
        by anonymous read


When I set the loglevel to 128 (ACL processing) I see the following:
Mar  2 23:38:17 rauru slapd[31149]: => access_allowed: write access to
"uid=jhenkel,ou=staff,ou=people,dc=sterlingcrane,dc=ca" "description"
requested
Mar  2 23:38:17 rauru slapd[31149]: => acl_get: [1] check attr
description
Mar  2 23:38:17 rauru slapd[31149]: => acl_get: [2] check attr
description
Mar  2 23:38:17 rauru slapd[31149]: <= acl_get: [2] acl
uid=jhenkel,ou=staff,ou=people,dc=sterlingcrane,dc=ca attr: description
Mar  2 23:38:17 rauru slapd[31149]: => acl_mask: access to entry
"uid=jhenkel,ou=staff,ou=people,dc=sterlingcrane,dc=ca", attr
"description" requested
Mar  2 23:38:17 rauru slapd[31149]: => acl_mask: to all values by "",
(=n)
Mar  2 23:38:17 rauru slapd[31149]: <= check a_dn_pat:
cn=admin,dc=sterlingcrane,dc=ca
Mar  2 23:38:17 rauru slapd[31149]: <= check a_dn_pat: self
Mar  2 23:38:17 rauru slapd[31149]: <= check a_dn_pat: anonymous
Mar  2 23:38:17 rauru slapd[31149]: <= acl_mask: [3] applying read
(=rscx) (stop)
Mar  2 23:38:17 rauru slapd[31149]: <= acl_mask: [3] mask: read (=rscx)
Mar  2 23:38:17 rauru slapd[31149]: => access_allowed: write access
denied by read (=rscx)

Obviously the last entry is the one that is causing the whole process to
fail but I don't understand what could be wrong.



I would really appreciate the LDAP experts help on these issues.

Thanks, 

Jayson

-- 
Jayson Henkel <jhenkel@sterlingcrane.ca>
Sterling Crane