Go to main content

Trusted Extensions Configuration and Administration

Exit Print View

Updated: December 2017
 
 

Using the LDAP Naming Service in Trusted Extensions

To achieve uniformity of user, host, and network attributes within a security domain with multiple Trusted Extensions systems, a naming service is used for distributing most configuration information. The svc:/system/name-service/switch service determines which naming service is used. LDAP is the recommended naming service for Trusted Extensions.

The LDAP Server can provide the LDAP naming service for Trusted Extensions and Oracle Solaris clients. The server must include Trusted Extensions network databases, and the Trusted Extensions clients must connect to the server over a multilevel port. The security administrator specifies the multilevel port during system configuration.

Typically, this multilevel port is configured in the global zone for the global zone. Therefore, a labeled zone does not have write access to the LDAP directory. Rather, labeled zones send read requests through the multilevel proxy service that is running on their system or another trusted system on the network. Trusted Extensions also supports an LDAP configuration of one directory server per label. Such a configuration is required when users have different credentials per label.

Locally Managed Trusted Extensions Systems

If a distributed naming service is not used at a site, administrators must ensure that configuration information for users, systems, and networks is identical on all systems. A change that is made on one system must be made on all systems.

On a locally managed Trusted Extensions system, configuration information is maintained in files in the /etc, /etc/security, and /etc/security/tsol directories, and by configuration properties in the name-service/switch SMF service.

Trusted Extensions LDAP Databases

Trusted Extensions extends the LDAP Server's schema to accommodate the tnrhdb and tnrhtp databases. Trusted Extensions defines two new attributes, ipTnetNumber and ipTnetTemplateName, and two new object classes, ipTnetTemplate and ipTnetHost.

The attribute definitions are as follows:

ipTnetNumber
( 1.3.6.1.1.1.1.34 NAME 'ipTnetNumber'
DESC 'Trusted network host or subnet address'
EQUALITY caseExactIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
SINGLE-VALUE )
ipTnetTemplateName
( 1.3.6.1.1.1.1.35 NAME 'ipTnetTemplateName'
DESC 'Trusted network template name'
EQUALITY caseExactIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
SINGLE-VALUE )

The object class definitions are as follows:

ipTnetTemplate
( 1.3.6.1.1.1.2.18 NAME 'ipTnetTemplate' SUP top STRUCTURAL
DESC 'Object class for Trusted network host templates'
MUST ( ipTnetTemplateName )
MAY ( SolarisAttrKeyValue ) )

ipTnetHost
( 1.3.6.1.1.1.2.19 NAME 'ipTnetHost' SUP top AUXILIARY
DESC 'Object class for Trusted network host/subnet address
to template mapping'
MUST ( ipTnetNumber $ ipTnetTemplateName ) )

The cipso template definition in LDAP is similar to the following:

ou=ipTnet,dc=example,dc=example1,dc=exampleco,dc=com
objectClass=top
objectClass=organizationalUnit
ou=ipTnet

ipTnetTemplateName=cipso,ou=ipTnet,dc=example,dc=example1,dc=exampleco,dc=com
objectClass=top
objectClass=ipTnetTemplate
ipTnetTemplateName=cipso
SolarisAttrKeyValue=host_type=cipso;doi=1;min_sl=ADMIN_LOW;max_sl=ADMIN_HIGH;

ipTnetNumber=0.0.0.0,ou=ipTnet,dc=example,dc=example1,dc=exampleco,dc=com
objectClass=top
objectClass=ipTnetTemplate
objectClass=ipTnetHost
ipTnetNumber=0.0.0.0
ipTnetTemplateName=internal