Go to main content

Remote Administration Daemon Client User's Guide

Exit Print View

Updated: November 2020
 
 

Generic Security Services API Transport in RAD

RAD includes a Generic Security Services API (GSS-API) transport, which allows secure administrative communication between the client and the server.

The following examples shows the configuration parameters when configuring GSS-API transport in RAD:

DNS domain name = example.com
RAD client = client.example.com
RAD server = server.example.com
Kerberos realm name = EXAMPLE.COM
Kerberos administrative principal = adjdoe/admin
User/principal = jdoe

Securing Messages Using G-RAD

The GSS-API transport allows secure messaging for RAD applications.

The GSS-API transport leverages environments that have deployed secure authentication protocols, such as Kerberos. A URI transport element is added to the existing schema to indicate the GSS-API RAD (G-RAD) transport as follows:

radg://[user@]host[:port] 

radg specifies the transport indicating G-RAD support.

If the user is not specified, then the invoking user is utilized. In the case of Kerberos, the user is mapped into a user principal.

If the host is not specified, then failure is returned.

If the port is not specified, then the default port is 6789.

G-RAD Applications Using Kerberos

The RAD server must be configured to host Kerberos and to utilize the G-RAD transport for Kerberos. Configuring the RAD server includes creating a rad service principal for the system and adding the associated keys to its key table. For more information about configuring the RAD server with Kerberos, see Configuring Kerberos Clients in Managing Kerberos in Oracle Solaris 11.4.

After the system is configured for Kerberos, create the rad service principal, such as rad/server.example.com, on the RAD server. You can authenticate as a RAD user on the RAD client by using the kinit command or by authenticating through PAM with pam_krb5.

Using the RAD client's initial authentication through the system key table file (/etc/krb5/krb5.keytab), the root user can also be configured as a RAD user in Kerberos. The host service principal is used in this scenario, therefore the client must be configured as a Kerberos system. For more information, see Configuring Kerberos Clients in Managing Kerberos in Oracle Solaris 11.4.

To authorize RAD requests as root, the RAD server must also map the authenticated host service principal of the client to the local root user. For example, on the RAD server, the /etc/krb5/krb5.conf file is updated to include auth_to_local_names in the realms section as follows:

server# cat /etc/krb5/krb5.conf
...
[realms]
    EXAMPLE.COM = {
        ...
        auth_to_local_names = {
            host/client.example.com = root 
        }
    }
Example 46  G-RAD Application Example

The following example shows G-RAD transport utilization with live zone migration as a privileged user:

client$ id
uid=1234567(mre) gid=1(other)
client $ profiles
Zone Configuration
Zone Migration
Basic Solaris User
All
client$ auths
solaris.admin.wusb.read,solaris.mail.mailq,solaris.network.autoconf.read,
solaris.zone.config/zone1,solaris.zone.migrate/zone1
client$ kinit
Password for mre@EXAMPLE.COM:
client$ pfexec /usr/sbin/zoneadm -z zone1 migrate radg://server
zoneadm: zone 'zone1': Using existing zone configuration on 
destination.
zoneadm: zone 'zone1': Attaching zone.
zoneadm: zone 'zone1': Booting zone in 'migrating-in' mode.
zoneadm: zone 'zone1': Checking migration compatibility.
zoneadm: zone 'zone1': Performing initial copy (total 8192MB).
...
zoneadm: zone 'zone1': Migration successful.