[OpenAFS] Authenticating to AFS via GSSAPI version 0.2 with WIN32

Douglas E. Engert deengert@anl.gov
Fri, 03 May 2002 11:35:15 -0500

For those of you who might be interested, I have updated the gsiklog 
program from last year to use Kerberos GSSAPI as well as the Globus 
Toolkit(tm) GSI. The  package is now called gssklog and can be found at: 


This version also works under Windows. I tested it against OpenAFS-1.2.2b 
on W2K with the Krb5 from kfw-2.1.2, against both an MIT KDC, and a W2K 
domain controller.

I am looking for comments. 


GSSKLOG - version 0.2


o now runs under WIN32.


Obtain an AFS token, using a Generic Security Services (GSS) implementation
for authentication thus giving the user and administrators greater flexibility
in authenticating to an AFS cell. This can still be used in conjunction with 
current AFS authentication methods. This separates the dependency of AFS on 
using Kerberos V4 tickets to obtain a token.

When used with Kerberos V5, it replaces the the aklog command, and does not
require the use of the krb524d. 

No modifications to any AFS code or servers are required, but the AFS administrator 
will need to run an additional daemon on one or more of the AFS servers. 

A modified klog program uses the GSS to authenticate to a daemon process running
on one or more of the AFS database servers. If authentication is accepted, and the 
user is found in a map file on the server, and AFS token is returned.

Much of the program source is derived from OpenAFS source, http://www.openafs.org.
and eventially could become part of the OpenAFSdistribution. But the package does 
not require the OpenAFS source to build. It does require either OpenAFS or 
Transarc/IBM AFS 3.6 include files and libraries located in /usr/afsws to compile
and link. 

The client, gssklog, is a modified klog which does not use the Kerberos V4, protocol
to authenticate. Instead it uses GSS through its GSS-API  and uses TCP to autheitcate
to the server. It locates the server(s) via the client's standard CellServDB file,
thus there are no new configuration files on the client.  

The server daemon, gssklogd, runs on one or more of the AFS database servers. It 
needs access to the /usr/afs/etc/KeyFile which contains the DES keys used by AFS. 
The server is run as a daemon, not from inetd. 

This package has been tested using two different GSS implementations: the MIT 
KRB5-1.2.3 GSSAPI and the Globus Toolkit(tm) 2.0 GSI GSSAPI. The previous 
version of the package was called GSIKLOG, and realy only worked with GSI.
Changes where made to make sure it would run with either of these two GSS 
The server, gssklogd needs a GSS credential which in GSS terms is a 
GSS_C_NT_HOSTBASED_SERVICE, "gssklog@hostname" where hostname id the FQDN of 
the machine running the gssklogd. 

With kerberos, the server's credential is a keytab file with a key for the server 
principal of gssklog/hostname@realm. The file is found using normal Kerberos 
routines, or via the -k option. 

With GSI the server's credential is a server certificate with CN=gssklog/hostname
and a matching private key. These are defaulted to: /etc/grid-security/afscert.pem
and /etc/grid-security/afskey.pem.  The trusted certificates directory: 
/etc/grid-security/certificates  is also needed. These can be specified via 
the -C -K and -D options respecively. 

The mapping of a GSS client_name to an AFS user name is currently done via a 
mapping file. This is defaults to: /etc/grid-security/afsgrid-mapfile
It can be specified via the -G option.

The mapfile has one line for each user, which consists of the
credential name i.e. Kerberos principal or GSI certificate subject name and 
the afs username, for example:

"johndoe@ANL.GOV"  jdoe
"/O=Grid/O=Globus/OU=anl.gov/CN=John Doe" jdoe

Where jdoe is the AFS user name. 

More then one username can be added, separated by commas. This lets the user
select which AFS username to use when authenticating with a single credential. 
For example:

"/O=Grid/O=Globus/OU=anl.gov/CN=John Doe" jdoe,gridadmin

The client uses the normal GSS credentials. For Kerberos these are the ticket
cache, and GSI these are the proxy file. 


Configure, make and make install are used. Note it is assumed
you are using shared libraries for the GSSAPI. If you are not,
you will have to edit the Makefile. 

To build the gsiklog and gssklogd run configure, adding:

  --enable-server     Build the server as well as client. 
                      Normally only the client is built.

  --with-afs=PATH     Location of AFS libs and includes
                      This would be /usr/afsws for example. 

  --with-server-extra-ldflags=FLAGS  Use to configure DES on
                      the server See the DES comments below. 

  --with-gss-include=PATH  Location of the gssapi.h
  --with-gss-lib-dir=PATH  Location of the GSS i.e. -L
  --with-gss-lib-name=NAME NAME of lib for use with -l

To build with Kerberos:
../src/configure \
  --with-server-extra-ldflags=-ldes425 \
  --with-server-extra-cflags=-DUSE_KRB5_DES \
  --with-gss-include=/krb5/include \
  --with-gss-lib-dir=/krb5/lib \
  --with-gss-lib-name=gssapi_krb5 \

At our site the KRB5-1.2.3 is installed on each system in the /krb5
directory, and the GSSAPI lib is know as: /krb5/lib/libgssapi_krb5*.

The build with the Globus Toolkit 2.0 GSI:

../src/configure \
  --with-gss-include=/afs/anl.gov/usr/ctd/b17783/work/Globus/gp/sun4x_57/include/gcc32dbg \
  --with-gss-lib-dir=/afs/anl.gov/usr/ctd/b17783/work/Globus/gp/sun4x_57/lib \
  --with-gss-lib-name=globus_gssapi_gsi_gcc32dbg \
  --enable-server \
  --with-server-extra-ldflags=-lcrypto_gcc32dbg \

The flavor of gcc32dbg was used. Note that the LD_LIBRARY_PATH 
may need to be set as per Globus install instructions. Only four share 
libraries are needed by the gssklogd. These could be copied to the 
AFS server. These are: libcrypto_gcc32dbg.so.0.0.0, libssl_gcc32dbg.so.0.0.0,  
libglobus_gssapi_gsi_gcc32dbg.so.0.0.0 and libglobus_ssl_utils_gcc32dbg.so.0.0.0.
Symlinks for the *.so.0 -> *.so.0.0.0 also need to be created. If placed
in /usr/lib, the LD_LIBRARY_PATH would not be needed. 


Edit the gssklog.mak file, and change the locations for:

 AFS include and *.lib files:

 GSS include and a gssapi32.lib:

 or if you have GSI:


 The run:
   nmake -f gssklog.mak


The gssklogd generates one DES key for the session key, and does one encryption
operation, where the ticket is encrypted in the AFS server key. This requires
access to a DES library. On Solaris the IBM AFS 3.6 has a libdes.a, but the 
pcbc_encrypt function is not exposed. 

So some other DES library must be made available for the gssklogd. The two GSSAPI
implementation tested both have DES libraries which can be used by the gssklogd. 
With the MIT Kerberos routines, the -ldes425 can be used. With the GSI, the GSI
version of the OpenSSL-0.9.6 -lcrypto_gcc32dbg can be used. 

The client also needs to link against the AFS libdes.a to satisfy some external
references from some of the other AFS libraries.   

Note: with normal Kerberos V4, the cipher would also be encrypted using the user's
TGT key, but the cipher is returned protected instead by the GSSAPI wrap functions. 


The client gssklog can be anywhere, but needs access to the shared GSSAPI 
libraries. type "gssklog help" to see the options, which are basically the klog 
options, plus -port option. 

The server gssklogd needs to run on one or more AFS database servers,as the client
will try each of the database servers listed in the CellServDB to find the gssklogd.
Options fore the server are:
 -d       run in debug mode in foreground.

 -p port  TCP port, defaults to 750

 -l file  Logfile name

 -s name  server name, defaults to gssklog@hostname

 -C file  See above.

 -K file  See above.
 -D file  See above.

 -G file  afsgrid-map file see above.

 -a file  AFS key file.

 -k file  Kerberos keytab file.


The gssklog client should work with the previous gsiklogd, if the -gsiklog 
option is used. The main difference is that the old gsiklog used a 
GSS_C_NT_HOSTBASED_SERVICE of afs@cellname. This should allow for testing of 
the gssklog with the older gsiklogd, which was using Globus Toolkit GSI 1.1.3. 


This is still a beta release, and more needs to be done:

 o This has only been tested on Solaris 5.7 with Transarc/IBM AFS 3.6.

 o The session keys are generate by the gssklogd, and the seeding
   of the random number generator needs to be reviewed. 

 o A real port needs to be assigned. It defaults to 750 TCP 
   but the client has a -port option, and the server a -p option. 

 o The use of a single port with multiple GSS mechanisms needs to
   be looked at. (mech-glue for example.) 

 o Better logging facilities like syslog need to be added.
 o With the GSI there are no command line options on the gssklog 
   to select which proxy credentials are used. The X509_* environment
   variables can still be used, i.e. X509_USER_PROXY

 o Likewise with Kerberos, the KRB5CCNAME can be set. 

 o The server needs to have better time-out processing on requests.

 o When starting the daemon with GSI, make sure X509_* variables are not set
   or set to point to the daemons cert, key, and directory.  

 o The server does NOT look at the kaserver.DB, or the prdb.DB so will 
   issue tokens based solely on the afsgrid-mapfile. 

 o A better mapping function, or rule based function like krb5_aname_to_localname
   could be used. 
 o The code needs to be worked into the Globus Gatekeeper, FTPD, and SSHD.
   This is basically outlined with each of these packages.   

If you try this, or have suggestions, let me know.

Doug Engert deengert@anl.gov

I would also like to acknowledge Helmut Heller <Helmut.Heller@lrz-muenchen.de>
and Andrea Parrini <aprarini@tiscalinet.it>  who have tested the original
gsiklog code more then I have and has found a number of bugs.

OpenAFS-info mailing list