To configure Vector to use Kerberos, you must set certain parameters in Configuration-By-Forms. In addition, connection attributes may be required depending on the requirements of the enterprise.

The following system components in Configuration-By-Forms are relevant:

When you configure Vector to use Kerberos, you should first check the basic configuration. The basic configuration consists of the mechanisms parameter and the domain parameter in the Security component.

For Vector to use Kerberos as a dynamic mechanism, the mechanism parameter must be set to kerberos. In Configuration-By-Forms, the mechanisms parameter is located in Security, Configure, System.

The setting should look similar to this:

In addition to the mechanism parameter, the domain parameter must be set to configure Vector to use Kerberos.

In Configuration-By-Forms, the domain parameter is located in Security, Configure, System, Mechanisms, Kerberos.

The domain parameter must contain the fully qualified host name of the local installation. This name corresponds to the Vector service principal name. For example, for machine foo.xyz.com, the value for the domain parameter should be “foo.xyz.com.” If the entry reads simply “foo,” edit and correct the entry.

The setting should look similar to this:

The Name Server can be configured to use Kerberos for authentication for all remote targets. If so configured, connection attempts on non-Kerberos targets will fail. Use the remote_mechanism parameter for this purpose.

In Configuration-By-Forms, the remote_mechanism parameter is located in the Name Server component. Add kerberos to the mechanism list (if not already added in the Security configuration), and specify kerberos as the value on the remote_mechanism parameter.

The setting should look similar to this:

In a homogeneous Kerberos environment, it is not necessary to add login/password information for the vnode definitions in netutil. They are ignored at connect time.

Heterogeneous Kerberos environments are those in which both Kerberos and non-Kerberos connection targets exist in the enterprise. In such an environment, the Name Server settings in Configuration-By-Forms must remain at their default values. The local client behavior must change, depending on the connection target.

To configure the client in a heterogeneous Kerberos environment, specify connection attributes for a vnode using the netutil utility.

Here is a sample vnode configuration in netutil:

To specify encryption, the following options are available in Configuration-By-Forms under the Net Server (also known as Communications Server) component:

Outbound connection items may be configured as connection attributes in netutil.

The following example specifies Kerberos encryption for all inbound connections:

Delegation provides an alternate method of acquiring and forwarding authentication. When delegation is configured, the Name Server generates authentication certificates as if it were the client.

This method requires Kerberos to be configured as both the local and remote authentication mechanism. The client process generates an authentication certificate for the local Name Server. The local Name Server, in turn, uses its delegation capabilities to generate an authentication certificate, and forwards the certificate on behalf of the client to the remote Name Server.

If delegation is not enabled, or Kerberos is not configured as the local authentication mechanism, then the Name Server cannot generate the remote authentication certificate. Instead, the client acquires the authentication certificate prior to making the remote connection. The client then forwards the credentials directly to the remote Name Server. Either method is valid for making secure connections through Kerberos.

The process of acquiring and forwarding authentication can be delegated to the Name Server.