The procedures in this section are relevant when using the RADIUS, SafeWord, or the Windows-based authentication modules.
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.
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.
Open the server.policy file in a text editor.
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.
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
Save the server.policy file.
Restart Application Server.
For more information on SocketPermission, see the Java Platform, Enterprise Edition API Specification
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.
In the domain controller, create a user account for the OpenSSO Enterprise authentication module.
From the Start menu, go to Programs>Administration Tools.
Select Active Directory Users and Computers.
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.
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.
Associate the user account with a service provider name.
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.
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.
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
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
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.
Restart the server.
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.
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"/>
<connection-pool max-pending-count="4096" queue-size-in-bytes="65536" receive-buffer-size-in-bytes="65536" send-buffer-size-in-bytes="65536"/>
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.
These steps apply to Microsoft Internet Explorer™ 6 and later. If you are using an earlier version, make sure that OpenSSO Enterprise is in the browser’s internet zone and enable Native Windows Authentication.
Internet Explorer (5.01 or later) running on Windows 2000 (or later) currently supports SPNEGO. In addition, Mozilla 1.4 on Solaris (9 and 10) has SPNEGO support, but the token returned is only a KERBEROS token because SPNEGO is not supported on Solaris.
In the Tool menu, go to Internet Options > Advanced/Security > Security.
Select the Integrated Windows Authentication option.
Go to Security > Local Internet.
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.
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.
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.
Red Hat Linux ships with a Samba client located in the /usr/bin directory.
Download the Samba software from http://www.samba.org.
Install the software to the OpenSSO-Deploy-base/OpenSSO-deploy-uri/bin directory.
(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.
(Optional) Set multiple interfaces by configuration of the smb.conf file which is passed to the smbclient.