openldap-technical August 2008

openldap-technical@openldap.org

63 participants
81 discussions

Syncrepl question
by Ivan Ordonez 04 Dec '08

04 Dec '08

Hi all, We have a small size domain with about 500 users and computers. We are using Samba with Openldap integration to authenticate user login and file sharing. Our setup is consist of 3 servers running Gentoo Linux - 1PDC and 2BDCs. As for replication, we are still using "slurpd". Any changes or modification is done through the PDC which replicates the changes to BDC1, then from BDC1, it then goes down to BDC2 - it's like a chain. We want to start using "syncrepl" soon as a way to replicate our database but I'm not sure were to start. We want to setup all of our machine to sync with each other everyday, and not worry which machine is use to make changes, modification, etc.... I'm not sure which syncrepl function to use to achieve what we want to do. Is "N-Way Multi Master replication" the correct choice to do this? We are using "BDB" database on each servers, and would like to achieve this with minimal downtime if possible. What is the best way to do this? Please advise. Any help is greatly appreciated. -Ivan

3 12

Openldap force replication
by Govind c 10 Sep '08

10 Sep '08

Hi, Is there a way to force the replication between Master and the slave?. The number of objects and entries are the same in both master and slave,however the some fields don`t have the same content (eg : last login time)Wondering if there is way to keep both in sync in terms of content and objects/entries. Cheers CG

3 6

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical August 2008