Page 1 of 4

Transcription

Page 1 of 4

How To Create a New Zone on a DNS Server in Windows 2000
Page 1 of 4
This article was previously published under Q308201
On This Page
SUMMARY
Article ID
: 308201
Last Review : October 31, 2006
Revision
: 2.2
How to Create a Forward Lookup Zone
How to Modify the Forward Lookup Zone Properties
How to Create a Reverse Lookup Zone
How to Modify the Reverse Lookup Zone Properties
How to Create a Host Record
How to Add a CNAME
How to Add an MX Record
How to Add a Name Server
REFERENCES
SUMMARY
This article is a step-by-step guide for creating a Domain Name System (DNS) zone for a new domain.
How to Create a Forward Lookup Zone
A DNS zone is the range of IP addresses for which your DNS server hosts naming information in the DNS namespace.
The DNS Forward Lookup zone is used to resolve computer host names to an IP address ("forward name resolution").
To create a new forward lookup zone:
1.
Start the DNS snap-in. To do this, click Start, point to Programs, point to Administrative Tools, and then
click DNS.
2.
Under DNS, expand Host name (where Host name is the host name of the DNS server).
3.
Expand Forward Lookup Zones.
4.
Right-click Forward Lookup Zones, and then click New Zone. The New Zone Wizard starts. Click Next to
continue.
5.
Click Standard primary, and then click Next.
6.
In the Name box, type the name of the zone.
The name of the zone should be the same as the DNS suffix of the host computers for which you want to
create the zone. For example, type example.com, and then click Next.
7.
On the Zone File page, click Next, and then click Finish.
The new zone is listed under Forward Lookup Zones in the DNS tree.
How to Modify the Forward Lookup Zone Properties
To modify or verify the zone properties:
1.
click DNS.
2.
3.
4.
Under Forward Lookup Zones, right-click the zone that you want (for example, example.com), and then
click Properties.
5.
In the Allow dynamic updates list, click Yes.
6.
Click the Start of Authority (SOA) tab.
7.
In the Responsible person box, type the e-mail address that you want (in the format of
"username.domain.com"). For example, if the e-mail address is [email protected], type
http://support.microsoft.com/kb/308201
1/11/2007
Page 2 of 4
support.example.com.
8.
Click Apply, and then click OK.
How to Create a Reverse Lookup Zone
The Reverse Lookup zone resolves IP addresses to computer host names in the DNS namespace ("reverse name
resolution").
To create a new reverse lookup zone:
1.
click DNS.
2.
3.
Expand Reverse Lookup Zones.
4.
Right-click Reverse Lookup Zones, and then click New Zone. The New Zone Wizard starts. Click Next to
continue.
5.
Click Standard primary, and then click Next.
6.
In the Network ID box, type the network ID.
The network ID is the portion of the TCP/IP address that identifies the network. For example, type 192.168.0,
and then click Next.For additional information about TCP/IP networks, click the article number below to view
the article in the Microsoft Knowledge Base:
164015 (http://support.microsoft.com/kb/164015/EN-US/) Understanding TCP/IP Addressing and Subnetting
Basics
7.
On the Zone File page, click Next, and then click Finish.
The new zone is listed under Reverse Lookup Zones in the DNS tree.
How to Modify the Reverse Lookup Zone Properties
To modify or verify the zone properties:
1.
click DNS.
2.
3.
Expand Reverse Lookup Zones.
4.
Under Reverse Lookup Zones, right-click the zone that you want (for example, 102.168.0.x Subnet), and
then click Properties.
5.
In the Allow dynamic updates list, click Yes.
6.
Click the Start of Authority (SOA) tab.
7.
In the Responsible person box, type the e-mail address that you want (in the format of
"username.domain.com"). For example, if the e-mail address is [email protected], type
support.example.com.
8.
Click Apply, and then click OK.
NOTE: When you create the forward and reverse lookup zones, the DNS service automatically creates an "A" record
for the DNS server. However, it does not create a PTR, or reverse lookup record, for the DNS server.
To create a PTR record for the DNS server:
1.
Right-click the reverse lookup zone (for example, 192.168.0.x Subnet), and then click New Pointer.
2.
In the Host IP number box, type the host portion of the DNS server IP address. For example, if the DNS
server is on a "C" class network and has an IP address of 192.168.0.10, the host portion of the IP address is
10. In this case, type 10.
3.
In the Host name box, type the host name of the DNS server. For example, type dnsserv.example.com.
4.
Click OK.
1/11/2007
Page 3 of 4
How to Create a Host Record
Each computer requires a host record or "A" record to identify the computer in the DNS system. The host record
consists of the host name of the computer along with its corresponding IP address.
To create a host or "A" record:
1.
click DNS.
2.
3.
4.
click New Host.
5.
In the Name (uses parent domain name if blank) box, type the name of the host that you want to add.
For example, if you want to add a host record for a Web server, type www.
6.
In the IP address box, type the IP address of the host that you want to add. For example, type
192.168.0.100.
7.
Select the Create associated pointer (PTR) record check box, and then click Add Host. A message similar
to the following message appears:
The host record www.example.com was successfully created.
Click OK.
8.
When you are finished adding hosts, click Done.
How to Add a CNAME
A CNAME (or "Canonical Name") is an alias or an additional host name that is resolved to the IP address of an existing
host computer in the DNS namespace. For example, if you use the same computer as both a Web server and an FTP
server, you may want to resolve both the WWW host name and the FTP host name to the same IP address. Using a
CNAME, you can resolve both names to the same IP address.
To create a CNAME:
1.
click DNS.
2.
3.
4.
click New Alias.
5.
In the Alias name box, type the alias that you want. For example, type ftp.
6.
In the Fully qualified name for target host box, type the fully qualified host name of the host computer
that you want. For example, type www.example.com, and then click OK.
How to Add an MX Record
An MX (or "Mail Exchanger") record is used to identify a host computer as a Simple Mail Transport Protocol
(SMTP)/Post Office Protocol (POP3) server. To add an MX record, use the following steps. Note that you must first
create the "A" record for the mail server host.
1.
click DNS.
2.
3.
4.
Right-click the zone that you want (for example, example.com), and then click New Mail Exchanger.
5.
In the Mail server box, type the fully qualified domain name of the host computer that acts as the mail
server. For example, type mail.example.com.
1/11/2007
6.
Page 4 of 4
Click OK.
How to Add a Name Server
To identify an additional name server:
1.
click DNS.
2.
3.
4.
click Properties.
5.
Click the Name Servers tab, and then click Add.
6.
In the Server name box, type the host name of the server that you want to add. For example, type
namesvr2.example.com.
7.
In the IP address box, type the IP address of the Name server that you want to add (for example, type
192.168.0.22), and then click Add.
8.
Click OK, and then click OK to return to the DNS window.
9.
Expand Reverse Lookup Zones, right-click the zone that you want, and then click Properties.
10.
Click the Name Servers tab, and then click Add.
11.
In the Server name box, type the host name of the server that you want to add. For example, type
namesvr2.example.com.
12.
In the IP address box, type the IP address of the Name server that you want to add (for example, type
192.168.0.22), and then click Add.
13.
Click OK, and then click OK to return to the DNS window.
REFERENCES
For additional information about installing and configuring DNS, click the article numbers below to view the articles in
the Microsoft Knowledge Base:
172953 (http://support.microsoft.com/kb/172953/EN-US/) How to Install and Configure Microsoft DNS Server
238797 (http://support.microsoft.com/kb/238797/EN-US/) Microsoft DNS Server Installation and Configuration
Document Available on Windows NT FTP Site
1/11/2007
Frequently asked questions about Windows 2000 DNS and Windows Server 2003 DNS
Page 1 of 3
Frequently asked questions about Windows 2000 DNS and Windows
Server 2003 DNS
This article was previously published under Q291382
On This Page
SUMMARY
Article ID
: 291382
Last Review : November 1, 2006
Revision
: 9.1
MORE INFORMATION
Additional Resources
SUMMARY
This article describes DNS functionality in Windows 2000 and Windows Server 2003, and provides answers to
frequently asked questions about Windows 2000 and Windows Server 2003 DNS.
MORE INFORMATION
DNS is the backbone of Active Directory and the primary name resolution mechanism of Windows 2000 and Windows
Server 2003. Windows 2000 and Windows Server 2003 domain controllers dynamically register information about
themselves and about Active Directory in DNS. Other Windows 2000 and Windows Server 2003 domain controllers,
servers, and workstations that are part of the domain query DNS to find Active Directory-related information. If DNS
is not set up correctly, domain-wide issues can occur such as replication between domain controllers. You may also be
unable to log on to the domain or to join the domain from a workstation or server.
Question: What are the common mistakes that are made when administrators set up DNS on network that contains a
single Windows 2000 or Windows Server 2003 domain controller?
Answer: The most common mistakes are:
• The domain controller is not pointing to itself for DNS resolution on all network interfaces.
• The "." zone exists under forward lookup zones in DNS.
• Other computers on the local area network (LAN) do not point to the Windows 2000 or Windows Server 2003
DNS server for DNS.
Question: Why do I have to point my domain controller to itself for DNS?
Answer: The Netlogon service on the domain controller registers a number of records in DNS that enable other
domain controllers and computers to find Active Directory-related information. If the domain controller is pointing to
the Internet service provider's (ISP) DNS server, Netlogon does not register the correct records for Active Directory,
and errors are generated in Event Viewer. In Windows Server 2003, the recommended DNS configuration is to
configure the DNS client settings on all DNS servers to use themselves as their own primary DNS server, and to use a
different domain controller in the same domain as their alternative DNS server, preferably another domain controller
in the same site. This process also works around the DNS "Island" problem in Windows 2000. You must always
configure the DNS client settings on each domain controller's network interface to use the alternative DNS server
addresses in addition to the primary DNS server address.
For more information about the Windows 2000 DNS "Island" problem, see "Chapter 2 - Structural Planning for Branch
Office Environments" in the "Planning" section of the Windows 2000 Server Active Directory Branch Office Planning
Guide at the following Microsoft Web site:
http://www.microsoft.com/windows2000/techinfo/planning/activedirectory/branchoffice/default.asp (http://www.microso
ft.com/windows2000/techinfo/planning/activedirectory/branchoffice/default.asp)
Question: What does a domain controller register in DNS?
Answer: The Netlogon service registers all the SRV records for that domain controller. These records are displayed as
the _msdcs, _sites, _tcp, and _udp folders in the forward lookup zone that matches your domain name. Other
computers look for these records to find Active Directory-related information.
Question: Why can't I use WINS for name resolution like it is used in Microsoft Windows NT 4.0?
Answer: A Windows 2000 or Windows Server 2003 domain controller does not register Active Directory-related
information with a WINS server; it only registers this information with a DNS server that supports dynamic updates
such as a Windows 2000 or Windows Server 2003 DNS server. Other Windows 2000-based and Windows Server 2003based computers do not query WINS to find Active Directory-related information.
1/11/2007
Page 2 of 3
Question: If I remove the ISP's DNS server settings from the domain controller, how does it resolve names such as
Microsoft.com on the Internet?
Answer: As long as the "." zone does not exist under forward lookup zones in DNS, the DNS service uses the root
hint servers. The root hint servers are well-known servers on the Internet that help all DNS servers resolve name
queries.
Question: What is the "." zone in my forward lookup zone?
Answer: This setting designates the Windows 2000 or Windows Server 2003 DNS server to be a root hint server and
is usually deleted. If you do not delete this setting, you may not be able to perform external name resolution to the
root hint servers on the Internet.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
229840 (http://support.microsoft.com/kb/229840/) DNS server's root hints and forwarder pages are unavailable
Question: Do I need to configure forwarders in DNS?
Answer: No. By default, Windows 2000 DNS uses the root hint servers on the Internet; however, you can configure
forwarders to send DNS queries directly to your ISP's DNS server or other DNS servers. Most of the time, when you
configure forwarders, DNS performance and efficiency increases, but this configuration can also introduce a point of
failure if the forwarding DNS server is experiencing problems. The root hint server can provide a level of redundancy
in exchange for slightly increased DNS traffic on your Internet connection. Windows Server 2003 DNS will query root
hints servers if it cannot query the forwarders.
Question: Should I point the other Windows 2000-based and Windows Server 2003-based computers on my LAN to
my ISP's DNS servers?
Answer: No. If a Windows 2000-based or Windows Server 2003-based server or workstation does not find the
domain controller in DNS, you may experience issues joining the domain or logging on to the domain. A Windows
2000-based or Windows Server 2003-based computer's preferred DNS setting should point to the Windows 2000 or
Windows Server 2003 domain controller running DNS. If you are using DHCP, make sure that you view scope option
#15 for the correct DNS server settings for your LAN.
Question: Do I need to point computers that are running Windows NT 4.0 or Microsoft Windows 95, Microsoft
Windows 98, or Microsoft Windows 98 Second Edition to the Windows 2000 or Windows Server 2003 DNS server?
Answer: Legacy operating systems continue to use NetBIOS for name resolution to find a domain controller; however
it is recommended that you point all computers to the Windows 2000 or Windows Server 2003 DNS server for name
resolution.
Question: What if my Windows 2000 or Windows Server 2003 DNS server is behind a proxy server or firewall?
Answer: If you are able to query the ISP's DNS servers from behind the proxy server or firewall, Windows 2000 and
Windows Server 2003 DNS server is able to query the root hint servers. UDP and TCP Port 53 should be open on the
proxy server or firewall.
Question: What should I do if the domain controller points to itself for DNS, but the SRV records still do not appear in
the zone?
Answer: Check for a disjointed namespace, and then run Netdiag.exe /fix. You must install Support Tools from the
Windows 2000 Server or Windows Server 2003 CD-ROM to run Netdiag.exe.
For more information about how to check for a disjointed namespace, click the following article number to view the
article in the Microsoft Knowledge Base:
257623 (http://support.microsoft.com/kb/257623/) The DNS suffix of the computer name of a new domain controller
may not match the name of the domain after you install upgrade a Windows NT 4.0 Primary domain controller
to Windows 2000
Question: How do I set up DNS for a child domain?
Answer: To set up DNS for a child domain, create a delegation record on the parent DNS server for the child DNS
server. Create a secondary zone on the child DNS server that transfers the parent zone from the parent DNS server.
Note Windows Server 2003 has additional types of zones, such as Stub Zones and forest-level integrated Active
1/11/2007
Page 3 of 3
Directory zones, that may be a better fit for your environment.
Set the child domain controller to point to itself first. As soon as an additional domain controller is available, set the
child domain controller to point to this domain controller in the child domain as its secondary.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
255248 (http://support.microsoft.com/kb/255248/) How to create a child domain in Active Directory and delegate the
DNS namespace to the child domain
Additional Resources
241505 (http://support.microsoft.com/kb/241505/) SRV records missing after implementing Active Directory and
Domain Name System
247811 (http://support.microsoft.com/kb/247811/) How domain controllers are located in Windows
249868 (http://support.microsoft.com/kb/249868/) Replacing root hints with the Cache.dns file
1/11/2007
Creating User and Group Accounts in Windows 2000
Page 1 of 9
Creating User and Group Accounts
from Chapter 8, Microsoft Windows 2000 Administrator's Pocket Consultant by William R. Stanek.
A key part of your job as an administrator is to create user accounts, and this chapter will show you how to do
that.
User accounts allow Microsoft Windows 2000 to track and manage information about users, including
permissions and privileges. When you create user accounts, the primary account administration tools you use
are
•
Active Directory Users And Computers, which is designed to administer accounts throughout an Active
Directory domain.
•
Local Users And Groups, which is designed to administer accounts on a local computer.
Creating domain accounts as well as local users and groups is covered in this chapter.
User Account Setup and Organization
The most important aspects of account creation are account setup and organization. Without the appropriate
policies, you could quickly find that you need to rework all your user accounts. So before you create accounts,
determine the policies you'll use for setup and organization.
Account Naming Policies
A key policy you'll need to set is the naming scheme for accounts. User accounts have display names and logon
names. The display name (or full name) is the name displayed to users and the name referenced in user
sessions. The logon name is the name used to log on to the domain. Logon names were discussed briefly in the
section of Chapter 7 entitled "Logon Names, Passwords, and Public Certificates."
Rules for Display Names
In Windows 2000, the display name is normally the concatenation of the user's first name and last name, but
you can set it to any string value. The display names must follow these rules:
•
•
•
•
Local display names must be unique on a workstation.
Display names must be unique throughout a domain.
Display names must be no more than 64 characters long.
Display names can contain alphanumeric characters and special characters.
Rules for Logon Names
Logon names must follow these rules:
•
Local logon names must be unique on a workstation and global logon names must be unique throughout a
domain.
•
Logon names can be up to 104 characters. However, it isn't practical to use logon names that are longer than
64 characters.
•
A Microsoft Windows NT version 4.0 or earlier logon name is given to all accounts, which by default is set to
the first 20 characters of the Windows 2000 logon name. The Windows NT version 4.0 or earlier logon name
must be unique throughout a domain.
•
Users logging on to the domain from Windows 2000 computers can use their Windows 2000 logon name or
their Windows NT version 4.0 or earlier logon name, regardless of the domain operations mode.
http://thesource.ofallevil.com/technet/prodtechnol/windows2000serv/deploy/confeat/08w2... 1/10/2007
•
Page 2 of 9
Logon names can't contain certain characters. Invalid characters are
" / \ [ ] : ; | = , + * ? < >
•
Logon names can contain all other special characters, including spaces, periods, dashes, and underscores.
But it's generally not a good idea to use spaces in account names.
Note: Although Windows 2000 stores user names in the case that you enter, user names aren't case sensitive.
For example, you can access the Administrator account with the user name Administrator or administrator.
Thus, user names are case aware but not case sensitive.
Naming Schemes
You'll find that most small organizations tend to assign logon names that use the user's first or last name. But
you can have several Toms, Dicks, and Harrys in an organization of any size. So rather than having to rework
your logon naming scheme when you run into problems, select a good naming scheme now and make sure
other administrators use it. For naming accounts, you should use a consistent procedure that allows your user
base to grow and limits the possibility of name conflicts and ensures that your accounts have secure names that
aren't easily exploited. If you follow these guidelines, the types of naming schemes you may want to use
include:
•
User's first name and last initial You take the user's first name and combine it with the first letter of the
last name to create the logon name. For William Stanek, you would use williams or bills. This naming scheme
isn't practical for large organizations.
•
User's first initial and last name You take the user's first initial and combine it with the last name to
create the logon name. For William Stanek, you would use wstanek. This naming scheme isn't practical for
large organizations, either.
•
User's first initial, middle initial, and last name You combine the user's first initial, middle initial, and
last name to create the logon name. For William R. Stanek, you would use wrstanek.
•
User's first initial, middle initial, and first five characters of the last name You combine the user's
first initial, middle initial, and the first five characters of the last name to create the logon name. For William
R. Stanek, you would use wrstane.
•
User's first name and last name You combine the user's first and last name. To separate the names, you
could use the underscore character ( _ ) or hyphen (-). For William Stanek, you could use william_ stanek or
william-stanek.
Tip In tight security environments, you can assign a numeric code for the logon name. This numeric code
should be at least 20 characters long. Combine this strict naming method with smart cards and smart card
readers to allow users to quickly log on to the domain. Don't worry, users can still have a display name that
humans can read.
Password and Account Policies
Windows 2000 accounts use passwords and public certificates to authenticate access to network resources. This
section focuses on passwords.
Secure Passwords
A password is a case-sensitive string that can contain up to 104 characters with Active Directory directory
service and up to 14 characters with Windows NT Security Manager. Valid characters for passwords are letters,
numbers, and symbols. When you set a password for an account, Windows 2000 stores the password in an
encrypted format in the account database.
But simply having a password isn't enough. The key to preventing unauthorized access to network resources is
to use secure passwords. The difference between an average password and a secure password is that secure
passwords are difficult to guess and crack. You make passwords difficult to crack by using combinations of all
the available character types—including lowercase letters, uppercase letters, numbers, and symbols. For
Page 3 of 9
example, instead of using happydays for a password you would use haPPy2Days&, Ha**y!dayS, or even
h*PPY%d*ys.
Unfortunately, no matter how secure you initially make a user's password, eventually the user usually chooses
the password. Because of this, you'll want to set account policies. Account policies are a subset of the policies
configurable as a group policy.
Setting Account Policies
As you know from previous discussions, you can apply group policies at various levels within the network
structure. You manage local group policies in the manner discussed in the section of Chapter 4 entitled
"Managing Local Group Policies." You manage global group policies as explained in the section of Chapter 4
entitled "Managing Site, Domain, and Unit Policies."
Once you access the group policy container you want to work with, you can set account policies by completing
the following steps:
1.
As shown in Figure 8-1, access the Account Policies node by working your way down the console tree.
Expand Computer Configuration, then Windows Settings, and then Security Settings.
2.
You can now manage account policies through the Password Policy, Account Lockout Policy, and Kerberos
Policy nodes.
Note: Kerberos policies aren't used with local computers. Kerberos policies are only available with group
policies that affect sites, domains, and organizational units.
Figure 8-1: Use entries in the Account Policies
node to set policies for passwords and general
account use. The console tree shows the name of
the computer or domain you're configuring. Be
sure this is the appropriate network resource to
configure.
Page 4 of 9
Figure 8-2: With local policies,
you'll see the effective policy as
well as the local policy.
3.
To configure a policy, double-click its entry or right-click on it and select Security. This opens a
Properties dialog box for the policy.
4.
For a local policy, the Properties dialog box is similar to the one shown in Figure 8-2. The effective policy
for the computer is displayed but you can't change it. You can change the local policy settings, however.
Use the fields provided to configure the local policy. For a local policy, skip the remaining steps; those
steps apply to global group policies.
Note: Site, domain, and organizational unit policies have precedence over local policies.
5.
For a site, domain, or organizational unit, the Properties dialog box is similar to the one shown in Figure
8-3.
Figure 8-3: Define and configure
global group policies using their
Properties dialog box.
6.
All policies are either defined or not defined. That is, they are either configured for use or not configured
for use. A policy that isn't defined in the current container could be inherited from another container.
7.
Select or clear the Define This Policy Setting check box to determine whether a policy is defined.
Tip Policies can have additional fields for configuring the policy. Often, these fields are option buttons labeled
Enabled and Disabled. Enabled turns on the policy restriction. Disabled turns off the policy restriction.
Specific procedures for working with account policies are discussed in the sections of the chapter entitled
"Configuring Password Policies," "Configuring Account Lockout Policies," and "Configuring Kerberos Policies."
This chapter's next section, "Viewing Effective Policies," will teach you more about viewing the effective policy
on a local computer.
Viewing Effective Policies
When working with account policies and user rights assignment, you'll often want to view the effective policy on
a local system. The effective policy is the policy being enforced and, as discussed in Chapter 4 under "Group
Page 5 of 9
Policy Management," the effective policy depends on the order in which you apply the policies.
To view the effective policy on a local system, complete the following steps:
1.
Access the local policy for the system you want to work with, as explained in the section of Chapter 4
entitled "Managing Local Group Policies." Or select Local Policy Settings on the Administrative Tools
menu (if these tools are installed and you're currently logged on to the computer you want to examine).
2.
Access the policy node that you want to examine. Figure 8-4 shows the Password Policy node.
3.
With local policies, the Computer Setting column is replaced by a Local Setting column and an Effective
Setting column. The Local Setting column shows the local policy settings. The Effective Setting column
shows the policy settings that are being enforced on the local computer.
4.
If there are policy conflicts that you want to track down, review the sections of Chapter 4 entitled "In
What Order Are Multiple Policies Applied?" and "When Are Group Policies Applied?"
Configuring Account Policies
As you learned in the previous section, there are three types of account policies: password policies, account
lockout policies, and Kerberos policies. The sections that follow show you how to configure each one of these
policies.
Figure 8-4: Local policies show the effective
setting as well as the local setting.
Configuring Password Policies
Password policies control security for passwords and they include
•
•
•
•
•
•
Enforce Password History
Maximum Password Age
Minimum Password Age
Minimum Password Length
Passwords Must Meet Complexity Requirements
Store Password Using Reversible Encryption For All Users In The Domain
The uses of these policies are discussed in the following sections.
Enforce Password History
Enforce Password History sets how frequently old passwords can be reused. You can use this policy to
discourage users from changing back and forth between a set of common passwords. Windows 2000 can store
up to 24 passwords for each user in the password history. By default, Windows 2000 stores one password in the
password history.
Page 6 of 9
To disable this feature, set the size of the password history to zero. To enable this feature, set the size of the
password history using the Passwords Remember field. Windows 2000 will then track old passwords using a
password history that is unique for each user, and users won't be allowed to reuse any of the stored passwords.
Note: To discourage users from cheating Enforce Password History, you shouldn't allow them to change
passwords immediately. This will prevent users from changing their passwords several times to get back to their
old passwords.
Maximum Password Age
Maximum Password Age determines how long users can keep a password before they have to change it. The
aim is to periodically force users to change their passwords. When you use this feature, set a value that makes
sense for your network. Generally, you use a shorter period when security is very important and a longer period
when security is less important.
The default expiration date is 42 days, but set it to any value from 0 to 999. A value of zero specifies that
passwords don't expire. Although you may be tempted to set no expiration date, users should change
passwords regularly to ensure the network's security. Where security is a concern, good values are 30, 60, or
90 days. Where security is less important, good values are 120, 150, or 180 days.
Note: Windows 2000 notifies users when they're getting close to the password expiration date. Anytime the
expiration date is less than 30 days away, users see a warning when they log on that they have to change their
password within so many days.
Minimum Password Age
Minimum Password Age determines how long users must keep a password before they can change it. You can
use this field to prevent users from cheating the password system by entering a new password and then
changing it right back to the old one.
By default, Windows 2000 lets users change their passwords immediately. To prevent this, set a specific
minimum age. Reasonable settings are from three to seven days. In this way, you make sure that users are less
inclined to switch back to an old password but are able to change their passwords in a reasonable amount of
time if they want to.
Minimum Password Length
Minimum Password Length sets the minimum number of characters for a password. If you haven't changed the
default setting, you'll want to do so immediately. The default is to allow empty passwords (passwords with zero
characters), which is definitely not a good idea.
For security reasons, you'll generally want passwords of at least eight characters. The reason for this is that
long passwords are usually harder to crack than short ones. If you want greater security, set the minimum
password length to 14 characters.
Passwords Must Meet Complexity Requirements
Beyond the basic password and account policies, Windows 2000 includes facilities for creating additional
password controls. These facilities are available in the password filters, which can be installed on a domain
controller. If you've installed a password filter, enable Passwords Must Meet Complexity Requirements.
Passwords are then required to meet the filter's security requirement.
For example, the standard Windows NT filter (PASSFILT.DLL) enforces the use of secure passwords that follow
these guidelines:
•
•
•
Passwords must be at least six characters long.
Passwords can't contain the user name, such as stevew, or parts of the user's full name, such as Steve.
Passwords must use three of the four available character types: lowercase letters, uppercase letters,
numbers, and symbols.
Page 7 of 9
Store Password Using Reversible Encryption
Passwords in the password database are encrypted. This encryption can't normally be reversed. If you want to
allow the encryption to be reversed, enable Store Password Using Reversible Encryption For All Users In The
Domain. Passwords are then stored with reversible encryption and can be recovered in case of emergency.
Forgetting a password in not an emergency situation. Any administrator can change user passwords.
Configuring Account Lockout Policies
Account lockout policies control how and when accounts are locked out of the domain or the local system. These
policies are
•
•
•
Account Lockout Threshold
Account Lockout Duration
Reset Account Lockout Threshold After
Account Lockout Threshold
Account Lockout Threshold sets the number of logon attempts that are allowed before an account is locked out.
If you decide to use lockout controls, you should set this field to a value that balances the need to prevent
account cracking against the needs of users who are having difficulty accessing their accounts.
The main reason users may not be able to access their accounts properly the first time is that they forgot their
passwords. If this is the case, it may take them several attempts to log on properly. Workgroup users could also
have problems accessing a remote system where their current passwords don't match the passwords the
remote system expects. If this happens, several bad logon attempts may be recorded by the remote system
before the user ever gets a prompt to enter the correct password. The reason is that Windows 2000 may
attempt to automatically log on to the remote system. In a domain environment, this normally doesn't happen
because of the Single Log-On feature.
You can set the lockout threshold to any value from 0 to 999. The lockout threshold is set to zero by default,
which means that accounts won't be locked out because of invalid logon attempts. Any other value sets a
specific lockout threshold. Keep in mind that the higher the lockout value, the higher the risk that a hacker may
be able to break into your system. A reasonable range of values for this threshold is between 7 and 15. This is
high enough to rule out user error and low enough to deter hackers.
Account Lockout Duration
If someone violates the lockout controls, Account Lockout Duration sets the length of time the account is locked.
You can set the lockout duration to a specific length of time using a value between 1 and 99,999 minutes or to
an indefinite length of time by setting the lockout duration to zero.
The best security policy is to lock the account indefinitely. When you do, only an administrator can unlock the
account. This will prevent hackers from trying to access the system again and will force users who are locked
out to seek help from an administrator, which is usually a good idea. By talking to the user, you can determine
what the user is doing wrong and help the user avoid problems.
Tip When an account is locked out, access the Properties dialog box for the account in Active Directory Users
And Computers. Then click the Account tab and clear the Account Is Locked Out check box. This unlocks the
account.
Reset Account Lockout Threshold After
Every time a logon attempt fails, Windows 2000 raises the value of a threshold that tracks the number of bad
logon attempts. Reset Account Lockout Threshold After determines how long the lockout threshold is
maintained. This threshold is reset in one of two ways. If a user logs on successfully, the threshold is reset. If
the waiting period for Reset Account Lockout Threshold After has elapsed since the last bad logon attempt, the
threshold is also reset.
By default, the lockout threshold is maintained for one minute, but you can set any value from 1 to 99,999
minutes. As with Account Lockout Threshold, you need to select a value that balances security needs against
Page 8 of 9
user access needs. A good value is from one to two hours. This waiting period should be long enough to force
hackers to wait longer than they want to before trying to access the account again.
Note: Bad logon attempts to a workstation against a password-protected screen saver don't increase the
lockout threshold. Similarly, if you lock a server or workstation using Ctrl+Alt+Delete, bad logon attempts
against the Unlock dialog box don't count.
Configuring Kerberos Policies
Kerberos version 5 is the primary authentication mechanism used in an Active Directory domain. To verify the
identification of users and network services, Kerberos uses service tickets and user tickets. As you might
expect, service tickets are used by Windows 2000 service processes and user tickets are used by user
processes. Tickets contain encrypted data that confirm the identity of the user or service.
You can control ticket duration, renewal, and enforcement through the following policies:
•
•
•
•
•
Enforce User Logon Restrictions
Maximum Lifetime For Service Ticket
Maximum Lifetime For User Ticket
Maximum Lifetime For User Ticket Renewal
Maximum Tolerance For Computer Clock Synchronization
These policies are discussed in the sections that follow.
Caution: Only administrators with an intimate understanding of Kerberos security should change these policies.
If you change these policies to inefficient settings, you may cause serious problems on the network. In most
cases the default Kerberos policy settings work just fine.
Enforce User Logon Restrictions
Enforce User Logon Restrictions ensures that any restrictions placed on a user account are enforced. For
example, if the user's logon hours are restricted, this policy is what enforces the restriction. By default, the
policy is enabled and should only be disabled in rare circumstances.
Maximum Lifetime
Maximum Lifetime For Service Ticket and Maximum Lifetime For User Ticket set the maximum duration for
which a service or user ticket is valid. By default, service tickets have a maximum duration of 41,760 minutes
and user tickets have a maximum duration of 720 hours.
You can change the duration of tickets. For service tickets, the valid range is from 0 to 99,999 minutes. For user
tickets, the valid range is from 0 to 99,999 hours. A value of zero effectively turns off expiration. Any other
value sets a specific ticket lifetime.
A ticket that expires can be renewed, provided the renewal takes place within the time set for Maximum
Lifetime For User Ticket Renewal. By default, the maximum renewal period is 60 days. You can change the
renewal period to any value from 0 to 99,999 days. A value of zero effectively turns off the maximum renewal
period and any other value sets a specific renewal period.
Maximum Tolerance
Maximum Tolerance For Computer Clock Synchronization is one of the few Kerberos policies that you may need
to change. By default, computers in the domain must be synchronized within five minutes of each other. If they
aren't, authentication fails.
If you have remote users that log on to the domain without synchronizing their clock to the network timeserver,
you may need to adjust this value. You can set any value from 0 to 99,999.
from Microsoft Windows 2000 Administrator's Pocket Consultant by William R. Stanek. Copyright © 1999
Page 9 of 9
Microsoft Corporation.
Click to order
NAP offers a network access control solution for SMBs
Page 1 of 2
NAP offers a network access control solution for
SMBs
by Deb Shinder | More from Deb Shinder | 1/5/07
Tags: Hardware servers | Windows Vista | Microsoft Windows | Network security
Article
Comments: 1 | 1 NEW | View all
Save to my Workspace
E-mail Article
Rating: Not yet rated Rate it
Print Article
Takeaway: SMBs are increasingly faced with security threats posed by the computers
that connect to their networks. Microsoft's new NAP technology can give you control over
the health status of both remote access and on-site clients as your organization grows.
Protecting the network is an important goal of any IT security strategy, and there are a
number of sophisticated mechanisms that can give you better control of who accesses
the network and how they do it. Unfortunately, small and medium businesses often
perceive the available third-party products as too complex and/or expensive to be
feasible. For example, Cisco's Network Admission Control (NAC) appliance can cost
several thousand dollars. That may be more than small businesses on a budget can
afford.
But if you plan to upgrade your network operating systems to the next generation of
Windows Server (currently called Longhorn), the Network Access Protection (NAP)
platform is already built in and can be used with Windows Vista or with XP clients running
the NAP Client add-on software for XP that’s scheduled to be released at the same time
as the new server OS (the XP NAP client is currently in beta testing). Windows Server
2003 will also be able to be a NAP client.
SMBs can take advantage of this core component of Longhorn Server and Vista to
ensure that clients connecting to their networks meet their health and security criteria.
The importance of protecting network access
Every computer that connects to your local area network poses a potential threat. If it’s
infected with a virus or spyware, if it doesn’t have adequate firewall protection, has had
the latest security updates and patches installed, etc., the entire network can be placed at
risk. You have some control over the on-site computers, but what about those that
connect to the LAN via remote access, or the laptops that employees bring to work with
them after having connected them to home or public networks?
To protect your network, you should set policies requiring that before it can connect to
your LAN, a computer has to meet minimum "health" standards. But you can’t always
trust users to comply voluntarily, so you need an enforcement mechanism that can
determine whether a system meets the standards and prevent it from connecting, or
restrict its access, if it doesn’t. That’s where NAP comes in; it’s Microsoft’s health policy
compliance platform.
At first glance, NAP may sound a lot like Windows Server 2003’s Network Access
Quarantine Control (NAQC), which can be used to enforce policies for remote access
dialup and VPN connections to a Server 2003 system, but it’s a different technology and
does much more. NAQC is only for remote access clients, whereas NAP is designed to
protect the health of all systems that connect to your network.
http://articles.techrepublic.com.com/5100-1009_11-6147167.html
1/9/2007
Page 2 of 2
For example, with NAP you can enforce IPsec policies to specify requirements for secure
communications, enforce 802.1x policies for wireless clients, along with enforcement of
health policies on VPN clients. You can also use the DHCP enforcement feature to
enforce the health policy whenever a computer tries to renew or obtain a new IP address
via DHCP. NAP also has the ability to interoperate with Cisco’s NAC.
With NAQC, you have to write custom scripts and use command line tools to manually
configure the behavior. It is possible to use NAQC and NAP at the same time, but in most
cases NAP with replace NAQC.
Page: 1 | 2 | Next Page
http://articles.techrepublic.com.com/5100-1009_11-6147167.html
1/9/2007
Page 1 of 2
NAP offers a network access control solution for
SMBs
Page 2 of 2
How NAP works
NAP allows you to define the policies you want to apply to computers that connect to the
network and check each connecting computer against that set of policies. You also have
options as to what happens if a computer is non-compliant. For example:
You can allow it to access the network anyway, with information noted in the log so you
can follow up and see that the computer is brought into compliance.
You can allow it to only access a restricted network, rather than the entire LAN. This is
useful so you can provide resources on the restricted network that the user can use to
bring the computer into compliance (for example, required security updates or antivirus software and updates). You can also restrict the amount of time that a noncompliant computer can access the network.
It can be automatically updated to bring it into compliance, using SMS or other systems
management programs.
Components of NAP
The components in Windows Vista and Longhorn Server that verify a computer's health
are called system health agents (SHAs) and system health validators (SHVs). Third-party
software vendors can provide SHAs and SHVs in their software for interoperability with
NAP.
The SHA runs on the NAP clients and provides information about the client’s health
status. The SHV runs on the server and validates whether the health information provided
by the SHA complies with your policies. The health policy is configured on the NPS
server. The NPS server components include both a NAP Administration Server and a
NAP Enforcement Server. User and computer account information, including network
access properties, is stored in Active Directory.
You can also use health certificates obtained from a certification authority to prove
compliance. In that case, you need a Longhorn Server acting as a Health Registration
Authority (HRA) that runs IIS to obtain these certificates.
The server(s) that a non-compliant computer can access on the restricted network, which
contain resources that can be used to bring the computer into compliance, are called
remediation servers.
For more detailed technical information about what occurs in each step of the NAP
validation process, download the whitepaper titled Introduction to Network Access
Protection from the Microsoft TechNet web site.
Summary
NAP is a robust solution for controlling network access based on computers’ health status
and takes up where NAQC left off. It's a built-in component of Windows Longhorn Server
and Windows Vista, so SMBs that use these operating systems will be able to take
advantage of its benefits without the need to buy and deploy additional third party
solutions. NAP provides for scalability and interoperability with other technologies such as
Cisco NAC, so that as your network grows, you can continue to provide the level of
http://articles.techrepublic.com.com/5100-1009_11-6147167-2.html
1/9/2007
Page 2 of 2
protection your organization needs.
Page: 1 | 2 | Previous Page
http://articles.techrepublic.com.com/5100-1009_11-6147167-2.html
1/9/2007

Page 1 of 4

Transcription

Similar documents

domain registration form

How to build a scalable passive DNS Alexandre Dulaunoy February 17, 2012

CompleMng The Chain of Trust

CEDAR DNS 8 Live review in Front Of House (Dec

How to control bed bugs - TODAY`S TMJ4

Promoting Inter-ccTLD Cooperation in Africa - ISOC-NY

1 Configuring Your MX Records for SpamTitan Cloud

DNS domains and servers testing

Internet of Things. A recent visit to CES:

Username your username as shown on the logon letter sent to you