Administrators in the Fishworks Appliance Kit
By William Pijewski on Nov 20, 2008
As discussed in other blog entries, many of the problems we solved in building the Sun Storage 7000 series were not specific to the NAS market. Moreover, the appliance kit framework we built solves many problems associated with an appliance in any domain -- that is, in addition to providing new innovative features, the appliance kit exposes and clarifies existing Solaris abstractions. In that vein, we needed a system to manage which users function as administrators of the appliance. We wanted the capability to pull users from an existing directory service, such as NIS or LDAP. Moreover, administrators need their own properties which were specific to our framework, such as whether they required a session annotation, or were a kiosk user. Finally, administrators have several user preferences which customize their environment to their liking, such as their initial login screen or character locale.
The 7000 series functions as a NIS and LDAP client1 and queries those directory services for information about users. These directory services consolidate the management of users in that single place, and allow a user's password and other properties (UID, home directory, etc.) to remain consistent throughout an entire organization. Adding a administrator from a directory service allows that user to login to the 7000 series and administer the appliance. Attributes and passwords for these directory users are stored in a directory service, and the appliance authenticates those administrators through a directory service. Administrators can also be added locally, in which case passwords for those users are stored locally on the appliance. These local users must be added to each appliance separately.
When our team was discussing how users should administer the appliance, we decided that the best practice was to add all administrators from a directory service and forego adding any local users. We established this best practice for the following reasons:
- Simplified management of users. If an employee changes his password, that change will take effect on all machines.
No UID conflicts. Because local users are given UIDs starting from 2000000000 in the order in which they're added, two local users on different appliances can have different UIDs, or even worse, the same UID can represent two different users. Even though these local users should not be used to access data, local users are no different than any other user on a Solaris system -- they can be used in establishing permissions on the root directory of a filesystem. If a particular user requires the same UID across several machines, shouldn't that user be stored in a directory service?
- No orphaned accounts. When an employee leaves a company, only the user account in the directory service must be deleted. The administrative accounts added to the appliance will not function if that user cannot be resolved in the directory service. These users are called degraded users, and while they should be cleaned up as part of normal housekeeping, they pose no security risk since they cannot login.
We've had some beta customers request the ability to prevent any local users on an appliance and restrict all administrators (other than root, of course) to be stored in a directory service. We'll work on this feature for the next software update. The appliance kit also has a rich set of fine-grained access controls for administrators which closely resembles RBAC in its design -- I'll cover this feature in a later entry.
 The 7000 series can also join an Active Directory domain and communicate with a domain controller for the purposes of authenticating CIFS clients. However, support for pulling administrators from Active Directory is not currently supported and will be coming a future software update.