Cisco WLC – HA SSO upgrade

“Is the upgrade procedure for a high-availability pair of Cisco Wireless LAN Controllers the same as the procedure for a single Cisco WLC?” Several customers asked me this questions and the answer is YES.

First you check the current and backup firmware image.

(Cisco Controller) >show boot
Primary Boot Image…………………………. 8.2.111.0 (default) (active)
Backup Boot Image………………………….. 8.1.102.0

Next you check if your SSO configuration is working as expected.

(Cisco Controller) >show redundancy summary
Redundancy Mode = SSO ENABLED
Local State = ACTIVE
Peer State = STANDBY HOT
Unit = Primary
Unit ID = 00:81:C4:87:3B:C9
Redundancy State = SSO
Mobility MAC = 00:81:C4:87:3B:C9
BulkSync Status = Complete
Average Redundancy Peer Reachability Latency = 177 Micro Seconds
Average Management Gateway Reachability Latency = 935 Micro Seconds

Upload the new firmware to the controller by using an TFTP or FTP server. I am using an TFTP server in this example.

(Cisco Controller) >transfer download datatype code
(Cisco Controller) >transfer download filename AIR-CT5520-K9-8-2-141-0.aes
(Cisco Controller) >transfer download path .
(Cisco Controller) >transfer download serverip 10.200.8.83
(Cisco Controller) >transfer download mode tftp
(Cisco Controller) >transfer download start

After the TFTP session is finished you’ll notice that the the software is automatically transferred from the active to the standby unit.

TFTP Code transfer starting.

TFTP receive complete… extracting components.

Checking Version Built.

Image version check passed.

Informing the standby to start the transfer download process

Waiting for the Transfer & Validation result from Standby.

Standby – Standby receive complete… extracting components.

Standby – Image version check passed.

Transfer & validation on Standby success, proceed to Flash write on Active.

Writing new AP Image Bundle to flash disk.

Executing fini script.

File transfer is successful.
Reboot the controller for update to complete.
Optionally, pre-download the image to APs before rebooting to reduce network downtime.

Transfer Download complete on Active & Standby

The last step is to reload both controllers to activate the firmware. After you reboot the active controller, you are able to access the standby controller and reboot that controller too. You have the option to reboot both controllers with one command.

(Cisco Controller) >reset system both in 00:05:00 image no-swap reset-aps

The controller also has the option to pre download the firmware from the controller to the access-points. This speeds up the upgrade process for the access-points, because the access-point don’t need to download the firmware after the controllers are online again. The access-point only need to reboot when the loose the connection with the controller. I will describe this process in a separate post.

After the controllers are back online, you should check the primary and backup boot firmware to see if the upgrade was successful.

(Cisco Controller) >show boot
Primary Boot Image…………………………. 8.2.141.0 (default)
Backup Boot Image………………………….. 8.2.111.0 (active)

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.