Blog Host: Laura Hunter - IT project leader, Univ. of Pennsylvania READ ENTIRE BIO

• Monad -- Currently in Beta 2, this is going to be the next major advancement in scripting platforms for the Windows Server products, as well as for back-end products like Exchange. But more than a simple scripting interface like VBScript, Monad will allow you to run "cmdlets," which are small programs written in C# or another .NET language that allow you to do even more from the command line. It also extends the idea of "piping," a familiar concept from Unix scripting days where you could have the text output of one command be used as the input for a subsequent one. In Monad, you can pipe not only simple text strings, but entire objects that you can pass from one command to another. While not specifically tied to Active Directory, Monad should be on every administrator's radar screen as a technology to become familiar with. While it's going to have a much steeper learning curve than the more basic command-line administration we've seen up until now, the benefits of it will be equally great. O'Reilly publishing has recently released the first major title associated with Monad, definitely worth picking up and reading!

• Network Access Protection -- Slated for release as part of the Longhorn server product, NAP will provide network quarantine services for both your wired and wireless connections, ensuring that only computers that have passed certain minimum "health checks" will be permitted to pass traffic to and from hosts that are a part of your domain. This is a greatly improved extension on the current Network Access Quarantine Control and will allow you to configure network protection using DHCP, 802.1X, IPSec or VLAN technologies. This is going to be one of those technologies that isn't a simple "five minutes and you're ready to go" kind of setup -- it's going to take some extensive planning and deployment skills to integrate this protection into your network infrastructure. NAP is one of those tools that I'm really excited about, as I think it'll be an incredible step forward for the security of Microsoft networks.

• Active Directory Application Mode -- You don't have to wait around for ADAM; it's available right now as a download or as part of the Windows Server 2003 R2 release. ADAM takes some major steps forward in terms of allowing more flexibility in extending and utilizing the Active Directory information store, by allowing you to store customized user information without necessarily needing to extend the Active Directory schema. Because it's so easy to work with, I think that ADAM is going to be the future of application development for AD -- you can put up and take down an ADAM without affecting your underlying NTDS.DIT file, use it to store user data that can integrate with your network applications and replicate that data to only those locations where it needs to be stored.

• Active Directory Federation Services and Microsoft Identity Integration Services -- Both of these products take the notion of Active Directory identity management and push the envelope out beyond the local or wide area network into corporate partnerships and heterogeneous networking environments. While I'm of the opinion that a true "single sign-on" solution will likely remain something of an unattainable Holy Grail, ADFS (available with R2) and MIIS (available as an add-on to Windows Server products) will both take us one great big step closer to achieving that goal.

1. From the Group Policy Management Console, open the policy that you want to edit and browse to Computer Setting --> Windows Settings --> Security Settings. Right-click on the IP Security Policies node, and select Create IP Security Policy. Click Next to bypass the initial Welcome screen.

2. Give your policy a name and a description, and then click Next.

3. The next screen gives you the option to activate the Default Response rule. The Default Response rule will try to enable secure communications with any machine that requests a connection to the local machine, even if that machine doesn't fall under the parameters of the rule you're creating. It's usually a good idea to leave this enabled unless you're supporting a lot of down-level clients that don't speak IPSec. Click Next to continue.

4. Assuming that you activate the Default Response rule, the next screen will ask you to specify the authentication method that the Default Response rule should use. You can use the Kerberos version 5 authentication protocol (the default for Active Directory), certificates from a Windows Certificate Authority or a pre-shared IPSec key. If you use certificates for authentication, you can specify the CA, as well some optional settings. Click Next to continue.

When you begin to edit your Notice that the only IPSec rule that's listed is the Default Response Rule. To create a new rule, click Add, and use the following steps:

1. Click Next to bypass the initial Welcome screen. Your first question involves IP tunneling: If you need to configure IPSec in tunneling mode, this is where you'll specify the endpoint of the tunnel on the opposite end of the connection. If you're using IPSec in transport mode, just hit Next to continue.

2. Next you'll configure whether you want the IPSec encryption to apply to all networks, the Local Area Network (LAN) only or to remote access connections only. In most cases, you'll want to apply your IPSec policy to all network connections unless you've got a performance or backwards-compatibility issue that's preventing you from doing so. Click Next to continue.

3. Select the IP filter list that this policy should apply to. The default filter lists are All ICMP Traffic and All IP Traffic. If you've created any additional filter lists, they'll be shown here as well. Let's create a new filter list to look for traffic on TCP port 6667, since that's one of the default ports for the Internet Relay Chat (IRC) protocol and a well-known transport mechanism for worms and other malicious code. Click Add to create a new IP filter list.

4. Now that you've created a new IP filter list, it's time to add an actual filter to it. First give it a name and a description, and then get rid of the check mark next to Use Add Wizard. (I think we're wizard-ed out by now, don't you?) Click Add again to configure a specific IP Filter. You'll see the screen shown in Figure 5-2.

5. When you're configuring an IP filter, you have available three tabs in the IP Filter Properties dialog box: Addresses, Protocol, and Description. You have a number of possibilities to configure the source and destination IP addresses. You can also decide whether the filter should be mirrored, that is, applied to both incoming and outgoing traffic. So if you have a policy that's applying to traffic going from Any IP address to My IP address, the Mirrored setting would create a second policy that would apply to traffic going from My IP address to Any IP address. Your options for configuring an IP filter list are as follows:
   • My IP Address (the IP address of the computer applying the policy)
   • Any IP Address
   • A specific DNS Name
   • A specific IP Address
   • A specific IP subnet
   • DNS Servers <dynamic>
   • WINS Servers <dynamic>
   • DHCP Servers <dynamic>
   • Default Gateway <dynamic>

6. The Protocol tab will let you choose the specific IP protocol that this filter should apply to. You can specify a particular source and destination port or leave it at the default of Any IP Address.

7. Once you've finished configuring the IP filter, click OK until you're back at the screen from step 3.

8. Your next step will be to configure a filter action. Select the IP Filter List you just created, and click Next.

9. Here you'll configure the filter action. By default, you can choose Permit, Request Security and Require Security. You can create a new filter action to block traffic or you can click Edit to modify one of the default actions. When customizing any Negotiate filter action, you can specify which security method your clients should use as follows:
   • Authentication Header (AH): For authentication only
   • Encapsulating Security Payload (ESP): For both authentication and encryption
   • Custom: To create a customized security method

10. Your final step will be to select the authentication method that this policy should use. Your choices here are identical to the choices for the Default Response Rule: Kerberos, certificates and a pre-shared key.

• IPSec Policy. This is the overall framework that manages the security configuration that's in place; it acts as a container to house the different rules that you've configured to respond to traffic going to and from machines on your network. The IPsec policy also holds the name and description of the policy and dictates how frequently Group Policy will look for new changes to the policy. This refresh rate is 90 minutes for workstations and member servers, and every two minutes for domain controllers.

• IPSec Rule. A rule defines a combination of a filter list, filter action and authentication method, which taken together will determine how IPSec responds to traffic received by a machine on your network.

• Filter List. This is a list of filters that you've defined that IPSec will use to look for a particular subset of inbound or outbound network traffic that should be secured, permitted or blocked. Once the policy finds a packet that matches a specific filter you've created, it will take a particular filter action in response to the packet. A filter list can contain one or multiple individual filters, but each filter list can only be associated with one filter action.

• Filter Action. Like it sounds, this dictates what IPSec will actually do with a packet that matches the criteria of a particular filter list. The possible filter actions available are "block", "permit" or "negotiate security." "Negotiate security" is the default, and you can specify one or more authentication methods that should be used to secure traffic.

• Authentication Methods. You can specify one or more authentication methods to secure traffic and place them in an order of preference if you've listed more than one. You can use Kerberos v5 protocol for authentication, certificates from a Certification Authority (CA) or a pre-shared IPSec key if you have clients that require it. (Though I don't recommend this last one because it's a relatively weak security approach compared to the other two, since the pre-shared key gets stored in plain text.)

• Client (Respond Only). Machines configured with this policy will only use IPSec to encrypt packets if they're communicating with a machine that specifically requests it. In all other cases, communications will remain unencrypted.

• Server (Request Security). Machines configured with this policy will request secure communications from any machine that contacts them. But if the remote machine refuses, this policy will still allow unsecured communications to take place.

• Secure Server (Require Security). This is for a high-security environment. A machine configured this way will request secure communications from any machine contacting it. It's important to note that both the Server and Secure Server policies will allow unsecured incoming traffic in order to support clients configured with the Client (Respond Only) policy. The difference between this policy and "Server (Request Security)" is that this will secure all outgoing traffic, not just traffic that's sent to clients that support it.

• GPanswers.com is the online home of Group Policy guru Jeremy Moskowitz. Subscribe to the newsletter, hang out in the forums and pick up his marvelous book.

• Group Policy Management Console is an updated tool for managing Group Policy Objects in your environment. It greatly improves your ability to create, edit and manage security on GPOs in your whole forest, and can create detailed reports of which settings are being enforced by which GPO. GPMC includes the Resultant Set of Policy, which allows you to generate a report of which GPO settings are in effect for a particular user and even lets you do some basic "what if" planning to see how a change in OU, group membership or client operating system will affect the Group Policies that affect a particular user or computer. GPMC also allows you to back up and restore individual GPOs and to migrate them between domains.

• GPMonitor (built into 2003) and the Group Policy Inventory tools are free utilities that help you to troubleshoot and report on Group Policy refresh operations. GPInventory is a really useful one, as it uses the Windows Management Instrumentation (WMI) to let you do hardware and software inventories of computers in your domain, to scan your domain to see if a particular hotfix has been applied and more.

• In the paid utility arena, a favorite of mine is DesktopStandard's PolicyMaker, which extends Group Policy to allow you to map printers, create Outlook profiles and other useful tricks that are difficult-to-impossible just using the native tools. They've also released a free utility called PolicyMaker Registry Extensions that'll help you easily push out Registry changes, as well as GPOVault, a free add-on to GPMC that helps you with version control.

• Adfind -- from my favorite freeware utility site at Joeware.net -- performs quick or complex queries against your AD database. To get started run adfind -? for basic help instructions, or try -?? or -??? for more advanced features. Need to find all the computer objects in your domain? adfind –default –f "objectcategory=computer" Pretty simple, huh?

• Admod, also from Joeware, makes small or large modifications to your AD database from the command line, either by explicitly listing an object to modify or by using the results of an adfind query to modify multiple objects simultaneously. Now, this one I'll caution you on a bit, since you obviously don't want to go hosing your directory by making incorrect modifications. Test twice, modify once, as they say. (By default, admod has a safety feature that will only modify 10 objects at a time unless you specify otherwise; if you attempt a mod that will overrun that safety option, the entire operation will abort.)

• DCDiag, built into the Windows operating system, is, as the name suggests, is a diagnostics tool for your domain controllers. By default, DCDiag will run a battery of tests to search for replication errors, validate cross-references, check the SYSVOL share and ensure that the DC's machine account has been created correctly and is advertising services as needed.

• NetDiag from the Windows Support Tools is another one you can guess from the name. It runs a battery of tests against your computer's network configuration, testing your IP configuration and default gateway, NetBIOS name resolution, the availability of DNS servers and DCs for your domain and more.

• DNSLint, downloadable from Microsoft, is indispensable in diagnosing DNS issues, although not specifically an Active Directory tool. Since AD simply can't function if your DNS is broken, this deserves a place of honor in your toolkit. Dnslint /ad will verify the presence of DNS records used for AD replication. DNSlist /d will search for lame delegations on your DNS servers, and DNSLinst /ql will verify a specific set of DNS records on one or more DNS servers.

1. Use Restricted Groups to control membership in sensitive security groups, including (but not limited to):
   • administrators
   • domain admins
   • enterprise admins
   • schema admins
   • account operators
   • server operators
   • backup operators
   • print operators

2. While I'm at it, don't add accounts to the Account, Server, Backup or Print Operators groups without taking a good hard look at (and changing) their default rights. (For example: Print Operators, by default, have the ability to shut down a DC. Why, why, why, oh why…is that the case?)

3. Restrict user rights as appropriate, including (but not limited to):
   • log on locally
   • access this computer from the network
   • shut down the system
   • back up files and directories
   • load and unload device drivers

4. Restrict anonymous enumeration of SAM accounts, network shares and named pipes.

5. Restrict the types of LM/NTLM authentication that's accepted, preferably to "Accept NTLMv2 only, refuse all others" or whatever it's called in the GUI. Disable storage of the LM hash in AD.

6. Enable LDAP and SMB signing.

7. Enable the following security options:
   • Clear the pagefile on shutdown
   • Require Domain Authentication to Unlock Workstation (prevents a just-fired admin from wreaking havoc with an existing session)
   • Shut down immediately if unable to log security audits (arguably ultra-paranoiac in nature, but I do it)

8. Disable the following security options:
   • Allow shut down without logon
   • Let Everyone permissions apply to anonymous users
   • Allow anonymous SID/name translation

9. Rename administrator, disable guest. Create the "fake-me-out" admin account with heavy auditing and no privs.

10. Unless you're using them a lot (and if you're in a production environment, why is this happening?), leave Schema Admins empty until you actually need to do something that requires them.

11. Delegate Full Control Active Directory permissions with care, particularly on OUs.

12. Replace the EVERYONE built-in group with Authenticated Users in the Pre-Windows 2000 Compatible security group.

13. SYSKEY -- I could argue both for and against it, depending on the environment. If you're in a 24x7 staffed machine room, maybe a good idea for the ultra-paranoid…if you'd need to drag some poor branch manager out of bed at 2 a.m. when you remote reboot a server? Maybe not so much.

14. Configure AD object quotas to protect against DoS attacks caused by a runaway DIT. Store your DIT and log files somewhere other than the system drive for this reason, as well as just to have them in a non-default locale.

15. Limit physical access to DCs and networking hardware. (No security plan in the world will help you if I can walk up to your DC, boot it into Knoppix and grab all of your password hashes. And no availability plan is complete if it's vulnerable to a well-thrown brick.)

16. Use IPSec and firewalls to limit exposure of your DCs to the outside world. Don't forget about egress filtering.

17. You're patching and backing up and updating your anti-virus, right?

18. You're not running IIS or SQL or anything else really inappropriate and out of place on your DCs, right?

19. You're using "Runas" on your administrative workstations and running as Joe Q. NormalUser otherwise, right? (And you wouldn't lie to your Aunt Laura about this now, would you?)

20. Configure auditing, password complexity and account lockout policies that are appropriate to your environment. There's a great big wheel with "Security" on one side and "Convenience" on the other -- as you dial one up, you almost invariably dial the other down…you don't want your password policy to be so weak as to be laughable, but at the same time you don't want to configure an Account Lockout policy that would cause a normal person to lock herself out of her account every single morning just because she hasn't had her coffee yet.

So it's a holiday, but because I'm a network admin, here I am sitting and working. Perhaps 'tis the season to start thinking about automation, about ways that we can make our lives easier and not have to spend quite so much time working on all of those repetitive tasks. So I'll spend the next few days looking at some common questions that come up, all of which involve the words "How can I" and "automatically" somewhere in the sentence.

"How can I automatically disable accounts on my network that haven't been used in 30/60/x number of days?"

Get thee to Joeware.net, and I do mean right now. The oldcmp utility will do just the trick to find and disable unused user and computer accounts on your network. Oldcmp is an indispensable tool in my arsenal; this one single tool will do any of the following:

• Report on the objects that will be disabled or deleted if you execute the command. You can use this as a sanity-check to make sure that you're only disabling the 15 objects you expect to be disabling, rather than 1500 that you didn't.
• Disable computer or user objects that have been unused for an amount of time that you specify.
• Delete computer or user objects that you've disabled.
• Move disabled objects to a separate organizational unit.

• Oldcmp will only report on what it would have done unless you use the –forreal switch
• You can't delete an object without first disabling it.
• You can't disable or delete more than 10 objects at a time unless you manually specify a larger number with the –safety switch.
• Finally, oldcmp won't do anything at all to your domain controllers.

1. The "ActiveDir" list-serv. Run by Microsoft MVP Tony Murray, this is a moderate- to heavy-traffic list-serv that deals with all things Active Directory, occasionally branching into topics of Group Policy, DNS and other infrastructure services, and even Microsoft Exchange and interop. The quality of participation on this list is incredibly high, including some MSFT folks themselves who lurk and occasionally participate. This is, hands-down, my most valuable AD resource, and one that I consider required reading.

2. Robbie Allen's Active Directory Cookbook. An indispensable guide to performing any number of Active Directory management and administrative tasks. I love the O'Reilly Cookbook format because it's very quick and to the point: "Here's a thing you want to do. Here's how to do it in the GUI. Here's how to do it at the command line. Here's how to script it. Next topic."

3. Alistair G. Lowe-Norris, Robbie Allen and Joe Richards's Active Directory. Also from O'Reilly, it's a more in-depth guide that I'd recommend as a companion to the Cookbook. Hold out for the third edition that's due to be released very soon -- Joe has done some significant work on re-vamping the content and has produced what I consider to be an outstanding text.

4. Jeremy Moskowitz's Group Policy Web site and book. My good friend Jeremy Moskowitz has written what I consider the definitive guide to Group Policy and hosts Q&A forums and the occasional newsletter on his site. I always find at least one or two useful tidbits in his newsletters.

5. The ADSI and Directory Services Yahoo! Group. Operated by DS MVP Carlos Magalhaes, this group is more specifically geared towards development and scripting questions using ADSI and the .NET Directory Services interfaces.