HTTP/1.1 401 Unauthorized

Problem:

Here is the Problem. Support Team builds new Exchange 2000 server into existing environment. Support team moves all the users from working exchange server, to the new exchange server. After move is complete support team notices one can get to OWA, however outlook works fine. Support team opens a case with upper tier for resolution of this problem.

General information about the environment:

This organization is fairly huge; the mail comes from outside passes trough clustered ISA servers in DMZ.ISA servers host the host name for the URL, ISA accepts the traffic and passes the traffic to the inside network, trough Second PIX. The request comes to Content Switch (CSS). CSS has two OWA road balanced servers. Each server has two NICs build in them. One NIC is dedicated for OWA traffic only, for traceability reasons. Each time an Exchange server gets added to the SMTP domain, the IP address of the exchange server needs to be added into the dedicated NIC, as persistent route. There are simple batch files build for this purpose as follows, for convenience purpose, these batch files are being used.

 

Route add 192.168.1.56 MASK 255.255.255.255 192.168.1.6 –p

If there is route needs to be deleted, there is another batch file available

Route delete 192.168.56.52

After content switch passes the traffic to the OWA server, below window appears. Note that this company is not using form base authentication for OWA. User inputs the valid user name and the password along with correct DOMAIN name followed with back slash, windows pops right back, and user repeats this process two more times, and sees the following message on the browser

"HTTP/1.1 401 Unauthorized"

Trouble shooting:

Upper tier logs on to the OWA servers, and opens the browser. First thing they do is, type the hostname of the internal mail server into the browser along with /Exchange

Http://mailboxserver/Exchange

They use valid user name and password and verify the user is not able to log in. Support team logs in to the mailbox server and checks all the IIS, Exchange related virtual directories, permissions and fins several permissions problems and correct all of them one by one. After they make sure all permissions look good they go back and try to log in on more time, and successfully get to user mailbox suiting on this mailbox server, by using the internal server host name /Exchange. Now support team goes back to one of the OWA servers, and logs into the FE (OWA) server, and tries to log I as the same user into the OWA. The FE servers should be able to locate the user mailbox servers and well as the Authentication server (DC). The user name and password by this way would be validated against Active Directory NTDS.DIT database and if the credential fine user would see its mailbox.

While this test is being performed the support team opens DOS command and type the following string

Netstat –n 1 |Find "192.168.49.100"

Those of you who know UNIX will now this command. Rest will find very exciting and useful. Netstat –n is displays addresses and port numbers in numerical form. The number1 is to tell the DOS refresh the window every one second. Pipe is to connect the following command, Find"X.X.X.X" IP address if there is any port connection opens. These are the ports we expect to see connection on Port (DSAccess) 389 and 3268. After issuing the following command (Netstat –n 1 |Find "192.168.49.100") support team attempt to log in as user, and there is no authentication happened on the OWA servers. Obviously the OWA servers don't even bother to talk to the Domain Controller for the mailbox server. Support team opens another CMD window, and telnet into the Domain controller local Exchange server configured to talk too. Soon enough the Netstat –n windows start showing connection on both ports 389 and 3268.

Support team goes back to First Exchange server and finds out the DNS IP addresses, and they found out the server Primary address is configured for ISP DNS IP addresses( such as surprise (-: ). They take the ISP DNS server from DNS list and only add internal DC/GC IP address there. They go back and make the corrections on the new Exchange server. They use following commands

IPconfig /FlushDNS

IPconfig /RegisterDNS

NbtStat –RR

Restart netlogon service on both servers( DC and the exchange server)

After time for replication completes, user are able to login trough corporate OWA link.

Best Regards

Oz Ozugurlu