Booches.nl

RSA AM 7.1SP3 Token Delivery

Using two-factor authentication is common when publishing remote services to the internet with components like Citrix NetScaler or Juniper SA appliances. RSA is a well-known provider of two-factor authentication mechanism.

Beginning with RSA Authentication Manager 7.1 people have the ability to use the On-Demand feature. This feature enables the delivery of token codes via SMS or e-mail. When using this feature you had to publish the RSA Self-Service website to the internet, so users can request a token code. The RSA Self-Service website is displayed below.

The procedure for opening a extra website to request an On-Demand token is difficult to understand for many people and increases the risk of problems and errors during the authentication process.

This behavior is changed in RSA AM 7.1SP3. With SP3 the Authentication Agent has possibility to generate the On-Demand token request on behalf of the user. The procedure to login to the Authenticaton Agent is:

1. 1. Browse to the portal website
2. 2. Enter your user credentials (username + password)
3. 3. Enter only the token PIN code
4. 4. The Authentication Agent generates the On-Demand token request and redirects the user to a website to enter the On-Demand token code
5. 5. The user waits for the delivery of the token via SMS or e-mail
6. 6. The user enters the On-Demand token code on the Authentication Agents website
7. 7. The Authentication Agent validates the token code and displays the web portal

This way the delivery of token codes is less prone to problems and errors during the authentication process. I personally like this new feature.

Citrix NetScaler: Protocol Driver Error

Today I have been troubleshooting a Citrix NetScaler configuration, where some clients received the Protocol Driver Error message when executing a published application. This error message is mostly related to a wrong configuration of the Security Ticket Authorities (STA’s). I spent a lot of time troubleshooting this issue and focused on the STA configuration. I have been deleting, adding and modifying multiple STA’s to the configuration of the NetScaler without any luck. I checked the configuration of the firewall, but this wasn’t the problem either.

I decided to go back to basic and just added one STA to the Virtual Server and the STA service group used by the Web Interface. I was able to login with that STA server, but after a while I wasn’t able to login and received the Protocol Driver Error again.

While browsing through the NetScaler I noticed one thing. Every time I wasn’t able to login, there were 5 concurrent users already connected with the NetScaler. I did some more research on the internet and found the following article.

Reading the article, tells me that, by default, only 5 concurrent ICA sessions are possible through the NetScaler. I checked the license and the customer has a license for 50 SSL VPN connections, like shown below:

> show license
License status:
Web Logging: YES
Surge Protection: NO
Load Balancing: YES
Content Switching: YES
Cache Redirection: NO
Sure Connect: NO
Compression Control: NO
Delta Compression: NO
Priority Queuing: NO
SSL Offloading: YES
Global Server Load Balancing: NO
GSLB Proximity: NO
Http DoS Protection: NO
Dynamic Routing: YES
Content Filtering: YES
Integrated Caching: NO
SSL VPN: YES  (Maximum users = 50)
AAA: NO
OSPF Routing: NO
RIP Routing: NO
BGP Routing: NO
Rewrite: YES
IPv6 protocol translation: YES
Application Firewall: NO
Responder: YES
HTML Injection: NO
NetScaler Push: NO

I increased the default value to 50 with the following command:

> set aaa parameter -maxAAAUsers 50

From that point on I was able to start another ICA connection, while there were already 5 concurrent users connected. Now I have to wait and see if this actually solved the problem, but I guess it has.

I tried to increase the –maxAAAUsers value to a value higher than 50, but that isn’t possible as you can see.

> set aaa parameter -maxAAAUsers 100
ERROR: MaxAAAUsers value not allowed by license

PacketShaper Traffic Discovery and Citrix Session Reliability

While troubleshooting some performance issues with Citrix sessions between headquarters and sub locations, I decided to take a closer look at the PacketShaper. The PacketShaper is positioned at the headquarter and does outbound shaping to the sub locations. The PacketShaper is using older software (7.2x), which isn’t necessarily a problem.

I deleted the class for a specific location, created the class again and enabled traffic discovery for that class to check which protocols are used by the sub location.

Traffic Discovery: The PacketWise process of observing and creating traffic classes for all packets as they pass through the unit. This process compiles a list of the protocols and applications in use on a network, creating a traffic tree.

Traffic Discovery is working perfectly, because I see different protocols popping up under the sub locations class under which Citrix. In the past PacketShaper had the opportunity to discover the Published Applications or priority bit tagging used with Citrix. This gave you the opportunity to configure shaping parameters per published application.

Nowadays a lot of Citrix customers use Session Reliability. A major drawback of Session Reliability, in conjunction with a PacketShaper, is the encryption of the data stream. The encryption of the data stream prevents the PacketShaper from discovering the published applications or the priority bit tagging.

I first checked if this problem is solved by the latest software release (8.5 at the time of writing), but it isn’t. BlueCoat acknowledges the problem and describes it in this article. The article contains a link to another article about Manage Citrix Performance, which can be useful when using Citrix without Session Reliability.

Disabling Session Reliability isn’t an option for my troubleshooting, so I guess I have to find another way to troubleshoot the performance issues.

User expiration with RSA AM 7.1

I noticed some differences in the user expiration between RSA Authentication Manager 7.1 and RSA Authentication Manager 7.1 SP2. When assigning a token to an user in RSA AM7.1, the user automatically gets an expiration date set on its user account. The default expiration date is one year. I cannot reproduce this same symptom with RSA AM7.1SP2. When I assign a token to an user, the user doesn’t get an expiration date set. I prefer this behavior above setting an expiration date on the user. Setting an expiration date means extra administrative burden for system engineers.

When an user account expires, the user doesn’t have the opportunity to log in on an Authentication Agent. When using the Real-time Activity Monitor, you will see an error message for the specific user with the reason “Principal account expired”.

I configured the reporting functionality to generate reports on monthly basis to filter all user account which expired within the next X days. You can use the built-in template “Expired User Accounts” to generate the report. Next I created a scheduled report to run every last day of the month. This way system engineers can proactively monitor which user account will expire in the near future. One drawback from the scheduled report functionality is lacking the ability to send the report to an mail account. You have to log in to the RSA Security Console to view the reports.

The Death of CiscoBlog.com

CiscoBlog.com is a website often used by myself to find useful information on network related issues. Today I read the following article on the website.

Well, after 5 fun years of running CiscoBlog.com, Cisco “agents” have come. I was contacted by Cisco a couple weeks ago stating that CiscoBlog.com violates their trademark. Being that CiscoBlog.com gets 600,000 hits monthly (isn’t that amazing?!?) I thought I could at least get a box of t-shirts out of the whole deal. Unfortunately, the response went something like, “Mr. Anderson…this is a legal matter. We don’t negotiate.”

So…I have until July 4th to find a new domain name. I guess if I owned Cisco, I wouldn’t want some hoodlum posting at CiscoBlog.com…so I understand the complaint.

…I just wanted a box of t-shirts out of the whole thing… :o)

In my opinion a stupid move from Cisco, because a lot of people use CiscoBlog.com to find information about Cisco technologies / equipment / certification and so forth. I hope the blog stays in the air under a different FQDN and the author doesn’t decide to quit blogging.