I would have to agree with Al here... Just have the perl script making the changes to OpenLDAP make the changes directly to AD as well. You don't need additional Sync software if this is all one way and all of your changes are being forced through one interface that you can already manipulate as needed. The sync software would be, IMO, additional unneeded overhead.
 
I would also agree with Jackson's post if you can do it. I understand the politics and such argument though. Politics is cause for many bad decisions. Also though if you have a ton of APP data, I am not necessarily of the opinion that that should be in AD anyway. I am all for the idea of AD as the NOS directory and App data going elsewhere. Maybe say an AD/AM and then just work out some method to link an AD ID to an AD/AM entry WITHOUT syncing all of the damn AD Data into AD/AM. Say you have an attribute in AD that says, also see this AD/AM. Then in AD/AM there is an attribute say a bindable GUID or something that says this entry is linked to this AD Entry, go there to find the rest of the info. Obviously there would be some limitations in searching though if the data you needed to compare was partially in AD and partially in AD/AM, at that point you don't have a choice but to use one or the other or sync the data from one to the other. Just the same, using AD/AM, you still get to use AD for auth which is nice not having multiple auth stores.... That way when your tool that changes the passwords in both places breaks on one or the other, it isn't a big deal.
 
 joe


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mulnick, Al
Sent: Wednesday, November 10, 2004 4:05 PM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] AD Sync with OpenLDAP

So if it's just account data that you're interested in, any particular reason you want to change it? Are there problems?
 
 
One idea that does come to mind is that you could have a perl script that controls all of it without LDIFDE in the middle. If you wanted to. 
 
The advantage of something like MIIS or another commercial product is the control and logic already built in without you having to work in all the crazy logic to make it more robust.  You could however just use perl if that's what you're comfortable with since you're not really doing anything too more than reading user-objects from the OL directory and duplicating them in AD.  It's more or less a mapping function and a function to make sure that you get new accounts either as they are introduced else on commit.
 
Am I missing anything?


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Brown
Sent: Wednesday, November 10, 2004 3:56 PM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] AD Sync with OpenLDAP

Currently I have one way sync coming from my OpenLDAP server to my AD Domain.  The modifications that happen to the OpenLDAP server are done daily with Perl Scripts… which then create ldife files for AD whenever changes are made to the account.

 

A batch file is then used to grab the ldife files and import them into AD using LDIFDE.

 

All passwords are handled separately through a web page I have programmed (php/asp) that sets both OpenLDAP password and the AD password whenever a user changes their password.

 

Thanks,

--

Matt Brown

Information Technology System Specialist

Eastern Washington University

 

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mulnick, Al
Sent:
Wednesday, November 10, 2004 12:21 PM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] AD Sync with OpenLDAP

 

MIIS or simplesynch come to mind.  What level of sync do you have? For example, are synching passwords, groups, id's etc?

What kind of process do you have now?

 

 

 


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Brown
Sent:
Wednesday, November 10, 2004 3:05 PM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] AD Sync with OpenLDAP

Well,

 

I have an OpenLDAP server running with all user accounts (approx 14k accounts) in it.  I’d like to keep a replica of all the accounts in Active Directory, making appropriate changes when necessary.  (IE: account renames, ou changes, etc.)

 

I currently have something in place to do this, but it’s a cumbersome process and I’m curious what others are doing and how they are getting the job done.

 

Thanks,

--

Matt Brown

Information Technology System Specialist

Eastern Washington University

Reply via email to