Missing creatorsName/createTimeStamp after migrate from Sun One dir to ds389
by Sam Wen
Hi There,
1. Not sure is there anyone having the same experience. We export the ldap data from Sun One directory to ldif file and import through the DS389 console. There is no error report and all records imported.
But later we found out the creatorsName and createTimeStamp have not been imported. Do you guys know why?
2. Can't modify those 2 attributes easily. But there is some special keywords for these 2 attributes. "NO-USER-MODIFICATION, USAGE directoryOperation"
Can I just remove those keywords and do the ldapmodify to those 2 attributes manually? I have tried but there will be some strange error reports.
Best Regards
Sam Wen
System Administrator
Faculty of Engineering and IT
University of Technology, Sydney
PH: 9514 2374
Em: sam.wen(a)uts.edu.au<mailto:sam.wen@uts.edu.au>
UTS CRICOS Provider Code: 00099F
DISCLAIMER: This email message and any accompanying attachments may contain confidential information.
If you are not the intended recipient, do not read, use, disseminate, distribute or copy this message or
attachments. If you have received this message in error, please notify the sender immediately and delete
this message. Any views expressed in this message are those of the individual sender, except where the
sender expressly, and with authority, states them to be the views of the University of Technology Sydney.
Before opening any attachments, please check them for viruses and defects.
Think. Green. Do.
Please consider the environment before printing this email.
12 years
Repair replication
by Herb Burnswell
On Tue, Apr 3, 2012 at 2:59 PM,
<389-users-request(a)lists.fedoraproject.org>wrote:
> Send 389-users mailing list submissions to
> 389-users(a)lists.fedoraproject.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://admin.fedoraproject.org/mailman/listinfo/389-users
> or, via email, send a message with subject or body 'help' to
> 389-users-request(a)lists.fedoraproject.org
>
> You can reach the person managing the list at
> 389-users-owner(a)lists.fedoraproject.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of 389-users digest..."
>
>
> Today's Topics:
>
> 1. Repair replication (Herb Burnswell)
> 2. Re: Repair replication (Jim Finn)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 3 Apr 2012 14:55:37 -0700
> From: Herb Burnswell <herbert.burnswell(a)gmail.com>
> To: 389-users(a)lists.fedoraproject.org
> Subject: [389-users] Repair replication
> Message-ID:
> <CAOuzmw4659u30rHUn+D9r2zbh9dFFPyKYmc+5A2LxOfDEEdD8g(a)mail.gmail.com
> >
> Content-Type: text/plain; charset="iso-8859-1"
>
> ---------- Forwarded message ----------
> From: Rich Megginson <rmeggins(a)redhat.com>
> Date: Mon, Apr 2, 2012 at 7:37 PM
> Subject: Re: [389-users] Fwd: Repair replication
> To: "General discussion list for the 389 Directory server project." <
> 389-users(a)lists.fedoraproject.org>
> Cc: Herb Burnswell <herbert.burnswell(a)gmail.com>
>
>
> On 04/02/2012 05:48 PM, Herb Burnswell wrote:
>
>
>
> ---------- Forwarded message ----------
> From: Rich Megginson <rmeggins(a)redhat.com>
> Date: Mon, Apr 2, 2012 at 3:23 PM
> Subject: Re: [389-users] Repair replication
> To: "General discussion list for the 389 Directory server project." <
> 389-users(a)lists.fedoraproject.org>
> Cc: Herb Burnswell <herbert.burnswell(a)gmail.com>
>
>
> On 04/02/2012 04:13 PM, Herb Burnswell wrote:
>
>
>
> On Fri, Mar 23, 2012 at 10:53 AM, Rich Megginson <rmeggins(a)redhat.com
> >wrote:
>
> > On 03/23/2012 11:09 AM, Herb Burnswell wrote:
> >
> > Thanks for the reply David.
> >
> > >> 1. How can I find out which system(s) is/are master, consumer, hub,
> etc?
> > >>>>You should be able to determine the role of the Directory Server for
> > each
> > >>>>system by logging into the LDAP console under
> > >>>>"Configuration->Replication". The role is either "Single Master",
> > "Hub" or
> > >>>>"Dedicated Consumer".
> >
> > >I was able to determine that we have two "Multiple Master" systems.
> > Let's call >them 'A' and 'B'. System A has been the only system running
> > for what appears to >be several years (it is being backed up nightly).
> > System B has been off for some >time but is running now.
> >
> > >> 2. How do I confirm that the systems have the correct credentials for
> > >replication? (I am receiving: "Unable to acquire replica: Permission
> > >denied.")
> > >a. How can I change the bind dn "cn=replication,cn=config"
> credentials
> > >on each system to ensure replication will work?
> > >>>>You can do that on the console as well. Just navigate down the
> > directory
> > >>>>tree and manually reset the password for the replication user
> account.
> > >>>>There's a possibility that your replication user account's password
> > expired.
> >
> > >I can navigate to the screen to reset the password for the replication
> > user account. I >have not reset the passwords yet as I am reading
> > documentation to confirm that >system B will simply update it's data to
> > system A's upon resuming replication.
> >
> > >When you change the password of the replication user on B, you'll also
> > have to update >those credentials in the replication agreement on A for
> the
> > agreement from A to B.
> >
> > >Note that if replication has been down for years, you will have to
> > perform a manual >replica initialization procedure - replication will not
> > automatically "catch up" if it has >been down that long.
> >
> > Rich - Thank you for the response. I was diverted to another urgent
> issue but have come back to this replication fix.
>
> I've confirmed that there are two Dedicated Consumer's (C and D) to go
> along with the two Dual Master's (A and B). I want to replicate to one of
> the dedicated consumers, C, prior to syncing the dual master B. I changed
> the passwords for dn:cn=replication,cn=config on A via the Directory
> Manager console, and via ldapmodify on C. I am confident that the passwords
> are the same on both systems.
>
>
> >What exactly did you do?
> >Note that you'll have to update the password in cn=replication,cn=config
> on the >consumer (C) and update the replication agreement on A for the
> replication agreement >between A and C.
>
> Thanks for the reply Rich. Yes, I updated the password on A and C. I
> apologize as I left out the link in my below reference to section 8.10.5.1
> :
>
> http://www.centos.org/docs/5/html/CDS/ag/8.0/Managing_Replication-Initial...
> .
> I used bak2db with backup files from A. After which, I see: "Unable to
> acquire replica: permission denied. The bind dn "cn=replication,cn=config"
> does not have permission to supply replication updates to the replica. Will
> retry later." on system A's error logs..
>
> >I think doing the restore is resetting the password. After doing the
> bak2db, change the >passwords.
>
> Well, I'm kind of at a loss here. I've reset the passwords on A and C
> after doing the bak2db. Same error:
>
>
> Unable to acquire replica: permission denied. The bind dn
> "cn=replication,cn=config" does not have permission to supply replication
> updates to the replica. Will retry later.
>
> Next, I removed and re-added the replication agreement on Master A to
> Consumer C, same error above.
>
> Is there any way that I can output the settings/password information for
> cn=replication,cn=config on both A and C via the command line to compare?
> I have read that there needs to be a 'person' entry on the consumer for
> cn=replication,cn=config that is used for the replication of the data. Is
> there a way I can confirm this configuration to ensure it is set up
> correctly?
>
> I'm also seeing this error in the logs on consumer C:
>
> NSMMReplicationPlugin - conn=2 op=9 replica="o=myTree": Unable to acquire
> replica: error: permission denied
>
>
>
> >I followed section 8.10.5.1 on initializing the consumer replica from
> backup files and it >worked with the following:
>
> >[02/Apr/2012:11:58:03 -0700] - Add Attribute readonly Value off
> >[02/Apr/2012:11:58:03 -0700] - Add Attribute nsslapd-directory Value
> /new/path/from/master/server
> >[02/Apr/2012:11:58:04 -0700] - Del Attribute nsslapd-directory Value
> /old/path/from/consumer
> >[02/Apr/2012:11:58:04 -0700] - WARNING!!: current Instance Config is
> different from backed up configuration; The backup is restored.
>
> >First, do I need to reset these attributes back to 'readonly' and the
> original nsslapd-directory?
>
> >Second, I am now receiving the following error from the master A:
> >Unable to acquire replica: permission denied. The bind dn
> "cn=replication,cn=config" >does not have permission to supply replication
> updates to the replica. Will retry later.
>
> >On another note, I see plain text passwords in the error logs on A for the
> consumers >but passwd = {SSHA}0bgDq2f1IM/2nNOOIHUh8lXfkG13XUOHTYD== for B,
> the other >master. Is there specific reason for this?
>
> >As always, any guidance that can be provided is greatly appreciated.
>
> TIA,
>
> Herb
>
> >
> > >> 3. I assume that upon repairing replication (apparently it has not
> been
> > working for several years) the systems will all replicate to the most
> > recent information. Correct?
> > >>>>I think that's the tricky part. Make sure you backup your directory
> > on all
> > >>>>the LDAP first so you have something to roll back. I *believe* the
> > last
> > >>>>step when setting up replication is initializing the directory and
> that
> > >>>>will wipe out directory on the other LDAP. Someone on the list might
> > be
> > >>>>able to provide a better on this but I am just giving you a heads up
> > that
> > >>>>this can be a complicated process.
> >
> > Given the fact that system B has not been running for some time, ideally
> > it would simply replicate to the current data on system A. After
> > replication is reestablished the systems are set up to "Always keep
> > directories in sync". If anyone can confirm the behavior that will occur
> > upon replication on these two systems it would be greatly appreciated.
> >
> > Thanks in advance,
> >
> > Herb
> >
> >
> > ------------------------------
> >>
> >> Message: 2
> >> Date: Thu, 22 Mar 2012 10:40:34 -0400
> >> From: Chun Tat David Chu <beyonddc.storage(a)gmail.com>
> >> To: "General discussion list for the 389 Directory server project."
> >> <389-users(a)lists.fedoraproject.org>
> >> Subject: Re: [389-users] Repair replication
> >> Message-ID:
> >> <
> >> CANCf8oLYKet99sB_ou4U3CER8U89UgwZhGUBTHekcF9HWNKL9g(a)mail.gmail.com>
> >> Content-Type: text/plain; charset="iso-8859-1"
> >>
> >> Hey Herb,
> >>
> >> You should refer to the Red Hat Directory Server administration guide
> for
> >> detail about setting up replication which you can locate in here.
> >> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/
> >>
> >> >> 1. How can I find out which system(s) is/are master, consumer, hub,
> >> etc?
> >> You should be able to determine the role of the Directory Server for
> each
> >> system by logging into the LDAP console under
> >> "Configuration->Replication". The role is either "Single Master", "Hub"
> >> or
> >> "Dedicated Consumer".
> >>
> >> >> 2. How do I confirm that the systems have the correct credentials for
> >> replication? (I am receiving: "Unable to acquire replica: Permission
> >> denied.")
> >> a. How can I change the bind dn "cn=replication,cn=config"
> credentials
> >> on each system to ensure replication will work?
> >> You can do that on the console as well. Just navigate down the
> directory
> >> tree and manually reset the password for the replication user account.
> >> There's a possibility that your replication user account's password
> >> expired.
> >>
> >> >> 3. I assume that upon repairing replication (apparently it has not
> been
> >> working for several years) the systems will all replicate to the most
> >> recent information. Correct?
> >> I think that's the tricky part. Make sure you backup your directory on
> >> all
> >> the LDAP first so you have something to roll back. I *believe* the last
> >> step when setting up replication is initializing the directory and that
> >> will wipe out directory on the other LDAP. Someone on the list might
> be
> >> able to provide a better on this but I am just giving you a heads up
> that
> >> this can be a complicated process.
> >>
> >> Good luck
> >>
> >> - David
> >>
> >> 2012/3/21 Herb Burnswell <herbert.burnswell(a)gmail.com>
> >>
> >> > Hi All,
> >> >
> >> > I'm new to LDAP administration and have been tasked with fixing the
> >> system
> >> > replication of 4 Linux systems running Fedora Directory Services. I
> am
> >> > very comfortable working with Linux/Unix but am not experienced with
> >> LDAP.
> >> > I've been reading the communications from this user group and reading
> as
> >> > much as I can from documentation. I believe this environment is not
> too
> >> > complex but I am looking for some guidance, any assistance is greatly
> >> > appreciated.
> >> >
> >> > Info:
> >> >
> >> > OS: Fedora Core 4
> >> > LDAP: Fedora Directory Server v 7.1
> >> >
> >> > First, I know that both the systems and FDS versions are ancient.
> >> > However, at this point I need to get the replication working prior to
> >> > putting together a migration plan. I have access to the Directory
> >> Manager
> >> > console and am comfortable running command line commands as well.
> >> Either
> >> > way is fine.
> >> >
> >> > Questions:
> >> >
> >> > 1. How can I find out which system(s) is/are master, consumer, hub,
> etc?
> >> >
> >> > 2. How do I confirm that the systems have the correct credentials for
> >> > replication? (I am receiving: "Unable to acquire replica: Permission
> >> > denied.")
> >> > a. How can I change the bind dn "cn=replication,cn=config"
> >> credentials
> >> > on each system to ensure replication will work?
> >> >
> >> > 3. I assume that upon repairing replication (apparently it has not
> been
> >> > working for several years) the systems will all replicate to the most
> >> > recent information. Correct?
> >> >
> >> > Again, any guidance is greatly appreciated.
> >> >
> >> > Thanks in advance,
> >> >
> >> > Herb
> >> >
> >> > --
> >> > 389 users mailing list
> >> > 389-users(a)lists.fedoraproject.org
> >> > https://admin.fedoraproject.org/mailman/listinfo/389-users
> >> >
> >> -------------- next part --------------
> >> An HTML attachment was scrubbed...
> >> URL: <
> >>
> http://lists.fedoraproject.org/pipermail/389-users/attachments/20120322/e...
> >> >
> >>
> >>
> >
> > --
> > 389 users mailing list389-users@lists.fedoraproject.orghttps://
> admin.fedoraproject.org/mailman/listinfo/389-users
> >
> >
> >
>
>
> --
> 389 users mailing
> list389-users@lists.fedoraproject.orghttps://
> admin.fedoraproject.org/mailman/listinfo/389-users
>
>
>
>
>
> --
> 389 users mailing
> list389-users@lists.fedoraproject.orghttps://
> admin.fedoraproject.org/mailman/listinfo/389-users
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.fedoraproject.org/pipermail/389-users/attachments/20120403/8...
> >
>
> ------------------------------
>
> Message: 2
> Date: Tue, 3 Apr 2012 16:59:38 -0500
> From: Jim Finn <jamespfinn(a)gmail.com>
> To: "General discussion list for the 389 Directory server project."
> <389-users(a)lists.fedoraproject.org>
> Subject: Re: [389-users] Repair replication
> Message-ID:
> <CAHx81c8Qw+3LMMbPC7+7gAXsJaMXPUTh=gD-S20h681oUMsX+A(a)mail.gmail.com
> >
> Content-Type: text/plain; charset="iso-8859-1"
>
> This can be caused by replication dn having an expired password.
>
Thanks Jim. Yea, I've reset the passwords on the Master and Consumer
several times to no avail. I continually receive the errors:
Master = Unable to acquire replica: permission denied. The bind dn
"cn=replication,cn=config" does not have permission to supply replication
updates to the replica. Will retry later.
Consumer = NSMMReplicationPlugin - conn=198 op=3 replica="o=mytree": Unable
to acquire replica: error: permission denied
>
> On Tue, Apr 3, 2012 at 4:55 PM, Herb Burnswell
> <herbert.burnswell(a)gmail.com>wrote:
>
> >
> > ---------- Forwarded message ----------
> > From: Rich Megginson <rmeggins(a)redhat.com>
> > Date: Mon, Apr 2, 2012 at 7:37 PM
> > Subject: Re: [389-users] Fwd: Repair replication
> > To: "General discussion list for the 389 Directory server project." <
> > 389-users(a)lists.fedoraproject.org>
> > Cc: Herb Burnswell <herbert.burnswell(a)gmail.com>
> >
> >
> > On 04/02/2012 05:48 PM, Herb Burnswell wrote:
> >
> >
> >
> > ---------- Forwarded message ----------
> > From: Rich Megginson <rmeggins(a)redhat.com>
> > Date: Mon, Apr 2, 2012 at 3:23 PM
> > Subject: Re: [389-users] Repair replication
> > To: "General discussion list for the 389 Directory server project." <
> > 389-users(a)lists.fedoraproject.org>
> > Cc: Herb Burnswell <herbert.burnswell(a)gmail.com>
> >
> >
> > On 04/02/2012 04:13 PM, Herb Burnswell wrote:
> >
> >
> >
> > On Fri, Mar 23, 2012 at 10:53 AM, Rich Megginson <rmeggins(a)redhat.com
> >wrote:
> >
> >> On 03/23/2012 11:09 AM, Herb Burnswell wrote:
> >>
> >> Thanks for the reply David.
> >>
> >> >> 1. How can I find out which system(s) is/are master, consumer, hub,
> >> etc?
> >> >>>>You should be able to determine the role of the Directory Server for
> >> each
> >> >>>>system by logging into the LDAP console under
> >> >>>>"Configuration->Replication". The role is either "Single Master",
> >> "Hub" or
> >> >>>>"Dedicated Consumer".
> >>
> >> >I was able to determine that we have two "Multiple Master" systems.
> >> Let's call >them 'A' and 'B'. System A has been the only system running
> >> for what appears to >be several years (it is being backed up nightly).
> >> System B has been off for some >time but is running now.
> >>
> >> >> 2. How do I confirm that the systems have the correct credentials for
> >> >replication? (I am receiving: "Unable to acquire replica: Permission
> >> >denied.")
> >> >a. How can I change the bind dn "cn=replication,cn=config"
> credentials
> >> >on each system to ensure replication will work?
> >> >>>>You can do that on the console as well. Just navigate down the
> >> directory
> >> >>>>tree and manually reset the password for the replication user
> account.
> >> >>>>There's a possibility that your replication user account's password
> >> expired.
> >>
> >> >I can navigate to the screen to reset the password for the replication
> >> user account. I >have not reset the passwords yet as I am reading
> >> documentation to confirm that >system B will simply update it's data to
> >> system A's upon resuming replication.
> >>
> >> >When you change the password of the replication user on B, you'll also
> >> have to update >those credentials in the replication agreement on A for
> the
> >> agreement from A to B.
> >>
> >> >Note that if replication has been down for years, you will have to
> >> perform a manual >replica initialization procedure - replication will
> not
> >> automatically "catch up" if it has >been down that long.
> >>
> >> Rich - Thank you for the response. I was diverted to another urgent
> > issue but have come back to this replication fix.
> >
> > I've confirmed that there are two Dedicated Consumer's (C and D) to go
> > along with the two Dual Master's (A and B). I want to replicate to one of
> > the dedicated consumers, C, prior to syncing the dual master B. I changed
> > the passwords for dn:cn=replication,cn=config on A via the Directory
> > Manager console, and via ldapmodify on C. I am confident that the
> passwords
> > are the same on both systems.
> >
> >
> > >What exactly did you do?
> > >Note that you'll have to update the password in cn=replication,cn=config
> > on the >consumer (C) and update the replication agreement on A for the
> > replication agreement >between A and C.
> >
> > Thanks for the reply Rich. Yes, I updated the password on A and C. I
> > apologize as I left out the link in my below reference to section
> 8.10.5.1:
> >
> >
> http://www.centos.org/docs/5/html/CDS/ag/8.0/Managing_Replication-Initial...
> .
> > I used bak2db with backup files from A. After which, I see: "Unable to
> > acquire replica: permission denied. The bind dn
> "cn=replication,cn=config"
> > does not have permission to supply replication updates to the replica.
> Will
> > retry later." on system A's error logs..
> >
> > >I think doing the restore is resetting the password. After doing the
> > bak2db, change the >passwords.
> >
> > Well, I'm kind of at a loss here. I've reset the passwords on A and C
> > after doing the bak2db. Same error:
> >
> >
> > Unable to acquire replica: permission denied. The bind dn
> > "cn=replication,cn=config" does not have permission to supply replication
> > updates to the replica. Will retry later.
> >
> > Next, I removed and re-added the replication agreement on Master A to
> > Consumer C, same error above.
> >
> > Is there any way that I can output the settings/password information for
> > cn=replication,cn=config on both A and C via the command line to compare?
> > I have read that there needs to be a 'person' entry on the consumer for
> > cn=replication,cn=config that is used for the replication of the data.
> Is
> > there a way I can confirm this configuration to ensure it is set up
> > correctly?
> >
> > I'm also seeing this error in the logs on consumer C:
> >
> > NSMMReplicationPlugin - conn=2 op=9 replica="o=myTree": Unable to
> acquire
> > replica: error: permission denied
> >
> >
> >
> >
> > >I followed section 8.10.5.1 on initializing the consumer replica from
> > backup files and it >worked with the following:
> >
> > >[02/Apr/2012:11:58:03 -0700] - Add Attribute readonly Value off
> > >[02/Apr/2012:11:58:03 -0700] - Add Attribute nsslapd-directory Value
> > /new/path/from/master/server
> > >[02/Apr/2012:11:58:04 -0700] - Del Attribute nsslapd-directory Value
> > /old/path/from/consumer
> > >[02/Apr/2012:11:58:04 -0700] - WARNING!!: current Instance Config is
> > different from backed up configuration; The backup is restored.
> >
> > >First, do I need to reset these attributes back to 'readonly' and the
> > original nsslapd-directory?
> >
> > >Second, I am now receiving the following error from the master A:
> > >Unable to acquire replica: permission denied. The bind dn
> > "cn=replication,cn=config" >does not have permission to supply
> replication
> > updates to the replica. Will retry later.
> >
> > >On another note, I see plain text passwords in the error logs on A for
> > the consumers >but passwd = {SSHA}0bgDq2f1IM/2nNOOIHUh8lXfkG13XUOHTYD==
> for
> > B, the other >master. Is there specific reason for this?
> >
> > >As always, any guidance that can be provided is greatly appreciated.
> >
> > TIA,
> >
> > Herb
> >
> >>
> >> >> 3. I assume that upon repairing replication (apparently it has not
> been
> >> working for several years) the systems will all replicate to the most
> >> recent information. Correct?
> >> >>>>I think that's the tricky part. Make sure you backup your directory
> >> on all
> >> >>>>the LDAP first so you have something to roll back. I *believe* the
> >> last
> >> >>>>step when setting up replication is initializing the directory and
> >> that
> >> >>>>will wipe out directory on the other LDAP. Someone on the list
> might
> >> be
> >> >>>>able to provide a better on this but I am just giving you a heads up
> >> that
> >> >>>>this can be a complicated process.
> >>
> >> Given the fact that system B has not been running for some time, ideally
> >> it would simply replicate to the current data on system A. After
> >> replication is reestablished the systems are set up to "Always keep
> >> directories in sync". If anyone can confirm the behavior that will
> occur
> >> upon replication on these two systems it would be greatly appreciated.
> >>
> >> Thanks in advance,
> >>
> >> Herb
> >>
> >>
> >> ------------------------------
> >>>
> >>> Message: 2
> >>> Date: Thu, 22 Mar 2012 10:40:34 -0400
> >>> From: Chun Tat David Chu <beyonddc.storage(a)gmail.com>
> >>> To: "General discussion list for the 389 Directory server project."
> >>> <389-users(a)lists.fedoraproject.org>
> >>> Subject: Re: [389-users] Repair replication
> >>> Message-ID:
> >>> <
> >>> CANCf8oLYKet99sB_ou4U3CER8U89UgwZhGUBTHekcF9HWNKL9g(a)mail.gmail.com>
> >>> Content-Type: text/plain; charset="iso-8859-1"
> >>>
> >>> Hey Herb,
> >>>
> >>> You should refer to the Red Hat Directory Server administration guide
> for
> >>> detail about setting up replication which you can locate in here.
> >>> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/
> >>>
> >>> >> 1. How can I find out which system(s) is/are master, consumer, hub,
> >>> etc?
> >>> You should be able to determine the role of the Directory Server for
> each
> >>> system by logging into the LDAP console under
> >>> "Configuration->Replication". The role is either "Single Master",
> "Hub"
> >>> or
> >>> "Dedicated Consumer".
> >>>
> >>> >> 2. How do I confirm that the systems have the correct credentials
> for
> >>> replication? (I am receiving: "Unable to acquire replica: Permission
> >>> denied.")
> >>> a. How can I change the bind dn "cn=replication,cn=config"
> credentials
> >>> on each system to ensure replication will work?
> >>> You can do that on the console as well. Just navigate down the
> directory
> >>> tree and manually reset the password for the replication user account.
> >>> There's a possibility that your replication user account's password
> >>> expired.
> >>>
> >>> >> 3. I assume that upon repairing replication (apparently it has not
> >>> been
> >>> working for several years) the systems will all replicate to the most
> >>> recent information. Correct?
> >>> I think that's the tricky part. Make sure you backup your directory on
> >>> all
> >>> the LDAP first so you have something to roll back. I *believe* the
> last
> >>> step when setting up replication is initializing the directory and that
> >>> will wipe out directory on the other LDAP. Someone on the list might
> be
> >>> able to provide a better on this but I am just giving you a heads up
> that
> >>> this can be a complicated process.
> >>>
> >>> Good luck
> >>>
> >>> - David
> >>>
> >>> 2012/3/21 Herb Burnswell <herbert.burnswell(a)gmail.com>
> >>>
> >>> > Hi All,
> >>> >
> >>> > I'm new to LDAP administration and have been tasked with fixing the
> >>> system
> >>> > replication of 4 Linux systems running Fedora Directory Services. I
> am
> >>> > very comfortable working with Linux/Unix but am not experienced with
> >>> LDAP.
> >>> > I've been reading the communications from this user group and reading
> >>> as
> >>> > much as I can from documentation. I believe this environment is not
> >>> too
> >>> > complex but I am looking for some guidance, any assistance is greatly
> >>> > appreciated.
> >>> >
> >>> > Info:
> >>> >
> >>> > OS: Fedora Core 4
> >>> > LDAP: Fedora Directory Server v 7.1
> >>> >
> >>> > First, I know that both the systems and FDS versions are ancient.
> >>> > However, at this point I need to get the replication working prior to
> >>> > putting together a migration plan. I have access to the Directory
> >>> Manager
> >>> > console and am comfortable running command line commands as well.
> >>> Either
> >>> > way is fine.
> >>> >
> >>> > Questions:
> >>> >
> >>> > 1. How can I find out which system(s) is/are master, consumer, hub,
> >>> etc?
> >>> >
> >>> > 2. How do I confirm that the systems have the correct credentials for
> >>> > replication? (I am receiving: "Unable to acquire replica: Permission
> >>> > denied.")
> >>> > a. How can I change the bind dn "cn=replication,cn=config"
> >>> credentials
> >>> > on each system to ensure replication will work?
> >>> >
> >>> > 3. I assume that upon repairing replication (apparently it has not
> been
> >>> > working for several years) the systems will all replicate to the most
> >>> > recent information. Correct?
> >>> >
> >>> > Again, any guidance is greatly appreciated.
> >>> >
> >>> > Thanks in advance,
> >>> >
> >>> > Herb
> >>> >
> >>> > --
> >>> > 389 users mailing list
> >>> > 389-users(a)lists.fedoraproject.org
> >>> > https://admin.fedoraproject.org/mailman/listinfo/389-users
> >>> >
> >>> -------------- next part --------------
> >>> An HTML attachment was scrubbed...
> >>> URL: <
> >>>
> http://lists.fedoraproject.org/pipermail/389-users/attachments/20120322/e...
> >>> >
> >>>
> >>>
> >>
> >> --
> >> 389 users mailing list389-users@lists.fedoraproject.orghttps://
> admin.fedoraproject.org/mailman/listinfo/389-users
> >>
> >>
> >>
> >
> >
> > --
> > 389 users mailing list389-users@lists.fedoraproject.orghttps://
> admin.fedoraproject.org/mailman/listinfo/389-users
> >
> >
> >
> >
> >
> > --
> > 389 users mailing list389-users@lists.fedoraproject.orghttps://
> admin.fedoraproject.org/mailman/listinfo/389-users
> >
> >
> >
> >
> >
> > --
> > 389 users mailing list
> > 389-users(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/389-users
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.fedoraproject.org/pipermail/389-users/attachments/20120403/e...
> >
>
> ------------------------------
>
> --
> 389 users mailing list
> 389-users(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>
> End of 389-users Digest, Vol 83, Issue 9
> ****************************************
>
12 years
Audit log - clear text password in user changes
by Alberto Viana
I have an 389 DS (version 1.2.10.2) with AD replication and I enabled the
audit log, but when I change a user password, shows the unhashed password
in the audit log file:
time: 20120404113336
dn: uid=alberto.viana,OU=G,OU=RJ,dc=my,dc=domain
changetype: modify
replace: userPassword
userPassword: {SSHA}bqBSVbLJpqKCujEC2JC4ysaUUJuTsFe87AoPsQ==
-
replace: modifiersname
modifiersname:
uid=admin,ou=administrators,ou=topologymanagement,o=netscaperoo
t
-
replace: modifytimestamp
modifytimestamp: 20120404143336Z
-
replace: unhashed#user#password
unhashed#user#password: maisumteste
-
Is the expected behavior? Can I configure to just not show the unhashed
password? Because I need the audit log.
12 years
Questions on RedHat DS9.0 Deployment Guide (schema replication)
by Roberto Polli
Hi all,
just some easy questions. The quoted text is taken from
Red Hat DS 9.0 Deployment Guide.
§7.4.4 Schema Replication
> In all replication scenarios...[cut] The following conditions apply:
> If the version of the schema ...[master has newer]...the supplicer server
replicates to the consumer
Q1: shouldn't this happen only when changes are done via ldapmodify (as stated
in the note at the ending of the chapter)?
Q2: changes made with 98example.ldif shouldn't propagate, right?
> If the version of the schema...[slave has newer]...the server may return
many errors...
Q3: so replication still happens. I would state this clearly, like
"replication happens even in case of schema mismatching"
> A consumer might contain replicated data from two suppliers, each with
different schema. Whichever supplier was updated last wins, and its schema is
propagated to the consumer.
Q4: imho it seems a wider highway to hell -_- As of Q1,2 I can avoid it using
ldif, right?
> Changes made to custom schema files are only replicated if the schema is
updated using LDAP or the Directory Server Console
Q5: I have understood that you can't change a custom schema file using
LDAP/DSConsole. All modifications go to 99user.ldif: right?
I hope I haven't bored you too much...
Thx+Peace,
R.
--
Roberto Polli
Community Manager
Babel S.r.l. - http://www.babel.it
T: +39.06.9826.9651 M: +39.340.652.2736 F: +39.06.9826.9680
P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma)
CONFIDENZIALE: Questo messaggio ed i suoi allegati sono di carattere
confidenziale per i destinatari in indirizzo.
E' vietato l'inoltro non autorizzato a destinatari diversi da quelli indicati
nel messaggio originale.
Se ricevuto per errore, l'uso del contenuto e' proibito; si prega di
comunicarlo al mittente e cancellarlo immediatamente.
12 years
Re: [389-users] Password Sync - Extended Characters nothing happnes?
by Rich Megginson
On 04/03/2012 08:09 AM, MATON Brett wrote:
>
> Hi,
>
> The password sync service between AD and Directory server appears to
> “can” passwords with extended characters.
>
> I’m working for a client in Belgium at the moment and they’re quite
> accent happy with passwords.
>
> Now, Active Directory happily accepts these passwords but I don’t
> even get a sniff of the password change attempt in the audit log from
> in 389-DS.
>
> Is this a bug or by design ?
>
> http://port389.org/wiki/Howto:WindowsSync#PassSync_Logging
>
>
>
> Thanks Rich ( I don’t normally get access to windows logs J).
>
> 04/02/12 14:42:22: Modify password failed for remote entry:
> uid=<user>,ou=People,<blah>
>
> 04/02/12 14:42:22: Deferring password change for <user>
>
> 04/02/12 14:42:24: Ldap error in ModifyPassword
>
> 19: Constraint violation
>
> No problem, bit of digging around tells me that there is a 7 bit
> character constraint on passwords (7-bit check plugin).
>
> What I don’t understand is why there is nothing on the Linux side, surely:
>
> 04/02/12 14:42:24: Ldap error in ModifyPassword
>
> Means that the password change has been attempted and rejected by the
> server, so why am I not seeing anything in the logs on the server?
>
> Do you see any connections at all from the AD box in your directory
> server access log? /var/log/dirsrv/slapd-INSTANCE/access
>
>
> Yes, I’ve got this with a tome stamp matching when the user changed
> their AD password 14:42:21, and 2 seconds later 14:42:23 (there is
> more of the same every few seconds until it gives up):
>
> [02/Apr/2012:14:42:21 +0200] conn=14516 SSL 128-bit RC4
>
> [02/Apr/2012:14:42:21 +0200] conn=14516 op=0 BIND dn="cn=<sync
> id>,cn=config" method=128 version=3
>
> [02/Apr/2012:14:42:21 +0200] conn=14516 op=0 RESULT err=0 tag=97
> nentries=0 etime=0 dn="cn=<sync id>,cn=config"
>
> [02/Apr/2012:14:42:21 +0200] conn=14516 op=1 SRCH
> base="ou=People,<domain>" scope=2 filter="(ntUserDomainId=<user id>)"
> attrs=ALL
>
> [02/Apr/2012:14:42:21 +0200] conn=14516 op=1 RESULT err=0 tag=101
> nentries=1 etime=0
>
> [02/Apr/2012:14:42:21 +0200] conn=14517 fd=106 slot=106 SSL connection
> from <AD Server IP> to <DS Server IP>
>
> [02/Apr/2012:14:42:21 +0200] conn=14517 SSL 128-bit RC4
>
> [02/Apr/2012:14:42:21 +0200] conn=14517 op=0 BIND dn="uid=<user
> id>,ou=People,<domain>" method=128 version=3
>
> [02/Apr/2012:14:42:21 +0200] conn=14517 op=0 RESULT err=49 tag=97
> nentries=0 etime=0
>
> [02/Apr/2012:14:42:21 +0200] conn=14517 op=1 UNBIND
>
> [02/Apr/2012:14:42:21 +0200] conn=14517 op=1 fd=106 closed - U1
>
> [02/Apr/2012:14:42:21 +0200] conn=14516 op=2 MOD dn="uid=<user
> id>,ou=People,<domain>"
>
> [02/Apr/2012:14:42:21 +0200] conn=14516 op=2 RESULT err=19 tag=103
> nentries=0 etime=0
>
> [02/Apr/2012:14:42:21 +0200] conn=14516 op=3 UNBIND
>
> [02/Apr/2012:14:42:21 +0200] conn=14516 op=3 fd=103 closed - U1
>
> [02/Apr/2012:14:42:23 +0200] conn=14518 fd=103 slot=103 SSL connection
> from <AD Server IP> to <DS Server IP>
>
> [02/Apr/2012:14:42:23 +0200] conn=14518 SSL 128-bit RC4
>
> [02/Apr/2012:14:42:23 +0200] conn=14518 op=0 BIND dn="cn=<sync
> id>,cn=config" method=128 version=3
>
> [02/Apr/2012:14:42:23 +0200] conn=14518 op=0 RESULT err=0 tag=97
> nentries=0 etime=0 dn="cn=<sync id>,cn=config"
>
> [02/Apr/2012:14:42:23 +0200] conn=14518 op=1 SRCH
> base="ou=People,<domain>" scope=2 filter="(ntUserDomainId=<user id>)"
> attrs=ALL
>
> [02/Apr/2012:14:42:23 +0200] conn=14518 op=1 RESULT err=0 tag=101
> nentries=1 etime=0
>
> [02/Apr/2012:14:42:23 +0200] conn=14519 fd=106 slot=106 SSL connection
> from <AD Server IP> to <DS Server IP>
>
> [02/Apr/2012:14:42:23 +0200] conn=14519 SSL 128-bit RC4
>
> [02/Apr/2012:14:42:23 +0200] conn=14519 op=0 BIND dn="uid=<user
> id>,ou=People,<domain>" method=128 version=3
>
> [02/Apr/2012:14:42:23 +0200] conn=14519 op=0 RESULT err=49 tag=97
> nentries=0 etime=0
>
> [02/Apr/2012:14:42:23 +0200] conn=14519 op=1 UNBIND
>
> [02/Apr/2012:14:42:23 +0200] conn=14519 op=1 fd=106 closed - U1
>
> [02/Apr/2012:14:42:23 +0200] conn=14518 op=2 MOD dn="uid=<user
> id>,ou=People,<domain>"
>
> [02/Apr/2012:14:42:23 +0200] conn=14518 op=2 RESULT err=19 tag=103
> nentries=0 etime=0
>
> [02/Apr/2012:14:42:23 +0200] conn=14518 op=3 UNBIND
>
> [02/Apr/2012:14:42:23 +0200] conn=14518 op=3 fd=103 closed - U1
>
> Having seen the error logged on the AD Server I guess I should be
> looking for these entries (err=19) then?:
>
> [02/Apr/2012:14:42:21 +0200] conn=14516 op=2 RESULT err=19 tag=103
> nentries=0 etime=0
>
> Anyway to get these password failures logged to audit?
>
> Hmm - I guess failed modify operations are not logged to the audit log?
> Anyway, you have confirmed that the directory server doesn't like the
> passwords - err=19 means that either the password fails the 7-bit
> checking or fails password syntax checking.
>
> It would appear that I only have successful modifications logged in audit.
>
> And yes, for sure the problem is the 7-bit check as the guys are using
> (or trying to) accented characters in their passwords.
>
Ok. You can turn off the 7-bit check plugin
shutdown 389
edit /etc/dirsrv/slapd-INST/dse.ldif - look for cn=7-bit
check,cn=plugins,cn=config - change the nsslapd-pluginenabled: off
start 389
>
> Regards,
>
> Brett
>
> -------------------------------------------------------------------
>
> *GreeNRB
> */NRB considers its environmental responsibility and goes for green IT./
> /May we ask you to consider yours before printing this e-mail? /**
>
> *NRB, daring to commit
> */This e-mail and any attachments, which may contain information that
> is confidential and/or protected by intellectual property rights, are
> intended for the exclusive use of the above-mentioned addressee(s).
> Any use (including reproduction, disclosure and whole or partial
> distribution in any form whatsoever) of their content is prohibited
> without prior authorization of NRB. If you have received this message
> by error, please contact the sender promptly by resending this e-mail
> back to him (her), or by calling the above number. Thank you for
> subsequently deleting this e-mail and any files attached thereto./
>
12 years
Re: [389-users] Password Sync - Extended Characters nothing happnes?
by Rich Megginson
On 04/03/2012 07:53 AM, MATON Brett wrote:
>
> Hi,
>
> The password sync service between AD and Directory server appears to
> “can” passwords with extended characters.
>
> I’m working for a client in Belgium at the moment and they’re quite
> accent happy with passwords.
>
> Now, Active Directory happily accepts these passwords but I don’t
> even get a sniff of the password change attempt in the audit log from
> in 389-DS.
>
> Is this a bug or by design ?
>
> http://port389.org/wiki/Howto:WindowsSync#PassSync_Logging
>
>
> Thanks Rich ( I don’t normally get access to windows logs J).
>
> 04/02/12 14:42:22: Modify password failed for remote entry:
> uid=<user>,ou=People,<blah>
>
> 04/02/12 14:42:22: Deferring password change for <user>
>
> 04/02/12 14:42:24: Ldap error in ModifyPassword
>
> 19: Constraint violation
>
> No problem, bit of digging around tells me that there is a 7 bit
> character constraint on passwords (7-bit check plugin).
>
> What I don’t understand is why there is nothing on the Linux side, surely:
>
> 04/02/12 14:42:24: Ldap error in ModifyPassword
>
> Means that the password change has been attempted and rejected by the
> server, so why am I not seeing anything in the logs on the server?
>
> Do you see any connections at all from the AD box in your directory
> server access log? /var/log/dirsrv/slapd-INSTANCE/access
>
> Yes, I’ve got this with a tome stamp matching when the user changed
> their AD password 14:42:21, and 2 seconds later 14:42:23 (there is
> more of the same every few seconds until it gives up):
>
> [02/Apr/2012:14:42:21 +0200] conn=14516 SSL 128-bit RC4
>
> [02/Apr/2012:14:42:21 +0200] conn=14516 op=0 BIND dn="cn=<sync
> id>,cn=config" method=128 version=3
>
> [02/Apr/2012:14:42:21 +0200] conn=14516 op=0 RESULT err=0 tag=97
> nentries=0 etime=0 dn="cn=<sync id>,cn=config"
>
> [02/Apr/2012:14:42:21 +0200] conn=14516 op=1 SRCH
> base="ou=People,<domain>" scope=2 filter="(ntUserDomainId=<user id>)"
> attrs=ALL
>
> [02/Apr/2012:14:42:21 +0200] conn=14516 op=1 RESULT err=0 tag=101
> nentries=1 etime=0
>
> [02/Apr/2012:14:42:21 +0200] conn=14517 fd=106 slot=106 SSL connection
> from <AD Server IP> to <DS Server IP>
>
> [02/Apr/2012:14:42:21 +0200] conn=14517 SSL 128-bit RC4
>
> [02/Apr/2012:14:42:21 +0200] conn=14517 op=0 BIND dn="uid=<user
> id>,ou=People,<domain>" method=128 version=3
>
> [02/Apr/2012:14:42:21 +0200] conn=14517 op=0 RESULT err=49 tag=97
> nentries=0 etime=0
>
> [02/Apr/2012:14:42:21 +0200] conn=14517 op=1 UNBIND
>
> [02/Apr/2012:14:42:21 +0200] conn=14517 op=1 fd=106 closed - U1
>
> [02/Apr/2012:14:42:21 +0200] conn=14516 op=2 MOD dn="uid=<user
> id>,ou=People,<domain>"
>
> [02/Apr/2012:14:42:21 +0200] conn=14516 op=2 RESULT err=19 tag=103
> nentries=0 etime=0
>
> [02/Apr/2012:14:42:21 +0200] conn=14516 op=3 UNBIND
>
> [02/Apr/2012:14:42:21 +0200] conn=14516 op=3 fd=103 closed - U1
>
> [02/Apr/2012:14:42:23 +0200] conn=14518 fd=103 slot=103 SSL connection
> from <AD Server IP> to <DS Server IP>
>
> [02/Apr/2012:14:42:23 +0200] conn=14518 SSL 128-bit RC4
>
> [02/Apr/2012:14:42:23 +0200] conn=14518 op=0 BIND dn="cn=<sync
> id>,cn=config" method=128 version=3
>
> [02/Apr/2012:14:42:23 +0200] conn=14518 op=0 RESULT err=0 tag=97
> nentries=0 etime=0 dn="cn=<sync id>,cn=config"
>
> [02/Apr/2012:14:42:23 +0200] conn=14518 op=1 SRCH
> base="ou=People,<domain>" scope=2 filter="(ntUserDomainId=<user id>)"
> attrs=ALL
>
> [02/Apr/2012:14:42:23 +0200] conn=14518 op=1 RESULT err=0 tag=101
> nentries=1 etime=0
>
> [02/Apr/2012:14:42:23 +0200] conn=14519 fd=106 slot=106 SSL connection
> from <AD Server IP> to <DS Server IP>
>
> [02/Apr/2012:14:42:23 +0200] conn=14519 SSL 128-bit RC4
>
> [02/Apr/2012:14:42:23 +0200] conn=14519 op=0 BIND dn="uid=<user
> id>,ou=People,<domain>" method=128 version=3
>
> [02/Apr/2012:14:42:23 +0200] conn=14519 op=0 RESULT err=49 tag=97
> nentries=0 etime=0
>
> [02/Apr/2012:14:42:23 +0200] conn=14519 op=1 UNBIND
>
> [02/Apr/2012:14:42:23 +0200] conn=14519 op=1 fd=106 closed - U1
>
> [02/Apr/2012:14:42:23 +0200] conn=14518 op=2 MOD dn="uid=<user
> id>,ou=People,<domain>"
>
> [02/Apr/2012:14:42:23 +0200] conn=14518 op=2 RESULT err=19 tag=103
> nentries=0 etime=0
>
> [02/Apr/2012:14:42:23 +0200] conn=14518 op=3 UNBIND
>
> [02/Apr/2012:14:42:23 +0200] conn=14518 op=3 fd=103 closed - U1
>
> Having seen the error logged on the AD Server I guess I should be
> looking for these entries (err=19) then?:
>
> [02/Apr/2012:14:42:21 +0200] conn=14516 op=2 RESULT err=19 tag=103
> nentries=0 etime=0
>
> Anyway to get these password failures logged to audit?
>
Hmm - I guess failed modify operations are not logged to the audit log?
Anyway, you have confirmed that the directory server doesn't like the
passwords - err=19 means that either the password fails the 7-bit
checking or fails password syntax checking.
>
> Regards,
>
> Brett
>
> -------------------------------------------------------------------
>
> *GreeNRB**
> */NRB considers its environmental responsibility and goes for green IT./
> /May we ask you to consider yours before printing this e-mail? /**
>
> *NRB, daring to commit
> */This e-mail and any attachments, which may contain information that
> is confidential and/or protected by intellectual property rights, are
> intended for the exclusive use of the above-mentioned addressee(s).
> Any use (including reproduction, disclosure and whole or partial
> distribution in any form whatsoever) of their content is prohibited
> without prior authorization of NRB. If you have received this message
> by error, please contact the sender promptly by resending this e-mail
> back to him (her), or by calling the above number. Thank you for
> subsequently deleting this e-mail and any files attached thereto./
>
> -------------------------------------------------------------------
>
> *GreeNRB
> */NRB considers its environmental responsibility and goes for green IT./
> /May we ask you to consider yours before printing this e-mail? /**
>
> *NRB, daring to commit
> */This e-mail and any attachments, which may contain information that
> is confidential and/or protected by intellectual property rights, are
> intended for the exclusive use of the above-mentioned addressee(s).
> Any use (including reproduction, disclosure and whole or partial
> distribution in any form whatsoever) of their content is prohibited
> without prior authorization of NRB. If you have received this message
> by error, please contact the sender promptly by resending this e-mail
> back to him (her), or by calling the above number. Thank you for
> subsequently deleting this e-mail and any files attached thereto./
>
12 years
Problem with plugin
by Juan Asensio Sánchez
Hi
We have done a plugin that dynamically change some attributes of the
search results. The main code is like this:
int smbhack_hook( Slapi_PBlock* pb ) {
// ...
Slapi_Entry** s_entradas = NULL;
Slapi_PBlock* pbi = NULL;
// ...
rv = slapi_pblock_get(
pb,
SLAPI_SEARCH_STRFILTER,
&s_strfilter
);
if (rv == -1) {
slapi_unlock_mutex(cfg_lock);
return LDAP_OP_IGNORED;
}
// ...
slapi_search_internal_set_pb(
pbi,
s_dn, // Base
s_scope, // Ambito
s_strfilter, // Filtro
s_attrs, // Atributos buscados
s_attrsonly, // Flag de seleccion
s_controls, // Controls
s_uid, // DN vs uid
plugin_id, // ComponentId
SLAPI_OP_FLAG_NEVER_CHAIN // Flags
);
// ...
rv = slapi_pblock_get(
pbi,
SLAPI_PLUGIN_INTOP_SEARCH_ENTRIES,
&s_entradas
);
// ...
if (s_entradas == NULL || s_entradas[0] == NULL) {
slapi_unlock_mutex(cfg_lock);
destruir_estructura_dn(pila_dn_invocador);
slapi_pblock_destroy(pbi);
return LDAP_OP_IGNORED;
}
// ...
}
The problem is thar when doing a search with this filter:
(&(ou:dn:=People)(uid=myuid)(objectClass=sambaSamAccount))
the method slapi_pblock_getfor the attribute
SLAPI_PLUGIN_INTOP_SEARCH_ENTRIES returns s_entradas != null, but if I
do a search with this filter:
(&(|(ou:dn:=Computers)(ou:dn:=People))(uid=myuid)(objectClass=sambaSamAccount))
s_entradas is null or s_entradas[0] is null and the operation is ignored.
What could the reason?
If anyone can be useful, this plugin simulates a samba domain trust,
making some users of other organization in a group, change dinamycally
their sambasid to make them a valid user in the target windows domain.
12 years
Re: [389-users] Password Sync - Extended Characters nothing happnes?
by Rich Megginson
On 04/02/2012 11:16 PM, MATON Brett wrote:
>
> Hi,
>
> The password sync service between AD and Directory server appears to
> “can” passwords with extended characters.
>
> I’m working for a client in Belgium at the moment and they’re quite
> accent happy with passwords.
>
> Now, Active Directory happily accepts these passwords but I don’t
> even get a sniff of the password change attempt in the audit log from
> in 389-DS.
>
> Is this a bug or by design ?
>
> http://port389.org/wiki/Howto:WindowsSync#PassSync_Logging
>
> Thanks Rich ( I don’t normally get access to windows logs J).
>
> 04/02/12 14:42:22: Modify password failed for remote entry:
> uid=<user>,ou=People,<blah>
>
> 04/02/12 14:42:22: Deferring password change for <user>
>
> 04/02/12 14:42:24: Ldap error in ModifyPassword
>
> 19: Constraint violation
>
> No problem, bit of digging around tells me that there is a 7 bit
> character constraint on passwords (7-bit check plugin).
>
> What I don’t understand is why there is nothing on the Linux side, surely:
>
> //04/02/12 14:42:24: Ldap error in ModifyPassword
>
> Means that the password change has been attempted and rejected by the
> server, so why am I not seeing anything in the logs on the server?
>
Do you see any connections at all from the AD box in your directory
server access log? /var/log/dirsrv/slapd-INSTANCE/access
>
> Regards,
>
> Brett
>
> -------------------------------------------------------------------
>
> *GreeNRB
> */NRB considers its environmental responsibility and goes for green IT./
> /May we ask you to consider yours before printing this e-mail? /**
>
> *NRB, daring to commit
> */This e-mail and any attachments, which may contain information that
> is confidential and/or protected by intellectual property rights, are
> intended for the exclusive use of the above-mentioned addressee(s).
> Any use (including reproduction, disclosure and whole or partial
> distribution in any form whatsoever) of their content is prohibited
> without prior authorization of NRB. If you have received this message
> by error, please contact the sender promptly by resending this e-mail
> back to him (her), or by calling the above number. Thank you for
> subsequently deleting this e-mail and any files attached thereto./
>
12 years
Schema upgrade and a little error in wiki
by Roberto Polli
Hi Rich|All,
= Stuff 1 =
I'm planning a schema upgrade on a platform with 4 ds. The schema is on a
98myschema.ldif.
I got 2 MMR on backend and 2 replica on FE.
On RH documentation I read to:
- upgrade all masters;
- then upgrade slaves;
- lately restart.
This approach seems to lead to some service discontinuity, as - during this
migration - I should stop writes to all master/slaves.
How would you do it?
= Stuff 2 =
I found a possible typo here:
http://directory.fedoraproject.org/wiki/Dynamically_Reload_Schema
The following command doesn't write out the schema
# ldapsearch -D "cn=Directory Manager" -w password -b "cn=schema" -T
"(objectclass=*)"
you need to specify the attributes, eg:
# ldapsearch ... -b "cn=schema" -T "(objectclass=*)" "*" objectclasses
Does it happen to you too?
Thx+ Peace,
R.
--
Roberto Polli
Community Manager
Babel S.r.l. - http://www.babel.it
T: +39.06.9826.9651 M: +39.340.652.2736 F: +39.06.9826.9680
P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma)
CONFIDENZIALE: Questo messaggio ed i suoi allegati sono di carattere
confidenziale per i destinatari in indirizzo.
E' vietato l'inoltro non autorizzato a destinatari diversi da quelli indicati
nel messaggio originale.
Se ricevuto per errore, l'uso del contenuto e' proibito; si prega di
comunicarlo al mittente e cancellarlo immediatamente.
12 years
Strange problem with 389 console
by Brian Bresina
Account activation and inactivation no longer seems to be working with my 389 console
system. Unfortunately, there are several people with admin rights to the ldap servers so I
am unsure if someone might have messed the server up. Currently, I can select inactivate
for an account and I will get back a box showing no errors. If I look at the account
however, only the nsmangeddisalble role and nsdisabled roles have been set. The
nsaccountlock is never added to the account. Also, if you right click on the account the
activate is always greyed out. I can manually add the nsaccountlock attribute and set it
to true. If I do this, the activate will appear when I right click on the account but when
I activate it only the roles will be removed, the nsaccountlock attribute is still in
place. Also I have noticed that there are two entries for some of the attributes if I go
to add them to an account, nsaccount lock is one of them. Sadly, this is running in a
production system, so I really need to have a way for other SAs to lock out accounts for
users that are no longer on the system with having them added attributes for each account.
Anyone know what might be going on here? Thanks.
--
"I am not completely worthless, I can always serve as a bad example."
12 years
