You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@river.apache.org by "Jonathan Costers (JIRA)" <ji...@apache.org> on 2009/10/11 15:58:31 UTC

[jira] Commented: (RIVER-307) KDC (Key Distribution Center) Server for kerberos tests

    [ https://issues.apache.org/jira/browse/RIVER-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12764451#action_12764451 ] 

Jonathan Costers commented on RIVER-307:
----------------------------------------

I have successfully installed and configured a testing KDC on my machine and have successfully run the hello example using this configuration.

Here is a rough guide:

1. Configure your network

2. Install MIT Kerberos 5 (example for Ubuntu)

sudo apt-get install krb5-kdc krb5-admin-server
sudo dpkg-reconfigure krb5-kdc

3. Configure MIT Kerberos 5 servers

The configuration file for Kerberos is /etc/krb5kdc/kdc.conf. This file provides settings for your Kerberos realm. Important settings here are the locations of the KDC's data files, and the default settings for the durations that tickets are valid. 

[kdcdefaults]
    kdc_ports = 750,88

[realms]
    YOURREALM = {
        database_name = /var/lib/krb5kdc/principal
        admin_keytab = FILE:/etc/krb5kdc/kadm5.keytab
        acl_file = /etc/krb5kdc/kadm5.acl
        key_stash_file = /etc/krb5kdc/stash
        kdc_ports = 750,88
        max_life = 10h 0m 0s
        max_renewable_life = 7d 0h 0m 0s
        master_key_type = des3-hmac-sha1
        supported_enctypes = des3-hmac-sha1:normal aes256-cts:normal arcfour-hmac:normal des-cbc-crc:normal des:normal des:v4 des:norealm des:onlyrealm des:afs3
        default_principal_flags = +preauth
    }

Kerberos uses an Access Control List (ACL) to specify the access a principal will have to the Kerberos admin deamon. This file is /etc/krb5kdc/kadm5.acl. The default, as shown below will suffice to get started. You may need to add additional ACLs depending on the needs of your network configuration.

# This file Is the access control list for krb5 administration.
# When this file is edited run /etc/init.d/krb5-admin-server restart to activate
# One common way to set up Kerberos administration is to allow any principal
# ending in /admin  is given full administrative rights.
# To enable this, uncomment the following line:
*/admin@YOURREALM    *

Edit /etc/krb5.conf:

[libdefaults]
    default_realm = YOURREALM
    default_tgs_enctypes = des3-cbc-sha1 aes256-cts arcfour-hmac des-cbc-md5 des-cbc-crc
    default_tkt_enctypes = des3-cbc-sha1 aes256-cts arcfour-hmac des-cbc-md5 des-cbc-crc
    permitted_enctypes = des3-cbc-sha1 aes256-cts arcfour-hmac des-cbc-md5 des-cbc-crc

[realms]
        YOURREALM = {
                kdc = yourhostname.yourdomainname
                admin_server = yourhostname.yourdomainname
        }

[logging]
    kdc = FILE:/var/log/krb5kdc.log
    admin_server = FILE:/var/log/kadmin.log
    default = FILE:/var/log/krb5lib.log

Create the Kerberos database:

jonathan@calisto:~$ krb5_newrealm

Restart Kerberos services

4. Setup Principals

Use the program kadmin or kadmin.local to create principals. Running kadmin.local as root will let you authenticate without having an existing principal for yourself. 

kadmin.local:  addprinc -pw yourpw youruser/admin

Create principals for hello example:

kadmin.local:  addprinc -pw serverpw -e des3-cbc-sha1 server
kadmin.local:  addprinc -pw clientpw -e des3-cbc-sha1 client
kadmin.local:  addprinc -pw reggiepw -e des3-cbc-sha1 reggie
kadmin.local:  addprinc -pw phoenixpw -e des3-cbc-sha1 phoenix


Verify:
kadmin.local:  listprincs
K/M@LEKTRONET
client@LEKTRONET
root/admin@LEKTRONET
jonathan@LEKTRONET
kadmin/admin@LEKTRONET
kadmin/changepw@LEKTRONET
kadmin/history@LEKTRONET
kadmin/localhost@LEKTRONET
krbtgt/LEKTRONET@LEKTRONET
phoenix@LEKTRONET
reggie@LEKTRONET
server@LEKTRONET

jonathan@calisto:~$ sudo kadmin
Authenticating as principal root/admin@LEKTRONET with password.
Password for root/admin@LEKTRONET: 
kadmin:  q

jonathan@calisto:~$ kinit
Password for jonathan/@LEKTRONET: 
jonathan@calisto:~$

5. Create keytab file for hello example

jonathan@calisto:~$ ktutil
kutil: addent -password -p server -k 1 -e des3-cbc-sha1 
kutil: addent -password -p phoenix -k 1 -e des3-cbc-sha1 
kutil: addent -password -p reggie -k 1 -e des3-cbc-sha1 
kutil: wkt /home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/examples/hello/config/krb-servers.keytab

6. Configure hello example script

Edit scripts/krb-setenv.sh:

# Default realm used by KDC and all principals in this example
# Example: REALM=REALM1.XYZ.COM
REALM=${REALM:-YOURREALM}

# Host on which the KDC server is running
# Example: KDC_HOST=server3.xyz.com
KDC_HOST=${KDC_HOST:-yourhostname.yourdomainname}


> KDC (Key Distribution Center) Server for kerberos tests
> -------------------------------------------------------
>
>                 Key: RIVER-307
>                 URL: https://issues.apache.org/jira/browse/RIVER-307
>             Project: River
>          Issue Type: Sub-task
>          Components: Web site and infrastructure
>            Reporter: Peter Firmstone
>
> From Peter Jones comment:
> Another failed assumption of the previous internal Sun environment:
> this test is expecting to find a Kerberos KDC at the host name
> "jiniautot.east.sun.com".
> FAILED: net/jini/jeri/kerberos/UnitTests/runTestEndpoints.sh
> FAILED: net/jini/jeri/kerberos/UnitTests/runTestPerformance.sh
> These tests failed because they attempt to invoke the JRE's "kinit"
> tool using the internal sun.security.krb5.internal.tools.Kinit API,
> from which it was available in 1.4.x and 5.0 JRE versions.  The Java
> version of this tool was removed from the Solaris and Linux JREs for
> version 6 because there is a native kinit on those platforms, although
> it remains in the Windows JRE.
> Beyond this kinit problem, though, these Kerberos tests would surely
> have failed expecting to find a KDC at "jiniautot.east.sun.com" like
> the previous two.
> FAILED: net/jini/jeri/tcp/localHostExposure/LocalHostExposure.java
> FAILED: net/jini/jeri/transport/multihomed/Multihomed.java
> FAILED: net/jini/jeri/transport/multihomed/runMultihome.sh
> These tests failed during the compilation phase because of this issue
> discussed recently here:
> http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200904.mbox/%3C20090421151237.GA19950@east%3E
> What's the best way to implement a KDC for tests?    Your thoughts please?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.