1. This is a bug in posix-winsync plugin.
2. This is not a regression.  The code has been there from the beginning (I guess).
3. IPA does not use posix-winsync plugin for the account enabling/disabling.  It has its own plugin, I think.  Martin or Jenny, could you confirm?
4. And if IPA has its own plugin, could you test this failed case?
4-1. create an account (either DS or AD).
4-2. disable the account on AD.
4-3. enable it back on DS.
If the account is successfully enabled on DS and it's sync'ed to AD, it is free from the bug.

In the posix-plugin, when it receives a request to disable the account from AD, it checks the nsAccountLock explicitly as well as virtually.  If it's not found in the both checks, it does NOT set a flag to tell it is a virtual attribute, then a real "nsAccountLock: true" attr-value pair is added to the user entry.  Once the real nsAccountLock attribute is added to an entry, ns-activate.pl (as well as Console) does not remove it (since it's not implemented for that).

This patch fixes the problem.  I'm going to open a trac ticket.
diff --git a/ldap/servers/plugins/posix-winsync/posix-winsync.c b/ldap/servers/plugins/posix-winsync/posix-winsync.c
index d43e76d..9a70244 100644
--- a/ldap/servers/plugins/posix-winsync/posix-winsync.c
+++ b/ldap/servers/plugins/posix-winsync/posix-winsync.c
@@ -152,6 +152,9 @@ _check_account_lock(Slapi_Entry *ds_entry, int *isvirt)
     int attr_free_flags = 0;
     char *strval;
 
+    if (isvirt) {
+        *isvirt = 1; /* nsAccountLock is implemeted as nsRole */
+    }
     /* first, see if the attribute is a "real" attribute */
     strval = slapi_entry_attr_get_charptr(ds_entry, "nsAccountLock");
     if (strval) { /* value is real */

I agree this is a pretty bad bug, and I'd like to fix it as soon as possible.  But we don't have the enough justification if this does not affect IPA and it is not a regression...?

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

(In reply to Noriko Hosoi from comment #6)
> 1. This is a bug in posix-winsync plugin.
> 2. This is not a regression.  The code has been there from the beginning (I
> guess).
> 3. IPA does not use posix-winsync plugin for the account enabling/disabling.
> It has its own plugin, I think.  Martin or Jenny, could you confirm?
> 4. And if IPA has its own plugin, could you test this failed case?
> 4-1. create an account (either DS or AD).
> 4-2. disable the account on AD.
> 4-3. enable it back on DS.
> If the account is successfully enabled on DS and it's sync'ed to AD, it is
> free from the bug.

Checked in version 389-ds-base-1.3.3.1-13.el7.x86_64 with ipa-server-4.1.0-16.el7.x86_64.

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: [   LOG    ] :: ipa_winsync_0009: Synchronization behaviour of account lock status
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

ipawinsyncacctdisable: both
:: [   PASS   ] :: Winsync account disable set to "both" by default 
:: [ 15:30:55 ] :: Testing with Winsync account disable set to"both"
:: [  BEGIN   ] :: Creating ldif file to reset ipawinsyncacctdisable to "both" :: actually running 'acctdisable_ldif both'
:: [   PASS   ] :: Creating ldif file to reset ipawinsyncacctdisable to "both" (Expected 0, got 0)
:: [  BEGIN   ] :: Setting disabled account to sync to both servers :: actually running 'ldapmodify -x -D "cn=Directory Manager" -w Secret123 -f acctdisable.ldif'
modifying entry "cn=ipa-winsync,cn=plugins,cn=config"

:: [   PASS   ] :: Setting disabled account to sync to both servers (Expected 0, got 0)
:: [  BEGIN   ] :: aduser1 is enabled on IPA :: actually running 'ipa user-show aduser1 | grep "Account disabled: False"'
  Account disabled: False
:: [   PASS   ] :: aduser1 is enabled on IPA (Expected 0, got 0)
:: [  BEGIN   ] :: Creating ldif file for disabling aduser1 :: actually running 'ADuser_cntrl_ldif aduser1 ads 514'
:: [   PASS   ] :: Creating ldif file for disabling aduser1 (Expected 0, got 0)
:: [  BEGIN   ] :: Disable aduser1 on AD :: actually running 'ldapmodify -ZZ -h squab.adrelm.com -D "CN=Administrator,CN=Users,DC=adrelm,DC=com" -w Secret123 -f ADuser_cntrl.ldif'
modifying entry "CN=aduser1 ads,CN=Users,DC=adrelm,DC=com"

:: [   PASS   ] :: Disable aduser1 on AD (Expected 0, got 0)
:: [  BEGIN   ] :: aduser1 disabled in AD :: actually running 'ldapsearch -x -ZZ -h squab.adrelm.com -D "CN=Administrator,CN=Users,DC=adrelm,DC=com" -w Secret123 -b "CN=aduser1 ads,CN=Users,DC=adrelm,DC=com" | grep "userAccountControl: 514"'
userAccountControl: 514
:: [   PASS   ] :: aduser1 disabled in AD (Expected 0, got 0)
:: [  BEGIN   ] :: Waiting for sync :: actually running 'sleep 30'
:: [   PASS   ] :: Waiting for sync (Expected 0, got 0)
:: [  BEGIN   ] :: Running 'sleep 5'
:: [   PASS   ] :: Command 'sleep 5' (Expected 0, got 0)
:: [  BEGIN   ] :: After sync aduser1 disabled on IPA as well :: actually running 'ipa user-show aduser1 | grep "Account disabled: True"'
  Account disabled: True
:: [   PASS   ] :: After sync aduser1 disabled on IPA as well (Expected 0, got 0)
:: [  BEGIN   ] :: Running 'ipa user-enable aduser1'
------------------------------
Enabled user account "aduser1"
------------------------------
:: [   PASS   ] :: Command 'ipa user-enable aduser1' (Expected 0, got 0)
:: [  BEGIN   ] :: Re-enabled aduser1 from IPA :: actually running 'ipa user-show aduser1 | grep "Account disabled: False"'
  Account disabled: False
:: [   PASS   ] :: Re-enabled aduser1 from IPA (Expected 0, got 0)
:: [  BEGIN   ] :: Giving 5 seconds to inform AD :: actually running 'sleep 5'
:: [   PASS   ] :: Giving 5 seconds to inform AD (Expected 0, got 0)
:: [  BEGIN   ] :: aduser1 is enabled in AD as well :: actually running 'ldapsearch -x -ZZ -h squab.adrelm.com -D "CN=Administrator,CN=Users,DC=adrelm,DC=com" -w Secret123 -b "CN=aduser1 ads,CN=Users,DC=adrelm,DC=com" | grep "userAccountControl: 512"'
userAccountControl: 512
:: [   PASS   ] :: aduser1 is enabled in AD as well (Expected 0, got 0)

Thank you Viktor and Steeve!!!

Followed these steps to verify the bug:
1. Setup winsync/passsync on RHEL7.2 latest with windows 2012r2.
2. Created few users in AD and DS.
3. Waited for the entries to be synced across.
4. Then, ran ldapmodify on AD to disable users.
[root@dhcp35-196 slapd-M1]# ldapmodify -D "cn=Administrator,cn=users,dc=adrelm,dc=com" -w Secret123  -H ldap://win2012r2.adrelm.com << EOF
dn: CN=nnusrds1,OU=adpasssync,DC=adrelm,DC=com
changetype: modify
replace: userAccountControl
userAccountControl: 514
EOF

modifying entry "CN=nnusrds1,OU=adpasssync,DC=adrelm,DC=com"

5. Ldapsearch to check if the user is disabled.
ldapsearch -D "cn=Administrator,cn=users,dc=adrelm,dc=com" -w Secret123  -H ldap://win2012r2.adrelm.com -b "ou=adpasssync,dc=adrelm,dc=com" "userAccountControl"
# nnusrad1, adpasssync, adrelm.com
dn: CN=nnusrad1,OU=adpasssync,DC=adrelm,DC=com
userAccountControl: 514

6. Check if the same user is disabled on DS.
[root@dhcp35-196 slapd-M1]# ns-accountstatus.pl -Z M1  -D "cn=Directory Manager" -w Secret123 -I uid=nnusrad1,ou=dswinsync,dc=passsync,dc=com
uid=nnusrad1,ou=dswinsync,dc=passsync,dc=com  activated.

Result: FAIL

After few mins of wait, the account is automatically enabled on AD. This is really strange.

# nnusrad1, adpasssync, adrelm.com
dn: CN=nnusrad1,OU=adpasssync,DC=adrelm,DC=com
userAccountControl: 512

Additional details...
1. Automatically account is enabled on AD, if the user account is created/synced and then disabled at AD.
2. If the user account is syned after being disabled, then automatic change of account status from 514 to 512 doesn't occur.
3. Account on DS side is disabled, even though the account is automatically enabled on AD.

I was keep testing the account enable/disable or activate/inactivate from AD to DS and vice versa. None of the above mentioned issues are reproducible.

Test cases verified:
Account disable sync from DS to AD - PASS
Account enable sync from DS to AD - PASS
Account disable sync from AD to DS - PASS
Account enable sync from AD to DS - PASS

Hence, marking the bug as Verified. 

I will check again, if the issues mentioned above in comment #13 and comment #14 are reproducible.

Build tested: 389-ds-base-1.3.4.0-8.el7.x86_64

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/RHBA-2015-2351.html