[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