Cisco Subscriber Edge Services Manager Troubleshooting Guide 3.3
SESM Troubleshooting Aids
Downloads: This chapterpdf (PDF - 345.0KB) | Feedback

SESM Troubleshooting Aids

Table Of Contents

SESM Troubleshooting Aids

Turning On Installation Logging

Verifying Basic Configurations and Connections

Verifying Operating System Patch Levels

Verifying Basic SSG Configuration

Verifying Connection Access Among SESM Components

Using Java Command Line Options

Using Run Time Logging and Debugging Features

Log File Descriptions

Log File Configuration

Isolating a Problem Area

Determining the Problem Area

Web Based Authentication Problems

Service Activation Problems

Captive Portal User Redirection Problems

RDP Problems

RDP General Problems

RDP in Proxy Mode Problems


SESM Troubleshooting Aids


This chapter describes tools and procedures to use to diagnose and isolate SESM installation and configuration problems. It includes the following topics:

Turning On Installation Logging

Verifying Basic Configurations and Connections

Using Java Command Line Options

Using Run Time Logging and Debugging Features

Isolating a Problem Area

Turning On Installation Logging

The log option on the installation command line turns on the installation logging feature.

On Solaris, the following command runs the GUI mode installation and turns on logging:

sesm_sol.bin -log @ALL

Where:

@ALL indicates to log all messages, which is the recommended procedure

On Windows, the following command runs the GUI mode installation and turns on logging:

sesm_win.exe -options -log @ALL

Where:

@ALL indicates to log all messages, which is the recommended procedure.

Verifying Basic Configurations and Connections

Use the suggestions in this section to verify basic deployment conditions. Topics are:

Verifying Operating System Patch Levels

Verifying Basic SSG Configuration

Verifying Connection Access Among SESM Components

Verifying Operating System Patch Levels

To display Solaris hardware platform type and operating system versions, enter:

uname -a
prtdiag -v

To determine which patches are installed on the system, examine the following directory:

/var/sadm/patches

To determine if there are any new patches and to download the new patches or patch clusters, go to the Sun website.

To display Windows hardware platform type and operating system versions, choose:

Start > Programs > Accessories > System Tools > System Information

Verifying Basic SSG Configuration

This section describes how to verify basic connectivity between Service Selection Gateway (SSG) and a SESM web portal. To perform these verifications, enter the following command on the SSG platform:

show run

Examine the output for the following:

1. Verify that the SSG feature is enabled on the Cisco network device. Examine the output from the show run command for the following line:

ssg enabled

2. Verify that the Cisco IOS release running on the platform contains the features you are intending to implement. Examine the beginning of the show version output for the version information:

Check Cisco Subscriber Edge Services Manager Release Notes for Release 3.3 for feature compatibility information between SESM releases and Cisco IOS SSG releases.

3. Verify that the SSG default network includes the system on which your SESM web applications are installed. Otherwise, client requests never reach the SESM application, and the client browser eventually times out. To display the default network setting, examine the output from the show run command for the following line:

ssg default-network ipAddress mask

Verifying Connection Access Among SESM Components

Verify that the systems that are hosts to the SESM components have connection access to other components in your deployment by pinging the components. Issue pings from the SESM application system to the following systems:

SSG platform

RADIUS server system

SPE database system (if used in your deployment)

For example, enter the following commands from the SESM server:

ping ssg
ping radiusserver

Where radiusserver and ssg are the DNS names or IP addresses of the RADIUS server and SSG. If any of the pings fail, check the configuration attributes in the application MBeans to ensure that the IP addresses or host names in the MBean attributes are accurate.

Using Java Command Line Options

The SESM application startup scripts execute the java command. You can specify any Java command line option when you run the SESM application startup scripts.

To specify Java options, use -jvm as an option on the startup script command line. For example, you might add the following to the command line when you execute SESM application startup scripts:

-jvm -Djava.compiler=NONE

Using Run Time Logging and Debugging Features

The SESM log files can help troubleshoot SESM applications and deployments. By changing the configuration of the logging and debugging mechanisms, you can change the amount of detail reported and specify message filtering. Two of the log files have debugging mechanisms in addition to the logging features.

All SESM applications use the same logging and debugging features. However, the settings for these features are configured individually for each application.

Log File Descriptions

The log files associated with SESM applications are:

Jetty HTTP Request log—Contains incoming HTTP requests. You can use this log file to analyze volume and traffic patterns for the web server.

Jetty log—Contains logging and debugging messages from Jetty. The logging messages record the startup of the Jetty server and all ongoing activity, such as errors trapped by the Jetty server and HTTP errors. If the SESM application fails to start, look at this log. Make sure you monitor this log file for illegal HTTP requests that might indicate attempts to subvert the web server. If you enable debugging, the log file also includes more detailed debugging messages.

Application log—Contains logging and debugging messages from the SESM application. The logging tool logs SESM web application activity. The debugging mechanism produces messages useful to developers in debugging applications.

You can configure all three of these logs for each SESM portal application and for CDAT. RDP uses only the application log.

Log File Configuration

The installed default configuration places all log files for an application into the logs subdirectory under the application home directory. For example:

SESMinstallDir
nwsp
logs

If the logs directory does not exist, it is created at application startup time.


Note ERP applications log files (DNS proxy for example), except for RDP log files are under: tools/logs/<application name> (e.g.tools/logs/dns).


Table 2-1 shows the MBeans that configure the log files, including the level of verbosity in the logs, message filtering, debugging, file location, and file management.

Table 2-1 Configuring the Log Files

Log Type
MBean Name
Filename Attribute
Default Log Filename

Request log

Server MBean

RequestLog

date.request.log

Jetty log

Log MBean

Debug MBean

filename

date.jetty.log

Application log

Logger MBean

logFile

date.application.log


For explanations of the attributes in these MBeans, see the Logging and Debugging Applications chapter in Cisco Subscriber Edge Services Manager Administration and Configuration Guide. To change values of the logging attributes, use the SESM Application Manager. The Application Manager includes an operational scenario for Logging.

Isolating a Problem Area

This section provides flow charts for analyzing and isolating the causes of problems in SESM deployments. This section contains:

Determining the Problem Area

Web Based Authentication Problems

Service Activation Problems

Captive Portal User Redirection Problems

RDP Problems


Note For further information about installation issues or changing configuration parameters, refer to Cisco Subscriber Edge Services Manager Installation Guide and Cisco Subscriber Edge Services Manager Administration and Configuration Guide.


Determining the Problem Area

This section describes some initial troubleshooting procedures which can be used to determine the general area of the problem.

Figure 2-1 Determining the Problem Area

Table 2-2 provides additional information about the determining the problem area flow chart.

Table 2-2 Determining the Problem Area 

Problem
Additional Information

Verifying whether SESM was successfully installed.

The SESM Release Notes for a particular version will document any installation bugs and their associated workarounds. Refer to the online documentation for these details:

http://www.cisco.com/univercd/cc/td/doc/solution/sesm/index.htm

In cases where installation-related issues are reported, ensure that the SESM platform has the latest operating system patches installed. Refer to the Sun and Windows websites for details.

Verifying whether the Web Portal has been modified.

You might make modifications to the SESM web portals, either in the way the portal looks, or in more advanced cases, by adding new features. In both cases, if you encounter a problem with the modified application, you must repeat any tests with the standard SESM Subscriber Portal.

Verifying whether the problem occurs with the default SESM Web Portal.

If the problem persists when you repeat a test with the default web portal, then the Cisco Technical Assistance Center (TAC) can troubleshoot further using the standard web portal. Use this document to further diagnose the problem and provide the appropriate information to TAC.

If the problem does not exist once you revert to the standard web portal, then you will most likely have introduced a bug into your modified code. For assistance in troubleshooting the modified application, contact the SESM Developer Support Program (DSP):

http://www.cisco.com/en/US/products/svcs/ps3034/ps5408/ps5418
/serv_home.html

Verifying whether Web-Based Authentication is working.

If you cannot authenticate successfully using the SESM web portal, continue to Web Based Authentication Problems to attempt to diagnose the problem.

Verifying whether Service-Selection is working.

If you cannot activate a service using the SESM web portal, continue to Service Activation Problems to attempt to diagnose the problem.


Escalation

If you are unable to resolve the problem, report the problem to the Cisco Technical Assistance Center (TAC). For details see "Procedures for Reporting SESM Problems to Cisco."

You should provide the following information to TAC:

Description of the problem, including SESM version and platform its installed on (Solaris/Windows/Linux)

Network topology diagram

SSG Configuration

SSG Version

Contents of the following directories within SESM in a .zip or .tar file:

<SESM>/nwsp/config/*

<SESM>/jetty/config/*

<SESM>/jetty/bin/*

Web Based Authentication Problems

This section describes some basic troubleshooting procedures for the SESM Web Portal.

Figure 2-2 Web Based Authentication Problems

Table 2-3 provides additional information about the Web Authentication Problems flow chart.

Table 2-3 Web Based Authentication Problems 

Problem
Additional Information

Checking connectivity and verifying the SESM applications are running.

1. Check Connectivity and Topology.

The first and most basic check to perform when authentication fails is to check for connectivity between all of the relevant network elements. Use "ping" to verify that SESM, SSG, and AAA can all communicate with each other.

Once you ensure IP connectivity, check the network topology. Look for any firewalls in the network between the SESM, SSG, and AAA. Check the firewall configs to ensure that they are not blocking RADIUS traffic. In addition, if SESM is deployed in an SPE (self-care) scenario, ensure that the firewall is not blocking the Web Portal or RDP from reaching the LDAP directory.

Default RADIUS port on SESM: 1812

Default LDAP port on SESM: 389

2. Check whether SESM Applications are Running.

Check whether the SESM applications are still running. Use commands like netstat to determine if the applications are still listening on their normal ports

netstat -an | grep <portno>

The following are default port numbers of various SESM applications:

Web Portal: 8080

CDAT: 8081

CDATApplication Manager: 8082

Message Portal: 8085

Captive Portal: 8090

Web Proxy: 8102

Verifying if the Web Portal is configured correctly to communicate with SSG.

If there are short delays (around 30-60 seconds) when attempting to display the login page, it's likely that the Web Portal is not configured to communicate with the SSG correctly.

If you are using IP Host-Key in your deployment:

You must statically map between your client subnets and your SSG's IP address. This will mean that there will be one or more lines such as the following in their application configuration file. (File: <SESM>/nwsp/config/nwsp.xml)

This line maps all clients on the 10.0.0.0/8 network to the SSG at 192.168.150.10

<Callname="setSubnetAttribute"><Arg>10.0.0.0</Arg><Arg>255.0.0.0</A
rg><Arg>IP</Arg><Arg>192.168.150.10</Arg></Call>

Check that the clients which you are using to test fall within the subnets defined in these lines, and that the SSG IP address is correct and reachable. No additional configuration is required on the SSG for an IP Host-Key deployment.

If you are using Port-Bundle Host-Key in your deployment:

When Port-Bundle Host-Key (PBHK) is configured, the only configuration required within the application config file is setting the BUNDLE_LENGTH. The BUNDLE_LENGTH within the SESM config file should match the "port-map length" setting on the associated SSG (the default value for this on the SSG is 4).

<Callname="setGlobalAttribute"><Arg>BUNDLE_LENGTH</Arg><Arg>4</Arg>
</Call>

RADIUS Shared Secrets

A "shared secret" password exists between a RADIUS client and a RADIUS server. The secret on the client and server side must match before the two devices can successfully exchange RADIUS messages.

In a SESM RADIUS deployment, the Web Portal sends RADIUS requests to the SSG (user authentication and authorization), and the RADIUS server (service profile download). A different shared secret exists between SESM/SSG and SESM/RADIUS Server. In practice, these may be the same, but it's important to realize that they can be different.

Verifying if the Web Portal is configured correctly to communicate with SSG. (continued)

This section of the NWSP's configuration file shows where the SESM/RADIUS Server shared secret is set:

File: <SESM>/nwsp/config/nwsp.xml

  <Configure 
jmxname="com.cisco.sesm:name=AAA,connection=ServiceProfile"> 
    <Set name="throttle" type="int">256</Set>
    <Set name="timeOut" type="int">4000</Set>
    <Set name="maxRetries" type="int">3</Set>
    <Set name="primaryIP">ANHAWKIN-W2K3</Set>
    <Set name="primaryPort" type="int">1812</Set>
    <Set name="secret">cisco</Set>
    <Set name="secondaryIP">ANHAWKIN-W2K3</Set>
    <Set name="secondaryPort" type="int">1812</Set>
    <Set name="servicePassword">servicecisco</Set>
    <Set name="serviceGroupPassword">groupcisco</Set>
  </Configure>

This section of the NWSP's configuration file shows where the SESM/SSG shared secret is set:

File: <SESM>/nwsp/config/nwsp.xml

<Callname="setGlobalAttribute"><Arg>PORT</Arg><Arg>1812</Arg> 
</Call>
<Callname="setGlobalAttribute"><Arg>TIMEOUTSECS</Arg><Arg>10</Arg> 
</Call>
<Callname="setGlobalAttribute"><Arg>RETRIES</Arg><Arg>3</Arg></Cal>
<Callname="setGlobalAttribute"><Arg>SECRET</Arg><Arg>cisco</Arg> 
</Call>
<Callname="setGlobalAttribute"><Arg>THROTTLE</Arg><Arg>20</Arg> 
</Call>

In a SESM SPE Deployment, the Web Portal sends only RADIUS requests to the SSG. The configuration section for SSG communication is exactly the same in an SPE deployment as it is in a RADIUS deployment.

Verifying that the SSG is correctly configured with the correct AAA and Radius server settings.

Check whether the SSG router is correctly configured with the appropriate AAA and RADIUS server settings, and that the shared secret between the SSG and the RADIUS server matches.

Verifying whether user profile exists within the AAA server.

Ensure that the user profile that you are using to conduct the tests exists within the RADIUS server and that you are using the correct password.

From the SSG router, issue the following command to test the SSG/RADIUS server communication.

ROUTER# test aaa group radius <username> <password> 
<radius-server-port> <code-path>

This will send an access-request to the RADIUS server for the given username and password. If authentication is successful, then the communication between the SSG and RADIUS server is correctly configured. If this command is not successful, there is a problem with the communication between the SSG and the RADIUS server.

Verifying that both SESM and SSG are configured to be RADIUS clients in the AAA server.

Ensure that both SESM and SSG are in any client list that is configured on the RADIUS server.

The SSG sends RADIUS requests to the RADIUS server whenever a user attempts to login/activate a service. In a SESM RADIUS installation, SESM also sends requests to the RADIUS server to download service profiles in order to determine the service type, as well as other service attributes.

If the RADIUS server has a client list configured and SESM or the SSG does not feature in this client list, there will be problems when a user tries to log in to the portal.


Escalation

If you are unable to resolve the problem, report the problem to the Cisco Technical Assistance Center (TAC). For details see "Procedures for Reporting SESM Problems to Cisco"

You should provide the following information to TAC:

Description of the problem, including SESM version and platform on which SESM is installed. (Solaris/Windows/Linux).

Network topology diagram.

SSG Configuration.

SSG Version.

Example of the user profile which is causing the problem.

List of web browsers being used in the test.

Zipped/tarred contents of the following directories within SESM:

<SESM>/nwsp/config/*

<SESM>/jetty/config/*

<SESM>/jetty/bin/*

Service Activation Problems

This section describes basic troubleshooting procedures for SESM Activation.

Figure 2-3 Service Activation Problems

Table 2-4 provides additional information about the Service Activation Problems flow chart.

Table 2-4 Service Activation Problems 

Problem
Additional Information

Verifying that the service passwords in SESM, SSG and AAA match.

For an attempted service connection to be successful, the service passwords on the SESM, SSG, and RADIUS server (part of the service profile itself) must all match.

SESM Service Password

In the SESM Subscriber Portal, the service password is defined here:

File: <SESM>/nwsp/config/nwsp.xml

  <Configure 
jmxname="com.cisco.sesm:name=AAA,connection=ServiceProfile"> 
    <Set name="throttle" type="int">256</Set>
    <Set name="timeOut" type="int">4000</Set>
    <Set name="maxRetries" type="int">3</Set>
    <Set name="primaryIP">ANHAWKIN-W2K3</Set>
    <Set name="primaryPort" type="int">1812</Set>
    <Set name="secret">cisco</Set>
    <Set name="secondaryIP">ANHAWKIN-W2K3</Set>
    <Set name="secondaryPort" type="int">1812</Set>
    <Set name="servicePassword">servicecisco</Set>
    <Set name="serviceGroupPassword">groupcisco</Set>
  </Configure>

SSG Service Password

In the SSG configuration, the service password definition will be similar to the following (depending on SSG version):

ssg service-password <service-password>

RADIUS Server Service Password

Within the RADIUS server, the service-profile will also have a service-password associated with it. In this example from a Merit-format file, the password is servicecisco:

Internet-Basic Password = "servicecisco", Service-Type = 
Outbound
        Service-Info = "IBronze Internet - 500KB",
        Service-Info = "R151.151.151.0;255.255.255.0",
        Service-Info = "MC",
        Service-Info = 
"QU;512000;16000;32000;D;512000;16000;32000",
        Service-Info = "TP"


Verifying if the problem is affecting services requiring authentication.

Check if the problem is with all types of services (Passthrough, Proxy and Tunnel services), or just with services requiring authentication.

If the problem is with services requiring authentication, then you must check the service profiles and the connectivity to the remote RADIUS and LNS servers.

Verifying if the problem is affecting services requiring authentication. (continued)

Proxy Service

Attempting to activate a proxy service results in the SSG sending a RADIUS request to a remote RADIUS server to authenticate the user at the remote server, so that the user is able to access the service.

If the RADIUS server is not configured correctly, or the end user is supplying the incorrect credentials to this server (the username and password that a user supplies to the remote RADIUS server are generally not the same as the user's login credentials), then the service activation will fail.

Below is an example of a proxy service profile in merit format. The Service-Info `S' attribute defines the remote RADIUS server to use for service authorization:

discount_shopping Password = "servicecisco", Service-Type = 
Outbound
        Service-Info = "IDiscount Shopping",
        Service-Info = "R158.158.158.0;255.255.255.0",
        Service-Info = "S192.168.146.10;1812;1813;cisco",
        Service-Info = "MC",
        Service-Info = "TX"

The various fields that make up the service-info S attribute are as follows:

Service-Info = S<remote-radius-ip>;<auth-port>;<accounting-port>;<shared-secret>

Tunnel Service

Attempting to activate a tunnel service will result in the SSG creating an L2TP tunnel between itself and the LNS defined in the tunnel service profile. If the tunnel attributes are incorrect, then the tunnel will not be established. As with the Proxy service example, if the end user is supplying the incorrect credentials when attempting to connect to the service (which are again likely to be different to the login credentials), the service will not be activated.

Below is an example of a tunnel service profile in merit format:

banking Password = "servicecisco", Service-Type = Outbound
        Service-Info = "IBanking Tunnel",
        Service-Info = "MC",
        Service-Info = "TT",
        Service-Info = "R198.198.198.0;255.255.255.0",
        av-pair = "vpdn:tunnel-id=bank-tunnel-id",
        av-pair = "vpdn:l2tp-tunnel-password=cisco",
        av-pair = "vpdn:tunnel-type=l2tp",
        av-pair = "vpdn:ip-addresses=10.99.99.2"


Verifying if the service causing the problem is a prepaid service.

If a user is attempting to connect to a prepaid service (service profile contains `service-info=Z') when they have no quota, the service logon attempt will not be successful.


Escalation

If you are unable to resolve the problem, report the problem to the Cisco Technical Assistance Center (TAC). For details see "Procedures for Reporting SESM Problems to Cisco".

You should provide the following information to TAC:

Description of the problem, including SESM version and platform SESM is installed on (Solaris/Windows/Linux)

Network topology diagram

SSG Configuration

SSG Version

Example of the user profile and service profiles which are causing the problem

List of web browsers being used in the test

Zipped/tarred contents of the following directories within SESM:

<SESM>/nwsp/config/*

<SESM>/jetty/config/*

<SESM>/jetty/bin/

Captive Portal User Redirection Problems

This section describes basic troubleshooting procedures for the SESM Captive Portal application.

Figure 2-4 Captive Portal User Redirection Problems

Table 2-5 provides additional information about the Captive Portal User Redirection Problems flow chart.

Table 2-5 Captive Portal User Redirection Problems 

Problem
Additional Information

Verifying whether the SESM applications are running.

Check if all of the required applications have been started. If not, use the following start scripts:

<SESM>/jetty/bin/startNWSP

<SESM>/jetty/bin/startCAPTIVEPORTAL

Verifying whether SSG is configured properly.

Use the example SSG configuration that is provided within the SESM installation to check if the SSG is configured to communicate with the Captive Portal application properly.

The example file can be found at the following location:

<SESM>/captiveportal/config/ssgconfig.txt

If this file/directory does not exist, the Captive Portal application has not been installed, and will not be running.

You should perform a custom installation of SESM again, and select the Captive Portal option, plus all of the prerequisites (prerequisites will be auto-selected by the installer) during the installation process.

The following ports on the Captive Portal application correspond to the types of TCP redirection on the SSG:

8090—Unauthenticated User Redirection

8091—Initial Captivation

8092—Advertisement Captivation

8093—Default Service Redirection

8094—Named Service Redirection

8095—Named Service Redirection

8096—Named Service Redirection

8099—HTTPS Redirection

8101—Unauthorized web-proxy redirection

Verifying if the Captive Portal is redirecting unauthenticated users to the correct location.

Check that the Captive Portal application is redirecting users to the correct URL. This should be the URL of the SESM Web Portal.

The Captive Portal configuration file defines where unauthenticated users are redirected by Captive Portal and is at the following location:

<SESM>/captiveportal/config/captiveportal.xml

This section defines whether unauthenticated user redirection is enabled:

<Set name="userRedirectOn" type="boolean">true</Set>

This section defines the URL which unauthenticated users will be redirected to:

<Set name="userRedirectURL">http://<SystemProperty 
name="serviceportal.host" 
default="192.168.147.42"/>:<SystemProperty 
name="serviceportal.port" default="8080"/>/home</Set>

A misconfiguration where the Captive Portal is redirecting users to a URL which is not SESM, results in a redirection to the error URL. However if the error URL is also misconfigured, this will result in a loop, where users are continually TCP redirected back to Captive Portal. This can be avoided by having a local error page rather than a redirection error URL.

Verifying whether the browser has a web proxy configured.

If the browser has a web proxy configured, the solution may not be able to authenticate the user (depending upon SESM and SSG versions). You should re-try with the web proxy disabled.

If it is a requirement that web proxy users are able to authenticate and use the system, you should be using SESM-3.2(1) or later. You should also be using SSG version 12.3(3)B or 12.3(8)T onwards. To ensure that permanent redirection works, verify SSG support for permanent redirection.


Escalation

If you are unable to resolve the problem, report the problem to the Cisco Technical Assistance Center (TAC). For details see "Procedures for Reporting SESM Problems to Cisco"

You should provide the following information to TAC:

Description of the problem, including SESM version and platform SESM is installed on (Solaris/Windows/Linux)

Network topology diagram

SSG Configuration

SSG Version

Example of the user profile which is causing the problem

List of web browsers being used in the test

Zipped/tarred contents of the following directories within SESM:

<SESM>/nwsp/config/*

<SESM>/captiveportal/config/*

<SESM>/jetty/config/*

<SESM>/jetty/bin/*

RDP Problems

The following sections describe basic troubleshooting procedures for the SESM RADIUS Data Proxy.

It is divided into two sections:

RDP General Problems

RDP in Proxy Mode Problems

RDP General Problems

This section describes basic troubleshooting procedures for establishing RDP configuration.

Figure 2-5 RDP General Problems

Table 2-6 provides additional information about the RDP General Problems flow chart.

Table 2-6 RDP General Problems 

Problem
Additional Information

Verifying whether Proxy mode is configured.

The following section of the RDP configuration file shows whether Proxy mode is configured.

File: <SESM>/rdp/config/rdp.xml

<Item><New class="com.cisco.sesm.erp.ERPFilter">
<Set name="name">AUTHENTICATION</Set>
<Set name="nextHandler">PROXY</Set>
</New>
</Item>

Other values of the `nextHandler' attribute include DOMAINPROXY and LOCAL. Where Proxy mode is configured, proceed to Escalation.

Verifying whether RDP has a client list configured.

The following section of the RDP configuration file defines the server's client-list. This must contain all of the RDP's RADIUS clients (such as the SSGs), and their correct shared secrets.

File: <SESM>/rdp/config/rdp.xml

<Set name="allowedClients">
<Array class="java.lang.String">
<Item>client_one:secret_one</Item>
<Item>client_two:secret_two</Item>
</Array>
</Set>

However, even when RDP is configured with the client list, it uses the 
global shared secret for all the clients and not the per client shared secret.

Note RDP will also work if no clients are defined. If no clients are defined it will accept all clients.


Verifying whether authentication works.

The RDP can be configured to respond to successful authentication requests in two ways, with the full user profile or without the full user-profile.

Add Services must be configured in the RDP for auto-connect services to be successfully connected at user logon.

Add Services is configured in the following location:

File: <SESM>/rdp/config/rdp.xml

<Set name="addService" type="boolean">true</Set>
<Set name="addAutoService" type="boolean">true</Set>
<Set name="addGroup" type="boolean">true</Set>

`addAutoService' must be set to true in order for the auto-connect services to be added to the successful authentication request.


Escalation

If you are unable to resolve the problem, report the problem to the Cisco Technical Assistance Center (TAC). For details see "Procedures for Reporting SESM Problems to Cisco".

You should provide the following information to TAC:

Description of the problem, including SESM version and platform its installed on (Solaris/Windows/Linux)

Network topology diagram

SSG Configuration

SSG Version

Example of the user profile which is causing the problem

List of web browsers being used in the test

Zipped/tarred contents of the following directories within SESM:

<SESM>/nwsp/config/*

<SESM>/rdp/config/*

RDP in Proxy Mode Problems

This section describes basic troubleshooting procedures for RDP in Proxy Mode.

Figure 2-6 RDP in Proxy Mode Problems

Table 2-7 provides additional information about the RDP in Proxy Mode problems flow chart.

Table 2-7 RDP in Proxy Mode Problems 

Problem
Additional Information

Verifying whether the RDP Proxy mode configuration is correct.

Check which version of SESM you are using. The example below is valid for SESM-3.1(9) and SESM-3.2(1). This section shows that the RDP is configured for Proxy mode:

File: <SESM>/rdp/config/rdp.xml

<!-- installer:start proxy -->
<Item><New class="com.cisco.sesm.erp.ERPFilter">
<Set name="name">AUTHENTICATION</Set>
<Set name="nextHandler">PROXY</Set>
</New></Item>
<!-- installer:end proxy -->

The following section of the rdp.xml file defines which remote RADIUS server the RDP will use:

File: <SESM>/rdp/config/rdp.xml

<Configure 
jmxname="com.cisco.sesm:name=RDP,PROXY=ProxyHandler,component=RA
DIUSClientSocket">
<Set name="throttle" type="int">256</Set>
<Set name="timeOut" type="int">4000</Set>
<Set name="maxRetries" type="int">3</Set>
<Set name="primaryIP">proxy_server_primary</Set>
<Set name="primaryPort" type="int">1812</Set>
<Set id="AAASecret" name="secret">cisco</Set>
<Set name="secondaryIP">proxy_server_secondary</Set>
<Set name="secondaryPort" type="int">1812</Set>
<Set name="accountingPortOffset" type="int">1</Set>
</Configure>

You need to ensure that the primary and secondary RADIUS server in this section is correctly configured and points to a RADIUS server that will carry out the authentication of users.

Also, check the ports and the secret that the remote RADIUS server is configured with to ensure they match the settings in the section from the rdp.xml file provided above.

Verifying if the remote RADIUS server is configured correctly.

You need to verify that the remote RADIUS server is correctly configured. For example, we need to ensure that if it has a client list configured, then this list must include the RDP server.

You should check the following:

IP address

RADIUS port

RADIUS shared secret

Client list

Connectivity

Verifying if the RDP's LDAP directory configuration is correct.

The following file defines the LDAP directory that the RDP will attempt to connect to, and the privileged user that it will use to attempt to do so. It also defines the container in which the SESM and SSG objects will be stored.

File: <SESM>/rdp/config/dessauth.xml

This section defines the server the RDP will use:

<Configure 
jmxname="com.cisco.sesm:name=Directory,type=Connection,instance=
Primary">
<Set name="poolSize" type="int">2</Set>
<Set name="URL">ldap://127.0.0.1:389/</Set>
<Set name="principal">cn=admin,ou=sesm,o=cisco</Set>
<Set name="credentials">admin</Set>
  </Configure>

This section defines the container that the SESM applications will use to lookup and store the SESM/SSG objects:

<Configure jmxname="com.cisco.sesm:name=Directory">
<Set 
name="connectionNameRoot">com.cisco.sesm:name=Directory,type=Con
nection,*</Set>
<Set 
name="factory">com.cisco.cns.security.jndi.JNDIConnection</Set>
<Set name="context">ou=sesm,o=cisco</Set>
<Set name="DESSPrincipal">cn=admin,ou=sesm,o=cisco</Set>
<Set name="alwaysGetAllAttributes" type="boolean">false</Set>

If your LDAP directory is not defined using this information, it is likely that you have entered the wrong values during the SESM installation. The only way to correct this is to reinstall the SESM applications (as this will also affect applications such as CDAT and the Subscriber Portal).


Escalation

If you are unable to resolve the problem, report the problem to the Cisco Technical Assistance Center (TAC). For details see "Procedures for Reporting SESM Problems to Cisco."

You should provide the following information to TAC:

Description of the problem, including SESM version and platform SESM is installed on (Solaris/Windows/Linux)

Network topology diagram

SSG Configuration

SSG Version

Example of the user profile which is causing the problem

Zipped/tarred contents of the following directories within SESM:

<SESM>/nwsp/config/*

<SESM>/rdp/config/*