Headless System Configuration in Trusted Extensions (Task Map)

On headless systems, a console is connected by means of a serial line to a terminal emulator window. The line is typically secured by the tip command. Depending on what type of second system is available, you can use one of the following methods to configure a headless system. The methods are listed from more secure to less secure in the following table. These instructions also apply to remote systems.

Task	Description	For Instructions
Enable remote login by the `root` user.	If you are not using LDAP, you must initially log in to the headless system as `root`. If you are using LDAP, you can skip this procedure.	Enable Remote Login by `root` User in Trusted Extensions
Enable remote login.	Enable remote login for a user who can assume the `root` role or another administrative role.	Enable Remote Login by a Role in Trusted Extensions
	Enable the administration of Trusted Extensions systems from an unlabeled system.	Enable Remote Login From an Unlabeled System
	Enable a user to access the global zone on a headless system.	How to Enable Specific Users to Log In Remotely to the Global Zone in Trusted Extensions
(Optional) Enable the display of administrative GUIs.	Enable administrative GUIs that run on the headless system to display on the desktop system.	Enable the Remote Display of Administrative GUIs
(Optional) Enable virtual network computing (vnc)	From any client, uses the Xvnc server on the remote Trusted Extensions to display a multilevel session back to the client.	How to Use Xvnc to Remotely Access a Trusted Extensions System
Choose a configuration and administration method to set up the headless system.	Assume a role or become superuser to administer the remote system.	Use the `rlogin` or `ssh` Command to Log In and Administer a Headless System in Trusted Extensions
	Use the Solaris Management Console on the headless system.	Use a Remote Solaris Management Console to Administer in the Files Scope
	If you have no windowing system, you can use serial login as superuser. This procedure is insecure.	No configuration is required.

Note - Consult your security policy to determine which methods of remote administration are permissible at your site.

Enable Remote Login by `root` User in Trusted Extensions

As in the Solaris OS, root can log in remotely from a labeled system when the CONSOLE entry is disabled.

If you plan to administer a remote system by editing local files, use this procedure.

In the trusted editor, comment out the CONSOLE= line in the /etc/default/login file.
```
# /usr/dt/bin/trusted_edit /etc/default/login
```
The edited line appears similar to the following:
```
#CONSOLE=/dev/console
```
Permit root user login over an ssh connection.
Modify the /etc/ssh/sshd_config file. By default, ssh is enabled on a Solaris system.
```
# /usr/dt/bin/trusted_edit /etc/ssh/sshd_config
```
The edited line appears similar to the following:
```
PermitRootLogin yes
```

Next Steps

To log in as the root user from an unlabeled system, you must also complete Enable Remote Login From an Unlabeled System.

To enable remote login by a role, continue with Enable Remote Login by a Role in Trusted Extensions.

Enable Remote Login by a Role in Trusted Extensions

Follow this procedure only if you must administer a headless system by using the rlogin or ssh command.

Configuration errors can be debugged remotely.

Before You Begin

If you are using local files to administer the remote system, you have completed Enable Remote Login by root User in Trusted Extensions. Then, as the root user, perform this task on both systems.

On both systems, identify the other system as a labeled system.
The desktop system and the headless system must identify each other as using the identical security template. For the procedure, see How to Assign a Security Template to a Host or a Group of Hosts.
To assign a temporary label, see Example 6-1.
On both systems, create identical users and roles.
The names and IDs must be identical, and the role must be assigned to the user on both systems. To create users and roles, see Creating Roles and Users in Trusted Extensions.

To contact a remote Solaris Management Console, do the following on both systems:

Add the other system's host name and IP address to the /etc/hosts file.

# /usr/dt/bin/trusted_edit /etc/hosts

127.0.0.1    localhost    
192.168.66.66    local-system-name    loghost
192.168.66.12    remote-system-name

To allow remote role assumption, modify the pam.conf file to relax PAM policy.

Copy the /etc/pam.conf file to /etc/pam.conf.orig.
```
# cp /etc/pam.conf /etc/pam.conf.orig
```
In the trusted editor, open the pam.conf file.
```
# /usr/dt/bin/trusted_edit /etc/pam.conf
```
Copy the default entries under Account management.
In each copied entry, change other to smcconsole.

To the copied pam_roles.so.1 entry, add allow_remote.

Use the Tab key between fields. This section now appears similar to the following:

# Solaris Management Console definition for Account management
#
smcconsole   account requisite   pam_roles.so.1   allow_remote
smcconsole   account required    pam_unix_account.so.1
smcconsole   account required    pam_tsol_account.so.1

# Default definition for Account management
# Used when service name is not explicitly mentioned for account management
#
other   account requisite    pam_roles.so.1
other   account required     pam_unix_account.so.1
other   account required     pam_tsol_account.so.1

Save the file and exit the editor.
(Optional) Copy the file to /etc/pam.conf.site.
```
# cp /etc/pam.conf /etc/pam.conf.site
```
If you upgrade the system to a later release, you must then evaluate if you should copy the changes from /etc/pam.conf.site into the pam.conf file.

Example 6-1 Creating a Temporary Definition of a Trusted Extensions Host Type

In this example, the administrator wants to start configuring a remote Trusted Extensions system before the host type definitions are set up. To do so, the administrator uses the tnctl command on the remote system to temporarily define the host type of the desktop system:

remote-TX# tnctl -h desktop-TX:cipso

Later, the administrator wants to reach the remote Trusted Extensions system from a desktop system that is not configured with Trusted Extensions. In this case, the administrator uses the tnctl command on the remote system to temporarily define the host type of the desktop system as an unlabeled system that runs at the ADMIN_LOW label:

remote-TX# tnctl -h desktop-TX:admin_low

Enable Remote Login From an Unlabeled System

Before You Begin

This procedure is not secure.

You have relaxed PAM policy to allow remote role assumption, as described in Enable Remote Login by a Role in Trusted Extensions.

On the trusted system, apply the appropriate security template to the unlabeled system.
Caution - With the default settings, another unlabeled system could log in and administer the remote system. Therefore, you must change the 0.0.0.0 network default from ADMIN_LOW to a different label. For the procedure, see How to Limit the Hosts That Can Be Contacted on the Trusted Network.
In the trusted editor, open the /etc/pam.conf file.
```
# /usr/dt/bin/trusted_edit /etc/pam.conf
```
Find the smcconsole entries.

Add allow_unlabeled to the tsol_account module.

Use the Tab key between fields.

smcconsole   account required  pam_tsol_account.so.1 allow_unlabeled

After your edits, this section appears similar to the following:

# Solaris Management Console definition for Account management
#
smcconsole  account  requisite      pam_roles.so.1    allow_remote
smcconsole  account  required       pam_unix_account.so.1
smcconsole  account  required       pam_tsol_account.so.1 allow_unlabeled

Use a Remote Solaris Management Console to Administer in the Files Scope

If you are not using LDAP, and you want to use the Solaris Management Console on a remote system, you enable remote connection to the Console. This procedure is not sufficient to enable access for the LDAP scope.

To enable access for the LDAP scope, you must complete all the procedures in Configuring the Solaris Management Console for LDAP (Task Map).

Before You Begin

Both systems are labeled systems.

You have completed the following procedures:

Complete Enable the Solaris Management Console to Accept Network Communications.
On the desktop system, become a user that is defined identically on both systems.
On the desktop system, assume the role that is defined identically on both systems.
On the desktop system, start the Solaris Management Console.
```
# /usr/sbin/smc &
```
In the Server dialog box, type the name of the headless system.
Then, choose the Scope=Files toolbox.
```
This Computer (remote-system: Scope=Files, Policy=TSOL)
```

Enable the Remote Display of Administrative GUIs

The procedure for remote display on a desktop is identical to the procedure on a Solaris system that is not configured with Trusted Extensions. This procedure is placed here for convenience.

On the desktop system, enable processes from the headless system to display.
1. Enable the headless system to access the X server on the desktop system.
```
desktop $ xhost + headless-host
```
2. Determine the value of the desktop's DISPLAY variable.
```
desktop $ echo $DISPLAY
:n.n
```
On the headless system, set the DISPLAY variable to the desktop system.
```
headless $ DISPLAY=desktop:n.n
headless $ export DISPLAY=n:n
```

Use the `rlogin` or `ssh` Command to Log In and Administer a Headless System in Trusted Extensions

This procedure enables you to use the command line and the txzonemgr GUI to administer a headless system as superuser or as a role.

Note - Remote login by using the rlogin command is less secure than remote login by using the ssh command.

To use the Solaris Management Console to administer a remote system does not require you to use a remote login command. For the procedure, see How to Remotely Administer Systems by Using the Solaris Management Console From a Trusted Extensions System.

Before You Begin

You have completed Enable Remote Login by a Role in Trusted Extensions.

You are a user who is enabled to log in to the headless system with that same user name and user ID, and you can assume the same role on the headless system that you can assume on the desktop system.

On the desktop system, enable processes from the headless system to display.
```
desktop $ xhost + headless-host
desktop $ echo $DISPLAY
:n.n
```
Ensure that you are the user who is identically defined on both systems.

From a terminal window, remotely log in to the headless system.

Use the ssh command to log in:

desktop $ ssh -l identical-username headless
Password: Type the user's password
headless $

Or, use the rlogin command to log in:

desktop # rlogin headless
Password: Type the user's password
headless $

Assume the role that is defined identically on both systems.
Use the same terminal window. For example, assume the root role.
```
headless $ su - root
Password: Type the root password
```
You are now in the global zone. You can now use this terminal to administer the headless system from the command line.
Enable processes on the headless system to display on the desktop system.
Note - You can also display remote GUIs by logging in with the ssh -X command. For more information, see the ssh(1) man page. For an example, see Example 6-2.
```
headless $  DISPLAY desktop:n.n
headless $ export DISPLAY=n:n
```
You can now administer the headless system by using Trusted Extensions GUIs. For example, start the txzonemgr GUI:
```
headless $ /usr/sbin/txzonemgr
```
The Labeled Zone Manager runs on the remote system and displays on the desktop system.
(Optional) Access Trusted CDE actions.
To open and safely close the Application Manager, see How to Remotely Administer Trusted Extensions With dtappsession.

Example 6-2 Configuring Labeled Zones on a Headless System

In this example, the administrator uses the txzonemgr GUI to configure labeled zones on a labeled headless system from a labeled desktop system. As in the Solaris OS, the administrator enables X server access to the desktop system by using the -X option to the ssh command. The user install1 is defined identically on both systems, and can assume the role remoterole.

TXdesk1 $ xhost + TXnohead4
TXdesk1 $ whoami
install1

TXdesk1 $ ssh -X -l install1 TXnohead4
Password: Ins1PwD1
TXnohead4 $

To reach the global zone, the administrator assumes the role remoterole. This role is defined identically on both systems.

TXnohead4 # su - remoterole
Password: abcd1EFG

Then, the administrator starts the txzonemgr GUI.

TXnohead4 $ /usr/sbin/txzonemgr &

The Labeled Zone Manager runs on the headless system and displays on the desktop system.