Bug 1379824
| Summary: | ns-accountstatus.pl shows wrong status for accounts inactivated by Account policy plugin | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Sankar Ramalingam <sramling> | |
| Component: | 389-ds-base | Assignee: | Noriko Hosoi <nhosoi> | |
| Status: | CLOSED ERRATA | QA Contact: | Viktor Ashirov <vashirov> | |
| Severity: | urgent | Docs Contact: | ||
| Priority: | urgent | |||
| Version: | 7.3 | CC: | arubin, enewland, mkolaja, mreynolds, msauton, nkinder, rmeggins, tlavigne | |
| Target Milestone: | rc | Keywords: | ZStream | |
| Target Release: | --- | |||
| Hardware: | x86_64 | |||
| OS: | Linux | |||
| Whiteboard: | ||||
| Fixed In Version: | 389-ds-base-1.3.6.1-3.el7 | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1390342 (view as bug list) | Environment: | ||
| Last Closed: | 2017-08-01 21:10:21 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 1390342 | |||
|
Description
Sankar Ramalingam
2016-09-27 18:38:20 UTC
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 The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days |