[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 : > 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 : > >> 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 : >> >>> 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 pas
[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 : > 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 : > >> 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 1
[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 : > 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 : > 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" > > 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 : > 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" > > 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 : > 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 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" Para: "General discussion list for the 389 Directory server project." <389-users@lists.fedoraproject.org>Enviados: 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 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 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
Re: [389-users] winsync: differences between 1.2.11.15 and 1.3
Rich,Thanks for replying.The entry CN= is the same in both cases and inside the scope (inside the windows subtree). The agreements are the same in both servers:v1.2.11.15dn: cn=ad5,cn=replica,cn=dc\3Dmetaeprinsa\2Cdc\3Dorg,cn=mapping tree,cn=configobjectClass: topobjectClass: nsDSWindowsReplicationAgreementdescription: ad5cn: ad5nsds7WindowsReplicaSubtree: dc=eprnsds7DirectoryReplicaSubtree: ou=usuarios,dc=metaeprinsa,dc=orgnsds7NewWinUserSyncEnabled: onnsds7NewWinGroupSyncEnabled: offnsds7WindowsDomain: eprnsDS5ReplicaRoot: dc=metaeprinsa,dc=orgnsDS5ReplicaHost: ad5.eprnsDS5ReplicaPort: 389nsDS5ReplicaBindDN: cn=metasync,ou=usuarios de servicio,ou=grupos,dc=eprnsDS5ReplicaBindMethod: SIMPLEnsDS5ReplicaCredentials: oneWaySync: fromWindowsv1.3dn: cn=ad5,cn=replica,cn=dc\3Dmetaeprinsa\2Cdc\3Dorg,cn=mapping tree,cn=configobjectClass: topobjectClass: nsDSWindowsReplicationAgreementdescription: ad5cn: ad5nsds7WindowsReplicaSubtree: dc=eprnsds7DirectoryReplicaSubtree: ou=usuarios,dc=metaeprinsa,dc=orgnsds7NewWinUserSyncEnabled: onnsds7NewWinGroupSyncEnabled: offnsds7WindowsDomain: eprnsDS5ReplicaRoot: dc=metaeprinsa,dc=orgnsDS5ReplicaHost: ad5.eprnsDS5ReplicaPort: 389nsDS5ReplicaBindDN: cn=metasync,ou=usuarios de servicio,ou=grupos,dc=eprnsDS5ReplicaBindMethod: SIMPLEnsDS5ReplicaCredentials: oneWaySync: fromWindowsDe: "Rich Megginson" Para: "General discussion list for the 389 Directory server project." <389-users@lists.fedoraproject.org>CC: "Juan Carlos Camargo" Enviados: Jueves, 18 de Julio 2013 16:01:52Asunto: Re: [389-users] winsync: differences between 1.2.11.15 and 1.3On 07/18/2013 06:17 AM, Juan Carlos Camargo wrote: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? Can you post your winsync config? The AD entry CN= - is it in the windows subtree or outside of it? If it is outside of it, why? 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] 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
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" Para: "General discussion list for the 389 Directory server project." <389-users@lists.fedoraproject.org>CC: "Juan Carlos Camargo" Enviados: 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] 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
[389-users] pwdUpdateTime when password policies are applied.
I've installed 10.2.11.15 on a lab machine (fedora17) and set passwordTrackUpdateTime to on in config. This is the first time I'm testing this feature, I dont know if this also happens in former 10.2.11x versions. I've noticed that whenever a password policy is applied to an user, either directly or inherited from branch/ou, the pwdUpdateTime stops updating upon password changes. If I remove the password policy then the attribute works as expected. Is this the correct behaviour?Regards.JC.-- 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] Announcing 389 Directory Server version 1.2.11.12 Testing
Thanks for the info and the update! Congrats Carsten, wonderful job!I needed to turn off schema checking on the server (1.2.11.11) for the update to complete. Otherwise I had an "object class violation" error:(...)Full DN of administrative user [cn=Directory Manager]: Password for this user: Could not open TLS connection to freeipa2.eprinsa.org:389 - trying regular connectiondn: cn=Posix Winsync API,cn=plugins,cn=configobjectclass: topobjectclass: nsSlapdPluginobjectclass: extensibleObjectcn: Posix Winsync APInsslapd-pluginpath: libposix-winsync-pluginnsslapd-plugininitfunc: posix_winsync_plugin_initnsslapd-plugintype: preoperationnsslapd-pluginenabled: offnsslapd-plugin-depends-on-type: databaseposixwinsyncmssfuschema: falseposixwinsyncmapmemberuid: trueposixwinsynccreatememberoftask: falseposixwinsynclowercaseuid: falsensslapd-pluginprecedence: 25Error adding entry 'cn=Posix Winsync API,cn=plugins,cn=config'. Error: Object class violationError: could not update the directory server.(...)De: "Rich Megginson" Para: 389-annou...@lists.fedoraproject.org, 389-users@lists.fedoraproject.org, test-annou...@lists.fedoraproject.orgEnviados: Viernes, 31 de Agosto 2012 22:50:56Asunto: [389-users] Announcing 389 Directory Server version 1.2.11.12TestingThe 389 Project team is pleased to announce the release of 389-ds-base-1.2.11.12 for Testing. This release includes support for POSIX attributes in Windows Sync, several bug fixes, and cleanup of various issues found by valgrind and Coverity. The 389 team would like to thank Carsten Grzemba for contributing his POSIX Windows Sync plugin to the project.The new packages and versions are: 389-ds-base 1.2.11.12NOTE: 1.2.11 will not be available for Fedora 16 or earlier, nor for EL6 or earlier - 1.2.11 will only be available for Fedora 17 and later. We are trying to stabilize current, stable releases - upgrades to 1.2.11 will disrupt stability.Installation yum install 389-ds --enablerepo=updates-testing # or for EPEL yum install 389-ds --enablerepo=epel-testing setup-ds-admin.plUpgrade yum upgrade 389-ds-base --enablerepo=updates-testing # or for EPEL yum upgrade 389-ds-base --enablerepo=epel-testing setup-ds-admin.pl -uHow to Give FeedbackThe best way to provide feedback is via the Fedora Update system. Go to https://admin.fedoraproject.org/updates In the Search box in the upper right hand corner, type in the name of the package In the list, find the version and release you are using (if you're not sure, use rpm -qi on your system) and click on the release On the page for the update, scroll down to "Add a comment" and provide your inputOr just send us an email to 389-users@lists.fedoraproject.orgReporting BugsIf you find a bug, or would like to see a new feature, use the 389 Trac - https://fedorahosted.org/389More Information* Release Notes - http://port389.org/wiki/Release_Notes* Install_Guide - http://port389.org/wiki/Install_Guide* Download - http://port389.org/wiki/Download--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] 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" Para: 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
Re: [389-users] Problem with passwords and spanish characters
It is (ñ = 0xf1). Will file that ticket. Thanks Rich!De: "Rich Megginson" Para: "General discussion list for the 389 Directory server project." <389-users@lists.fedoraproject.org>CC: "Juan Carlos Camargo" Enviados: Martes, 8 de Mayo 2012 15:10:14Asunto: Re: [389-users] Problem with passwords and spanish characters
On 05/08/2012 01:20 AM, Juan Carlos Camargo wrote:
Hi there,
I'm
facing a problem with windows users whose password contains
the spanish accented "n" (ñ). Neither the ldap directory or
the password sync service complain at all , but the user is
unable to auth in 389ds (latest version both 389-ds and
windows pass sync). I've browsed the forums and disabled the
7bit-check plugin, but that does not seem to work either.
Here's what I've found in the audit logs (please note the
unhashed password entry):
Windows
user password: funci0nA
time: 20120508080147
dn: uid=***
changetype: modify
replace: userPassword
userPassword:
{SSHA}z8Ns6yOIY5N8JiZA7N53DWUCm6QCdBV083dXbA==
-
replace: modifiersName
modifiersName: cn=directory manager
-
replace: modifyTimestamp
modifyTimestamp: 20120508060323Z
-
replace: unhashed#user#password
unhashed#user#password: funci0nA
-
replace: entryusn
entryusn: 203032
However,
with accented "n":
Windows user password: cañadelomo
time: 20120508080345
dn: uid=*
changetype: modify
replace: userPassword
userPassword:
{SSHA}gD/DhJXnFiRsXl2KIooVPaSwG+1K9VjU8yxZ5Q==
-
replace: modifiersName
modifiersName: cn=directory manager
-
replace: modifyTimestamp
modifyTimestamp: 20120508060521Z
-
replace: unhashed#user#password
unhashed#user#password::
Y2HxYWRlbG9tbw==
-
replace: entryusn
entryusn: 203037
-
Why
the difference when the spanish char is used, does it trigger
something else in the sync process?
Possibly. Please file a ticket at https://fedorahosted.org/389
Note that
unhashed#user#password:: Y2HxYWRlbG9tbw==
is ca\xf1adelomo - I'm assuming \xf1 is ñ in utf-8 encoding
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
-- 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] Problem with passwords and spanish characters
Hi there,I'm facing a problem with windows users whose password contains the spanish accented "n" (ñ). Neither the ldap directory or the password sync service complain at all , but the user is unable to auth in 389ds (latest version both 389-ds and windows pass sync). I've browsed the forums and disabled the 7bit-check plugin, but that does not seem to work either. Here's what I've found in the audit logs (please note the unhashed password entry):Windows user password: funci0nAtime: 20120508080147dn: uid=***changetype: modifyreplace: userPassworduserPassword: {SSHA}z8Ns6yOIY5N8JiZA7N53DWUCm6QCdBV083dXbA==-replace: modifiersNamemodifiersName: cn=directory manager-replace: modifyTimestampmodifyTimestamp: 20120508060323Z-replace: unhashed#user#passwordunhashed#user#password: funci0nA-replace: entryusnentryusn: 203032However, with accented "n":Windows user password: cañadelomotime: 20120508080345dn: uid=*changetype: modifyreplace: userPassworduserPassword: {SSHA}gD/DhJXnFiRsXl2KIooVPaSwG+1K9VjU8yxZ5Q==-replace: modifiersNamemodifiersName: cn=directory manager-replace: modifyTimestampmodifyTimestamp: 20120508060521Z-replace: unhashed#user#passwordunhashed#user#password:: Y2HxYWRlbG9tbw==-replace: entryusnentryusn: 203037-Why the difference when the spanish char is used, does it trigger something else in the sync process?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] Creating windows sync agreements via ldif
Fixed! Thanks Carsten!De: "Carsten Grzemba" Para: "General discussion list for the 389 Directory server project." <389-users@lists.fedoraproject.org>Enviados: Lunes, 26 de Marzo 2012 15:22:57Asunto: Re: [389-users] Creating windows sync agreements via ldifHi,nsds5BeginReplicaRefresh: startshould do the job.But I have not done this in a single step, but first add the agreement and then add the attribute nsds5BeginReplicaRefresh: startPerhaps that helpsRegardsCarstenAm 26.03.12, schrieb Juan Carlos Camargo :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: nsDS5ReplicaTransportInfo: LDAPnsDS5ReplicaCredentials: < pass of proxy user>nsds5BeginReplicaRefresh: start-- Juan Carlos Camargo Carrillo 957-211157 , 650932877 --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: nsDS5ReplicaTransportInfo: LDAPnsDS5ReplicaCredentials: < pass of proxy user>nsds5BeginReplicaRefresh: 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" 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 <>-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] 389-DSGW and userPassword / sambaNTPassword / sambaLMPassword synchronization
Apologies for my english :) Thanks Rob, I'll try that. El mié, 06-07-2011 a las 09:37 -0400, Rob Crittenden escribió: > Juan Carlos Camargo Carrillo wrote: > > Can IPA use 389ds as a replication partner? The idea is to have IPA as > > a source directory with all of its growing benefits (kerberos, pass > > sync, windows sync with selected attributes) while keeping faithful to > > 389ds, simply because that's the solution we're all here for. > > I'm not sure I understand the statement "keeping faithful." > > This isn't something the IPA developers have tried. You can manually set > up replication agreement between the two, using SSL would be the > easiest. You'd probably want it to be a read-only replica. > > rob > > > > El mar, 05-07-2011 a las 08:43 -0600, Rich Megginson escribió: > >> On 07/05/2011 07:02 AM, Alexandr Popov wrote: > >>> Hello! > >>> > >>> I've got a directory server and DSGW running. > >>> > >>> Mail server, openvpn server and samba share use ldap authentication > >>> against this directory server. Users change their passwords in DSGW. > >>> > >>> The mailserver and openvpn use SSHA hash in "userpassword" field, but > >>> samba uses NT hash and LM hash in "sambantpassword" and > >>> "sambalmpassword" fields accordingly. > >>> > >>> How can I make "userpassword" , "sambantpassword" and > >>> "sambalmpassword" fields change synchronously when users change their > >>> passwords in DSGW? > >>> > >>> As I can understand, there is no already written 389-DS-plugin for > >>> synchronizing these fields. > >>> Moreover, it seems to me that such issues as mine are often solved on > >>> the ldap clients: > >>> http://web.archiveorange.com/archive/v/I3m7YImbRJ3Dj9WoXlCz > >>> Am I right? > >>> > >>> So should I change domodify.c > >>> <http://git.fedorahosted.org/git?p=389/dsgw.git;a=blob;f=domodify.c;h=5a3719276e3283e80415a884998e5281e066a8c1;hb=refs/tags/389-dsgw-1.1.7> > >>> which is responsible for password change in DSGW? Does it seem to be > >>> useful for Community? > >>> > >>> Looking forward to your prompt repy. > >> Patches welcome. > >> > >> Or you could use IPA instead - IPA provides a plugin that keeps all of > >> your passwords in sync - userPassword, and Samba and Kerberos passwords. > >>> > >>> Best regards, > >>> Alex Popov. > >> > >> -- > >> 389 users mailing list > >> 389-users@lists.fedoraproject.org > >> <mailto: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 mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] 389-DSGW and userPassword / sambaNTPassword / sambaLMPassword synchronization
Can IPA use 389ds as a replication partner? The idea is to have IPA as a source directory with all of its growing benefits (kerberos, pass sync, windows sync with selected attributes) while keeping faithful to 389ds, simply because that's the solution we're all here for. El mar, 05-07-2011 a las 08:43 -0600, Rich Megginson escribió: > On 07/05/2011 07:02 AM, Alexandr Popov wrote: > > > Hello! > > > > I've got a directory server and DSGW running. > > > > Mail server, openvpn server and samba share use ldap authentication > > against this directory server. Users change their passwords in DSGW. > > > > The mailserver and openvpn use SSHA hash in "userpassword" field, > > but samba uses NT hash and LM hash in "sambantpassword" and > > "sambalmpassword" fields accordingly. > > > > How can I make "userpassword" , "sambantpassword" and > > "sambalmpassword" fields change synchronously when users change > > their passwords in DSGW? > > > > As I can understand, there is no already written 389-DS-plugin for > > synchronizing these fields. > > Moreover, it seems to me that such issues as mine are often solved > > on the ldap clients: > >http://web.archiveorange.com/archive/v/I3m7YImbRJ3Dj9WoXlCz > > Am I right? > > > > So should I change domodify.c which is responsible for password > > change in DSGW? Does it seem to be useful for Community? > > > > Looking forward to your prompt repy. > > Patches welcome. > > Or you could use IPA instead - IPA provides a plugin that keeps all of > your passwords in sync - userPassword, and Samba and Kerberos > passwords. > > > > > Best regards, > > Alex Popov. > > > > -- > 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] 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 "
4.2 for existing ldap users, "addprinc -x dn=
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 :
> > 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] About Kerberos and dirsrv
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
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 > 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-/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 > > > >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? > > > >> > > > >> &g
Re: [389-users] 1.2.8 Windows sync agreement initialization
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-/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 > 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 > > > 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 has no update vector. It has never been initialized" > > > > continously filling the error log until I proceed with the init. But > > > > the replica was initialized and conversations between 389 and AD were > > > > working nicely. And what I would not want at al
Re: [389-users] 1.2.8 Windows sync agreement initialization
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 > 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 has no update vector. It has never been initialized" continously > > filling the error log until I proceed with the init. But the replica was > > initialized and conversations between 389 and AD were working nicely. And > > what I would not want at all is to lose any changes made on either side as > > a result of the initialization process. My question then, is this the > > normal behaviour ? > > > > 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 -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
[389-users] 1.2.8 Windows sync agreement initialization
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 has no update vector. It has never been initialized" continously filling the error log until I proceed with the init. But the replica was initialized and conversations between 389 and AD were working nicely. And what I would not want at all is to lose any changes made on either side as a result of the initialization process. My question then, is this the normal behaviour ? Thanks! -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
[389-users] "onewaysync" attr.
Hi everyone, I'm working with the new attribute "onewaysync" to manage replication between our AD domain and 389ds. To start with I've created a windows repl. agreement, then set that attribute the value "fromWindows" .So far it seems to work. My question is, which method you find better, in order to protect the Active Directory objects from potential modifications made by 389? a) Use a proxy user for the repl. agreement with tailored permissions? If so, which permissions are you using? b) Leave it as such, without the "onewaysync" attr. Besides, it is a consumer replica, so by design it wasnt meant to send updates. Which other choices you have in mind or have already implemented? And finally, is there a way to select a subset of windows attributes to be sync'd to 389? Regards!! -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
