Bug 1111364 - Updating winsync one-way sync does not affect the behaviour dynamically
Summary: Updating winsync one-way sync does not affect the behaviour dynamically
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.0
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: rc
: ---
Assignee: Noriko Hosoi
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-06-19 20:48 UTC by Scott Poore
Modified: 2015-03-05 09:35 UTC (History)
5 users (show)

Fixed In Version: 389-ds-base-1.3.3.1-1.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-03-05 09:35:33 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:0416 normal SHIPPED_LIVE Important: 389-ds-base security, bug fix, and enhancement update 2015-03-05 14:26:33 UTC

Description Scott Poore 2014-06-19 20:48:09 UTC
Description of problem:

I setup winsync replication on a RHEL7 IPA server.  I modified the sync to uni-directional fromWindows.  However, it's still syncing from IPA server back to Windows.

Version-Release number of selected component (if applicable):
389-ds-base-1.3.1.6-25.el7.x86_64
ipa-server-3.3.3-28.el7.x86_64


How reproducible:
Unknown.

Steps to Reproduce:
1.  Setup IPA Master
2.  Setup winsync/passsync on IPA and AD servers
3.  Set sync to one-way fromWindows.
4.  disable AD sync'd user on IPA side
5.  Check User on AD side

Actual results:
AD side shows user disabled.


Expected results:
AD side should still show user enabled which is different than IPA side.

Additional info:

I setup the one-way sync with this:

[root@master ~]# ldapmodify -x -D "cn=Directory Manager" -w Secret123 <<EOFdn: cn=meTowinsync1.adws1.example.com,cn=replica,cn=dc\3Dipa1\2Cdc\3Dexample\2Cdc\3Dtest,cn=mapping tree,cn=config
changetype: modify
add: oneWaySync
oneWaySync: fromWindows
EOF

Then I enable aduser3:

[root@master ~]# ipa user-enable aduser3
------------------------------
Enabled user account "aduser3"
------------------------------

I see it enable on AD side.

I then disable on AD side and I see it disable on IPA side:

[root@master ~]# ipa user-show aduser3
  User login: aduser3
  First name: ad
  Last name: user3
  Home directory: /home/aduser3
  Login shell: /bin/sh
  UID: 857200005
  GID: 857200005
  Account disabled: True
  Password: True
  Kerberos keys available: True

So, it appears to be sync'ing both directions.  I would not have expected the enable on IPA side to enable also on AD side.

Comment 2 Rich Megginson 2014-06-19 21:21:44 UTC
Note that only IPA syncs the account enable/disable - regular 389 does not sync this field.  So it could be an IPA only problem.  The way to verify this is to attempt to modify some field other than the account enable/disable field e.g. telephoneNumber and see if you can sync it both ways with oneWaySync: fromWindows set.

Comment 3 Scott Poore 2014-06-19 21:34:48 UTC
Seems to sync back for homePhone too:

[root@master ~]# ldapmodify -x -D "cn=Directory Manager" -w Secret123 <<EOF> dn: cn=meTowinsync1.adws1.example.com,cn=replica,cn=dc\3Dipa1\2Cdc\3Dexample\2Cdc\3Dtest,cn=mapping tree,cn=config
> changetype: modify
> add: oneWaySync
> oneWaySync: fromWindows
> EOF
modifying entry "cn=meTowinsync1.adws1.example.com,cn=replica,cn=dc\3Dipa1\2Cdc\3Dexample\2Cdc\3Dtest,cn=mapping tree,cn=config"


[root@master ~]# ipa user-mod aduser2 --addattr="homePhone=8888"
-----------------------
Modified user "aduser2"
-----------------------
  User login: aduser2
  First name: ad
  Last name: user2
  Home directory: /home/aduser2
  Login shell: /bin/sh
  UID: 857200004
  GID: 857200004
  Telephone Number: 1-888-555-1212
  Account disabled: False
  Password: True
  Kerberos keys available: True


Note Telephone Number above was a first attempt at using --phone option for user-mod but, that didn't seem to match homePhone as synced from Windows to IPA like I tested on aduser1 prior to this.  So, I just used --addattr there.  When I did that, I was able to see the number in AD as 8888.

Comment 4 Rich Megginson 2014-06-19 21:36:38 UTC
(In reply to Scott Poore from comment #3)
> Seems to sync back for homePhone too:
> 
> [root@master ~]# ldapmodify -x -D "cn=Directory Manager" -w Secret123 <<EOF>
> dn:
> cn=meTowinsync1.adws1.example.com,cn=replica,
> cn=dc\3Dipa1\2Cdc\3Dexample\2Cdc\3Dtest,cn=mapping tree,cn=config
> > changetype: modify
> > add: oneWaySync
> > oneWaySync: fromWindows
> > EOF
> modifying entry
> "cn=meTowinsync1.adws1.example.com,cn=replica,
> cn=dc\3Dipa1\2Cdc\3Dexample\2Cdc\3Dtest,cn=mapping tree,cn=config"
> 
> 
> [root@master ~]# ipa user-mod aduser2 --addattr="homePhone=8888"
> -----------------------
> Modified user "aduser2"
> -----------------------
>   User login: aduser2
>   First name: ad
>   Last name: user2
>   Home directory: /home/aduser2
>   Login shell: /bin/sh
>   UID: 857200004
>   GID: 857200004
>   Telephone Number: 1-888-555-1212
>   Account disabled: False
>   Password: True
>   Kerberos keys available: True
> 
> 
> Note Telephone Number above was a first attempt at using --phone option for
> user-mod but, that didn't seem to match homePhone as synced from Windows to
> IPA like I tested on aduser1 prior to this.  So, I just used --addattr
> there.  When I did that, I was able to see the number in AD as 8888.

Ok.  So it's not just account enable/disable - oneWaySync is broken with IPA.  The next step will be to determine if this affects only IPA, or if it affects plain 389 too.

Comment 5 Noriko Hosoi 2014-06-19 21:46:38 UTC
Scott, could you attach the WinSync agreement entry in the 389-ds-base config file to this bug?

/etc/dirsrv/slapd-<ID>/dse.ldif

dn: cn=<WinSync>,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
objectClass: top
objectClass: nsDSWindowsReplicationAgreement
cn: <WinSync>
.....

Thanks!

Comment 6 Scott Poore 2014-06-20 00:57:31 UTC
This the one you're looking for?

dn: cn=meTowinsync1.adws1.example.com,cn=replica,cn=dc\3Dipa1\2Cdc\3Dexample\2
 Cdc\3Dtest,cn=mapping tree,cn=config
nsds7WindowsReplicaSubtree: cn=Users,DC=ADWS1,DC=EXAMPLE,DC=COM
nsds7DirectoryReplicaSubtree: cn=users,cn=accounts,dc=ipa1,dc=example,dc=test
cn: meTowinsync1.adws1.example.com
nsds7NewWinGroupSyncEnabled: false
objectClass: nsDSWindowsReplicationAgreement
objectClass: top
nsDS5ReplicaTransportInfo: TLS
description: me to winsync1.adws1.example.com
nsDS5ReplicaRoot: dc=ipa1,dc=example,dc=test
nsDS5ReplicaHost: winsync1.adws1.example.com
nsds5replicaTimeout: 120
nsDS5ReplicaBindDN: cn=Administrator,cn=Users,dc=adws1,dc=example,dc=com
nsds7NewWinUserSyncEnabled: true
nsDS5ReplicaPort: 389
nsds7WindowsDomain: ipa1.example.test
nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE memberof idnssoaserial
  entryusn krblastsuccessfulauth krblastfailedauth krbloginfailedcount
nsDS5ReplicaBindMethod: simple
nsDS5ReplicaCredentials: {DES}e6rSi5rS3Mn22lsJWKbfIg==
creatorsName: cn=directory manager
modifiersName: cn=Multimaster Replication Plugin,cn=plugins,cn=config
createTimestamp: 20140618222440Z
modifyTimestamp: 20140620005521Z
nsds7DirsyncCookie:: TVNEUwMAAACgZ6ZPIozPAQAAAAAAAAAAKAAAAMNgAAAAAAAAAAAAAAAAA
 ADDYAAAAAAAAIKih5qXcK1ErOqXcz33naYBAAAAAAAAAAEAAAAAAAAAgqKHmpdwrUSs6pdzPfedps
 NgAAAAAAAA
oneWaySync: fromWindows

Comment 7 Noriko Hosoi 2014-06-20 01:09:28 UTC
(In reply to Scott Poore from comment #6)
> This the one you're looking for?

Yes, thanks!!

Comment 8 Noriko Hosoi 2014-06-20 21:38:49 UTC
I could not reproduce the problem using the master build as well as the rhel-7.0 branch build...

I set oneWaySync in my WinSync agreement:
oneWaySync: fromWindows

Only the updates on windows are synced to the DS, and the updates on DS are not to the windows.

Comment 9 Rich Megginson 2014-06-20 21:50:18 UTC
(In reply to Noriko Hosoi from comment #8)
> I could not reproduce the problem using the master build as well as the
> rhel-7.0 branch build...
> 
> I set oneWaySync in my WinSync agreement:
> oneWaySync: fromWindows
> 
> Only the updates on windows are synced to the DS, and the updates on DS are
> not to the windows.

So does that mean this problem is specific to IPA winsync?

Comment 10 Noriko Hosoi 2014-06-20 22:57:58 UTC
(In reply to Rich Megginson from comment #9)
> (In reply to Noriko Hosoi from comment #8)
> > I could not reproduce the problem using the master build as well as the
> > rhel-7.0 branch build...
> > 
> > I set oneWaySync in my WinSync agreement:
> > oneWaySync: fromWindows
> > 
> > Only the updates on windows are synced to the DS, and the updates on DS are
> > not to the windows.
> 
> So does that mean this problem is specific to IPA winsync?

Not sure...  I was hoping to reproduce the problem without IPA, but I could not.  Could there be an IPA system with AD I could play with?  I'd love to try the basic test I did on my system.  I.e., first, I'd like to make sure the oneWaySync is broken via IPA, then run the DS-AD winsync only test...  If the problem is reproduced without IPA operation, I'd like to go through with gdb.  To do so, I need windows access via vnc or something...

Comment 11 Scott Poore 2014-06-21 00:53:39 UTC
Noriko, 

I'll send login info for some servers you can take a look at.

Thanks,
Scott

Comment 12 Noriko Hosoi 2014-06-24 22:03:54 UTC
Scott, here's my observation.  I think WinSync is working as expected including the one-way feature, but the search result is a bit out of state?

1. I added a user to DS using ldap command line (ldapmodify) as well as ipa user-add, but the entry was not added to the AD. <== OK

2. I added a user (cn=ad user10) to AD, which was synced to DS.
2-1. ad user10 on DS: Account disabled: True
     ad user10 on AD: right click menu shows "Enable account", i.e., disabled.
2-2. on DS
      # ipa user-enable aduser10
      -------------------------------
      Enabled user account "aduser10"
      -------------------------------
      # ipa user-show aduser10
      Account disabled: False
     on AD
      ad user10 on AD: right click menu shows "Enable account", i.e., disabled. <== OK
     on DS
      # ipa user-user-disable aduser10
      -------------------------------
      Disabled user account "aduser10"
      -------------------------------
      # ipa user-show aduser10
      Account disabled: True
2-3. on AD
      ad user10 on AD: select "Enable account"
     on DS
      # ipa user-show aduser10
      Account disabled: True <== showing the status before the AD change was sync'ed.
      # ipa user-show aduser10
      Account disabled: False <== repeat the command shows the sync'ed result.

The first ipa user-show in 2-3 looks out-of-sync, but it's just temporarily...  Do you think that's the problem?

Comment 13 Scott Poore 2014-06-24 23:06:48 UTC
No, I don't think 2-3 not changing immediately is a problem there.  Just a timing issue I think, right?

And it's interesting but, I'm not seeing the sync'ing back from IPA to AD anymore either.  

Is it possible that something you changed on DS caused it to start working?  Or maybe just a restart of DS was necessary after adding oneWaySync?

Comment 14 Noriko Hosoi 2014-06-24 23:24:32 UTC
(In reply to Scott Poore from comment #13)
> No, I don't think 2-3 not changing immediately is a problem there.  Just a
> timing issue I think, right?

Right.  AD->DS is not sync'ed immediately while DS->AD is.  Interestingly, it seems "ipa user-show" triggers the AD->DS sync (I guess it issues the sync request).

> And it's interesting but, I'm not seeing the sync'ing back from IPA to AD
> anymore either.  

Oh, you don't, either...

> Is it possible that something you changed on DS caused it to start working? 
> Or maybe just a restart of DS was necessary after adding oneWaySync?

Hmmm, I think it should be dynamically configured.  (the oneWaySync value is retrieved in windows_parse_config_entry via agmtlist_modify_callback, which is called when the agreement is modified.)

Comment 15 Noriko Hosoi 2014-06-25 21:38:06 UTC
Hi Scott,

Could there be anything we are supposed to do on this bug?
--noriko

Comment 16 Scott Poore 2014-06-25 22:22:19 UTC
I'm going to try to look at this again but, it may be a day or two until I get back to this.  Marking needinfo for myself to indicate this.

Comment 17 Scott Poore 2014-06-27 03:21:20 UTC
Ok, I had a little time to look at this again.

I was pretty consistently seeing the "ipa user-show" have to be run twice to show me the update from windows when oneWaySync was set.  I tried with a sleep 300 after change on Windows and no longer saw the non-update.  So, just a timing/cached issue there.  Not a problem here I don't think.

Back to the issue at hand.  

I was able to reproduce on the same environment by deleting the oneWaySync and re-adding it.  Then if I restarted IPA, I saw expected behavior where it was not syncing from IPA to Windows.

To reproduce it, I did the following:

1. make sure aduser is enabled on both ad and ipa
2. ipactl restart
3. set oneWaySync to fromWindows
4. ipa user-disable aduser
5. check ad.

I was able to do this a few times on my test env today so we should be able to reproduce it again.  Now, when I restart ipa, it stopped syncing from IPA to AD when oneWaySync was set to fromWindows.

Comment 18 Noriko Hosoi 2014-07-10 18:47:35 UTC
Hi Scott,

I could reproduce the problem on my test env.
I'm updating the summary and opening a 389 ticket to fix for RHEL-7.1.

Thanks!
--noriko

Comment 19 Noriko Hosoi 2014-07-10 19:17:43 UTC
Upstream ticket:
https://fedorahosted.org/389/ticket/47852

Comment 21 Viktor Ashirov 2015-01-17 12:04:23 UTC
$ rpm -qa | grep 389
389-ds-base-debuginfo-1.3.3.1-11.el7.x86_64
389-ds-base-libs-1.3.3.1-11.el7.x86_64
389-ds-base-1.3.3.1-11.el7.x86_64

[1] oneWaySync is absent, sync is bi-directional: 
$ ldapsearch -o ldif-wrap=no -LLL -D "cn=Directory Manager" -w Secret123 -H ldap://localhost:1189 -b "cn=WinPassSync,cn=replica,cn=dc\\3Dexample\\2Cdc\\3Dcom,cn=mapping tree,cn=config" oneWaySync
dn: cn=WinPassSync,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config

Add new entry:
$ ldapmodify -D "cn=Directory Manager" -w Secret123  -H ldap://localhost:1189 -a << EOF
dn: uid=usr01,ou=dswinsync,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: ntUser
ntUserDomainId: usr01
uid: usr01
givenName: usr01
sn: usr01
cn: usr01
userPassword: Secret123
ntUserCreateNewAccount: true
EOF
adding new entry "uid=usr01,ou=dswinsync,dc=example,dc=com"

It was synchronized:
$ ldapsearch -o ldif-wrap=no -LLL -D "cn=Administrator,cn=users,dc=adrelm,dc=com" -w Secret123  -H ldap://win2k8.adrelm.com -b dc=adrelm,dc=com cn=usr01 cn 
dn: CN=usr01,CN=Users,DC=adrelm,DC=com
cn: usr01

[2] Set oneWaySync to fromWindows: 
$ ldapmodify -D "cn=Directory Manager" -w Secret123  -H ldap://localhost:1189 -a << EOF
dn: cn=WinPassSync,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
changetype: modify
add: oneWaySync
oneWaySync: fromWindows
EOF
modifying entry "cn=WinPassSync,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config"

Add new entry: 
$ ldapmodify -D "cn=Directory Manager" -w Secret123  -H ldap://localhost:1189 -a << EOF
dn: uid=usr02,ou=dswinsync,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: ntUser
ntUserDomainId: usr02
uid: usr02
givenName: usr02
sn: usr02
cn: usr02
userPassword: Secret123
ntUserCreateNewAccount: true
EOF
adding new entry "uid=usr02,ou=dswinsync,dc=example,dc=com"

It wasn't synchronized, ldapsearch returns empty result: 
$ ldapsearch -o ldif-wrap=no -LLL -D "cn=Administrator,cn=users,dc=adrelm,dc=com" -w Secret123  -H ldap://win2k8.adrelm.com -b dc=adrelm,dc=com cn=usr02 cn 

Marking as VERIFIED.

Comment 23 errata-xmlrpc 2015-03-05 09:35:33 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2015-0416.html


Note You need to log in before you can comment on or make changes to this bug.