[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Problem importing LDIF file
As to using OpenLDAP as a proxy....that's what I originally wanted to
do, but that didn't fly with our security people. You'd think they were
defending launch codes here or something (I work at Department of
Labor). In any case, now that I know how to stop the ldap server so I
can wipe the database prior to importing the day's LDIF file, I should
be good to go (thanx again Ralph).
One question though.....would it be possible to use OpenLDAP to
proxy an AD Global Catalog? We have multiple domains in our domain
tree, and I would have had to setup OpenLDAP to proxy all of them. I
wasn't able to figure out if OpenLDAP would be able to do that or not.
Just curious.....
-----Original Message-----
From: Dusty Doris [ mailto:openldap@mail.doris.cc
<mailto:openldap@mail.doris.cc> ]
Sent: Tuesday, June 14, 2005 9:54 AM
To: Boxall, Colin - OASAM CTR
Cc: 'openldap-software@OpenLDAP.org'
Subject: Re: Problem importing LDIF file
>
> Intro and background: I'm running OpenLDAP 2.26 on a Suse Enterprise
Server
> 9.0. I'm trying to use the OpenLDAP database to make a portion of
Active
> Directory (just usernames, universal group memberships and email
addresses)
> available to a segment of the DMZ that can't be allowed access to the
entire
> Active Directory infrastructure. To do this, the AD folks are going
to
> provide me a daily LDIF (via a batch process) of all the user objects
with
> just the attributes I need values for. For security reasons, we can't
use
> more typical replication techniques. I need to then use a batch
process to
> import those LDIF files into the OpenLDAP database. I have run into a
> variety of problems linked to the facts that a) I've never used
OpenLDAP
> before, and b) I've never used Linux before. I've managed to get Suse
> installed and OpenLDAP running, so I don't think the situation is
completely
> hopeless.
>
>
Couldn't you just setup openldap to proxy to the AD server? You just
need
the AD people to create a user for you that has read access to the user
part of the AD tree.
Something similar to this might work for you.
database meta
suffix "dc=yourdomain,dc=com"
dncache-ttl forever
uri "ldap://adserver:389/ou=system
users,dc=yourdomain,dc=com"
binddn "cn=ldapreaduser,ou=system users,dc=yourdomain,dc=com"
bindpw "passwd"
pseudorootdn "cn=ldapreaduser,ou=system users,dc=yourdomain,dc=com"
pseudorootpw "passwd"
map attribute mail userPrincipalName
map attribute name displayname
map attribute member memberOf
access to *
by dn.children="ou=system users,dc=yourdomain,dc=com" read