Connecting the world…

on

RSA 7.1 with On-Demand

RSA token security provides a way to strengthen the security on public services. Token authentication is most often implemented with hardware tokens. RSA 7.1 has additional methods of token authentication besides the hardware tokens:

  • Token delivery by SMS;
  • Token delivery by e-mail;

To enable the above features you have to install at least RSA 7.1 and obtain a On-Demand license, like shown below:

rsa-od-lic

Next I will show you how to configure token authentication for the delivery of tokens through SMS and e-mail. My test environment contains a RSA Authentication Manager 7.1 with RADIUS server installed on a Windows 2003 R2 server under VMware. The RSA server has a LDAP mapping to Active Directory for authenticating users.

E-MAIL

The first method explained is configuring RSA to deliver tokens to an e-mail address. The first step is configuring a SMTP server on the RSA server. In this scenario I create a SMTP connection to a Windows Exchange 2003 server. rsa-od-mailIn the Security Console, navigate to Setup – Instances and edit the instance you would like to use for the SMTP connection.

In the SMTP setup you need to configure the Hostname of the SMTP server and a “from” e-mail address. Some SMTP servers require authentication to use them as relay server. If your SMTP server requires authentication you can configure the appropriate user credentials. In my situation I only need to deliver mail to the @booches.nl domain, so I don’t need to configure authentication or assign relay rights to the RSA server on the Exchange server. If you would like to deliver e-mail to domains outside your mail environment, you have to configure authentication or relay access for the RSA server.

rsa-od-ena-mail After configuring the SMTP server you have to enable the ability to deliver token codes by e-mail. Navigate to Setup – Component Configuration – Authentication Manager – On-Demand Tokencodes in the Security Console. Enable the option “Delivery by E-mail” and choose the User Attribute to Provide E-mail Destination. This User Attribute is obtained by default through LDAP. In my scenario I use the e-mail field within Active Directory to obtain the specific e-mail address from a user.

rsa-od-user-mail From now on you can enable the usage of e-mail token delivery to your users. To accomplish this navigate to Identity – Users – Manage Existing and search for a specific user. Go to Security Tokens for the specific user and enable “On-Demand Tokencodes” and the specific settings, like shown in the picture. I configured an initial PIN for the user. The user should be able to obtain a token code through SMS via the Self-Service console. This portal can be reach via the URL: https://<ip address / FQDN RSA server>:7004/console-selfservice.

On-Demand token codes have a PIN code associated to the delivered token code. This PIN code is different from the PIN code of normal hardware tokens. I normally enable the On-Demand feature for a user and specify the first initial PIN code. After the user logs in with this PIN code, the PIN code needs to be changes. There are two ways of doing this:

  1. The user automatically receives a new PIN code, which is generated by the RSA server;
  2. The user has the option to manually specify a new PIN code;

rsa-od-token-policy Most often system engineers let the customers choose there own PIN code. Toggling between both settings is possible by changing the Token Policy. Changing the Token Policy is possible by navigating to Authentication – Policies – Token Policies.

SMS

To configure SMS token delivery you need some kind of method to send SMS messages. RSA and Clickatell have partnered to enable delivery of SecurID tokencodes to mobile devices via SMS/text. RSA Authentication 7.1 has a build-in method for delivering SMS messages through Clickatell. Click here to obtain more info about the partnership between RSA and Clickatell and how to register a (trial) Clickatell account.

The first step is to link a User Attribute from the Active Directory to RSA. This User Attribute contains the phone number for delivering the SMS. To such link navigate to Identity – Identity Attribute Definition – Add New.

rsa-od-mobile-link

Within Active Directory you can configure multiple Telephone numbers for a user. Because the SMS is sent to the users mobile phone, I enter the appropriate phone number under the mobile Telephone number of the users.

The picture shows how to configure the the User Attribute mapping. The Attribute Name is a user friendly name to identify the mapping. I choose Personal as Category and the Entry Type is optional. The users mobile phone number is displayed under Personal when editing the user.

The Identity Source Mapping defines the LDAP attribute to use for obtaining the mobile phone number from the user. This value has to be exactly the same as the LDAP value for the mobile phone number in Active Directory. I use Softerra’s LDAP browser to obtain this value from Active Directory. Softerra LDAP browser is a useful tool for browsing LDAP directories.

rsa-od-sms

The configuration of the SMS service provider can be found under Setup – Component Configuration – Authentication Manager – On-Demand Tokencodes.

You need to enable the option “Delivery by SMS”, choose the previously configured User Attribute, select your country code and provide the credentials for your Service Provider.

You can now switch between token code delivery by e-mail and SMS. A user has the option to choose the preferred delivery method via the Self-Service console. Users need access to the Self-Service console to request a token code. The Self-Service portal needs to be securely published to the internet. This can be achieved by using a reverse proxy or some comparable solution. The following PDF contains a quick howto for publishing the RSA environment securely to the internet.

Juniper SA & Terminal Server with Novell Client SSO

Normally configuring SSO on a Terminal Server in conjunction with a Juniper SA isn’t that hard. On the Juniper you pass the user credentials to the Terminal Server. On a normal Terminal Server you have to check the following:

Disable Always prompt for password under:

Terminal Services Configuration –> Connections –> Properties of RDP-tcp –> Tabblad Logon Settings

On a Terminal Server, which is member of a Windows Domain, you have to check the following Group policy:

Disable Always prompt client for password upon connection under:

Computer Configuration –> Administrative Templates –> Windows Components –> Terminal Services –> Encryption and Security –> Policy “Always prompt client for password upon connection”

Now I had to configure Single Sign On to a Terminal Server where the Novell Client is installed. As soon as I pushed the user credentials to the Terminal Server, I noticed that the RDP session tries to logon as Workstation only. I found a nice thread on the Novell website to Enable TSClientAutoAdminLogon.

I added the following two registry keys to the registry:

HKEY_LOCAL_MACHINE\SOFTWARE\Novell\Login 
Value Type=REG_SZ, Name=TSClientAutoAdminLogon, Data=1 
Value Type=REG_SZ, Name=DefaultLoginProfile, Data=Default 

I am able to logon to the Terminal Server using SSO after adding both registry keys to the registry. All registry entries under HKEY_LOCAL_MACHINE\SOFTWARE\Novell\Login are displayed in the picture below.

SSO_TS_novell_client

Juniper SA & GroupWise WebAcc SSO

While configuring a Juniper SA2500 in conjunction with Novell GroupWise WebAccess, the customers wanted single sign on (SSO) configured. The default Novell GroupWise WebAccess login page uses FBA (Forms Based Authentication). So it should be possible to push the correct POST parameters to enable SSO for GroupWise WebAccess.

I started with looking at the page source of the login page and found the POST configuration. You can find them by searching the string:

<form method=”post” action=”/gw/webacc” name=”loginForm” target=”_top”>

I configured a Web Resource Profile in the Juniper SA. This Resource Profile has a bookmark which displays the Novell GroupWise WebAccess page. Next I configured a Form POST Resource Policy. The picture below shows the configuration.

JuniperSA-gwwebacc-sso

The table displays the POST detail settings:

User label Name Value
error error login
User.displayDraftItems User.displayDraftItems 1
merge merge webacc
action action User.Login
Url.hasJavaScript Url.hasJavaScript 1
Low.bandwidth Low.bandwidth 0
User.interface User.interface css
User.Theme.index User.Theme.index 1
Username User.id <USER>
Password User.password <PASSWORD>
User.lang User.lang nl
User.settings.speed User.settings.speed high

The above configuration works in my situation. The user is automatically logged in to their corresponding Novell GroupWise WebAccess page.

Link State Tracking

Last week a friend called me and told me he was having serious problems with his network. A complete blade environment wasn’t able to communicate with the rest of the network. I asked what changed in the network and he told me that he had added a VLAN to a trunk allowed lists.

Because he is a friend, I dialed in and checked the configuration of the switch. I noticed that all ports on the switch were err-disabled. What happened here, that all switch ports were err-disabled!!! I noticed the configuration of link state tracking on all ports.

Link-state tracking, also known as trunk failover, is a feature that binds the link state of multiple interfaces. Link-state tracking provides redundancy in the network when used with server network interface card (NIC) adapter teaming. When the server network adapters are configured in a primary or secondary relationship known as teaming and the link is lost on the primary interface, connectivity transparently changes to the secondary interface.

At first I was skeptic about the link state configuration and asked my friend why it was used. He couldn’t give me any answer, because he didn’t configure the switch. For me it was hard to find a reason why link state tracking was used, because I wasn’t familiar with the network. I removed the link state configuration from the switch. All ports changed to a normal state. I noticed that the uplink (port-channel) configuration wasn’t correct. They added the VLAN to the trunk allowed lists on a member port and not on the port-channel interface.

After helping my friend and dreaming for a couple of days, I started thinking about the Link State Tracking feature. I tried to discover why someone configured the feature in my friends environment. Eventually, after some brain cracking, I found the solution. Let’s look at the following example environment.

LinkStateTracking

The figure shows one ESX server, which has two NIC’s. One NIC is connected to bl-sw01 and the other NIC is connected to bl-sw02. The ESX uses the load-balancing algorithm “Route based on Virtual PortID”.

Now lets assume the link between bl-sw02 and dis-sw02 loses its connection. Because the ESX server still has a connection with bl-sw02, it keeps sending packet that way. Switch bl-sw02 doesn’t have any uplink to the rest of the network, so the packet will get dropped.

When using Link State Tracking the connection between the ESX server and switch bl-sw02 will also loose its connection when the uplink between bl-sw02 en switch dis-sw02 gets lost. The ESX server will only use the connection with switch bl-sw01 to reach the rest of the network. Link State Tracking uses upstream and downstream interfaces. In the example the connection between the switch port, which connects switch bl-sw02 to switch dis-sw02, would be configured as an upstream port. The switch port to the ESX server would be configured as a downstream port. The downstream port is put in err-disable state when the upstream port loses its connection. This is exactly what you would like to accomplish.

The first step to enable Link State Tracking globally on the switch:

bl-sw02(config)# link state track 1

The next step is configuring the upstream and downstream interfaces.

interface GigabitEthernet0/16
description switch-uplink

switchport trunk encapsulation dot1q
switchport mode trunk
switchport nonegotiate
link state group 1 upstream
spanning-tree link-type point-to-point

!

interface GigabitEthernet0/10
description ESX01

switchport trunk encapsulation dot1q
switchport mode trunk
switchport nonegotiate
link state group 1 downstream
spanning-tree portfast trunk

You can check the status of the Link State Group with the following command:

bl-sw02#show link state group detail

Link State Group: 1 Status: Enabled, Up

Upstream Interfaces : Gi0/16(Up)

Downstream Interfaces : Gi0/10(Up)

In the future I will use Link State Tracking, especially in blade environments. At least in blade environments with multiple switch, which don’t support some kind of stacking technology, and servers with multiple NIC’s.

MAC Authentication Bypass – Continued

Finally I had a day “off” and could test MAC Authentication Bypass (MAB) in our test environment at the office. I created the following test environment:

MAB-TEST

There are 4 different VLAN’s and a Cisco Catalyst 3750 connects the VLAN’s to each other. I wanted to create an environment with the following properties:

  • All switch ports are default member of VLAN 1;
  • Authenticated workstations become member of VLAN 25;
  • Unauthenticated workstation become member of VLAN 30;
  • VoIP phones are member of VLAN 15;
  • All workstation should be able to boot with Wake on LAN;
  • MS-IAS is used as RADIUS Authentication server;

I have configured the necessary components and got the environment working with the above properties. The next few sections cover the configuration of the different components.

Cisco Catalyst 3750

Most of the configuration is done on the Cisco Catalyst 3750 switch. First of all I created the different VLAN’s on layer 2 of the OSI model. Next I created the SVI’s to make the VLANs routable. I used the standard SVI configuration. I used the ‘quick-and-dirty’ solution for configuring Wake On LAN (WOL) by just adding the ip directed-broadcast command to the SVI’s. The snippet below shows the SVI configuration.

Interface Vlan1
ip address 192.168.1.254 255.255.255.0
ip directed-broadcast
end
!
Interface Vlan10
ip address 192.168.10.254 255.255.255.0
ip directed-broadcast
end
!
Interface Vlan15
ip address 192.168.15.254 255.255.255.0
end
!
Interface Vlan30
ip address 192.168.30.254 255.255.255.0
end

The next step is configuring AAA and the RADIUS group for authenticating the connected clients to the network. The snippet shows these configuration.

aaa new-model
aaa authentication dot1x default group radius
aaa authorization network default group radius
!
radius-server host 192.168.10.30 auth-port 1812 acct-port 1813 key ictivity

The following step is to enable 802.1x globally in the switch. You should use the command in the following snippet to enable 802.1x.

dot1x system-auth-control

The last configuration snipper shows the configuration of a switch port. This switch port is configured use MAC Authentication Bypass as backup authentication method if 802.1x cannot authenticate.

interface GigabitEthernet1/0/16
switchport mode access
switchport voice vlan 15
dot1x mac-auth-bypass
dot1x pae authenticator
dot1x port-control auto
dot1x control-direction in
dot1x timeout tx-period 1
dot1x max-reauth-req 1
dot1x guest-vlan 30
spanning-tree portfast
spanning-tree bpduguard enable

MS-IAS

I configured Internet Authentication Services on a Windows 2003 server. I didn’t configure the Active Directory, but use the local users and local groups to authenticate. I configured the RADIUS client inside IAS and started to create a Remote Access Policy. The Remote Access Policy matches a newly created Windows Group. The important aspects of the Policy are the Authentication options and the Advanced Attributes. The configuration of both is shown below.

Authentication Advanced

The last step in the whole process is configuring the Windows Group and adding users to that group. The MAC address of the workstation is acting as username and password. Important to notice is that all characters are case-sensitive and the username and password should only contain lowercase characters. An example of username and password is: 0016762eccda.

After configuring the test environment I have done some testing. First was trying to connect a workstation and authenticate. This is working perfectly, you will see a nice IAS event message on the Windows 2003 server. Next I connected an IP Phone with a build-in switch and connected the workstation to the IP Phone. The workstation again authenticates flawlessly against the RADIUS server. The last test was trying to wake up the workstation via Wake On LAN. When you should down the workstation, the switch ports first goes in shutdown and re-enables after the complete shutdown of the workstation. Next the switch ports returns to Vlan 1 (switchport access vlan 1). I send the Magic Packet to the broadcast address of VLAN 1. The workstation starts booting and authenticates against the RADIUS server.

I can only say, that MAC Authentication Bypass is working perfectly in my TEST environment. Shortly I will try to implement it on the network of one of our customers, because he wants a cheap method for securing his switch ports.

I know, and I told the customer, that MAC authentication isn’t a very powerful tool for security the switch port. Because spoofing a valid MAC address is enough to get access to the network. But MAC authentication is still better, then no authentication at all. And let’s face it, what are the costs: NOTHING!!!

Most companies have a Windows 2003 server where IAS can be installed or you can use FreeRADIUS, so no costs on the OS. I have tried an IP Base and an IP Services IOS on the Cisco Catalyst 3750, both are working perfectly. A switch has minimal an IP Base image, so no additional costs here. The only costs are made during the configuration and testing of the authentication.

Check the latest article about MAB and MDA in an IP Phone environment