[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
> 9.0.  I'm trying to use the OpenLDAP database to make a portion of
> Directory (just usernames, universal group memberships and email
> available to a segment of the DMZ that can't be allowed access to the
> Active Directory infrastructure.  To do this, the AD folks are going
> provide me a daily LDIF (via a batch process) of all the user objects
> just the attributes I need values for.  For security reasons, we can't
> 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
> 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
> hopeless. 

Couldn't you just setup openldap to proxy to the AD server?  You just
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
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