openldap-technical

openldap-technical@openldap.org

7 participants
9901 discussions

RHEL 5 will not do TLS/SSL authentication
by Dat Duong 02 Sep '08

02 Sep '08

Hi, I can't find anywhere on how to fix my RHEL 5 to use TLS/SSL authentication. I will work when I comment out the ssl startTLS and SSL. On my Solaris 10, I can do ldapsearch with the -ZZ option Here is what I did with the debug on for ldapsearch. Please help me solve this problem...THANKS!! TLS trace: SSL_connect:SSLv3 read server certificate A TLS trace: SSL_connect:SSLv3 read server certificate request A TLS trace: SSL_connect:SSLv3 read server done A TLS trace: SSL_connect:SSLv3 write client certificate A TLS trace: SSL_connect:SSLv3 write client key exchange A TLS trace: SSL_connect:SSLv3 write change cipher spec A TLS trace: SSL_connect:SSLv3 write finished A TLS trace: SSL_connect:SSLv3 flush data TLS trace: SSL3 alert read:fatal:handshake failure TLS trace: SSL_connect:failed in SSLv3 read finished A TLS: can't connect. ldap_perror ldap_start_tls: Connect error (-11) additional info: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure

2 1

Fw: RHEL 5 will not do TLS/SSL authentication
by Dat Duong 01 Sep '08

01 Sep '08

1 0

ldapsearch - Active Directory proxyaddresses:smtp
by Chris Henderson 31 Aug '08

31 Aug '08

I am trying to filter proxyaddress:smtp email addresses querying Active Directory. I need to use this for sendmail address lookup. I tried the following queries but they give a lot of extraneous information I don't need. Any help would be much appreciated. Thanks. - ldapsearch -x -h 192.168.25.16 -p 3268 -b "DC=company,DC=com" "(&(proxyAddresses=SMTP:*))" - ldapsearch -x -h 192.168.25.16 -p 3268 -b "DC=company,DC=com" -P2 -s sub "objectclass=*" SMTP - ldapsearch -x -h 192.168.25.16 -p 3268 -b "DC=company,DC=com" -P2 -s sub "proxyAddresses=*" Normally the address comes in this exact format while querying Active Directory: "proxyAddresses: SMTP:firstname.lastname@company.com" Thanks.

4 3

Mistake in the doc ?
by Vincent Panel 30 Aug '08

30 Aug '08

Hi, Maybe I don't understand but, I'm looking at § 8.2.4.1 in this document : http://www.openldap.org/doc/admin22/schema.html The goal is to create an attributetype called "myUniqueName" which is unique. With the last definition of this attributetype : attributetype ( 1.1.2.1.1 NAME 'myUniqueName' DESC 'unique name with my organization' SUP name ) How can openldap guess that we cant a unique attributetype ? Isn't there a SINGLE-VALUE missing at the end of the description ? Thanks for your answers, Vincent

3 3

More info: TLSVerifyClient: Basic setup works, but SSHD and su fail (SLAPD 2.4.9 and OpenSSL 0.9.8g on Ubuntu 8.04 server)
by Hauke Coltzau 30 Aug '08

30 Aug '08

Hi again, when I make sudo /etc/init.d/ssh restart after reboot, the network users can login, even when the tls_cert and tls_key options in /etc/ldap.conf have been disabled. After rebooting the machine, the login fails and I have to login as local user to restart the sshd. <some user>@<some host>:~> ssh <network_user>@<client> <network_user>@<client>'s password: Permission denied, please try again. <network_user>@<client>'s password: <some user>@<some host>:~> ssh <local_user>@<client> <local_user>@<client>'s password: Last login: Sat Aug 30 10:25:56 2008 from <some host> <local_user>@<client>:~$ sudo /etc/init.d/ssh restart [sudo] password for <local user>: * Restarting OpenBSD Secure Shell server sshd [ OK ] <local_user>@<client>:~$ logout <some user>@<some host>:~> ssh <network_user>@<client> <network_user>@<client>'s password: Last login: Sat Aug 30 10:23:40 2008 from <some host> <network_user>@<client>:~$ I'm very confused now! Best regards, Hauke ----- Ursprüngliche Mail ----- Von: "Hauke Coltzau" <hauke.coltzau(a)FernUni-Hagen.de> An: "Buchan Milne" <bgmilne(a)staff.telkomsa.net> CC: openldap-technical(a)openldap.org Gesendet: Freitag, 29. August 2008 21:33:08 GMT +01:00 Amsterdam/Berlin/Bern/Rom/Stockholm/Wien Betreff: AW: Re: TLSVerifyClient: Basic setup works, but SSHD and su fail (SLAPD 2.4.9 and OpenSSL 0.9.8g on Ubuntu 8.04 server) Hi Buchan, summary first: the su - <network_user> problem is solved thanks to your question. ssh <network_user>@<client> works only under certain circumstances (see below). > > I want to use TLS-communication between my ldap server and > > the clients. > > [...] > > > Next, I activated TLSVerifyClient on the server side > > Why ? You don't need this to address your single remaining problem, > unless you haven't stated it in full. Sorry, I did not point out that I want only valid users/services to be able to get information from the ldap server at all. A valid service or user shall be identified by a certificate that is signed by a valid CA of mine. All other connection attempts shall be rejected. That is how I understood the combination of TLS_REQCRT (to verify the server) and TLSVerifyClient (to verify the client). Am I wrong here? > Since I use the ldap server for network user authentication, I can (as > local user) make a su - <network_user>, enter the password and get > authenticated, but have a look at the shell: > > <local user>@<client>:~$ su - <network_user> > Password: <network user password here> > id: cannot find name for group ID <network_user group> > I have no name!@<client>:~$ > > Does 'strace -e open id' tell you anything interesting (specifically about > the key/cert)? Wow, one single question of yours gave me several hours of work and the solution for my first problem. Thanks ;-) I ensured that the requested files are readable by the user (they already were, but I checked it again, even made a chmod -R 777 on the directory). This was not the problem. But after creating a new certificate for that network user with the CN set to the users username (instead of the surname/name before), the problem with su - <network_user> disappeared. Now I can su from a certified local user to my network user. <local user>@<client>:~$ su - <network user> Password: <network user>@<client>:~$ That's cool! > > In /etc/ldap.conf (ubuntu 8.04 uses this as replacement for > > lib(pam|nss)_ldap.conf), > > Actually, Ubuntu reverts back to the upstream location, lib(pam|nss)_ldap.conf > is a Debian-ism. Thanks for the info, did not know that. > > I set the values for > > > > tls_cert /usr/lib/ssl/certs/<client>.ldap.cert.pem > > tls_key /usr/lib/ssl/private/<client>.ldap.key.pem > > You didn't indicate any of the other /etc/ldap.conf settings, such as > tls_cacertfile, tls_check_peer. Additionally, you don't specify if you are > using nscd, or whether the logged in user (below) can read the tls_cert and > tls_key files. Since the verification of the server certificate works out fine, I only provided the client-verification specific values. Here are the missing values: base dc=... uri ldaps://<fqdn of my server>/ ldap_version 3 bind_policy soft pam_password md5 tls_check_peer yes tls_cacertfile /usr/lib/ssl/cacerts/<serverca>.chain.pem tls_cert /usr/lib/ssl/certs/<client>.ldap.cert.pem tls_key /usr/lib/ssl/private/<client>.ldap.key.pem nss_initgroups_ignoreusers backup,bin,daemon,dhcp,fetchmail,games,gnats,irc,klog,libuuid,list,lp,mail,man, \ messagebus,news,postfix,proxy,root,sshd,statd,sync,sys,syslog,uucp,www-data,zimbra The nss_initgroups_ignoreusers entry is automatically created when executing /etc/init.d/libnss-ldap restart or when booting the system. I disabled the nscd caches for passwd and group before starting to deal with TLS just to make sure that the ldap server is always contacted. ==== /etc/nscd.conf ==== ... enable-cache passwd no ... enable-cache group no ... == END /etc/nscd.conf == After tideous testing I found out something new: I wanted to strace the sshd, too and therefore stopped the running instance with /etc/init.d/ssh stop and started a new instance manually <local user>@<client> sudo -s root@<client># /usr/sbin/sshd -D Doing so, the login via SSH works sout perfectly. I assumed that this is because sshd would read the .ldaprc of <local user>, which has a valid cert/key entry (see above), so I straced the above command. But: root@<client>:/etc/init.d# strace -e open /usr/sbin/sshd -D 2>&1 open("/etc/ld.so.cache", O_RDONLY) = 3 open("/lib/libwrap.so.0", O_RDONLY) = 3 open("/lib/libpam.so.0", O_RDONLY) = 3 open("/lib/libdl.so.2", O_RDONLY) = 3 open("/lib/libselinux.so.1", O_RDONLY) = 3 open("/usr/lib/libck-connector.so.0", O_RDONLY) = 3 open("/usr/lib/libdbus-1.so.3", O_RDONLY) = 3 open("/usr/lib/libcrypto.so.0.9.8", O_RDONLY) = 3 open("/lib/libutil.so.1", O_RDONLY) = 3 open("/usr/lib/libz.so.1", O_RDONLY) = 3 open("/lib/libnsl.so.1", O_RDONLY) = 3 open("/lib/libcrypt.so.1", O_RDONLY) = 3 open("/lib/libresolv.so.2", O_RDONLY) = 3 open("/usr/lib/libgssapi_krb5.so.2", O_RDONLY) = 3 open("/usr/lib/libkrb5.so.3", O_RDONLY) = 3 open("/usr/lib/libk5crypto.so.3", O_RDONLY) = 3 open("/lib/libcom_err.so.2", O_RDONLY) = 3 open("/lib/libc.so.6", O_RDONLY) = 3 open("/usr/lib/libkrb5support.so.0", O_RDONLY) = 3 open("/lib/libkeyutils.so.1", O_RDONLY) = 3 open("/etc/selinux/config", O_RDONLY) = -1 ENOENT (No such file or directory) open("/proc/mounts", O_RDONLY) = 3 open("/dev/null", O_RDWR) = 3 open("/proc/14556/fd", O_RDONLY|O_NONBLOCK|O_DIRECTORY|0x80000) = 3 open("/etc/ssh/sshd_config", O_RDONLY) = 3 open("/dev/urandom", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 3 open("/etc/gai.conf", O_RDONLY) = 3 open("/etc/nsswitch.conf", O_RDONLY) = 3 open("/etc/ld.so.cache", O_RDONLY) = 3 open("/lib/libnss_files.so.2", O_RDONLY) = 3 open("/etc/passwd", O_RDONLY|0x80000 /* O_??? */) = 3 open("/etc/ssh/ssh_host_rsa_key", O_RDONLY) = 3 open("/etc/ssh/blacklist.RSA-2048", O_RDONLY) = 3 open("/etc/ssh/ssh_host_dsa_key", O_RDONLY) = 3 open("/etc/ssh/blacklist.DSA-1024", O_RDONLY) = 3 open("/etc/localtime", O_RDONLY) = 4 open("/var/run/sshd.pid", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4 Now if I do ssh <network_user>@<client> from any machine in the net, everything works out perfectly: <some id>@<some host>:~> ssh <network_user>@<client> <network_user>@<client>'s password: Last login: Fri Aug 29 21:23:06 2008 from <fqdn of some host> <network user>@<client>:~$ But not a single ldap or libnss/libpam config file is stat'ed or read by the above sshd at all. The only thing that can be seen is that after logging out, the above sshd command echos --- SIGCHLD (Child exited) @ 0 (0) --- and that's it. When I kill the above sshd and do /etc/init.d/ssh start again, the login still works out. But after restarting the sytem, the login fails as always. As far as I can see, /etc/init.d/ssh starts sshd as root, obviously not chrooted or something similar. Do you have any idea, what this is all about? Kind regards, Hauke --

1 0

Re: SSHD doesn't start
by Jordi Espasa Clofent 29 Aug '08

29 Aug '08

> This is more of a sys-admin question, but change when sshd starts up so > ldap comes up first. Ok Gavin, I'd thought that the present 'openldap-technical' mail-list was the correct place to ask this kind of questions. ¿Can you point to me what is the correct list? -- Thanks, Jordi Espasa Clofent

1 0

AW: Re: TLSVerifyClient: Basic setup works, but SSHD and su fail (SLAPD 2.4.9 and OpenSSL 0.9.8g on Ubuntu 8.04 server)
by Hauke Coltzau 29 Aug '08

29 Aug '08

Hi Buchan, summary first: the su - <network_user> problem is solved thanks to your question. ssh <network_user>@<client> works only under certain circumstances (see below). > > I want to use TLS-communication between my ldap server and > > the clients. > > [...] > > > Next, I activated TLSVerifyClient on the server side > > Why ? You don't need this to address your single remaining problem, > unless you haven't stated it in full. Sorry, I did not point out that I want only valid users/services to be able to get information from the ldap server at all. A valid service or user shall be identified by a certificate that is signed by a valid CA of mine. All other connection attempts shall be rejected. That is how I understood the combination of TLS_REQCRT (to verify the server) and TLSVerifyClient (to verify the client). Am I wrong here? > Since I use the ldap server for network user authentication, I can (as > local user) make a su - <network_user>, enter the password and get > authenticated, but have a look at the shell: > > <local user>@<client>:~$ su - <network_user> > Password: <network user password here> > id: cannot find name for group ID <network_user group> > I have no name!@<client>:~$ > > Does 'strace -e open id' tell you anything interesting (specifically about > the key/cert)? Wow, one single question of yours gave me several hours of work and the solution for my first problem. Thanks ;-) I ensured that the requested files are readable by the user (they already were, but I checked it again, even made a chmod -R 777 on the directory). This was not the problem. But after creating a new certificate for that network user with the CN set to the users username (instead of the surname/name before), the problem with su - <network_user> disappeared. Now I can su from a certified local user to my network user. <local user>@<client>:~$ su - <network user> Password: <network user>@<client>:~$ That's cool! > > In /etc/ldap.conf (ubuntu 8.04 uses this as replacement for > > lib(pam|nss)_ldap.conf), > > Actually, Ubuntu reverts back to the upstream location, lib(pam|nss)_ldap.conf > is a Debian-ism. Thanks for the info, did not know that. > > I set the values for > > > > tls_cert /usr/lib/ssl/certs/<client>.ldap.cert.pem > > tls_key /usr/lib/ssl/private/<client>.ldap.key.pem > > You didn't indicate any of the other /etc/ldap.conf settings, such as > tls_cacertfile, tls_check_peer. Additionally, you don't specify if you are > using nscd, or whether the logged in user (below) can read the tls_cert and > tls_key files. Since the verification of the server certificate works out fine, I only provided the client-verification specific values. Here are the missing values: base dc=... uri ldaps://<fqdn of my server>/ ldap_version 3 bind_policy soft pam_password md5 tls_check_peer yes tls_cacertfile /usr/lib/ssl/cacerts/<serverca>.chain.pem tls_cert /usr/lib/ssl/certs/<client>.ldap.cert.pem tls_key /usr/lib/ssl/private/<client>.ldap.key.pem nss_initgroups_ignoreusers backup,bin,daemon,dhcp,fetchmail,games,gnats,irc,klog,libuuid,list,lp,mail,man, \ messagebus,news,postfix,proxy,root,sshd,statd,sync,sys,syslog,uucp,www-data,zimbra The nss_initgroups_ignoreusers entry is automatically created when executing /etc/init.d/libnss-ldap restart or when booting the system. I disabled the nscd caches for passwd and group before starting to deal with TLS just to make sure that the ldap server is always contacted. ==== /etc/nscd.conf ==== ... enable-cache passwd no ... enable-cache group no ... == END /etc/nscd.conf == After tideous testing I found out something new: I wanted to strace the sshd, too and therefore stopped the running instance with /etc/init.d/ssh stop and started a new instance manually <local user>@<client> sudo -s root@<client># /usr/sbin/sshd -D Doing so, the login via SSH works sout perfectly. I assumed that this is because sshd would read the .ldaprc of <local user>, which has a valid cert/key entry (see above), so I straced the above command. But: root@<client>:/etc/init.d# strace -e open /usr/sbin/sshd -D 2>&1 open("/etc/ld.so.cache", O_RDONLY) = 3 open("/lib/libwrap.so.0", O_RDONLY) = 3 open("/lib/libpam.so.0", O_RDONLY) = 3 open("/lib/libdl.so.2", O_RDONLY) = 3 open("/lib/libselinux.so.1", O_RDONLY) = 3 open("/usr/lib/libck-connector.so.0", O_RDONLY) = 3 open("/usr/lib/libdbus-1.so.3", O_RDONLY) = 3 open("/usr/lib/libcrypto.so.0.9.8", O_RDONLY) = 3 open("/lib/libutil.so.1", O_RDONLY) = 3 open("/usr/lib/libz.so.1", O_RDONLY) = 3 open("/lib/libnsl.so.1", O_RDONLY) = 3 open("/lib/libcrypt.so.1", O_RDONLY) = 3 open("/lib/libresolv.so.2", O_RDONLY) = 3 open("/usr/lib/libgssapi_krb5.so.2", O_RDONLY) = 3 open("/usr/lib/libkrb5.so.3", O_RDONLY) = 3 open("/usr/lib/libk5crypto.so.3", O_RDONLY) = 3 open("/lib/libcom_err.so.2", O_RDONLY) = 3 open("/lib/libc.so.6", O_RDONLY) = 3 open("/usr/lib/libkrb5support.so.0", O_RDONLY) = 3 open("/lib/libkeyutils.so.1", O_RDONLY) = 3 open("/etc/selinux/config", O_RDONLY) = -1 ENOENT (No such file or directory) open("/proc/mounts", O_RDONLY) = 3 open("/dev/null", O_RDWR) = 3 open("/proc/14556/fd", O_RDONLY|O_NONBLOCK|O_DIRECTORY|0x80000) = 3 open("/etc/ssh/sshd_config", O_RDONLY) = 3 open("/dev/urandom", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 3 open("/etc/gai.conf", O_RDONLY) = 3 open("/etc/nsswitch.conf", O_RDONLY) = 3 open("/etc/ld.so.cache", O_RDONLY) = 3 open("/lib/libnss_files.so.2", O_RDONLY) = 3 open("/etc/passwd", O_RDONLY|0x80000 /* O_??? */) = 3 open("/etc/ssh/ssh_host_rsa_key", O_RDONLY) = 3 open("/etc/ssh/blacklist.RSA-2048", O_RDONLY) = 3 open("/etc/ssh/ssh_host_dsa_key", O_RDONLY) = 3 open("/etc/ssh/blacklist.DSA-1024", O_RDONLY) = 3 open("/etc/localtime", O_RDONLY) = 4 open("/var/run/sshd.pid", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4 Now if I do ssh <network_user>@<client> from any machine in the net, everything works out perfectly: <some id>@<some host>:~> ssh <network_user>@<client> <network_user>@<client>'s password: Last login: Fri Aug 29 21:23:06 2008 from <fqdn of some host> <network user>@<client>:~$ But not a single ldap or libnss/libpam config file is stat'ed or read by the above sshd at all. The only thing that can be seen is that after logging out, the above sshd command echos --- SIGCHLD (Child exited) @ 0 (0) --- and that's it. When I kill the above sshd and do /etc/init.d/ssh start again, the login still works out. But after restarting the sytem, the login fails as always. As far as I can see, /etc/init.d/ssh starts sshd as root, obviously not chrooted or something similar. Do you have any idea, what this is all about? Kind regards, Hauke --

1 0

Re: Mistake in the doc ?
by Gavin Henry 29 Aug '08

29 Aug '08

----- "Vincent Panel" <yohonet(a)gmail.com> wrote: > Hi, > > Maybe I don't understand but, I'm looking at § 8.2.4.1 in this > document : http://www.openldap.org/doc/admin22/schema.html > > The goal is to create an attributetype called "myUniqueName" which is > unique. With the last definition of this attributetype : > > attributetype ( 1.1.2.1.1 NAME 'myUniqueName' > DESC 'unique name with my organization' > SUP name ) > > How can openldap guess that we cant a unique attributetype ? > > Isn't there a SINGLE-VALUE missing at the end of the description ? It's just talking about the name of the attribute, not the attribute value. SINGLE-VALUE means attributes of this type are restricted to a single value, nothing about uniqueness. Please have a read of doc/rfc/rfc4512.txt at your leisure. -- Kind Regards, Gavin Henry. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie, Aberdeenshire, AB51 4FP.

1 0

TLSVerifyClient: Basic setup works, but SSHD and su fail (SLAPD 2.4.9 and OpenSSL 0.9.8g on Ubuntu 8.04 server)
by Hauke Coltzau 29 Aug '08

29 Aug '08

Hi everybody, hope, this is still the right group for my question, might also be a lib{pam|nss}_ldap problem. I am very happy to say that I have an almost completely running installation now. But one single problem still remains: I want to use TLS-communication between my ldap server and the clients. I started up with an own RootCA, created 2 SubCAs (one for server certs, one for user certs) and generated a certificate for my server, signed by the ServerCA. On client side, I have set ==== /etc/ldap/ldap.conf ==== BASE dc=... URI ldaps://<fqdn>/ # Require valid cert from server TLS_REQCERT yes # CA for trusted server certs TLS_CACERT /usr/lib/ssl/cacerts/<serverca>.chain.pem == END /etc/ldap/ldap.conf == This works out perfectly, as I can see using a paket sniffer. The client only communicates with the server using TLSv1 and only if the server's certificate is valid. Next, I activated TLSVerifyClient on the server side ==== /etc/ldap/slapd.conf ==== ... # The CA chain for valid client certs TLSCACertificateFile /usr/lib/ssl/cacerts/<userca>.chain.pem # The server's cert TLSCertificateFile /usr/lib/ssl/certs/<server>.cert.pem # The server's key TLSCertificateKeyFile /usr/lib/ssl/private/<server>.key.pem # Verify clients always TLSVerifyClient demand == END /etc/ldap/slapd.conf == and created a client cert without password for my local client user, signed by the UserCA. This cert and the according key are referenced in the (local) users .ldaprc on the client machine: ==== /home/<user>/.ldaprc ==== TLS_CERT /home/<user>/openldap/<user>.ldap.cert.pem TLS_KEY /home/<user>/openldap/<user>.ldap.key.pem == END /home/<user>/.ldaprc == So, when I start ldapsearch -x as local user, I get a positive result as long as the above mentioned certificate is valid. If the user's certificate is not valid, ldapsearch fails. Wonderful, that's exactly what I wanted. But now to my problem: Since I use the ldap server for network user authentication, I can (as local user) make a su - <network_user>, enter the password and get authenticated, but have a look at the shell: <local user>@<client>:~$ su - <network_user> Password: <network user password here> id: cannot find name for group ID <network_user group> I have no name!@<client>:~$ Without TLSVerifyClient, this works out fine: <local user>@<client>:~$ su - <network_user> Password: <network user password here> <network_user>@<client>:~$ Secondly: How do I make it possible that when connecting via ssh to the client machine (from any other machine), I can login as <network_user>? Here are the details: In /etc/ldap.conf (ubuntu 8.04 uses this as replacement for lib(pam|nss)_ldap.conf), I set the values for tls_cert /usr/lib/ssl/certs/<client>.ldap.cert.pem tls_key /usr/lib/ssl/private/<client>.ldap.key.pem The certificate has been signed by the same CA as the above user certificate. The CN is the name of the host (not fqdn, that is, just the hostname). But when I try to login via ssh, quits the connection saying slapd -d127 -h "ldaps:///" -u openldap -g openldap ... TLS: can't accept: The peer did not send any certificate.. connection_read(12): TLS accept failure error=-1 id=0, closing ... Whithout TLSVerifyClient, I can login. I assume that both problems have the same background, but I just don't get it. Hope, this time I didn't miss reading a manual again ;-) Best regards, Hauke --

2 1

Proxy to Active Directory
by Nazeeruddin Mohammad 29 Aug '08

29 Aug '08

Hi Everyone, Like many organizations, we have two authentication systems here. I am trying to figure out a way of synchronizing LDAP passwords with AD passwords; or proxying the requests to AD. Management wants to keep LDAP intact, while enjoying the flexibility of single password. I have unsuccessfully tried to use proxy functionally of LDAP to get user information from AD. First of all, AD needs a user name and password to retrieve information. Is there a way of specifying username/password? Even the following ldapsearch FAILS on openldap server, but the same query works fine for AD server. ldapsearch -LLL -x -h localhost -b 'cn=users,dc=internal,dc=phg,dc=com,dc=au' -D "ldapauth(a)internal.phg.com.au" -W -x ldapsearch -LLL -x -h localhost -b 'dc=internal,dc=phg,dc=com,dc=au' -D "CN=Ldap Authentication,OU=Linux,OU=InformationTechnology,OU=Portland House,OU=Sites,DC=internal,DC=phg,DC=com,DC=au" -W -x Here is the relevant sladp.conf snippet. database ldap suffix "cn=users,dc=internal,dc=phg,dc=com,dc=au" subordinate rebind-as-user uri "ldap://192.168.100.100/" chase-referrals yes Any help is appreciated. Thank you very much. Cheers Nazeer *************************************************************************** CAUTION: This email message and accompanying data may contain information that is confidential and/or subject to legal privilege. If you are not the intended recipient, you are notified that any use, dissemination, distribution or copying of this message or data is prohibited. If you have received this email message in error, please notify us immediately and erase all copies of this message and attachments. Thank you. ***************************************************************************

5 6

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical