Cisco Prime Access Registrar 9.1 User Guide

MaximumIncomingRequestRate

You can use the MaximumIncomingRequestRate property to limit incoming traffic in terms of “allowed requests per second”.

For example, if you set the MaximumIncomingRequestRate to n, then at any given second, only n requests are accepted for processing. In the next second, another n requests are accepted regardless of whether the requests accepted earlier are processed or not. This condition serves as a soft limit.

The MaximumIncomingRequestRate property by default is zero (disabled).

MaximumOutstandingRequests

You can use the MaximumOutstandingRequests property to limit incoming traffic in terms of “requests processed”.

For example, if you set the MaximumOutstandingRequests to n, n requests are accepted for processing. Further requests are accepted only after processing some of these requests and sending the replies back. This condition serves as a hard limit.

The MaximumOutstandingRequests property by default is zero (disabled).

Note You can enable either of these properties independent of the other.

Configuring the MaximumOutstandingRequests

To configure the MaximumIncomingRequestRate or MaximumOutstandingRequests property:

Step 1 Log into aregcmd.

Step 2 Change directory to /Radius/Advanced.

Step 3 Set the MaximumIncomingRequestRate or MaximumOutstandingRequests property to non-zero values.

set MaximumIncomingRequestRate n

or

set MaximumOutstandingRequests n

where n is any nonzero value.

Step 4 Save the configuration; enter:

save

Step 5 Reload the server; enter:

reload

Call Flow

This section describes the call flow of the Query-Notify feature.

1. The Prime Access Registrar server caches information from an from Accounting-Start.

This information is usually from a GGSN when a subscriber enters into the network.

2. When a WAP gateway receives a request to authenticate a subscriber, it queries the Prime Access Registrar server using an Access-Request packet to retrieve the cached information for that subscriber.

3. The Prime Access Registrar server responds with Access-Accept if an entry is found for the subscriber in its cache; otherwise the server returns an Access-Reject.

The Prime Access Registrar server sends an Access-Accept packet to the WAP gateway. The list of attributes sent in this Access-Accept will depends on radius-query service configuration.

Note You use aregcmd to configure the attributes for the Access-Accept packet in the AttributesToBeReturned subdirectory under a radius-query service type.

4. If the Prime Access Registrar server finds a cache entry for the subscriber and if the EnableNotifications property is set to TRUE, the Prime Access Registrar server stores the client IP address in the subscriber’s cache.

5. If the Prime Access Registrar server receives an Accounting-Interim-Update packet from the GGSN, it responds by sending an Accounting-Response packet then sends the Accounting-Interim-Update packets to all the queried clients of the WAP Gateways.

If the WAP gateway queried clients do not respond to the Accounting-Interim-Update packets, the Prime Access Registrar server times out and retries by notifying the WAP gateways again. If there is no response after all the retries, the proxy packet is deleted and no change is made to the session or the WAP gateway’s state in the Prime Access Registrar server. The StaleSessionTimeout property under /Radius/Advanced is not applicable for Accounting-Interim-Update packets.

6. When the subscriber logs out of the network, the Prime Access Registrar server receives an Accounting-Stop packet and responds by sending an Accounting-Response back to the client.

Before releasing the subscriber’s session, the Prime Access Registrar server looks for any client IP addresses in the subscriber’s cache. If it finds any, the Prime Access Registrar server sends Accounting-Stop packets to those clients with the attributes configured in the NotificationAttributeGroup subdirectory for each client.

The Prime Access Registrar server forms the attributes with those attributes in the session cache and from the Accounting-Stop packet. The Prime Access Registrar server uses the value configured for the Port property in the NotificationProperties subdirectory as the destination port for the Accounting-Stop packet and uses the client’s shared secret.

The Prime Access Registrar server then waits for Accounting-Response packets from each client to which it has sent Accounting-Stop packets. The Prime Access Registrar server waits for the time interval configured in the InitialTimeout property configured in the NotificationProperties subdirectory before sending another Accounting-Stop packet. If it does not receive an Accounting-Response packet, the Prime Access Registrar server sends additional Accounting-Stop packets until the number of attempts reaches the value configured in the MaxTries property in the NotificationProperties subdirectory.

7. When the Prime Access Registrar server receives an Accounting-Response packet from each client, the server releases the subscriber session.

If the Prime Access Registrar server does not receive Accounting-Response packets from all clients after the configured time and attempts, the server maintains the subscriber session for the time interval configured in the StaleSessionTimeout property in /Radius/Advanced then releases the subscriber session.

The Prime Access Registrar server maintains the subscriber session to address the quarantine IP address requirement. The Prime Access Registrar server must quarantine IP addresses if a WAP gateway does not respond to Accounting-Stop sent by the Prime Access Registrar server. The length of time an IP address is quarantined depends on the value of the InitialTimeOut property under the NotificationProperties subdirectory of /Radius/Clients/wap_gateway.

8. If the StaleSessionTimeout property is TRUE for a subscriber session, the Prime Access Registrar server rejects any query requests from clients for this session cache. After the StaleSessionTimeout expires, the Prime Access Registrar server will again send Accounting-Stop to all the clients listed in the session and proceeds to delete this subscriber session regardless of the status of the Accounting-Stop.

Configuration Examples

Note In addition to the following configuration, the StaleSessionTimeout property must be set in /Radius/Advanced. This property has a default value of 1 hour.

The following shows an example configuration for a Query-Notify client:

The following shows an example configuration for a Query-Notify AttributeGroup:

Memory and Performance Impact

Using the Query-Notify feature will have the following effects:

• There will be a memory impact because the Prime Access Registrar server caches IP addresses of clients queried in the session record.
• There will be an impact on performance because the Prime Access Registrar server has to persist the cached IP address information before responding to radius-query requests.

Call Flow

The following is the WPS process and Wireless Internet Service Provider (WISP) packet sequence for a new wireless client login at a Wi-Fi hotspot location:

1. The client discovers the WISP network at a Wi-Fi hotspot.

2. The client authenticates as guest (with null username and credentials) to the Prime Access Registrar server.

3. The client is provisioned and a new account is created.

4. The client is authenticated using the new account credentials and accesses the Internet.

The Prime Access Registrar server performs the following functions during WPS:

1. Detects the guest subscriber login from the null username and null credentials during PEAPv0 (MS-PEAP) authentication.

2. Grants a successful login and returns a sign-up URL of the provisioning server as a PEAP-Type-Length-Value (TLV) in the next Access-Challenge Packet.

The following is an example value for the URL PEAP-TLV:

http://www.example.com/provisioning/master.xml#sign up

W here #sign up is the parameter for this action and is a required element of the value.

The sign-up URL value is passed when the user authenticates as guest. The sign-up URL is a fragment within the Master URL. You can also configure other fragments to be returned in the Master URL. See Master URL Fragments for more information about the different fragments.

3. Sends a VLAN-ID or IP filter (or both) in the final Access-Accept packet to restrict the guest user’s accessibility to only the Provisioning server.

4. Authenticates using the user configuration in the user database after the client is provisioned and a new account is created.

Example Configuration

The following shows an example configuration for the WPS feature:

When you set the EnableWPS property to TRUE, you must provide values for the properties MasterURL and WPSGuestUserProfile. See Environment Variables for more information.

Environment Variables

The following two environment variables are used to support WPS:

• Send-PEAP-URI-TLV
• Master-URL-Fragment

Send-PEAP-URI-TLV

Send-PEAP-URI-TLV property is a Boolean value used by the authenticating user service to make the PEAP-V0 service include the URI PEAP-TLV in the protected success message. Under different circumstances Prime Access Registrar might send back different fragments within the MasterURL to the client, as described above.

The conditions under which this has to be sent is best known to the user authentication service (the service that is specified within the eap-mschapv2 service, which in turn is the tunnel service for PEAP-V0 service). So when it decides that it needs to send back the URL it can set this variable to TRUE. The default value for this is FALSE.

Master-URL-Fragment

The Prime Access Registrar authenticating user service uses Master-URL-Fragment to set the fragment within the Master URL that needs to be sent back. The Prime Access Registrar user authentication service sets the fragment to different values under different circumstances. While the Send-PEAP-URL-TLV indicates whether to send the URL or not, Master-URL-Fragment is used to intimate which fragment within the URL needs to be sent. If this variable is not set and if it is required to send the URL, ‘#signup’ will be sent by default.

Master URL Fragments

The following sections describe the different fragments the RADIUS server might send to the AP in the Master URL:

• Sign up
• Renewal
• Password change
• Force update

Sign up

This value is passed when the user authenticates as guest. The following is an example value for the URL PEAP-TLV:

http://www.example.com/provisioning/master.xml#sign up

where #sign up is the parameter for this action and a required element of the value.

Renewal

This value is passed when the user’s account is expired and needs renewal before network access can be granted. The following is an example value for the URL PEAP-TLV:

http://www.example.com/provisioning/master.xml#renewal

where #renewal is the parameter for this action and a required element of the value.

Password change

This value is passed when the user is required to change the account password. An example value for the URL PEAP-TLV is:

http://www.example.com/provisioning/master.xml#passwordchange

where #passwordchange is the parameter for this action and a required element of the value.

Force update

This value is passed when the WISP requires the Wireless Provisioning Services on the client to download an updated XML master file. This method of updating the XML master file on the client should be used only to correct errors; otherwise, the TTL expiry time in the XML master file is used to provide background updates. The following is an example value for the URL PEAP-TLV:

http://www.example.com/provisioning/master.xml#forceupdate

where #forceupdate is the parameter for this action and a required element of the value.

Unsupported Features

The following features are part of the Microsoft WPS functionality, but are not supported in the Prime Access Registrar:

• Account Expiration and Renewal
• Password Changing and Force Update

Account Expiration and Renewal

When the user creates an account and logs in with that account, the RADIUS server authenticates and authorizes the request and sends back an Access-Accept with a Session-Timeout attribute. The Access Point (AP) then forces the wireless client to reauthenticate for every timeout value. When there is one timeout duration left in the user account, the RADIUS server needs to send back a renewal URL (a URL fragment within the master URL) to the client for the user to renew the account.

Prime Access Registrar does not support this feature because the interface the Prime Access Registrar server has with the CiscoSecure Remote Agent does not have provisions to get the expiration information of user account. However, this release does provide an environment variable to copy the URL fragment and to control whether or not to send the URL using another environment variable. This can be used to send the renewal URL. There are some limitations, however.

Password Changing and Force Update

The Password Changing option is passed when the user is required to change the account password. Force Update option is passed when the WISP requires the Wireless Provisioning Services on the client to download an updated XML master file.

These functions are not possible in this release for the same reason mentioned above, the loose coupling between Prime Access Registrar and the CiscoSecure Remote Agent. Additionally, there is no known use case for this. As mentioned above, you can use the newly added environment variables to trigger these options.

Configuration Example - AccountingGroupService

To configure an accounting Group Service to deliver accounting requests to multiple Remote Servers:

Step 1 The first task is to set up the subservices which are to be part of the AccountingGroupService. Since subservices are merely configured Services which have been included in a service group, you need only define two new Services.

For this example, we will define two new radius Services called OurAccountingService and TheirAccountingService. A provider might want to maintain duplicate accounting logs in parallel with their bulk customer's accounting logs.

Step 2 Change directory to /radius/services. At the command line, enter the following:

cd /radius/services

Step 3 At the command line, enter the following:

add OurAccountingService

add TheirAccountingService

The configuration of these Services is very similar to standalone Radius accounting service. Step-by-step configuration instructions are not provided, but the complete configuration is shown below:

The next step is to create the new AccountingGroupService. The purpose of this Service is to process Accounting requests through both OurAccountingService and TheirAccountingService.

Step 4 At the command line, enter the following:

add AccountingGroupService

cd AccountingGroupService

set type group

Step 5 Set the ResultRule to AND to ensure that both services process the accounting request successfully.

set ResultRule AND

ls

set IncomingScript AcctGroupSvcInScript

set OutgoingScript AcctGroupSvcOutScript

Add OurAccountingService and TheirAccountingService as subservices of the Group Service.

Step 6 At the command line, enter the following:

cd GroupServices

set 1 OurAccountingService

Set 2 TheirAccountingService

ls

This completes the setup of the AccountingGroupService. To use this Service simply set it as the DefaultAccountingService and/or configure a policy/rule set which will select this Service. Essentially, this can be used in the same manner as any other standalone service.

Summary of Events

The following describes the flow of what happens when a client sends an accounting request which is processed by the AccountingGroupService:

1. ActGroupSvcInScript is executed.

2. OurAccountingService is called.

3. OurAccountingService's Incoming Script, OurAccountingInScript is called.

4. The request is sent to the Remote Server OurPrimaryServer and/or OurSecondaryServer, if necessary.

5. If a response is not received, because we used the AND ResultRule, the request failed and no response is sent to the client and the request is dropped. If a response is received, then the process continues.

6. OurAccountingService's Outgoing Script, OurAccountingOutScript is called.

7. TheirAccountingService is called.

8. TheirAccountingService's Incoming Script, TheirAccountingInScript is called.

9. The request is sent to the Remote Server TheirPrimaryServer and/or TheirSecondaryServer, if necessary.

10. If a response is not received, because we used the AND ResultRule, the request failed and no response is sent to the client and the request is dropped. If a response is received, then the process continues.

11. TheirAccountingService's Outgoing Script, TheirAccountingOutScript is called.

12. AcctGroupSvcOutScript is executed.

13. Standard processing continues.

Configuration Example 2 - AuthenticationGroupService

To configure a Group Service for the purposes of providing alternate Remote Servers for a single authentication:

Note If Service A rejects the request, try Service B.

Step 1 The first task is to set up the subservices which are to be part of the AuthenticationGroupService. Since subservices are merely configured Services which have been included in a service group, we will simply define two new Services. For simplicity, we will define two new radius Services called AuthenticationServiceA and AuthenticationServiceB.

Step 2 At the command line, enter the following:

cd /radius/services

[ //localhost/Radius/Services ]

Entries 1 to 2 from 2 total entries

Current filter: <all>

local-file/

local-users/

add AuthenticationServiceA

add AuthenticationServiceB

Step 3 The configuration of these Services is very similar to standalone Radius authentication service. Step-by-step configuration instructions are not provided, but the complete configuration is shown below:

[ //localhost/Radius/Services/AuthenticationServiceA ]

Name = AuthentictionServiceA

Description =

Type = radius

IncomingScript = AuthAInScript

OutgoingScript = AuthAOutScript

OutagePolicy = RejectAll

OutageScript = AuthAOutageScript

MultipleServersPolicy = Failover

RemoteServers/

1. PrimaryServerA

2. SecondaryServerA

[ //localhost/Radius/Services/AuthenticationServiceB ]

Name = AuthentictionServiceB

Description =

Type = radius

IncomingScript = AuthBInScript

OutgoingScript = AuthBOutScript

OutagePolicy = RejectAll

OutageScript = AuthBOutageScript

MultipleServersPolicy = Failover

RemoteServers/

1. PrimaryServerB

2. SecondaryServerB

The next step is to create the new "AuthenticationGroupService". The purpose of this Service is to process authentication requests through both AuthenticationServiceA and AuthenticationServiceB if AuthenticationServiceA rejects the request.

Step 4 At the command line, enter the following:

add AuthenticationGroupService

Added AuthenticationGroupService

cd AuthenticationGroupService

[ //localhost/Radius/Services/AuthenticationGroupService ]

Name = AuthenticationGroupService

Description =

Type =

IncomingScript =

OutgoingScript =

set type group

Set Type group


Next set the ResultRule to OR because we want to ensure that if the first subservice rejects the request, we then try the second subservice. If the second subservice rejects the request, then the response to the client is a reject.

Step 5 At the command line, enter the following:

set ResultRule OR

Set ResultRule OR


Set IncomingScript AuthGroupSvcInScript

Set OutgoingScript AuthGroupSvcOutScript


Set IncomingScript AuthGroupSvcInScript

Set OutgoingScript AuthGroupSvcOutScript

ls

[ //localhost/Radius/Services/AuthenticationGroupService ]

Name = AuthenticationGroupService

Description =

Type = group

IncomingScript = AuthGroupSvcInScript

OutgoingScript = AuthGroupSvcOutScript

ResultRule = OR

GroupServices/

Now we must add the services we created "AuthenticationServiceA" and "AuthenticationServiceB" as subservices of the Group Service.

Step 6 At the command line, enter the following:

cd GroupServices

[ //localhost/Radius/Services/AuthenticationGroupService/GroupServices ]


set 1 AuthenticationServiceA

Set 1 AuthenticationServiceA


Set 2 AuthenticationServiceB

Set 2 AuthenticationServiceB


ls

[ //localhost/Radius/Services/AuthenticationGroupService ]

Name = AuthenticationGroupService

Description =

Type = group

IncomingScript = AuthGroupSvcInScript

OutgoingScript = AuthGroupSvcOutScript

ResultRule = OR

GroupServices/

1. AuthenticationServiceA

2. AuthenticationServiceB

This completes the setup of the AuthenticationGroupService. To use this Service simply set it as the DefaultAuthenticationService and/or configure a policy/rule set which will select this Service. Essentially, this can be used in the same manner as any other standalone Service.

Summary of Events

The following describes the flow of what happens when a client sends an Authentication request which is processed by the AuthenticationGroupService:

1. AuthGroupSvcInScript is executed.

2. AuthenticationServiceA is called.

3. AuthenticationServiceA's Incoming Script, AuthAInScript is called.

4. If the response is a reject or the request is dropped (due to an Outage Policy):

a. AuthenticationServiceA's Outgoing Script, AuthAOutScript is called.

b. Processing continues with the next service.

5. If the response is an Accept:

a. AuthenticationServiceA's Outgoing Script, AuthAOutScript is called.

b. Skip to step 9.

6. AuthenticationServiceB is called.

7. AuthenticationServiceB's Incoming Script, AuthBInScript is called.

8. Since this is the last subservice in our Group Service:

a. AuthenticationServiceB's Outgoing Script, AuthBOutScript is called.

b. Regardless of whether the request is Accepted or Rejected, processing will continue at step 9.

9. AuthGroupSvcOutScript is executed.

10. Standard processing continues.

Remote LDAP Server Password Encryption

Apart from the two values, none and crypt, of the PasswordEncryptionStyle property on a Remote LDAP Server, SHA-1 supports adds three additional values for the PasswordEncryptionStyle property. Table 9-2 lists the valid values for this property and describes the corresponding behavior.

Dynamic Password Encryption

When using the dynamic setting for the PasswordEncryptionStyle property on a Remote LDAP Server, the Prime Access Registrar server looks for the prefixes listed in Table 9-3 to determine if encryption or a hash algorithm should be used during password comparison.

Note Password prefixes are not case-sensitive.

The default value for the PasswordEncryptionStyle property on a Remote LDAP Server is dynamic.

Note Using the dynamic setting for the PasswordEncryptionStyle property will require a bit more processing for each password comparison. When using dynamic, the Prime Access Registrar server must examine each password for a known prefix. This should have no visible impact on performance.

Logs

Turn on trace to level 4 to indicate (via the trace log) which password comparison method is being used.

Object Properties with Dynamic Support

The following object properties support dynamic values:

Radius

DefaultAuthenticationService

DefaultAuthorizationService

DefaultAccountingService

DefaultSessionManager

IncomingScript

OutgoingScript

Note Do not use the following environment variables:
Accounting-Service for the /Radius/DefaultAccountingService, Authentication-Service for the /Radius/DefaultAuthenticationService, or Authorization-Service for the /Radius/DefaultAuthorizationService
User-Profile for the BaseProfile, User-Group for the Group, User-Authorization for the AuthorizationScript, Session-Manager for the DefaultSessionManager, or Session-Service for the DefaultSessionService.

/Radius/Clients

client1/

IncomingScript

OutgoingScript

/Radius/Userlist/Default

user1/

Group

BaseProfile

AuthenticationScript

AuthorizationScript

/Radius/UserGroup

Group1/

BaseProfile

AuthenticationScript

AuthorizationScript

/Radius/Vendor

Vendor1/

IncomingScript

OutgoingScript

/Radius/Service

Service1/

IncomingScript

OutgoingScript

OutageScript

OutagePolicy

/Radius/RemoteServers

remoteserver1/

IncomingScript

OutgoingScript

Remoteldapserver1/

Searchpath

Filter

Note To differentiate the properties that support dynamic attributes, we place a tilde (~) after each property, as in IncomingScript~. However, when the Prime Access Registrar administrator is required to set values for those properties, continue to use the original property name, such as set IncomingScript ${e|realm}{Test}. The tilde is only for visual effect, and including the tilde will generate an error (“310 command Failed.”)

Dynamic Attribute Format

The format of the dynamic attribute is:

${eqp|attribute-name}{default-name}

where e stands for environment dictionary, q stands for request dictionary, and p stands for response dictionary. You can use e, q, and p in any order. The attribute name is the name for the attribute from environment dictionary, request dictionary, or response dictionary.

For example,

The default Authentication Service is determined at run time. Prime Access Registrar first checks to see if there is one value of realm in the environment dictionary. If there is, it becomes the value of DefaultAuthenticationService. If there is not, check the value of realm in the request dictionary. If there is one value, it becomes the value of DefaultAuthenticationService. Otherwise, local-users is the DefaultAuthenticationService. If we do not set local-users as the default value, the DefaultAuthenticationService is null. The same concept applies to all other attribute properties.

The validation for the dynamic values of the object property will only validate the default value. In the above example, Prime Access Registrar will do validation to check whether local-users is one of services defined in the service subdirectory.

Note When setting specific property values, do not use the tilde (~) in the property name. Doing so generates a 310 Command Failed error.

Configuration

1. Configure the tag attributes as untagged attributes under the /Radius/Advanced/Attribute Dictionary directory (for example, Tunnel-Type).

2. Attach the “ _tag ” tag to these attributes when configuring the attributes under all of the other directories as tagged attributes (for example, Tunnel-Type_tag10 under the /Radius/Profiles/test directory). Without the tag number, the default value is ( _tag = _tag0).

Example

Notes

1. “ _tag ” is reserved for the tunneling attributes. No other attributes should include this suffix.

2. The tag number value can range from 0 through 31.

Validation

The Prime Access Registrar server checks whether the tag attributes are defined under the /Radius/Advanced/Attribute Dictionary directory. The server also checks whether the tag number falls within the range (0-31).

Using User-Name/User-Password for Each Cisco 6400 Device

This approach assumes that for every 6400 NAS, a device-name/device-password is created for each. Following are the required changes:

For each NAS in Prime Access Registrar:

When the 6400 sends out the device authentication packet, it might have different User-Name / User-Password attributes for each 6400 NAS. When Prime Access Registrar receives the packet, it tries to obtain the Device-Name / Device-Password attributes from the NAS entry in the Prime Access Registrar configuration database. When the User-Name / User-Password in the packet match the configured Device-Name / Device-Password attribute values, Prime Access Registrar assumes that it must get the device. The next step is to replace the User-Name attribute with the concatenated <module> / <slot> / <port> string. From this point, the packet is treated as a regular packet.

Note A user record with the name of the concatenated string must be created.

Format of the New User-Name Attribute

After the device is identified, the User-Name attribute is replaced with the new value. This new value is the concatenation of 6400 <module> / <slot> / <port> information from the NAS-Port attribute and the packet is treated as a regular user authentication from this point on.

Note This format only supports NAS Port Format D. See Cisco IOS documentation for more information about NAS port formats.

The format of the new User-Name attribute is the printf of “%s-%d-%d-%d-%d-%d” for the following values:

NAS-IP—in dot format of the NAS-Ip-Address attribute. For example, 10.10.10.10.

slot—apply mask 0xF0000000 on NAS-Port attribute and shift right 28 bits. For example, NAS-Port is 0x10000000, the slot value is 1.

module—apply mask 0x08000000 on NAS-Port attribute and shift right 27 bits. For example, NAS-Port is 0x08000000, the module value is 1.

port—apply mask 0x07000000 on NAS-Port attribute and shift right 24 bits. For example, NAS-Port is 0x06000000, the port value is 6.

VPI—apply mask 0x00FF0000 on NAS-Port attribute and shift right 16 bits. For example, NAS-Port is 0x00110000, the VPI value is 3.

VCI—apply mask 0x0000FFFF on NAS-Port attribute. For example, NAS-Port is 0x00001001, the VCI value is 9.

User-Profile

This attribute is of type string with the format:

<Value1> :: <Value2> …

The User-Profile attribute is intended to hold a list of profile names. <Value1> and <Value2> represent the names of the profiles. They are separated by the “::” character, therefore, the “::” can not be part of the profile name. The order of values in the string has significance, as the profiles are evaluated from left to right. In this example, profile <Value2> is applied after profile <Value1>.

Assume the user record has a field called UserProfile that holds the name of the profile that applies to this user. This field is mapped to the environment attribute User-Profile. Following is how the mapping is done with aregcmd :

After Prime Access Registrar authenticates the user, it checks whether User-Profile exists in the environment dictionary. If it finds User-Profile, for each value in User-Profile, Prime Access Registrar looks up the profile object defined in the configuration database and adds all of the attributes in the profile object to the response dictionary. If any attribute is included in more than one profile, the newly applied profile overrides the attribute in the previous profile.

User-Group

You can use the User-Group environment variable to apply the user profile as well. In Prime Access Registrar, a user can belong to a user group, and that user group can have a pointer to a user profile. When Prime Access Registrar finds that a packet has User-Group set, it obtains the value of the User-Profile within the user group, and if the User-Profile exists, it applies the attributes defined in the user profile to that user.

Note that in Prime Access Registrar, every user can also directly have a pointer to a user profile. Prime Access Registrar applies profiles in the following order:

1. If the user profile defined in the user group exists, apply it.

2. If the user profile defined in the user record exists, apply it.

The profile in User-Group is more generic than in User-Profile. Therefore, Prime Access Registrar applies the profile from generic to more specific.

Example User-Profile and User-Group Attributes in Directory User Record

You can use an existing user attribute in the user record to store profile info. When this is a new attribute, we suggest you create a new auxiliary class AR_UserRecord for whichever user class is used. AR_User_Profile and AR_User_Group are two optional members in this class. They are of type string. The mapping is as follows:

Running arbug

To run the arbug script, change directory to /cisco-ar/bin and enter the following:

./arbug

The following is a typical sequence.

Files Generated

The arbug script generates five files that are compressed into a tarball. Table 9-7 provides a summary of the information found in each of the files.

Configuring Check Items

You use aregcmd to configure check item attributes.

Configuring User Check Items

To configure UserList check item attributes:

Step 1 Log into the Prime Access Registrar server, and use aregcmd to navigate to //localhost/Radius/UserLists/default/bob.

Step 2 Change directory to CheckItems.

cd CheckItems

Step 3 Use set to add any attributes to be used as check items.

set calling-Station-Id 4085551212

save

Configuring Usergroup Check Items

To configure UserGroups check item attributes:

Step 1 Log into the Prime Access Registrar server, and use aregcmd to navigate to //localhost/Radius/UserGroups/Default.

cd /Radius/UserGroups/Default

Step 2 Change directory to CheckItems.

cd CheckItems

Step 3 Use set to add any attributes to be used as check items.

set NAS-IP-Address 10.10.10.10

save

Configuring Packet of Disconnect

This section describes how to configure the POD feature in the following:

• Configuring the Client Object
• Configuring a Resource Manager for POD

Configuring the Client Object

You should enable POD for each client object that might want to send disconnect requests to those clients. You enable POD in a client object using the EnableDynamicAuthorization property. This property is set to FALSE by default when you create a client object. The following example shows the default configuration for a new client object, NAS1.

If the Prime Access Registrar server might send a POD to this client, set the EnableDynamicAuthorization property to TRUE. When you set this property to TRUE, the Prime Access Registrar server creates a DynamicAuthorizationServer subdirectory under the client object. The following example shows a newly created DynamicAuthorizationServer subdirectory:

The default port is 3799. You can change the port, if desired.

The property DynamicAuthSharedSecret is initially set to the same as value as the client's SharedSecret property when you set EnableDynamicAuthorization to TRUE. You can chose to configure a different secret for POD in this subdirectory.

The InitialTimeout property represents the number of milliseconds used as a timeout for the first attempt to send a POD packet to a remote server. For each successive retry on the same packet, the previous timeout value used is doubled. You must specify a number greater than zero, and the default value is 5000 (or 5 seconds).

The MaxTries property represents the number of times to send a proxy request to a remote server before deciding the server is offline. You must specify a number greater than zero, and the default is 3.

The PODAttributeGroup property points to a group of attributes to be included in a disconnect-request packet sent to this client.

You can create and configure the PODAttributeGroup in the /Radius/Advanced/AttributeGroups/ directory. The default group contains commonly used POD attributes NAS-Port and Acct-Session-Id.

The COAAttributeGroup property is used with the Change of Authorization (CoA) feature, also known as hot-lining.

Configuring a Resource Manager for POD

Prime Access Registrar provides a resource manager type called session-cache. When you set a resource manager to session-cache, the resource manager’s configuration contains a subdirectory called AttributesToBeCached. The following is an example Resource Manager set to type session-cache:

The attributes you configure under the AttributesToBeCached directory are cached in the session record during session management. The cached attributes are then sent in the disconnect-request for this session.

The OverwriteAttributes property indicates whether to overwrite the existing attributes if there are any in the session record. Since this resource manager can be invoked during Access-Request as well as Accounting-Start processing, the OverwriteAttributes can be used to control if the attributes cached during Access-Request processing can be overwritten with the attributes available during Accounting-Start processing.

The following is an example of a typical session-cache resource manager:

The attributes used in the example can be added as an indexed list using add or set commands (in any order).

Proxying POD Requests from External Servers

Prime Access Registrar can also proxy the disconnect requests received from external servers. To make Prime Access Registrar listen for external POD requests, the ListenForDynamicAuthorizationRequests property under /Radius/Advanced should be set to TRUE. The default value for this is FALSE. The default POD listening port is 3799. However this can be changed by configuring a new port of type pod under /Radius/Advanced/Ports and setting the new port number accordingly.

For security reasons, the source of a POD request should be configured as a remote server in Prime Access Registrar and the remote server should be configured to accept PODs. Set the property AcceptDynamicAuthorizationRequests to TRUE to do this. The default for this is FALSE. POD requests from unauthorized sources are silently discarded.

CLI Options for POD

Prime Access Registrar has options for the query-sessions and release-sessions CLI commands that enable querying or releasing sessions based on the session’s age. Another option enables querying or releasing sessions based on any valid RADIUS attribute available in the user's session record. This section contains the following topics:

• query-sessions
• release-sessions

query-sessions

The syntax for using query-sessions with-Age option is the following:

query-sessions <path> with-Age <value>

Where <path> is the path to the server, session-manager or resource manager and <value> is the minimum age of the session specified in minutes or hours with options M, Minutes, H or Hours. This command returns all sessions that are older than the given age value.

The syntax for using query-sessions with-Attribute option is the following:

query-sessions <path> with-Attribute <name> <value>

Where <name> is the RADIUS attribute name and <value> is the value of the attribute to be matched. This command returns the sessions where a session record contains and matches the attribute value specified in <value> field.

release-sessions

The syntax for using release-sessions with-Age option is:

release-sessions <path> with-Age <value>

Where, <path> is the path to the server, session-manager or resource manager and <value> is the minimum age of the session specified in minutes or hours with options M for Minutes, H for Hours. This command returns all sessions that are older than the given age value.

The syntax for using release-sessions with-Attribute option is:

release-sessions <path> with-Attribute <name> <value>

Where, <name> is the RADIUS attribute name and <value> is the value of the attribute to be matched. This command returns the sessions where a session record contains and matches the attribute value specified in <value> field.

A new option is also available for release-sessions command to enable an administrator to trigger sending a POD for a user after the session is released.

release-sessions <path> with-<type> <value> [send-pod]

Where, <path> is the path to the server, Session Manager, or Resource Manager and <type> is one of the following: NAS, User, IP-Address ID, or Age. The release-sessions command with an optional [send-pod] at the end results in Prime Access Registrar sending a POD request. The PoD requests are directed to port number configured in /radius/clients/<client name>/DynamicAuthorizationServer/port. By default it is set to 3799. To configure udp xxx, set the port value as:

/radius/clients/<client name>/DynamicAuthorizationServer/port = xxx

Configuring the Client Object

You should enable CoA for each client object that might want to send CoA requests to those clients. You enable CoA in a client object using the EnableDynamicAuthorization property. This property is set to FALSE by default when you create a client object. The following example shows the default configuration for a new client object, NAS1.

If the Prime Access Registrar server might send a CoA request to this client, set the EnableDynamicAuthorization property to TRUE. When you set this property to TRUE, the Prime Access Registrar server creates a DynamicAuthorizationServer subdirectory under the client object. The following example shows a newly created DynamicAuthorizationServer subdirectory:

The default port is 3799. You can change the port, if desired.

The property DynamicAuthSharedSecret is initially set to the same as value as the client's SharedSecret property when you set EnableDynamicAuthorization to TRUE. You can chose to configure a different secret for CoA in this subdirectory.

The InitialTimeout property represents the number of milliseconds used as a timeout for the first attempt to send a CoA packet to a remote server. For each successive retry on the same packet, the previous timeout value used is doubled. You must specify a number greater than zero, and the default value is 5000 (or 5 seconds).

The MaxTries property represents the number of times to send a proxy request to a remote server before deciding the server is offline. You must specify a number greater than zero, and the default is 3.

The COAAttributeGroup property points to a group of attributes to be included in a CoA request packet sent to this client.

You can create and configure the COAAttributeGroup in the /Radius/Advanced/AttributeGroups/ directory. The default group is not set to any value by default. When an attribute group is configured, the Prime Access Registrar server includes the attributes in this group in a CoA request. The values for these attributes are fetched from the user’s session record. A sample CLI is provided below:

Sample profile:

The CoA attribute group configuration can be used with a session-cache Resource Manager. For example, any new attributes that are to be sent in a CoA request can be configured for caching by the session-cache Resource Manager so they will be available in the session record when it is to be sent in the CoA request. A sample CLI is provided below:

The CoA request might also contain AV pairs from the optional profile name in the query-session CLI command used to send the CoA request. In a 3GPP2 scenario, a profile containing the Filter-Id attribute set to a value “Hot-Line Active” can be included when a user is to be hot-lined. This can be used as a hot-line profile possibly containing other attributes as desired by the wireless operator. Another profile might be defined containing the Filter-Id attribute with the value “Hot-Line Normal.” This profile can be used with the query-session CLI command to bring the user back to normal.

Prime Access Registrar supports send-CoA using CLI and REST API interfaces. For configuring send-CoA using CLI, see the “query-sessions” section in the “Setting the Cisco Prime Access Registrar Configurable Option” chapter of the Cisco Prime Access Registrar 9.1 Administrator Guide. For configuring send-CoA using REST API, see the “CoA and PoD REST APIs” section in the “Support for REST API in Cisco Prime Access Registrar” chapter of the Cisco Prime Access Registrar 9.1 Reference Guide.

The CoA request packet sent by the Prime Access Registrar server conforms to Internet RFC 3756. In response to a CoA request initiated by the Prime Access Registrar server, the client should respond with a COA-ACK if it is able to hot-line the user based on credentials available in the CoA request. If the client is unable to hot-line the user for any reason, the client can include an error-cause attribute with the appropriate reason in a COA-NAK packet.

The Prime Access Registrar server logs all CoA responses. If the Prime Access Registrar server does not receive a response to a CoA request within the timeout period, it will retransmit for the configured number of retries, then logs an error if no response is received.

The Prime Access Registrar server forwards proxied CoA requests sent by external servers to the destination NAS. The CoA requests are proxied based on the NAS-IP-Address in the incoming request. The proxied CoA requests from external servers are forwarded to the destination NAS only if the source IP address is configured to accept dynamic authorization requests. The responses received from the NAS (either COA-ACK or COA-NAK) are forwarded back to the source where the Prime Access Registrar server received the original proxy request.

Configuring Dynamic DNS

Before you configure Prime Access Registrar you need to gather information about your DNS environment. For a given Resource Manager you must decide which forward zone you will be updating for sessions the resource manager will manage. Given that forward zone, you must determine the IP address of the primary DNS server for that zone. If the dynamic DNS updates will be protected with TSIG keys, you must find out the name and the base64 encoded value of the secret for the TSIG key. If the resource manager should also update the reverse zone (ip address to host mapping) for sessions, you will also need to determine the same information about the primary DNS server for the reverse zone (IP address and TSIG key).

If using TSIG keys, use aregcmd to create and configure the keys. You should set the key in the Remote Server or the Resource Manager, but not both. Set the key on the Remote Server if you want to use the same key for all of the zones accessed through that Remote Server. Otherwise, set the key on the Resource Manager. That key will be used only for the zone specified in the Resource Manager.

Configuring the Dynamic DNS

To configure the dynamic-dns remote server:

Step 1 Launch aregcmd.

Step 2 Create the dynamic-dns TSIG Keys:

cd /Radius/Advanced/DDNS/TSIGKeys

add foo.com

This example named the TSIG Key, foo.com, which is related to name of the example DNS server we use. You should choose a name for TSIG keys that reflects the DDNS client-server pair (for example, foo.bar if the client is foo and the server is bar), but you should use the name of the TSIG Key as defined in the DNS server.

Step 3 Configure the TSIG Key:

cd foo.com

set Secret <base64-encoded string>

The Secret should be set to the same base64-encoded string as defined in the DNS server. If there is a second TSIG Key for the primary server of the reverse zone, follow these steps to add it, too.

Step 4 Use aregcmd to create and configure one or more dynamic-dns Remote Servers.

Step 5 Create the dynamic-dns remote server for the forward zone:

cd /Radius/RemoteServers

add ddns

This example named the remote server ddns which is the related to the remote server type. You can use any valid name for your remote server.

Step 6 Configure the dynamic-dns remote server:

cd ddns

set Protocol dynamic-dns

set IPAddress 10.10.10.1 (ip address of primary dns server for zone)

set ForwardZoneTSIGKey foo.com

set ReverseZoneTSIGKey foo.com

If the reverse zone will be updated and if the primary server for the reverse zone is different than the primary server for the forward zone, you will need to add another Remote Server. Follow the previous two steps to do so. Note that the IP Address and the TSIG Key will be different.

You can now use aregcmd to create and configure a resource manager of type dynamic-dns.

Step 7 Create the dynamic-dns resource manager:

cd /Radius/ResourceManagers

add ddns

This example named the service ddns which is the related to the resource manager type but you can use any valid name for your resource manager.

Step 8 Configure the dynamic-dns resource manager.

cd ddns

set Type dynamic-dns

set ForwardZone foo.com

set ForwardZoneServer DDNS

Finally, reference the new resource manager from a session manager. Assuming that the example configuration was installed, the following step will accomplish this. If you have a different session manager defined you can add it there if that is appropriate.

Step 9 Reference the resource manager from a session manager:

cd /Radius/SessionManagers/session-mgr-1/ResourceManagers

set 5 DDNS

Note The Property AllowAccountingStartToCreateSession must be set to TRUE for dynamic DNS to work.

Step 10 Save the changes you have made.

Testing Dynamic DNS with radclient

After the Resource Manager has been defined it must be referenced from the appropriate Session Manager. You can use radclient to confirm that dynamic DNS has been properly configured and is operational.

Testing the Dynamic DNS using Radclient

To test Dynamic DNS using radclient:

Step 1 Launch aregcmd and set the trace to level 4.

aregcmd

Login to the Prime Access Registrar server as an administrative user.

trace 4

Step 2 Launch radclient.

cd /opt/CSCOar/bin

radclient

Step 3 Create an Accounting-Start packet

acct_request Start username

Example:

set p [ acct_request Start bob ]

Step 4 Add a Framed-IP-Address attribute to the Accounting-Start packet

Step 5 Send the Accounting-Start packet

$p send

Step 6 Check the aregcmd trace log and the dns server to verify that the host entry was updated in both the forward and reverse zones.

Configuring Dynamic Service Authorization Feature

Configuring the dynamic service authorization involves:

• Setting Up the Environment Variable
• Configuring the Script for the Dynamic Service Authorization

Setting Up the Environment Variable

Before configuring the dynamic service authorization feature, you must set the following three environment variables in Prime Access Registrar:

• Re-Authentication-Service

When the Re-Authentication-Service is set, the server directs the request to the specified reauthentication service for processing.

• Re-Authorization-Service

When the Re-Authorization-Service is set, the server directs the request to the specified reauthorization service for processing.

• Re-Accounting-Service

When the Re-Accounting-Service is set, the server directs the request to the specified reaccounting service for processing.

You can set the environmental variable by using scripts. See for more information.

Note When using the same service for reauthentication and reauthorization, a loop can occur in these services. The loop count, by default is 10. You can change the loop count using the Dynamic-Service-Loop-Limit environment variable.

Following is a sample procedure for setting the environment variable:

You can append this procedure by copying it into tclscript.tcl that is located in /opt/CSCOar/scripts/radius/tcl directory, or to the location that you chose when you installed Prime Access Registrar. You can also use this procedure as a separate script file and configure the script accordingly. See for more information on configuring the TCL script.

Configuring the Script for the Dynamic Service Authorization

To configure the script for the dynamic service authorization:

Step 1 Launch aregcmd.

aregcmd

Step 2 Change directory to /Radius/Scripts.

cd /Radius/Scripts

Step 3 Enter dynamicservice.

Step 4 Change the directory to dynamicservice.

cd dynamicservice

You get the following output:

Step 5 Set the Language property to TCL.

Set Language TCL

Step 6 Set the filename property to tclscript.tcl.

Set Filename tclscript.tcl

Step 7 Set the EntryPoint property to dynamicservice.

Set EntryPoint dynamicservice

The following is an example of the script configuration:

Step 8 Enter Save to save the configuration.

The following shows a sample trace:

Configuration Examples

The following shows an example configuration for EAP-AKA:

[ //localhost/Radius/Services/eap-aka-wx ]

Name = eap-aka-wx

Description =

Type = eap-aka

AlwaysRequestIdentity = False

EnableIdentityPrivacy = False

PseudonymSecret = <encrypted>

PseudonymRenewtime = "24 Hours"

PseudonymLifetime = Forever

Generate3GPPCompliantPseudonym = False

EnableReauthentication = False

MaximumReauthentications = 16

ReauthenticationTimeout = 3600

ReauthenticationRealm =

AuthenticationTimeout = 120

QuintetGenerationScript~ =

UseProtectedResults = False

SendReAuthIDInAccept = False

SubscriberDBLookup = Diameter

DestinationRealm = mpc.com

PreRequestTranslationScript~ =

PostRequestTranslationScript~ =

PreResponseTranslationScript~ =

PostResponseTranslationScript~ =

The following shows an example configuration for EAP-SIM:

[ //localhost/Radius/Services/eap-sim-wx ]

Name = eap-sim-wx

Description =

Type = eap-sim

NumberOfTriplets = 2

UseSimDemoTriplets = False

AlwaysRequestIdentity = False

EnableIdentityPrivacy = False

PseudonymSecret = <encrypted>

PseudonymRenewtime = "24 Hours"

PseudonymLifetime = Forever

Generate3GPPCompliantPseudonym = False

EnableReauthentication = False

MaximumReauthentications = 16

ReauthenticationTimeout = 3600

ReauthenticationRealm =

TripletCacheTimeout = 120

AuthenticationTimeout = 120

UseProtectedResults = False

SendReAuthIDInAccept = False

SubscriberDBLookup = DIameter

DestinationRealm = hss.com

PreRequestTranslationScript~ =

PostRequestTranslationScript~ =

PreResponseTranslationScript~ =

PostResponseTranslationScript~ =

Configuring Lawful Intercept

Two scripts which are LawfulIntercept and RexLiScript are to be configured to run LawfulIntercept service in Prime Access Registrar. LawfulIntercept script should be configured in the server's incoming scripting point which is used to check the provisioned status of the user in the incoming access request. If the user is provisioned in the data store, Virtual-Server-Outgoing-Script will be executed after the server's ing point.

InitEntryPoint of LawfulIntercept script writes the targeted list of users to a file while the server is stopping and reads the targeted users back to data store while the server is starting.

RexLiScript is configured in Virtual-Server-Outgoing-Script that sends events of the provisioned users to the LI service client.

Configuring the Lawful Intercept

To configure Lawful Intercept:

Step 1 Create the RexLiScript script object that will be set in Virtual-Server-Outgoing-Script point.

Step 2 Create the LawfulIntercept script object.

Step 3 set LawfulIntercept script object to ServerIncoming scripting point;

Note The file 'libLiScript.so' comes up with Prime Access Registrar kit. You have to copy it into /cisco-ar/scripts/radius/rex/ path.

Step 4 Save the configuration:

save

Step 5 Reload the configuration:

reload