Configure CA Access Gateway 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.
casso127
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.
CA Single Sign-On
, using the Windows Authentication scheme, secures resources by processing user credentials that are obtained by the Microsoft Integrated Windows Authentication infrastructure.
You can configure
one
of the following authentication schemes with
CA Access Gateway
:
  • Windows authentication scheme on Windows server
  • Kerberos authentication scheme on Windows and UNIX server
Use the following workflow to configure the authentication scheme:
Windows Authentication Scheme
  1. Verify the Prerequisites
  2. Configure Windows Authentication Scheme
  3. Enables Windows Authentication Scheme
  4. Configure the Web Browser to Support Automatic Login
Kerberos Authentication Scheme
  1. Configure Kerberos Key Distribution Center
  2. Configure the Policy Server
  3. Configure the Web Server
  4. Configure Windows Workstation
  5. Configure Kerberos Authentication Scheme
  6. Configure Kerberos External Realm on Windows
Contents
Windows Authentication Schemes
The Windows authentication scheme allows
CA Single Sign-On
 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.
Perform the following steps to configure 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 Access Gateway
to support IWA:
  1. Configure a Windows domain controller.
  2. Add
    CA Access Gateway
    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.
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.
  3. Click Create Authentication Scheme.
    Verify that the Create a new object of type Authentication Scheme is selected.
  4. Click OK
  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 Access Gateway
      , for example:
      server1.myorg.com
    • Target
      /siteminderagent/ntlm/smntlm.ntc
      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
CA Access Gateway
now supports Windows authentication scheme that is configured on the Policy Server. To let the
CA Access Gateway
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.
If you do not define or set the value of the WindowsNativeAuthentication ACO parameter, the
CA Access Gateway
does not support the Windows authentication.
Configure Web Browser to Support Automatic Login
Configure your browser to enable automatic login. You must first provide the login credentials to access the resource, the browser will store the login data and auto-fill the data for you on the subsequent login requests.
Refer to the documentation of your web browser for information on how to configure automatic login.
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.
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.
    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.
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.
For any service to use Kerberos protocol, ensure that you create the Service Principal Name (SPN) in the service/[email protected]_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/[email protected]
    3. Add the Policy Server principal name to the SmpsServicePrincipal parameter.
      Example: [email protected]
  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.
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 Web Agent with 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.
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:
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.
When you create or modify a Policy Server object, use ASCII characters. Object creation or modification with non-ASCII characters is not supported.
  1. Select Infrastructure, Authentication, Authentication Schemes.
  2. Click Create Authentication Scheme.
  3. Select Custom Template from the Authentication Scheme Type list.
    Custom Template settings appear.
  4. Enter
    smauthkerberos
    in the Library field.
  5. 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/[email protected];(uid=%{UID})
    LDAP Example 2:
    http:/win2k8sps.test.com/siteminderagent/Kerberos/creds.kcc;smps/[email protected];(uid=%{UID})
    AD Example 1:
    http://win2k8sps.test.com/siteminderagent/Kerberos/creds.kcc;smps/[email protected];(cn=%{UID})
    AD Example 2:
    http://win2k8sps.test.com/siteminderagent/Kerberos/creds.kcc;smps/[email protected];(cn=%{UID})
    ODBC Example 1:
    http://win2k8sps.test.com/siteminderagent/Kerberos/creds.kcc;smps/[email protected];%{UID}
    ODBC Example 2
    : http://win2k8sps.test.com/siteminderagent/Kerberos/creds.kcc;smps/[email protected];%{UID}
  6. 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
    The password used here is same as the one used while creating the host principal account in the MIT KDC.
  7. Restart the host. 
    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 [email protected] 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 Access Gateway
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. 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 Server Example
The steps listed following exemplify how to configure a Windows domain controller to support 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.
      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 Access Gateway
    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/[email protected]) and create a keytab file using the Ktpass utility. The syntax differs depending on whether the Policy Server is on Windows or on UNIX.
    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/[email protected] -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/[email protected] 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/[email protected] -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/[email protected] 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/[email protected]) 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/[email protected] -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/[email protected] 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/[email protected] -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/[email protected] 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 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 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
    [[email protected] init.d]# kdb5_util create -r EXAMPLE.COM - s Initializing database '/var/kerberos/krb5kdc/principal' for realm 'EXAMPLE.COM', master key name 'K/[email protected]' 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/[email protected], and a service principal (HTTP/[email protected]) 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/[email protected]) and service principal (smps/[email protected]) 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 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 Policy Server.
  4. Install and configure policy store directory services.
  5. Add a Host Configuration Object referencing the Policy Server.
  6. Add an Agent Configuration Object and add the following three new parameters:
    Parameter
    Value
    KCCExt
    .kcc
    HttpServicePrincipal
    Specify the web server principal name.
    Example:
    HTTP/win2k8sps.test.com@TEST.COM
    SmpsServicePrincipal
    Specify the Policy Server principal name.
    Example:
    [email protected]
  7. Create a user directory.
  8. Create a user, for example, testkrb, in the user directory.
  9. Configure a new Authentication Scheme using the
    CA Single Sign-On
    Admininistrative UI:
    1. Create the scheme using the custom template.
    2. Specify the 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/[email protected];(uid=%{UID})
  10. Configure a policy domain.
  11. Add a realm to protect a resource using the Authentication Scheme.
  12. Add Rules and Policies to allow access for the user, testkrb.
  13. 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
  14. 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
  15. Verify the created krb5.keytab as follows:
    klist -k Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---- -------------------------------------------------------------------------- 3 host/[email protected] 3 smps/[email protected]
  16. Deploy the Windows 2003 KDC keytab file containing the host and Policy Server principal credentials to a secure location on the Policy Server.
  17. 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 Kerberos authentication.
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 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:
    Parameter
    Value
    KCCExt
    .kcc
    HttpServicePrincipal
    Specifies the web server principal name.
    Example:
    HTTP/win2k8sps.test.com@TEST.COM
    SmpsServicePrincipal
    Specifies the Policy Server principal name.
    Example:
    [email protected]
  6. Create a user directory.
  7. Create a user, for example, testkrb, in the user directory.
  8. Configure a new Authentication Scheme using the Admininistrative UI:
    1. Create the scheme using the custom template.
    2. Specify the 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/[email protected];(uid=%{UID})
  9. Configure a policy domain.
  10. Add a realm to protect a resource using the Authentication Scheme.
  11. Add Rules and Policies to allow access for the user, testkrb.
  12. 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
  13. 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.