• Sun
    November 20, 2008

Administrators in the Fishworks Appliance Kit

Guest Author

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
NIS or
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.

The 7000
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 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.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.