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@REALM ... addprinc wouter@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
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/infrastructure
