Connecting the world…

in

Automatic Log In Reverse Proxy with FBA

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.

POST-STATEMENT

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>
&SubmitCreds=Log+On

Troubleshooting EIGRP

To troubleshoot EIGRP you should obvious have a grasp understanding of the specific routing protocol. Of course this doesn’t only apply to the EIGRP routing protocol.

Troubleshooting the EIGRP routing protocol on a Cisco devices is mainly about logging the correct information to a syslog server, the buffer or the console and know what the output of several show commands mean.

Neighbor instability on a router has mostly one of the following reasons:

  • Holding time expired;
  • Retry limit exceeded;
  • Manual changes like route filter changes;
  • Unidirectional links;
  • Primary / secondary IP address mismatch (EIGRP uses the primary IP address);
  • Routes get Stuck-in-Active aka SIA (“Active” means recovering from a change in the network, for example flapping links). Routes can get SIA by the following reasons: bad or congested links, query range is “too long”, excessive redundancy, overloaded router, router memory shortage and so one;

Many problems with EIGRP appear when using external routes, like redistributing a routing protocol like OSPF into EIGRP. The most common cause of this problem is the absence of setting the metrics. Important when using the redistribute command is specifying the metrics with the default-metric <metric> or redistribute <protocol> metric <metric> command.

Black Hole Summary Routing is also a common problem when using EIGRP. Black Hole Summary Routing is caused when manual summary routes are configured.

BHR

The picture shows a case of Black Hole Routing. Routers A and B summary the different /24 networks as one /16 network to router X. Suddenly the link between router A and router C gets lost. Because we used summarization between router A and router X, router X isn’t aware of the lost link, so router X keeps sending traffic for network 10.1.1.0/24 to router A and router B ((un)equal cost load-balancing). All traffic send to router A would get lost in the process.

A solution to this problem is connecting routers A and B by using a physical link or creating a GRE tunnel between both, if the physical links isn’t possible.

As mentioned before, troubleshooting the routing protocol can be done by using the correct show, logging and debug commands. Important commands for troubleshooting EIGRP are:

  • show ip eigrp neighbors: for checking neighbors, hold timers, uptime, Smooth Round Trip Timer (SRTT) and Retransmit Time Out (RTO);
  • show ip eigrp topology active: used for noticing if route is SIA;
  • show ip eigrp events: check what EIGRP events are going on;
  • RTR(config-router)#eigrp-log-neighbor-changes;
  • RTR(config-router)#logging buffered <size>;
  • debug eigrp packet hello: showing the processing of hello packets;
  • debug eigrp packet terse: shows all EIGRP packet debugging except hellos;
  • debug ip eigrp notifications: troubleshooting redistribution by showing what happens between EIGRP and the routing table as routes are redistributed;

Troubleshooting a routing protocol can only be done if you know what the protocol is actually doing. When troubleshooting it is necessary to know the correct way to troubleshoot and start exempting possibilities for the routing problems. Exempting possibilities narrows the scope, which can result in finding the actual problem.