As discussed in href="http://blogs.sun.com/bmc/entry/fishworks_now_it_can_be">other blog
many of the problems we solved in building the href="http://www.sun.com/storage/disk_systems/unified_storage/">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
LDAP. Moreover, administrators
need their own properties which were specific to our framework, such as
whether they required a href="http://blogs.sun.com/wdp/entry/session_annotations">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.
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:
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?
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
in its design -- I'll cover this feature in a later entry.
 The 7000 series can also href="http://blogs.sun.com/wdp/entry/windows_interoperability">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.