Computers, Programming, Technology, Music, Literature

if you have Integrated Windows Authentication on an Internet website

leave a comment »


When consolidating a few applications deployed across servers inside the corporate firewall (intranet) and outside the corporate firewall (internet), we made some decisions to port of few of the intranet sites to the internet web servers but still to have Windows Authentication enabled. This was done for maintainability reasons.

Later some time an email that came from the IT team read as below: I am posting the content verbatim and it did seem to make sense.

Do you know if your applications are using windows authentication or if it can be disabled.


NTLM authentication is enabled on the Microsoft IIS Web server. This allows a remote user to perform account brute force by requesting a non existing HTTP resource or an existing HTTP resource that does not actually require authentication. Requests would include the “Authorization:

NTLM” field.


An attacker can attempt brute force attacks against known Windows logins, including the Administrator Account, which could potentially lead to the system being compromised. Windows also has a few easy-to-guess default names for built-in accounts: “Administrator” for administering the computer/domain, “Guest” for guest access, IUSR_<MachineName> for anonymous access to IIS, and IWAM_<Machinename> for IIS to start out of process applications. Here the machine name <Machinename> may be obtained via Windows UDP Netbios NS (port 137). If the host has an account lockout policy in place, a remote user may exploit this vulnerability to lockout a local user, provided that the name of the local user is known. The account lockout policy does not apply to the administrator account. So if the host uses a default name of “Administrator” for the administrator account, the password brute force of this account is possible through the IIS authentication interface. If the host does not have an account lockout policy in place, a remote user may exploit this vulnerability to brute force user passwords. In addition, if the request has the NTLMSSP_REQUEST_TARGET flag on, the Web server may respond to the request with an NTLM challenge that contains sensitive host information, such as the Windows server and domain in which the authentication will be checked.


Currently there are no vendor supplied patches available for this issue.


1) Disable NTLM authentication for your Web server. This can be done by unchecking “Integrated Windows Authentication” within “Authentication

Method” under “Directory Security” in “Default Web Site Properties”.

Scan Results page 6

If NTLM cannot be disabled, an alternative remediation option for this issue is to perform the following 2 actions:

1) Ensure an Account Lockout Policy is in place.

2) Ensure the Administrator Account has been renamed to something more unique.

A Lockout Policy will ensure an attacker does not have an unlimited amount of time and attempts to guess the password.



Using Windows Authentication on an Internet website – Is it’s safe? Well, the answer really depends what the word safe means to you. I will leave the decisions to you. Weigh the pros and cons. Analyze.

With NTLM, or Kerberos enabled for Windows Authentication on IIS, the passwords are never really sent as clear text. In fact the passwords are not sent, but just the hash of the credentials are. Typical argument is well explained in the blog –,guid,d6bb26b9-8371-40f1-a357-ab9023df86ad.aspx. Read it to entirety. But the gist is below.



In general:

  • Whether the site is in the Intranet security zone determines whether IE attempts to automatically authenticate when prompted by the server.
  • Whether the site is in the Internet security zone determines whether IE attempts to use Kerberos authentication (Kerberos authentication requires the client machine to be able to contact the KDC to get TGTs etc, and generally this isn’t possible in an Internet setting, so IE uses NTLM instead).
  • Whether your user is logged on to the domain or not, on their workstation, is irrelevant to determining the authentication mechanism used, or how IE sends credentials to the server.

If the site is placed into the local Intranet security zone -and- Internet Explorer is still in its default configuration (if you go to Tools -> Internet Options -> Security -> Custom settings for Intranet zone, there is an option “automatic logon only in Intranet zone”), then Internet Explorer will attempt to log you on using your current logged on credentials when the web server sends back its 401 response (IE will attempt an anonymous request first no matter what the configuration, then the server will send back a 401, then IE will attempt to auto-logon). If the credentials IE sends automatically are not accepted by the server (the server sends back another 401), then IE will prompt you to supply alternate credentials.





Written by gmaran23

March 13, 2013 at 6:57 pm

Posted in .Net, security, Windows

Tagged with , ,

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: