You can define multiple instances of a vendor-specific attribute for the same Agent type. When you define multiple instances of a vendor-specific attribute, you can send a different value to the NAS device for each instance of the attribute. For example, for a Cisco Agent, you could define the following vendor-specific attributes, all using the same identifier (26):
The settings that define the number of times an attribute can be used within a response are located on the Modify Agent Type Attribute pane of the Administrative UI.
To configure the attribute to be used multiple times, the Access Accept value must be set to Zero or Many.
The type of attribute that you define must match the vendor type of the Agent returning the response. For example, a vendor-specific Cisco attribute can only be returned by a Cisco Agent.
When the response is returned by the Agent, the packet structure of the response reflects the type of RADIUS Agent that sent the response. For example, the packet structure of a response returned by a Cisco Agent would include the vendor ID and the length of the string.
To define an attribute for an Agent type
The Modify Agent Type pane opens.
A list of Agent types that match the search criteria opens.
The Modify Agent Type: Name pane opens.
The Create Agent Type Attribute pane opens.
The Create Agent Type Attribute: Name pane opens.
The attribute identifier is defined in the RADIUS protocol specification. Although it is possible to overwrite the identifier of a Generic RADIUS attribute, you should generally retain the pre-defined Generic RADIUS attribute definitions, which match the RADIUS specification (RFC 2138).
Example: To create an attribute for the Callback-Id variable, type 20 in the Identifier field.
The attribute identifier is defined in the vendor documentation.
Example: To create an attribute for the Ascend-Callback attribute, type 246 in the Identifier field.
The attribute identifier is 26.
Example: To create an attribute for a Cisco Agent that enables the Agent to use TACACS+, type 26 in the Identifier field.
Note: For more information about attribute identifiers, see your RADIUS vendor documentation.
Attribute cannot be used in a response.
One instance or no instances of the attribute can be returned in the same response. If this value is selected, and you use the attribute in a response, the attribute will be removed from the Attribute list after you have used the attribute in a response.
Multiple instances or no instances of the attribute can be returned in the same response.
One instance of the attribute must be returned in a response. If this value is selected, and you use the attribute in a response, the attribute will be removed from the Attribute list after you have used the attribute in a response.
The fields on the RADIUS group box are:
Provides information used to determine whether or not a user is allowed access to a specific NAS. The Access Request packets also provide information for any special services requested for that user.
Provides specific configuration information necessary to begin delivery of service to the user.
Note: You must set the Access Accept value to Zero or One, Zero or Many, or One and Only One in order to use the attribute in a response.
Sends information if any value of the received Attributes is not acceptable. This code is often used for reply messages.
Sends information if the NAS device has been configured for challenge/response.
Describes the type of service being delivered and the user to whom it is being delivered.
Sends information if the Accounting Request was recorded successfully. A RADIUS Accounting-Response is not required to have any attributes in it.
The Modify Agent Type Attribute pane reopens, and the attribute name-value pair is added to the Values group box.
Note: To create multiple attribute name-value pairs, repeat steps 12 and 13. By mapping symbolic names to values, you only need to remember names.
The Modify Agent Type pane reopens, and the Agent type attribute is added to the Agent Type Attributes group box.
The Modify Agent Type task is submitted for processing.
Note: When the task is complete and you create a response for this Agent type, you can select the Agent type attribute that you just added to the Agent type from an attribute list.
You can modify attributes that you created and attributes that have been pre-defined for a RADIUS Agent. For example, you can modify the pre-defined Ascend-PPP-Address attribute for the Ascend Agent type.
Note: When you modify an existing attribute, the attribute is not updated dynamically in responses that already use the attribute. If an attribute is used in a response, you must recreate the response using the updated attribute.
All RADIUS Agent types have been pre-configured to use the generic RADIUS attributes, as defined in RFC 2138. These attributes are available to be used by each RADIUS Agent type.
Important! If you overwrite a generic attribute or define a new attribute in the Generic RADIUS Agent, the change is applied to all RADIUS Agents. For example, if you modify the Filter ID attribute in the Generic RADIUS Agent, the modification is also made to all of the other RADIUS Agent types, such as Cisco, Shiva, Livingston, Ascend, and Checkpoint.
To modify agent type attributes
The Modify Agent Type pane opens.
SiteMinder can be setup to provide authentication services in a variety of different RADIUS environments:
Before deploying SiteMinder in a RADIUS environment, note the following guidelines:
A homogeneous RADIUS environment is the most simple to protect. You can protect the RADIUS device using just one policy. This type of environment includes only one RADIUS device, such as a Cisco RAS, and one user directory, as shown in the following graphic:
Follow these steps:
You can authenticate RADIUS users using any user directory that is supported for the NT or UNIX platform you are using.
If the user directory contains information about user privileges, you can create responses using user attributes. When the user attributes are sent back to the RADIUS device, the attributes are used to configure the user session.
You can use the following directories:
The policy domain must identify one or more user directories that contain the names of the RADIUS users, the names of the Administrators who can modify the domain, and the realm that the RADIUS Agent is protecting.
You can use any of the following authentication schemes:
PAP is a PPP authentication protocol that provides a simple method for a host to establish its identity in a two-way handshake. Authentication takes place only upon initial link establishment and does not use encryption.
CHAP is also a secure PPP authentication protocol. CHAP provides a way to periodically verify the identity of a host using a three-way handshake and encryption. Authentication takes place upon initial link establishment. The RAS can repeat the authentication process any time after the connection takes place.
Note: For more information on creating an authentication scheme, see the Authentication Schemes chapter in this guide.
A more powerful and complex deployment of the Policy Server in a RADIUS environment is one that includes multiple realms administered by multiple NAS devices. In this scenario, the Policy Server can serve as the RADIUS authentication server for multiple RADIUS clients at once.
The advantage of using a heterogeneous configuration is that you save time by using the same RADIUS authentication server (that is, the Policy Server) for each RADIUS client.
An example of a heterogeneous configuration is illustrated in the following graphic:
In the network topology shown in the previous diagram, the Policy Server authenticates users of two NAS devices: a Cisco RAS and a Checkpoint Firewall. The Policy Server uses one user directory to authenticate the users.
Each NAS device has its own RADIUS Agent, which has been configured with a realm hint. When the Policy Server receives a request to authenticate the user, it uses the RADIUS Agent’s realm hint to determine the resource (domain) that the authenticated user can access.
The process of authentication when one user directory is used is as follows:
The RAS notifies the Policy Server that the session has begun and when the session ends.
When the Internet user attempts to dial into the Internet Service Provider via the Checkpoint Firewall, a similar process of authentication occurs. Using the realm hint, the RADIUS Agent defined for the Checkpoint Firewall determines which domain the Internet user has access to. If the user is authenticated, the Policy Server passes the Firewall the correct attributes to establish the session.
User information for both NAS devices is stored in the same user directory. Each time the Policy Server receives an authentication request, it authenticates the user using the same data directory.
This system configuration differs from the homogeneous environment; you must now create two Agents.
Within the policy domain there is one policy that includes rules and responses for the Cisco Agent and the Checkpoint Agent.
To setup SiteMinder in the heterogeneous, single directory environment described above, you must:
A diagram of this policy domain is shown in the following graphic:
For this environment, you must configure two RADIUS Agents:
The Policy Server can authenticate users using the same user directory for both NAS devices.
The policy domain must identify the user directory that contains the names of the RADIUS users, the names of the Administrators who can modify the domain, and the realm that the RADIUS Agent is protecting. A RADIUS environment that uses only one user directory requires only one policy domain.
The Policy Server can also be configured to authenticate users for multiple NAS devices when the user information for each device is located in separate user directories. The NAS devices can be of different vendor types.
There are several advantages to this configuration:
An example of a heterogeneous configuration that uses two user directories is illustrated in the following graphic:
Unlike the topology described in the previous section, this Policy Server uses two user directories to authenticate the users. User information for the Cisco RAS users is stored in User Directory A. User information for the Checkpoint firewall is stored in User Directory B. The Policy Server can authenticate users using both of these directories.
By dividing the configuration into two policy domains, the need for realm hints is eliminated. Each RADIUS Agent exists in a separate policy domain and is bound to only one realm.
The process of authentication when two user directories are used is as follows:
The RAS notifies the Policy Server that the session has begun and when the session ends.
When the Internet user attempts to dial into the Internet Service Provider by using the Checkpoint Firewall, this same process of authentication occurs. However, the Policy Server evaluates the Internet user’s authentication information against a different user directory.
To configure the heterogeneous environment described above, which includes two user directories, you must:
A diagram of these two policy domains is shown in the following graphic:
For this environment, you must configure two RADIUS Agents:
Each of the user directories containing RADIUS user information must be configured in the Policy Server. Each directory will be associated with a separate policy domain so that separate administrators can be defined for each policy domain.
One policy domain must be created for the Cisco RAS and one policy domain must be created for the Checkpoint firewall. When defining the policy domains, associate each domain with the appropriate user directory.
Creating a RADIUS Agent group enables you to manage multiple RADIUS Agents at once and eliminates the need to create and configure separate realms for each RADIUS Agent. Using one realm saves time because you can define the same session timeouts and the same authentication scheme for all RADIUS Agents simultaneously.
A group of RADIUS Agents could include Agents for different types of NAS devices. For instance, an Agent group could contain Agents for a Shiva LAN Rover RAS, a Checkpoint firewall, and a Cisco RAS. The Agent group containing all of these RADIUS Agents would be associated with a single realm, which defined the authentication scheme and session timeout requirements.
Agent groups are best suited for static environments that do not change often; Agent groups enable you to quickly configure SiteMinder to authenticate users of many NAS devices. If your environment is not static and frequently changes as new NAS devices are added or removed, you should probably avoid using Agent groups. Instead, it is usually easier to add and remove RADIUS Agents if they are not located in groups. If the Agents are separated and not grouped together, you can usually find specific Agents faster, and modify or remove policies more quickly.
When using RADIUS Agent groups, you typically setup a separate policy for each type of RADIUS Agent. By using separate policies for each type of RADIUS Agent, you can share the common elements of the policy domain, such as the realm and a rule, in each policy. Sharing these common elements saves time.
Unlike the rule and realm, the response in each policy is not shared. Each policy has its own response, which corresponds to the device type of the RADIUS Agent in the policy. The attributes in a response match the attributes provided by the Dictionary file of the NAS device. For example, a response for a Cisco RAS would need to provide attributes that the Cisco RAS could interpret using the Cisco Dictionary file.
Note: All of the NAS devices represented in a RADIUS Agent group must share the same user directory. If they do not share the same user directory, they cannot exist in the same policy domain and therefore, they cannot share the same generic realms or generic rules.
The following example depicts one RADIUS Agent group that contains both an Agent for a Cisco RAS and an Agent for a Shiva RAS. The Agent group is shared by both the Cisco policy and the Shiva policy. Both of these policies share the same generic rule to allow access and the same generic realm, which binds the Agent group to the same authentication scheme. Notice, however, that the responses for each policy are unique.
The procedure for setting up a RADIUS Agent Group is in Configure an Agent Group.
A RADIUS response group is a collection of responses defined for the same type of Agent, such as Generic RADIUS. When a rule fires, all of the RADIUS responses paired with it in the response group are triggered.
The responses must be of the same Agent type in order to use the same Dictionary file. For example, you could combine two Cisco responses in the same group or two Generic RADIUS responses in the same group. However, you could not group a Generic RADIUS and a Cisco response in the same group.
The advantage of using RADIUS response groups is that it enables you to configure a policy domain using fewer policies. Instead of creating a separate realm and a separate policy for each RADIUS Agent, you could group RADIUS Agents of the same type, create one generic rule for authentication, and then group the responses for the rule. This type of configuration is shown in the following diagram:
Response groups also make it easier to add RADIUS devices to the environment. For instance, in an environment such as the one shown in the previous figure, you could quickly add another Shiva RAS to the RADIUS Agent group and this new RAS would automatically be configured with the appropriate rule and responses.
Once you have configured the Policy Server to act as a RADIUS authentication server, you can test and troubleshoot the policies using the tools described in subsequent topics.
RADIUS logs track debugging and accounting information generated by the Policy Server. Use the RADIUS log file to track the following:
Logs are turned on and off using the Policy Server Management Console from the Debug tab.
The Policy Server time stamps the log file with the date and time it was created. For example, "log.txt" can be specified as the name of the file. When the Policy Server is restarted and the Policy Server creates the log file, the date and time are added to the name.
If you are appending logging information to the same file, the date on the file reflects the date and time it was created. The timestamp is only updated if the Policy Server is restarted.
This tool is used to read RADIUS log files generated by the Policy Server. It is useful for troubleshooting the Policy Server when used as a RADIUS authentication server. Options are provided to display individual RADIUS attributes that are exchanged between NAS and SiteMinder.
Smreadclog uses the following arguments to supply information required to read RADIUS log files:
Specifies the filename of the log file.
Specifies the filename of the output file.
Specifies the shared secret that can be used to decode RADIUS passwords.
Indicates that a hex dump of an entire RADIUS packet be displayed.
Indicates that RADIUS attributes should be displayed individually.
Indicates that RADIUS attributes should be displayed according to their definition in the policy store. This option displays actual attribute names as well as attribute values formatted based on their attribute type. Without this option, only the attribute name and value are displayed (as a hex string).
Enables you to record and replay RADIUS activity of the Policy Server service against your RADIUS server.
Specifies the port used for RADIUS authentication if that port is not the default port, 1645.
Specifies the port used for RADIUS accounting if that port is not the default port, 1646.
To use smreadclog
where <siteminder_installation> is the installed location of SiteMinder.
where <siteminder_installation> is the installed location of SiteMinder.
smreadclog -i<input-file> -o<output-file> -s<secret> -r -a -d -p<radius-server> -m<portnumber> -n<portnumber>
For example,
smreadclog -iradiuslog.txt -oradiuslog2.txt -ssecret -r -a -d -p123.123.12.12
The SiteMinder Test Tool simulates the behavior of a RADIUS authentication server. Using the Test Tool, you can test policies that authenticate RADIUS users and ensure that the response attributes you configured are returning the appropriate data.
The process of testing RADIUS policies includes the following steps:
To configure the Policy Server Management console
Important! If you are accessing this graphical user interface on Windows Server 2008, open the shortcut with Administrator permissions. Use Administrator permissions even if you are logged in to the system as an Administrator. For more information, see the release notes for your SiteMinder component.
You are now ready to test the RADIUS policies using the Test Tool.
To test RADIUS policies
Important! Before running a SiteMinder utility or executable on Windows Server 2008, open the command line window with administrator permissions. Open the command line window this way, even if your account has administrator privileges.
The policy is tested and the response attributes appear in the Attributes group box.
|
Copyright © 2012 CA.
All rights reserved.
|
|