Admin Alert: Creating an i5/OS User Profile Architecture
February 8, 2006 Joe Hertvik
|
Many of my Admin Alert columns have focused on how to configure and control i5/OS user profiles to meet two conflicting goals: to increase user productivity and to protect the system from internal and external threats. While I often discuss the mechanics of user profile administration, it’s also worthwhile to discuss the philosophy and architecture behind user profile creation and how you can use that architecture to meet corporate needs. A user profile architecture is a structure of i5/OS and OS/400 features and configurations that determine how to build user profiles for maximum efficiency, security, and organizational needs. Some elements, such as security issues, are basic to most IT shops and take on a standard form within an i5, iSeries, or AS/400 environment. Others elements, such as user names, are more creative and may not follow a set pattern. Your architectural elements form the rules by which you build and manage your user environment, and a starter environment would include the following items.
This architecture also encompasses standards for how things should be done, procedures for administrators and users to follow, and configuration settings that make the whole thing work. Let’s look at each item in turn to see how it affects your user profile architecture and system effectiveness. What’s in a User Profile Name? For a secure system, each user should be assigned a unique user profile that is created only for their needs. Policies should be put in place to discourage users from sharing their user profiles and passwords, and penalties could be assessed for users who violate policies. In i5/OS and OS/400, user profile names are limited to ten characters or less, and there is no one standard naming convention for a user profile name. In my experience, I have found that there are two schools of thought for how user profiles should be named. The first school believes that a user profile name should correlate to some variation on the user name or the job function that user is performing. Using this standard, if user Barney Brown worked in the accounting department of the Bubba Gump Company, I could format his user profile in many different ways. I could use a variation of his first or last name, where the user profile could be named ‘BARNEY’, ‘BARNEYB’, ‘BBROWN’, or I could incorporate his department or company into the profile with names like ‘ACCTBROWN’, ‘ACBROWN’, ‘ACCT01’, or ‘BGACBROWN’. By using an abbreviated user profile name that describes the user, it becomes easier for a system administrator to identify jobs, objects, or output belonging to that particular user. On the negative end, using a standardized naming convention that describes the user could also make it easier for other users to guess user names on the system, and that could encourage hacking and other unauthorized access. The second school of user profile naming conventions believes that user profiles should be somewhat meaningless, where the names provide no clue to user identity at all. Under this convention, I might assign our users a generic name that consisted of a single letter followed by a user number, creating names like U00001, U00002, and U00003. This naming convention would guarantee anonymity and make it difficult for outsiders to guess user profile names. The downside is that it also makes it more difficult to administer the system because there are no obvious clues as to which user belongs to which profile. The other thing to consider is how i5/OS user profile names could affect user names on non-i5, iSeries, or AS/400 systems. If you want to use the same user ID name on all systems, the i5/OS user profile structure will limit all names to a ten-character user ID on each system, regardless of whether or not that system supports longer character names. What a Non-Trivial Thing a Password Should Be By design, whenever i5/OS creates a new user profile, it provides that profile with a default password (where the password value is the same as the user name). This is a serious security problem and should not be tolerated on your system. For new users, I recommend that you assign a starting password for that profile that is non-trivial, meaning that it made up of both letters and numbers and does not contain a common word or a word that would normally be associated with your user. In i5/OS V5R1 and above, minimum and maximum user passwords lengths can be set anywhere from 1 to 128 characters and the passwords can be configured to contain upper-case and lower-chase characters as well as special characters, such as spaces, that are not normally used on i5 and iSeries boxes. This support is configured through the Password level system value (QPWDLVL) but IBM recommends that you limit passwords to ten characters or less if your system communicates with any other system that uses ten character passwords. There are also several system values that you can set to prevent users from choosing easily-guessed trivial passwords. Password-related system values can force users to include a number in their password (to prevent their password from only being a common word), limit adjacent numbers in a password (which prevents users from embedding their phone extension or social security number in the password), limit specific characters from being used (such as vowels), limit repeating characters (so the user cannot type in an easy password such as ‘AAAAAA’), and to limit adjacent repeating characters in a password (to make it harder for a user to choose several common words, such as ‘PASSWORD’). It’s also worthwhile to assign a significant value to the Duplicate Password Control system value (QPWDRQDDIF), which controls how often a user can reuse a password that they’ve already used. This help prevents recycling for passwords that may have been previously compromised. In general, the more you can do to force the users to choose non-trivial passwords, the more secure your system will become. All of these password security-related system values can be viewed by entering the following Work with System Values command (WRKSYSVAL) on a command line: WRKSYSVAL SYSVAL(*SEC) For a good reference on creating non-trivial passwords, check out an article called Creating Effective Passwords by the dean of i5/OS security, Wayne O. Evans. For information on detecting and disabling default passwords, see Dealing with Default OS/400 Passwords. When a Password Passes Its Time User passwords are frequently discovered or given away, and you run a higher risk of unauthorized access if you don’t force your users to change their passwords on a regular basis. To combat this, i5/OS and OS/400 feature a Password Expiration Interval system value (QPWDEXPITV) that specifies how long a user password can be active on the system before its associated profile is marked as expired. By default, QPWDEXPITV is set to *NOMAX, which means that unless you change this value, your passwords will never expire. You can change QPWDEXPITV to a value between 1 and 366 days, and that change will take effect immediately. I’ve always found 90 to 180 days to be a good time period for forced password changes. Be careful, however, because QPWDEXPITV password checking can be overridden in a user profile by changing the profile’s Password Expiration Interval parameter (PWDEXPITV) to a value that is different than the QPWDEXPITV value. So if you’re not careful, someone can still retain a *NOMAX password without your knowledge. For more information about password expiration intervals, see Making OS/400 Profiles a Little More Secure. Setting up a Class System Another key user profile architectural element is the various user classes and special authorities that you can assign to each user profile. By using classes and profiles correctly, you can categorize your users into various classes ranging from a normal user with no special authorities all the way up to a security officer. Be stingy here and only assign the authorities that the user needs to get their jobs done. In particular, the *SECOFR user class and *ALLOBJ special authority should only be assigned on an absolute as-needed basis. For more information on these items, see A Checklist for Creating OS/400 User Profiles, Part 1 Accounting for Expired and Terminated Users When dealing with user profiles, it’s extremely important to insure that terminated, or inactive users, are regularly disabled or purged in the system. Architecturally, there are several ways to do this. You can disable a user profile manually by setting the profile’s Status (STATUS) parameter to *DISABLED. You can automatically disable or delete a user profile on a certain date by using expiration schedule entries from the Security Tools menu (GO SECTOOLS). You can also set up the Analyze Profile Activity command (ANZPRFACT) to automatically disable any user profile that hasn’t been used in a certain number of days. ANZPRFACT comes in handy when you want to automatically disable active user profiles for people who may have left your division or company without your knowledge. For more information on these techniques, see Making OS/400 Profiles a Little More Secure, The Joys and Pains of Automatically Disabling User Profiles, and Bullet-Proofing User Profiles from Automatic Disablement, Expiration. Protecting User Profiles from Unauthorized Usage The final element to consider in our user profile architecture is how you can prevent unauthorized personnel from guessing or signing on with a user profile: otherwise known as sign-on security. There are several ways to discourage unauthorized usage by both internal and external users, but I have found the following techniques to be very effective. If the needs of your shop allow, you can restrict your users from signing on to more than one device at a time by setting the Limit Device Sessions system value (QLMTDEVSSN) to ‘1’. While this will not stop a user from using a group job or calling the system request menu, it will prevent password sharing by forcing each user at each workstation to have their own user profile and password. But unauthorized access can occur from the outside of the company as well as from the inside, particularly when a hacker discovers how to open up a telnet session to your i5/OS box. To cut down on brute-force attacks–where the user can just keep trying different combinations of i5/OS user profile names and password until one opens the door–IBM provides two system values that can slow down or stop brute force attacks by disabling any devices or passwords the hacker is using to try to infiltrate your session. The Maximum sign-on attempts allowed system value (QMAXSIGN) specifies how many incorrect sign-on attempts the system will allow before it takes action. An incorrect sign-on attempt happens whenever a user enters an incorrect user ID or password from a session. Once a user reaches the number of incorrect sign-on attempts specified in QMAXSIGN, the system will automatically take the action specified in the Action to take for failed sign-on attempts system value (QMAXSGNACN). The QMAXSGNACN value can be configured to disable the device the incorrect sign-on attempts came from, to disable the user profile that is being used in the sign-on attempts, or to disable both the device and the user profile where the sign-on attempts are originating from. By default, QMAXSIGN is set to 3 attempts and QMAXSGNACN is shipped with a value of ‘3’, which disables both the device and the user profile. Be warned, however, that while the QMAXSIGN and QMAXSGNACN combination is valuable for stopping unauthorized access attempts, it can result in a lot of extra administrative work in re-enabling user profiles that were accidentally disabled. For more information on these values, see The Joys and Pains of Automatically Disabling User Profiles. RELATED STORIES A Checklist for Creating OS/400 User Profiles, Part I A Checklist for Creating OS/400 User Profiles, Part II Bullet-Proofing User Profiles from Automatic Disablement, Expiration Dealing with Default OS/400 Passwords |
