Syncrepl question
by Ivan Ordonez
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
14 years, 5 months
Openldap force replication
by Govind c
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
14 years, 8 months
ldapsearch - Active Directory proxyaddresses:smtp
by Chris Henderson
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.
14 years, 9 months
Mistake in the doc ?
by Vincent Panel
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
14 years, 9 months
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
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
--
14 years, 9 months
Re: SSHD doesn't start
by Jordi Espasa Clofent
> 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
14 years, 9 months
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
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
--
14 years, 9 months
Re: Mistake in the doc ?
by Gavin Henry
----- "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.
14 years, 9 months
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
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
--
14 years, 9 months
Proxy to Active Directory
by Nazeeruddin Mohammad
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.
***************************************************************************
14 years, 9 months
