Oracle Solaris 11.2 Qualified User Attributes
By Glenn Faden on Apr 29, 2014
User security attributes are implemented in Oracle Solaris via an extensible set of keywords and values. The list of attributes is described in the user_attr(4) man page. These attributes are usually assigned to individual users via the useradd(1M) and usermod(1M) commands, or to roles via the roleadd(1M) and rolemod(1M) commands. Alternatively, the User Manager GUI can be used to manage many of these attributes. As an optimization, multiple attribute specifications can be grouped into hierarchical rights profiles, which can then be assigned to users and roles. The user_attr(4) database entries for each user and role can be stored locally on each host, or in an enterprise-wide LDAP directory.
Although the use of LDAP significantly improves administrative efficiency, it has not previously been possible to use the Solaris LDAP schema to qualify user attributes for individual hosts or collections of hosts (netgroups). The foundation for qualified user attributes was laid in Solaris 8 and is now implemented in Oracle Solaris 11.2. A new qualifier option can be used with the usermod and rolemod commands to indicate the host or netgroup where the key-value attributes apply. Qualified and unqualified attributes are maintained independently, and cannot be combined so distinct usermod and rolemod commands are required to manage each set of qualified or unqualified attributes. The userdel and roledel commands can now be used to remove a complete set of qualified attributes without affecting other qualified or unqualified attributes.
The policy for applying the appropriate set of user attributes follows the search order specified via the Name Service Switch service, and is cached by the Name Service Cache service. If the cache is empty or expired, a new query is initiated. By default, a local entry matching the named user or role has the highest precedence. If no local entry exists, an LDAP query is initiated which returns all qualified and unqualified sets of attributes matching the named user or role. The highest precedence is given to an entry whose hostname matches the current host. If not found, each entry qualified by a netgroup is checked to determine if the current host is a member. The search terminates if a matching netgroup is found. An unqualified has the lowest precedence. If a match is found it is cached to optimize subsequent queries. Note that the default attributes specified in each host's /etc/policy.conf file are also applied unless the user or role has been assigned the Stop profile.
Adding Host-Qualified Attributes
The -q option can be used to specify a hostname or a netgroup name. A netgroup name is distinguished by prepending it with a plus sign. In the following example, a user account is created in the LDAP directory, and assigned the System Administrator rights profile:
root@solaris# useradd -S ldap -m test
root@solaris# passwd test
Re-enter new Password:
root@solaris# usermod -q host1 -K profiles="System Administrator" test"
When the user test logs in to the host host1, she can enable profile-based execution via pfbash and act as the system administrator. However, those rights are not granted to her on any other system.
Note that qualified user attributes may be used to implement both permissive and restrictive policies. For example, user qualifiers may be combined with other restrictive attributes such as access_times, pam_policy, or the Stop profile.
Adding Netgroup-Qualified Attributes
A netgroup can contain a set of hosts, users, or other netgroups. The qualified attributes feature does not interpret user entries within netgroups. Furthermore, hierarchical netgroups, while supported, should be used with caution since their lookups are generally slower. Also note that if the same host is assigned to multiple netgroups, and a user is assigned qualified attributes using more than one of those netgroups, the best matching entry for the host is ambiguous since the first match can't be reliably predicted.
A netgroup can be created and assigned using the following commands:
root@solaris# ldapaddent -D "cn=Directory Manager" -f /tmp/mynetgroup netgroup
root@solaris# usermod -q +mynetgroup -K profiles="System Operator" test"
In this case, if the test user logs into host1 she will only have the System Administrator profile because the host qualifier has precedence over the netgroup qualifier. But when logging into host2, only the System Operator profile is granted.
Viewing a User's Attributes
Since multiple sets of qualified attributes can be assigned to a user, the tools for viewing attributes can return multiple settings. In general, the results returned depend on where these commands are executed. For example, the test user would see different results for the userattr command, depending on the current host:
test@host2# userattr profiles" System Operator
It is also possible to manage assignments in the format described in user_attr(4). The qualifier field that was previously documented as being Reserved for future use, is now actually used. When the ldapaddent(1M) command is used to populate the LDAP directory with user_attr entries, the qualifier field is interpreted properly.
The ldapaddent command can also be used to view the user_attr assignments. However it does no filtering, so a program like grep is required to look for specific entries.
test:host1:::profiles=System Administrator test:+mynetgroup:::profiles=System Operator
The getent(1M) command follows the name switch, and the effective entry is retrieved from the cache:
Removing Qualified Attributes
User attributes are generally removed using usermod or rolemod, and specifying the value to remove using -= or an empty value to clear it. For example, either of the following commands could be used to remove a qualified profile assignment:
root@solaris# usermod -q +mynetgroup -K profiles= test"
However, qualified entries must have at least one attribute specified. So the proper way to remove all the attributes in this case is to use userdel or roledel as follows:
Note that this command does not remove the account or affect any other attributes associated with the account.