Chapter 6   Managing Authentication


This chapter explains how to setup and administer authentication for your iPS portal, and how to customize authentication modules, if needed. Topics covered include:

• An overview of iPlanet Portal Server authentication methods

• Managing authentication attributes

• How to set up authentication for users

• How to customize authentication modules on your portal

Overview of iPlanet Portal Server Authentication

---

This section briefly describes how authentication works on your portal.

iPlanet Portal Server uses authentication to verify the identity of users trying to access your portal. You primarily use the Administration Console and iPlanet Portal Server desktop to set up authentication.

---

Note

---

Default Authentication Methods

When you install iPlanet Portal Server using a standard (not customized) iPlanet Portal Server installation, the following authentication modules are enabled on your portal:

• S/Key

• SecurID

• SafeWord

• UNIX/NIS

• Windows NT

• LDAP

• Personal Digital Certificates (PDCs)

• RADIUS

• Membership

The iPlanet Portal Server product includes only the client modules for RADIUS, SafeWord, SecurID (ACE/client, NT primary domain controller), and LDAP. You must obtain the server modules for these authentication types from a third-party supplier to have the full implementation.

Common Authentication Tasks

Some common tasks involving customizing authentication include:

• Setting up modules that require site-specific information (for example, an LDAP server name and DN to start search, RADIUS server and shared secret)

• Limiting authentication modules, by disabling modules not needed in your environment

• Customizing prompts and screens for authentication (and failure messages).

• Customizing the behavior subsequent to authentication to automatically launch specific applications or Web sites

Files Used for Authentication

You might need to view the iPS configuration files directly, for example, to verify a specific setting. Moreover, you need to directly edit configuration files on the iPS server for some authentication settings and customization. Table 6-1 describes the files that iPS authentication uses.

---

Note	All paths and file names specified in this chapter assume a default installation in /opt. (Configuration files are always in /etc/opt). If you have changed the installation location, your paths will differ from those listed in this chapter.

---

Table 6-1 Files and directories related to authentication settings.

Files	Purpose
/etc/opt/SUNWips/platform.conf	Lists the authentication process to start with iPlanet Portal Server, on the lines starting with ips.daemons and the subsequent lines containing port settings for each of the listed specified process.
/etc/opt/SUNWips/auth/default/*.html and /etc/opt/SUNWips/auth/default/*.properties	Contain the base pages displayed during the authentication process. Review this chapter before changing these files.

How the Users Experience the Authentication Process

When end users first access the login URL, they may be presented with an HTML authentication page, depending on the domain of the end user and whether the administrator has configured the system to prompt for authentication. If the iPlanet Portal Server server is configured with multiple authentication modules, end users are presented with a menu of authentication types and the kind of information requested depends on the option they choose. If only one authentication module is configured and some form of authentication entry is required, the end user bypasses the authentication menu and sees only the specific authentication page.

If user-based authentication has been configured for the domain, the user is prompted for a userID first. Then the authentication types enabled for that user are presented in a menu.

If end users fail authentication, they are directed to an authentication-failed page. This page does not indicate to the end user the specific reason that authentication failed. After a successful authentication, end users are redirected to the iPlanet Portal Server Desktop.

---

Note	Upon a failed Administration authentication attempt, a message describing the reason for the failure is sent to the authentication log.

---

Setting Up User Authentication for a Multiple Domain Portal

When configuring a multiple-domain portal, you must tell users how to authenticate to the correct domain. You can do this by either:

• Requiring users to type their domain names at the time of authentication

• Using a virtual host name for the gateway

Requiring the User to Type a Domain Name

Suppose you have two domains named eng and corp, and a gateway named gateway.eng.sun.com. Click Manage Domains, and then choose one of the domains. If you have added more gateways after initial installation, in the Authentication profile for that domain, you can add gateway.eng.sun.com/corp to the Domain URLs attribute for the corp. The default domain URL, /corp, should already be there. Do the same for the eng domain.

To connect to iPlanet Portal Server, users in the eng domain authenticate by typing the URL https://gateway.eng.sun.com/eng, and users in the corp domain type https://gateway.eng.sun.com/corp.

You can use multiple strings for each domain, but at least one must match what the user enters as the URL.

Using a Virtual Host Name for the Gateway

You can use a virtual host name for the gateway, or have multiple DNS names for one gateway interface. For example, assume that your gateway has both the DNS names gateway.eng.sun.com and gateway.corp.sun.com. Users from the eng domain would authenticate by typing https://gateway.eng.sun.com, and users from the corp domain would authenticate by typing https://gateway.corp.sun.com.

To configure your iPlanet Portal Server installation to allow this, click Manage Domains link at the left from, select the desired domain, expand the Authentication link and modify the Domain URL attribute in each domain. The attribute for the named domain will then have the string hostname.domainname and the attribute for the named domain would have the string gatewayname.domainname.

Managing Authentication Attributes

---

You can define authentication attributes on a platform-wide and on a domain-specific basis using the Administration Console.

To Define Platform-Wide Authentication Attributes

Use the Administration Console to define platform-wide authentication attributes. You must be the Super Administrator to define platform-wide attributes.

1. Click Manage Platform Settings at the left of the Administration Console screen.

2. Click the Authentication link on the right of the Portal Server Platform.

3. Click the Show Advanced Options on the Component Profile: Auth screen.

   From this page, you can set values for the various attributes that apply to the authentication scheme for the entire portal.

To Define Domain-Specific Authentication Attributes

Use the Administration Console to define domain-specific authentication attributes. You can be a delegated administrator for the particular domain or Super Administrator to perform the next steps.

1. Click Manage Domains at the left of the Administration Console.

2. Click the link for the domain to be administered, as displayed on the Portal Server Domains page.

3. Click the Authentication link on the Domain, Role & User Profiles page and configure attributes that pertain to the domain.

4. Press Submit to activate your changes, and then press Continue to return to the Authentication profile page.

5. Click the Back to Overview link to return to the Domain, Role & User profile page.

6. Expand the Authentication tree to display links for each supported authentication type.

7. Click the link for the authentication type that you want to configure.

   You display the profile page for the particular authentication type.

8. Define the attributes for the authentication method as needed for your portal.

Setting Up Authentication for Users

---

This section explains how to set up the available authentication types for users. Topics covered include:

• Configuring authentication for administrators

• Generating S/Key passwords for users

• Configuring LDAP authentication for users

• Configuring PDCs and devices

• Configuring Windows NT authentication for users

• Configuring SafeWord authentication for users

• Configuring SecurID authentication for users

• Configuring RADIUS authentication for users

• Configuring UNIX/NIS or Membership authentication for users

Configuring Authentication for Administrators

To configure the authentication type for an administrator, follow these steps:

1. Select Manage Administrators from the Administration Console main menu, under Roles and Users.

2. Click the adminRole for the domain you want to configure.

   For a delegated administrator, click Manage Domains from the left pane -> View Domain Administrator Roles, and then the appropriate Admin Role.

3. Click Authentication to view the Authentication profile.

4. Change the Admin Authenticator attribute to reflect the authentication type for that administrator

5. Press Submit to activate the changes.

Configuring S/Key Authentication

S/Key is the one-time password system developed by Bellcore. S/Key users must be valid UNIX/NIS users known to the iPlanet Portal Server server system.

Although each iPlanet Portal Server Server can support multiple domains, S/Key's reliance on the UNIX/NIS authentication restricts all domains to the single set of UNIX/NIS userIds the iPlanet Portal Server Server system can authenticate as valid.

When the user logs in using S/Key as an authentication type, the initial S/Key authentication screen prompts for the user's Unique UserID (UUID) and Personal Identification Number (PIN). If these are validated, then the user is prompted for the next expected one-time password. (This password is actually a six-word passphrase).

Only one of the attributes for S/Key is worth mentioning: S/Key Maximum Passphrases To Generate. Since each time a user logs in, S/Key requests a different passphrase from a list of passphrases specifically generated for that user, S/Key is set up to create such a list upon demand by a user or a system administrator. While maximum number of passphrases that can be set is 400, most system administrators find it more convenient to use the default of 100 when producing a passphrase list.

A system administrator must remember to generate a list of S/Key passwords for a user before that user attempts remote access for the first time.

S/Key Password Generation

Anyone with a valid UNIX userID on the iPS server can generate S/Key passwords for themselves to use with iPlanet Portal Server. Those with "S/Key Generation" authority (usually administrators) can generate new S/Key passwords for others to use when authenticating themselves to the iPlanet Portal Server desktop.

After you have set the S/Key generation privilege for the AdminRole, you can go on to generate actual keys for the users. Or you can show users how to generate their own S/Key. However, point out to your users that they must be careful to generate new password lists before logging out of a session, as stated in the Note under step 7 of "To Have Users Generate Their Own S/Key" on page 105.

To Enable S/Key Generation

---

Note	You must be Super Administrator to perform this procedure.

---

1. Access the Administration Console and click Manage Domains.

2. Click the name of the Domain you want to administer, and then click View Domain Administrator Roles.

3. Click the name of the administrator Role, for example, AdminRole for the Super Administrator of the default domain.

4. Click Policy to display the Policy Module.

5. Click S/Key Generation to move to the S/Key Generation privilege.

6. Ensure that the Generate S/Keys box is checked to enable this privilege.

7. Press the Submit button to submit the change to the Profile Server. Click the Continue button when prompted that the change has been made.

To Generate S/Keys for Users

1. Log in as the Super Administrator or the delegated Administrator to the iPlanet Portal Server desktop.

2. Edit the URL by changing the ending /DesktopServlet to /SKeyGeneration.

   The Generate S/KEY Passwords Login screen is displayed, as shown in Figure 6-1.

   
   
   

Figure 6-1    Generate S/Key Login Screen

3. Specify the UNIX userID, number of S/Key passwords to generate, and the PIN to use for that particular user.

4. Press Submit Query.

   The new one-time passwords generated for the user are displayed.

5. Print the resulting list so that you can provide it to the user.

6. Return to the iPlanet Portal Server desktop by changing the ending of the URL from /SKeyGeneration to /DesktopServlet.

7. Repeat the steps above for each user to receive S/Key passwords.

   When you generate the passwords on behalf of end users, give them the unique userID (UUID) and list of passwords and, separately, give them the PIN that you used. For security, the end users should keep this PIN separate from the UUID and the list of passwords.

To Have Users Generate Their Own S/Key
End users can generate their own set of S/Key passwords. Give the users the following steps:

1. Start a Web browser, and enter the URL to display the iPlanet Portal Server system login menu.

2. Select UNIX authentication and type your UNIX userID (UUID) and password.

   The iPlanet Portal Server Desktop is displayed.

3. Edit the URL by changing the ending /DesktopServlet to /SKeyGeneration.

   The Generate S/KEY Passwords Login screen is displayed with your UNIX userID printed at the top.

4. Specify the number of S/Key passwords to generate.

5. Type a PIN of five alphanumeric characters or more, press Return, and then retype the PIN.

6. Press Submit Query.

   Your new one-time passwords appear in the browser. You can print them out using the browser's print feature.

   
   

   ---

   Note

   If you use the last password and log out before generating a new list of passwords, then either your iPlanet Portal Server administrator has to generate a new list of S/Keys for you, or you have to repeat S/Key generation as described, beginning in Step 1. Generating more S/Key passwords supersedes the previously generated list. Also, the UUID for that user will change.

   ---

   
   

7. Return to the iPlanet Portal Server Desktop by changing the ending of the URL from /SKeyGeneration to /DesktopServlet.

8. Log out of the Desktop, and then return to the desktop login.

9. Authenticate yourself by clicking S/Key Authentication.

   The S/Key login screen appears, as shown in Figure 6-2:

   
   
   

Figure 6-2    S/Key Login Screen

10. Type the Unique User ID (UUID) from the list in the appropriate box, and then press Return.

11. Type the PIN.

12. Click Submit

    The S/Key Authentication screen is displayed.

    
    
    

Figure 6-3    S/Key Authentication Screen

13. Type the list of one time passwords for the sequence requested and press Submit.

If authentication is successful, the iPlanet Portal Server desktop is displayed.

Reinstalling the iPlanet Portal Server software deletes all S/Key password information for all users.

Authentication Using the LDAP Server

iPlanet Portal Server supports both the LDAP v2 and LDAP v3 servers.

It is important to distinguish between the user authenticating with the iPlanet Portal Server LDAP authentication module and the LDAP authentication module itself when authenticating to the LDAP directory. The iPlanet Portal Server user is simply sending a userID and password to the gateway, which then binds to the LDAP directory and verifies the user's userID and password in the directory. If the userID and password are in the directory, the user is allowed access and is set up with a valid iPlanet Portal Server session.

In order to access the Directory Service, a Directory Service client needs to first authenticate itself to the service. That is, the client needs to tell the Directory Service who is going to be accessing the data, so that the server can decide what the client is allowed to see and do. in iPlanet Portal Server's case, the client is the LDAP authentication module. There are two options for authenticating the iPlanet Portal Server authentication module to the Directory Service:

1. Anonymous authentication. This method means that the iPlanet Portal Server authentication module does not need to authenticate to the Directory Service before checking whether the Directory Service has a valid userID and user password in the directory. By not setting the following attributes, anonymous authentication will be used:

      iwtAuthLdap-bindDN
      iwtAuthLdap-bindPasswd

2. Password-based (simple) authentication. This method requires the iPlanet Portal Server authentication module to bind to the directory with its distinguished name (DN) and user password before validating the user. By setting the following attributes, iPlanet Portal Server will bind to the directory before validating the user:

      iwtAuthLdap-bindDN o=sun.com,ou=engineering,uid=admin
      iwtAuthLdap-bindPasswd mypassword

Security

By default, the information sent from the iPlanet Portal Server authentication module to the Directory Service is in clear text. This means the data could be read by someone listening on the network. If this is a concern, you may choose to use SSL between the iPlanet Portal Server authentication module and the Directory Service. Your Directory Service must be configured to use SSL in order for this to work. Then you need to set the following attribute to true (the default is false):

iwtAuthLdap-sslEnabled = true

Which LDAP Server to Use?

The iwtAuthLdap-server attribute specifies the LDAP server which iPlanet Portal Server uses to validate your users. The format is server:port, where :port is necessary only if you are not using the default LDAP port of 389. For example, if your server name is ldserver.eng.sun.com and it listens on port 876, then the attribute iwtAuthLdap-server should be set to ldserver.eng.sun.com:876. If the Directory Service listens on 389, it should be set to ldserver.eng.sun.com.

If you have a multiple domain configuration, you may configure a different LDAP server for each domain. Please refer to the section Authentication in Multiple Domains for more information.

Configuring LDAP Authentication

To configure LDAP authentication:

1. Click Manage Domains from the Administration Console menu.

2. Click the link for the domain for which you want to configure LDAP authentication.

3. Expand the Authentication tree, and then click Ldap.

4. Configure the following attributes to specify the necessary properties for LDAP Authentication.

   For example, if you want to use anonymous bind and one level search from cn=Eng,ou=Engineering,o=sun.com, then provide the following information:

   
   

   
   
   

   LDAP authentication server	myserver.eng
   DN to start search	cn=Eng,ou=Engineering,o=sun.com
   scope for the userId search	ONELEVEL

   Or, if you want to use admin bind and subtree search from o=sun.com, with SSL enabled, then provide the following information:

   
   

   
   
   

   LDAP authentication server	myserver.eng
   DN to start search	o=sun.com
   DN for root user bind	uid=admin,ou=Engineering,o=sun.com
   Password for root user bind	12345
   scope for the userId search	SUBTREE
   Enable SSL to LDAP server	Checked

Configuring Personal Digital Certificates (PDCs) and Encoded Devices Authentication

iPlanet Portal Server lets users authenticate using PDCs and encoded devices such as smart cards and Java Cards. The encoded devices carry an electronic equivalent of a PDC stored on the card. If a user logs in using one of these mechanisms, no login screen appears and no authentication screen appears.

The authentication process for PDCs involves several steps:

1. At a browser, the user types a connect request:

   http://my.ips.com

   The response to this request depends on whether the gateway to my.ips.com has been configured to accept certificates.

2. When a gateway is configured to accept certificates, it will accept only logins with certificates, not any other kind of login. If it has not been configured to accept certificates and no other authentication modules are enabled, the user's connection request is denied.

To configure the PDC and encoded devices with the gateway, do the following:

1. Go to the Admin Console.

2. Select Gateway Management from the menu at the left.

3. Select the Manage Gateway Profile link

4. Click in the text box under the PDC Enabled field and enter the fully qualified name that is configured for the PDC and any used encoded devices.

5. Click the Add button to add this name to the list window.

   When configured, the gateway asks the user for their certificate and the connect process continues.

6. The user sees a Select Certificate dialog box and types in a password.

7. The gateway looks at the certificate, checks that the certificate was issued by a known Certificate Authority, has not expired, and has not been tampered with. If the certificate is deemed valid, the gateway lets the user proceed to the next step in the authentication process.

8. The gateway contacts the PDC authentication module in the server and passes it the certificate.

   The server checks how two attributes, "check CRL" and "check certstore," have been set.

   If "check CRL" has been set to yes, the server checks to see if the certificate matches an existing certificate revocation list inside the LDAP server. If a match exists, the user is allowed to proceed; if not, the user is denied access.

   If "check certstore" has been set to yes, the server attempts to match the certificate received from the client with an existing certificate inside the LDAP server. If a match exists, the user is allowed to proceed; if not, the user is denied access.

   .

   
   

   ---

   Note	Certificate management tools that manage the addition and deletion of certificates in LDAP are to be provided by the customer or by vendors of certificates. Sun does not provide these tools.

   ---

   
   

Managing PDC Attributes

The Certificate authentication module attributes can be managed from within the platform.conf file. This file contains the attributes described in "PDC Attributes" on page 112.

Table 6-2 PDC Attributes 

Attribute entry in platform.conf file	What it does
iwtAuthCert-chkCertInLDAP	Check user certificate to see if it is in LDAP. If certificate has been issued previously, it will be in the LDAP server. Initial value is false.
iwtAuthCert-chkCRL	Check user certificate against Certificate Revocation List in LDAP. Initial value is false.
iwtAuthCert-ldapFactory	Location of LDAP class library.
iwtAuthCert-ldapProviderUrl	URL of LDAP certificate server. Default value is ldap://LDAP host:389.
iwtAuthCert-startSearchLoc	Name (DN) of node in LDAP where search for certificate should start.
iwtAuthCert-securityType	LDAP access authentication method: none = access to LDAP does not require a principal name or password simple= access to LDAP does require a principal name and password; these will be sent to LDAP in plain text. CRAM-MD5=access to LDAP does require a principal name and password; these will be sent to LDAP encrypted.
iwtAuthCert-principleUser	Principal user (usually system administrator) for the certificate LDAP server.
iwtAuthCert-principlePasswd	Principal user's password.
iwtAuthCert-useSSL	Use SSL to access the certificate LDAP server.
iwtAuthCert-userProfileMapper	Which field in Certification should be used to verify user profile information? (issuer|serial number|subject DN|Certificate)
iwtAuthCert-debug	Debugging flag. Default value is false.
iwtAuthCert-aliases	Name of field in Certification to match user profile; used by authentication daemon to map a name field to a user profile.

Configuring Windows NT Primary Domain Controller Authentication

Many enterprise customers have environments in which end users are required to be authenticated against a NT Primary Domain Controller. This type of authentication is specified from the admin console as follows.

1. Choose Manage Domains.

2. Click on the domain of interest.

3. Expand the Authentication link.

4. Click the NT profile in the Administration Console to see the application attributes for NT.

The iPlanet Portal Server NT Authentication module lets users authenticate the username and password they would normally use when accessing their NT desktops.

The following attributes are used by the iPlanet Portal Server authentication module to determine where to send the request to validate the user. By default, the user is prompted for username, password, and NT host. The NT domain where the host resides is taken from iwtAuthNT-domain.

The default properties file for the NT authentication module is in /etc/opt/SUNWips/default/auth/NT.properties and contains the following:

SCREEN

TIMEOUT 60

TEXT NT Authentication

TOKEN Host

TOKEN User Name

PASSWORD Password

The NT authentication module can be configured to prompt the user to enter userID, password, NT host, and NT domain. In this case, user entries are used instead of stored attributes.

In this case, the properties files should be modified to look like the contents of /etc/opt/SUNWips/auth/(DOMAIN)/NT.properties. Properties should be ordered as follows:

SCREEN

TIMEOUT 60

TEXT NT Authentication

TOKEN Host

TOKEN Domain

TOKEN User Name

PASSWORD Password

The properties file can be configured to prompt the user only for username and password. In this case, both the server name and domain name are taken from the attributes set in the Administration Console. The properties file should then be the following, in order:

SCREEN

TIMEOUT 60

TEXT NT Authentication

TOKEN User Name

PASSWORD Password

Configuring SafeWord Authentication

The iPlanet Portal Server Server SafeWord authentication client is implemented using Secure Computing's SafeWord remote client API. The SafeWord server does not have to reside on the iPlanet Portal Server Server.

The SafeWord authentication system uses hardware tokens, which are obtained from Secure Computing. When logging onto the iPlanet Portal Server Server using SafeWord authentication, you initially supply only your userid. Subsequently you must supply a response (generated by your SafeWord token) to the challenge issued by the SafeWord server.

Follow these steps:

1. Enter the URL to display the system login menu and select SafeWord authentication.

2. Enter your login information in the iPlanet Portal Server Authentication screen.

   You receive a "challenge" from the SafeWord authentication server.

3. Turn on your token and enter the Personal Identification Number (PIN).

4. Enter the challenge from Step 1 on your token.

5. Enter the response from your token in response to the challenge from the SafeWord authentication server.

The SafeWord token configuration has no known restrictions. The SafeWord token can be used over RADIUS when authenticating to a SafeWord RADIUS server. See the section "Configuring RADIUS Authentication" on page 117."

Each iPlanet Portal Server Server can support multiple domains. Since each domain can have its own dedicated SafeWord server, the information needed to configure the SafeWord authentication helper is defined at the domain level. Information about all of the known SafeWord servers is sent to the iPlanet Portal Server Server SafeWord authentication helper during its configuration; to update the helper's configuration, restart the iPlanet Portal Server Server. The SafeWord helper is described in "Starting Debugging Using the SafeWord Helper" on page 210.

Viewing or Changing SafeWord Attributes

To view or modify the SafeWord attributes, follow these steps:

1. Log in to the iPlanet Portal Server Administration Console.

2. In the left frame, click on the Manage Domains link. In the right frame, click on the domain of interest, then the SafeWord link from the expanded list of iPlanet Portal Server Authentication profiles.

3. You must change at least the SafeWord Server Hostname attribute (initially null) for SafeWord authentication to work in your installation. Enter the hostname of your SafeWord Server.

4. The SafeWord Server Identifier field is set by the SafeWord authentication module during helper configuration time.

5. Use the default SafeWord system values for Server's Port (7842) and System name (STANDARD). If you have a simple SafeWord system installation, neither of these need changing.

6. Unless a problem cannot be solved using the steps described in the Debugging section, the SafeWord Logging Level can and should remain 0 (no logging).

7. Click the Submit button to update your changes in the Profile Server. The iPlanet Portal Server Server must be restarted for your changes to take effect in the SafeWord authentication module and helper.

Configuring SecurID Authentication

The iPlanet Portal Server Server SecurID authentication client is implemented using Security Dynamics' ACE/Client API. The ACE/Server is usually installed on a system other than the iPlanet Portal Server Server. The SecurID token (available from Security Dynamics) may also be used over RADIUS when authenticating to an ACE/Server RADIUS server.

iPlanet Portal Server may support multiple domains. Since each domain may have its own dedicated ACE/Server, the information needed to configure the SecurID authentication helper is defined at the domain level. Information about all of the known ACE/Servers is sent to the iPlanet Portal Server Server SecurID authentication helper during configuration. To update the helper's configuration, restart the iPlanet Portal Server server.

When logging into the iPlanet Portal Server server using SecurID authentication, you supply your userID and the concatenation of your PIN and your token's current value. You may receive other prompts if you enter the "next Token" or "new PIN" modes during your authentication session.

Viewing or Changing SecurID Attributes

To view or modify SecurID attributes, follow these steps:

1. Log into the Administration Console.

2. Click on the Manage Domains menu option at the left.

3. Click on the Authentication link. In the right frame, click on the domain of interest, then the SecurID link from the expanded list of iPlanet Portal Server Authentication profiles.

4. You may have to change the SecurID Server's Configuration Path (initially /opt/ace/data) for SecurID to work in your installation, especially, if your installation has multiple domains with SecureID authentication. Change this path to reflect where the domain's ACE/Server configuration file, sdconf.rec, is located.

   This path may not actually contain any configuration information, so it may remain the default /opt/ace/data path. However, if there are multiple ACE/Servers, discrete SecurID Server Configuration Paths must be specified. Additionally, the sdconf.rec files from the corresponding ACE/Server systems must be placed in those directories.

5. The SecureID user configuration path can usually remain as the default /opt/ace/prog even if your installation has multiple domains with SecureID authentication.

6. The default SecurID system values for "SecurID Server Identifier Name" may remain the default value (Server000), though this value can be changed to reflect the Server Identifier (Local).

7. Click the Submit button to update your changes.

Configuring RADIUS Authentication

The RADIUS module is a client implementation of Remote Authentication Dial In User Service (RFC 2138, not including the accounting features of RFC 2139).

RADIUS authentication uses a password assigned by the RADIUS server system to the workstation making an authentication request.

Each iPlanet Portal Server Server may support multiple domains. Since each domain may have its own dedicated RADIUS servers, the servers and shared secret are configured at the domain level.

The following RADIUS codes are supported:

• Access-Request

• Access-Accept

• Access-Reject

• Access-Challenge

Viewing or Changing RADIUS Attributes

To view or modify RADIUS attributes, follow these steps:

1. Log in to the iPlanet Portal Server Administration Console.

2. In the left frame, click on the Manage Domains link. In the right frame, click on the domain of interest, then the RADIUS link from the expanded list of iPlanet Portal Server Authentication profiles.

3. Change the RADIUS shared secret and the RADIUS Server 1 and Server 2 fields for RADIUS to work in your installation.

   Enter the shared secret (default is "nosecret") through the Administration Console.

   Enter the hostname or IP address for both Server1 and Server2 (defaults are 127.0.0.1). If a Server2 is not present, clear the RADIUS Server2 field and leave it blank.

4. Change the RADIUS Server's Port value from 1645 to the actual port number, if it doesn't use the default value.

5. Click the Submit button to update your changes in the Profile Server. The iPlanet Portal Server Server must be restarted for your changes to take effect in the SafeWord authentication module and helper.

When logging into the iPlanet Portal Server Server using RADIUS authentication, supply your userID and password. You may subsequently need to supply more information in the form of responses to challenges, especially if you are using SafeWord or SecurID tokens over RADIUS.

Attributes for RADIUS authentication include the following:

• User-Name

• User-Password

• NAS-IP-Address

• NAS-Port

• Reply-Message

• State

"User-Name" and "User-Password" are the userID and password you used to login. NAS-IP-Address and NAS-Port refer to the Network Access Server's IP address and port used to access the network.

"Reply-Message" is the message the server sends in its reply to a RADIUS client's access request. In an Access-Accept, it's the success message; in an Access-Reject, it's the failure message; in an Access-Challenge, it is the dialog message (for example, when using a RADIUS-to-SafeWord RADIUS server, it would be the SafeWord challenge).

For RADIUS debugging issues, refer to "Debugging RADIUS" on page 213.

Configuring UNIX Authentication

Most iPlanet Portal Server system administrators already have UNIX userIDs and passwords associated with the Solaris systems they are running. A quick and easy way to become an authenticated user on a new iPlanet Portal Server installation is to use that UNIX userID and password. Once set up, of course, the system administrator may prefer to use a different form of authentication.

Although each iPlanet Portal Server Server may support multiple domains, UNIX authentication restricts all domains to the single set of UNIX/NIS userIDs the iPlanet Portal Server Server system can authenticate as valid.

The UNIX/NIS authentication module validates userid-password pairs. The system administrator can administer userids locally (through, for example, admintool) or through NIS.

If you are using a UNIX userID and password (local file, NIS, or both) for authentication, then you must make sure that the passwd: entry in the /etc/nsswitch.conf file on the iPlanet Portal Server server is set up correctly.

Customizing Authentication on Your Portal

---

This section explains how to tailor authentication to your portal's needs by customizing the authentication modules.

Editing the Properties Files

You can see the authentication screen properties for each authentication module in a properties file that can be edited from the command line. The properties files for the module are located in /etc/opt/SUNWips/auth/default on the iPlanet Portal Server server. For example, the UNIX authentication modules properties file is /etc/opt/SUNWips/auth/default/UNIX.properties.

Each authentication module has a TIMEOUT parameter that can be modified in the corresponding file:
/etc/opt/SUNWips/auth/default/authentication_module.properties.

This time-out specifies the number of seconds that the end users have to submit the screen before the time-out page displays. The default for each module is 60 seconds.

For example, if you want to make sure that the end users using a UNIX login have two minutes (120 seconds) to log in, change the TIMEOUT parameter in the /etc/opt/SUNWips/auth/default/UNIX.properties from 60 to 120.

The doUNIX helper (and helpers in general) also has a time-out attribute value that is separate from this TIMEOUT value. If they are of different values, the component (authentication module or helper) with the shorter time-out value will terminate the authmodule-helper session, and the authentication request fails. (For complete information on helpers, refer to Authentication Helpers (daemons).)

Each HTML page that is sent for the authentication module has a keyword SCREEN followed by keyword TEXT, followed by any number of the keywords TOKEN and PASSWORD. Each screen might also contain an optional TIMEOUT keyword.

For example, the UNIX.properties file contains the following entries as shown in Code Example 6-1, with keyword definitions provided in "Properties File Keywords" on page 120.

Code Example 6-1 Sample UNIX.properties File

SCREEN TIMEOUT 60 TEXT UNIX User Password Login TOKEN Enter Your UserId PASSWORD Enter Your Password

---

Note	You cannot change the ordering of any of the tokens

---

Table 6-3 Properties File Keywords

Keyword	What it means
TIMEOUT	This keyword specifies the number of seconds the authentication module will wait before sending the user a login session time-out page.
TEXT	Each screen has one TEXT keyword. This is the text that is displayed at the top of the authentication page. It is typically used to describe the authentication module or as an informational message to the end user.
TOKEN	Each TOKEN keyword causes an input box to be displayed. The text after the keyword is displayed above the input box. You cannot change the ordering of the tokens.
PASSWORD	Each PASSWORD keyword causes an input box to be displayed. The text after the keyword will be displayed above the input box. The only difference between the TOKEN and PASSWORD is the PASSWORD text will not be echoed, but will be asterisks. You cannot change the ordering of the tokens.
IMAGE	This keyword instructs the authentication module to replace the standard iPlanet Portal Server image with the image following the keyword. The image should be placed in /etc/opt/SUNWips/auth/default/optionaldomain. This image should be a GIF file.
HTML	This keyword tells the authentication module to override the dynamic HTML generation and supply your own HTML page. The authentication modules expect to receive URL parameters specific to each type of authentication. If you override the HTML for a module, your HTML page must supply the correct number and names of the parameters and show a small section of the HTML necessary for the UNIX page. One such sample is shown in Code Example 6-2 below.

The following HTML code will be generated given the UNIX properties file shown in Code Example 6-2. The user does not have to create this.

Code Example 6-2 Section of HTML Code for the UNIX Page

<P><STRONG>Enter Your UserId</STRONG><BR> <INPUT TYPE=" NAME=TOKEN0 SIZE="22"></P> <P><STRONG>Enter Your Password</STRONG><BR> <INPUT TYPE="PASSWORD" NAME=TOKEN1 SIZE="22"></P>

The UNIX module expects the userID and password in the parameters TOKEN0 and TOKEN1. To ensure you have the correct HTML you should go to that authentication page and view the HTML source.

Adding or Removing Modules From the Menu

When multiple modules are enabled, the end users see a menu of all the possible authentication modules. When end users click the link for a specific module, the authentication server loads that module. The end users receive the HTML pages for that module. If only one module is enabled, then no menu is sent, and the user is sent directly to the enabled authentication module.

Adding or Removing an Authentication Module from the Platform

You cannot add or remove authentication modules using the Administration Console. You must use the ipsadmin command to do this. See the instructions for using ipsadmin in the iPlanet Portal Server Programmer's Reference for procedures for adding or removing authentication modules.

You must stop and start the servers for it to recognize the changes. You can do this at the command line with the following command:

# /opt/SUNWips/bin/ipsserver start

Changing the Look of Authentication Modules on a Per-Domain Basis

By default, all authentication module pages that are presented to users are identical across all domains. If you want to customize the look and feel of each domain's authentication, you must follow the procedure described below.

By default, all templates for creating authentication pages are in the /etc/opt/SUNWips/auth/default directory.

To Customize an Authentication Module on a Per-Domain Basis

1. Create a subdirectory in /etc/opt/SUNWips/auth and give it the name of the domain you are customizing.

2. Copy all files from /etc/opt/SUNWips/auth/default to that directory.

   All authentication pages for that domain will now be built from the files in the directory corresponding to the domain's name. You can customize the HTML code, colors, etc.

Authentication Helpers (daemons)

Some of the authentication modules provided with iPlanet Portal Server use authentication type-specific "helpers." These helpers are independently running processes with which the corresponding authentication module communicates. Usually, the helper is what is actually communicating with the remote authentication server. Helpers can assist in the debugging process for authentication modules.

When you install iPlanet Portal Server, several authentication helpers are configured and set to start automatically. Each of the helpers is listed in the ips.daemons entry in /etc/opt/SUNWips/platform.conf on each server. By default, this line looks like this:

ips.daemons=securid radius safeword unix skey

If you have started your iPlanet Portal Server gateway, you can confirm that each of these helpers is running by typing:

To return the list of running daemons, including doRadius, doSafeWord, doSKey, doSecurID, and doUNIX.

Additionally, each helper requires a configuration port specified in the /etc/opt/SUNWips/platform.conf file. The default configuration ports for the five helpers mentioned above are:

securidHelper.port=8943

radiusHelper.port=8944

safewordHelper.port=8945

unixHelper.port=8946

skeyHelper.port=8947

Note that these helper configuration ports must also be specified in the Profile Server (using the Administration Console). The helpers get their configuration port specified as a command line argument, which the server startup script gets from the platform.conf file. The server's authentication modules get that information from the Profile Server. The helper's authentication request listening ports are specified during the configuration process, so they need only be specified in the Profile Server.

See the sectionManaging Authentication Attributes to learn to adjust these settings as well as related helper configuration values. For information on starting helpers for different authentication modules, refer to "Troubleshooting Authentication Problems" on page 208.

Platform-wide Authentication Attributes

Some of the attributes that govern the behavior of the authentication modules are platform-wide, since authentication modules handle authentication requests for all domains.

Only Super Administrators can modify platform-wide attributes. Domain Administrators cannot view or modify them.

Appendix B, Table B-1, lists the attributes that are platform-wide. You find them by clicking the Manage Platform Settings link on the iPlanet Portal Server page, then the Profiles->Authentication link on the right side of the window, then the Show Advanced Options button. Authentication attributes that can be changed at the domain level will not appear here. Platform-wide attributes cannot be overridden at lower levels of the role tree.

Appendix B, Table B-2 lists authentication attributes for the Super Administrator profile. These may be found by clicking the links in the order specified:

• Manage Administrators

• Admin Role (under Super Admins)

• Authentication.

• Click the Show Advanced Options button at the bottom.

Authentication Attributes at the Domain Level

Some of the authentication attributes are set only at the domain level. Appendix B, Table B-3 lists the attributes that are domain-wide. Domain-wide attributes, can be customized by either a Domain Administrator or the Super Administrator.

For example, one company may have two domains, each with its own LDAP server, making it necessary to configure a different LDAP server name for each domain. Now suppose Company X has a domain for employees and a domain for partners. The users in the partners domain need to access some special applications. Employees use SafeWord authentication; partners use LDAP.

To implement this scenario, you would do the following after creating the partner domain.

1. Select the Authentication profile under that domain.

2. Edit the Authentication Menu attribute to only select LDAP.

3. Select the LDAP profile and type the name of the server, plus the DN to start search for the partners.

4. Repeat the process for employees, except choose SafeWord as the authentication type.

Once the iPlanet Portal Server server is restarted, partners get the LDAP authentication page and employees get the SafeWord authentication page.

Another example might include two companies sharing the same iPlanet Portal Server installation that must use different authentication methods.

Authentication Attributes at the Role or User Level

Modifying an attribute at the role or user level means that you can customize how iPlanet Portal Server behaves for as many individuals as required. While there are few Authentication attributes that should be customized at the role or user level, some must be, including S/Key settings.

To modify an attribute at the role or user level, navigate to the domain in which this role or user resides, select the specific role or user, select the appropriate authentication module and change the attribute.