vi

Books

Contents
Chapter 5 Windows Server 2003 Security Enhancements . . . . . . . . . . . . . 81
Securing the Wire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Shoring Up with SMB Signing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Win98 Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
NT 4.0 Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Win95 Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Manipulating the Servers to Not Require SMB Signing . . . . . . . . . . . . . . . . . . . . . 85
Shoring Up with Secure Channel Signing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Shoring Up with LDAP Signing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Shoring Up by Eliminating NTLM and LM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Enabling NTLMv2 Authentication at the Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
NTLMv2 for NT 4.0 Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
NTLMv2 for Win9x Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Disabling NTLM and LM at the Domain Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
ACL Viewing and Editing Improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Security Principals Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Schema Updates and Modifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Next: Backup, Restore, and Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
 81

Chapter 5:

Windows Server 2003

Security Enhancements
In Chapter 4, I considered what happens when you merge two environments, including how to
create secure forest trusts and deploy new Windows Server 2003 (Windows 2003) DNS features to
make a merged environment workable. Although I discussed some security concerns – particularly,
how to keep all but those you choose from accessing the resources you need to protect – Windows
2003 brings much more to the table for your protection effort.
In this chapter, I cover some of the new security enhancements that you can use to ensure a
more secure environment day to day. I review improvements in securing file shares and in ACL
viewing and editing for better control of file permissions. I discuss the InetOrgPerson object and the
ease of new schema modification functions that can help you take better advantage of AD. I also
include a tip or two about how to shore up different parts of your Active Directory (AD) to make
them a bit more secure.

Securing the Wire

Microsoft has a history of being burned by the vulnerability of its internetworking protocols. The
protocol tradeoff is easy to understand: If you make protocols fast, light, and only cursorily secure,
they’re speedier on the wire – and you can deploy them more quickly and widely. However,
unsecure protocols on your network can compromise your company’s resources.
With that in mind, Windows 2003 introduces both new restrictions and new options for some
familiar scenarios. The changes in Windows 2003 means that you must better understand available
security functions such as Server Message Block (SMB) signing, secure channel signing, Lightweight
Directory Access Protocol (LDAP) signing, and password authentication methods.

Shoring Up with SMB Signing

Not all users can drop their deployed desktops and switch to Windows XP Professional or Windows
2000 Professional. Legacy (aka “downlevel”) clients are all too familiar to IT staff. In fact, some orga-
nizations include clients that have not only different Windows OSs but also different service packs
applied, which can make it especially difficult to ensure a baseline of protection across the network.
Wherever it can, Windows 2003 endeavors to make things more secure than its predecessor. One
way in which it attempts greater security is by using SMB connections. The SMB protocol comes into
play when clients connect to shares. When you performed your first Dcpromo to Windows 2003, you
saw the Active Directory Installation Wizard screen that Figure 5.1 shows.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

82 Windows 2003: Active Directory Administration Essentials

Figure 5.1
Warnings about downlevel machines

The screen in Figure 5.1 indicates that you might have problems with older downlevel machines.
The good news is that connections to every Windows 2003 share will be “signed” (i.e., authenticated)
each time a client makes a connection. Indeed, each SMB packet carries a unique signature that the
recipient validates. Therefore, malicious users can’t pretend to be what they’re not.
The bad news, however, is twofold. First, older downlevel clients will fail to connect because
they can’t “speak” the revised protocol’s language. Second, when clients can use SMB signing, it will
slow connections down a bit, probably by 10 percent to 15 percent.
The real problem, however, is that because older downlevel clients can’t perform SMB signing,
they can’t log on. To log on to the network, each client must connect to a domain controller’s (DC’s)
Netlogon share. Therefore, each client must be able to perform SMB signing to that Netlogon share to
validate to the network. Clients that can’t perform SMB signing are out of luck. Because Windows 98
can respond to SMB signing, you’ll only need to troubleshoot problems. Also, you can make changes
to address SMB signing for Windows NT 4.0 and Windows 95 clients.

Win98 Clients
Win98 clients, by default, can respond to SMB signing requests. This capability means that you don’t
have to change or set up anything on your Win98 clients for them to participate in domains with
Windows 2003 DCs.
However, if you have one or two Win98 clients that can’t log on to Windows 2003 DCs or
connect to Windows 2003 shares, the client’s ability to respond to SMB signing might be disabled.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

 Chapter 5 Windows Server 2003 Security Enhancements 83

To turn off a Win98 machine’s ability to respond to SMB signing, someone must manually add a
registry value.
Therefore, if you suspect a Win98 machine isn’t responding to SMB signing requests, you’ll need
to dive into the registry and look for the addition of either of two registry settings.
Navigate to the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\VNetsup
subkey and look for an EnableSecuritySignature value of type REG_DWORD. The default is that this
value is absent, which means SMB signing is enabled. To turn off SMB signing, you would create this
value and set it to 0. Therefore, to re-enable SMB signing, set the value to 1 (Enable). The client will
then respond to SMB signing.
Also, look for an RequireSecuritySignature value of type REG_DWORD. The default is 0.
Manually setting the value to 1 (Enable) requires that all SMB traffic be signed.
Again, you’re checking to see whether someone has created these values. If they exist, someone
might well have specifically disabled a machine’s ability to respond to SMB signing.

NT 4.0 Clients
NT 4.0 Service Pack 3 (SP3) clients won’t perform SMB signing by default. You’ll have to enable SMB
signing through the registry, as I discuss below.
If you’ve already loaded your NT 4.0 clients with SP4 or later – the clients can by default respond
to SMB signing requests. Therefore, you won’t need to set up or change anything on your NT 4.0 SP4
clients to have them participate in domains with Windows 2003 DCs.
However, if you have one or two NT 4.0 clients with SP4 that can’t log on to Windows 2003 DCs
or connect to Windows 2003 shares, someone might have disabled the machines’ ability to respond
to SMB signing – in much the same way that I discussed relative to Win98.
Enabling SMB signing on NT 4.0 SP3 machines and troubleshooting NT 4.0 SP4 or later machines
that aren’t responding to SMB signing requests involves the same two registry values. For NT 4.0 SP3
machines, if the values don’t exist, you’ll create them, then set both values to enable SMB signing. If
the values do exist, set them to enable the feature. For NT 4.0 SP4 or later machines, you might
create and set or re-set the values to re-enable the feature.
Navigate to the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManServer
\Parameters subkey and look for an EnableSecuritySignature value of type REG_DWORD. The default
is that the value is absent, which means that the client will respond to SMB signing. A value of 0
means the client won’t respond to SMB signing. To enable or re-enable SMB signing, set the value
to 1 (Enable) – the client will then respond to SMB signing.
Also, look for a RequireSecuritySignature value of type REG_DWORD. The default is 0. Manually
setting the value to 1 (Enable) requires that all SMB traffic be signed.

Win95 Clients
As the Active Directory Installation Wizard screen in Figure 5.1 indicated, Win95 clients can’t log on
to Windows 2003 DCs. If Win95 clients attempt to log on, they get the message that Figure 5.2
shows.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

84 Windows 2003: Active Directory Administration Essentials

Figure 5.2
Message returned if a Win95 client attempts to log on to a Windows 2003 network

To get your Win95 clients up to speed, you’ll need to load the Active Directory Client Extension
(ADC; aka Directory Service Client – DS Client). The DS Client apparently isn’t on the Windows 2003
CD, but you can find it on any Win2K CD-ROM, in the \CLIENTS\Win9x directory. To run
DSClient.exe, you’ll need to have Internet Explorer (IE) 4.0 or later loaded. Figure 5.3 shows the
Directory Service Client Setup Wizard that you can use to load DS Client onto Win95.

Figure 5.3
Directory Service Client Setup Wizard

After you load the DS Client, Win95 machines won’t need any additional registry settings to
respond to SMB-signed traffic. In other words, just load the DS Client on your Win95 clients, and
you’re “in like Flynn.”

Brought to you by NetIQ and Windows & .NET Magazine eBooks

 Chapter 5 Windows Server 2003 Security Enhancements 85

Manipulating the Servers to Not Require SMB Signing

What if you can’t get your clients up to speed? Specifically, what if you can’t reach some client
combination of
• Win98
• NT 4.0 with SP4
• Win95 with ADC

and you still need to have your clients log on to Windows 2003 DCs and connect to Windows 2003
file shares? You have a final option: You can configure the domain to not require SMB signing.
However, this approach is definitely a “last resort” because it really decreases the intended security.
Nevertheless, if you must disable SMB signing, click Start, Programs, Domain Controller Security
Policy. Navigate to Windows Settings\Security Settings\Local Policies\Security Options. Locate
Microsoft network server: Digitally sign communications (always), which Figure 5.4 shows. With the
Define this policy setting check box selected, change the default from Enabled to Disabled.

Figure 5.4
Disabling SMB signing

Brought to you by NetIQ and Windows & .NET Magazine eBooks

86 Windows 2003: Active Directory Administration Essentials

j Tip
Even if you need to disable SMB signing as described above, you can still leave the sister policy,
Microsoft network server: Digitally sign communications (if client agrees), enabled without
penalty. This setting lets clients and servers that can use SMB signing do so.

Shoring Up with Secure Channel Signing

When Windows 2003 DCs and client workstation and server members communicate about their status
in the domain, they do so over a “secure channel.” Communications about status occur when domain
members join, leave – or their computer passwords are automatically updated between the computer
and the domain.
Windows 2003 DCs require that these secure channel actions be digitally signed. XP, Win2K, and
NT 4.0 with SP4 or later can participate in secure channel signing without any modification. Win9x
machines aren’t strictly “domain members” and therefore don’t use the secure channel or participate
in secure channel signing. For the purposes of secure channel use and secure channel signing, you
can ignore Win9x machines. However, if you have NT 4.0 machines without SP4, you need to either
upgrade those systems to SP4 or disable secure channel signing in the domain.
If you must disable secure channel signing, click Start, Programs, Domain Controller Security
Policy. Navigate to
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options. In
the list of policies and policy settings, locate Domain Member: Digitally encrypt or sign secure
channel data (always). With the Define this policy setting check box selected, change the default
from Enabled, which Figure 5.5 shows, to Disabled. The change disables the requirement for secure
channel communications with domain members. Again – only disable secure channel communications
if you can’t upgrade your NT 4.0 machines to SP4 or later.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

 Chapter 5 Windows Server 2003 Security Enhancements 87

Figure 5.5
Disabling secure channel signing

Shoring Up with LDAP Signing

After you introduce your first Windows 2003 DC, you’ll want to start using the new Windows 2003
administration tools. The good news is that these tools all enforce another new security feature. That
is, many of the Windows 2003 administrative tools work only when LDAP signing protects the
communication.
LDAP signing guarantees that nothing tampers with the communications and data that flow
between your administrative workstation and DCs. When you use the Windows 2003 administration
tools, all your DCs must be able to perform LDAP signing. To support LDAP signing with Win2K,
you need to load Win2K SP3 on each DC and restart the DC.
Even if you can’t load SP3 on all your Win2K DCs, you might still want to use the Windows
2003 administration tools to manage all your DCs. To do so, you can turn off LDAP signing on your
administrative workstation (usually XP). Doing so will let the communication go over the wire
unsigned, which might leave the traffic vulnerable to sniffing. Do so at your own risk.
After you load the Windows 2003 administration tools on your XP administrative workstation,
you’ll need to modify the registry on your machine. Navigate to the HKEY_LOCAL_MACHINE
\SOFTWARE\Microsoft\Windows\CurrentVersion\AdminDebug\ADsOpenObjectFlags subkey on
your administrative workstation. Set the ADsOpenObjectFlags value to 0x03. Restart the administrative
tools. You’ve now turned off LDAP signing between your administrative workstation and all DCs.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

88 Windows 2003: Active Directory Administration Essentials

j Tip
For more information and to see which specific applets inside the Windows 2003
administration tools explicitly use LDAP signing, go to Knowledge Base article Q325465,
“Windows 2000 Domain Controllers Require SP3 or Later When Using Windows Server 2003
Administration Tool,” at the Microsoft Product Support Services (PSS) URL below:

http://support.microsoft.com/?kbid=325465

Shoring Up by Eliminating NTLM and LM

The most vulnerable part of your network is still your users’ passwords. As you know, you need as
strong a password policy as possible without getting too much resistance from your user community.
However, it’s equally important to ensure that the passwords can’t be “stolen” on the wire. First, let
me review the available password authentication methods.
Clients can authenticate their passwords to a DC four ways. Those methods, listed from strongest
to weakest are
• Kerberos – Kerberos is the strongest authentication method. Kerberos ensures that both the client
and the server mutually authenticate each other or the password isn’t accepted. You’ll find
Kerberos authentication in Windows 2003 and Win2K DCs and in Win2K and XP clients.
When it’s available, Kerberos is the default authentication mechanism.
• NT LAN Manager (NTLM)v2 – NTLMv2 is the next strongest authentication method, and no
one’s cracked it yet. NTLMv2 enhances NTLM authentication by strengthening the encryption
mechanism.
• NTLM – NTLM includes password encryption as well as signing. However, inherent elements
make NTLM authentication easy to crack.
• LM – LM is the weakest authentication method. It’s the default authentication method for NT 4.0
without SP4 and for all Win9X machines.

The upshot is that the only two secure mechanisms for password validation are Kerberos and
NTLMv2. If intruders intend to capture traffic on the wire – and the traffic includes NTLM and LM
traffic from NT 4.0 SP3 and earlier or from Win9X – they would soon have the passwords that rely
on the weaker authentication methods.
My suggestion if you have mixed downlevel clients is to accept the default Windows 2003
security – and harden your overall security significantly by eliminating NTLM and LM authentication.
Eliminating the weaker authentication methods could be the most important security step for your
Windows 2003 network.
To eliminate NTLM and LM authentication, follow these steps:
1. Update the client software. For NT 4.0 machines, load SP4. For Win9X machines, load the
AD client, as I described previously.
2. Enable NTLMv2 authentication on the client.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

 Chapter 5 Windows Server 2003 Security Enhancements 89

3. At the domain level, refuse NTLM and LM authentication traffic; accept only Kerberos and
NTLMv2 traffic.

Enabling NTLMv2 Authentication at the Client

After you update NT 4.0 machines with SP4 or later and load the ADC on every Win9x client, you
need to take an additional step. The clients must be configured so that they won’t attempt to
authenticate through NTLM or LM, but rather with NTLMv2. Enabling authentication at the client is
slightly different for each client type, as I describe below.

NTLMv2 for NT 4.0 Clients

To set an NT 4.0 with SP4 or later client to use NTLMv2 only, you need to modify each computer’s
registry. In HKEY_LOCAL_MACHINE\System\CurrentControlSet\control\LSA subkey, locate the
LMCompatibilityLevel value and set it to 3 to permit NTLMv2 authentication only.

j Tip
You can set additional registry options at this time. For more information, read the Knowledge
Base article Q147706, “How to Disable LM Authentication on Windows NT,” at the URL
below.

http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb
/articles/q147/7/06.asp&NoWebContent=1

NTLMv2 for Win9X Clients

For both Win98 and Win95 clients, you must first load the ADC. However, Win95 also requires
several additional updates before you continue: the Distributed File System (DFS) client (which you
can download from http://microsoft.com/ntserver/nts/downloads/winfeatures/NTSDistrFile/default.asp)
along with two updates available in one package: WinSock 2.0 Update and Microsoft Dial Up
Networking (DUN) 1.3 (which you can download together from http://www.microsoft.com
/windows95/downloads/contents/WURecommended/S_WUNetworking/dunwinsky2k/Default.asp).
To set a Win9X client to use NTLMv2 only, you need to modify each computer’s registry. In the
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control subkey, create an LSA registry subkey.
Then, add the value LMCompatibility of type REG_DWORD and set the value to 3.

j Tip
You can set additional registry options at this time. For more information, read the Knowledge
Base article Q239869, “How to Enable NTLM 2 Authentication,” at the URL below.

http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb
/articles/q239/8/69.asp&nowebcontent=1

Brought to you by NetIQ and Windows & .NET Magazine eBooks

90 Windows 2003: Active Directory Administration Essentials

Disabling NTLM and LM at the Domain Level

After you’ve set up NTLMv2 support all your clients, you’re ready to disable both LM and NTLM
authentication at the DCs. You’ll perform this action inside the Domain Security policy. Once open,
navigate to Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options and locate the policy named Network Security: LAN Manager. With the Define this policy
setting check box selected, define the policy Send NTLMv2 response only\refuse LM & NTLM, from
the drop-down list that Figure 5.6 shows.

Figure 5.6
Defining authentication levels

d Caution
If you disable NTLM and LM responses, you lock out clients that support only those
authentication methods, including Macintosh clients and Services for UNIX (SFU) clients. The
disabling could also be harmful to alternate authentication methods such as Win2K Routing and
Remote Access Service (RRAS); Cisco, Shiva, or Ascend dial-in modems; and other products
that use Windows authentication. Such products might rely on NTLM or LM authentication.

Additionally, although it’s not strictly necessary, it’s also good to expunge the recorded traces of
LM passwords from your DCs. You can do so by selecting the Group Policy Network security: Do

Brought to you by NetIQ and Windows & .NET Magazine eBooks

 Chapter 5 Windows Server 2003 Security Enhancements 91

not store LAN Manager hash value on next password change policy, which Figure 5.7 shows. With
the Define this policy setting check box selected, you define and enable the policy.

Figure 5.7
Eliminating LM password hash values from DCs

After you’ve enabled this policy, the AD doesn’t store the LM values when users’ passwords are
changed. If a DC is compromised, no one will be able to use the values to gain access.

ACL Viewing and Editing Improvements

One day-to-day problem that Windows 2003 has overcome involves file permissions. With Win2K,
Microsoft added directory level inheritance; that is, if you had permissions, or rights, explicitly set
upon a folder, folders below the original folder automatically inherited those permissions, as the
diagram in Figure 5.8 shows.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

92 Windows 2003: Active Directory Administration Essentials

Figure 5.8
Overview of Win2K and Windows 2003 inheritance

Joe’s rights are explicitly

placed upon this folder The rights are simply
calculated via inheritance—
there need not be a specific
ACL on the folder

Inherited
Joe User

Directory1 Joe User

Sales
In
he

Directory2
rit
ed

Joe User
Marketing
Directory3

In Win2K, however, it was difficult to determine the effective permissions in a lower directory.
Effective permissions come into play whenever a user or group might have explicit permissions and
inherited permissions. How can you know what the effective permissions are?
For example, consider Directory 2 in Figure 5.8. What are Joe’s effective permissions if he inherits
rights from Directory1, but is also a member of Sales, which has its own permissions?
You can see that permissions could quickly become confusing. To combat this confusion,
Windows 2003 has added a new ACL editor that lets you easily discover and edit permissions. With
Windows 2003, you’ll find an Effective Permissions tab on every directory and file.
Simply right-click and select Properties for the directory or file whose effective permissions you
want to examine, select the security tab, and click the Advanced button. You can then click the
Effective Permissions tab, which Figure 5.9 shows.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

 Chapter 5 Windows Server 2003 Security Enhancements 93

Figure 5.9
Windows 2003’s new ACL editor

Just click Select, select a user or group, and you can see the precise access control placed upon
that object for a specific user or group. The new ACL editor makes knowing “who” has permissions
“where” a lot easier.

Security Principals Update

Win2K has many object types (e.g., users, groups, contacts, organizational units – OUs). Windows
2003 adds a new type of object: InetOrgPerson. In Windows 2003, an InetOrgPerson object has many
of the same features and attributes as a regular user object, including
• Name,
• Phone number,
• Logon account restrictions,
• Password

So why might you need the InetOrgPerson object if user objects already work well in Windows
2003? Because InetOrgPerson objects comply with Request for Comments (RFC) 2798, whereas
regular user objects don’t. This difference is a concern in a limited set of circumstances. You might
need InetOrgPerson objects if you use a third-party metadirectory service (e.g., Sun’s iPlanet) to

Brought to you by NetIQ and Windows & .NET Magazine eBooks

94 Windows 2003: Active Directory Administration Essentials

update both your AD and your iPlanet directory. iPlanet expects its input and output to be an
RFC-compliant InetOrgPerson object – not a Windows 2003/Win2K user object. You can check out
the InetOrgPerson RFC at http://www.faqs.org/rfcs/rfc2798.html. InetOrgPerson objects are easy to
create, potentially useful, and have few drawbacks.
You can create an InetOrgPerson object as easily as you create a new user object. Figure 5.10
shows how you create an InetOrgPerson object in the Active Directory Users and Computers console.

Figure 5.10
Creating an InetOrgPerson object

You can create your “User” objects the standard way or choose to make them “InetOrgPerson”
objects. You incur no penalty if you make your user objects InetOrgPerson objects rather than User
objects. However, you should continue to use regular User objects unless you know you need
InetOrgPerson objects to be 100 percent compatible with RFC-compliant metadirectory services.

d Caution
You should be aware that InetOrgPerson objects aren’t compatible with Exchange 2000.
That is, you can’t enable an InetOrgPerson mailbox.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

 Chapter 5 Windows Server 2003 Security Enhancements 95

Schema Updates and Modifications

Although modifying the schema is always risky, Windows 2003 makes it easier to write applications
that modify the schema and take full advantage of AD. If you upgraded your domain from Win2K to
Windows 2003, you already modified the schema by running Adprep.
Additionally, several Microsoft and third-party applications modify the schema. One Microsoft
application that modifies the schema is the upcoming Systems Management Server (SMS) 2003 (still in
beta), which Figure 5.11 shows.

Figure 5.11
SMS 2003 (not yet released) option to extend the schema

Schema updates have been permanent – until Windows 2003. That fact made many developers
hesitate to write applications that leveraged the advantages of a schema update. Win2K application
developers had a problem if they ever wanted to distribute an update to their application that
changed their use of the schema.
For example, if an application vendor had made a schema modification by adding an attribute
called SHOE SIZE, which accepted a numeric value – that modification might work well at the time.
However, if the vendor then wanted to update the attribute to accept a character (e.g., S, M, L) rather
than a numeric value, the vendor would have to introduce another schema modification attribute to
accept the value types desired. This situation occurred because “under the hood” of the schema, each
attribute is assigned a unique Object Identification Number (OID).

Brought to you by NetIQ and Windows & .NET Magazine eBooks

96 Windows 2003: Active Directory Administration Essentials

Win2K allows a schema attribute to be considered “defunct.” This ability to change the “status”
works well; however, if you consider the example above, in which the vendor wants to change the
SHOE SIZE attribute from accepting numbers to accepting characters, the vendor would have to get
another OID and code the application to insert yet another permanent schema addition to add the
new attribute.
Windows 2003 also lets a schema attribute be considered defunct. However, you can reuse the
underlying OID with a different name or value. Additionally, you can set attributes to be Defunct or
Active at any time.

n Note At no time is the attribute ever truly deleted. Rather, the attribute is classified as defunct so
that you can reuse its OID.

j Tip
According to rumor, future versions of AD will support “tombstoning” and purging defunct
schema definitions. Tombstoning is similar to deleting except that when you tombstone, you
inform other servers that you’re removing the schema object definitions so that those servers
can update their databases. Again, Windows 2003 doesn’t yet support these features.

If you have an attribute you want to designate as defunct, you’ll need to follow several steps,
as I outline below. First, you’ll need to register the schmmgmt.dll with regsv32.exe, as Figure 5.12
shows.
Figure 5.12
Registering the schmmgmt.dll

Brought to you by NetIQ and Windows & .NET Magazine eBooks

 Chapter 5 Windows Server 2003 Security Enhancements 97

d Caution
Any changes you make to the schema are at your own risk. Make changes to the schema only
in a test lab. To modify the schema, you must enter a registry value in the registry upon the
schema master. By default, AD servers don’t let anyone edit the schema.

To modify the schema, navigate to the HKLM\SYSTEM\CurrentControlSet\Services\NTDS

\Parameters subkey. Enter a value named Schema Update Allowed of type REG_DWORD and set it
to 1, as Figure 5.13 shows.

Figure 5.13
Entering a registry value before you modify the schema

Next, add the Active Directory Schema snap-in to the Microsoft Management Console (MMC).
Figure 5.14 shows how you select Active Directory Schema to add it as a standalone snap-in.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

98 Windows 2003: Active Directory Administration Essentials

Figure 5.14
Adding the Active Directory Schema snap-in

By default, you can’t see defunct objects. If you want to see them, right-click the Active Directory
Schema and select View, Defunct Objects, as Figure 5.15 shows.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

 Chapter 5 Windows Server 2003 Security Enhancements 99

Figure 5.15
The view inside the schema

To make an object defunct, locate the attribute, examine its properties, and clear the default
Attribute is active check box, as Figure 5.16 shows.

Figure 5.16
Clearing the Attribute is active check box

Brought to you by NetIQ and Windows & .NET Magazine eBooks

100 Windows 2003: Active Directory Administration Essentials

At this point, you can create a new attribute with the same OID but a different name and value
type. Windows 2003’s improved schema modification functions make it easier for application vendors
to write applications that modify the schema to get the most from AD.

Next: Backup, Restore, and Recovery

Windows 2003 definitely offers improved security – with SMB signing, secure channel signing, and
LDAP signing as the defaults. However, if you have clients on which you can’t load the service packs
or ADC to let them participate in these security measures, you might need to reduce server-side
security to let your clients function.
As the text makes clear, it might be a good idea to strengthen the fortress a bit by removing all
NTLM and LM communications, but be sure to test the impact of removal before you make your
move. (You don’t need hordes of angry laptop users who can’t connect through your third-party
dialup.)
Finally, the improvements in the ACL viewer and editor, the new InetOrgPerson object, and the
new schema modification functions are useful add-ons. All in all, Windows 2003 makes it a more
secure world.

Brought to you by NetIQ and Windows & .NET Magazine eBooks