In this article, you will get a quick overview about how to setup Microsoft's Internet Information Services and then you can read on to a more thorough introduction to the authentication models IIS and other Web servers provide.
After configuring IIS correctly, you will be able to access your Web site from any device in your network, e.g. from an Apple Macintosh or a Linux box by using your IIS hostname. This article was last updated in September 2013.
1.) Install the server on your Windows7 machine by selecting it from
add/remove programs -> add/deactivate Windows features
2.) Setting up your Web site should be quite easy. Just delete the default one in IIS and add your own site, pointing to some local folder containing a typical Web server file, e.g. an index.html.
3.) Authentification: Set this to anonymous to get IIS7 running.
4.) ACL/NTLM Auth: Add the user IIS_IUSRS with read permissions to the permissions of the folder containing your index.html. You can add this user directly inside Internet Information Services or inside the folder itself via Explorer.
5.) Open the Windows Firewall (Basic) and activate the checkbox www-services (http) to allow communication of IIS through the firewall.
Now you can use your server's NetBios hostname on any client Web Browser, e.g. http://yellowOstrich and it will display your webpage, which brings us to our next subject, hostname resolution in your network.
If you want to host a Web site on your Intranet and access it by your server's hostname, but you don't have any Domain Name Service installed, you can make use of Netbios to let other clients in your network resolve your server's IP address.
Let's keep saying yellowOstrich is the hostname of your Microsoft Operating System running IIS. A proper router should resolve requests of your clients to your Windows OS which in return answers with the Netbios Name by employing either local cache lookup, WINS server query, broadcast, DNS server query, or a file lookup in Lmhosts or the Hosts file.
You can issue this command in Windows command line interface to display the names that were registered locally:
Or in order to display the name cache holding the names of other computers in your network, issue a
I know it sounds unreal, but Microsoft provides something like a real-time network sniffer:
netstat -n -o
Generally the host name of a Windows computer is based on the NetBIOS name. The Primary DNS Suffix may be added, but in a SoHo Local Area Network it can very well be, that one does not have a DNS running. Subsequently Windows won't add a DNS Suffix to your hostname, resulting in your FQDN (Full Qualified Domain Name) be just yellowOstrich instead of something like yellowOstrich.zoo . It should be mentioned, if you don't use a DNS and you happen to employ IPv6, Windows will use LLMNR, Link Local Multicast Name Resolution in preference to NetBios.
MacOSX also uses your Mac's individual name that you have given it when booting up the first time as NetBIOS name. You find it under the WINS Tab at
System Settings -> Additional Options -> Network.
Setting up Security
To add Security to your IIS configuration, you first must know the up- and downsides of your options. You could use methods like Digest, Kerberos, Forms over Basic or SSL Auth.
You can use Digest Authentication with any HTTP 1.1 enabled browser. Broken down, this works by the browser sending an anonymous request to the server which returns with the status code 401 - Unauthorized.
Then the browser requests a nounce , which is a unique value generated for this challenge only. The client then asks the user for his credentials and constructs out of them a MD5 Hash. This is then send to Microsoft's IIS which must have your credentials as well and can create its own MD5 Hash to verify your clients MD5 hash and grant your browser access to the website or other services via a token.
So in essence there is no possibility to read your password over the network stream. However Digest Authentication is prone to man-in-the-middle attacks, since your client does not have the means to verify that the server is he who he claims to be, and vice versa. A successful attacker would pretend to be the server or the client with intercepted nounces.
This form of authentication is a platform-independent standard and was developed by Netscape, Microsoft, VeriSign and others in the RFC 2617 in 1999.
Negotiate / Kerberos
Cross-platform as well, the Negotiate Protocol automatically chooses Kerberos, given you are in a domain, but if not, it chooses NTLM, the integrated Windows Authentication, at least last time I checked.
Kerberos needs a DNS with an working Active Directory server or alternatives and a Ticket Granting Server, so chances are your operating system will use NTLM if you are on a SoHo network with no mention-worthy network infrastructure.
The login method can use a form to authenticate users by asking for their credentials. Unfortunately, this would happen in clear-text Basic authentication, readable by everyone listening on your network traffic.
In conclusion it clearly is better using the Secure Socket Layer (SSL) together with Forms authentication.
SSL/TLS establishes a something like a secure transmission tunnel for the data which cannot be intercepted by third parties, even should they have gained access to your LAN/WLAN. For SSL to work, you must issue yourself a certificate or get one from a Trusted Root Certificate Authority (CA). This will let clients and your IIS (or more popular Web servers for that matter) identify each other. This way, you would make man-in-the-middle attacks much harder. For further reading about this topic, especially in the light of PRISM and other questionable wire-tapping schemes, let me suggest Steve Gibson's Web site post about Fingerprints. That Web site and its author can safely be considered as generally excellent.
So, to come to an end of this write-up about connectivity and security of IIS and other web servers, in my opintion SSL/TLS in conjunction with Kerberos can be considered an adequate solution for hardening your network security. But since this is 2013 and there is no denying anymore that all of globally interconnected networks are being mass-surveilled by corrupt and legitimate governments alike, Pretty Forward Secrecy might spark your interest.
PFS works by issuing temporary certificate for each session, neither a leaked private- nor a leaked root certificate could be used by an attacker to decrypt all of the network traffic of the domain that uses these certs. Only the specific conversations, for which a temporary certificate was issued would be decypherable, given that the temporary certifacte gets known to the attacker. If you want to know more about PFS, let me direct you to this Reddit thread about Diffie-Hellman key exchange with the help of elliptic curve cryptography.
I hope you enjoyed this blog post, why not take part in the conversation in the comment section below. Have a nice day anyhow and thanks for reading.