[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Turning off clear text - how 2 get tls only communications?
- To: openldap-software@OpenLDAP.org
- Subject: Turning off clear text - how 2 get tls only communications?
- From: "Jim C." <jcllings@javahop.com>
- Date: Tue, 15 Jun 2004 16:41:41 -0700
- User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I'm doing something wrong here. My objective is to turn off clear text
ldap communications with remote clients and use only tls on a Linux
system that uses ldap auth. Clear text with clients located on the
server is OK.
Questions to be answered:
1. Is ldaps the same as tls? This is to say that if I set ssl start_tls
on the client, and set the ldap uris on slapd to "ldap://127.0.0.1/
ldaps:///" then in theory it *should* communicate ldaps on port 389 and
ldap on port 389 but only on the server. This does not seem to be the
case. What exactly should happen when I change the uri as mentioned?
Looking at the slapd man pages under "-h", it says that the default port
for ldap is 389 and for ldaps it is 636, it doesn't mention that using
"ldap:/// ldaps:///" causes it to talk ldap and tls on 389. Does it
then also talk on port 636? What would be most useful is a short table
of client/server examples. What works, what doesn't and why. Heck, I'ld
even write it, if I knew more.
Starting config:
Mandrake 10.0 Official
nss_ldap-212-3mdk
pam_ldap-167-3mdk
libldap2-2.1.25-6mdk
perl-ldap-0.31-2mdk
openldap-clients-2.1.25-6mdk
openldap-2.1.25-6mdk
Clients are set to "ssl start_tls" in /etc/ldap.conf
slapd is started with SLAPDURLLIST set to "ldap:/// ldaps:///" in
/etc/sysconfig/ldap.
Encryption works fine according to testing I've done using ethereal and
clear text also works with the above settings. I'm still trying to get
the hang of ethereal though.
Given this starting point, I wanted to turn off clear text and ensure
that ldap would not talk to clients in anything other than a tls
encrypted means. It would be fine for the client on the server to use
clear text however, since that is fairly safe.
This is what is puzzleing me:
I made the following changes:
I set SLAPDURLLIST="ldap://127.0.0.1/ ldaps:///"
Given this setting I would assume that ldap would be turned off on
remote clients and tls would still work. Now my ldap user which I am
using for test is called "njim"
Before the change, I got:
[root@kaliklak root]# getent passwd njim
njim:x:1000:100:System User:/mnt/home/njim:/bin/bash
[root@kaliklak root]#
After the change, I restarted the server:
[root@enigma sysconfig]# service ldap restart
Stopping slapd: [ OK ]
Starting slapd (ldap + ldaps): [ OK ]
[root@enigma sysconfig]#
...and then made sure nscd wasn't running for the first test:
[root@kaliklak root]# service nscd stop;ssh enigma service nscd stop
Stopping nscd: [FAILED]
Stopping nscd: [FAILED]
[root@kaliklak root]#
Note: enigma is the server, kaliklak is the client. Also the failure
mentioned above is because nscd wasn't running in the first place.
Then I restarted the server...
[root@enigma sysconfig]# service ldap restart
Stopping slapd: [ OK ]
Starting slapd (ldap + ldaps): [ OK ]
...and on the client I got:
[root@kaliklak root]# getent passwd njim
[root@kaliklak root]#
i.e. nada. Hmmm... is it an nscd issue? Lets find out:
I'll reset the url list to "ldap:/// ldaps:///", restart the server and
set ssl = off on the client. With nscd still not running, if I get
errors or no response, then nscd should be one of the potential problems:
Having done that I should be not be able to see ldap users on the client
now, if there is a problem with nscd:
[root@kaliklak etc]# getent passwd njim
njim:x:1000:100:System User:/mnt/home/njim:/bin/bash
OK, so nscd is probably not at issue. I can probably ignore it in future
tests but I would want it running when not testing just for speed and
because kde may still like it.
...anyway I've tried a whole host of combinations to try and get
SLAPDURLLIST="ldap://127.0.0.1/ ldaps:///" to work with my clients but
no dice.
Client side settings I've tried:
host ldap.j9starr.net
ssl start_tls
host ldap.j9starr.net:389
ssl start_tls
host ldap.j9starr.net:636
ssl start_tls
uri ldaps://ldap.j9starr.net/
ssl start_tls
uri ldaps://ldap.j9starr.net:389/
ssl start_tls
uri ldaps://ldap.j9starr.net:636/
ssl start_tls
...round about here I reached the point of maximal frustration and tried
something different. Namely searches from the server:
[root@enigma sysconfig]# ldapsearch -LL -H ldap://localhost
- -b"dc=j9starr,dc=net" -x "(cn=njim)"
version: 1
dn: uid=njim,ou=People,dc=j9starr,dc=net
objectClass: top
objectClass: inetOrgPerson
objectClass: posixAccount
cn: njim
sn: njim
uid: njim
uidNumber: 1000
gidNumber: 100
homeDirectory: /mnt/home/njim
loginShell: /bin/bash
gecos: System User
description: System User
[root@enigma sysconfig]# ldapsearch -LL -Z -H ldap://localhost
- -b"dc=j9starr,dc=net" -x "(cn=njim)"
ldap_start_tls: Connect error (91)
~~ additional info: error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
ldap_bind: Can't contact LDAP server (81)
~~ additional info: error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
[root@enigma sysconfig]# ldapsearch -LL -Z -H ldaps://localhost
- -b"dc=j9starr,dc=net" -x "(cn=njim)"
ldap_start_tls: Can't contact LDAP server (81)
~~ additional info: error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
ldap_bind: Can't contact LDAP server (81)
~~ additional info: error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
[root@enigma sysconfig]# ldapsearch -LL -Z -H ldaps://localhost:389
- -b"dc=j9starr,dc=net" -x "(cn=njim)"
ldap_start_tls: Can't contact LDAP server (81)
ldap_bind: Can't contact LDAP server (81)
[root@enigma sysconfig]# ldapsearch -LL -Z -H ldaps://localhost:636
- -b"dc=j9starr,dc=net" -x "(cn=njim)"
ldap_start_tls: Can't contact LDAP server (81)
~~ additional info: error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
ldap_bind: Can't contact LDAP server (81)
~~ additional info: error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
[root@enigma sysconfig]# ldapsearch -LL -H ldap://localhost
- -b"dc=j9starr,dc=net" -x "(cn=njim)"
version: 1
dn: uid=njim,ou=People,dc=j9starr,dc=net
objectClass: top
objectClass: inetOrgPerson
objectClass: posixAccount
cn: njim
sn: njim
uid: njim
uidNumber: 1000
gidNumber: 100
homeDirectory: /mnt/home/njim
loginShell: /bin/bash
gecos: System User
description: System User
[root@enigma sysconfig]# ldapsearch -LL -Z -H ldap://localhost
- -b"dc=j9starr,dc=net" -x "(cn=njim)"
ldap_start_tls: Connect error (91)
~~ additional info: error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
ldap_bind: Can't contact LDAP server (81)
~~ additional info: error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Hmmm... are the ports open?
[root@kaliklak etc]# nmap -sT 192.168.2.101
Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-06-15 12:59 PDT
Interesting ports on enimga.j9starr.net (192.168.2.101):
(The 1647 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
22/tcp open ssh
53/tcp open domain
111/tcp open rpcbind
139/tcp open netbios-ssn
445/tcp open microsoft-ds
636/tcp open ldapssl
735/tcp open unknown
901/tcp open samba-swat
1002/tcp open windows-icfw
2049/tcp open nfs
3128/tcp open squid-http
32771/tcp open sometimes-rpc5
Nmap run completed -- 1 IP address (1 host up) scanned in 0.432 seconds
[root@kaliklak etc]# ssh enigma nmap -sT localhost
Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-06-15 13:00 PDT
Interesting ports on localhost (127.0.0.1):
(The 1645 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
22/tcp open ssh
53/tcp open domain
111/tcp open rpcbind
139/tcp open netbios-ssn
389/tcp open ldap
445/tcp open microsoft-ds
636/tcp open ldapssl
735/tcp open unknown
901/tcp open samba-swat
953/tcp open rndc
1002/tcp open windows-icfw
2049/tcp open nfs
3128/tcp open squid-http
32771/tcp open sometimes-rpc5
Nmap run completed -- 1 IP address (1 host up) scanned in 0.465 seconds
[root@kaliklak etc]#
[root@kaliklak etc]# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
[root@kaliklak etc]#
[root@kaliklak etc]# ssh enigma iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
[root@kaliklak etc]#
So no firewall issues.
Grr!!!
Clue? Anyone?
Jim C.
- --
- -----------------------------------------------------------------
| I can be reached on the following Instant Messenger services: |
|---------------------------------------------------------------|
| MSN: j_c_llings@hotmail.com AIM: WyteLi0n ICQ: 123291844 |
|---------------------------------------------------------------|
| Y!: j_c_llings Jabber: jcllings@njs.netlab.cz |
- -----------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFAz4k157L0B7uXm9oRApXrAJsHJy3tcOW4UmaxYrz2KzLFUjvSZwCeOlpv
wv66xwgJmBjPdSf7Zwm4bYI=
=N9iQ
-----END PGP SIGNATURE-----