Network Administration

Microsoft Eschews Patch, Gives Exploit Code for IIS 5.0 Bug

2007-06-07T07:48:37Z

Saying that an Internet Information Server exploit is due to a feature, not a flaw, Microsoft has published exploit code for the flaw but no workaround or patch.

]]> The exploit, which was discovered on Dec. 15, 2006, and made public at the end of May, works against IIS 5.x. By design, versions 5.x allow bypass of basic authentication by using the "hit highlight" feature. The hit-highlighting feature can be used by an unauthorized user to grab documents to which he or she has no privileges.

At the very least, this leaves IIS 5.x users vulnerable to data interception. And while the exploit hasn't been used to take over systems to date, that could well change, according to Swa Frantzen of the Internet Storm Center.

The ability to execute code is "unexplored, but hinted about," Frantzen wrote in a blog post on SANS' Internet Storm Center security alert site.

The ISC has tracked public exploits that apparently focus on leaking protected information.

According to Microsoft, which has written up the issue in its Knowledge Base article 328832, hit-highlighting with Webhits.dll only relies on the Microsoft Windows NT ACL (Access Control List) configuration on 5.x versions.

Microsoft "strongly [recommends] that all users upgrade to IIS (Internet Information Services) version 6.0 running on Microsoft Windows Server 2003. IIS 6.0 significantly increases Web infrastructure security," the company wrote in its KB article.

Microsoft is currently shipping IIS 6.0 of the Internet Information Services Server for Windows Server 2003. Microsoft is up to IIS 7.0 for Windows Vista and IIS 5.1 for Windows XP Professional.

What are the security issues with Microsoft's "Surface"?

Yet, in spite of urging upgrading in order to gain improved security, Microsoft is treating the bug as a nonissue, providing no workaround nor indications that it will patch versions 5.0 and 5.1. "This behavior is by design," the KB article asserts.

Rather than supply a patch or workaround, Microsoft published six steps to reproduce the exploit—a response that is "a bit atypical," according to Frantzen. "Microsoft is telling the world how to exploit their products being used by their customers. Not that the worst of those interested in it did not already know, but the one thing we need from Microsoft is not the exploit, but the patch or at least a decent work-around," Frantzen wrote.

The only defensive information Microsoft gives is to urge users to upgrade to 6.0—an upgrade that's neither free nor easy, Frantzen pointed out. He provided these possible workarounds:

If you don't use the Web hits functionality, a simple workaround would be to remove the script mapping for .htw files. Without a script mapping, IIS should treat the file as static content.

Try to use application-level firewalls (filters). If you have the infrastructure it can be a temporary measure till you can upgrade IIS, solving the actual problem.

URLScan, a URL filter by Microsoft can be used to stop access to .htw files and is reported by some SANS-ISC readers as being effective.

Manage rights on the confidential files or directories themselves.

Upgrade to Apache or another Web server, with or without a (cross) upgrade of the OS.

Scramble an upgrade to Windows 2003, potentially on more potent hardware.

Frantzen advised IIS 5.x users that failing to find "null.htw" in a document root directory doesn't mean much—the exploit doesn't need the file.

Microsoft hadn't delivered a statement by the time this story posted.

Source: Lisa Vaas - eWEEK

Active Directory: Questions and Answers

2006-11-28T20:49:39Z

What is the difference between Windows 2000 Active Directory and Windows 2003 Active Directory? Is there any difference in 2000 Group Polices and 2003 Group Polices? What is meant by ADS and ADS services in Windows 2003?

Windows 2003 Active Directory introduced a number of new security features, as well as convenience features such as the ability to rename a domain controller and even an entire domain – see Microsoft's website for more details.

Windows Server 2003 also introduced numerous changes to the default settings that can be affected by Group Policy – you can see a detailed list of each available setting and which OS is required to support it by downloading the Group Policy Settings Reference.

ADS stands for Automated Deployment Services, and is used to quickly roll out identically-configured servers in large-scale enterprise environments. You can get more information from the ADS homepage.

]]> The benefits of AD over NT4 directory services

Active Directory marked a shift in the way that Microsoft manages directory services, moving from the flat and fairly restrictive namespaces used by NT4 domains and moving to an actual hierarchical directory structure. There's a sample chapter from the Windows 2000 technical reference available here that will give you a good introduction into the major differences between the NT4 and Active Directory directory services.

I want to setup a DNS server and Active Directory domain. What do I do first? If I install the DNS service first and name the zone 'name.org' can I name the AD domain 'name.org' too?

Not only can you have a DNS zone and an Active Directory domain with the same name, it's actually the preferred way to go if at all possible. You can install and configure DNS before installing Active Directory, or you can allow the Active Directory Installation Wizard (dcpromo) itself install DNS on your server in the background.

What is the best way to migrate Exchange 2000 mailboxes to Exchange 2003?

The nice folks at MSExchange.org have put together a pretty detailed tutorial on how to migrate from Exchange 2000 to Exchange 2003 on new hardware. The MSExchange site also hosts online forums that are frequented by Exchange MVPs who can help you with any specific errors that you run into along the way.

How do I design two Active Directory domains in a client network?

For Windows Server 2003, your best bet is going to be the Deployment Kit. The section on "Deploying Network Services" will assist you in designing and installing your DNS servers, and the section on "Designing and Deploying Directory and Security Services" will assist you with deploying Active Directory and configuring trust relationships.

What is difference between ADS and domain controller?

ADS is the Automated Deployment Service, which is used to quickly image, deploy, and administer servers and domain controllers on a large scale. You can find more information at the ADS Technology Center.

How can I modify the path of all my users' home directory within Active Directory using a vbs logon script?

Check out the source code from Robbie Allen's "Active Directory Cookbook". Recipe 6.4 shows you how to modify a property value for multiple users. Essentially, you select a container such as an OU or a domain and then use a FOR loop to loop through each user object in that container.

How do I determine if user accounts have local administrative access?

You can use the net localgroup administrators command on each workstation (probably in a login script so that it records its information to a central file for later review). This command will enumerate the members of the Administrators group on each machine you run it on. Alternately, you can use the Restricted Groups feature of Group Policy to restrict the membership of Administrators to only those users you want to belong.

Why am I having trouble printing with XP domain users?

In most cases, the inability to print or access resources in situations like this one will boil down to an issue with name resolution, either DNS or WINS/NetBIOS. Be sure that your Windows XP clients' wireless connections are configured with the correct DNS and WINS name servers, as well as with the appropriate NetBIOS over TCP/IP settings. Compare your wireless settings to your wired LAN settings and look for any discrepancies that may indicate where the functional difference may lie.

I am upgrading from NT to 2003. The only things that are NT are the PDC and BDCs; everything else is 2000 or 2003 member servers. My question is, when I upgrade my NT domain controllers to 2003, will I need to do anything else to my Windows 2000/2003 member servers that were in the NT domain?

Your existing member servers, regardless of operating system, will simply become member servers in your upgraded AD domain. If you will be using Organizational Units and Group Policy (and I hope you are), you'll probably want to move them to a specific OU for administration and policy application, since they'll be in the default "Computers" container immediately following the upgrade.

How do I use Registry keys to remove a user from a group?

In Windows Server 2003, you can use the dsmod command-line utility with the -delmbr switch to remove a group member from the command line. You should also look into the freeware utilities available from www.joeware.net . ADFind and ADMod are indispensable tools in my arsenal when it comes to searching and modifying Active Directory.

Why are my NT4 clients failing to connect to the Windows 2000 domain?

Since NT4 relies on NetBIOS for name resolution, verify that your WINS server (you do have a WINS server running, yes?) contains the records that you expect for the 2000 domain controller, and that your clients have the correct address configured for the WINS server.

Four steps to secured VoIP

2006-11-21T00:15:22Z

Securing Voice over IP (VoIP) doesn't have to be a challenge for small and medium-sized businesses (SMBs).

VoIP is basically a phone call over the Internet. It offers the same promises - and pitfalls - as the Internet. The promises are cheap and easy communication over a readily available and easy-to-use public network - the Internet. The pitfalls are the same security weaknesses of that network, which wasn't originally designed for security - or phone calls, for that matter.

]]> But it's not as scary as it seems for cash-strapped SMBs with limited IT staffs. Most of the tuning required to secure VoIP involves the same efforts as hardening Internet and Web connections your company probably already has in place. And most of that work can be handled by your existing network staff, even without a dedicated information security department.

Even if your SMB doesn't host its own Web site or Internet service, like a larger enterprise, it still has connections to the Internet through conventional routers. Handling VoIP for them should be a snap.

Security comes first

Before delving into the four best practices for securing VoIP and how to apply them to SMBs, be aware of the overall security issues around VoIP.

There are three major security concerns around VoIP, and they're the same security issues as those for IP traffic, in general. The three issues are:

1. Lack of authentication.
2. Spoofing, and exposure of unencrypted data.
3. Unwanted traffic similar to email spam, which in the VoIP world is called SPIT, or spam over Internet telephony.

VoIP can also serve as an entry point into your company, just like any other Internet connection, for viruses, spyware and malware. But this isn't a specific problem of VoIP. Denial-of-service (DoS) attacks are also possible via VoIP but, again, this is a general IP protocol issue and not just a VoIP concern.

IP traffic isn't authenticated. It moves freely over the Internet and can come from anywhere. This is a problem inherent in the TCP/IP protocol. For VoIP, it means a malicious user could fake, or spoof, your company's IP address and appear on the caller ID of an unsuspecting customer. This tactic is known as VoIP phishing, which, like its email counterpart, is meant to entice customers to give up confidential account information over the phone to thieves posing as your company employees.

IP traffic moves in the clear by default. It can be easily picked up by conventional packet sniffers like Wireshark (formerly Ethereal), dsniff, Ettercap and their ilk. Any conversations on your new shiny VoIP phones can be eavesdropped by sniffing unencrypted traffic traveling over the Internet. Unlike regular phone lines, which require some effort to tap through the phone company, VoIP can potentially expose your SMB to the whole world just by being on the Internet.

And, just as spam is delivered via email, junk voicemail messages can be pumped into your company through VoIP, clogging your SMB's phones with SPIT. This is in addition to a DoS attack against your company, just like any other from the Internet, through your VoIP connection.

So, what's an SMB to do to protect itself from the dangers of VoIP? Here are four suggestions:

1. First, run all your VoIP traffic through a separate Internet connection and separate voice and data traffic into their own network segments. Use a VLAN to separate voice and data. This can prevent an attack via the data stream from the Internet leaking into your voice system, using your VoIP network to attack your primary network. Set up separate servers dedicated just to VoIP traffic and firewall them apart from the rest of your network. For VoIP connections between different buildings, use a virtual private network (VPN) to authenticate users to prevent spoofing.

2. Second, avoid cheap VoIP systems that can be installed on an ordinary desktop or workstation. As tempting as it might be to a cost-conscious SMB, these systems are highly insecure since they can be easily compromised and used as a back door into your network. Go for a real VoIP system from a major provider like Vonage Holdings Corp. or Avaya Inc., which integrates with your existing routers and can be handled by your existing network staff.

3. Third, encrypt any VoIP traffic to keep it confidential and prevent eavesdropping by network sniffers. VoIP encryption is getting better but it can just as easily be set at the router or gateway level and then tunneled through IPSec. This should put less of a strain on your SMB staff members, who may already be setting up these types of connections for your VPN.

4. Lastly, put VoIP servers in a secure physical location, as you would for your other networking equipment. Ideally, if space permits, the equipment should be in its own equipment room separate from that other networking equipment.

Like the rest of your network servers, baseline security controls should be in place for your VoIP system. Here's how:

* Make sure all routers and servers hosting your VoIP system have been hardened and all unnecessary services turned off and ports closed.
* Restrict access to VoIP servers to only system administrators and log and monitor all access.
* Use intrusion detection systems to monitor malicious attempts to access your VoIP network.
* Employ a defense-in-depth of strategy with multiple layers of security, including dedicated VoIP-ready firewalls.

Implementing VoIP is not as scary, or as much of a burden, as it seems. Most of the tasks for securing VoIP can be handled by your existing IT staff, since it is already integrated into your network.

Define server roles, counterattack zero-day threats

2006-11-18T18:01:26Z

Zero-day exploits are an unsettling issue for any administrator who is concerned with security. A zero-day exploit is an exploit against a previously undiscovered and undocumented vulnerability. The problem with zero-day exploits is that you are trying to protect the system against security holes that may or may not even exist. This means that you can't just apply a security patch to prevent the vulnerability from being exploited, because no one except for the hacker who exploits the vulnerability knows about it.

]]> While you can't usually rely on patching as a mechanism for protecting you from zero-day exploits, there are some things you can do to harden your server and make your system far less susceptible to these types of attacks.

By far the most effective countermeasure against a zero-day exploit is to reduce the attack surface on your systems. Imagine a hacker launching a zero-day exploit against a previously undiscovered security hole in Internet Information Server (IIS). Depending on the nature of the vulnerability, such an attack could be catastrophic if IIS is installed.

That's why it's a good security practice to take a role-based approach in regards to your servers. Try specifically defining the tasks that each server on your network is required to perform. By doing so, you can easily determine which system components are and are not required in order to perform the necessary tasks. For example, if a server is acting solely as a file server, then there is no reason why it would need to run components like IIS or the Print Spooler service.

It is best to configure each server so it performs only a single task. That way, you not only reduce the server's attack surface, but you also make it far easier to determine which system components are required in order for the server to do its job.

More on zero-day threats
Harden your network services and contain zero-day threats
Eliminate zero-day threats with virtual server technology

Harden your network services and contain zero-day threats

2006-11-18T17:58:17Z

We all dread the thought of zero-day threats; they arrive and you have no vaccine for them. These exploits are all too common in recent months and years. Fortunately, there are some common sense steps you can take to harden your network layer against these threats.

]]> You may not know exactly what the exploit is, but you can certainly deploy some protective elements like these that might stop such a problem in its tracks:

Use virtual LANs (VLANs), if possible, to segregate some areas of your network.
VLANs are essentially multiple logical boundaries created within one physical network. VLANs are an easy way to divide critical areas of your network from others. For instance, you could have one VLAN for servers and another for client machines, or you could segregate machines based on department, or any other scheme you choose. Creating a VLAN in and of itself doesn't necessarily create a layer of protection, but it forms the basis for any number of other hardening techniques, and it provides a way to limit the scope of more stringent security procedures to only the most critical areas of a network.

Implement Internet Protocol Security (IPsec) to protect the contents of individual transmissions.
IPsec encapsulates communications in a layer of encryption that is difficult to break, but it also allows you to restrict communications to and from certain machines based on whether their machine certificates are signed and valid. By doing this, the machines restricted by IPsec would simply ignore it, even if an exploit was introduced into your network. Using IPsec in this way also forms the basis for using network access control, covered later in this list.

Deploy an intrusion detection system (IDS).
Intrusion detection systems often use heuristics that can detect malicious activity on your network before an actual definition is created by antivirus and anti-malware vendors. IDSes also provide a foundation for forensic analysis in case you care to examine how an exploit entered your network (should one actually penetrate your defenses).

Employ perimeter protection, like a stateful firewall.
This almost goes without saying (which is why I put it midway through the list), but perimeter defense is the first, best and most effective way to protect against zero-day exploits in a variety of forms. To help prevent your network from being a vector of delivery for a nasty vulnerability, deploy a firewall immediately. Better yet, deploy a better firewall than the one you have now, and perform regular audits of that firewall if you aren't doing audits already.

Introduce network access control to prevent rogue machines from gaining access to the wire.
One of the easiest and arguably most prevalent ways for nefarious software or Internet users to creep onto your network is not through holes in your firewall, nor brute-force password attacks nor anything else that might occur at your corporate headquarters or campus. It's through your mobile users -- when they try to connect to your business network while on the road and through visitors on your campus trying to attach themselves to your network. Neither of these categories of machines are subject to your (hopefully) stringent security policies, and that's a problem. Network access control products, like Cisco's NAC, NAQC in Windows Server 2003 and the possible inclusion of network access point (NAP) in the upcoming Longhorn Server are all good ways to close this attack vector.

Lock down wireless access points and use a security scheme like Wi-Fi Protected Access or WPA2 for maximum protection against wireless-based attacks.
Simply using media access control (MAC) filtering and not broadcasting your service set identifier (SSID) are methods that just don't cut it anymore in a corporate setting. WEP has been cracked numerous times and even the most junior cracker will have no trouble gaining access to your wireless network protected only by WEP. Look into WPA2 to really filter out the bad guys.

Eliminate zero-day threats with virtual server technology

2006-11-18T17:54:30Z

One solution when fighting zero-day attacks is to take advantage of virtual server technology. If you have several server roles that require a minimal amount of system resources, you could consolidate those roles onto a single physical server that is hosting multiple virtual servers. Doing so provides better security than hosting all of the server roles under a common operating system (OS) because each virtual OS functions as an isolated environment.

]]> Using virtual servers is also more cost effective than using separate physical boxes for each server. Not only do you save money on hardware, but you also save on licenses: Windows Server 2003 R2 is licensed to run up to four virtual instances of Windows Server on each physical server.

Whether you choose to use physical or virtual servers, the real trick is to figure out exactly which components you do and do not need on each server. Only then can you remove unnecessary components and disable unnecessary services. (Disabling unnecessary services and uninstalling unnecessary components also tends to increase the server's performance.)

Fortunately, it's not as difficult as it sounds. Microsoft has created a document called the Windows Server 2003 Security Guide, which helps you figure out which components are necessary for your situation. The guide takes a role-based approach to server security and discusses at length which components are required for servers acting in various roles. You can access the Windows security guide on Microsoft's TechNet site.

Although the Windows Server 2003 Security Guide is a rather extensive document, it does not cover every possible scenario. The good news is that Microsoft has published similar guides pertaining to most of its server products. For example, suppose that one of the servers in your organization is running Exchange Server 2003. The Windows Server 2003 Security Guide does not address the procedure for hardening an Exchange Server. It does, however, contain a baseline procedure for hardening a member server. You can use the baseline policy as a starting point and then refer to the Microsoft Exchange Server 2003 Security Hardening Guide for specific Exchange Server requirements.

I can't provide the links for all of the security guides -- there are just too many of them. But, you can easily find any of these guides by performing a simple query using the product name and the words SECURITY GUIDE in either Google or directly on the Microsoft Web site.

The most effective countermeasure against zero-day exploits involves reducing the attack surface of the computer that you are trying to protect. Keep in mind that you should always exercise security in depth. In other words, don't depend solely on a limited attack surface to protect you against a zero-day exploit. Adhere to standard security best practices, such as keeping systems patched, keeping antivirus software up to date, using strong passwords and working with the lowest possible user privileges.

Permitting Ping: ICMP Exceptions

2006-11-16T18:42:13Z

When Windows Firewall first appeared in XP SP2, I started getting odd questions on email. They all went something like, "Hey, something's weird on my system now that I'm running SP2. I've got two computers, A and B. A can ping B, but B can't ping A. What's going on?" What was going on was that system A was running XP SP2 with Windows Firewall enabled by default, and system B was a Windows 2000 system without any firewalls.

]]> When A pinged B, then the firewall on A said, "Ah, we're pinging B; when the response comes back, I'll let it through," but when A pings B, then B says "Auugh! An unsolicited transmission! No doubt it's some blackguard worm, I'd better block it!"

Ping's the most basic troubleshooting tool in many a networker's arsenal, and it's a pain to try to do network troubleshooting in a network that's blocked all pings, as I discussed back in the DEP chapter. But pings are useful to more than folks trying to troubleshoot; several network protocols need ping to operate correctly. For example, part of group policy processing on a client needs an answer to the question, "Am I dialed up or directly connected via a high-speed network to my domain controller?" If the client's dialed up, then the client skips software installation (installing Word over a 56 Kbps connection wouldn't be fun), folder redirection (ditto), and login scripts. But how to know whether a system's dialed up or LAN-connected? Well, believe it or not, your system pings the domain controller, times how long it takes for the response, and guesses the connection speed from there. Of course, a DC with a ping-ignoring firewall in place never responds, and so every system in the network thinks it's dialed up, and that's not good, so let's see how to allow ICMP messages through WF.

Allowing Ping from the GUI

To open the door for pings from the GUI, bring up the Windows Firewall applet in Control Panel as you've done before: Start > Control Panel > Windows Firewall, and then click the Advanced tab. Click the Settings button in the ICMP section.

You see several different settings to allow different things in ICMP with check boxes next to them. You may have to check them all in some cases, but in my experience the only thing I tend to need is ICMP's incoming echo request. I've checked that box in the screen shot. To allow ping responses, check Allow Incoming Echo Request and click OK, then click OK to clear the WF property page. You'll then be able to ping the web server from the XP box, if you're following along in the examples.

Once you've opened up ICMP responses, a netsh firewall show state won't reflect any changes. But add verbose=enable, and you'll get a lot more information, including this:

ICMP settings for all network interfaces:

Mode Type Description
Disable 2 Allow outbound packet too big
Disable 3 Allow outbound destination unreachable
Disable 4 Allow outbound source quench
Disable 5 Allow redirect
Enable 8 Allow inbound echo request
Disable 9 Allow inbound router request
Disable 11 Allow outbound time exceeded
Disable 12 Allow outbound parameter problem
Disable 13 Allow inbound timestamp request
Disable 17 Allow inbound mask request

Notice the line with Enable 8 Allow inbound echo request; that's the one that shows you that this system will respond to pings.

Allowing Ping from the Command Line

Next, let's see how to allow ICMP echoes from the command line. (If you're following the examples, then go back to the Advanced tab and uncheck the box in ICMP Exceptions that allowed ICMP echoes.) To enable ICMP echoes from the command line, you'd type

netsh firewall set icmpsetting 8 enable

The 8 means "ICMP echo"; to see all of the other numeric values and what they correspond to in ICMP-ese, type netsh firewall set icmpsetting /?. (Again, I've never found a use for them.) Alternatively, you can open up the whole set of ICMP responses with

netsh firewall set icmpsetting all enable

After executing either command, the web server will again respond to pings. To disable either ICMP echo or all ICMP responses, just replace enable with disable on the command line. To stop ICMP echo so as to be able to reopen it again with a group policy setting, then, you'd type

netsh firewall set icmpsetting 8 disable

Allowing Ping from Group Policy settings

To allow ICMP echoes from group policy, return to the Group Policy Editor and the Standard Profile folder under Windows Firewall. Open up the setting Windows Firewall: Allow ICMP Exceptions.

Yours will probably have the Not Configured radio button clicked; I've clicked the Enabled radio button so you can more easily see the options. (Oddly enough, there's a scroll bar in this dialog box, but scrolling up or down doesn't show any more options, so you're not missing anything!)

The setting you're looking for here is Allow Inbound Echo Request. After clicking Enabled in your dialog box, check the box next to Allow Inbound Echo Request and then click OK. Again, the pings will flow freely. As before, netsh firewall show state won't show any difference without the verbose=enable parameter except to reveal in the Group policy version = Windows Firewall that group policy settings are somewhere afoot. As before, any attempts to override the group policy setting via command line or GUI will be ignored.

Eight daily steps to a more secure network

2006-11-16T18:07:04Z

While many companies have a 9-to-5 security staff, hackers don't punch a clock. However, your network can still remain secure in the 16 hours in-between - you just need to focus activities to provide maximum coverage for the network.

]]> In today's connected world, hacking is a 24/7 business. Whether approaching it as a job or a hobby, hackers don't punch a clock.

While many companies don't have the budget for 24/7 security managers, that doesn't mean you should just give up on security. If your security staff, or your one security staff member, is on a 9-to-5 schedule, your network can still remain secure in the 16 hours in-between - you just need to focus activities to provide maximum coverage for the network.

Develop a methodical, comprehensive task list that provides the most efficient means of securing your network. To jump-start your planning, here are eight simple tasks you should make sure to check off every day.

After arriving at work, get some coffee, check your e-mail, and do the following:

1. Verify the current connections: There's nothing like catching malicious behavior while it's occurring. Inspect all the connections going through your firewall -- both in and out. Look for anomalies and investigate them; this could include outbound FTP or inbound Telnet/SSH sessions. You're looking for things that aren't normal.

2. Look at network traffic statistics: How much activity took place while you weren't there? What type of traffic was it, and what was the destination and source?

3. Look at your antivirus logs: Did a virus hit your e-mail system last night? Are the antivirus signatures up to date?

4. Read the security logs on your domain servers: Did the system lock out any accounts last night? Pay special attention to any accounts with administrator access. Verify that lockouts were human error - and not part of a breach attempt.

5. Check for new security patches: Determine whether any of your vendors released patches for any software in your baseline. (If you don't have a baseline, I highly recommend developing one.) If a new patch is available, read the release notes thoroughly. Then, make a decision or recommendation whether to implement it now or wait for scheduled system downtime.

When you arrive back from lunch, there's still a lot left to do:

1. Meet and brief: Managers like to know what's going on, so don't wait for them to ask -- tell them. Meet and brief on anything that occurred during the evening and the actions you've taken so far. This is also a good time to pitch new ideas; such as tools that could help you defend the network or staff training.

2. Check more logs: Take an in-depth look at IDS and firewall logs. Who on the Internet is knocking on your door? What are they looking for? Who on the inside of your network is doing something they shouldn't be?. If you find unauthorised and/or illegal activity, report it immediately, and take action to stop it.

3. Turn knowledge into action: Now that you know what went on while you weren't there, develop an action plan to prevent the behavior in the future. Do you need to adjust your firewall rules? Is your IDS catching and reporting the proper events? Do you need to archive logs to save space on your servers? Do you need to give a final briefing on any actions that occurred during the last 24 hours?

Final thoughts

A lot of companies don't run 24/7 security operations, and sometimes you might find yourself as the only person providing security for a network. While it's easy to get caught up in events and miss important items on your security checklist, you'll never know what you're missing if you don't create a list in the first place. Network security shouldn't be reactionary -- don't wait for events to drive you into action.

The above list isn't complete, but it's a starting point. Create your own security to-do list that's specific to your organisation's needs, and keep your security on track.

---

Mike Mullins has served as an assistant network administrator and a network security administrator for the U.S. Secret Service and the Defense Information Systems Agency. He is currently the director of operations for the Southern Theater Network Operations and Security Center.

What you need to know about OSPF

2006-11-09T11:36:39Z

As I mentioned in the "What you need to know about EIGRP" article, EIGRP and Open Shortest Path First (OSPF) are the two most popular routing protocols for today's midsize and large companies—both offer a huge breadth of features that can cover just about any routing scenario such companies would need. That article answered some common questions about EIGRP, but what about OSPF?

]]> Review the OSPF basics

OSPF is an internal routing protocol. (While primarily used inside a single company, it can span multiple sites.) Based on RFC 2328, it's an open standard. Because of this, OSPF is available on Microsoft's Windows Server 2003 OS, Linux, and many other network devices - unlike Cisco's EIGRP routing protocol. Like other dynamic routing protocols, OSPF enables routers to disclose their available routes to other routers.

OSPF is a link-state routing protocol that runs Dijkstra's algorithm to calculate the shortest path to other networks. Taking the bandwidth of the network links into account, it uses cost as its metric. OSPF works by developing adjacencies with its neighbors, periodically sending hello packets to neighbors, flooding changes to neighbors when a link's status changes, and sending "paranoia updates" to neighbors of all recent link state changes every 30 minutes.

While OSPF is an excellent routing protocol for networks of all sizes, one of its weaknesses is that it can be quite complex to configure. On the other hand, it offers more features than simpler protocols such as RIP.

Here are some of OSPF's strengths:

* It converges quickly, compared to a distance-vector protocol.
* Routing update packets are small, as it doesn't send the entire routing table.
* It's not prone to routing loops.
* It scales very well for large networks.
* It recognizes the bandwidth of a link and takes this into account in link selection.
* It supports variable-length subnet masks (VLSM) or Classless Inter-Domain Routing (CIDR).
* It supports a long list of optional features that many others don't.

Configure OSPF

Some may find OSPF configuration intimidating, so let's look at how to make it easy. Let's start with a basic network: Our network example has two routers - one in San Diego (192.168.1.0 /24) and one in Dallas (192.168.2.0 /24). Between these two routers, there's a point-to-point T1 circuit with IP network address 1.1.1.0/30. The San Diego router's WAN interface is 1.1.1.1, and the Dallas router's WAN interface is 1.1.1.2.

We'll begin by configuring the router in San Diego. The first step to configuring OSPF is to use the router ospf command when in Global Configuration Mode. Here's an example:

Router(config)# router ospf {process number}
Router(config-router)#

While it doesn't matter which process number you use, I recommend keeping it the same on all OSPF routers on your network. I usually use 100 to keep everything simple. However, if you use different process numbers, OSPF will still work and exchange all routes - unlike EIGRP.

After entering OSPF Configuration Mode, the most common next step is to specify which networks OSPF will advertise, which you can do using the network command. Here's an example:

Router(config-router)# network 192.168.1.0 0.0.0.255 area 0
Router(config-router)# network 1.1.1.0 0.0.0.3 area 0

The first parameter is the network ID, and the second parameter is the inverse mask. The inverse mask - or wildcard mask - is the inverse of the subnet mask. It tells OSPF what range of interfaces the IP addresses given will apply to. Therefore, you can have one network statement that covers multiple interfaces.

You also need to specify the area, which is how OSPF organizes networks. All traffic must flow through area 0. In a small network, it's logical to put all networks in area 0, as we did in the example.

After you've configured each side of the network, the routers will exchange routes and form adjacencies. You should see a statement in the log file or console that looks something like the following:

*Mar  1 02:53:33.370: %OSPF-5-ADJCHG: Process 100, Nbr 1.1.1.1 
  on Ethernet0/0 from LOADING to FULL, Loading Done

To make sure you see these types of messages, use the log-adjacency-changes command in your OSPF router configuration. This command causes OSPF to enter information into the router's log file whenever it loses or regains connectivity with its neighbors. Here's an example:

Router(config-router)# log-adjacency-changes

Check the status of OSPF

After you've configured OSPF, you need to know how to check its status. Here are some common OSPF commands, along with links to their Cisco documentation and sample output from our example:

* show ip ospf
* show ip ospf neighbor
* show ip ospf interface
* show ip route ospf

For more information on OSPF, see Cisco's OSPF Design Guide and Cisco's OSPF Documentation.

What you need to know about EIGRP

2006-11-09T11:21:05Z

When it comes to internal routing protocols, the two most popular in use today at midsize and large companies are Enhanced Interior Gateway Routing Protocol (EIGRP) and Open Shortest Path First (OSPF). Both of these routing protocols offer a huge breadth of features that can cover just about any routing scenario that a midsize or large company would require.

]]> Not very familiar with EIGRP? Let's look at some common things every network administrator needs to know.

Know the EIGRP basics

Let's start with the fundamentals of EIGRP and discuss how to configure this protocol.

What type of routing protocol is EIGRP?
EIGRP is a hybrid-distance-vector routing protocol. It's primarily a distance-vector routing protocol, but it also uses the same composite metrics as Interior Gateway Routing Protocol (IGRP). EIGRP uses the Diffusing-Update Algorithm (DUAL) to perform look-free routing and calculate the shortest path.

How does EIGRP work?
With EIGRP, two routers form a neighbor relationship and exchange routes. Hello packets ("keepalives") are present between the two routers; they serve to let each side know if the other goes down or if the link between them goes down.

Typically, these keepalives between neighbors are multicast packets. The type of multicast used is Reliable Transport Protocol (RTP), and communication takes place using the reserved IP address 224.0.0.10.

How do I configure EIGRP?
Like OSPF, EIGRP uses autonomous system numbers to identify areas of the network that are under a single administrative domain. In other words, these network areas are under the control of a single part of the company or a certain group.

To activate EIGRP on your router and enter its Configuration Mode, use the router eigrp command while in Global Configuration Mode. Here's an example:

Router(config)# router eigrp {AS number}
Router(config-router)#

It doesn't matter which Autonomous System (AS) number you use - as long as it's the same on all routers that will be talking to each other. Valid options for the AS number are 1 to 65535. While you can configure more than one AS on a single router, Cisco doesn't recommend this approach

After entering the EIGRP Configuration Mode, a network administrator's most common task is to specify which networks EIGRP will advertise. You can accomplish this using the network command. Here's an example:

Router(config-router)# network 10.0.0.0 0.255.255.255

The first parameter is the network IP address; the second parameter is the inverse mask. The inverse mask (or wildcard mask) is the inverse of the subnet mask.

This command is similar to the OSPF network command. It tells OSPF which range of interfaces the specified IP addresses will apply to. So, you can have one network statement that covers multiple interfaces. However, unlike OSPF, EIGRP does not use areas.

How do I see what's going on with EIGRP?
After you've configured EIGRP, you need to know how to check its status. Here's a list of the most common EIGRP commands as well as links to their Cisco documentation:

* show ip eigrp neighbors
* show ip eigrp interfaces
* show ip eigrp topology
* show ip eigrp traffic

Study the vocabulary

Now that you know how to configure EIGRP and you're familiar with common commands, let's define some words you may run across while working with EIGRP.

What is the topology table?
Essentially, the topology table is the EIGRP database of available routes received from neighbors. It shows the metric for these routes as well as the feasible distance to these networks. The topology table contains a lot of information about successors, feasible successors, and feasible distance.

What is a successor?
A successor is the neighbor with the best path to a destination.

What is a feasible successor?
A feasible successor is the neighbor or neighbors that have other loop-free paths to a destination that aren't a preferred as the successor's path.

What is the feasible distance?
The feasible distance is the metric of a network advertised by the connected neighbor plus the cost to get there.

What is an adjacency?
An adjacency is when two neighbors form a relationship and are exchanging routes.

Get more specific

Now let's take a look at some specifics about using EIGRP.

Does EIGRP use split horizon?
Split horizon is a loop-prevention method. Essentially, when using split horizon, a routing protocol tries to prevent a routing loop. It does this by not advertising a route from an interface from which it received an advertisement for that route.

EIGRP uses split horizon, but you can disable it if necessary. To do so, use the no ip split-horizon eigrp {AS number} command. Keep in mind that the no ip split-horizoncommand doesn't affect EIGRP, as it would RIP. Link-state routing protocols such as OSPF and the Intermediate System-to-Intermediate System (IS-IS) protocol don't use split horizon.

Does EIGRP support VLSM or CIDR?
EIGRP carries the subnet mask in the routing update, and it does support both variable length subnet masks (VLSM) and Classless Inter-Domain Routing (CIDR). In other words, you can subnet your network from the classful boundaries (where a class A network is 10.0.0.0 with a 255.0.0.0 subnet mask, etc.), and EIGRP will work fine. (Lack of support for VLSM and CIDR are limitations of RIP and IGRP.)

By default, EIGRP summarizes networks at the classful boundaries. You can disable this by using the no auto-summary command in Router Configuration Mode.

What is the administrative distance (AD) and routing table code for EIGRP?
An entry in the routing table for EIGRP looks something like the following:

D       10.93.103.0/24 [90/5542656] via 10.226.100.1, 00:30:54, Serial5/0

The D at the beginning tells you that this is EIGRP. The 90 is the administrative distance for this EIGRP route. This is the default administrative distance for EIGRP.

What happens when EIGRP is "stuck in active"?
"Stuck in active" is a common issue with EIGRP. In fact, it's so common that Cisco has an acronym for it: SIA. Cisco has also created a support page for SIA; however, Cisco login information is required.

Essentially, SIA occurs when an EIGRP router doesn't receive a query reply sent to its neighbor after three minutes. When this happens, you'll see "DUAL-3-SIA" in the log file. Troubleshooting this can be quite complex, so I would refer to the Cisco documentations.

Network Load Balancing: Economical means to scalability, fault tolerance

2006-11-07T16:40:26Z

One way to make a network server both scalable and fault-tolerant is to implement clustering, which allows a server's workload to be distributed across multiple servers. This provides fault tolerance in that if one server fails, the remaining servers in the cluster will continue to service requests.

]]> Many administrators assume that clustering is expensive and complicated to deploy. And it can be.

However, Windows Server 2003 supports two types of clustering; traditional clustering and Network Load Balancing. The latter is far less expensive and complicated to deploy than traditional clustering.

Network Load Balancing is primarily used to provide scalability and fault tolerance to servers hosting Web applications, such as Outlook Web Access. OWA allows a user to access their Exchange mailbox through a Web site (which is designed to look just like Outlook).

For companies with many remote users, OWA is critical. Such companies will often cluster their OWA servers using Network Load Balancing; this allows OWA to service more requests than would be possible using a single server, while eliminating a single point of failure.

Requirements for implementation

Requirement #1: The servers making up the Network Load Balancing cluster (called nodes) must all be running duplicate copies of the same hosted application. Network Load Balancing is typically used for Web servers because cluster nodes cannot contain any data. (The reason for this: It is difficult to predict which server will service in-bound requests).

If data were stored on individual cluster nodes, then each server would contain a subset of the total data, and there would be no easy way of consolidating this data. Instead, data is typically stored on a back-end server, where it is centrally accessible by all cluster nodes.

To see how this works, let's look at the OWA server. OWA acts as a front-end interface to an Exchange Server organization. But the OWA server does not contain any user data. It merely hosts the OWA Web site, and acts as an interface to a back-end mailbox server. All of the user's mailboxes are stored on the back-end Exchange Server, so they can be centrally accessible to any front-end OWA server.

(By the way, back-end Exchange Servers can also be clustered, but not with Network Load Balancing. Clustering back-end servers requires the use of traditional clustering, which is beyond the scope of this article.)

Requirement #2: A Network Load Balancing cluster must contain 2 to 32 nodes. The number that will be appropriate for your cluster depends on the level of activity you expect your hosted application to receive. If you're unsure how many nodes you need, you can create a two-node cluster, then add additional nodes as the workload increases.

Requirement #3: Each cluster node must have two IP addresses. The first IP address works just like any other IP address. It is unique to the individual server, and must not be duplicated. The other IP address is shared by all of the nodes in the cluster.

To see how this works, say you have a two-node cluster hosting a Web application. The DNS server that is authoritative for your domain must be configured so that the record pointing to the Web application references the IP address that is shared by all nodes in the cluster. Now, when users access the Web application, they are taken directly to the cluster's IP address.

When the request arrives, all the hosts in the cluster receive and process the request. The Network Load Balancing service runs an algorithm to determine which of the nodes should respond to the request. Each node performs this calculation independently, without communicating with the others. Communications with the other cluster nodes are required any time a node is added to or removed from the cluster, as well as on a periodic basis to gauge the health of each node. When nodes are added or removed, the algorithm that determines which host responds to a request is changed to reflect the new number of nodes.

One last thing: Network Load Balancing clusters will only provide fault tolerance as long as a failure is related to one of the nodes in the cluster. Other types of failures will still result in downtime. If you're implementing a Network Load Balancing cluster, I recommend having multiple Internet connections, routers, firewalls and switches. In order to provide true fault tolerance, you must have redundancy outside of the cluster.

Remember: True scalability and fault tolerance are only achieved so long as there is redundancy outside of the cluster, and any backend databases are able to keep pace with the cluster.

Using the new DFS in Windows Server 2003 R2

2006-05-10T13:22:49Z

R2 is an interim or "upgrade" release of Windows 2003. It is an optional upgrade, but has some very nice features such as the new DFS. Look here for more details on R2.

Before we continue this discussion, it is important to note that "DFS" previously referred to shares and namespace management. Beginning with the Windows Sever 2003 R2 release, "DFS" is an umbrella term that refers to both namespaces and replication. The term "DFSR", at lease as it is used at this time, refers to the new replication engine.

]]> FRS is used to replicate SYSVOL content (Group Policy) as well as DFS data which is defined and configured by the System Administrator. After years of trying to patch the very problematic FRS, Microsoft made an important strategic move and started from scratch to build a more efficient, reliable replication engine to replace FRS. They added a new DFS component in the Windows Server 2003 release of R2 that uses DFSR for replication of DFS folders. This new engine, called DFSR (Distributed File System Replication), is used in R2 for replicating DFS Namespace data. Unfortunately they didn't get time to implement it for SYSVOL replication, but it will be implemented for SYSVOL in the Longhorn release of Windows.

The only bad thing about DFSR is its name. It makes it very confusing to refer to the replication engine that has the same name (DFS) as the namespace. So there is an old DFS, a new DFS with DFSR and a new management console. However, once you dig into the new console, it is easy to distinguish them.

DFS Management Console

One of the hardest things about DFS has been figuring out the terminology. Terms like DFS root, root target, root replica, link, link target, etc. are not intuitive and are difficult to understand. The new management console is much more simplistic. Figure 1 shows the new console. Note the left column shows two items: Namespace and Replication. Wow -- terms that actually make sense! You can see the namespaces defined (formerly known as DFS Roots) under Namespaces, and under Replication, you see the folders replicated (formerly known as Links). In Figure 1 you can also see the servers that host this namespace (formerly known as Root Targets or replicas).

Figure 1

There is a cool replication wizard that lets you configure the replication with common sense terms, and you can monitor the replication status all within this console. This is shown at least in part in Figure 2 where we can see the properties of the replicated folder, DATA. Note the tabs:

Memberships - List of all servers replicating this folder (formerly known as Link targets) along with the path of the folder, if replication is enabled or disabled on that member, and the staging quota size
Connections - Data about replication (who is the sending member, who is the receiving member, their respective sites, etc.)
Replicated Folders - The name of the replicated folder, publication status and namespace path
Delegation - Security (who has permissions to the folder and how it was granted)

Figure 2

Interoperability between Windows 2003 and Windows 2003/R2 DFS

It should be fairly obvious that with a new DFS replication engine, namespaces can only use one or the other -- not both. Even with the new DFS installed, you can still use FRS to replicate DFS data just like you always did. Note in Figure 3, if you look in Administrative Tools, you'll see the old DFS Management snap-in, called Distributed File System in the tools list, as well as the new R2 console, called DFS Management. Simply use DFS Management to configure with the DFSR replication engine, and use Distributed File System snap-in (the old one) to use FRS.

Figure 3

For example, let's say you have five Windows 2003 SP1 DFS servers hosting a folder called Documents. You want to start upgrading them to R2 and eventually use the new DFS. You can upgrade them at whatever schedule you see fit and just not change anything. They will still replicate using FRS under the old definitions. Once they are all upgraded, install DFS from the Windows Components under Control Panel \ Add-Remove Programs on each one. Open up the new DFS Management console and add the namespace just like you did in the old snap-in. No need to reconfigure the namespace. Just right click on the Replication option in the left panel of the console and answer the wizard's questions to configure replication.

NOTE: It is possible - thought not recommended - to have two different replication topologies for a single namespace, but on different servers. Suppose in the previous scenario you upgrade servers S1, S2 and S3 but it will be a while before you can upgrade S4 and S5 and you want to try out the new DFS. So you install the new DFS on S1, S2 and S3, then go into the new DFS Management snap-in on S1 and configure replication for the Documents folder for S1, S2 and S3. You now have a split brain replication. S1, S2 and S3 will replicate their Documents folder with each other and S4 and S5 will replicate their documents folder between themselves. However, if you add files to the directory on S4, it won't replicate to S1 and vise-versa. The problems here are obvious. The recommendation then, is to replicate folders with like data in either the old DFS or the new DFSR, but not both. Be careful during migration to plan your move and not have this happen.

I ran through the wizard and configured replication topology for a folder. It was very easy, very intuitive and it didn't use the words Root, Replica, link or target once. I highly recommend you migrate to the new DFS to take advantage of these features as well as the new "Remote Differential Compression" which allows sending only the changes made to a file rather than the whole file - a huge improvement in performance and reduction of network load.

There are many other reasons you'll like the new DFS that we'll discuss in future articles. Check out the FAQ and the other information on the Microsoft web site noted at the start of this article.

Active Directory scripting secrets: When GUI just isn't enough

2006-05-10T13:00:00Z

While it's true that Active Directory provides a number of easy, wizard-driven Graphical User Interface options to create objects and perform many common administrative tasks, to be a truly effective admin you'll often need to get away from the GUI and find a more efficient way to operate.

]]> A common example among AD administrators I know goes like this: take two administrators, call them Admin A and Admin B, and give each of them the task of creating 1,000 Organizational Unit objects. Admin A launches into the Active Directory Users and Computers snap-in and right-clicks where she wants the OU to go. She clicks New > Organizational Unit, fills in the relevant information in the wizard, and poof! The first OU on the list is done, and now she's got another 999 to go. Not only is this time-consuming, but the odds are extremely good that she'll make at least one or two typos or create an OU in the wrong location.

Admin B, on the other hand, decides to head to the command-line. She creates a text file called ous.txt with the Distinguished Name (DN) of each OU on a separate line, like this:

  ou=Finance,dc=mycompany,dc=com
  ou=Payroll,ou=Finance,dc=mycompany,dc=com
  ou=Marketing,dc=mycompany,dc=com
  ou=Training,dc=mycompany,dc=com

…and so on.

Admin B then uses a simple for loop that cycles through the OUs in the text file and creates each one in turn, like this:

  for /f %i in (C:\ous.txt) do dsadd ou "%i"

While it may take a little extra time to format that ous.txt file appropriately and to proofread it for correctness, it'll more than pay off in the end when the process of actually creating those 1,000 OUs ends up taking less than a minute. Using a script for this process is also much less error-prone, since there's no chance that you'll mistype "Training" as "Tarining" because it's the twentieth time you've had to type it into the ADUC wizard and your eyes have gone crossed.

What's that, you say? Still not convinced? You're only running a small AD deployment and the odds of you needing to create 1,000 OUs in a single go are quite slim indeed? Try this one on for size then.

You've been asked to deploy a software application to your clients that requires at least 512MB of RAM to run comfortably, and you need to know how many of your current workstations have less than this. So you open up ADUC, right-click on the domain and click Find. Hmm, seems the only options you can search for here are the computer name, role, description, and operating system version. Out of luck? Not by a long shot. You can use the Windows Management Instrumentation (WMI) to loop through the computers in your domain and grab the information you need. To obtain the total amount of memory installed on your local computer, for example, you'd use something like this:

  Set objWMIService = GetObject("winmgmts:\\.\root\CIMV2")

    Set colItems = objWMIService.ExecQuery("SELECT * FROM Win32_LogicalMemoryConfiguration",
    "WQL", _ wbemFlagReturnImmediately + wbemFlagForwardOnly)

For Each objItem In colItems

 WScript.Echo "Total Installed Memory: " & objItem.TotalPhysicalMemory
   WScript.Echo

  Next

Next

Now, before your eyes start to glaze over because there's just no way that you have time to learn something that looks so confusing, here's a secret: you can find ready-made scripts to do most of the things you need just by searching the Internet. To help you get started, there's the TechNet Script Center Repository, a plethora of free scripts to be found at Lissware.net, and an excellent collection of Active Directory-specific scripts from RallenHome.com. The Microsoft "Scripting Guys" who run the Microsoft site I just mentioned also host a number of webcasts each month to help you get started with administrative scripting.

While I know that we're all overworked administrators with not much time left in the day to pick up a new skill like VBScript or learning a host of new command-line utilities, I can promise you that the time you spend now to learn these useful tools will end up saving you hours spent doing the "point-and-click shuffle" in the long-run. Scripting also lends itself quite well to automation: you can create a script to check for unused computer or user accounts on your domain once a quarter, or to parse your server event logs looking for red flag error messages. The more you can automate tasks such as these, the better your network will run and the more time you can devote to more involved tasks (or maybe just going home at 5:30 to play with your kids or your dog once in awhile!)

Extracting Active Directory info quick and easy with LDIFDE

2006-05-10T12:50:59Z

As mature as Active Directory is, it still amazes me how many admins I talk to who have no idea how to write simple LDIFDE.exe commands to gather data for routine operations. My next few articles will give you some simple instructions on how to take advantage of this tool to gather AD data without using those painful UIs -- even for the scripting impaired!

]]> LDIF is actually a standard interface for LDAP (RFC 2849 which can be found at here ). LDIF describes Directory and Directory entries in text format. Simply put, you can extract object and attribute data from the directory and have it output in simple text format, as well as using it to read a simple text file to create objects in the directory. Microsoft provided LDIFDE.exe as a command line tool, native to all server versions of Windows 2000, 2003, etc. While it is not native to Windows XP, you can simply copy the ldifde.exe file from a server to an XP workstation and it will work. It uses common LDAP syntax and structure to export from or import data into Active Directory. Since it is a standard, it can also be used to move objects such as users, groups, etc. between LDAP directories.

O.K. - so now you know the boring stuff - let's look at a few simple commands. Note that just by typing LDIFDE at a command prompt on a server, the help file will be output. The LDIFDE command contains several basic components:

    LDIFDE
  -i    import
   (default option is export)
    -f (file name)     name of import or export file)
    -s  (server name)   name of server to bind to for the operation
    -d (Ldap path)    Distinguished name for the path to the object(s) desired
    -r  (ldap object filter)     Filter the results using common ldap filters
    -l  (ldap attribute filter)  lists attributes to be returned on the object
    in the object filter.

Examples

Here are some basic examples you can cut your teeth on.

This first command will dump the entire AD into a file called ADdump.ldf. Note that since export is the default, we don't have to give it an export option. The -f option directs the output to ADdump.ldf and the -s option binds to the domain controller ATL-DC01 for the operation. If the -s option is missing it will bind to the DC you are executing the command from (assuming you are on a DC).

   LDIFDE –f ADdump.ldf –s ATL-DC01

This is an interesting command. Since users have read access to the directory, any user can put LDIFDE.exe on his or her workstation and dump the entire AD into a text file. This seems like a bit of a security hole -- especially if you store private data like Social Security numbers, Employee Badge Numbers, etc. that could be exposed with the dump of the user objects. There is no way around this as users must have read privileges. As one Admin put it, "At some point, you have to trust the users."

Obviously, you don't want to dump the entire AD and then sort through piles of data to find what you are looking for. LDIFDE uses common LDAP filters to narrow the search. Here are a few examples of how you can use the LDAP filters.

Suppose you want to get the attributes of all users in the Americas OU in the Corp.net domain. Using the -d and the -r command options described previously, the command would look like this:

   Ldifde –f users.ldf –s hpqnet-dc4 –d "OU=USA, dc=corp,dc=net" –r "(objectClass=user)"

Note that for the -d option, the LDAP path is the distinguished name (DN) for the OU. The -r option defines the objectClass. In this case, we just want Users. This would dump all attributes of all users. The data returned from one user would look similar to this:

    dn: CN=Steve Vai,OU=Americas,DC=Corp,DC=Net
    changetype: add
    AccountExpires: 9223372036854775807
    badPasswordTime: 0
    badPwdCount: 0
    codePage: 0
    cn: Gary Olsen
    countryCode: 0
    displayName: Steve Vai
    givenName: Steve
    instanceType: 4
    lastLogoff: 0
    lastLogon: 0
    logonCount: 0
    distinguishedName: CN=Steve Vai,CN=Users, ,DC=Company,DC=com
    objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=Company,DC=com
    objectClass: user
    objectGUID:: 4QiWdzpEYk2UTNL6iz/msA==
    objectSid:: AQUAAAAAAAUVAAAA/j9VVfSHVADdy8sQWwQAAA==
    primaryGroupID: 513
    pwdLastSet: 126270827951240348
    name: Steve Vai

Note the values of the objectGUID, objectSid, pwdLastSet, and AccountExpires attributes are unintelligible. There is some data that has to be reformatted via a script to get the right data. This will be discussed in a future article.

This article has given you some basics. You could use the same sample command and replace the User objectClass with Computer, or any other valid objectClass. There are also ways to filter certain attributes, such as returning only the street address, or perhaps return only users with a surname beginning with "A". These advanced operations require a bit more digging into LDAP search syntax. In the next few articles, I will give you a brief tutorial on LDAP searches and how to implement them in LDIFDE commands.

Taking out the Active Directory trash

2006-01-18T14:04:46Z

Active Directory (AD) is essentially a big database. As with any database, you have to do a little work to maintain it properly. In this article, I'll shown you how to defragment the Active Directory database and how garbage collection works.

]]> The size of Active Directory (AD) depends on the number and type of objects it contains. As more objects are added, the directory grows in size. There is generally no appreciable change in performance as the size of the directory grows, and in general, there's little performance reason to reduce the directory size. Storage capacity is, however, a consideration. In this article, I'll take a look at what Active Directory does when you remove entries from it.

What do you want on your tombstone?
When objects are deleted from the directory, they are not immediately removed. Instead, the directory service removes the majority of the object's attributes and tags the object as tombstoned. The tombstone state indicates that the object has been deleted but not removed from the directory, much like a deleted file is removed from the file allocation table but the data is not actually removed from the drive. The directory service moves tombstoned objects to the Deleted Objects container, where they remain until the garbage collection process removes the objects. Garbage collection also defragments the database, essentially rearranging the data to be contiguous, and thereby reducing the size of the database file. The primary consideration isn't performance but rather keeping disk utilization to a manageable size.

Time to take out the garbage
The garbage collection process by default runs every 12 hours on a Domain Controller. The length of time tombstoned objects remain in the directory service before being deleted is 60 days (by default). The tombstone lifetime must be significantly longer than the garbage collection frequency to ensure that deletion of objects is replicated to other DCs. These default values ensure that the tombstoned state of the objects is replicated and the objects are deleted from all DCs, because it is extremely unlikely that it will take 60 days for a single replication to complete.

While you don't need to change the garbage collection interval or the tombstone lifetime, you can do so if your domain structure or replication scheme warrants it. For example, you might prefer to reduce the garbage collection interval to 24 hours to reduce server load and reduce the tombstone lifetime to 30 days to free up disk space more frequently. The maximum garbage collection interval is one-third of the tombstone lifetime. If you set the tombstone lifetime to 30 days, for example, the garbage collection interval will be 10 days, even if you've specified a larger value.

You can use the ADSI Edit tool included with the Windows 2000 Support Tools (located in the Support\Tools folder of the Windows 2000 CD) to modify the settings for garbage collection and tombstone lifetime. The values are attributes of the cn=Directory Service,cn=Windows NT,cn=Services,cn=Configuration,dc=ForestRootDomain object, and the attributes to change are tombstoneLifetime and garbageCollPeriod.

Defragmenting the Active Directory database
When AD performs the garbage collection process, it defragments the database; although it does not free up space on the disk, it simply restructures the existing data within the file. You use the Ntdsutil.exe command-line tool included with Windows 2000 to perform the defragmentation. While you can run Ntdsutil while the server is online, you must defragment the database with the directory service offline to recover disk space.

To start the server in Directory Services Restore Mode to perform the defragmentation, press [F8] at startup to display the Windows 2000 Advanced Options menu. Select Directory Services Restore Mode and press [Enter]. After the server boots, run the Ntdsutil utility to defragment the database. Ntdsutil is an interactive console program that performs several actions on the database.

When you perform a defragmentation, Ntdsutil creates a new copy of the Ntds.dit database file in a different folder. You then replace the old file with the new one and restart the server. You should retain the old Ntds.dit file in case you experience problems with the new file. Also, compare the file size between the old and new files to determine how much space you've freed through the defragmentation.

In addition, you can configure Windows 2000 to log the amount of space that would be freed by an offline defragmentation to the Directory Service event log during garbage collection. You'll need to tweak the registry to accomplish this. Open the Registry Editor and set the value of HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics\Garbage Collection to 1. Then, check the log after the next garbage collection to verify that the directory service is logging the data.

As explained above, Ntdsutil.exe is an interactive utility. Type Ntdsutil.exe at a console prompt and then enter Help to view the command options. You use the Files command to defragment the database.