We have a mostly 5.x centos environment and we are trying to move to 6.x. The stopping point at this time is setting up 6.3 as an ldap client. I'm at my wits end a bit and don't know where to go from here. I used authconfig to set it up in the same manner as I always have with our 5.x machines. My /etc/openldap/ldap.conf file looks like this:

URI ldap://xxx.xxx.xxx.xxx/
BASE dc=our,dc=base,dc=dc
TLS_CACERTDIR /etc/openldap/cacerts
TLS_REQCERT allow

(with hostname and real base replaced with bogus here)

The /etc/ldap.conf file was not there, but reading through Chapter 10 authentication configuration stuff in red hat's docs I found it had been replaced by /etc/pam_ldap.conf and it looks like this:

base dc=our,dc=base,dc=dc
uri ldap://xxx.xxx.xxx.xxx/
ssl start_tls
tls_cacertdir /etc/openldap/cacerts
pam_password md5

If I try to su - username on the 6.3 client, in the client /var/log/messages it reports:

Oct 19 09:38:41 servername nslcd[1780]: [5558ec] ldap_start_tls_s() failed: Connect error (uri="ldap://xxx.xxx.xxx.xxx/")
Oct 19 09:38:41 chaos nslcd[1780]: [5558ec] failed to bind to LDAP server ldap://xxx.xxx.xxx.xxx/: Connect error
Oct 19 09:38:41 chaos nslcd[1780]: [5558ec] no available LDAP server found

And on our open ldap server it reports:


Oct 19 09:41:06 server slapd[4031]: conn=1861 fd=50 ACCEPT from IP=xxx.xxx.xxx.xxx:50072 (IP=0.0.0.0:389)
Oct 19 09:41:06 server slapd[4031]: conn=1861 op=0 STARTTLS
Oct 19 09:41:06 server slapd[4031]: conn=1861 op=0 RESULT oid= err=0 text=
Oct 19 09:41:06 server slapd[4031]: conn=1861 fd=50 closed (TLS negotiation failure)

I have diffed the files on the 5.x and 6.x machines and they are identical.

If I do a basic ldap search using ldapsearch -x -b "dc=our,dc=base,dc=dc" it returns everything as expected. The logs on the ldap server report:


Oct 19 09:46:50 server slapd[4031]: conn=1871 fd=50 ACCEPT from IP=xxx.xxx.xxx.xxx:50076 (IP=0.0.0.0:389)
Oct 19 09:46:50 server slapd[4031]: conn=1871 op=0 BIND dn="" method=128
Oct 19 09:46:50 server slapd[4031]: conn=1871 op=0 RESULT tag=97 err=0 text=
Oct 19 09:46:50 server slapd[4031]: conn=1871 op=1 SRCH base="dc=our,dc=base,dc=dc" scope=2 deref=0 filter="(objectClass=*)"
Oct 19 09:46:53 server slapd[4031]: conn=1871 op=1 SEARCH RESULT tag=101 err=0 nentries=9805 text=
Oct 19 09:46:54 server slapd[4031]: conn=1871 op=2 UNBIND
Oct 19 09:46:54 server slapd[4031]: conn=1871 fd=50 closed

Additionally I can bind as a particular username and password and it returns results. For some reason it cannot start a tls session and I've exhausted googling and reading redhat docs trying to find out why. Any help would be greatly appreciated.

Usually LDAPS runs on port 636

From the looks of your logs you're trying to communicate through port 389. You may want to configure your ldap.conf file to "talk" on the right port. Also, make sure port 636 is open on both client and server side.

HTH

-C

With TLS start, the clients connect on 389 initially, and then start at TLS session to 636..this is how it is suppose to work and does so fine on all clients so far but 6.x. The port is indeed open to both.

Did you use the "system-config-authentication" or "authconfig" commands? Or did you edit the files manually?

I ask because I've done it "by hand" before and I've always missed something.

-C

I used authconfig. I do notice with authconfig there are more options available than with 5.x and some things checked by default (that I left) in 5.x are not checked by default in 6.x. I did check them to make them identical, though I'm wondering if that is part of the issue. The only thing I added manually is the same as with 5.x, in /etc/openldap/ldap.conf, adding the line TLS_REQCERT allow.

Have you had a look in the /etc/sysconfig/authconfig file?

I know there were some changes I had to make (don't know them off the top of my head) going from 5.x to 6.x

--C

All of the common things are identical in the 2 files. The 6.x box does have 6 more lines than the 5.x. Here they are:

5.x authconfig
USEMKHOMEDIR=no
USEPAMACCESS=no
USESSSDAUTH=no
USESHADOW=yes
USEWINBIND=no
USEDB=no
USEHESIOD=no
FORCESMARTCARD=no
PASSWDALGORITHM=md5
USELDAPAUTH=yes
USELOCAUTHORIZE=yes
USECRACKLIB=yes
USEWINBINDAUTH=no
USESMARTCARD=no
USELDAP=yes
USENIS=no
USEKERBEROS=no
USESYSNETAUTH=no
USESMBAUTH=no
USESSSD=no
USEPASSWDQC=no

6.x authconfig
IPADOMAINJOINED=no
USEMKHOMEDIR=no
USEPAMACCESS=no
CACHECREDENTIALS=yes
USESSSDAUTH=no
USESHADOW=yes
USEWINBIND=no
USESSSD=no
PASSWDALGORITHM=md5
FORCELEGACY=no
USEFPRINTD=no
USEHESIOD=no
FORCESMARTCARD=no
USELDAPAUTH=yes
IPAV2NONTP=no
USELDAP=yes
USECRACKLIB=yes
USEIPAV2=no
USEWINBINDAUTH=no
USESMARTCARD=no
USELOCAUTHORIZE=yes
USENIS=no
USEKERBEROS=no
USESYSNETAUTH=no
USESMBAUTH=no
USEDB=no
USEPASSWDQC=no

Ah hah! I found something! I brought up another 6.3 box with X installed, and for some reason after running authconfig on it, instead of just start nscd, it also started some service called sssd (which is not running on the other box without X installed). It did not get me any further to success, but DID give me an error in the logs I was not getting on the other one. This seems to be the culprit, but I don't have a clue what to do about it.



Could not start TLS encryption. TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user.

Now, another oddity though. When I do the same ldap search command on this box with the ldaps://, I get results back where on the other I do not.

So is there anyway to tell the 6.x client to trust the cert it is being given?

Did it also start a service called?

Also just for S's and G's try this: edit the /etc/sysconfig/authconfig and change the FORCELEGACY line to read...

Then run

And just to be clear...You're not using Kerberos with LDAP are you?

--C

No.

Can you post the authconfig command you ran?

--C

I didn't run it at command line. I ran "setup" and then chose authentication.

---------- Post added 10-30-12 at 04:03 PM ----------

And on the 2nd box which had X installed, I ran authconfig-tui

From what I've read you need to supply the TLS file to import...

https://sites.google.com/site/guente...hsshapasswords

HTH

--C

Well, the example shows doing such with 5 and 6, but with 5 I know TLS_REQCERT allow works as my whole environment works this way. According to the man page this is still allowed in 6. But never the less, I did copy the cert over and point to it to no avail.