RFR - KDC for NFSv4 test day

[James Laska]

Greetings,

Apologies, I just noticed that the RFR sent in by Cai for the upcoming
test day wasn't passed along to the list.  Cai has been working to
document the setup instructions for running a local KDC to test against.
However, if available, a KDC hosted on a fedora test system would reduce
the start-up cost for testing.  Is it too late to make progress on this
ticket?

Ticket filed at
https://fedorahosted.org/fedora-infrastructure/ticket/1953

== Project Sponsor ==

 * '''Name''': Qian Cai
 * '''Fedora Account Name''': caiqian
 * '''Group''': Fedora QA Group
 * '''Infrastructure Sponsor''': 

== Secondary Contact info ==

 * '''Name''': James Laska
 * '''Fedora Account Name''': jlaska
 * '''Group''': Fedora QA Admin Group

== Project Info ==

 * Project Name: NFSv4 Test Day 4 Feb. this Thursday
 * Target Audience: Fedora users/NFS community
 * Expiration/Delivery Date (required):2010-02-04 (Test Day date)
 * Description/Summary: 

A KDC server with a few accounts so that users can use it to configure
their own NFS server and client to use kerberos authentication for
secure NFS test cases.

 * Project plan (Detailed): 

One of NFSv4 test day's focus is on secure NFS, which requires - a KDC
server, NFS server, and NFS client. They all need to have credentials—
principals, in Kerberos-terminology—stored in the Kerberos database.
Enabling Kerberos authentication in any service usually boils down to
four steps:

     1. Creating a Kerberos principal
     2. Storing the Kerberos principal on the server system so that it
        can access it
     3. Modifying the server’s configuration so that it accepts
        Kerberos-based authentication
     4. Configuring the client so that it tries Kerberos authentication

To make sure Kerberos likes your network, it’s a good idea to install
ntpd which will fix the timing issues. As for the name resolving issues,
try ping localhost ; if that returns things like

        64 bytes from host.example.com (127.0.0.1): icmp_seq=1... 
        

while running hostname --fqdn returns host.example.com, you’re all set.
If not, fiddle with /etc/hosts until it does. You should also try to
ping your hosts from different machines, and the result should be
similar.

With that out of the way, you should now install the server-side
Kerberos software on the machine that will serve as the Kerberos server.
With that done, run kdb5_util create -s, which will ask you a few
questions and then create your Kerberos realm. Next you should create an
ACL file for the kdc, which will tell the latter who can create and/or
manage Kerberos principals. An easy (and yet safe enough for most cases)
ACL file would look like this:

        */admin * 
        

You will need to store that file as /etc/krb5kdc/kadm5.acl. Now it’s
time to start the kdc ( /usr/sbin/krb5kdc ) and the admin server
( /usr/sbin/kadmind ). Next, run /usr/sbin/kadmin.local to create the
initial principals:

# kadmin.local

        addprinc root/admin at REALM
        

...

        addprinc wouter at REALM
        

...

        quit
        

# 

Both will ask you to enter a password; it’ll be easiest for you to
remember if you just use your own password for that. Obviously, you
should also replace REALM by the realm name you’ve created.

By now, you have a fully operational Kerberos realm. You can play a bit
with kinit, klist and kdestroy (read their manpages). Next will be to
set up the different servers so that they support Kerberos
authentication, followed by the clients; and to finish it all properly,
we should also configure PAM to authenticate against the Kerberos server
rather than /etc/passwd. 
Goals: Having a centralized server with some pre-populated data to test
against, so itwould probably lower the barriers for people having to
setup their own server + data

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/infrastructure/attachments/20100202/0e62470d/attachment.bin