test

Sun OpenSSO Enterprise 8.0 Administration Guide

Before You Begin

The procedures in this section are relevant when using the RADIUS, SafeWord, or the Windows-based authentication modules.

Setting Up for RADIUS and SafeWord Authentication

To Set Up RADIUS or SafeWord with Sun Java System Application Server should be performed before configuring an authentication process that uses the RADIUS or SafeWord authentication modules.

ProcedureTo Set Up RADIUS or SafeWord with Sun Java System Application Server

A Java Platform, Enterprise Edition SocketPermission class represents access to a network using sockets; it consists of a host location and a set of actions specifying ways to connect to that host. When the SafeWord client forms a socket connection to its server, only the connect action of the SocketPermission object is allowed in the Application Server’s server.policy file. In order for the SafeWord authentication module to work properly, permission needs to be granted to the accept, listen, and resolve actions manually.

  1. Open the server.policy file in a text editor.

  2. Add an entry for the appropriate actions into the Application Server server.policy file.

    For example, permission java.net.SocketPermission "localhost:1024-", "accept,connect,listen";

    If this permission is granted to some code, it allows that code to accept connections on, connect to, or listen to any port between 1024 and 65535 on the local host. The listen action is only meaningful when used with a local host. The resolve (resolve host/IP name service lookups) action is implied when any of the other actions are present. This second example (permission java.net.SocketPermission "machine1.example.com:1645", "connect,accept";) allows the code to connect to, and accept connections on, port 1645 on machine1.example.com.

    Note –

    Granting code permission to accept or make connections to remote hosts may cause problems, because malevolent code can then more easily transfer and share confidential data among parties who may not otherwise have access to the data. Make sure to give only appropriate permissions by specifying exact port number instead of allowing a range of port numbers

  3. Save the server.policy file.

  4. Restart Application Server.

See Also

For more information on SocketPermission, see the Java Platform, Enterprise Edition API Specification

Setting Up Windows Desktop SSO Authentication

In addition to configuring the Windows Desktop SSO authentication module using the OpenSSO Enterprise console, a user must be created in the Windows 2000 Domain Controller and Internet Explorer must be configured.

ProcedureTo Create a User in the Windows Domain Controller

  1. In the domain controller, create a user account for the OpenSSO Enterprise authentication module.

    1. From the Start menu, go to Programs>Administration Tools.

    2. Select Active Directory Users and Computers.

    3. Go to Computers > New > computer and add the client computer's name.

      If you are using Windows XP, this step is performed automatically during the domain controller account configuration.

    4. Go to Users > New > Users and create a new user with the OpenSSO Enterprise host name as the User ID (login name).

      The OpenSSO Enterprise host name should not include the domain name.

  2. Associate the user account with a service provider name.

  3. Install the ktpass utilities to the c:\program files\support tools directory.

    The ktpass utilities are not installed as part of the Windows 2000 server. You must install it from the installation CD.

  4. Export the keytab files to the system in which OpenSSO Enterprise is installed by running the following commands.


    ktpass -princ host/hostname.domainname@DCDOMAIN -pass password -mapuser userName-out 
hostname.host.keytab
ktpass -princ HTTP/hostname.domainname@DCDOMAIN -pass 
password -mapuser userName-out hostname.HTTP.keytab

    The ktpass command accepts the following parameters:

    hostname. The host name (without the domain name) on which OpenSSO Enterprise runs.

    domainname . The OpenSSO Enterprise domain name.

    DCDOMAIN. The domain name of the domain controller. This may be different from the OpenSSO Enterprise domain name.

    password . The password of the user account. Make sure that password is correct, as ktpass does not verify passwords.

    userName. The user account ID. This should be the same as hostname.

    Note –

    Make sure that both keytab files are kept secure.

    The service template values should be similar to the following example:

    Service Principal: HTTP/machine1.EXAMPLE.COM@ISQA.EXAMPLE.COM

    Keytab File Name: /tmp/machine1.HTTP.keytab

    Kerberos Realm: ISQA.EXAMPLE.COM

    Kerberos Server Name: machine2.EXAMPLE.com

    Return Principal with Domain Name: false

    Authentication Level: 22

    Note –

    If you are using Windows 2003 or Windows 2003 Service Packs,, use the following ktpass command syntax:


    ktpass /out filename /mapuser username /princ HTTP/hostname.domainname 
     /crypto encryptiontype /rndpass /ptype principaltype /target domainname

    For example:


    ktpass /out demo.HTTP.keytab /mapuser http 
/princ HTTP/demo.identity.sun.com@IDENTITY.SUN.COM /crypto RC4-HMAC-NT 
/rndpass /ptype KRB5_NT_PRINCIPAL /target IDENTITY.SUN.COM

    For syntax definitions, see KTPASS Syntax.

  5. Restart the server.

ProcedureTo Reduce the Size of a Kerberos Ticket

All Active Directory groups to which a user belongs are encoded within an issued Kerberos ticket, increasing the size of the HTTP header. Choose one of the following options to reduce the ticket's size.

  1. Increase the default maximum header size of the web container being used.

    For example, when using Glassfish replace:

    <connection-pool max-pending-count="4096" 
queue-size-in-bytes="4096" receive-buffer-size-in-bytes="4096" 
send-buffer-size-in-bytes="8192"/>

    with

    <connection-pool max-pending-count="4096" 
queue-size-in-bytes="65536" receive-buffer-size-in-bytes="65536" 
send-buffer-size-in-bytes="65536"/>

  2. Disable the PAC for the OpenSSO service account

    This is the Microsoft extension to Kerberos that contains the Active Directory groups. See http://support.microsoft.com/kb/832572.

ProcedureTo Set Up Internet Explorer

  1. In the Tool menu, go to Internet Options > Advanced/Security > Security.

  2. Select the Integrated Windows Authentication option.

  3. Go to Security > Local Internet.

    1. Select Custom Level. In the User Authentication/Logon panel, select the Automatic Logon Only in Intranet Zone option.

    2. Go to Sites and select all of the options.

    3. Click Advanced and add the OpenSSO Enterprise to the local zone (if it is not added already).

Troubleshooting

If you are using Microsoft Internet Explorer 6.x for Windows Desktop SSO authentication and the browser does not have access to a Kerberos/SPNEGO token for the user that matches the (KDC) realm defined in the Windows Desktop SSO module, the browser will behave incorrectly for other modules after Windows Desktop SSO authentication fails. The direct cause of the problem is that after Windows Desktop SSO fails, the browser becomes incapable of passing all authentication module callbacks to OpenSSO Enterprise until the browser is restarted. Therefore all the modules coming after Windows Desktop SSO will fail due to null user credentials. See http://support.microsoft.com/default.aspx?scid=kb;en-us;308074 for related information.

Note –

As of this release, this restriction has been fixed by Microsoft. For more information, see http://www.microsoft.com/technet/security/bulletin/ms06-042.mspx.

Installing a Samba Client for Windows NT Authentication

To activate the Windows NT authentication module, Samba Client 3.x must be downloaded and installed. Samba is a file and print server for blending Windows and UNIX machines without requiring a separate Windows NT/2003 Server. See To Install the Samba Client for more information.

Tip –

Red Hat Linux ships with a Samba client located in the /usr/bin directory.

ProcedureTo Install the Samba Client

  1. Download the Samba software from http://www.samba.org.

  2. Install the software to the OpenSSO-Deploy-base/OpenSSO-deploy-uri/bin directory.

  3. (Optional) When running OpenSSO Enterprise on AIX, follow this sub procedure.

    See the Samba README for the reasons this startup script might be necessary for your deployment.

    1. Create a smbclient wrapper script.

      For example:

      #!/bin/sh

unset LIBPATH
/usr/bin/smbclient $@

    2. Copy the wrapper script to the OpenSSO-Deploy-base/OpenSSO-deploy-uri//bin directory.

  4. (Optional) Set multiple interfaces by configuration of the smb.conf file which is passed to the smbclient.