Administration Guide › Configure CA SiteMinder® SPS to Support Integrated Windows Authentication

Configure CA SiteMinder® SPS to Support Integrated Windows Authentication

This section contains the following topics:

Configure CA SiteMinder® SPS to Support Integrated Windows Authentication

Configure CA SiteMinder® SPS to Support Integrated Windows Authentication

Integrated Windows Authentication (IWA) uses the security features of Windows clients and servers. IWA enforces Single Sign-On by allowing Windows to gather user credentials during the initial interactive desktop login process and then transmitting that information to the security layer.

SiteMinder, using the Windows Authentication scheme, secures resources by processing user credentials that are obtained by the Microsoft Integrated Windows Authentication infrastructure.

The following diagram describes how you can configure CA SiteMinder® SPS to support IWA:

You can configure one of the following authentication schemes with CA SiteMinder® SPS:

• Windows authentication scheme on Windows server
• Kerberos authentication scheme on Windows and UNIX server

More information:

Configure Windows Authentication

Configure Kerberos Authentication

Windows Authentication Schemes

The Windows authentication scheme allows SiteMinder to provide access control in deployments with Active Directories running in native mode and Active Directories configured to support NTLM authentication. Windows authentication scheme uses SPNEGO to allow initiators and acceptors to negotiate with either Kerberos or NTLMSSP.

Configure Windows Authentication

Perform the following steps to support Windows authentication:

1. Verify the prerequisites.
2. Configure Windows authentication scheme.
3. Enable Windows authentication scheme.
4. Configure web browser to support an automatic login.

Verify the Prerequisites

Verify that you perform the following tasks before you configure CA SiteMinder® SPS to support IWA:

1. Configure a Windows domain controller.
2. Add CA SiteMinder® SPS host as a member of domain host for the Windows domain controller.
3. For legacy WinNT directories or Active Directory in mixed mode:
   • The user directory connection that you create in the Administrative UI specifies the WinNT namespace.
   • The requested resources can be located in any type of web server.
4. For Active Directories running in native mode:
   • User data resides in an Active Directory.
   • User directory connections must specify either an LDAP or AD namespace.
   • The requested resources can be located in any type of web server.
   • Client and server accounts are enabled for delegation.

Configure a Windows Authentication Scheme

You can use a Windows authentication scheme to authenticate users in a Windows environment.

Note: The following procedure assumes that you are creating an object. You can also copy the properties of an existing object to create an object. For more information, see Duplicate Policy Server Objects.

Follow these steps:

1. Click Infrastructure, Authentication.
2. Click Authentication Schemes.

   The Authentication Schemes page appears.

3. Click Create Authentication Scheme.

   Verify that the Create a new object of type Authentication Scheme is selected.

4. Click OK

   The Create Authentication Scheme page appears.

   Note: Click Help for descriptions of settings and controls, including their respective requirements and limits.

5. Enter a name and protection level.
6. Select Windows Authentication Template from the Authentication Scheme Type list.

   Scheme-specific settings appear.

7. Enter Server Name, Target, and User DN information. If your environment requires NT Challenge/Response authentication, obtain the following values from the agent owner:

   Server Name

   The fully qualified domain name of CA SiteMinder® SPS, for example:

   server1.myorg.com

   Target

   /siteminderagent/ntlm/smntlm.ntc

   Note: The directory must correspond to the virtual directory already configured by the installation. The target file, smntlm.ntc, does not need to exist and can be any name that ends in .ntc or the custom MIME type that you use in place of the default.

   Library

   smauthntlm

8. Click Submit.

   The authentication scheme is saved and can be assigned to a realm.

Enable Windows Authentication Scheme

The SPS now supports Windows authentication scheme that is configured on the Policy Server. To let the SPS support the Windows authentication scheme, perform the following steps:

1. Create the WindowsNativeAuthentication ACO parameter in the Policy Server.
2. Set the value of WindowsNativeAuthentication to no.

Note: If you do not define or set the value of the WindowsNativeAuthentication ACO parameter, the SPS does not support the Windows authentication.

Configure Web Browser to Support Automatic Login

To configure automatic logon in Internet Explorer 5.x and 6.x Browsers, perform the following steps:

1. From the menu bar in Internet Explorer, select Tools, Internet Options.

   The Internet Options dialog opens.

2. Click the Security tab to bring it to the front.
3. Select your Internet zone and click Custom Level.

   The Security Settings dialog opens.

4. Scroll down to User Authentication, Logon.
5. Select the Automatic logon with current username and password radio button.
6. Click OK.

To configure automatic logon in Internet Explorer 4.x Browsers, perform the following steps:

1. From the menu bar in Internet Explorer, select View, Internet Options.

   The Internet Options dialog opens.

2. Click the Security tab to bring it to the front.
3. Select your Internet zone from the drop down list.
4. In the Internet zone group box, select the and click Custom radio button and click Settings.

   The Security Settings dialog opens.

5. Scroll down to User Authentication, Logon.
6. Select the Automatic logon with current username and password radio button.
7. Click OK.

CA SiteMinder® SPS is configured to support Windows authentication

Kerberos Authentication Schemes

Kerberos is a standard protocol, designed at MIT, to provide a means of authentication between a client and a server on an open network. The Kerberos protocol protects messages from eavesdropping and replay attacks. Kerberos uses shared secrets, symmetric keys, and Kerberos services. Microsoft Windows operating environments use Kerberos V5 as the default authentication package. Solaris 10 also includes Kerberos V5.

In a Kerberos environment, user accounts and service accounts are named principals. Kerberos uses a trusted third party (the Key Distribution Center, or KDC) to mediate message exchanges between principals. The purpose of the Key Distribution Center is to reduce the risks inherent in exchanging keys.

Kerberos authentication is based on messages that request and deliver tickets. The Key Distribution Center processes two types of tickets:

• Ticket-Granting Ticket (TGT) — used internally by KDC to transport a requestor's credentials to the ticket-granting service (TGS).
• Session Ticket — used by the ticket-granting service (TGS) to transport the requestor's credentials to the target server or service.

Kerberos uses keytab files for logging in to KDC. Keytab files consist of pairs of Kerberos principals and encrypted keys derived from a Kerberos password.

The Kerberos protocol message exchange can be summarized in a simplified way as follows:

1. When a user logs in, the client contacts KDC Authentication Service, requesting a short-lived message (the ticket-granting ticket) containing the user identity information.
2. KDC authentication service generates the TGT and creates a session key that the client can use to encrypt communication with the ticket-granting service.
3. When a user requests access to local or network resources, the client presents the ticket-granting ticket (TGT), an authenticator, and the Service Principal Name (SPN) of the target server to KDC.
4. The ticket-granting service examines the ticket-granting ticket and the authenticator. If these credentials are acceptable, the ticket-granting service creates a service ticket, which includes the user identity information copied from the TGT. The service ticket is sent back to the client.

   Note: The ticket-granting service cannot determine whether the user is granted access to the target resource. The ticket-granting service only authenticates the user and returns the session ticket.

5. After the client has the session ticket, the client sends the session ticket and a new authenticator to the target server, requesting access to a resource.
6. The server decrypts the ticket, validates the authenticator, and grants the user access to the resource.

Configure Kerberos Authentication

Perform the following steps to configure Kerberos Authentication:

1. Configure Kerberos Key Distribution Center (KDC).
2. Configure Policy Server.
3. Configure Web Server.
4. Configure Kerberos authentication scheme.
5. Configure a Kerberos External Realm on Windows.

Configure Kerberos Key Distribution Center

When using Kerberos, the domain controller is the Kerberos Key Distribution Center (KDC) for the Kerberos Realm. In a pure Windows environment, a Kerberos Realm is equivalent to a Windows Domain. The domain controller host provides storage for the user, service accounts, credentials, the Kerberos ticketing services, and Windows Domain services.

Kerberos authentication requires a keytab file, which lets users authenticate with KDC without being prompted for a password. On Windows, use the ktpass command tool utility to create the keytab file and on UNIX, use the ktadd utility creates the keytab file.

Perform the following steps to configure KDC:

1. Create a user account to log in to the workstation.
2. Create a service account for the web server to log in to the web server host.
3. Create a service account for the Policy Server to log in to the Policy Server host.
4. Associate the web server account with a web server principal name.
5. Create a keytab file, which is transferred to the web server host.
6. Associate the Policy Server account with a Policy Server principal name.
7. Create another keytab file and transfer the new keytab file to the Policy Server host.
8. Verify that the web server and Policy Server accounts are Trusted for Delegation.

Important! For any service to use Kerberos protocol, ensure that you create the Service Principal Name (SPN) in the service/fqdn_host@REALM_NAME format.

Configure Policy Server

Perform the following steps in addition to the standard Policy Server configuration:

1. Open the ACO of the agent you want to configure and perform the following steps:
   1. Add the value .kcc to the KCCExt parameter.
   2. Add the value web server principal name to the HttpServicePrincipal parameter.

      Example: HTTP/win2k8sps.test.com@TEST.COM

   3. Add the Policy Server principal name to the SmpsServicePrincipal parameter.

      Example: smps@winps.test.com

2. Configure a Kerberos configuration file, krb5.ini and perform one of the following steps:
   • On Windows, place the krb5.ini file in the system root path.
   • On UNIX, place the krb5.ini file in the /etc/krb5/ path.
3. Deploy the keytab file created on KDC that contains the Policy Server principal credentials to a secure location on the Policy Server.

Important! If the Policy Server is installed on Windows and KDC is deployed on UNIX, ensure that you perform the additional configuration on the Policy Server host using the Ksetup utility.

Configure Web Server

Perform the following steps to configure a web server:

1. Install a SiteMinder Web Agent with SiteMinder Kerberos Authentication Scheme support.
2. Register a trusted host with the Policy Server and configure the Web Agent.
3. Configure a Kerberos configuration file, krb5.ini, and perform the following steps:
   1. Configure KDC for the Kerberos realm (domain).
   2. Configure krb5.ini to use the keytab file containing the credentials of the web server principal.
   3. Place krb5.ini in the system root path on Windows and in /etc/krb5/ on UNIX.
4. Deploy the keytab file created on KDC that contains the web server credentials to a secure location on the web server.

Important! If the web server is installed on Windows and KDC is deployed on UNIX, ensure that you perform additional configuration on the web server using the Ksetup utility.

Configure Windows Workstation

Perform the following steps to configure the Windows workstation:

Important! If KDC is deployed on UNIX, be sure to perform the additional required configuration on the workstation using Ksetup utility.

1. Add the host for the Windows workstation to KDC domain.
2. Log in to the host using user account created on KDC.
3. Configure Internet Explorer to pass credentials automatically:
   1. Initiate an instance of the IE web browser.
   2. Select the Internet options menu.
   3. Select the Security tab.
   4. Select Local intranet tab.
   5. Click Sites and select all three checkboxes.
   6. Select the Advanced tab and add http://*.domain.com to local intranet zone.
   7. Select the Custom level tab under security settings and select Automatic logon only in intranet zone under the User Authentication tab.
   8. Select the Advanced tab from Internet options and select the Enable Integrated Windows authentication (requires restart) option.
   9. Close the browser.

Configure a Kerberos Authentication Scheme

A custom authentication scheme is required to support Kerberos authentication in the SIteMinder environment. Associate this authentication scheme with any realm whose protected resources use Kerberos authentication.

Follow these steps:

1. Log in to the Administrative UI.

   Note: When you create or modify a Policy Server object in the [set the ufi variable for your book], use ASCII characters. Object creation or modification with non-ASCII characters is not supported.

2. Select Infrastructure, Authentication, Authentication Schemes.
3. Click Create Authentication Scheme.
4. Select Custom Template from the Authentication Scheme Type list.

   Custom Template settings appear.

5. Enter smauthkerberos in the Library field.
6. Enter the following values in the Parameter field. Enter the values in the order in the following list, delimited by semicolons:
   1. The name of the host web server and target fields
   2. The Policy Server principal name from the Kerberos domain
   3. The mapping between user principal and the user store search filter

   LDAP Example 1: http://win2k8sps.test.com/siteminderagent/Kerberos/creds.kcc;smps/winps.test.com@TEST.COM;(uid=%{UID})

   LDAP Example 2: http:/win2k8sps.test.com/siteminderagent/Kerberos/creds.kcc;smps/winps.test.com@TEST.COM;(uid=%{UID})

   AD Example 1: http://win2k8sps.test.com/siteminderagent/Kerberos/creds.kcc;smps/winps.test.com@TEST.COM;(cn=%{UID})

   AD Example 2: http://win2k8sps.test.com/siteminderagent/Kerberos/creds.kcc;smps/winps.test.com@TEST.COM;(cn=%{UID})

   ODBC Example 1: http://win2k8sps.test.com/siteminderagent/Kerberos/creds.kcc;smps/winps.test.com@TEST.COM;%{UID}

   ODBC Example 2: http://win2k8sps.test.com/siteminderagent/Kerberos/creds.kcc;smps/winps.test.com@TEST.COM;%{UID}

7. Click OK.

   The Kerberos Authentication scheme is saved and appears in the Authentication Scheme List.

Configure a Kerberos External Realm on Windows

For the Windows workstation to use a Kerberos KDC deployed on UNIX, configure both the Kerberos KDC server and the workstation.

In the Kerberos realm, create a host principal for the Windows host. Use the following command:

kadmin.local: addprinc host/machine-name.dns-domain_name.

For example, if the Windows workstation name is W2KW and the Kerberos realm name is EXAMPLE.COM, the principal name is host/w2kw.example.com.

A Kerberos realm is not a Windows domain, perform the following procedure to configure KDC operating environment as a member of a workgroup:

1. Remove the host from the Windows domain.
2. Add the test user, for example, testkrb, to the local user database.
3. Add the Kerberos Realm:

   ksetup /SetRealm EXAMPLE.COM
   

4. Restart the host.
5. Add KDC:

   ksetup /addkdc EXAMPLE.COM rhasmit
   

6. Set a new password:

   ksetup /setmachpassword password
   

   Note: The password used here is same as the one used while creating the host principal account in the MIT KDC.

7. Restart the host.

   Note: Whenever changes are made to the external KDC and realm configuration, a restart is required.

8. Set the Realm Flag

   ksetup /SetRealmFlags EXAMPLE.COM delegate
   

9. Run AddKpasswd:

   ksetup /AddKpasswd EXAMPLE.COM rhasmit
   

10. Use Ksetup to configure single sign on to local workstation accounts by defining the account mappings between the Windows host accounts to Kerberos principals. For example:

    ksetup /mapuser testkrb@EXAMPLE.COM testkrb
    ksetup /mapuser * *
    

    The second command maps clients to local accounts of the same name. Use Ksetup with no arguments to see the current settings.

CA SiteMinder® SPS is configured to support Kerberos authentication.

Kerberos Configuration Examples

The configurations that follow include examples of the specifics, such as keytab file creation, required to implement Kerberos authentication in a SiteMinder environment. Note that additional configuration is required when KDC is deployed in a UNIX operating environment and the Policy Server, or web server, or workstation is in a Windows operating environment.

KDC Configuration on Windows 2008 Example

The steps listed following exemplify how to configure a Windows domain controller to support SiteMinder Kerberos authentication.

1. Promote a Windows Server to a domain controller (named test.com in this example) using Windows dcpromo utility.
2. Raise the domain functional level:
   1. Open the Active Directory users and computers dialog from Administrative tools.
   2. Right-click the test.com drop-down on the left side of dialog.
   3. Click Raise domain functional level.
   4. Raise the domain functional level of Active directory.

      Important! This step is irreversible.

3. Create a user account (for example, testkrb). Provide a password for this account. Clear the option, User must change password at next logon. Add this account to the domain administrators group so that the user has permissions to login. The Windows workstation uses this account to log in to test.com.
4. Create a service account for the web server (for example, wasrvwin2k8sps). Create a password for this account. Clear the option, User must change password at next logon. Add this account to the domain administrators group so that the user has permissions to login. CA SiteMinder® SPS uses this account to log in to test.com.
5. Create a service account for the Policy Server (polsrvwinps). Provide a password for this account. Clear the option, User must change password at next logon. Add this account to the domain administrators group so that the user has permissions to login. The Policy Server host (winps) uses this account to log in to test.com.
6. Join the web server (win2k8sps) and the Policy Server (winps) hosts to the test.com domain using their service accounts created in Steps 4 and 5.
7. Associate the web server account (wasrvwin2k8sps) with a web server principal name (HTTP/win2k8sps.test.com@TEST.COM) and create a keytab file using the Ktpass utility. The syntax differs depending on whether the Policy Server is on Windows or on UNIX.

   Note: The Ktpass command tool utility is a Windows support tool. You can install it from MSDN download or an installation CD. Always verify the version of support tools. The default encryption type must always be RC4-HMAC. The encryption type can be confirmed by running ktpass /? at the command prompt.

   When the Policy Server is on Windows:

   ktpass -out c:\wasrvwin2k8sps.keytab -princ HTTP/win2k8sps.test.com@TEST.COM 
   -ptype KRB5_NT_PRINCIPAL -mapuser wasrvwin2k8sps -pass <<password>>
   
   Targeting domain controller: winkdc.Test.com
   Using legacy password setting method
   Successfully mapped HTTP/win2k8sps.test.com to wasrvwin2k8sps.
   Key created.
   Output keytab to c:\wasrvwin2k8sps.keytab:
   Keytab version: 0x502
   keysize 67 HTTP/win2k8sps.test.com@TEST.COM ptype 1 (KRB5_NT_PRINCIPAL) vno 2 etype 0x17 (RC4-HMAC) keylength 16 (0xfd77a26f1f5d61d1fafd67a2d88784c7)
   

   The password is the same as the one used for creating the service account for the web server.

   When the Policy Server is on UNIX:

   ktpass -out d:\sol10sunone_host.keytab -princ host/sol10sunone.test.com@TEST.COM -pass <<password>> -mapuser sol10sunone -crypto DES-CBC-MD5 +DesOnly -ptype KRB5_NT_PRINCIPAL -kvno 3
   
   Targeting domain controller: winkdc.test.com
   Successfully mapped host/sol10sunone.test.com to sol10sunone.
   Key created.
   Output keytab to d:\sol10sunone_host.keytab:
   Keytab version: 0x502
   keysize 52 host/sol10sunone.test.com@TEST ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0x3 (DES-CBC-MD5) keylength 8 (0xb5a87ab5070e7f4a)
   Account sol10sunone has been set for DES-only encryption.
   

8. Associate the Policy Server account (polsrvwinps) with a Policy Server principal name (smps/winps.test.com@TEST.COM) and create another keytab file destined for the Policy Server host (winps).

   When the Policy Server is on Windows:

   Ktpass -out c:\polsrvwinps.keytab -princ smps/winps.test.com@TEST.COM -ptype KRB5_NT_PRINCIPAL -mapuser polsrvwinps -pass <<password>>
   Targeting domain controller: winkdc.Test.com
   Using legacy password setting method
   Successfully mapped smps/winps.test.com to polsrvwinps.
   Key created.
   Output keytab to c:\polsrvwinps.keytab:
   Keytab version: 0x502
   keysize 72 smps/winps.test.com@TEST.COM ptype 1 (KRB5_NT_PRINCIPAL) vno 2 etype 0x17 (RC4-HMAC) keylength 16 (0xfd77a26f1f5d61d1fafd67a2d88784c7)
   

   The password is same as the one used for creating the service account for Policy Server.

   When the Policy Server is on UNIX:

   ktpass -out d:\sol10polsrv.keytab -princ host/sol10sunone.test.com@TEST.COM -pass <<password>> -mapuser sol10sunone -crypto DES-CBC-MD5 +DesOnly -ptype KRB5_NT_PRINCIPAL -kvno 3
   
   Targeting domain controller: winkdc.test.com
   Successfully mapped host/sol10sunone.test.com to sol10sunone.
   Key created.
   Output keytab to d:\sol10polserv.keytab:
   Keytab version: 0x502
   keysize 52 host/sol10sunone.test.com@TEST ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0x3 (DES-CBC-MD5) keylength 8 (0xb5a87ab5070e7f4a)
   Account sol10sunone has been set for DES-only encryption.
   

9. Specify that the web server and Policy Server service accounts are Trusted for Delegation as follows:
   1. Right-click the service account (polsrvwinps/wasrvwin2k8sps) properties.
   2. Select the Delegation tab.
   3. Select the second option, Trust this user for delegation to any service (Kerberos only)

      Or, select the third option, Trust this user for delegation to specified service. Select the Use Kerberos only option button, and add the corresponding service principal name.

The domain controller is ready for SiteMinder Kerberos authentication.

KDC Configuration on UNIX Example

The process listed following exemplifies how to configure a KDC Kerberos Realm on a UNIX host to support SiteMinder Kerberos authentication.

1. Install MIT Kerberos, if necessary.
2. Use the kdb5_util command to create the Kerberos database and an optional stash file. The stash file is used to authenticate KDC to itself automatically before starting the kadmind and krb5kdc daemons as part of the host auto-boot sequence.

   Both the stash file and the keytab file are potential point-of-entry for a break-in. If you install a stash file, it must be readable only by root, must not be backed up, and must exist only on KDC local disk. If you do not want a stash file, run the kdb5_util without the -s option.

   This example generates the following five database files in the directory specified in kdc.conf file:

   • Two Kerberos database files: principal.db and principal.ok
   • One Kerberos administrative database file: principal.kadm5
   • One administrative database lock file: principal.kadm5.lock
   • One stash file: .k5stash

     [root@rhasmit init.d]# kdb5_util create -r EXAMPLE.COM -s
     Initializing database '/var/kerberos/krb5kdc/principal' for realm 'EXAMPLE.COM',
     master key name 'K/M@EXAMPLE.COM'
     You will be prompted for the database Master Password.
     It is important that you NOT FORGET this password.
     Enter KDC database master key:
     Re-enter KDC database master key to verify:
     

3. Create a user principal (testkrb).
4. Create a user principal (for example, testwakrb), a host principal (host/win2k8sps.example.com@EXAMPLE.COM, and a service principal (HTTP/win2k8sps.example.com@EXAMPLE.COM) for the web server host. The password used for creating host account must be same as the password specified when using the ksetup utility on the web server host.
5. Create a user principal (testpskrb), host principal (host/winps.example.com@EXAMPLE.COM) and service principal (smps/winps.example.com@EXAMPLE.COM) for the Policy Server host. The password used for creating host account must be same as the password specified when using the ksetup utility on the Policy Server host.
6. Create a keytab file for the web server service principal as follows:

   ktadd -k /tmp/win2k8sps.keytab HTTP/win2k8sps.example.com
   

7. Create keytab for Policy Server service principal as follows:

   ktadd -k /tmp/winps.keytab smps/winps.example.com
   

The Kerberos Realm is configured for SiteMInder on a UNIX host.

Kerberos Configuration at the Policy Server on UNIX Example

The following procedure shows an example of how to configure a Policy Server on a UNIX host to support CA SiteMinder® Kerberos authentication.

Follow these steps:

1. Create a user, for example, sol10psuser, with the same password used for creating a service account for the Policy Server host (sol10ps) in Active Directory.
2. Add the host to the test.com domain and login to host with user sol10psuser.
3. Install and configure CA SiteMinder® Policy Server.
4. Install and configure policy store directory services.
5. Add a Host Configuration Object referencing the Solaris Policy Server.
6. Add an Agent Configuration Object and add the following three new parameters:

1. Create a user directory.
2. Create a user, for example, testkrb, in the user directory.
3. Configure a new Authentication Scheme using the CA SiteMinder® Admin UI:
   1. Create the scheme using the custom template.
   2. Specify the CA SiteMinder® Kerberos Authentication Scheme library.
   3. Select the parameter field and specify the following three semicolon-delimited values in the specified order:
      • Server name and target fields.
      • Policy Server principal name from the Windows 2003 Kerberos realm.
      • Mapping between the user principal and an LDAP search filter.

      Sample parameter field:

      http://sol10sunone.test.com/siteminderagent/Kerberos/creds.kcc;smps/sol10ps.test.com@TEST.COM;(uid=%{UID})
      

4. Configure a policy domain.
5. Add a realm to protect a resource using the Authentication Scheme.
6. Add Rules and Policies to allow access for the user, testkrb.
7. Configure a Kerberos configuration file (krb5.ini) and place krb5.ini in the /etc/krb5 system path.
   • Configure KDC for the Windows 2003 Kerberos realm (domain) to use the Windows 2003 domain controller.
   • Configure krb5.ini to use the Windows 2003 KDC keytab file containing the Policy Server principal credentials.

     See the following sample krb5.ini:

     [libdefaults]
      ticket_lifetime = 24000
      default_realm=TEST.COM
      default_tgs_enctypes = des-cbc-md5
      default_tkt_enctypes = des-cbc-md5
      default_keytab_name = FILE:/etc/krb5.keytab
      dns_lookup_realm = false
      dns_lookup_kdc = false
      forwardable = true
      proxiable = true
     [realms]
      TEST.COM = {
       kdc = winkdc.test.com:88
       admin_server = winkdc.test.com:749
       default_domain = test.com
      }
     [domain_realm]
      .test.com=TEST.COM
       test.com=TEST.COM
     

8. Use the ktutil utility to merge the keytab files (sol10ps_smps.keytab & sol10ps_host.keytab) containing the host principal and service principal names for the Policy Server host in the /etc/krb5.keytab file:

   ktutil: rkt sol10ps_host.keytab
   ktutil: wkt /etc/krb5.keytab
   ktutil: q
   ktutil: rkt sol10ps_smps.keytab
   ktutil: wkt /etc/krb5.keytab
   ktutil: q
   

9. Verify the created krb5.keytab as follows:

   klist -k
   Keytab name: FILE:/etc/krb5.keytab
   KVNO Principal
   ---- --------------------------------------------------------------------------
      3 host/sol10ps.test.com@TEST.COM
      3 smps/sol10ps.test.com@TEST.COM
   

10. Deploy the Windows 2003 KDC keytab file containing the host and Policy Server principal credentials to a secure location on the Policy Server.
11. Verify that the following environment variable is set before starting the Policy Server:

    KRB5_CONFIG=/etc/krb5/krb5.conf

The Policy Server on a UNIX host is configured for Kerberos authentication.

Kerberos Configuration at the Policy Server on Windows Example

The following procedure shows an example of how to configure a Policy Server on Windows to support CA SiteMinder® Kerberos authentication.

Note: If the Policy Server is installed on Windows and KDC is deployed on UNIX, be sure to perform additional required configuration on the Policy Server host using the Ksetup utility.

Follow these steps:

1. Install and configure the CA SiteMinder® Policy Server.
2. Install and configure policy store directory services.
3. Log in to the Policy Server host with the service account (for example, polsrvwinps) created in Active Directory on the Windows domain controller.
4. Add a Host Configuration Object referencing the Policy Server.
5. Create an Agent Configuration Object and add these three new parameters:

1. Create a user directory.
2. Create a user, for example, testkrb, in the user directory.
3. Configure a new Authentication Scheme using the CA SiteMinder® Admin UI:
   1. Create the scheme using the custom template.
   2. Specify the CA SiteMinder® Kerberos Authentication Scheme library.
   3. Select the parameter field and specify the following three semicolon-delimited values in the specified order:
      • Server name and target fields.
      • Policy Server principal name from the Windows 2003 Kerberos realm.
      • Mapping between the user principal and an LDAP search filter.

      Sample parameter field:

      http://win2k8sps.test.com/siteminderagent/Kerberos/creds.kcc;smps/winps.test.com@TES.COM;(uid=%{UID})
      

4. Configure a policy domain.
5. Add a realm to protect a resource using the Authentication Scheme.
6. Add Rules and Policies to allow access for the user, testkrb.
7. Configure a Kerberos configuration file (krb5.ini) and place krb5.ini in the Windows system root path:
   • Configure KDC for the Windows 2003 Kerberos realm (domain) to use the Windows 2003 domain controller.
   • Configure krb5.ini to use the Windows 2003 KDC keytab file containing the Policy Server principal credentials.

     See the following sample krb5.ini:

     [libdefaults]
     default_realm = TEST.COM
     default_keytab_name = C:\WINDOWS\krb5.keytab
     default_tkt_enctypes = rc4-hmac des-cbc-md5
     default_tgs_enctypes = rc4-hmac des-cbc-md5
     [realms]
     TEST.COM = {
     kdc = winkdc.test.com:88
     default_domain = test.com        
     }
     [domain_realm]
     .test.com = TEST.COM
     

8. Deploy the Windows KDC keytab file containing the Policy Server principal credentials to a secure location on the Policy Server.

The Policy Server on a Windows host is configured for Kerberos authentication.