Tuesday Aug 17, 2010

Using Kerberos as Authentication Database in Oracle iPlanet Web Server on Solaris 10

Using Kerberos Authentication Database in Oracle iPlanet Web Server on Solaris 10

    This article describes how to use Kerberos authentication database in Oracle iPlanet Web Server. 

In this article, KDC and Web Server are setup on the same host (serverhost.your.domain.com), Kerberos domain is YOUR.DOMAIN.COM, DNS Domain is your.domain.com and client is on host : clienthost.your.domain.com. Both these KDC/Web Server and client machines have Solaris 10.

Make sure you configure DNS properly on KDC, server and client machines. 

"/etc/hosts" should have KDC hostname and it must be the same on all machines. You can verify by
	#getent hosts serverhost.your.domain.com
	<ip-address> serverhost.your.domain.com
            Note that the first entry is of the form hostname.domain not just hostname.

Clock Synchronization

All hosts that participate in the Kerberos authentication system must have their internal clocks synchronized within a specified maximum amount of time. Known as clock skew, this feature provides another Kerberos security check. If the clock skew is exceeded between any of the participating hosts, requests are rejected. The default value for the maximum clock skew is 300 seconds (five minutes).

One way to synchronize all the clocks is to use the Network Time Protocol (NTP) software. See Synchronizing Clocks Between KDCs and Kerberos Clients for more information.

Or you can also use rdate from client host as shown below

[clienthost]# rdate serverhost.your.domain.com

1. Configure Kerberos master KDC on Solaris 10

Install Solaris 10 with these options
  • Enable Kerberos : Yes
  • Kerberos default realm : YOUR.DOMAIN.COM
  • Kerberos Admin Server and KDC : serverhost.your.domain.com
\* even if you do not we can edit configuration files manually.

1.1 Modify Kerberos configuration files

            Modify Kerberos configuration files as shown in the tables below.

/etc/krb5/krb5.conf
[libdefaults]
        default_realm =  YOUR.DOMAIN.COM
[realms]
        YOUR.DOMAIN.COM = {
kdc = serverhost.your.domain.com
admin_server = serverhost.your.domain.com } [domain_realm] .your.domain.com = YOUR.DOMAIN.COM [logging] default = FILE:/var/krb5/kdc.log kdc = FILE:/var/krb5/kdc.log kdc_rotate = { period = 1d versions = 10 } [appdefaults] kinit = { renewable = true forwardable= true } gkadmin = { help_url = ... }

/etc/krb5/kdc.conf
[kdcdefaults]
    kdc_ports = 88,750

[realms]
     YOUR.DOMAIN.COM = {
        profile = /etc/krb5/krb5.conf
        database_name = /var/krb5/principal
        admin_keytab = /etc/krb5/kadm5.keytab
        acl_file = /etc/krb5/kadm5.acl
        kadmind_port = 749
        max_life = 8h 0m 0s
        max_renewable_life = 7d 0h 0m 0s
        default_principal_flags = +preauth
    }



/etc/krb5/kadm5.acl

\*/admin@YOUR.DOMAIN.COM \*


1.2 Start dns/client service on Master KDC

For Kerberos to work dns/client service must be started before you start any other Kerberos daemons. Edit /etc/resolv.conf to have nameserver entries and then enable dns/client service using svcadm command as shown below.


# svcadm -v enable -s dns/client
svc:/network/dns/client:default enabled.


1.3 Create principal database on master KDC

                 Create principal database using kdb5_util.


# kdb5_util create -s

Initializing database '/var/krb5/principal' for realm 'YOUR.DOMAIN.COM',
master key name 'K/M@YOUR.DOMAIN.COM'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key:  <--- Enter password here
Re-enter KDC database master key to verify:
<--- Enter the same password again

 List the principals which got created by default by listprincs command as shown below

# kadmin.local

kadmin.local: listprincs

K/M@YOUR.DOMAIN.COM
changepw/serverhost.your.domain.com@YOUR.DOMAIN.COM
kadmin/changepw@YOUR.DOMAIN.COM
kadmin/history@YOUR.DOMAIN.COM
kadmin/serverhost.your.domain.com@YOUR.DOMAIN.COM
kiprop/serverhost.your.domain.com@YOUR.DOMAIN.COM
krbtgt/YOUR.DOMAIN.COM@YOUR.DOMAIN.COM

Make sure you have these three entries shown in green color.

1.4 Add atleast one Administrative Principal to Kerberos database

The administrative principals created here should be the ones that were added to the ACL file.

# kadmin.local

kadmin.local: addprinc admin/admin@YOUR.DOMAIN.COM

WARNING: no policy specified for admin/admin@YOUR.DOMAIN.COM; defaulting to no policy
Enter password for principal "admin/admin@YOUR.DOMAIN.COM": <- Enter password here
Re-enter password for principal "admin/admin@YOUR.DOMAIN.COM": <- Enter the same password again
Principal "admin/admin@YOUR.DOMAIN.COM" created.

1.5 Create a keytab file for the kadmind service.

Create the kadmin keytab with entries for these principals

# kadmin.local
kadmin.local: ktadd -k /etc/krb5/kadm5.keytab
kadmin/serverhost.your.domain.com

               changepw/serverhost.your.domain.com
               kadmin/changepw

This command sequence creates a special keytab file with principal entries for kadmin/<FQDN> and changepw/<FQDN>. These principals are needed for the kadmind service and for passwords to be changed. Note that when the principal instance is a host name, the FQDN must be specified in lowercase letters, regardless of the case of the domain name in the /etc/resolv.conf file. The kadmin/changepw principal is used to change passwords from clients that are not running a Solaris release.

Use klist to inspect keytab file


#
klist -k /etc/krb5/kadm5.keytab
Keytab name: FILE:/etc/krb5/kadm5.keytab
KVNO Principal
---------------------------------------------------------
   3 kadmin/serverhost.your.domain.com@YOUR.DOMAIN.COM
   3 kadmin/serverhost.your.domain.com@YOUR.DOMAIN.COM
   3 kadmin/serverhost.your.domain.com@YOUR.DOMAIN.COM
   3 kadmin/serverhost.your.domain.com@YOUR.DOMAIN.COM
   3 kadmin/changepw@YOUR.DOMAIN.COM
   3 kadmin/changepw@YOUR.DOMAIN.COM
   3 kadmin/changepw@YOUR.DOMAIN.COM
   3 kadmin/changepw@YOUR.DOMAIN.COM
   3 changepw/serverhost.your.domain.com@YOUR.DOMAIN.COM
   3 changepw/serverhost.your.domain.com@YOUR.DOMAIN.COM
   3 changepw/serverhost.your.domain.com@YOUR.DOMAIN.COM
   3 changepw/serverhost.your.domain.com@YOUR.DOMAIN.COM

1.6 Create /etc/krb5/krb5.keytab

Some programs like telnet by default look for /etc/krb5/krb5.keytab so we create a softlink as shown below

# ln -s /etc/krb5/kadm5.keytab /etc/krb5/krb5.keytab

1.7 Start Kerberos Daemons on Master KDC

Use svcadm command to start Kerberos daemons krb5kdc and kadmin as shown below


# svcadm -v enable -s krb5kdc
svc:/network/security/krb5kdc:default enabled.

# svcadm -v enable -s kadmin

svc:/network/security/kadmin:default enabled.

Also, make sure that ktkt_warn service is also online.

# svcs | grep security
online       Apr_17   svc:/network/security/ktkt_warn:default
online        0:37:21 svc:/network/security/krb5kdc:default
online        0:37:26 svc:/network/security/kadmin:default

                Use svcadm command to start time service s as well

# svcadm -v enable -s time:stream time:dgram
svc:/network/time:stream enabled.
svc:/network/time:dgram enabled.

1.8 Create host and HTTP principal on KDC, and extract its keys into keytab

Create host and HTTP principal on KDC and extract them to keytab file as shown below

# kadmin -p admin/admin

kadmin: addprinc -randkey host/serverhost.your.domain.com
WARNING: no policy specified for host/serverhost.your.domain.com@YOUR.DOMAIN.COM; defaulting to no policy
Principal "host/serverhost.your.domain.com@YOUR.DOMAIN.COM" created.
kadmin: addprinc -randkey HTTP/serverhost.your.domain.com
WARNING: no policy specified for HTTP/serverhost.your.domain.com@YOUR.DOMAIN.COM; defaulting to no policy
Principal "HTTP/serverhost.your.domain.com@YOUR.DOMAIN.COM" created.
kadmin: ktadd -k /etc/krb5/kadm5.keytab host/serverhost.your.domain.com

kadmin: ktadd -k /etc/krb5/kadm5.keytab HTTP/serverhost.your.domain.com

\*Note that when the principal instance is a host name, the FQDN must be specified in lowercase letters.

1.9 Create a user "testuser" and add it to KDC

                  For testing, add a user "testuser", set its password and add this principal to KDC.

# useradd -u 400 testuser
# passwd testuser
...
# kadmin -p admin/admin
kadmin: addprinc testuser
WARNING: no policy specified for testuser@YOUR.DOMAIN.COM; defaulting to no policy
Enter password for principal "testuser@YOUR.DOMAIN.COM": <- Enter password here
Re-enter password for principal "testuser@YOUR.DOMAIN.COM": <- Enter the same password again

Principal "testuser@YOUR.DOMAIN.COM" created.

1.10 Configure slave KDCs as given in "Solaris 10 - System Administration Guide: Security Services" (optional)

But for simplicity this can be skipped.

2. Oracle iPlanet Web Server Configuration

2.1 Install Oracle iPlanet Web Server on the machine where KDC is installed.

In this case, for simplicity, Oracle iPlanet web server is installed on the same machine as master KDC.

2.2 Copy keytab file and make sure that user running Web Server Instance has file system permissions

If Web Server instance is running as "webservd"(or any user other than root), it doesn't have permissions to read /etc/krb5/kadm5.keytab. So copy the file as shown below and change its owner.

# cd https-<instance>/config
# cp /etc/krb5/kadm5.keytab kadm5.keytab
# chown webservd:webservd kadm5.keytab

2.3 Create Kerberos Authentication Database in Web Server

To create an authentication database through Administration CLI, execute the following wadm commands.

wadm> create-kerberos-authdb --config=test --service-name=HTTP my-kerberos

wadm> set-config-prop --config=test krb5-keytab-file=kadm5.keytab

\* Refer the latest Web Server documentation for details.

After this, server.xml should have these new entries :

<auth-db>
<enabled>true</enabled>
<name>my-kerberos</name>
<url>kerberos</url>
<property>
<name>servicename</name>
<value>HTTP</value>
</property>
</auth-db>

<krb5-keytab-file>kadm5.keytab</krb5-keytab-file>

2.4 Add the following ACL in ACL file

            Using Administration GUI/CLI, add ACL for /krb uri so that only authenticates users are allowed access.
             ACL file should contain ACL like this :

acl "uri=/krb/";
authenticate (user, group) {
    method = "gssapi";
    database = "my-kerberos";
};
deny (all) user="anyone";
allow (all) user="all";

You can set last allow ACE as user="testuser@YOUR.DOMAIN.COM" instead of user="all".

2.5 Add test.html in krb directory in document root directory

3. Configure Kerberos Client

      On client host (in this case it is clienthost.your.domain.com)

3.1 Copy /etc/krb5/krb5.conf file from KDC.

3.2 Obtain Kerberos ticket-granting ticket for "testuser" principal:

Add user testuser and request a ticket for that user

[clienthost]# useradd -u 400 testuser
[clienthost]# passwd testuser
...
[clienthost]# kinit testuser

Check that the ticket exists with klist command as shown below

[clienthost]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: testuser@YOUR.DOMAIN.COM

Valid starting                Expires                Service principal
07/01/10 01:06:48  07/01/10 09:06:48  krbtgt/YOUR.DOMAIN.COM@YOUR.DOMAIN.COM
        renew until 07/08/10 01:06:48
07/01/10 01:09:03  07/01/10 09:06:48  host/serverhost.your.domain.com@YOUR.DOMAIN.COM
        renew until 07/08/10 01:06:48

3.3 Testing if Kerberos was setup properly (optional)

3.3.1 Check for these entries in pam.conf. Needed just to test if telnet is kerberized.
 Entries in pam.conf
ktelnet auth required   pam_unix_cred.so.1
ktelnet auth binding pam_krb5.so.1
ktelnet auth required pam_unix_auth.so.1
other account requisite pam_roles.so.1
other account required pam_unix_account.so.1

other session required pam_unix_session.so.1

other password required pam_dhkeys.so.1
other password requisite pam_authtok_get.so.1
other password requisite pam_authtok_check.so.1
other password required pam_authtok_store.so.1

3.3.2 Make sure that telnetd is running on server.
3.3.3 Testing with telnet

[clienthost]telnet -a -F -l testuser serverhost.your.domain.com
Trying <ip-address-of-server>...
Connected to serverhost.your.domain.com.
Escape character is '\^]'.
[ Kerberos V5 accepts you as ``testuser@YOUR.DOMAIN.COM'' ]
[ Kerberos V5 accepted forwarded credentials ]
...

The above should log in without password prompt. This shows kerberos is setup properly.

3.4 Settings in Firefox/Mozilla Browser

Open Mozilla/Firefox browser. On the url type ">about:config,
set network.negotiate-auth.delegation-uris and network.negotiate-auth.trusted-uris to http://serverhost.your.domain.com,https://serverhost.your.domain.com

3.5 Access Web Server Content using Mozilla/Firefox Browser

On Mozilla/Firefox, access http://serverhost.your.domain.com/krb/test.html. This should bring up the test.html page

On the command prompt type # kdestroy. This should destroy the existing ticket issued to testuser

On Mozilla/Firefox now access http://serverhost.your.domain.com/krb/test.html. This should bring up Unauthorized page.

Enable security in Web Server and follow the same for https://....


This is what is happening between the Browser and Web Server, when /test.html is accessed. (Ignoring Browser->KDC and Web Server -> KDC interactions)

Browser to Web Server
Web Server to Browser
GET /test.html HTTP/1.1
Host: ...
...


HTTP/1.1 401 Unauthorized
Server: Sun-Java-System-Web-Server/7.0
Www-authenticate: Negotiate
...

<HTML><HEAD>
<TITLE>Unauthorized</TITLE>
</HEAD>
...
GET /test.html HTTP/1.1
Host: ...
Authorization: Negotiate <gssapi-data>
...


HTTP/1.1 200 OK
Server: Sun-Java-System-Web-Server/7.0
Www-authenticate: Negotiate <gssapi-data>
Content-type: text/html
...

This is test.html

  • Browser sends a GET request. 
  • Web server returns a 401 Unauthorized response with Header "Www-authenticate" with value "Negotiate".
  • Browser sends the same request with Header "Authorization" with value "Negotiate <gssapi-data>"
  • Web Server returns a 200 OK response with Header "Www-authenticate" with value "Negotiate <gssapi-data>" and the contents of the file user has asked for.
Access log of Web Server Instance shows two entries as shown below

format=%Ses->client.ip% - %Req->vars.auth-user% [%SYSDATE%] "%Req->reqpb.clf-request%" %Req->srvhdrs.clf-status% %Req->srvhdrs.content-length%

<client-ip-address> - -  [<date-and-time>]  "GET /test.html HTTP/1.1" 401 223
<client-ip-address> - testuser@YOUR.DOMAIN.COM [<date-and-time>]  "GET /test.html HTTP/1.1" 200 18

4. References

About

Meena Vyas

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today