Trusted Solaris Administrator's Procedures

Administering Systems in an Administrative Role

As described in the Trusted Solaris Administration Overview, users administer Trusted Solaris systems after having assumed a role. The programs and tools available to a role have a special property, the trusted path attribute to enable the commands to succeed. In the Trusted Solaris environment, the role root has very limited powers. The Security Administrator (usually called secadmin) and the System administrator (usually called admin), roles perform most tasks.

A user who can assume a role chooses the Assume Rolename Role option from the Trusted Path (TP) menu in the Front Panel, and types a password for the role. When the password is correct, an administrative role workspace at the label ADMIN_LOW becomes active with the trusted path attribute. The shell available in the role workspace is called a profile shell, which enables commands to execute securely. Each role can use only those tools in the rights profile(s) that are assigned to that role.

Accessing Administration Tools

The following table lists the Trusted Solaris administrative tools and where their use is described.

Solaris Management Console tool or equivalent commands, such as smuser(1M) and smrole(1M).

Used for most configuration of user accounts, hosts, and networks. Can update local files or name service databases. Can also launch legacy applications: dtterm(1) and dtappsession(1).

Note: Authorizations are used to control which tools or fields can be accessed by each role in the Solaris Management Console and which options can be used in the equivalent commands.

See "To Launch the Solaris Management Console".

Trusted Solaris administrative actions in the System_Admin Folder in the Application Management folder

Used to edit local files that the Solaris Management Console does not manage, such as /etc/system.

See "To Launch Local Administrative Actions".

Administrative commands and actions.

Used to perform tasks not covered by the Solaris Management Console or System_Admin programs.

See man pages section 1M: System Administration Commands.

Administering Remote Systems

Administrators can administer from remote hosts in several ways that are described in this guide, as summarized below:

After logging in to the local host and assuming a role, administrators can log in to a remote host from a terminal in their role workspace and use the commands rlogin(1), telnet(1), or ftp(1). See "To Log In Remotely From the Command Line" for how roles can log in remotely and work on the command line.
From a local host's CDE login screen, anyone can log directly into the CDE window system on a remote host (as described in "To Log In and Assume a Role"). . This works just as it does on a Solaris system.

After CDE remote login is complete, the CDE window environment from the remote host displays on the screen of the local host. An administrator can then assume a role from the Trusted Path menu and work as if logged in directly to the remote host.
Administrators can launch a Solaris Management Console (SMC), server that is running on a remote host. Accessing the SMC is described in "To Launch the Solaris Management Console".

The Application Manager can be started remotely by double-clicking the Application Manager icon from the Legacy Application list in the SMC. The Application Manager contains the System_Admin folder, a collection of programs to modify local system files that are not managed directly by the Solaris Management Console.
While working in a role workspace on a local host, the role can use the dtappsession(1) command to launch an Application Manager that runs and makes changes on the remote host. The dtappsession script starts an independent instance of the CDE Application Manager that runs on the remote host and displays on the local host. Unlike CDE remote login, dtappsession enables the administrator to work remotely within a local login session.

dtappsession is useful when a remote host does not have a monitor. For example, dtappsession is often used instead of CDE remote login when administering domains on large servers, such as a Sun Enterprise^TM 10000.