[389-users] Re: Strange behaviour password sync , windows 2012 r2
Any ideas on this issue? 2016-09-02 9:47 GMT+02:00 Juan Carlos Camargo <juancar...@eprinsa.es>: > I've been troubleshooting this issue. > Reinstalled password sync, certificates , verified those certificates. And > the sync started working, the sync user was able to check the remote > password. > Today, again, it's back: Binding with the user returns error 53 :( > > 09/02/16 09:32:12: Attempting to sync password for juankar > 09/02/16 09:32:12: Searching for (ntuserdomainid=juankar) > 09/02/16 09:32:12: Checking password failed for remote entry: > uid=juankar,ou=x > 09/02/16 09:32:12: Deferring password change for juankar > > and the ldap server is responding with error 53: > > [02/Sep/2016:09:32:12 +0200] conn=36 op=0 BIND dn="uid=juankar,xxx" > method=128 version=3 > [02/Sep/2016:09:32:12 +0200] conn=36 op=0 RESULT err=53 tag=97 nentries=0 > etime=0 > > With ldp , from the affected windows 2012 server and connecting to the > involved ldap server, using ssl I get no errors at all: > > res = ldap_simple_bind_s(ld, 'uid=juankar,xx', ); // v.3 > Authenticated as: 'uid=juankar,ou=sistemas,ou=ep > rinsa,ou=usuarios,dc=metaeprinsa,dc=org'. > > Going crazy. > > > > > > > > > 2016-08-30 8:44 GMT+02:00 Juan Carlos Camargo <juancar...@eprinsa.es>: > >> Thank you both for your answers. >> Sorry I should've included more lines in my log. >> Bindings with the passSync user are ok. But after that, the system tries >> to bind with the user whose password is being changed and that's when it >> fails: >> >> This is what happens when user jmml01 changes his password in Windows and >> he was connected to the failing controller: >> >> Windows: >> >> 08/30/16 08:28:56: Attempting to sync password for jmml01 >> 08/30/16 08:28:56: Searching for (ntuserdomainid=jmml01) >> 08/30/16 08:28:56: Checking password failed for remote entry: >> uid=jmml01,ou=xxx >> 08/30/16 08:28:56: Deferring password change for jmml01 >> 08/30/16 08:28:56: Backing off for 4096000ms >> >> 389ds: >> >> [30/Aug/2016:08:28:56 +0200] conn=262 fd=66 slot=66 SSL connection from >> A.B.C.D to A1.B1.C1.D1 >> [30/Aug/2016:08:28:56 +0200] conn=262 TLS1.2 256-bit AES >> [30/Aug/2016:08:28:56 +0200] conn=262 op=0 BIND >> dn="uid=winsync,ou=xx" method=128 version=3 >> [30/Aug/2016:08:28:56 +0200] conn=262 op=0 RESULT err=0 tag=97 nentries=0 >> etime=0 dn="uid=winsync,ou=x" >> [30/Aug/2016:08:28:56 +0200] conn=262 op=1 SRCH base="ou=usuarios,ou=xxx" >> scope=2 filter="(ntUserDomainId=jmml01)" attrs=ALL >> [30/Aug/2016:08:28:56 +0200] conn=262 op=1 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [30/Aug/2016:08:28:56 +0200] conn=263 fd=67 slot=67 SSL connection from >> A.B.C.D to A1.B1.C1.D1 >> [30/Aug/2016:08:28:56 +0200] conn=263 TLS1.2 256-bit AES >> [30/Aug/2016:08:28:56 +0200] conn=263 op=0 BIND dn="uid=jmml01,ou=x" >> method=128 version=3 >> [30/Aug/2016:08:28:56 +0200] conn=263 op=0 RESULT err=53 tag=97 >> nentries=0 etime=0 >> [30/Aug/2016:08:28:56 +0200] conn=263 op=1 UNBIND >> >> However if the user was connected on the other controller, the password >> will be successfully changed. I also believe it's a certificate problem , >> I'm going to review my config on that side. >> >> Regards! >> >> >> >> >> >> >> >> >> >> >> 2016-08-29 20:24 GMT+02:00 Noriko Hosoi <nho...@redhat.com>: >> >>> On 08/29/2016 02:48 AM, Juan Carlos Camargo wrote: >>> >>> Hi, 389ds'ers, >>> >>> I have two 2012 r2 domain controllers with passsync 1.6 x64 installed. >>> They're both targeting 389-ds-base-1.3.4.9-1.fc22.x86_64 . They're >>> working flawlessly. >>> I dont know if it's been a software update or a change in the domain >>> settings. Thing is today, one of the controllers has stopped sync'ing. >>> >>> Could there be a certificate issue? Did you have any chance to check >>> the cert with the tool certutil? >>> >>> Also, if you could try binding as the user "uid=juankar,ou=xxx" >>> using an ldap command over SSL, you may be able to get more info, e.g., >>> returned from the server. >>> >>> Thanks. >>> >>> Whenever I change one password in that controller, the following message >>> is logged in passsync.log: >>> >>> 08/29/16 11:30:07: Password list has 1 entries >>> 08/29/16 11:30:07: Attempting to
[389-users] Re: Strange behaviour password sync , windows 2012 r2
I've been troubleshooting this issue. Reinstalled password sync, certificates , verified those certificates. And the sync started working, the sync user was able to check the remote password. Today, again, it's back: Binding with the user returns error 53 :( 09/02/16 09:32:12: Attempting to sync password for juankar 09/02/16 09:32:12: Searching for (ntuserdomainid=juankar) 09/02/16 09:32:12: Checking password failed for remote entry: uid=juankar,ou=x 09/02/16 09:32:12: Deferring password change for juankar and the ldap server is responding with error 53: [02/Sep/2016:09:32:12 +0200] conn=36 op=0 BIND dn="uid=juankar,xxx" method=128 version=3 [02/Sep/2016:09:32:12 +0200] conn=36 op=0 RESULT err=53 tag=97 nentries=0 etime=0 With ldp , from the affected windows 2012 server and connecting to the involved ldap server, using ssl I get no errors at all: res = ldap_simple_bind_s(ld, 'uid=juankar,xx', ); // v.3 Authenticated as: 'uid=juankar,ou=sistemas,ou=eprinsa,ou=usuarios,dc= metaeprinsa,dc=org'. Going crazy. 2016-08-30 8:44 GMT+02:00 Juan Carlos Camargo <juancar...@eprinsa.es>: > Thank you both for your answers. > Sorry I should've included more lines in my log. > Bindings with the passSync user are ok. But after that, the system tries > to bind with the user whose password is being changed and that's when it > fails: > > This is what happens when user jmml01 changes his password in Windows and > he was connected to the failing controller: > > Windows: > > 08/30/16 08:28:56: Attempting to sync password for jmml01 > 08/30/16 08:28:56: Searching for (ntuserdomainid=jmml01) > 08/30/16 08:28:56: Checking password failed for remote entry: > uid=jmml01,ou=xxx > 08/30/16 08:28:56: Deferring password change for jmml01 > 08/30/16 08:28:56: Backing off for 4096000ms > > 389ds: > > [30/Aug/2016:08:28:56 +0200] conn=262 fd=66 slot=66 SSL connection from > A.B.C.D to A1.B1.C1.D1 > [30/Aug/2016:08:28:56 +0200] conn=262 TLS1.2 256-bit AES > [30/Aug/2016:08:28:56 +0200] conn=262 op=0 BIND dn="uid=winsync,ou=xx" > method=128 version=3 > [30/Aug/2016:08:28:56 +0200] conn=262 op=0 RESULT err=0 tag=97 nentries=0 > etime=0 dn="uid=winsync,ou=x" > [30/Aug/2016:08:28:56 +0200] conn=262 op=1 SRCH base="ou=usuarios,ou=xxx" > scope=2 filter="(ntUserDomainId=jmml01)" attrs=ALL > [30/Aug/2016:08:28:56 +0200] conn=262 op=1 RESULT err=0 tag=101 nentries=1 > etime=0 > [30/Aug/2016:08:28:56 +0200] conn=263 fd=67 slot=67 SSL connection from > A.B.C.D to A1.B1.C1.D1 > [30/Aug/2016:08:28:56 +0200] conn=263 TLS1.2 256-bit AES > [30/Aug/2016:08:28:56 +0200] conn=263 op=0 BIND dn="uid=jmml01,ou=x" > method=128 version=3 > [30/Aug/2016:08:28:56 +0200] conn=263 op=0 RESULT err=53 tag=97 nentries=0 > etime=0 > [30/Aug/2016:08:28:56 +0200] conn=263 op=1 UNBIND > > However if the user was connected on the other controller, the password > will be successfully changed. I also believe it's a certificate problem , > I'm going to review my config on that side. > > Regards! > > > > > > > > > > > 2016-08-29 20:24 GMT+02:00 Noriko Hosoi <nho...@redhat.com>: > >> On 08/29/2016 02:48 AM, Juan Carlos Camargo wrote: >> >> Hi, 389ds'ers, >> >> I have two 2012 r2 domain controllers with passsync 1.6 x64 installed. >> They're both targeting 389-ds-base-1.3.4.9-1.fc22.x86_64 . They're >> working flawlessly. >> I dont know if it's been a software update or a change in the domain >> settings. Thing is today, one of the controllers has stopped sync'ing. >> >> Could there be a certificate issue? Did you have any chance to check the >> cert with the tool certutil? >> >> Also, if you could try binding as the user "uid=juankar,ou=xxx" using >> an ldap command over SSL, you may be able to get more info, e.g., returned >> from the server. >> >> Thanks. >> >> Whenever I change one password in that controller, the following message >> is logged in passsync.log: >> >> 08/29/16 11:30:07: Password list has 1 entries >> 08/29/16 11:30:07: Attempting to sync password for juankar >> 08/29/16 11:30:07: Searching for (ntuserdomainid=juankar) >> 08/29/16 11:30:07: Checking password failed for remote entry: >> uid=juankar,ou=xxx >> 08/29/16 11:30:07: Deferring password change for juankar >> >> and in the server access log I get ldap bind err=53 when the passsync >> user tries to check the password: >> >> [29/Aug/2016:11:30:07 +0200] conn=276 fd=67 slot=67 SSL connection from >> >> [29/Aug/2016:11:30:07 +0200] conn=276 TLS1.2 128-bit AES >> [29/Aug/2016:11:30:07 +0200] co
[389-users] Re: Strange behaviour password sync , windows 2012 r2
Thank you both for your answers. Sorry I should've included more lines in my log. Bindings with the passSync user are ok. But after that, the system tries to bind with the user whose password is being changed and that's when it fails: This is what happens when user jmml01 changes his password in Windows and he was connected to the failing controller: Windows: 08/30/16 08:28:56: Attempting to sync password for jmml01 08/30/16 08:28:56: Searching for (ntuserdomainid=jmml01) 08/30/16 08:28:56: Checking password failed for remote entry: uid=jmml01,ou=xxx 08/30/16 08:28:56: Deferring password change for jmml01 08/30/16 08:28:56: Backing off for 4096000ms 389ds: [30/Aug/2016:08:28:56 +0200] conn=262 fd=66 slot=66 SSL connection from A.B.C.D to A1.B1.C1.D1 [30/Aug/2016:08:28:56 +0200] conn=262 TLS1.2 256-bit AES [30/Aug/2016:08:28:56 +0200] conn=262 op=0 BIND dn="uid=winsync,ou=xx" method=128 version=3 [30/Aug/2016:08:28:56 +0200] conn=262 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=winsync,ou=x" [30/Aug/2016:08:28:56 +0200] conn=262 op=1 SRCH base="ou=usuarios,ou=xxx" scope=2 filter="(ntUserDomainId=jmml01)" attrs=ALL [30/Aug/2016:08:28:56 +0200] conn=262 op=1 RESULT err=0 tag=101 nentries=1 etime=0 [30/Aug/2016:08:28:56 +0200] conn=263 fd=67 slot=67 SSL connection from A.B.C.D to A1.B1.C1.D1 [30/Aug/2016:08:28:56 +0200] conn=263 TLS1.2 256-bit AES [30/Aug/2016:08:28:56 +0200] conn=263 op=0 BIND dn="uid=jmml01,ou=x" method=128 version=3 [30/Aug/2016:08:28:56 +0200] conn=263 op=0 RESULT err=53 tag=97 nentries=0 etime=0 [30/Aug/2016:08:28:56 +0200] conn=263 op=1 UNBIND However if the user was connected on the other controller, the password will be successfully changed. I also believe it's a certificate problem , I'm going to review my config on that side. Regards! 2016-08-29 20:24 GMT+02:00 Noriko Hosoi <nho...@redhat.com>: > On 08/29/2016 02:48 AM, Juan Carlos Camargo wrote: > > Hi, 389ds'ers, > > I have two 2012 r2 domain controllers with passsync 1.6 x64 installed. > They're both targeting 389-ds-base-1.3.4.9-1.fc22.x86_64 . They're > working flawlessly. > I dont know if it's been a software update or a change in the domain > settings. Thing is today, one of the controllers has stopped sync'ing. > > Could there be a certificate issue? Did you have any chance to check the > cert with the tool certutil? > > Also, if you could try binding as the user "uid=juankar,ou=xxx" using > an ldap command over SSL, you may be able to get more info, e.g., returned > from the server. > > Thanks. > > Whenever I change one password in that controller, the following message > is logged in passsync.log: > > 08/29/16 11:30:07: Password list has 1 entries > 08/29/16 11:30:07: Attempting to sync password for juankar > 08/29/16 11:30:07: Searching for (ntuserdomainid=juankar) > 08/29/16 11:30:07: Checking password failed for remote entry: > uid=juankar,ou=xxx > 08/29/16 11:30:07: Deferring password change for juankar > > and in the server access log I get ldap bind err=53 when the passsync user > tries to check the password: > > [29/Aug/2016:11:30:07 +0200] conn=276 fd=67 slot=67 SSL connection from > > [29/Aug/2016:11:30:07 +0200] conn=276 TLS1.2 128-bit AES > [29/Aug/2016:11:30:07 +0200] conn=276 op=0 BIND > dn="uid=juankar,ou=xxx" method=128 version=3 > [29/Aug/2016:11:30:07 +0200] conn=276 op=0 RESULT err=53 tag=97 nentries=0 > etime=0 > [29/Aug/2016:11:30:07 +0200] conn=276 op=1 UNBIND > [29/Aug/2016:11:30:07 +0200] conn=276 op=1 fd=67 closed - U1 > [29/Aug/2016:11:30:07 +0200] conn=275 op=2 UNBIND > > Any hints? Could be a problem with certificates? They're both using the > same CA (windows CA Cert serv is installed in one of the DCs) > Regards! > > > > > > > > > -- > 389-users mailing > list389-users@lists.fedoraproject.orghttps://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org > > > > -- > 389-users mailing list > 389-users@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/389-users@ > lists.fedoraproject.org > > -- 389-users mailing list 389-users@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
[389-users] Strange behaviour password sync , windows 2012 r2
Hi, 389ds'ers, I have two 2012 r2 domain controllers with passsync 1.6 x64 installed. They're both targeting 389-ds-base-1.3.4.9-1.fc22.x86_64 . They're working flawlessly. I dont know if it's been a software update or a change in the domain settings. Thing is today, one of the controllers has stopped sync'ing. Whenever I change one password in that controller, the following message is logged in passsync.log: 08/29/16 11:30:07: Password list has 1 entries 08/29/16 11:30:07: Attempting to sync password for juankar 08/29/16 11:30:07: Searching for (ntuserdomainid=juankar) 08/29/16 11:30:07: Checking password failed for remote entry: uid=juankar,ou=xxx 08/29/16 11:30:07: Deferring password change for juankar and in the server access log I get ldap bind err=53 when the passsync user tries to check the password: [29/Aug/2016:11:30:07 +0200] conn=276 fd=67 slot=67 SSL connection from [29/Aug/2016:11:30:07 +0200] conn=276 TLS1.2 128-bit AES [29/Aug/2016:11:30:07 +0200] conn=276 op=0 BIND dn="uid=juankar,ou=xxx" method=128 version=3 [29/Aug/2016:11:30:07 +0200] conn=276 op=0 RESULT err=53 tag=97 nentries=0 etime=0 [29/Aug/2016:11:30:07 +0200] conn=276 op=1 UNBIND [29/Aug/2016:11:30:07 +0200] conn=276 op=1 fd=67 closed - U1 [29/Aug/2016:11:30:07 +0200] conn=275 op=2 UNBIND Any hints? Could be a problem with certificates? They're both using the same CA (windows CA Cert serv is installed in one of the DCs) Regards! -- 389-users mailing list 389-users@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
Re: [389-users] Bug 1251288, 389-ds-base-1.3.4.4-1.fc22.x86_64 , Fedora 22
German, I'ven testing here and there, preparing your logs and such.. to finally realize there's an old master server that's affected by the bug :( All changes forwarded by this server to my consumer replicas do not modify an attribute value when this attribute is deleted in the source object. I'm upgrading it to a newer version while I write this mail as an apology. Sorry and thanks again for your help. Have a nice day! *Tfn: 957-211157* 2015-10-15 10:01 GMT+02:00 German Parente <gpare...@redhat.com>: > Hi Juan Carlos, > > the bug you are mentioning was due to a regression in RHEL6 only, > introduced when backporting a specific patch. > > So, RHEL7 versions should not be affected. It could be a new bug ? > Do you manage to reproduce it systematically ? > > It could be good to set replication log level ( nsslapd-errorlog-level: > 8192 ), reproduce the bug and send us the error logs in supplier and > consumer. > > Thanks and regards, > > German. > > ----- Original Message - > > From: "Juan Carlos Camargo" <juancar...@eprinsa.es> > > To: "General discussion list for the 389 Directory server project." < > 389-users@lists.fedoraproject.org> > > Sent: Thursday, October 15, 2015 9:50:32 AM > > Subject: [389-users] Bug 1251288, 389-ds-base-1.3.4.4-1.fc22.x86_64 , > Fedora 22 > > > > Listers, > > > > Do you know if this bug has been fixed on version 1.3.4.4-1 running on > Fedora > > 22 x64? > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1251288 > > > > I'm facing the same behaviour: attribute deletion is not forwarded to > > consumer replicas. Master works fine, but not consumer replicas. > > Regards! > > > > > > Tfn: 957-211157 > > > > > > -- > > 389 users mailing list > > 389-users@lists.fedoraproject.org > > https://admin.fedoraproject.org/mailman/listinfo/389-users > -- > 389 users mailing list > 389-users@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] Bug 1251288, 389-ds-base-1.3.4.4-1.fc22.x86_64 , Fedora 22
German, Thanks for the quick response. Sure, I'm going to set that log level and come back with the results. Regards! *Tfn: 957-211157* 2015-10-15 10:01 GMT+02:00 German Parente <gpare...@redhat.com>: > Hi Juan Carlos, > > the bug you are mentioning was due to a regression in RHEL6 only, > introduced when backporting a specific patch. > > So, RHEL7 versions should not be affected. It could be a new bug ? > Do you manage to reproduce it systematically ? > > It could be good to set replication log level ( nsslapd-errorlog-level: > 8192 ), reproduce the bug and send us the error logs in supplier and > consumer. > > Thanks and regards, > > German. > > ----- Original Message - > > From: "Juan Carlos Camargo" <juancar...@eprinsa.es> > > To: "General discussion list for the 389 Directory server project." < > 389-users@lists.fedoraproject.org> > > Sent: Thursday, October 15, 2015 9:50:32 AM > > Subject: [389-users] Bug 1251288, 389-ds-base-1.3.4.4-1.fc22.x86_64 , > Fedora 22 > > > > Listers, > > > > Do you know if this bug has been fixed on version 1.3.4.4-1 running on > Fedora > > 22 x64? > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1251288 > > > > I'm facing the same behaviour: attribute deletion is not forwarded to > > consumer replicas. Master works fine, but not consumer replicas. > > Regards! > > > > > > Tfn: 957-211157 > > > > > > -- > > 389 users mailing list > > 389-users@lists.fedoraproject.org > > https://admin.fedoraproject.org/mailman/listinfo/389-users > -- > 389 users mailing list > 389-users@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
[389-users] Bug 1251288, 389-ds-base-1.3.4.4-1.fc22.x86_64 , Fedora 22
Listers, Do you know if this bug has been fixed on version 1.3.4.4-1 running on Fedora 22 x64? https://bugzilla.redhat.com/show_bug.cgi?id=1251288 I'm facing the same behaviour: attribute deletion is not forwarded to consumer replicas. Master works fine, but not consumer replicas. Regards! *Tfn: 957-211157* -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] Review 389-ds install/upgrade procedures and requisites on http://directory.fedoraproject.org/docs/389ds/download.html
Thanks for your comments and updates. *Tfn: 957-211157 / 650932877* 2015-03-10 1:01 GMT+01:00 Rich Megginson rmegg...@redhat.com: On 03/09/2015 05:54 PM, Rich Megginson wrote: On 03/09/2015 04:44 PM, Robert Viduya wrote: On Mar 9, 2015, at 5:30 PM, Noriko Hosoi nho...@redhat.com wrote: Hello, On 03/09/2015 02:18 PM, Robert Viduya wrote: I'm in the same boat. We, as an enterprise, have standardized on RHEL6 as our OS, with RHEL7 only on the horizon. Switching to either Fedora or CentOS isn't an option. But the only official 389 release for RHEL6 is years old. I reported a bug about a year ago, 47739, that's been fixed since 1.2.11.26. But only 1.2.11.15 is available for RHEL6. So, yes, there's at least one fix that we need that isn't available to us. But really, there's tons of bug fixes and features that have come out since then. The longer we're held back, the harder it will be to get our user base to adapt to all the new features once we do upgrade. The fix for the ticket 47739 is included in 389-ds-base-1.2.11.15-32 and newer and released on October 13, 2014 for RHEL-6.6. Sorry about missing the announcement. Could it be possible to upgrade your RHEL6 bits to the latest 389-ds-base-1.2.11.15-50.el6? Ok, so the EL6 dash releases have fixes for stuff that isn’t in the base 1.2.11.15 release. Is that detailed somewhere? Yes, I can upgrade to -50, but I and my managers would want to know what’s changed. As a RHEL customer, you have access to the portal, so you can go to https://access.redhat.com/downloads/content/rhel---6/x86_64/168/389-ds-base/1.2.11.15-50.el6_6/x86_64/fd431d51/package and look at the changelog for the 389-ds-base package. This has descriptions of the changes along with bugzilla bug number and sometimes 389 trac ticket numbers. There's probably some way to get a list of all errata for the 389-ds-base package in RHEL6, but I can't seem to find it. Found it. Unfortunately, it is not broken down by package. But if you go to this page and search for 389-ds-base you can find them. The erratas have the full documentation, bug/enhancement descriptions, and package versions. https://rhn.redhat.com/errata/rhel-server-6-errata.html For example, here is the latest errata released on March 5, 2015: https://rhn.redhat.com/errata/RHSA-2015-0628.html -- 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
[389-users] Review 389-ds install/upgrade procedures and requisites on http://directory.fedoraproject.org/docs/389ds/download.html
I'd like to see an updated install/upgrade procedure for 389-ds. The info on the web page is outdated, links for coprs are not working either , maybe they are not valid anymore. As a user of Centos6x I'm somehow lost when I see versions of the product coming out whereas my servers are stuck with the older ones. Should I make the move to Fedora? *Tfn: 957-211157 / 650932877* -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
[389-users] Password policy applied to a group
389ds'ers,I'm struggling to find the best way to apply a password policy only to members of a group, the rest having either the global or user/local policy. I have a number of users whose password should never expire , but those users live in different OU's, dont even share a parent branch. Do you think a CoS might help? Which do you think would be the best way to implement this?Thanks!-- Juan Carlos Camargo Carrillo.@jcarloscamargo957-211157 ,650932877-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] Self Service Portal
We've been using this:http://code.google.com/p/pwm/De: "Paul Robert Marino" prmari...@gmail.comPara: "General discussion list for the 389 Directory server project." 389-users@lists.fedoraproject.orgEnviados: Lunes, 29 de Julio 2013 2:20:41Asunto: Re: [389-users] Self Service PortalIn the inexpensive commercial zone I've used something called password manager pro which also maintains per user and enterprise wide password vaults.The other thing I've done is written simple Perl CGI pages that do the email confirmation thing using a double email system the first using an auth code stored with a short timeout in memcached for confirmation then emails a second email includes GPG encrypted temporary random password with the GPG decryption code on the page from the first approval confirmation page.-- Sent from my HP Pre3On Jul 26, 2013 10:56, harry.dev...@faa.gov harry.dev...@faa.gov wrote: We use Self Service Password from the LDAP Tool Box project. Works pretty well for us. http://ltb-project.org/wiki/documentation/self-service-password Harry From:Tom Tucker tktuc...@gmail.com To:389-users@lists.fedoraproject.orgDate:07/26/2013 10:48 AMSubject:[389-users] Self Service PortalSent by:389-users-boun...@lists.fedoraproject.org Any recommendations on a commercial or open source web based self service portal to allow 389 DS users the ability to recover or change their password? Thanks, Tom-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users --389 users mailing list389-users@lists.fedoraproject.orghttps://admin.fedoraproject.org/mailman/listinfo/389-users-- Juan Carlos Camargo Carrillo.@jcarloscamargo957-211157 ,650932877-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
[389-users] winsync: differences between 1.2.11.15 and 1.3
Hi 389ers,I have a lab scenario with one server running version 1.3 on Fedora19. My production servers still use 1.2.11.15 and run on CentOS. I've created oneway sync agreements FROM Windows2003 , in both cases with the same params: windows sync user, windows host, ds subtree and windows subtree. But I've noticed that in version 1.3 sync does not work, all users are reported to be "out of scope" even when the same sAMAccountName/uid is found. Ex:v1.3"[18/Jul/2013:12:59:15 +0200] NSMMReplicationPlugin - agmt="cn=ad5" (ad5:389): windows_process_dirsync_entry: windows inbound entry CN= has the same name as local entry uid= but the windows entry is out of the scope of the sync subtree [dc=DOMAIN] - if you want these entries to be in sync, add the ntUser/ntGroup objectclass and required attributes to the local entry, and move the windows entry into scope"v1.2.11.15[18/Jul/2013:13:31:00 +0200] NSMMReplicationPlugin - agmt="cn=ad5" (ad5:389): map_entry_dn_inbound: looking for local entry matching AD entry [CN=][18/Jul/2013:13:31:00 +0200] NSMMReplicationPlugin - agmt="cn=ad5" (ad5:389): map_entry_dn_inbound: looking for local entry by guid [155e86afca9f2141af71624d7f55a44c][18/Jul/2013:13:31:00 +0200] NSMMReplicationPlugin - agmt="cn=ad5" (ad5:389): map_entry_dn_inbound: found local entry [uid=]Sorry about the different timestamps, but the user under was the same in both cases. So, same agreement in version 1.2.11.15 syncs the users (from Windows always) perfectly. I've deleted and recreated the agreements in both sides, just in case I mispelled something,but still the same results. What has changed , or better, where did I go wrong?Regards!-- Juan Carlos Camargo Carrillo.@jcarloscamargo957-211157 ,650932877-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
[389-users] Problems upgrading from PassSync 1.4 to PassSync 1.5
Hi list,I was expecting these new changes in PassSync (moreover those related to the 8th bit handling) , so congrats for the advances. I've found the following when I've tried the upgrade the product on one of my 2003 32bits windows controllers:1.- I cannot simply update. The installed version was 1.4. A message tells me to uninstall the previous version and reinstall.2.- If I uninstall the previous version, restart and install 1.5 from scratch, the installer stops when it tries to start the PassSync service , the rolls back the setup and does nothing. Error 1603 appears in the event viewer. I've troubleshooted this error according to Microsofts kb but none of the symptoms match my scenario.I've tried the upgrade of my other two windows2003 x32 controllers , but I'm asked to upgrade windows installer first. All in all , could those problems relate to an old windows installer version? I havent updated it yet, just needed to make sure first. Could also be related to the way the 1.5 .msi was generated?Regards!-- Juan Carlos Camargo Carrillo.@jcarloscamargo957-211157 ,650932877-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] Problems upgrading from PassSync 1.4 to PassSync 1.5
Hi,thanks for the reply.We cannot make the upgrade to 2008 at the moment. I'll wait (*sobs*).De: "Rich Megginson" rmegg...@redhat.comPara: "General discussion list for the 389 Directory server project." 389-users@lists.fedoraproject.orgCC: "Juan Carlos Camargo" juancar...@eprinsa.esEnviados: Jueves, 27 de Junio 2013 18:09:13Asunto: Re: [389-users] Problems upgrading from PassSync 1.4 to PassSync 1.5On 06/27/2013 03:28 AM, Juan Carlos Camargo wrote:Hi list,I was expecting these new changes in PassSync (moreover those related to the 8th bit handling) , so congrats for the advances. I've found the following when I've tried the upgrade the product on one of my 2003 32bits windows controllers:1.- I cannot simply update. The installed version was 1.4. A message tells me to uninstall the previous version and reinstall.2.- If I uninstall the previous version, restart and install 1.5 from scratch, the installer stops when it tries to start the PassSync service , the rolls back the setup and does nothing. Error 1603 appears in the event viewer. I've troubleshooted this error according to Microsofts kb but none of the symptoms match my scenario.I've tried the upgrade of my other two windows2003 x32 controllers , but I'm asked to upgrade windows installer first. All in all , could those problems relate to an old windows installer version? I havent updated it yet, just needed to make sure first. Could also be related to the way the 1.5 .msi was generated? We are having problems with 1.5 on 2003. I don't suppose you can upgrade to 2008 R2? If not, then in the meantime continue to use PassSync 1.4 Regards!-- Juan Carlos Camargo Carrillo.@jcarloscamargo957-211157 ,650932877-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users-- Juan Carlos Camargo Carrillo.@jcarloscamargo957-211157 ,650932877-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
[389-users] Evaluating 1.2.11.6 on Fedora17: nsds5ReplicaEnabled
Hi there,One of the features of version 1.2.11.6 that caught my eye was the ability to enable/disable replication agreements. I've installed a copy on one of my lab machines, install went on flawlessly, but I seem to be unable to find where to apply the nsds5ReplicaEnabled attribute. I've tried adding it to the nsds5ReplicationAgreement object (same way as when I add the onewaysync attr) but I cant find it. Has it already been implemented? Not pushing, simply investigating :)Regards!-- Juan Carlos Camargo Carrillo 957-211157 , 650932877-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] Sync with active directory doubts
Alberto,I had a 389ds server with more than 70 windows sync agreements (for a first user reconciliation). Each of them to different AD domain controllers and different domains. No problems at all. But I wouldnt try it if the AD domain was the same regardless of the number of controllers that held it (your case).Regards!De: "Alberto Viana" alberto...@gmail.comPara: 389-users@lists.fedoraproject.orgEnviados: Jueves, 17 de Mayo 2012 23:26:04Asunto: [389-users] Sync with active directory doubtsHello,I have 2 389 DS servers a 6 AD servers and i read this on red hat documetation about windows replication:"There can only be a single sync agreement between the Directory Server environment and the Active Directory environment. Multiple sync agreements to the same Active Directory domain can create entry conflicts." Now I´m trying the following scenario: server2 389(consumer) - replication - server1 389 - replication - Server1 AD Server2 AD Server3 AD So in my master 389 server (server1) I have 3 agreements with 3 different AD servers. It´s not clear if "Active Directory environment" means just one AD server. Just to make clear that the 6 AD servers are in the same Active Directory domain and all replicate information with each other. I have this number of AD servers because they are located in different places(physically). Can this scenario create entry conflitc? Am I suppose to sync with just one AD server? Thanks, Alberto Viana --389 users mailing list389-users@lists.fedoraproject.orghttps://admin.fedoraproject.org/mailman/listinfo/389-users-- Juan Carlos Camargo Carrillo 957-211157 , 650932877-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
[389-users] Creating windows sync agreements via ldif
Hi,I'm making a script to recreate a windows sync agreement in my server and I've found that even the agreement is created and started, no sync in fact ever occurs. I've noticed also that the "cookie" attribute "nsds7DirsyncCookie" is never created for the sync object even after a full resync. No errors are shown , everthing looks normal. If I create the agreement via console then everything works as expected. Can you help me? Probably I'm missing something but cannot figure it out.Regards!.ldif file:cn: cn=adamuz,cn=replica,cn=dc\3Dmetaeprinsa\2Cdc\3Dorg,cn=mapping tree,cn=configchangetype: addobjectClass: topobjectClass: nsDSWindowsReplicationAgreementdescription: adamuzcn: adamuznsds7WindowsReplicaSubtree: dc=adamuz,dc=localnsds7DirectoryReplicaSubtree: ou=adamuz,ou=ayuntamientos,ou=usuarios,dc=metaeprinsa,dc=orgnsds7NewWinUserSyncEnabled: onnsds7NewWinGroupSyncEnabled: offnsds7WindowsDomain: adamuz.localnsDS5ReplicaRoot: dc=metaeprinsa,dc=orgnsDS5ReplicaHost: adamuzhost.eprnsDS5ReplicaPort: 389nsDS5ReplicaBindDN: cn of proxy usernsDS5ReplicaTransportInfo: LDAPnsDS5ReplicaCredentials: pass of proxy usernsds5BeginReplicaRefresh: start-- Juan Carlos Camargo Carrillo 957-211157 , 650932877-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] New Zenoss ZenPack to monitor 389 (and other cn=monitor) DS
Hi, thanks for the pack. On ZenOSS3.2.1 I get the message 'NoneType' object has no attribute 'clone' when I try to install it. Regards! - Mensaje original - De: Alan Milligan alan.milli...@last-bastion.net Para: 389-users@lists.fedoraproject.org Enviados: Lunes, 12 de Marzo 2012 8:06:50 Asunto: [389-users] New Zenoss ZenPack to monitor 389 (and other cn=monitor) DS Hi, I recently released ZenPacks.lbn.LDAPMonitor for large-scale DS installations. It's available on PyPi: http://pypi.python.org/pypi/ZenPacks.lbn.LDAPMonitor/3.0.3 We do enterprise LDAP at: http://linux.last-bastion.net/LBN/up2date/aim/13 We do enterprise Zenoss monitoring at: http://linux.last-bastion.net/LBN/monitor/aim/13 These RPM packages also run on RHEL6/CentOS6, and you can find our BastionLinux on AWS/EC2, and we do make the systems available on VMWare/vSphere (and other virtualisation) platforms. Please do feel free to download and use the ZenPack. If you're using other cn=monitor LDAP's, please do let us know and we'll try and ensure compatibility with our RRD graphs. Alan -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- -- J u an Carlos Camargo Carrillo 957-211157 , 650932877 attachment: logo.jpg-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] win sync limitation
Is there a way to use the IPA winsync plugin with 389ds? In general terms, there are some features of IPA that I'd like to use without changing the ldap server. El vie, 24-06-2011 a las 15:04 -0600, Rich Megginson escribió: On 06/24/2011 02:52 PM, solarflow99 wrote: I just noticed that a user created from windows cannot login on linux because they have no posixuser attributes. If there was 1 feature that would be a nice to have, this would be it. IPA winsync has this feature. -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] About Kerberos and dirsrv
This link may help: http://blogs.oracle.com/wfiveash/entry/the_rough_guide_to_configuring El jue, 16-06-2011 a las 18:23 +0900, 夜神 岩男 escribió: On Thu, 2011-06-16 at 10:52 +0200, Gioachino Bartolotta wrote: Hi Juan! It's possible to do a bash script to import existing users into kerberos?? In my ldap I have already 2000 users ... Thanks It is almost always possible to do a bash script to perform these sort of tasks. This is one of the best reasons to learn how if you aren't already good at it. If your sed/awk skills are well developed, this is an excellent, repeatable, adaptable solution. I will be facing a similar problem in the mid-term and if you have written a basic script by then I'd love to get a copy. If not, I will be writing one myself in a few months. This problem is probably frequent enough that someone may have already tackled it with a smart script... ? Anyone? -Iwao -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] About Kerberos and dirsrv
To your former question, yes. Basically, and assuming you have
experience with openldap:
0.- Backup your current installation or create a new 389ds instance.
1.- Configure the kdc to use ldap as a database backend.
2.- Get the 60kerberos.ldif from freeIPA (it works out of the box with
389ds) and copy it to the instance's schema folder. Add
krb5principalname to your suffix database indexes. Restart dirsrv.
3.- Create the realm with kdb5_ldap_util.
4.- Create kerberos principals for your users
4.1 for new users , addprinc principal
4.2 for existing ldap users, addprinc -x dn=full dn of the user
principal. This will add kerberos attributes to an existing ldap user.
Regards!
El mié, 15-06-2011 a las 13:10 +0200, Gioachino Bartolotta escribió:
Hi !!
Yes, I want to use 389ds as a backend for kerberos.
So, everything will work just if I import the schemas on 389ds?
Another question. I have actually 2 389ds configured with multimaster
replica, and on each server there is a kdc (1 master and 1 slave).
I have to copy the same keytab on both servers?
Have I also to change the file /etc/sysconfig/saslauthd with these
parameters??
MECH_OPTIONS=
THREADS=5
START=yes
MECHANISMS=ldap
OPTIONS=-m /var/run/saslauthd
Then ... I am missing something else??
Thank you.
2011/6/15 Juan Carlos Camargo Carrillo juan...@eprinsa.es:
Hi,
It depends. If you want to use 389ds as a Kerberos database backend then
you should import the schema into the directory and yes, you'll need to
create principals or modify the existing ldap entries to accept kerberos
attributes, as you've said you did with openldap. I've done it with my
389ds lab and it works.
El mié, 15-06-2011 a las 12:08 +0200, Gioachino Bartolotta escribió:
Hi all,
I have a problem in setup kerberos with 389 and I tried to do using
the documents available on 389 site and RedHat.
I followed everything, but I am unable to get the initial ticket from
kerberos. Have I to add these records as I have always done with
openldap??
dn: ou=KerberosPrincipals,ou=Users,dc=domain
ou: KerberosPrincipals
objectClass: top
objectClass: organizationalUnit
dn:
krb5PrincipalName=ldapmaster/admin@DOMAN,ou=KerberosPrincipals,ou=Users,dc=domain
objectClass: top
objectClass: person
objectClass: krb5Principal
objectClass: krb5KDCEntry
krb5PrincipalName: ldapmaster/admin@DOMAIN
krb5KeyVersionNumber: 1
krb5MaxLife: 86400
krb5MaxRenew: 604800
krb5KDCFlags: 126
cn: ldapmaster/admin@domain
sn: ldapmaster/admin@domain
userPassword: {MD5}5S2YxFmBmhF3WTbY37t5KQ==
Thanks
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] memberOf attribute and plugin behaviour between sub-suffixes.
Thanks for answering. Here you go: # MemberOf Plugin, plugins, config dn: cn=MemberOf Plugin,cn=plugins,cn=config objectClass: top objectClass: nsSlapdPlugin objectClass: extensibleObject cn: MemberOf Plugin nsslapd-pluginPath: libmemberof-plugin nsslapd-pluginInitfunc: memberof_postop_init nsslapd-pluginType: postoperation nsslapd-pluginEnabled: on nsslapd-plugin-depends-on-type: database memberofgroupattr: uniqueMember memberofattr: memberOf nsslapd-pluginId: memberof nsslapd-pluginVersion: 1.2.8.2 nsslapd-pluginVendor: 389 Project nsslapd-pluginDescription: memberof plugin El vie, 20-05-2011 a las 08:53 -0600, Rich Megginson escribió: On 05/20/2011 01:56 AM, Juan Carlos Camargo Carrillo wrote: Is the memberOf attribute handling by the memberOf plugin limited to objects inside the same subsuffix? If it's not planned as such please doublecheck this behaviour within the following scenario: - suffix dc=directory,dc=org - subsuffix ou=users,dc=directory,dc=org - subsuffix ou=testing,ou=users,dc=directory,dc=org We have then three databases. They're not replicated. The membefOf plugin works only with elements (users and groups) that belong to the same subsuffix. But not between different subsuffixes. As such, if you make a user of ou=testing... member of a group of ou=users then the plugin will not populate the memberOf attribute for that user. The same here: - subsuffix ou=users,dc=example,dc=com - subsuffix ou=grupos,dc=example,dc=com Here the plugin wont work either. If you make a user inside ou=users member of a group inside ou=groups then the value of memberOf wont be populated. If you set debug to heavy trace, you'll see that the plugin runs in every situation but: 1.- when the objects belong to the same subsuffix, adding one membership triggers the memberOf plugin to ldap replace values, which is correct. 2.- when the objects belong to different subsuffix, adding one membership triggers the memberOf plugin to ldap REMOVE values, which amazes me. Can you post your memberOf plugin configuration? DS 1.2.8.2 CentOS5. -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
[389-users] memberOf attribute and plugin behaviour between sub-suffixes.
Is the memberOf attribute handling by the memberOf plugin limited to objects inside the same subsuffix? If it's not planned as such please doublecheck this behaviour within the following scenario: - suffix dc=directory,dc=org - subsuffix ou=users,dc=directory,dc=org - subsuffix ou=testing,ou=users,dc=directory,dc=org We have then three databases. They're not replicated. The membefOf plugin works only with elements (users and groups) that belong to the same subsuffix. But not between different subsuffixes. As such, if you make a user of ou=testing... member of a group of ou=users then the plugin will not populate the memberOf attribute for that user. The same here: - subsuffix ou=users,dc=example,dc=com - subsuffix ou=grupos,dc=example,dc=com Here the plugin wont work either. If you make a user inside ou=users member of a group inside ou=groups then the value of memberOf wont be populated. If you set debug to heavy trace, you'll see that the plugin runs in every situation but: 1.- when the objects belong to the same subsuffix, adding one membership triggers the memberOf plugin to ldap replace values, which is correct. 2.- when the objects belong to different subsuffix, adding one membership triggers the memberOf plugin to ldap REMOVE values, which amazes me. DS 1.2.8.2 CentOS5. -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] 1.2.8 Windows sync agreement initialization
No prob, I had a backup at hand. I've updated the product with the latest alfpha release and the problem persists. Also tried with 1.2.7 on Centos5. And to add more, I've noticed that everytime I delete a windows sync agreement, the nslapd service woes. El mar, 08-02-2011 a las 14:27 +0100, Carsten Grzemba escribió: Sorry, than I'am wrong! Then there is another problem and do not change in dse.ldif! Regards, Carsten - Ursprüngliche Nachricht - Von: Juan Carlos Camargo Carrillo juan...@eprinsa.es Datum: Dienstag, 8. Februar 2011, 14:08 Betreff: Re: [389-users] 1.2.8 Windows sync agreement initialization An: General discussion list for the 389 Directory server project. 389-users@lists.fedoraproject.org Hi, I'm not using any particular winsync plugin different that the one that comes with the product. The error message begins with: NSMMReplicationPlugin - agmt=cn=windowsagreement (myserver:389): Replica has no update vector. It has never been initialized. According to this I presume I'm using the NSMMReplicationPlugin but I cant find it in the dse.ldif file. Also I've searched for the line nsslapd-plugin-depends-on-name and found it on the Legacy Replication Plugin DN. To give a try, I've removed it from there and still the problem continues to appear. Thanks! El mar, 08-02-2011 a las 13:28 +0100, Carsten Grzemba escribió: These modifications can you make in the /etc/dirserv/slap-instance/ds.ldif. The ns-slapd process has to be stopped! Which winsync plugin you are use? In the dse.ldif look for the entry like that: dn: cn=test-winsync,cn=plugins,cn=config there remove nsslapd-plugin-depends-on-named: Multimaster Replication Plugin if exists. and look for the entry: dn: cn=Multimaster Replication Plugin,cn=plugins,cn=config there add: nsslapd-plugin-depends-on-named: test Winsync AP and start the ns-slapd process. If you enable 'Replication' and 'Plug-ins' for the error logfile, you can see if the winsync API functions are called. These are at least every 5 min (winsyncinterval): [08/Feb/2011:11:16:57 +0100] test-winsync - -- test_winsync_begin_update_cb -- begin [08/Feb/2011:11:16:57 +0100] test-winsync - -- test_winsync_begin_update_cb -- end [08/Feb/2011:11:16:57 +0100] test-winsync - -- test_winsync_end_update_cb -- begin [08/Feb/2011:11:16:57 +0100] test-winsync - -- test_winsync_end_update_cb -- end even if there are no changes. Regards Carsten - Ursprüngliche Nachricht - Von: Juan Carlos Camargo Carrillo juan...@eprinsa.es Datum: Dienstag, 8. Februar 2011, 12:56 Betreff: Re: [389-users] 1.2.8 Windows sync agreement initialization An: General discussion list for the 389 Directory server project. 389-users@lists.fedoraproject.org Hi Carten, Thanks for your answer. In my case there's not a testing plugin but the one that governs the win synchronization. As I am a sort of deep newbie can you tell me where should I made those modifications in an out-of-the box configuration, so I can retry your guidelines? Regards! El mar, 08-02-2011 a las 12:17 +0100, Carsten Grzemba escribió: No, it is not a normaly behaviour. I had a similar problem because my winsync plugin was not registered after a restart. I have fixed the problem that I have changed the plugin dependencies. But I do not know if it is the right way. see thread [389-devel] Problem using winsync API in December 2010: ... I have removed from win sync plugin: nsslapd-plugin-depends-on-named: Multimaster Replication Plugin from the plugin configuration, and instead added on the Multimaster Plugin config nsslapd-plugin-depends-on-named: test Winsync API ... Regards Carsten - Ursprüngliche Nachricht - Von: Juan Carlos Camargo Carrillo juan...@eprinsa.es Datum: Dienstag, 8. Februar 2011, 11:49 Betreff: [389-users] 1.2.8 Windows sync agreement initialization An: 389-users@lists.fedoraproject.org Hi, I'm running 389-ds version 1.2.8 on CentOS 5x and configured a windows sync agreement against a 2003 active directory server. Everything works as expected. However, everytime I restart the directory server (service dirsrv restart) I need to reinitialize the windows agreement. Messages such as Replica
