on the Gateway Server machines, installing the vendor-provided dfs_login and dfs_logout commands on the NFS clients, configuring Kerberos on the NFS clients, and configuring the remote authentication service on both the Gateway Server machines and the NFS clients. However, authentication requires no administrative measures, and user passwords are never sent in the clear.

Note: The dfs_login and dfs_logout commands are not provided with DFS; these commands can be used only if they are available from your NFS vendor and have been installed on an NFS client. If these commands are not available, use the dfsgw add and dfsgw delete commands, which work in a similar fashion. See your NFS vendor documentation for the availability and use of the dfs_login and dfs_logout commands.

The dfsgw add and dfs_login commands both result in authenticated access to DFS from an NFS client. To provide a user with authenticated access, each command obtains a ticket-granting ticket (TGT) for the user from the DCE Security Service. The TGT is used to create a valid login context for the user. The login context includes a Process Activation Group (PAG), which DFS stores in the kernel of the Gateway Server machine. The PAG identifies the user’s TGT; the TGT serves as the user’s DCE credentials.

On the Gateway Server machine, an association is created between the UNIX user identification number (UID) of the user and the network address of the NFS client from which DFS access is desired. A mapping is then created between this pair and the PAG created for the user. The mapping is stored as an entry in a local authentication table, which, like the PAG, resides in the kernel of the machine. The mapping provides the user with authenticated access to DFS from the NFS client.

Each mapping grants a user authenticated access only from the specific NFS client for which the mapping exists. For authenticated access from a different NFS client, a user must use the dfsgw add or dfs_login command to create a new mapping for that client.

A user’s DCE credentials are good only for the lifetime of the TGT. The ticket lifetime is dictated by the registry database of the DCE cell. By default, each ticket receives the default ticket lifetime in effect in the registry database. The dfs_login command includes a -loption that can be used to request a different lifetime, but a requested lifetime is constrained by the policies in effect in the registry database. A user’s DCE credentials can be refreshed by using the dfsgw add command before the user’s TGT expires. If a user’s TGT expires, the user must obtain new DCE credentials. For more information on the dfsgw add command, see “Chapter 5. Configuration File and Command Reference” on page 25.

2DFS for Solaris: NFS/DFS Secure Gateway Guide and Reference

Page 12
Image 12
IBM manual DFS for Solaris NFS/DFS Secure Gateway Guide and Reference