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 (, Kerberos domain is YOUR.DOMAIN.COM, DNS Domain is and client is on host : 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
            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

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 :
\* 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.

        default_realm =  YOUR.DOMAIN.COM
        YOUR.DOMAIN.COM = {
kdc =
admin_server = } [domain_realm] = 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 = ... }

    kdc_ports = 88,750

        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


\*/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


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


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/
   3 kadmin/
   3 kadmin/
   3 kadmin/
   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/
   3 changepw/
   3 changepw/
   3 changepw/

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/
WARNING: no policy specified for host/; defaulting to no policy
Principal "host/" created.
kadmin: addprinc -randkey HTTP/
WARNING: no policy specified for HTTP/; defaulting to no policy
Principal "HTTP/" created.
kadmin: ktadd -k /etc/krb5/kadm5.keytab host/

kadmin: ktadd -k /etc/krb5/kadm5.keytab HTTP/

\*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 :



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

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/
        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
ktelnet auth binding
ktelnet auth required
other account requisite
other account required

other session required

other password required
other password requisite
other password requisite
other password required

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

[clienthost]telnet -a -F -l testuser
Trying <ip-address-of-server>...
Connected to
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,

3.5 Access Web Server Content using Mozilla/Firefox Browser

On Mozilla/Firefox, access 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 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

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


Post a Comment:
  • HTML Syntax: NOT allowed

Meena Vyas


« October 2015