While browsing some networking related blogs, so stumbled on a nice new feature in Cisco IOS on 6200networks.com. The feature prevents multiple users from changing the configuration of a network component simultaneous. This feature, configuration mode locking, is available in two different modes:
Looking at the IOS commands, configuring configuration locked is very simple. Let’s check out the available options:
SW01(config)#configuration mode exclusive [auto | manual]
When using the keyword auto the session is automatically locked as soon as you log in to the specific network component. When using the keyword manual, you can decide when to lock the session. The lock the session manually, you use the following command:
SW01#configure terminal lock
Configuration mode locked exclusively. The lock will be cleared once you exit out of configuration mode using end/exit
The status of configuration locking can be viewed with the command:
SW01#show configuration lock
Parser Configure Lock
Owner PID : 261
User : booches
TTY : 1
Type : EXCLUSIVE
State : LOCKED
Class : EXPOSED
Count : 1
Pending Requests : 0
User debug info : configure terminal lock
This feature is very useful in environments where multiple system engineers could log in and configure the same network component.
Recently I configured another ISA 2006 server as reverse proxy to publish the Exchange 2007 OWA environment on a secure way to the internet. The customer where I configured the reverse proxy is migrating from Novell GroupWise to Microsoft Exchange.
During the migration period, the customer has specific requirements when connecting to the webmail environment from the internet. The customer is using GroupWise and OWA next to each other. He build an own log in page for webmail. The user enters this credentials, which are check against a directory with the help of LDAP. Depending on the LDAP group the user is member of, he is redirected to GroupWise webmail or OWA.
The problem was that when the client gets redirected to OWA, he had to provide his credentials a second time to log in to OWA. The customer wants to use Single Sign On, so the user credentials should be automatically posted on the OWA sign in page. The customer has the option to edit his own sign in page, so specific parameters can be added when redirecting the client to the ISA 2006 reverse proxy.
I had to figure out, which URL is posted to the ISA reverse proxy after the user credentials are entered in the web browser. I started to search the internet and different forums, but the solution wasn’t found. So there was nothing else left, than starting the good old sniffer and capture the complete process. I always use WireShark as sniffer, which is a very powerful tool. I added a filter so only the traffic to and from the ISA 2006 server is captured.
I started the sniffer, logged in on the ISA 2006 server, stopped the sniffer and started analyzing the sniffer results. After some digging I found the POST statement, which is displayed below.
Looking at the POST statements, I now knew the exact URL which is posted to the ISA 2006 server. I copied the URL to notepad, changed the username and password to another account. Copied the new URL and pasted that one in my browser and HIEHOE. After hitting enter, I don’t get any sign in page, but get directly to my webmail. So exactly as the customer wants.
The default POST URL has the following format:
https://<DNS name>/CookieAuth.dll?Logon?curl=Z2Fowa&flags=0&forcedownlevel=0& formdir=1&trusted=0&username=<username>&password=<password>