Hide Forgot
Description of problem: The output of ns-accountstatus.pl script is misleading. Checking whether account is active/inactive for users which are inactivated by account policy plugin, it shows account is activated. Version-Release number of selected component (if applicable): 389-ds-base-1.3.5.10-11 How reproducible: Consistently with 389-ds-base-1.3.5 versions Steps to Reproduce: 1. Install 389-ds-base-1.3.5.10-11 on RHEL7.3 machines. 2. Create an instance and configure global account policy plugin. [root@ratangad ]# PORT=3989 ; ldapmodify -D "cn=Directory Manager" -w Secret123 -h localhost -p $PORT -x -vf /export/Backups/AccountPolicy/Global.ldif [root@ratangad ]# cat /export/Backups/AccountPolicy/Global.ldif dn: cn=Account Policy Plugin,cn=plugins,cn=config changetype: modify replace: nsslapd-pluginEnabled nsslapd-pluginEnabled: on - replace: nsslapd-pluginarg0 nsslapd-pluginarg0: cn=config,cn=Account Policy Plugin,cn=plugins,cn=config dn: cn=config,cn=Account Policy Plugin,cn=plugins,cn=config changetype: modify replace: alwaysrecordlogin alwaysrecordlogin: yes - replace: stateattrname stateattrname: lastLoginTime - replace: altstateattrname altstateattrname: createTimestamp - replace: specattrname specattrname: acctPolicySubentry - replace: limitattrname limitattrname: accountInactivityLimit - replace: accountInactivityLimit accountInactivityLimit: 120 3. Add few entries to the suffix, dc=example,dc=com 4. Wait for 120 secs and check if account is inactivated. [root@ratangad slapd-M1]# PORT=3989 ; USER3="uid=Anewnew1,ou=testing,dc=test_accpol,dc=com"; ns-accountstatus.pl -D "cn=Directory Manager" -w Secret123 -h localhost -p $PORT -Z newinst3 -I $USER3 -b $USER3 -f objectclass=* uid=Anewnew1,ou=Testing,dc=test_accpol,dc=com - activated. 5. Check if the user is active by binding. [ root@ratangad slapd-M1]# PORT=3989; USER="uid=Anewnew1,ou=testing,dc=test_accpol,dc=com"; /usr/bin/ldapsearch -x -p $PORT -h localhost -D "$USER" -w Secret123 -b "$USER" ldap_bind: Constraint violation (19) additional info: Account inactivity limit exceeded. Contact system administrator to reset. Actual results: ns-accountstatus.pl shows wrong status for inactive users. Expected results: It should print the correct status of user accounts. Additional info: There are test failures from account inactivity reliability tests, which we didn't observe with 389-ds-base-1.3.4.0 builds. RHEL73 - wiki-old.idm.lab.bos.redhat.com/qa/archive/beaker/RHDS/RHEL73/389-ds-base-1.3.5.10-11.el7.x86_64/Tier2/output/Linux/20160914-140158/accountinact/reliability/accountinact_reliab.run.out.4592 RHEL72 - http://wiki-old.idm.lab.bos.redhat.com/qa/archive/beaker/x86_64/389-ds-base-1.3.4.0-23.el7_2.x86_64/output/Linux/20160113-045003/accountinact/reliability/accountinact_reliab.run.out.4634 [root@ratangad slapd-M1]# PORT=3989 ; USER3="uid=Anewnew1,ou=testing,dc=test_accpol,dc=com"; ns-activate.pl -D "cn=Directory Manager" -w Secret123 -h localhost -p $PORT -Z newinst3 -I $USER3 uid=Anewnew1,ou=testing,dc=test_accpol,dc=com already activated. [root@ratangad slapd-M1]# PORT=3989 ; USER3="uid=Anewnew1,ou=testing,dc=test_accpol,dc=com"; ns-inactivate.pl -D "cn=Directory Manager" -w Secret123 -h localhost -p $PORT -Z newinst3 -I $USER3 uid=Anewnew1,ou=testing,dc=test_accpol,dc=com inactivated. [root@ratangad slapd-M1]# PORT=3989 ; USER3="uid=Anewnew1,ou=testing,dc=test_accpol,dc=com"; ns-accountstatus.pl -D "cn=Directory Manager" -w Secret123 -h localhost -p $PORT -Z newinst3 -I $USER3 -b $USER3 -f objectclass=* uid=Anewnew1,ou=Testing,dc=test_accpol,dc=com - inactivated (directly locked).
I could reproduce the problem... $ ldapsearch -LLLx -D 'uid=tuser996,ou=People,dc=example,dc=com' -w tuser996 -b "" -s base ldap_bind: Constraint violation (19) additional info: Account inactivity limit exceeded. Contact system administrator to reset. # ns-accountstatus.pl -Z test0 -D "cn=Directory Manager" -W -I "uid=tuser996,ou=People,dc=example,dc=com" uid=tuser996,ou=People,dc=example,dc=com - activated. The script searches cn=nsdisabledrole,<SUFFIX>, which fails with 32. [..] conn=45 op=0 BIND dn="cn=Directory Manager" method=128 version=3 [..] conn=45 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" [..] conn=45 op=1 SRCH base="cn=nsdisabledrole,dc=example,dc=com" scope=0 filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs="nsRoleDN" [..] conn=45 op=1 RESULT err=32 tag=101 nentries=0 etime=0 [..] conn=45 op=2 UNBIND And indeed there is no such entry. ldapsearch -LLLx -D 'cn=directory manager' -W -b "cn=nsdisabledrole,dc=example,dc=com" -s base "(|(objectClass=*)(objectClass=ldapsubentry))" No such object (32) Matched DN: dc=example,dc=com The cn=nsdisabledrole,dc=example,dc=com entry is only created and managed by ns-*activate.pl scripts (or Console, too?). Just by adding an entry and let the entry expire by the Account Policy config with no interaction with the ns-*activate.pl scripts, I don't think ns-accountstatus.pl can display the right status. I'm doubting it was working on 1.3.4.0, either... My vote is this is minor enough for rhel-7.3 and should be pushed to 7.4. What do you think, Mark?
(In reply to Noriko Hosoi from comment #2) > I could reproduce the problem... > > $ ldapsearch -LLLx -D 'uid=tuser996,ou=People,dc=example,dc=com' -w tuser996 > -b "" -s base > ldap_bind: Constraint violation (19) > additional info: Account inactivity limit exceeded. Contact system > administrator to reset. > > # ns-accountstatus.pl -Z test0 -D "cn=Directory Manager" -W -I > "uid=tuser996,ou=People,dc=example,dc=com" > uid=tuser996,ou=People,dc=example,dc=com - activated. > > The script searches cn=nsdisabledrole,<SUFFIX>, which fails with 32. > [..] conn=45 op=0 BIND dn="cn=Directory Manager" method=128 version=3 > [..] conn=45 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory > manager" > [..] conn=45 op=1 SRCH base="cn=nsdisabledrole,dc=example,dc=com" scope=0 > filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs="nsRoleDN" > [..] conn=45 op=1 RESULT err=32 tag=101 nentries=0 etime=0 > [..] conn=45 op=2 UNBIND > > And indeed there is no such entry. > ldapsearch -LLLx -D 'cn=directory manager' -W -b > "cn=nsdisabledrole,dc=example,dc=com" -s base > "(|(objectClass=*)(objectClass=ldapsubentry))" > No such object (32) > Matched DN: dc=example,dc=com > > The cn=nsdisabledrole,dc=example,dc=com entry is only created and managed by > ns-*activate.pl scripts (or Console, too?). Just by adding an entry and let > the entry expire by the Account Policy config with no interaction with the > ns-*activate.pl scripts, I don't think ns-accountstatus.pl can display the > right status. I'm doubting it was working on 1.3.4.0, either... > > My vote is this is minor enough for rhel-7.3 and should be pushed to 7.4. > What do you think, Mark? Actually this is bad if it's reporting the wrong status. Can it go into a batch update for 7.3?
I just figured out the actual regression for ns-activate.pl script. This is the reason why the account inactivity reliability tests fail. With Account policy plugin configured, the ns-activate.pl script returns exit status as 100 for users already activated. Where as, if no Account policy plugin configured, then it never returns exit status 100 for active users. The script is expected to return exit status 100, if you are running ns-activate.pl script when the user is already active. With account policy plugin configured: [root@ratangad MMR_WINSYNC]# PORT=3989 ; USER3="uid=Bnewnew2,ou=testing,dc=test_accpol,dc=com"; ns-activate.pl -D "cn=Directory Manager" -w Secret123 -h localhost -p $PORT -Z newinst3 -I $USER3 ; echo $? uid=Bnewnew2,ou=testing,dc=test_accpol,dc=com already activated. 100 [root@ratangad MMR_WINSYNC]# PORT=3989 ; USER3="uid=Bnewnew2,ou=testing,dc=test_accpol,dc=com"; ns-inactivate.pl -D "cn=Directory Manager" -w Secret123 -h localhost -p $PORT -Z newinst3 -I $USER3 ; echo $? uid=Bnewnew2,ou=testing,dc=test_accpol,dc=com inactivated. 0 [root@ratangad MMR_WINSYNC]# PORT=3989 ; USER3="uid=Bnewnew2,ou=testing,dc=test_accpol,dc=com"; ns-inactivate.pl -D "cn=Directory Manager" -w Secret123 -h localhost -p $PORT -Z newinst3 -I $USER3 ; echo $? uid=Bnewnew2,ou=testing,dc=test_accpol,dc=com already inactivated. 100 [root@ratangad MMR_WINSYNC]# PORT=3989 ; USER3="uid=Bnewnew2,ou=testing,dc=test_accpol,dc=com"; ns-activate.pl -D "cn=Directory Manager" -w Secret123 -h localhost -p $PORT -Z newinst3 -I $USER3 ; echo $? uid=Bnewnew2,ou=testing,dc=test_accpol,dc=com activated. 0 [root@ratangad MMR_WINSYNC]# PORT=3989 ; USER3="uid=Bnewnew2,ou=testing,dc=test_accpol,dc=com"; ns-activate.pl -D "cn=Directory Manager" -w Secret123 -h localhost -p $PORT -Z newinst3 -I $USER3 ; echo $? uid=Bnewnew2,ou=testing,dc=test_accpol,dc=com already activated. 100 No account policy plugin configured: [root@ratangad MMR_WINSYNC]# PORT=4989 ; USER3="uid=newnew2,ou=testing,dc=accpol,dc=com"; ns-activate.pl -D "cn=Directory Manager" -w Secret123 -h localhost -p $PORT -Z newinst4 -I $USER3 ; echo $? uid=newnew2,ou=testing,dc=accpol,dc=com activated. 0 [root@ratangad MMR_WINSYNC]# PORT=4989 ; USER3="uid=newnew2,ou=testing,dc=accpol,dc=com"; ns-inactivate.pl -D "cn=Directory Manager" -w Secret123 -h localhost -p $PORT -Z newinst4 -I $USER3 ; echo $? uid=newnew2,ou=testing,dc=accpol,dc=com inactivated. 0 [root@ratangad MMR_WINSYNC]# PORT=4989 ; USER3="uid=newnew2,ou=testing,dc=accpol,dc=com"; ns-inactivate.pl -D "cn=Directory Manager" -w Secret123 -h localhost -p $PORT -Z newinst4 -I $USER3 ; echo $? uid=newnew2,ou=testing,dc=accpol,dc=com already inactivated. 100 [root@ratangad MMR_WINSYNC]# PORT=4989 ; USER3="uid=newnew2,ou=testing,dc=accpol,dc=com"; ns-activate.pl -D "cn=Directory Manager" -w Secret123 -h localhost -p $PORT -Z newinst4 -I $USER3 ; echo $? uid=newnew2,ou=testing,dc=accpol,dc=com activated. 0 [root@ratangad MMR_WINSYNC]# PORT=4989 ; USER3="uid=newnew2,ou=testing,dc=accpol,dc=com"; ns-activate.pl -D "cn=Directory Manager" -w Secret123 -h localhost -p $PORT -Z newinst4 -I $USER3 ; echo $? uid=newnew2,ou=testing,dc=accpol,dc=com activated. 0 This is where we expect the script to return 100, but it returns 0 always.
(In reply to Sankar Ramalingam from comment #4) > I just figured out the actual regression for ns-activate.pl script. This is > the reason why the account inactivity reliability tests fail. > > With Account policy plugin configured, the ns-activate.pl script returns > exit status as 100 for users already activated. Where as, if no Account > policy plugin configured, then it never returns exit status 100 for active > users. The script is expected to return exit status 100, if you are running > ns-activate.pl script when the user is already active. > > With account policy plugin configured: > > [root@ratangad MMR_WINSYNC]# PORT=3989 ; > USER3="uid=Bnewnew2,ou=testing,dc=test_accpol,dc=com"; ns-activate.pl -D > "cn=Directory Manager" -w Secret123 -h localhost -p $PORT -Z newinst3 -I > $USER3 ; echo $? > uid=Bnewnew2,ou=testing,dc=test_accpol,dc=com already activated. > 100 > [root@ratangad MMR_WINSYNC]# PORT=3989 ; > USER3="uid=Bnewnew2,ou=testing,dc=test_accpol,dc=com"; ns-inactivate.pl -D > "cn=Directory Manager" -w Secret123 -h localhost -p $PORT -Z newinst3 -I > $USER3 ; echo $? > uid=Bnewnew2,ou=testing,dc=test_accpol,dc=com inactivated. > 0 > [root@ratangad MMR_WINSYNC]# PORT=3989 ; > USER3="uid=Bnewnew2,ou=testing,dc=test_accpol,dc=com"; ns-inactivate.pl -D > "cn=Directory Manager" -w Secret123 -h localhost -p $PORT -Z newinst3 -I > $USER3 ; echo $? > uid=Bnewnew2,ou=testing,dc=test_accpol,dc=com already inactivated. > 100 > > [root@ratangad MMR_WINSYNC]# PORT=3989 ; > USER3="uid=Bnewnew2,ou=testing,dc=test_accpol,dc=com"; ns-activate.pl -D > "cn=Directory Manager" -w Secret123 -h localhost -p $PORT -Z newinst3 -I > $USER3 ; echo $? > uid=Bnewnew2,ou=testing,dc=test_accpol,dc=com activated. > 0 > [root@ratangad MMR_WINSYNC]# PORT=3989 ; > USER3="uid=Bnewnew2,ou=testing,dc=test_accpol,dc=com"; ns-activate.pl -D > "cn=Directory Manager" -w Secret123 -h localhost -p $PORT -Z newinst3 -I > $USER3 ; echo $? > uid=Bnewnew2,ou=testing,dc=test_accpol,dc=com already activated. > 100 > > No account policy plugin configured: > > [root@ratangad MMR_WINSYNC]# PORT=4989 ; > USER3="uid=newnew2,ou=testing,dc=accpol,dc=com"; ns-activate.pl -D > "cn=Directory Manager" -w Secret123 -h localhost -p $PORT -Z newinst4 -I > $USER3 ; echo $? > uid=newnew2,ou=testing,dc=accpol,dc=com activated. > 0 > [root@ratangad MMR_WINSYNC]# PORT=4989 ; > USER3="uid=newnew2,ou=testing,dc=accpol,dc=com"; ns-inactivate.pl -D > "cn=Directory Manager" -w Secret123 -h localhost -p $PORT -Z newinst4 -I > $USER3 ; echo $? > uid=newnew2,ou=testing,dc=accpol,dc=com inactivated. > 0 > [root@ratangad MMR_WINSYNC]# PORT=4989 ; > USER3="uid=newnew2,ou=testing,dc=accpol,dc=com"; ns-inactivate.pl -D > "cn=Directory Manager" -w Secret123 -h localhost -p $PORT -Z newinst4 -I > $USER3 ; echo $? > uid=newnew2,ou=testing,dc=accpol,dc=com already inactivated. > 100 > [root@ratangad MMR_WINSYNC]# PORT=4989 ; > USER3="uid=newnew2,ou=testing,dc=accpol,dc=com"; ns-activate.pl -D > "cn=Directory Manager" -w Secret123 -h localhost -p $PORT -Z newinst4 -I > $USER3 ; echo $? > uid=newnew2,ou=testing,dc=accpol,dc=com activated. > 0 > [root@ratangad MMR_WINSYNC]# PORT=4989 ; > USER3="uid=newnew2,ou=testing,dc=accpol,dc=com"; ns-activate.pl -D > "cn=Directory Manager" -w Secret123 -h localhost -p $PORT -Z newinst4 -I > $USER3 ; echo $? > uid=newnew2,ou=testing,dc=accpol,dc=com activated. > 0 > > This is where we expect the script to return 100, but it returns 0 always. This is the correct behavior. When the script correctly accomplishes its task, it returns zero. If something goes wrong, or a user was already activated or inactivated, then it returns an error code. This is a change in behavior, but the old behavior was wrong. There is still a potential issue regarding comment 2.
Upstream ticket: https://fedorahosted.org/389/ticket/49014
Fixed upstream
GSS Approved Z-Stream
Hello Marcel, The devel freeze date for RHEL-7.3.z batch 1 is approaching (November 1). Could you please give an approval and clone this bug for rhel-7.3.z? Thanks! --noriko
Fixing 7.4.0 flag first, which was mistakenly cleared.
dirsrvtests/tests/suites/plugins/accpol_test.py::test_glinact_nsact OK group dirsrv exists OK user dirsrv exists INFO:lib389.utils:Configuring Global account policy plugin, pwpolicy attributes and restarting the server INFO:lib389.utils:AccountInactivityLimit set to 12. Account will be inactivated if not accessed in 12 secs INFO:lib389.utils:add_users: Pass all of these as parameters suffix, subtree, userid and nousrs INFO:lib389.utils:Sleep for 3 secs to check if account is not inactivated, expected value 0 INFO:lib389.utils:Account activate/in-activate/status using ns-activate/inactivate/accountstatus.pl INFO:lib389.utils:Running ns-activate.pl for uuser uid=nsactusr1,ou=groups,dc=example,dc=com INFO:lib389.utils:output: uid=nsactusr1,ou=groups,dc=example,dc=com already activated. INFO:lib389.utils:Sleep for 10 secs to check if account is inactivated, expected value 19 INFO:lib389.utils:Account activate/in-activate/status using ns-activate/inactivate/accountstatus.pl INFO:lib389.utils:Running ns-activate.pl for uuser uid=nsactusr1,ou=groups,dc=example,dc=com INFO:lib389.utils:output: uid=nsactusr1,ou=groups,dc=example,dc=com already activated. INFO:lib389.utils:Account activate/in-activate/status using ns-activate/inactivate/accountstatus.pl INFO:lib389.utils:Running ns-accountstatus.pl for uuser uid=nsactusr1,ou=groups,dc=example,dc=com INFO:lib389.utils:output: uid=nsactusr1,ou=groups,dc=example,dc=com - inactivated (inactivity limit exceeded). INFO:lib389.utils:Enable account by replacing lastLoginTime/createTimeStamp/ModifyTimeStamp attribute INFO:lib389.utils:Account activate/in-activate/status using ns-activate/inactivate/accountstatus.pl INFO:lib389.utils:Running ns-accountstatus.pl for uuser uid=nsactusr1,ou=groups,dc=example,dc=com INFO:lib389.utils:output: uid=nsactusr1,ou=groups,dc=example,dc=com - activated. INFO:lib389.utils:del_users: Pass all of these as parameters suffix, subtree, userid and nousrs PASSEDINFO:lib389.utils:Disabling Global accpolicy plugin and removing pwpolicy attrs Instance slapd-standalone_1 removed. ====== 1 passed in 26.80 seconds ====== [0 root@qeos-130 ds]# rpm -qa |grep -i 389-ds 389-ds-base-1.3.6.1-13.el7.x86_64 389-ds-base-debuginfo-1.3.6.1-13.el7.x86_64 389-ds-base-snmp-1.3.6.1-13.el7.x86_64 389-ds-base-libs-1.3.6.1-13.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://access.redhat.com/errata/RHBA-2017:2086