You could dive into the changes structure directly, but I would not
reccomentd it.
If it is just attribute names that need changing, why not write a filter
script which reads the ldif and outputs a modified ldif file for use
with Active Directory ?
Graham.
On Thu, Jun 28, 2001 at 05:27:00PM -0500, Christopher A Bongaarts wrote:
> The situation: we're populating MS Active Directory from a UNIX box
> using LDAPS. Our strategy is:
>
> (1) Read changes from an LDIF-formatted file using Net::LDAP::LDIF's
> read_cmd() method
> (2) Tweak the changes to make them work with Active Directory
> (3) Send the changes to AD using Net::LDAP::Entry's update() method
>
> (1) and (3) work beautifully. (2) has become the stumbling block,
> specifically for "modify" requests.
>
> Active Directory is particular about the format of the unicodePwd
> attribute. So I'm taking the value from the LDIF file and converting
> it to the format that AD wants, then using Net::LDAP::Entry::replace()
> to ditch the old value and plug in the new one. Unfortunately, this
> results in the internal "changes" array having *two* replace
> operations: the original replace operation read in from the LDIF file,
> and the new one I put in there. AD barfs on the first one as
> expected.
>
> What I really want to do is "change the changes", not add a new change
> to the list of changes. My temporary workaround will likely be to
> muck with the "changes" array directly. But I'm open to better
> solutions. I see there is an (undocumented?) "changes" method that
> returns the contents of the changes array. Perhaps if it returned a
> reference to the array I could muck with it without depending on the
> internal representation of the Entry object.
>
> %% Christopher A. Bongaarts %% ca...@tc... %%
> %% Internet Services %% http://umn.edu/~cab %%
> %% University of Minnesota %% +1 (612) 625-1809 %%
>
|
