 | Level: Introductory Sandeep Ramesh Patil (rsandeep@in.ibm.com), Staff Software Engineer, IBM
28 Feb 2006 Learn how to use the IBM NFS/DFS Authentication Gateway commands and application programming interfaces (APIs) to design applications during migration. As the storage needs of large enterprises continue to grow and NFS implementations offering more and more features, it makes business sense for enterprises to migrate to NFS Version 4, as outlined in the "IBM NFS/DFS Authentication Gateway: A migration bridge to NFS Version 4" companion article.
Introduction
With the IBM Distributed File System™ (DFS™) is reaching its end of life, Network File System Version 4 (NFS Version 4) is emerging as the next-generation enterprise file system. As a result, administrators need to start planning the migration of IBM DFS to NFS Version 4. A companion article, IBM NFS/DFS Authentication Gateway:
A migration bridge to NFS Version 4, discussed different migration strategies. It also explained how phased
migration could be one of the popular choices for enterprises having large volumes of data and many DFS/Distributed Computing Environment (DCE) users for migration. It also talked about IBM NFS/DFS Authenticating Gateway providing a bridge for users for
authenticated access to IBM DFS through NFS clients, which support both NFS Version 4 as well as NFS Version 3.
This article builds upon the previous article and describes how administrators can use the commands and application programming interfaces (APIs), provided by
IBM NFS/DFS Authenticating Gateway, to design applications to aid them during the migration period.
IBM NFS/DFS Authenticating Gateway commands and APIs
To provide file access, the NFS client is required to mount the exported IBM DFS filespace. In IBM DCE DFS, end users are identified by principal names and, in NFS, client requests are identified by an IP address and userID pair. So, there needs to be a mapping between the two.
IBM NFS/DFS Authenticating Gateway provides the dfsiauth command that is used to map this
authentication information.
Because the IBM NFS/DFS Authenticating Gateway resides on a separate
machine, NFS users must log in to this translation point and issue the dfsiauth command.
The dfsiauth command describes the address of
the NFS client user's machine and the user's ID (UID) on that machine. It then authenticates with DCE, declaring a
DCE principal and entering the password. When the IBM NFS/DFS Authenticating Gateway receives an NFS request,
it includes the NFS client user's machine address and the UID of the request. The IBM NFS/DFS Authenticating Gateway
embeds the DCE credential information in the request, which enables DCE authentication. NFS Version 4 client users can use
the IBM NFS/DFS Authenticating Gateway without making changes to their existing software if they use the dfsiauth
command on the NFS file server. In this manner, the NFS client can get authenticated access to the IBM DFS space.
| For detailed information on the dfsiauth command and its options, see the NFS/DFS Authenticating Gateway Guide and
Reference in the Resources section.
|
|
A major issue with the dfsiauth command is that it has to be executed on the machine that hosts
the IBM NFS/DFS Authenticating Gateway. Because the IBM NFS/DFS Authenticating Gateway resides on a separate machine,
NFS Version 4 users are required to log in to this translation point and issue the command before they can have authenticated
access to IBM DFS space. This is pretty cumbersome.
In a scenario where the machine hosting the NFS/DFS Authenticating Gateway is a secured server and is required to have limited access, having thousands of users log on to the machine to execute the command might not be possible. To address the issue, an API library (libdceiauth.a) is provided with the IBM NFS/DFS Authenticating Gateway so client/server applications can be
developed that establish authentication mappings from the native NFS client to the IBM NFS/DFS Authenticating
Gateway system. Such applications eliminate the need for users to log in to the NFS/DFS Authenticating Gateway
machine to establish their mappings.
The API library libdceiauth.a exports an API called dceiauthcall(), which can be used by applications
to perform operations against the IBM NFS/DFS Authenticating Gateway. It authenticates a DCE principal and performs
operations against the IBM NFS/DFS Authenticating Gateway to register or un-register a host-UID pair for translation.
In other words, the API allows remote host-UID pairs to be registered or un-registered to an existing DCE principal,
which is internally used to obtain the authenticated access to the IBM DFS space. This call must be executed
on the machine hosting the IBM NFS/DFS Authenticating Gateway that performs NFS/DFS translation. The
function definition and an explanation of a few of its important input parameters are shown in Listing 1 below.
Listing 1. Function definition
int dceiauthcall (char * remoteHost, char * remoteUid, char * user, char * passwd,
char * sys, char * host, int * pag, int * flags, char * buffer, int * buflen) |
- remoteHost
- Specifies the hostname of the system requesting the authenticated access.
- remoteUid
- Specifies the remote user ID.
- user
- Specifies the DCE principal for authentication.
- passwd
- Specifies the password of the DCE principal in the DCE registry.
For details on the other function parameters, see the NFS/DFS Authenticating Gateway Guide and Reference in the Resources section.
Using the IBM NFS/DFS Authenticating Gateway API
Administrators can plan to use the dceiauthcall() API explained above to design a client/server application
where the client program resides on all the user machines having the NFS Version 4 client (and wanting authenticated
access to IBM DFS space), while the server program runs on the machine hosting IBM NFS/DFS Authenticating Gateway.
Such a setup allows the NFS Version 4 client users to have authenticated access to DFS space by simply running the client
program. The client program communicates with its server counterpart running on the IBM NFS/DFS Authenticating Gateway
machine, which in turn provides the authenticated access by calling dceiauthcall() with relevant arguments
obtained from the client. One such approach that can be used by administrators during their migration period is described below.
Client side
- User logs into the machine where the NFS client has mounted the exported DFS filespace.
The same machine also has the NFS Version 4 client configured to the NFS Version 4 server to which the migration is underway.
- User executes the client program. The client program:
- Requires the user to enter their DCE user name and DCE password.
- Requires the user to enter the operation the user wants to carry out (one of the following):
- Add the authentication mapping.
- Remove the authentication mapping.
- Overwrite the existing authentication mapping.
- Programmatically obtains the logged in user's userID and the machine's hostname.
- Connects to the server that is listening on the machine hosting the NFS/DFS Authenticating Gateway,
and passes the DCE user name, DCE password, hostname, userID, and the operation that is to be carried out.
- Waits for the reply from the server and prints out the result to the user.
- On success, the user will have authenticated access to IBM DFS space and the NFS client will then be able to view the same file system hierarchy as the DFS client. The user can now access both the migrated data residing on NFS Version 4 space and the data that is still residing on IBM DFS space.
Server side
- The server program residing on the machine hosting IBM NFS/DFS Authenticating Gateway needs to be
executed at system startup, or manually by the administrator.
- The server program:
- Continuously listens for the client request.
- On receiving a client request, the server accepts the data (DCE user name, DCE password, the remote hostname, the remote userID, and the operation that needs to be carried out) being passed by the client.
- It then makes a call to the
dceiauthcall() function with its arguments formulated from the received data.
- Returns the result of the above function call to the client and logs the information on the server.
Figure 1 shows a high-level view of events that takes place between the client and the server application
to achieve authenticated access to IBM DFS space from the NFS Version 4 client.
Figure 1. Events between client and server to achieve authenticated access to IBM DCE DFS
Security
For the approach described above, there are a few questions that need to be addressed:
- How will the server program authenticate the client program, and vice versa?
- How will the client program pass the information securely to the server program, and vice versa?
- Can this be achieved with the existing infrastructure and software required for IBM AIX® 5.3 NFS Version 4 and IBM DCE DFS?
Before addressing those questions, let's briefly discuss NFS Version 4 and DFS security modules. One of the major features of NFS Version 4 is its support for enhanced security schemes, which allow stronger authentication, fine-grained access control, and encrypted data traffic. Kerberos is one such security protocol used by NFS Version 4 and is currently supported by NFS Version 4 implementations, such as IBM AIX 5.3 NFS Version 4 and open NFS Version 4.
To exploit the NFS Version 4 security features, you must install and configure Kerberos on the NFS
server and client machines. IBM AIX 5.3 NFS Version 4 requires that you install and configure IBM Network Authentication Service
(IBM's flavor of Kerberos), which is shipped along with AIX. For details on how to configure IBM AIX 5.3 NFS Version 4 with
IBM Network Authentication Service (IBM NAS), go to the IBM Redbook Securing NFS in AIX An Introduction to NFS Version 4 in AIX 5L Version 5.3 (see Recourses).
IBM DFS makes use of IBM DCE security for secure communication. Because Kerberos is a subset of
IBM DCE security, IBM DCE claims its interoperability with other Kerberos flavors. Both IBM NAS and IBM DCE
export the Generic Security Service Application Program Interface (GSS-API), which can be used by
applications for secured communication. GSS-API, as defined in [RFC-2743], provides security services to callers
in a generic fashion, supportable with a range of underlying mechanisms (like Kerberos) and technologies, and hence
allowing source-level portability of applications to different environments. It is a set of programming interfaces
that abstracts identity authentication, message origin authentication and integrity, and message confidentiality.
Now, about the questions above. The client and the sever applications described earlier in this article
can make use of GSS-API for mutual authentication and secure data exchange. Since the GSS-API component is a
part of IBM NAS (used by IBM AIX 5.3 NFS Version 4), as well as IBM DCE (used by IBM DFS), and they are documented to be
interoperable, there is no need for additional software or infrastructure. You can also choose
to install and configure IBM NAS on the server side and use its GSS-API component instead of the one provided by IBM DCE,
especially if you want to use the latest encryption types, such as AES for secure communication.
Figure 2 shows a high-level view of how the client and server applications
described in this article can use the existing infrastructure to communicate securely and finally achieve authenticated access to IBM DFS space from the IBM AIX NFS Version 4 client.
Figure 2. Secure flow between client and server
- The IBM NFS/DFS Authentication Gateway should be configured using AIX NFS Version 3 server and not AIX NFS Version 4 server.
- In the above description, the NFS clients will be required to configure to AIX NFS Version 3 server hosting the IBM NFS/DFS Authentication Gateway to be able to access the IBM DFS space.
- Since the AIX 5.3 NFS client installable can be configured to work with both NFS Version 3 as well as NFS Version 4, it makes the above stated possible.
Conclusion
With IBM is declaring its end of support for IBM DFS, NFS Version 4 is becoming the next-generation distributed file system. Administrators will become busier as they sketch migration strategies. This article showed how administrators can use the IBM NFS/DFS Authenticating Gateway and its associated commands and APIs to aid them during migration from IBM DFS to IBM AIX 5.3 NFS Version 4.
Resources Learn
Get products and technologies
-
Build your next development project with
IBM
trial software, available for download directly from developerWorks.
-
Get your hands on application development tools and middleware products from
DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®. You can download
evaluation versions of the products at no charge, or select the Linu® or
Windows® version of developerWorks' no-charge Software
Evaluation Kit.
About the author | 
| | Sandeep Ramesh Patil is a Staff Software Engineer for the IBM India Software Labs. He has worked for IBM for the past five years, focusing on distributed technology including DCE, SARPC, and security products such as the IBM Network Authentication Services (IBM Kerberos). He is currently developing new features and implementing security-related RFC for the IBM Network Authentication Service, along with its product support. Sandeep holds a Bachelor of Science degree in Computer Science and Engineering from the University of Pune, India. You can contact him at rsandeep@in.ibm.com. |
Rate this page
| |
