X

Blogs about Deep Learning, Machine Learning, AI, NLP, Security, Oracle Traffic Director,Oracle iPlanet WebServer

  • August 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

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.