Bug 1111364

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.

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.

(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.

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!

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

(In reply to Scott Poore from comment #6)
> This the one you're looking for?

Yes, thanks!!

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.

(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?

(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...

Noriko, 

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

Thanks,
Scott

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?

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?

(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.)

Hi Scott,

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

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.

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.

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

Upstream ticket:
https://fedorahosted.org/389/ticket/47852

$ 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.

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