Security and Systems Management Newsletter for the IBM i             March 12, 2014 - Vol 4, Issue 4
Security Training from

Security software from Powertech

Skyview Partners

Security Training from The 400 School

Feature Article

Using Adopted Authority for Password Resets

By Dan Riehl -

Sometimes powerful IBM i Special Authorities are required by users which are not system administrators or security officers. For example, when users forget their passwords or disable their profiles through excessive failed attempts to log in, Help Desk personnel or the Operations staff need the ability to reset the password and re-enable the user account. The Special Authority required to perform these sensitive User Profile functions is called Security Administrator (*SECADM) Special Authority. In practice, All Object (*ALLOBJ) Special Authority is also needed to be able to perform these password resets. *ALLOBJ Special Authority is needed to ensure that the Help Desk or Operations Staff have enough authority to the User Profiles that they need to reset. Normally, User Profiles are created with a *PUBLIC authority of *Exclude, allowing changes only by very powerful system administrators which have *ALLOBJ and *SECADM special authority inherent in their user profiles.

The simple solution is to just give all these Help Desk and Operations users *SECADM and *ALLOBJ special authority. However, *SECADM and *ALLOBJ special authority also lets users create and change other attributes of user profiles, and *ALLOBJ provides unrestricted access to all files, libraries, programs, etc. You do not want to give these users carte blanche to create and change user profiles at will, and you really do NOT want to give them full access to all *SECADM and *ALLOBJ special authority full time. You want to give them only the ability to reset passwords and status for selected user profiles. After all, you don't want to give the Help Desk and Operations staff the ability to reset the passwords for QSECOFR and other powerful profiles. You also do not want them to have the *ALLOBJ authority, to be able to change payroll amounts or view/change other sensitive data. This article discusses a very good method to allow a user to 'borrow' the *SECADM and *ALLOBJ authority required to reset a user profile, but then return that borrowed authority as soon as that distinct task is completed. This method prevents the use of the borrowed authority to do tasks that are beyond the user's scope or responsibility.

Borrowing Special Authority

One of the best methods to provide temporary use of the *SECADM and *ALLOBJ special authority is to use the IBM i facility called Program Adoption of Authority(PAA). Adoption of authority provides for temporary use of an elevated level of authority to perform functions that the user is not normally authorized to do. Here we deal with adopting the *SECADM and *ALLOBJ special authority to allow a user to reset a user profile status and password.

The Big Picture

The adopted authority technique can be used to adopt any special authority, with an ultimate view of removing, as much as possible, the assignment of any User Special Authorities.


The purpose of the RESETUSER command is to give a help desk or operations user the temporary authority to reset the password and/or status of a user profile.

The command consists of two parts, the command definition and the CL program. In order to secure the command and program, and to configure the program adoption of authority correctly, there are instructions for creating the command and the program. These step by step instructions are found at the end of the article.

SafeGuards Built Into RESETUSER

We need to ensure that this command is not improperly used to reset the IBM-supplied user profiles like QSECOFR and QSYSOPR. You also want to ensure that the command cannot be used to reset the passwords for users who have powerful special authorities, such as *ALLOBJ, *SERVICE, *SAVSYS, *AUDIT, *IOSYSCFG and *SECADM. If these could be reset, it would provide a way for the user of the command to reset a password for the powerful profiles, sign on as that profile, and perform unauthorized activities.

Read More . .    and get the source code

In This Issue

Featured Article - RESETUSER command

Security Shorts - More Adopted Authority

Industry News and Calendar

Security Resources

Quick Links

Search Security Site for IBM i and i5/OS

SecureMyi Website

Security Training from The 400 School

SecureMyi Newsletter Home/Archives

Our Newsletter Sponsors

Platinum Sponsor

    The 400 School, Inc

Gold Sponsor


    Skyview Partners, Inc

Silver Sponsor

    Cilasoft Security Solutions

IBM i Security Resources

IBM i Security Videos - SecureMyi

SecureMyi Newsletter Archives

Search Security for IBM i

IBM i Security Ref - 6.1

IBM i Security Ref - 7.1


QAUDJRN Entry Layouts

RedBook - Security Guide IBM i

OSF - DataLoss DB

PCI Data Security Standard


HIPAA Resources

HITECH Enforcement

CISSP - Certification

Follow SecureMyi on Twitter

Follow SecureMyi on YouTube

Software from Cilasoft

Security Training from The 400 School
Security Services from
Security news and Events

Live Security Related Webcasts and Training for IBM i

April Events

Coffee with Carol: Cloud Security Review
with Carol Woodbury

Live Webcast - Presented by Skyview Partners
Wednesday, April 2 10:00am CDT
More Information and Register to Attend

Live Hands-On - Expanded Security Workshop for IBM i
with Dan Riehl

Training Workshop - April 8-11
Dan Riehl presents this 4-Day Live Online Hands-on Workshop.
More Information and Register to Attend

May Events

May 4-7 - COMMON - A User Group
2014 Annual Conference and Exposition - Orlando, FL
More Information and Register to Attend

Coffee with Carol: with Carol Woodbury
Security Considerations for Application Development including PCI Requirements

Live Webcast - Presented by Skyview Partners
Wednesday, May 14 10:00am CDT
More Information and Register to Attend

June Events

Live Hands-On - IBM i System Administration and Control Workshop
with Dan Riehl

Training Workshop - June 2-6
Dan Riehl presents this 5-Day Live Online Hands-on Workshop.
More Information and Register to Attend

Security software from Powertech

Skyview Partners

Security Training from The 400 School

Security Shorts - Adopted Authority Cannot Do Everything

By Dan Riehl

We often use "Adopted Authority" to allow a user to perform operations that they have no inherent authority to perform. For example, as shown in the Feature Article in this issue, many of us use adopted authority to allow help desk users to reset a password or reset a user status.

You can also use adopted authority to allow the help desk to create user profiles or change other attributes of existing user profiles. But there is one major caveat when creating or changing user profiles under adopted authority; adopted authority cannot be used to assign a user to a group profile.

As an example, a help desk user runs a program to create a user profile. The program adopts the authority of Security Officer (QSECOFR), temporarily making the user "all powerful."

But in order to assign a user to a group profile (or supplemental group profile), the help desk user must have his or her own authority to the group profile being assigned to the user. Adopted authority cannot be used to assign the group.

The IBM documentation states that the user creating or changing the profile must have *CHANGE and *OBJMGT rights to the group profile in order to assign a user to the group and that the authority cannot come from the use of adopted authority.

This bothered me, as I did not want to give the help desk users that much authority to groups that they may need to assign. With *CHANGE authority, the help desk users would be able to run jobs as the group or otherwise hijack the group. (For more information on this exposure, see my October 2012 article on Hijacking a User Profile.)

In my testing, I was able to confirm that I could remove the *EXECUTE right for the help desk user to the groups they need to assign, thereby preventing the misuse of the group profiles.

So, yes, you assign the help desk users *CHANGE and *OBJMGT rights to the group profile they need to assign and then remove their *EXECUTE rights, in order to protect the group from being misused.

It is interesting that the help desk users can change the other attributes of a user profile while running under QSECOFR adopted authority, but they cannot assign a new group to which they are not authorized.

See the IBM support document on this topic.

Sponsored Links

IBM i, iSeries and AS/400
Security Services from SecureMyi

Expert IBM i Security Consulting
IT Security and Compliance Group. LLC

In Depth Security Assessment of IBM i
Upgrade to QSECURITY level 40 or 50
Forensic Research and Analysis
Audit Assistance and Remediation
Security Training for IT and Audit Staff
Security Software Selection & Configuration
Customized Security/System Programming

Live Training from The 400 School, Inc

Customized IBM i (AS/400) Training -
    Presented Live at your offices

Live Online Hands-On Workshops

Intro RPG IV Programming
Intro RPG/400 Programming
IBM i COBOL Programming
Interactive Programming Workshops
Introduction to System Operations
Expanded System Operations Workshop
System Administration and Control
Expanded Security Workshop
Control Language Programming
IBM i Concepts and Facilities
Concepts & Control Language
Query Workshop

Security Training from

Send your IBM i Security and Systems Management News and Events!           Send your Questions, Comments, Tips and Stories

Copyright 2014 -, all rights reserved | St Louis MO 63017