IBM i security configuration is usually pretty straightforward, but there are a few things that, misconfigured, can produce results you don’t expect. Carol explores some of those areas of the system.
In most areas, IBM has done a decent job of making it obvious what the outcome of a particular setting will be, but some outcomes aren’t so obvious. In addition, I’ve seen administrators turn a straightforward configuration upside down and make it very difficult to understand the actual result of their configuration choice. In this article, I explain these scenarios in hopes that you will take a look at your own configurations and make sure you’re getting the outcome you think you are.
QAUDLVL and QAUDLVL2 System Values
When auditing was first added to the system back in V1R3, the number of values one could specify in the action auditing system value QAUDLVL was more than enough. But through the years, additional values were defined for action auditing and some of the original values were subsetted, allowing you to be more granular in the actions audited. With the ability to specify more values for QAUDLVL, the system value could be “filled up.” So IBM created an overflow system value called QAUDLVL2. The “bite” here is that you can’t simply start to specify values in QAUDLVL2 and expect the system to recognize them. Unless you specify *AUDLVL2 in QAUDLVL, the system will never look in QAUDLVL2. I’ve seen clients think they’re using QAUDLVL2, but they haven’t specified *AUDLVL2 in QAUDLVL. If you’re using QAUDLVL2, check QAUDLVL to make sure you’ve included *AUDLVL2.
QPWDRULES System Values
For years, I’ve been advocating the use of the QPWDRULES system value. It provides many more options for specifying password composition rules than the individual system values that define the password rules (e.g., QPWDMINLEN, QPWDMAXLEN, QPWDRQDGT, etc.) The bite with this system value is that, once you start using it, you must specify all of your rules because the system stops looking at the individual system values. I’ve seen clients specify the values *LMTPRFNAME and *ALLCRTCHG but not specify the minimum and maximum lengths. The net effect is that the next time a user changes their password, while their profile name can’t be part of the password, they can specify a password of any length, including a length of 1!
Authorization Lists
As you know, I’m a big fan of using authorization lists. They’re an easy way to specify the same authority for many objects, including the *PUBLIC authority of those objects. What I’ve seen happen is that many people fail to specify that the public authority should come from the authorization list and just assume that it does. The bite is that just because an object is secured with an authorization list doesn’t mean the *PUBLIC authority is coming from the list. To have an object’s public authority come from an authorization list, one must specify *PUBLIC(*AUTL). I’ve seen administrators get confused because they’ve set the public authority of an authorization list to *EXCLUDE but fail to point the objects’ public authority to the list and wonder why users can access the files. In most cases, it’s because the objects’ *PUBLIC authority defaulted to *CHANGE (the default value of the QCRTAUT system value) when the objects were created, providing users with the ability to both read and update the files.
QPWDEXPITV System Value and the PWDEXPITV User Profile Attribute
I have to admit that this is one of the strangest configurations I’ve ever seen, but, unfortunately, I have seen it more than once. With this configuration, the system value that determines how often a password must be changed (QPWDEXPITV) is set to *NOMAX, meaning that users’ passwords never expire (that is, never have to be changed.) Unfortunately, I see this system value set to *NOMAX way more often than one would think. But what makes this configuration so strange is that the user profile setting for password expiration is set to a reasonable value such as 90. Since the user profile attribute overrides the system value, for the profiles configured in this manner, the passwords must be changed every 90 days. While this configuration seems to accomplish the intended goal of having profiles’ passwords changed every 90 days, I find this configuration problematic on multiple levels. First, auditors are going to look at the setting for QPWDEXPITV, see it set to *NOMAX, and flag it as an issue. Then, you’re going to have to spend time convincing them that users actually do have to change their passwords. Why do you want to waste your time on that? Second, while I agree that service accounts are typically set to have a non-expiring password, why risk forgetting to override this value for all other profiles just to make sure that the next time you create a service account, it’s created with a non-expiring password? Unless you create more service accounts than traditional user profiles (which I’ve never seen happen), this makes no sense. To me, the risk of forgetting to override this setting for regular accounts is far greater than forgetting to set a service account to have a non-expiring password.
Summary
I hope everyone takes a few moments to ensure you don’t have any of the configurations that I’ve just described. You’ve taken the time to use the security features of IBM i, so I recommend you make sure you’re getting the results you intended.
Carol Woodbury is President and CTO of DXR Security and has over 30 years’ experience with IBM i Security. She started her career as Security Team Leader and Chief Engineering Manager for iSeries Security at IBM in Rochester, MN. Since leaving IBM, she has co-founded two companies – SkyView Partners and DXR Security. Her current company - DXR Security - specializes in penetration testing for IBM i. Her practical experience together with her intimate knowledge of the system combine for a unique viewpoint and experience level that cannot be matched.
Carol is known world-wide as an author and award-winning speaker on security technology, specializing in IBM i Security topics. She has written seven books on IBM i Security. Carol has been named an IBM Champion since 2018 and holds her CISSP and CRISC security certifications.
MC Press books written by Carol Woodbury available now on the MC Press Bookstore.
 |
||
 |
|
IBM i Security Administration and Compliance: Third Edition Don't miss the newest edition by the industry’s #1 IBM i security expert. List Price $71.95 Now On Sale
|
 |
|
IBM i Security Administration and Compliance: Second Edition Get the must-have guide by the industry’s #1 security authority. List Price $71.95 Now On Sale
|
|
||
 |
|
IBM i Security Administration and Compliance For beginners to veterans, this is the definitive security resource. List Price $69.95
Now On Sale
|
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online