-
Sun
November 20, 2008
Administrators in the Fishworks Appliance Kit
As discussed in
entries,
many of the problems we solved in building the
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
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.
Best Practices
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.
[1] The 7000 series can also
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.