We migrated a Biztalk application from Biztalk 2006R2 to Biztalk 2013:
It has a HTTP Receive location on which it receives an xml transaction from exerternal agencies by HTTPS.
We have created a Windows local user account and provided it to the external agency to pass those credentials back to us when sending the transaction to us.

On IIS, we Disabled 'anonymous' authentication and enabled 'Basic' authentication.

It works absolutely fine old server(Windows Server 2003R2/IIS 6/Biztalk2006R2)

But the same application when migrated to the new server(Windows Server 2008R2/IIS 7.5/Biztalk2013)
  fails with 401-Unauthorized error on the Recieve location
(If I enable anonymous authentication, we are able to receive the transaction from external agency. So no problem in communication, it's only an authentication error. And we can't afford to have anonymous authentication)

I checked almost all the IIS settings of Virtual directory associated with the Biztalk Receive location on both the old and new servers and they look similar.

Appreciate any inputs/suggestions on resolution of the issue. Thanks.

Does that user have permissions on the site/app folders in Windows Explorer?

Yes. to the website folder

Does it also need access to C:\Program Files (x86)\Microsoft BizTalk Server 2013\HttpReceive

which has BTSHTTPReceive.dll  to which the Virtual directory associated with Biztalk receive location is pointing to?

Yes, add  the AD user to have access to the folder:\Program Files (x86)\Microsoft BizTalk Server 2013\HttpReceive

Also make sure you make sure the user account used is member of the BizTalk Isolated Hosts group and the IIS_WPG group.

Actually it is able to authenticate if the external agency modifies the userName and Password to Base64 format. Earlier they used the plain text format(below) on Windows 2003r2 server like:

username:password

But now if they change the format like below (where they use Base64 encoded value instead of plain text and the word 'Basic' infront of it.), it works fine.

Basic dXNlcm5hbWU=:cGFzc3dvcmQ=

Why on the earlier version of Windows and IIS it accepted plain text, and why not now? Appreciate any insight into it. Thanks.

• Edited by Annee797 Thursday, July 31, 2014 1:38 PM

Actually it is able to authenticate if the external agency modifies the userName and Password to Base64 format. Earlier they used the plain text format(below) on Windows 2003r2 server like:

username:password

But now if they change the format like below (where they use Base64 encoded value instead of plain text and the word 'Basic' infront of it.), it works fine.

Basic dXNlcm5hbWU=:cGFzc3dvcmQ=

Why on the earlier version of Windows and IIS it accepted plain text, and why not now? Appreciate any insight into it. Thanks.

• Edited by Annee797 Thursday, July 31, 2014 1:38 PM

Answering to my own question after a long time..  

We initially have enabled both 'Windows' authentication as well as 'Basic' authentication when this problem was occuring. But When we disabled 'Windows' authentication and enabled only 'Basic' authentication the problem is resolved.

Notably, this behavior in Windows 2008R2 is different from that of Windows 2003R2 where both the authentications were enabled and it still worked. A result of tightening of security rules in IIS 7.5.

• Marked as answer by Annee797 20 hours 29 minutes ago

Answering to my own question after a long time..  

We initially have enabled both 'Windows' authentication as well as 'Basic' authentication when this problem was occuring. But When we disabled 'Windows' authentication and enabled only 'Basic' authentication the problem is resolved.

Notably, this behavior in Windows 2008R2 is different from that of Windows 2003R2 where both the authentications were enabled and it still worked. A result of tightening of security rules in IIS 7.5.

• Marked as answer by Annee797 Tuesday, February 24, 2015 2:59 PM

Answering to my own question after a long time..  

We initially have enabled both 'Windows' authentication as well as 'Basic' authentication when this problem was occuring. But When we disabled 'Windows' authentication and enabled only 'Basic' authentication the problem is resolved.

Notably, this behavior in Windows 2008R2 is different from that of Windows 2003R2 where both the authentications were enabled and it still worked. A result of tightening of security rules in IIS 7.5.

• Marked as answer by Annee797 Tuesday, February 24, 2015 2:59 PM