Security limits

Edit online

Some IBM® i system limits relate to security, such as limits on the length of passwords and the number of user profiles on a system.

Table 1. Security limits
Security limits Value
Maximum number of entries for a user profile1, 2, 3 Start of change200 000 000End of change
Maximum number of objects that can be secured by an authorization list 16 777 215
Maximum number of private authorities to an authorization list4 Start of change199 999 999End of change
Maximum number of entries in a validation list 549 755 813
Maximum number of user profiles on a system6 Approximately 800 000
Maximum length of a password 128
Maximum number of profile handles in a job Approximately 20 000
Maximum number of profile tokens on the system Approximately 2 000 000
Maximum amount of storage in the system and basic user ASPs, or in each Independent ASP, for permanent objects owned by a single user profile5 8 589 934 592 TB
Maximum number of Kerberos authentication requests within a single job A degradation in performance in the processing of Kerberos authentication requests may occur at approximately 2 000 authentications per minute. To avoid this situation use load balancing to spread the authentication requests among multiple jobs.
Notes:
  1. A user profile contains four categories of entries: 1) every object owned by the profile, 2) every private authority the profile has to other objects, 3) every private authority to objects owned by this profile that other profiles have, and 4) every object for which this profile is the primary group. The sum of these categories equals the total number of entries for the profile.
  2. The operating system maintains internal user profiles that own objects that are shared or cannot be assigned to a single individual user (for example, QDBSHR owns shared database objects such as database formats, access paths, and so on). These internal user profiles are subject to the same limits as any other user profile on the system.
  3. Using authorization lists or group profiles reduces the number of private authorities and helps avoid this limit (see the Security topic in the information center).
  4. Limit is due to the maximum number of entries allowed for the user profile that owns the authorization list (one less because a category 01 entry is used for the ownership of the authorization list).
  5. Limit is not enforced when the maximum storage attribute of the user profile is *NOMAX.
  6. Since user profiles are stored in the QSYS library, this number can be less if the QSYS library contains objects of types *MODULE, *PGM, *QRYDFN, *SQLPKG or *SRVPGM because of internal space used by these objects.