Академический Документы
Профессиональный Документы
Культура Документы
A few common
server roles are listed below. For Windows Server 2003, there are a number of different server
roles that you can configure using the Configure Your Server Wizard of the Manage Your Server
utility:
• File server role; the file server role is responsible for storing data for network users, and
providing access to files stored on the file server. File servers enable users to store files in
a centralized location, and enables a user to share files with another user.
• Print server role; this role enables administrators to configure network printing
capabilities for the network and manage printing functions on the network. The print
server is the computer where the print drivers are located that manage printing between
printers and client computers. The print servers manage the print queues, and can also
supply audit logs on jobs printed by users.
• Application server role; the application server role makes Web applications and
distributed applications available to users. A Web server typically contains a copy of a
World Wide Web site and can also host Web based applications. Internet Information
Services 6.0 (IIS 6.0) is Microsoft's integrated Web server that enables you to create and
manage Web sites within your organization. Through IIS, you can create and manage
Web sites, and share and distribute information over the Internet or intranet. With the
introduction of Windows Server 2003, came the advent of Internet Information Services
(IIS) 6.
• Mail server role; the mail server role provides e-mail services for the network, by
providing the functionality needed for users to send and receive e-mail messages. Mail
servers store e-mail data, process client requests and receive incoming e-mail from the
Internet. The Simple Mail Transfer Protocol (SMTP) and Post Office Protocol 3 (POP3)
TCP/IP based protocols are installed when you configure the mail server role.
• Terminal server role; Terminal Services have the ability to operate as an application
server that remote clients can connect to, and run sessions from. The Terminal Services
server runs the applications. When a client establishes a connection to Terminal Services,
it creates a Terminal Services session for the client. All processing is handled by the
Terminal Services server. Clients use insignificant bandwidth on the underlying network
when they establish a connection.
• Remote access server/VPN server; the Windows Server 2003 remote access and VPN
server role can be used to provide remote access to clients through dial-up connections or
through Virtual private networks (VPNs). The Windows Server 2003 Routing and
Remote Access Service (RRAS) server provides a number of features and capabilities,
including LAN-to-LAN routing, LAN-to-WAN routing, Virtual private network (VPN)
routing, Network Address Translation (NAT) routing, additional routing features such as
IP multicasting and packet filtering, and can assign DHCP addresses to RRAS clients.
Authentication Types
What is Authentication
Authentication is the process whereby the system identifies legitimate users from unauthorized
users. It is the process in which a user identifies his/her self to the system. How effective an
authentication process is, is determined by the authentication protocols and mechanisms being
used. Windows Server 2003 provides a few different authentication types which can be used to
verify the identities of network users, including:
• Kerberos authentication protocol
• NT LAN Manager (NTLM) authentication protocol
• Secure Sockets Layer/Transport Security Layer (SSL/TLS)
• Digest authentication
• Smart cards
• Virtual Private Networking (VPN) and Remote Access Services (RAS)
The Kerberos version 5 authentication protocol is the default authentication type for a Windows
Server 2003 environment. Kerberos version 5 makes use of a 'ticket' strategy to authenticate
valid network users, and provides mutual authentication between users and resources. Windows
Server 2003 supports the NTLM authentication protocol to provide compatibility for the earlier
operating systems (OSs) such as for Windows NT 4 compatibility. Secure Sockets
Layer/Transport Security Layer (SSL/TLS) and digest authentication is typically used for Web
applications. SSL/TLS is based on X.509 public-key certificates, and enables mutual
authentication between the client and server.
A few authentication features introduced with Windows Server 2003 are outlined below:
• Windows Server 2003 includes support for smart cards, as well as support for a few
different multifactor authentication mechanisms. Windows Server 2003 can also support
a number of authentication protocols, such as NTLM, NTLMv2, and Kerberos version 5.
• With Windows Server 2003 Active Directory, the Active Directory directory service
stores the security credentials, such as the passwords of users, which are used for the
authentication process. Active Directory directory service can store security credentials
for each authentication protocol. The service also enables users to log on to computers in
an Active Directory environment that contains multiple domains and forests.
• A user can log on to any computer through a single domain account. This is known as
single sign-on. A user basically only needs to log on to a domain account once, and with
one password. The sign-on security information of the user is stored in Active Directory.
Whenever a user attempts to access a resource within a domain, network authentication
takes place.
The remainder of this Article focuses on the different authentication types which you can
implement to enforce an authentication strategy within your environment.
Kerberos Authentication Protocol
The foremost authentication protocol type used within a Windows Server 2003 Active Directory
domain is the Kerberos version 5 authentication protocol. The Kerberos authentication protocol
provides the following authentication features:
• Verifies the identify of network users
• Verifies whether the network service that a user is attempting to access is valid. This
security feature prevents users from accessing any fake network services which could
have possibly been created by unauthorized network users. These fake services are
normally created to deceive network users into disclosing their logon credentials.
The terminology used to describe the process by which both the identity of users, and the identity
of services being accessed are verified, is mutual authentication. The name of the Kerberos
authentication protocol is derived from Greek mythology (three headed dog). This is because of
the following three components of the protocol:
• A client requesting authentication or a service
• A server on which the service that the client requests, resides.
• A computer which both the client and server trusts. This is typically a Windows Server
2003 domain controller on which the Key Distribution Center service is running.
The Kerberos authentication type does not transmit passwords during the authentication process.
Instead, it uses tickets. Tickets are specially formatted data packets that allow a client to access a
resource. The ticket contains the identity of the user in an encrypted data format. When
decrypted, the data or information verifies the identity of the client. Because the Kerberos
authentication type makes use of tickets, it offers more security for the authentication process.
The Kerberos authentication type is dependant on the Key Distribution Center (KDC) to issue
tickets. Each network client makes use of DNS to find the closest available KDC to obtain a
Kerberos ticket. The ticket usually remains active for about 8 or 10 hours. The Key Distribution
Center (KDC) is a service which runs as a component of Active Directory. In fact, each domain
controller in a Windows Server 2003 domain operates as a Key Distribution Center (KDC). It is
the Key Distribution Center (KDC) which manages the database of security account information
for each security principal within a domain. Security principals that form the foundation of the
Active Directory security architecture are user accounts, security groups, and computer accounts.
Administrators of domains assign permissions to security principals to access network resources,
and to perform certain actions on these resources. The KDC holds the cryptographic key which is
only known by the particular security principal, and the KDC. This cryptographic key, also
called a long term key, is formed from the logon password of the user, and is used when the KDC
and security principal interact. Because each domain controller in Windows Server 2003
domains operates as a KDC, fault tolerance is enabled for the domain. When one domain
controller is unavailable, any other domain controller in the domain is able to issue tickets.
Kerberos authentication can be used by clients and servers running the following operating
systems (OSs):
• Windows 2000
• Windows XP Professional
• Windows Server 2003
Windows 2000, Windows XP Professional, and Windows Server 2003 computers which are
members of a Windows 2000 or Windows Server 2003 domain use the Kerberos protocol for
network authentication for domain resources. This is the default configuration for these domains.
When a down level client attempts to access a Kerberos secured resource, NTLM authentication
is used; and not Kerberos authentication.
How the Kerberos authentication process work
The steps outlined below describe the Kerberos authentication process.
1. The user provides his/her user name and password. The computer transmits these details
to the KDC.
2. The KDC creates a session key, and a Ticket Granting Ticket (TGT). A TGT is a ticket
that enables a client to receive temporary tickets from the ticket granting service for each
authentication, and it includes the following:
○ A copy of the session key
○ The name of the user
○ An expiration time
3. The TGT is encrypted by the KDC through its master key.
4. The client computer then receives this information from the KDC. At this point the client
computer holds the session key and TGT, and is authenticated to the domain. The session
key and TGT is stored in volatile memory because it offers better security than storing
the information on the hard disk.
5. A Kerberos client passes its TGT and a timestamp encrypted with its session key, to the
KDC when it needs to access resources hosted on a server which is a member of the same
domain. The KDC utilizes its master key to decrypt the TGT, and it utilizes the session
key to decrypt the timestamp. Since the user is the only individual that can use the
session key, the KDC is able to verify that the request to access resources originated from
the particular user.
6. At this point, the KDC generates a ticket for the client and a ticket for the server hosting
the resources which the client wants to access. Each ticket has a new key which the
server and client will share between each other, and contains the following information:
○ The name of the user
○ The recipient of the user request
○ A timestamp which indicates the time that the ticket was created.
○ The expiration time of the ticket
7. The server master key is used by the KDC to encrypt the ticket of the server. The ticket
of the server is stored within the ticket of the client. The session key which the KDC
shares with the particular user is then used to encrypt the entire set of information. This is
then transmitted to the user.
8. The user decrypts the ticket it receives using the session key. The user encrypts the
timestamp through the new key, and then transmits this information and the ticket of the
server hosting resources which it wants to access. Next, the server uses the server master
key to decrypt the server ticket. The new key is then used to decrypt the timestamp.
NT LAN Manager (NTLM) Authentication Protocol
The NT LAN Manager (NTLM) authentication protocol is the main authentication type used to
enable network authentication for versions of Windows earlier than Windows 2000, such as for a
Windows NT 4. The authentication protocol is essentially used for authentication between
machines running Windows NT and Windows Server 2003 machines.
The NTLM authentication type is typically used in the scenarios listed below:
• By Workstations and standalone servers that are members of workgroups.
• By Windows 2000 or Windows XP Professional computers accessing a Windows NT 4.0
primary domain controller or backup domain controller.
• By Windows NT 4.0 domain users when trusts exist with a Windows 2000 or Windows
Server 2003 Active Directory domain or forest.
• By Windows NT 4.0 Workstation clients who want to authenticate to a Windows NT 4.0,
Windows 2000 or Windows Server 2003 domain controller.
Windows Server 2003 supports the following forms of challenge- response authentication
methods:
• LAN Manager (LM): The LM authentication protocol is used to enable backward
compatibility with the earlier OSs such as Windows 95, Windows 98, Windows NT 4.0
SP 3, and earlier OSs. LM authentication is considered the weakest authentication
protocol because it is the easiest to compromise. LM authentication should not be used in
Windows Server 2003 environments.
• NTLM version 1: NTLM version 1 is more secure than LM authentication because it uses
56-bit encryption, and user credentials are stored in the NT Hash format. This format is
more secure than the level of encryption used in LM authentication.
• NTLM version 2: NTLM version 2 utilizes a 128-bit encryption, and therefore offers the
highest level of encryption.
NTLM authentication works by encrypting the logon information of the user. This is done by
applying a hash to the password of the user. A hash is a mathematical function. The security
account database contains the value of the hash which is generated when the password is
encrypted by NTLM. The password of the user is not transmitted over the network. What
happens is that the client applies the hash to the password of the user, prior to it actually sending
the information to the domain controller. The value of the hash is also encrypted.
How the NTLM authentication process works
1. The client and server negotiate the authentication protocol to use.
2. The client transmits the name of the user and the name of the domain to the domain
controller.
3. At this point, the domain controller creates a nonce. This is a 16-byte random character
string.
4. The nonce is encrypted by the client using the hash of the user password. The client
forwards this to the domain controller.
5. The domain controller then obtains the hash of the user password from the security
account database to encrypt the nonce.
6. This is then compared to the hash value which the client forwarded.
7. Authentication occurs when the two values are identical.
Secure Sockets Layer/Transport Layer Security (SSL/TLS)
Secure Socket Layer (SSL) is a Windows Server 2003 security protocols which utilizes a public-
key technology to provide a secure channel for applications communicating over a non-secure
network such as the Internet. SSL is typically used by Web browsers and Web servers for secure
communication channels. The Secure Socket Layer (SSL) protocol functions at the OSI model's
network layer to provide encryption for the following protocols:
• HTTP
• LDAP
• IMAP
The SSL protocol provides the following functions:
• Server authentication makes it possible for the user to verify that the Web server he/she
is accessing is, in fact the server it is portrayed as being.
• Client authentication enables the server to verify the identity of the user.
• Encrypted connections enable data confidentiality, because information passed between
the server and client are encrypted and decrypted.
Before a client and server can partake in secure Internet communication, the client and server
have to perform a security handshake. The security handshake is a process that authenticates
each entity involved in communication, and also establishes the level of security to use for
communication.
The following events occur when a client and server partake in a security handshake:
1. The client sends a request for a secure channel connection to the server.
2. The server sends its public-key certificate to the client. The server can also request the
certificate of the client for mutual authentication.
3. The client then verifies the authenticity of the certificate of the server. At this stage, the
client sends its certificate to the server if the server requested it in Step 2. The server
proceeds to verify the client's certificate.
4. The client produces a session key, and encrypts the session key with the public key of
server.
5. The server and client now have a secure channel for communication, because information
passed between the two are encrypted and decrypted with the session key.
The Transport Layer Security (TLS) protocol, currently being development by the Internet
Engineering Task Force (IETF), will replace the SSL protocol as the new protocol for securing
Internet traffic.
Digest Authentication
Digest authentication is typically used for authenticating Web applications running Internet
Information Services (IIS). Digest authentication utilizes the Digest Access Protocol in the
authentication process. The Digest Access Protocol employs a challenge-response mechanism
for applications using HTTP or Simple Authentication Security Layer (SASL) communications.
Once a client is authenticated, the session key of the client is located on the Web server. When
digest authentication transmits user information over the network, it does so using an encrypted
hash. This prevents unauthorized users who may be attempting to access network resources,
from intercepting the credentials of the user. Any ensuing authentication requests submitted by
the same client are dealt with by using this session key. Because of this feature of digest
authentication, the client does not need to authenticate with a domain controller each time that it
submits an authentication request.
A few conditions have to be met prior to using digest authentication on IIS servers. These are
listed below.
• Any client that wants to access a digest authentication secured resource has to be running
Internet Explorer 5 or later.
• The IIS server has to be running Windows 2000 or above.
• The domain, to which the IIS server is a member of, has to include a domain controller
that is running Windows Server 2003 or Windows 2000.
• The IIS server and a user that wants to log on to the IIS server has to belong to the same
domain. They can however be joined through trusts.
• Each user that needs to be authenticated must have a legitimate account in Active
Directory, on the particular domain controller.
• The passwords of users have to be stored in a reversibly encrypted format in Active
Directory. You can use the Active Directory Users and Computers console to access the
Account tab of the Properties dialog box of a user, to enable reversible encryption.
Web sites that utilize passport authentication make use of a central Passport server to
authenticate users. Passport authentication works with Microsoft Internet Explorer, Netscape
Navigator, and even with some UNIX systems and browsers. This is due to the fact that passport
authentication is not proprietary. Passport encryption utilizes the following Web technologies:
• SSL encryption
• Symmetric key encryption
• HTTP redirects
• Cookies
A few features of passport authentication are listed below:
• All Web pages which are used to manage sign-in and sign-out operations are located in a
central repository.
• These Web pages make use of SSL encryption to transmit information on user names,
and user account passwords.
• The Web site does not receive the actual passport of the user. Instead, it receives a cookie
which includes the encrypted timestamps which was generated when the user initially
signed in.
• Web sites using passport authentication make use of encrypted cookies to enable users to
access multiple sites, with the user not being required to resubmit his/her login
credentials. The actual cookie files utilize strong encryption.
• The central Passport server uses encryption when it sends sign-in credentials and any
other user information to a Web site enabled with passport authentication.
Smart Cards
Windows Server 2003 supports smart card authentication. Smart cards can be used to secure the
following items:
• The certificates of your users
• Public and private keys
• Passwords and other confidential data.
A smart card is a device similar in size to that of a credit card. Smart cards are dependent on the
Windows Server 2003 public key infrastructure (PKI). A smart card is used in conjunction with
an identification number (PIN) to enable authentication and single sign-on in the enterprise. The
smart card actually stores the private key of the user, public key certificate and logon
information. The user attaches the smart card into the smart card reader that is attached to the
computer. The user next inserts the PIN when prompted for the information.
Smart cards are typically used for interactive user logons to provide further security and
encryption for logon credentials. Smart card readers can be installed on servers, so that you can
require administrators to use smart card authentication when using an administrator account. You
can also require remote access logons to use smart card authentication. This assists in preventing
unauthorized users from using VPN or dial-up connections to launch an attack on your network.
Through smart cards, you can encrypt confidential files and other confidential user information
as well.
The cost associated with implementing and administering a smart card authentication strategy is
determined by the following elements:
• The number of and location of users that are to be enrolled in your smart card
authentication strategy.
• The method which the organization is going to utilize to issue smart cards to users.
• The procedures which are going to be implemented to deal with users who misplace their
smart cards.
In addition to the above, with smart card authentication, each computer has to have a smart card
reader, and one computer has to be configured as the smart card enrollment station. It s
recommend to use only plug and play Personal Computer/Smart Card (PC/SC) compliant smart
card readers. The user responsible for the smart card enrollment station has to be issued with an
Enrollment Agent certificate. The owner of this certificate can issue smart cards for users.
Internet Authentication Service (IAS)
The Internet Authentication Service (IAS) functions as a remote Authentication Dial-In User
Service (RADIUS) server, and can be used to manage the login process of users by providing the
following key features:
• Management of user authentication: IAS can be used for dial-up and VPN access, and for
wireless access.
• The IAS service provides the RADIUS protocol which it utilizes to pass authentication
and authorization requests to the proper Active Directory domain.
• Verification of the user to access network resources
• Tracking of user activity
Internet Authentication Service (IAS) is supported in the following editions of Windows Server
2003:
• Windows Server 2003 Standard Edition
• Windows Server 2003 Enterprise Edition
• Windows Server 2003 Datacenter Edition
The default authentication protocols supported by IAS are:
• Point-to-Point Protocol (PPP): The following PPP protocols are supported by IAS:
○ EAP-MD5
○ Extensible Authentication Protocol-Transport Level Security (EAP-TLS)
Although EAP-TLS is considered the strongest remote access services authentication
method, it can only be used when clients are running Windows 2000, Windows XP or
Windows Server 2003. EAP-TLS utilizes public key certificate based authentication to
provide authentication for wireless connections.
• Extensible Authentication Protocol (EAP): The following EAP protocols are supported
by IAS:
○ Password Authentication Protocol (PAP): Windows Server 2003 supports PAP
for backward compatibility. With PAP, user information (user name and
password) is transmitted in clear text.
○ Challenge Handshake Authentication Protocol (CHAP): CHAP encrypts the user
name and password of the user through MD5 encryption. A requirement of CHAP
is that user password information has to be stored using reversible encryption in
Active Directory.
○ Microsoft Challenge Handshake Authentication Protocol (MS-CHAP): MS-
CHAP provides better security than that provided by CHAP. The passwords of
users do not have to be stored using reversible encryption.
○ Microsoft Challenge Handshake Authentication Protocol version 2 (MS-CHAP
version 2): MS-CHAP version 2 includes the security capability of mutual
authentication. Mutual authentication occurs when the server and client both
verify the identity of each other. MS-CHAP version 2 utilizes separate encryption
keys for sending and receiving security information.
Once IAS has authenticated the user, it can use a few authorization methods to verify that the
authenticated user is permitted to access the network resource(s) he/she is requesting to access.
This includes the following:
• Automatic Number Identification/Calling Line Identification (ANI/CLI): With ANI/CLI,
authorization is determined by the number which the user is calling from.
• Dialed Number Identification Service (DNIS): Authorization is determined by examining
the phone number which the caller is using.
• Remote access policies: Remote access policies can be used to allow or deny network
connection attempts, based on conditions such as group membership details, time of day,
time of week, the access number being used, and other conditions. You can also use
remote access policies to control the amount of time which a remote access client can be
connected to the network. You can specify an encryption level which a remote access
client should use to access network resources.
• Guest authorization: Guest authorization enables users to perform limited tasks, without
needing to provide user credentials (user name and password).
Wireless clients can use certificates, smart cards, and a user name or password to authenticate to
an IAS server. Before a wireless client can connect to your corporate network, you need to define
the following:
• Create a remote access policy for the wireless users which permits these users to access
the corporate network. The remote access policy should include:
○ The access method
○ User and group information
○ The authentication method
○ The policy encryption method
○ The appropriate permissions
• All Wireless APs should be added on the IAS server as RADIUS clients. This ensures that
login information can be forwarded to IAS.
The events which occur when wireless clients requests network access are outlined below.
1. The Wireless AP requests authentication information from the wireless client.
2. The wireless client then passes this information to the Wireless AP. The Wireless AP
forwards the information to IAS.
3. When the information IAS receives is valid, it passes an encrypted authentication key to
the Wireless AP.
4. The Wireless AP next utilizes the encrypted authentication key to create a session with
the wireless client.
How to install the Internet Authorization Service (IAS) on a
domain controller
1. Click Start, Programs, Control Panel, and then double-click Add/Remove Programs.
2. Select Add/Remove Windows Components.
3. This launches the Windows Components Wizard.
4. Click Networking Services. Click Details.
5. When the Networking Services dialog box opens, enable the Internet Authentication
Service checkbox.
6. Click OK.
7. To start the actual installation of IAS, click Next.
8. When prompted, place the Windows Server 2003 CD into the CD-ROM drive.
9. Once the installation of IAS is complete, click Finish, and then click Close.
10. To register the IAS server with Active Directory so that it can obtain user information
from Active Directory domains, click Start, Programs, Administrative Tools, and then
Internet Authentication Service.
11. Right-click Internet Authentication Service, and then select Register Server in Active
Directory on the shortcut menu.
12. Click OK.
How to create a remote access policy
1. Click Start, Programs, Administrative Tools, and then Internet Authentication Service.
2. Right-click Remote Access Policies and then click New Remote Access Policy on the
shortcut menu.
3. This action starts the New Remote Access Policy Wizard. Click Next on the welcome
screen of the wizard.
4. Click the Use the wizard to set up a typical policy for a common scenario option, and
enter a name for the new remote access policy in the Policy name box. Click Next.
5. When the Access Method screen appears, choose the Dialup access method. The other
access method options include:
○ VPN access
○ Wireless access
○ Ethernet
6. Click Next.
7. Select Group and then choose the group to which you want to grant remote access
permission. Click Next.
8. When the Authentication Methods screen appears, choose the one of the following
authentication methods for the new remote access policy.
○ Extensible Authentication Protocol (EAP)
○ Microsoft Challenge Handshake Authentication Protocol version 2 (MS-
CHAPv2)
○ Microsoft Challenge Handshake Authentication Protocol (MS-CHAP)
9. Click Next
10. Specify the encryption level which users should utilize to connect to the IAS server.
Click Next.
11. Click Finish.
If you want to set any further remote access conditions, right-click the particular remote access
policy, and click Properties from the shortcut menu.
1. After accessing a Windows Server 2003 server desktop, click Start, Run, enter syskey
in the Run dialog box, and then click OK.
2. Click the Encryption Enabled option, and click the Update button.
3. Select one of the following options:
○ Password Startup option: Although this option encrypts password information on
the local computer, you have to specify a password that protects the actual system
key. You have to then provide this particular password when you reboot the
computer.
○ System Generated Password option: After selecting this option, you have to select
one of the following options:
Store Startup Key on Floppy Disk: This option stores the system key on a
diskette. This diskette has to be inserted when the system starts up.
Store Startup Key Locally: This option stores the key used for encrypting
password information on the local computer. Store Startup Key Locally is
the option that offers the least security.
4. Click OK.
Windows Server 2003 Authentication Protocols
Windows Server 2003 supports the following authentication protocols:
• NT LAN Manager (NTLM) authentication protocol: The NTLM authentication protocol
employs the challenge-response authentication strategy (the user is challenged to supply
unique confidential information) to authenticate the following types of users and
computers:
• Users/computers running the Windows Me OS, and prior OSs.
• Computers running Windows 2000 or later which are not members of a domain.
The following types of challenge- response authentication methods are supported in Windows
Server 2003:
○ LAN Manager (LM): This is the least secure challenge-response authentication
method, and was initially developed for Workgroups, Windows 95, Windows 98,
and Windows Me. With LM authentication, servers performing authentication
have to store user credentials in LMHash.
○ NTLMv1: With NTLMv1 authentication, the server stores user credentials in
NTHash. NTLMv1 utilizes 56-bit encryption for security, and is a more secure
challenge-response authentication method than the LM challenge-response
authentication method. It is used to connect to servers running Windows NT with
SP3 or prior.
○ NTLMv2: NTLMv1 utilizes 128-bit encryption for security, and is typically used
to connect to servers running Windows 2000, Windows XP and Windows NT
with SP4 or above.
• Kerberos authentication protocol: The Kerberos authentication protocol is the default
authentication protocol used for Windows 2000, Windows XP Professional, and
Windows Server 2003. Kerberos authentication offers improved security over the NTLM
authentication protocol, including the following:
○ Delegated authentication enables services to pose as clients when accessing
network resources.
○ Mutual authentication makes it possible for the server to be authenticated to the
client.
○ A server can authenticate a client with no need of contacting a domain controller.
○ Transitive trust can be used between domains within the same forest, and for
domains which are connected with a forest trust relationship.
Authentication Methods for Earlier Operating Systems
(OSs)
Because authentication protocols typically progress as time passes, the authentication methods
used in earlier OSs are in fact less secure than those used in later OSs. To provide backward
compatibility with the earlier operating systems, Windows Server 2003 can support quite a few
authentication protocols. This includes support for authentication protocols such as Kerberos,
LM, and NTLMv2. It is strongly recommended to use the more secure authentication protocols
such as NTLMv2 and Kerberos if you do not need to cater for compatibility with any earlier
operating systems. The Network Security LAN Manager Authentication Level policy determines
and stipulates which authentication protocols a computer can transmit, and receive or accept. The
Network Security LAN Manager Authentication Level policy is located under Local Policies in
the Security Options security policy node. As you increase the security of this particular policy,
the less the compatibility which exists between your system and those earlier OSs.
The LM Authentication Levels that can be selected are listed below, and are ordered from the
least secure option to the most secure option.
• Send LM & NTLM responses: When enabled, domain controllers accept LM, NTLM, and
NTLMv2 authentication. This ensures that clients can authenticate with servers running
OSs prior to Windows NT 4.0 Service Pack 4. Clients on the other hand only use LM and
NTLM authentication.
• Send LM & NTLM responses\use NTLMv2 session security if negotiated: Clients use LM
and NTLM authentication, but can also use NTLMv2 authentication if the server supports
the protocol. Domain controllers also accept LM, NTLM, and NTLMv2 authentication.
• Send NTLM response only: When this security policy setting is enabled, clients can use
NTLM authentication, and can only use NTLMv2 if the server supports the protocol. LM
authentication is not used. Domain controllers accept LM, NTLM, and NTLMv2
authentication.
• Send NTLMv2 response only: When this security policy setting is selected, clients use
NTLMv2 authentication only. Domain controllers accept LM, NTLM, and NTLMv2
authentication.
• Send NTLMv2 response only\refuse LM: When selected, clients use NTLMv2
authentication. Domain controllers only accept NTLM and NTLMv2 authentication.
• Send NTLMv2 response only\refuse LM & NTLM: If selected, clients use NTLMv2
authentication. Domain controllers only accept NTLMv2 authentication.
Anonymous authentication is an authentication method that actually allows a user and network
client to be authenticated with the user/client furnishing no user credentials. However, if you are
running Windows Server 2003, the user will not be authorized to access network resources. With
the earlier Windows operating systems, this was not the case. Anonymous authentication is
typically used to supply backward compatibility with systems earlier to Windows 2000, for the
following scenarios.
• Windows NT 4.0 could possibly use anonymous access to obtain information from
domain controllers.
• Remote Access Server (RAS) servers on Windows NT 4.0 utilizes anonymous access for
ascertaining dial-in permissions
• Older OSs could also use anonymous access to change passwords (Pre–Windows 2000–
compatible access group) in Active Directory.
To enable anonymous authentication, activate one of the following security policy settings:
• Network Access: Share That Can Be Accessed Anonymously: Use this security policy
setting to define specific shares which can be accessed.
• Network Access: Let Everyone Permissions Apply To Anonymous Users: When enabled,
anonymous users are added to the Everyone group.
A better method of enabling anonymous access is to include the Anonymous Logon security
principal in the access control list (ACL) that needs access.
How to configure domain controllers to only accept only NTLM authentication and to refuse LM
authentication
1. After accessing the domain controller, click Start, Administrative Tools, and then click
Domain Controller Security Policy.
2. Open Local Policies, and then click Security Options.
3. Double-click Network Security: LAN Manager Authentication Level
4. This opens the Network Security: LAN Manager Authentication Level Properties dialog
box.
5. Enable the Define This Policy Setting checkbox.
6. Choose the Send NTLMv2 Response Only\Refuse LM option from the list of available
options.
7. Click OK
8. You can force the policy to be immediately implemented for the domain controller by
clicking Start, clicking Run, entering gpupdate.exe in the Run dialog box, and the
clicking OK.
What is Multifactor Authentication?
A key authentication feature of Windows Server 2003 is its support for multifactor
authentication. Multifactor authentication increases authentication security because smart cards
are supported, as well a number of other authentication mechanisms using non-Microsoft
hardware or software. Because of the costs element associated with implementing smart cards,
they are typically only used for specific user accounts such as administrator accounts. Before
implementing or requiring smart cards for authentication, ensure first that your existing
applications are able to operate together with smart cards. Applications that have the Certified
for Windows Server 2003 marking have been tested for meeting the security standards for
Windows Server 2003.
Applications that have the Certified for Windows Server 2003 marking have the following
characteristics:
• These applications include support for smart card logons, and should be able to operate
together with smart card authentication.
• An application can use Kerberos, NTLM, and the Secure Sockets Layer (SSL) protocol.
• The applications use secure network connections, and do not use protocols with known
vulnerabilities. The applications therefore do not use NTLM. They use strong
authentication methods and account policies.
The Authentication Methods used with Active Directory
Trusts in Windows Server 2003
Trust is the terminology used to describe a relationship between domains or forests in Active
Directory that allows users in one domain to be authenticated by a different or remote domain.
This makes it possible for users, computers, or groups from one domain to be authenticated by
domain controllers located in different domains. Configuring trust relationships between
domains or forests does not however enable users to access resources in domains other than the
domain in which they are located. Configuring domain and forest trust relationships is however a
key component for the process of permitting users to access resources in other domains.
The different types of trusts that can be configured if you are running Windows Server 2003
Active Directory are listed below. The authentication protocols used with each trust type are
noted alongside each trust type.
• Parent/child trust is the default trust type that exists between each domain in a forest. The
Kerberos authentication protocol and the NTLM authentication protocol are used with
this trust type.
• Tree/root trust is the default trust type that exists between each domain tree in a forest.
The Kerberos and NTLM authentication protocols are used with tree/root trust.
• External trust has to be explicitly configured between domains that are not located in the
same forest. The NTLM authentication protocol is used with external trust.
• Realm trust has to be explicitly configured between a non-Windows domain such as a
Kerberos realm, and a Windows Server 2003 domain. The Kerberos authentication
protocol is used with realm trust.
• Shortcut trust is typically configured to reduce logon times between domains in a forest.
The Kerberos authentication protocol and NTLM authentication protocol is used with
shortcut trust.
• Forest trust is explicitly configured between forests raised to the Windows Server 2003
domain forest level. The Kerberos authentication protocol and NTLM authentication
protocol is used with forest trust.
The actual operating system used for a domain or forest determines the authentication protocol
which you can use. For instance, the earlier OSs could only use the LM authentication protocol.
Because of this, the OS used actually dictates which of type of trust you can configure between
domains and forests.
Kerberos authentication can only be used between Windows Server 2003 forests. Because
Windows 2000 forests cannot locate the Kerberos Key Distribution Centers (KDCs) in different
domains, Kerberos trust cannot be formed between Windows Server 2003 and Windows 2000
forests. You would need to configure external trust relationships between Windows Server 2003
and Windows 2000 forests. The same type of configuration is necessary to create a trust
relationship between a Windows Server 2003 forest and a Windows NT 4.0 forest. With
Windows Server 2003 Active Directory, you can create trusts between Windows Server 2003
domains, and domains using UNIX or some other OS which includes support for MIT-compliant
Kerberos.
The Active Directory Domains And Trusts console is the Active Directory management tool
which you need to use to configure trusts between domains within the same forest, or to
configure trusts between forests. DNS name resolution should be operational between any two
forests for which you are planning to configure a trust relationship. The functional level of each
forest in the trust relationship should be raised to the Windows Server 2003 forest functional
level before you can create the actual trust relationship.
Implementing an Authentication Strategy for Web Users
The LM, NTLM and Kerberos authentication protocols cannot be used by a Web browser to
authenticate users to a Web server. This is because Web servers use the Hypertext Transfer
Protocol (HTTP) to communicate. What this means is that for a user to be authenticated to a Web
server, the Web browser has to actually use an authentication protocol located in HTTP.
The following authentication methods can be implemented so that a Web browser can
authenticate users to a Web server:
• Basic Authentication: Even though basic authentication is the least secure authentication
method to implement, it is supported by a number of Web browsers. With basic
authentication, the password of the user is basically transmitted in a format which is the
same as the clear text format.
• Digest Authentication For Windows Domain Servers: This authentication method uses a
Message Digest 5 hash to submit the password of the user.
• Integrated Windows Authentication: This authentication method is supported by only a
few Web browsers, of which Microsoft Internet Explorer is one. When this authentication
method is enabled, Kerberos version 5 authentication and NTLM authentication is
enabled within the Web request.
• .NET Passport Authentication: This authentication method is usually enabled if the .NET
Passport service is used for authentication.
The majority of public Web sites on the Internet permit anonymous access for a segment of the
Web site. What this means is that a user does not need to provide user credentials to access
certain information on the Web site. Internet Information Services (IIS) accesses the network
resources on behalf of anonymous users, and uses a particular user account to access these
resources. The IUSR_computername user name account is the default account used by IIS for
this purpose. This account is automatically created when IIS is installed. You can however
specify that IIS should use a different user account.
To specify a user account that IIS should use to access network resources on behalf of
anonymous users, use the steps listed below:
1. Using administrative rights, log on to the computer.
2. Click Start, Administrative Tools, and then click Internet Information Services Manager.
3. Open the computer node, expand Web Sites, right-click the node that contains the Web
site which you want to work with, and then click Properties from the shortcut menu.
4. Select the Directory Security tab.
5. Click Edit in the Authentication And Access Control portion of the tab.
6. When the Authentication Methods dialog box opens, enter the name of the user account
in the User Name box, and then enter the password for the account in the Password box.
7. Click OK.
You can remove anonymous access by deselecting the Enable Anonymous Access checkbox on
the Authentication Methods dialog box.
Planning and Implementing an Authorization
Solution
An Overview on Authorization
Authentication is the first step in implementing a security strategy to protect your network
resources and elements from unauthorized users, because it is the process that deals with
identifying valid authorized network users from unauthorized users. Authentication therefore
verifies the identity of users. The next step in securing your network resources and elements
from unauthorized access is authorization. Authorization is the process that controls which
objects an authenticated network user can access. Just because a user is authenticated, does not
necessarily mean that the particular user is permitted to access all network resources.
Authorization determines whether the user can indeed access, and perform the requested actions
on the network resources, which the user is attempting to access.
Access to network
resources is controlled by setting permissions for objects, and assigning rights to users.
Permissions define the users, or groups which are permitted to access the network resource.
Permissions also detail the type of access permitted to a particular network resource. Access to a
network resource is controlled by the owner of that particular resource or object.
An effective authorization strategy should limit the access which a user needs to only those
network resources which the particular user needs to accesses, to perform its daily duties. You
can therefore also think of authorization as the process of differentiating between standard users,
administrators, and guests. Individually assigning rights to users could become impractical in a
large organization. Implementing groups and then assigning rights to groups is a more feasible
solution. Groups facilitate simpler access management processes.
Authorization practically occurs each time that a user who has passed authentication, attempts to
access the following objects or network resources:
• Active Directory directory service objects
• Files and folders
• Shared folders
• Network services
• Windows Management Interface objects
• Registry keys and values
• Terminal Services connections
Because of the diverse number of object types that typically exists in a network environment,
Windows Server 2003 attempts to simplify authorization management tasks. Assigning
permissions to each particular object type could become a cumbersome task. Windows Server
2003 utilizes a standard authorization model or strategy for all types of network objects. The
interface used to configure permissions for each type of object is very much the same as well.
The standard authorization model utilizes the following components to implement authorization:
• Access Control Lists (ACLs)
• Inherited permissions
• Standard Permissions
• Special Permissions
Understanding Access Control Lists (ACLs)
ACLs hold information on the users or groups which are allowed or denied access to a particular
object. What this means is that the ACL identifies those users who can access a particular
resource. The ACL of an object is managed by the owner or creator of that particular object. An
ACL contains access control entries (ACEs). The ACE is an entry in the ACL of an object which
grants permissions to users/groups to access the object. A user is granted access to an object, if
an ACL explicitly identifies the particular user, or if it explicitly identifies a group to which the
particular user is a member of. Similarly, the user is denied access to the object when the ACL
does not explicitly identify the user, or any group to which the user is a member of.
Access control lists (ACLs) consists of the following sets of permissions:
• NTFS Permissions: These permissions are applied on files and folders. It is generally
recommended to utilize NTFS permissions to control user access to files and folders.
• Share Permissions: Share permissions are applied for users who connect over the
network to an object. It is recommended to keep share permissions at their default
permission settings. NTFS permissions should be used to control user access to files and
folders. This is because of the disadvantages associated with share permissions, including
the following:
• You cannot back up share permissions.
• Any specified share permissions are no longer valid if the particular folder is
unshared.
• Share permissions cannot be inherited, or audited.
Understanding Standard Permissions and Special
Permissions
When you configure the access control lists for the different object types, you can use standard
permissions and special permissions.
• Standard Permissions: Standard object permissions include the following permissions:
• Reading the object
• Reading the permissions of the object
• Modifying the object
• Modifying the permissions of the object
• Deleting the object
• Changing the owner of the object
• Special permissions: When you specify a standard permission, a set of special
permissions associated with the particular standard permission become available, and
enable you to more finely manage the access which the user has to the object.
The standard and special permissions which can be applied to files and folders are listed in the
following section
• Standard Permissions for files and folders:
• Full Control; users can create and delete files and folders, and change the
permissions on files and folders.
• Modify; users can read, change, and delete files and folders.
• Read & Execute; users can read files, and execute applications attached to files.
• List Folder Contents; users can list the contents of a folder.
• Write; users can create files and folders.
• Read; users can read files, and view the contents of a folder.
• Special Permissions for files and folders:
• Traverse Folder/Execute File; Traverse Folder enables a user to traverse folders,
and Execute File enables users to run application files.
• List Folder/Read Data; List Folder permits/denies users to view the names of
subfolders and files, and Read Data allows users to read the file’s content.
• Read Attributes; permits/denies users to read the file/folder’s attributes.
• Read Extended Attributes; permits users to read the file/folder’s extended
attributes.
• Create Files/Write Data; Create Files allows users to create files in folders, and
Write Data permits users to change the current content of a file.
• Create Folders/Append Data; Create Folders allows users to create folders in
other folders, and Append Data allows users to implement changes at the end of a
file. Existing file content cannot however be overwritten.
• Write Attributes; allows/denies users to change the file/folder’s attributes.
• Write Extended Attributes; allows/denies users to change the file/folder’s
extended attributes.
• Delete Subfolders and Files; enables users to delete subfolders and files.
• Delete; enables users to delete files and folders.
• Take Ownership; allows for the taking of ownership of the file/folder.
• Read Permissions; allows the user to view the file/folder’s permissions.
• Change Permissions; allows the user to change the file/folder’s permissions.
How to view, configure, or change special permissions for files and folders
1. Open Windows Explorer
2. Locate, and right-click the file or folder, and then select Properties from the shortcut
menu.
3. When the Properties dialog box of the file or folder opens, click the Security tab.
4. Click the Advanced button
○ If you want to configure a special permission for a user/group, click Add, and
then enter the name of the user/group in the Name box. Click OK
○ If you want to view or change the special permissions for a user/group, select the
user/group, and then click the View or Edit.
○ If you want to remove a user/group, and any associated special permissions,
simply select the user/group, and then click Remove.
5. If you are working with a folder, specify where the permission should be applied in
Apply Onto, on the Permission Entry dialog box.
6. Specify the Allow or Deny for each particular permission
7. Click OK.
The standard permissions which can be applied to shares are summarized below.
• Full Control; allows the user to read, write and change permissions on files and folders
included in the share.
• Change; allows users to read and write to files/folders contained by the share.
• Read; allows users to read the files/folders contained by the share.
How to set share permissions
1. Open the File Server Management console.
2. Select Shared Folder, and then access the Shares subfolder.
3. Locate and right-click the shared folder that you want to set permissions for, and select
Properties from the shortcut menu.
4. Click the Share Permissions tab.
5. Specify the appropriate share permissions.
6. Click OK.
The standard and special permissions which can be applied to Active Directory objects are
listed in the following section.
• Standard Permissions for Active Directory objects:
• Full Control; users can perform all actions (read, write, change permissions, and
so forth) on the particular Active Directory object.
• Read; users can read or view the permissions, properties and contents of the
Active Directory object.
• Write; users can change the properties of the Active Directory object.
• Create All Child Objects; users can create child objects in the container, if the
particular object is a container (organizational unit).
• Delete All Child Objects; users can delete child objects in the container, if the
particular object is a container (organizational unit).
• Special Permissions for Active Directory objects: There are a few special permissions
which you can specify for Active Directory objects on the Advanced Security Settings
dialog box for the object using the Active Directory Users and Computers console. For
instance, for the Create All Child Objects, and Delete All Child Objects standard
permission, you use special permissions to restrict the types of objects which the user can
create or delete.
How to assign standard permissions for an Active Directory object
1. Click Start, Administrative Tools, and Active Directory Users And Computers.
2. Advanced Features should be enabled. Verify this on the View menu.
3. Locate and right-click the Active Directory object which you want to assign permissions
for, and click Properties on the shortcut menu.
4. When the Properties dialog box of the object opens, click the Security tab.
5. Click Add.
6. When the Select Users, Computers, Or Groups dialog box opens, enter the name of the
user/group for which you want to configure permissions. Click OK.
7. Use the Allow and Deny checkboxes to add, change or deny permissions.
8. Click OK.
The standard and special permissions which can be applied to printers are summarized below.
• Standard Permissions for printers:
• Print; enables users to connect to a printer, and to transmit documents to the
printer for printing.
• Manage Printers; users can perform all administrative tasks on the printer. This
includes among other tasks, pausing and restarting the printer, changing printer
permissions, and changing the properties of the printer.
• Manage Documents, permits users to restart, cancel, pause, and rearrange the
order of documents submitted by other users to the printer.
• Special Permissions for printers: There are about 6 special permissions which can be
assigned to users for printers.
How to change the standard permissions configured on a printer
1. On the Start menu, access the Printers and Faxes folder.
2. Right-click the printer for which you want to change standard permissions, and click
Properties from the shortcut menu.
3. In the Properties dialog box of the printer, click the Security tab
○ If you want to add a user/group to the list of users assigned permissions to the
printer, click Add, and enter the name of the user/group.
○ If you want to modify the current permissions for a user/group, select the
user/group, and then specify the permissions for the particular user/group.
○ If you want remove a user/group, select the user/group, and then click Remove
4. Click OK
The standard and special permissions which can be applied to services are summarized below.
• Standard Permissions for services:
• Full Control; enables users to perform all functions on the particular service. This
includes among other activities, changing the permissions of the service, and
starting/stopping the service.
• Read; users are only permitted to view the permissions, status, and dependencies
of the service.
• Start, Stop, And Pause; enables a user to start, pause, or stop the service.
• Write; users are permitted to set whether the service should be started manually or
automatically when the server reboots.
• Delete; enables the user to delete the service
• Special Permissions for services: As is the case with the other object types, there are over
10 special permissions which you can assign to users, for a service.
The standard and special permissions which can be applied to registry keys and values are
summarized below.
• Standard Permissions for registry keys and values:
• Full Control; enables users to create new registry keys or values, and to edit and
delete existing registry keys or values.
• Read; users can only view registry subkeys and values.
• Special Permissions for registry keys and values: There are over 10 special permissions
for registry keys and values which you can assign to users.
Understanding Explicit Permissions, Inherited Permissions
and Effective Permissions
Permissions that are directly set for an objects such as folders, files, or Active Directory objects
are called explicit permissions. In an effort to ease the administrative tasks necessary to assign
permissions, inherited permissions are used. Inherited permissions enable permissions to be
propagated from a parent object to child objects. The default configuration for inherited
permissions is that all newly created child objects automatically obtain the permissions specified
on its associated parent object. You can stop a child object from inheriting the permissions of a
parent object by clearing the Allow Inheritable Permissions From The Parent To Propagate To
This Object And All Child Objects checkbox.
Because users can be assigned permissions from different sources, the actual permission effect is
considered cumulative. Another way of saying this is that the permissions which are granted to a
user or group are cumulative. Individual user permissions can be either the allowed permission
or the denied permission for resource access. In addition to this, a user can be a member of many
different groups. Groups can also be nested within other groups. When determining the effective
permissions of a user, all the above has to be considered, while bearing in mind that any denied
permissions always override allowed permissions. This includes inherited permissions.
Deciding on the appropriate ACL access method to
implement for controlling access to resources
If you are dealing with a small organization that has roughly ten users or less, you can implement
the User/ACL method to control access to resources. This method only tends to work optimally
in small organizations that only need a small number of groups to manage resource access. In
large organizations, the User/ACL method has the following shortcomings:
• The ACLs would grow into unmanageable sizes, which would eventually lead to
degraded performance.
• Managing the User/ACL method in large organizations tends to lead to increased
administrative costs.
• Monitoring and troubleshooting user permissions to resources would be a time
consuming task.
• In large organizations, where user access requirements typically differ, an Administrator
would have to manually manage and change the rights for users who need additional
access to resources.
With the Account Group/ACL method for controlling access to resources, the global group in
which users are placed, is added to the ACL. What this means is that permissions to resources is
assigned on a per group basis. Using groups, you can configure the same permissions for all
users in the group that need to access the resources. This in turn leads to simpler management.
Global groups can also be added to the ACLs of any trusted domains. The Account Group/ACL
method also has a few limitations. These are detailed below.
• As the number of account groups which are added to a particular resource increases, the
more complicated it can be to perform administrative tasks.
• Deciding on the proper permissions needed for each group can be an intricate task.
With the Account Group/Resource Group method of controlling access to resources, users which
have similar access requirements to resources are added to an account group. The Account
Group/Resource Group method is the most feasible method to control access to resources in
large organizations. The Account Group/Resource Group method has the following benefits:
• To provide groups with access to the required resources, you merely have to add the
necessary account groups into resource groups.
• You no longer need to change permissions for each group individually. All you have to
do is add the account group to the particular resource group which has desired
permissions.
• Account groups can be added to ACLs in trusted domains.
• The Account Group/Resource Group method provides improved flexibility over the
Account Group/ACL method and User/ACL method.
• The Account Group/Resource Group method also simplifies administration typically
needed to control access to resources.
Deciding on the appropriate Group strategy to implement
for accessing resources
Groups assist in managing users, computers, and other objects; and in controlling access to
network objects or resources. The group scopes available in Windows Server 2003 are briefly
listed below.
• Global Groups are used to group users or computers which belong to the same domain.
• Domain Local groups can include users from any domain in the forest, and are used to
control access to resources which reside in the same group as the particular Domain
Local group.
• Universal groups can include users and groups from any domain in the forest. Universal
groups can be used to control access to resources that reside in any domain.
The strategy which Microsoft recommends for implementing a permission structure to control
access to resources is called AGDLP. This consists of the following steps:
1. Add domain users to global groups.
2. Add global groups to domain local groups.
3. Assign the domain local groups the permissions on the particular resource(s).
When including Universal groups, the permission structure is known as AGUDLP.
4. Add domain users to global groups.
5. Add global groups to universal groups.
6. Add universal groups to domain local groups.
7. Assign the domain local groups the permissions on the particular resource(s).
A few key factors to remember when nesting or combining groups are summarized below. While
nesting or combining groups can indeed significantly reduce network traffic and the
administrative overhead necessary to manage access to resources, you have to take time to plan
the group nesting strategy which you want to implement in your environment.
• When planning your group nesting strategy, remember the following:
• You can nest Domain local groups in other Domain Local groups.
• You cannot however nest Domain local groups in Global groups or Universal
groups.
• You can nest Global groups in Domain Local groups, Universal groups and in
other Global groups.
• Universal groups can be nested in other Universal groups.
• You can add Global groups to Universal groups.
• You cannot add Universal groups to Global groups
• You should record or document the description of each group, and the functionality of
each group, so that you can readily access this information if you need to troubleshoot
permission issues.
• You should always strive to reduce the level of nesting required. Having the number of
nested groups at a maximum of two levels or three levels is ideal.
How to troubleshoot authorization problems
Troubleshooting simple authorization issues typically involves the following process.
1. Determine the effective permissions of the user for the particular object.
2. Examine the effective permissions, and then assign the user or the group to which the
user belongs; the necessary permissions to perform the required tasks.
To determine the effective permissions of a user,
1. Examine the permissions of the particular object.
2. Select the Advanced button.
3. When the Advanced Security Settings dialog box opens, click the Effective Permissions
tab.
4. Click Select, and in the Select User, Computer, Or Group dialog box, enter the user’s
name for which you want to determine effective permissions. Click OK.
5. Proceed to examine the permissions that the user has, and compare this to the permissions
that the user requires. Click OK
6. You can now assign any other necessary permission to the user.
For complex authorization problems, where it is more complicated to determine whether an
application is attempting to access an Active Directory object, service, file, or registry value; you
can enable and use failure auditing to determine which objects the application or user is
unsuccessfully trying to access.
To enable failure auditing,
1. Log on to the appropriate system or domain controller.
2. Click Start, Administrative Tools.
3. If you are logged on to a member server, or standalone server, click Local Security
Policy.
4. If you are logged on to a domain controller, click Domain Controller Security Policy.
5. Proceed to expand Local Policies. Click Audit Policy.
6. For Active Directory object access problems, double-click Audit Directory Service
Access.
7. For other object types, double-click Audit Object Access.
8. Record the existing settings so that you can reconfigure them after you have
troubleshooted the authorization problem at hand.
9. Select Define These Policy Settings, and select Failure.
10. Click OK.
Now that you have enabled failure auditing for either the Audit Directory Services Access policy
or the Audit Object Access policy, the following step in troubleshooting the authorization
problem is to enable auditing for the particular resource(s).
You can enable auditing for the files and folders object type by using the following steps:
1. Open Windows Explorer
2. Locate and right-click the file or folder which you want to enable auditing for, and then
select Properties from the shortcut menu.
3. When the Properties dialog box of the file/folder opens, click the Security tab, and then
click Advanced.
4. Click the Auditing tab.
5. Record the current auditing settings, so that you can reconfigure them after you have
completed troubleshooting the authorization problem.
6. Click Add
7. Enter the name of the particular user experiencing the problem in the Select User Or
Group dialog box. Click OK.
8. When the Auditing Entry dialog box appears, click the Failed checkbox for Full Control.
This automatically checks all other Failed checkboxes. Click OK.
9. An event will now be logged in the Security event log whenever the particular user is
denied access to the resource.
10. You can analyze these failure events using Event Viewer.
Windows Server
2003 includes predefined security templates that hold security settings for different levels of
security. The security level is determined by the type of server that the template is applied to.
The Security Template areas where you can configure security for Windows 2000, Windows XP,
and Windows Server 2003 networking environments are listed here:
• Account policies. The Account Polices area is associated with policies that are connected
to user accounts.
• Local policies. Local policies deal with who has local access or network access to the
computer. It also includes the manner in which events are audited.
• Event log. This includes settings that indicate the manner in which Application logs,
Security logs, and System logs performs, when the logs are overwritten, and how long
logs are kept. You can view Event logs in the Event Viewer tool.
• Restricted groups. Restricted groups are used to add members to built-in user groups.
Built-in user groups consist of Administrators, Backup Operators and Power Users.
• System services. System Services include security settings of the system services (file,
network, print) on the local computer.
• Registry. Registry includes settings for registry keys.
• File System. File System is used to set access permissions for the directories and files on
the local system.
There are a number of predefined security templates as well:
• setup security.inf; contains the default security settings created by the Windows Server
2003 Setup program when a computer is installed.
• Compatws.inf; enables most types of applications to run. All members in the Power Users
group on computers running Windows Server 2003 is removed, and security is relaxed to
enable applications to run without errors.
• DC security.inf; defines default system services settings, default security settings, and file
system and Registry settings for a domain controller.
• hisecdc.inf is a highly secure template which contains security settings for domain
controllers. The hisecdc template provides NTLM version 2 and applies Registry and file
security. The hisecdc template disables all additional services and removes all members
from the Power Users group.
• hisecws.inf is a highly secure server or workstation template which contains security
settings for workstations. The hisecws template applies security settings to servers and
workstations, which are similar to those applied in the hisecdc template to domain
controllers.
• securedc.inf; contains security settings for domain controllers and maintains
compatibility with most functions and applications. The securedc template includes
enhanced security options, auditing policies, and includes restrictions for anonymous
users.
• securews.inf; contains enhanced security settings for workstations and member servers
that are not domain controllers. The template maintains compatibility with most functions
and applications. The securews template includes enhanced security options and auditing
policies.
• Rootsec.inf; contains the default file system permissions that can be applied as the root
permissions to the system drive of a computer.
• iesacls.inf; includes settings that can be utilized to audit registry settings that control
Internet Explorer security.
You can use the Security Templates snap-in to create a security template file which can be
deployed using either of these methods:
• The text security template file can be imported to the Security Settings extension to
configure security policy for the local computer, Active Directory domain, or Active
Directory organizational unit (OU).
• The Secedit.exe command-line tool can be used to apply a security template as well.
• The Security Configuration and Analysis snap-in can be used to analyze system security
based on the settings within the security template.
To create a new security template
1. First create a MMC console and add the Security Templates snap-in to it.
2. Open the Security Templates management console.
3. Proceed to expand the Security Templates node.
4. Right-click the Security Templates node and then select New Template Search Path from
the shortcut menu.
5. Enter the location which will be used to store your new security template. Click OK.
6. Now, right-click the security template search path, and then click New Template from the
shortcut menu.
7. Enter a name and description for the new security template.
8. Click OK.
9. You should now edit your new security template. Through the Security Templates snap-
in, you can add security policies to the template.
To customize an existing security template
1. First create a MMC console and add the Security Templates snap-in to it.
2. Open the Security Templates management console.
3. Proceed to expand the Security Templates node.
4. Select the default path folder
5. Right-click the security template you want to change in the right pane.
6. Click Save As
7. Enter a name for the security template.
8. Click Save,
9. The security template you have just created is displayed in the right pane.
10. Double-click the new security template to change the security settings.
11. To change a setting, right-click the appropriate attribute, and then select Properties from
the shortcut menu.
Defining Baseline Security Templates
You can use the Security Configuration And Analysis console included in Windows Server 2003
to define a baseline security template. The Security Configuration And Analysis console utilizes
a database specific to the computer to analyze computer security.
The features of Security Configuration And Analysis allow you to perform a number activities
and functions to define a baseline security template, including the following:
• Create your own databases to store customized security templates.
• Analyze security and view results, and sort out any detected discrepancies revealed by the
security analysis.
• Overwrite existing security templates.
• Add new security templates to the database.
• Import and export security templates.
• Combine multiple security templates into one multipart security template.
The typical activities which you need to perform to define a baseline security template through
the Security Configuration and Analysis console are listed here:
• Create a security database.
• Import a security template into your security database.
• Analyze security.
• View the results of the security analysis.
• Resolve security discrepancies - configure system security.
• Export the settings of the security database to a security template.
A few best practices for using the Security Configuration and Analysis feature are listed here:
• To avoid settings implemented through the Security Configuration And Analysis tool
from overriding local Group Policy settings, only use the Security Configuration And
Analysis tool to configure security settings for system services, local files/folders, and
registry keys.
• You should not use the Security Configuration And Analysis feature to configure domain
or organizational unit security. You should rather use either of these methods:
○ Create a security template through the Security Templates snap-in, and apply it to
the suitable Group Policy Object (GPO).
○ The Security Settings extension to Group Policy should be used to change any
specific security settings on a particular GPO.
• You should use the Secedit command-line tool to analyze a large number of computers.
To add the Security Configuration And Analysis console to a MMC
1. Click Start, Run, and enter mmc in the dialog box. Click OK.
2. Using the Console menu, click Add/Remove Snap-In, and then click Add.
3. When the Add Standalone Snap-In dialog box opens, select the Security Configuration
And Analysis feature, and then click Add.
4. Click Close. Click OK.
5. Using the Console menu, click Save and enter a name for the console.
6. Click Save.
7. The Security Configuration And Analysis console can now be accessed from the
Administrative Tools menu.
How to create a security database
Before you can analyse system security and define a baseline security template, you first have to
create a security database:
1. Open the Security Configuration And Analysis console.
2. Right-click Security Configuration And Analysis, and then select Open Database from
the shortcut menu.
3. When the Open Database dialog box opens, enter the name of the file in File Name, and
then click Open.
4. When the Import Template dialog box opens, choose the security template that should be
imported into the new security database.
5. Click Open.
How to analyze system security settings
1. Open the Security Configuration And Analysis console.
2. You need to have already created the security configuration and analysis database.
3. Right-click Security Configuration And Analysis and then select Analyze Computer Now
on the shortcut menu.
4. When the Perform Analysis dialog box opens, verify that the path specified for the log
file is correct.
5. Click OK to start the analysis of the computer.
How to view the security analysis results
1. Open the Security Configuration And Analysis console.
2. Expand the Security Configuration And Analysis node, expand the appropriate security
policies node such as Account Polices or Local Policies, and then select the policy whose
results you want to examine.
3. The analysis results are displayed in the details pane of the Security Configuration And
Analysis console, together with flags that indicate whether issues were detected or not.
4. The columns displayed in the details pane of the Security Configuration And Analysis
console are:
○ Policy column; contains the policy name for the results.
○ Database Setting; contains the value within the security template.
○ Computer Setting; displays the security setting configured for the system.
5. The different flags which can be displayed are:
○ Red X; signifies a disparity from the security database.
○ Green checkmark; signifies consistency with the security database.
○ Red exclamation; signifies an entry which was specified in the security database,
but which does not exist in the system which was analyzed.
○ Black question mark; signifies an entry which was not specified in the security
database. The item was therefore not included in the analysis.
○ No icon; signifies a policy that was not in the template.
While Windows
Server 2003
provides a number of features and tools when you install it on a computer, you have to
implement additional features and functionality on a server to provide the services and
capabilities required by the organization and its users.
There are a number of different risks that have an impact on an organization. Some of the
primary threats which you should address are listed here:
• Environmental threats pertain to both environmental disasters and disasters
due to human intervention. Examples of environmental threats are fires,
earthquakes, storms, faulty wiring, and so forth.
• Accidental threats relate to threats which are caused without malicious
intent. Accidental risks occur when an employee accidentally deletes
important files, or modifies data that should not have been changed.
• Deliberate threats relate to threats which are caused with malicious intent as
the primary objective. Examples of deliberate threats are viruses, Trojan
horses, and all other network attacks caused by hackers and intruders.
A typical security life cycle is consists of the following processes:
• Determining and designing the security infrastructure: The design phase of
the security life cycle includes elements such as identifying the resources of
the organization that needs to be secured, and then designing the security
infrastructure to protect these resources. The security design team should be
accountable for creating and designing security policies for the organization.
• Deploying and implementing security features and security policies: The
security design team should also be responsible for implementing security
features and security policies.
• Continually managing the security solution: All security software should be
upgraded as necessary, and audit logs should be regularly examined.
A number of common steps or processes have to be completed to design network infrastructure
security:
• Determine the security requirements of the organization.
• Plan network security which should be implemented.
• Establish and create secure boundaries.
• Implement security technologies for the network.
• Implement server security technologies.
• Implement application security technologies.
• Implement user security technologies.
• Implement an auditing strategy.
• Implement a network monitoring strategy.
A few methods of securing your network infrastructure are listed here:
• Physically secure all mission-critical network servers: A few guidelines and
recommendations for implementing physical security are detailed below:
○ All servers should be secured in a locked server room.
○ Only those individuals that need access should be permitted to access
the server room using a key or security code. You can also implement
a mechanism that monitors who enters and leaves the server room.
○ All hubs, routers and switches should be placed in a wiring closet, or in
a locked cable room.
○ You should use case locks on your servers. You can also install case
locks on other systems that can be physically accessed.
○ You should restrict access to the floppy drive as well.
○ Set a BIOS password on all systems. This would prevent an
unauthorized person from accessing the BIOS.
○ You should change the operating system selection timeout interval to 0
in order for Windows to boot automatically.
○ When you are setting up Windows, disconnect the server from the
Internet.
○ Install Windows operating systems to a NTFS partition.
○ Ensure that you use a strong local administrator password during
setup.
• Using the NTFS file system and its security features.
• Using the Encrypting File System (EFS).
• Securing network access points.
• Enforcing user authentication.
• Securing network access.
• Enforcing the use of strong passwords.
• Securing confidential network service data as it moves over the network.
• Securing confidential application data as it moves over the network.
• Securing confidential user data as it moves over the network.
Each Windows server operating system provides different features, and different security
configurations which can be enabled to enhance network security and server security. Before
deciding on the operating system to utilize, you have to know which security features are
required for your network design, as determined by the organization's requirements.
Most organizations use a security design committee or team to determine the security needs of
the organization and to deploy security policies which can meet these requirements.
The members of the network security design committee should be knowledgeable on a number
of factors, including the following:
• The mission critical resources of the organization.
• The security weaknesses or vulnerabilities of the organization.
• The threats to which the mission critical resources of the organization is
exposed.
• The resources which are mainly at risk.
• The loss to the organization should particular resources of the organization
be compromised.
• The level of security needed to secure the organization's resources.
• The security features and security policies which can be used to secure the
resources of the organization.
• The security features and security policies which are ideal to secure
particular resources.
• The impact of implementing security features and security policies on
employees, users and administrators.
• The requirements for deploying identified security solutions.
S/MIME Overview
Secure /Multipurpose Internet Mail Extensions (S/MIME) can be used to provide end-to-end
security for e-mail traffic. You can implement S/MIME to digitally sign e-mail messages being
transmitted, thereby protecting the information from being modified.
Digitally signing e-mail messages provides the following key security features:
• Origin integrity
• Message integrity
• E-mail messages can be encrypted as well.
Microsoft Exchange Server 2000 and Exchange Server 2003 support S/MIME. To implement
S/MIME, S/MIME requires e-mail application support only. The e-mail servers do not need to
support S/MIME.
Server Message Block (SMB) Protocol Signing Overview
Server Message Block (SMB) signing can be implemented to ensure the validity and integrity of
data in transit between a client and a server. Server Message Block (SMB) signing can therefore
be used to prevent man-in-the-middle attacks. SMB signing ensures the authenticity of a user and
the server on which the data resides. To prevent the modification of SMB packets while in
transit, SMB supports the digital signing of SMB packets. The signature is then verified at the
recipient computer. To sign SMB packets, a mathematical algorithm is run over specific fields
within the packet, to calculate a mathematical result. The recipient runs the same mathematical
algorithm and then compares the mathematical result. When the two mathematical results match,
it means that the data was not modified while in transit. A failure on either the server end or
client end results in data not being transmitted.
To protect against the impersonation of clients and servers in high security networking
environments that include Windows 2000 based clients and down-level Windows clients,
consider implementing SMB signing.
SMB signing is negotiated between the client and the server at the time when the SMB session is
established:
1. A client wants to establish a connection with a server that is defined to
require SMB signing.
2. The server responds by sending a challenge to the server. The challenge
takes the form of the data that the client will encrypt to the server.
3. The client responds by encrypting the challenge with a 168-bit session key.
The session key is calculated from the password of the user. Both the
response and the actual algorithm which was utilized to encrypt the
challenge are sent to the server.
4. The server utilizes its stored value for the user password to carry out the
same algorithm on the challenge, and then compares its results to the results
received from the client. Authentication of the user occurs when there is a
match between the mathematical results.
5. The server and client then negotiate the SMBs version which will be used. The
version selected is the highest SMBs version supported by both the server
and the client.
6. All messages sent between the client and server is protected through the
calculation of a digest. The digest is then included with each message.
When you configure a security template to utilize SMB signing, you can select between the
following options:
• Microsoft network client Digitally sign communications (always)
• Microsoft network client Digitally sign communications (if server agrees)
• Microsoft network server Digitally sign communications (always)
• Microsoft network server Digitally sign communications (if client agrees)
When designing SMB signing security, consider the following factors:
• By default, server end SMB signing is only enabled on domain controllers. It is
not enabled for member servers.
• By default, client end SMB signing is enabled on domain controllers, servers,
and workstations.
• If you want all communication with a server to require SMB signing;
○ The server must be configured to enable and require the utilization of
SMB signing.
○ The client computers have to be configured to enable or require SMB
signing.
• If you want communication with a server to allow SMB signing and unsigned
communications;
○ The server must be configured to only enable SMB signing.
A few guidelines
and recommendations for implementing physical server security are detailed below:
• All servers should be secured in a locked server room.
• Only those individuals that need access should be permitted to access the server room
using a key or security code. You can also implement a mechanism that monitors who
enters and leaves the server room.
• All hubs, routers and switches should be placed in a wiring closet, or in a locked cable
room.
• You should use case locks on your servers. You can also install case locks on other
systems that can be physically accessed.
• You should restrict access to the floppy drive as well.
• Set a BIOS password on all systems. This would prevent an unauthorized person from
accessing the BIOS.
• You should change the operating system selection timeout interval to 0 in order for
Windows to boot automatically.
• When you are setting up Windows, disconnect the server from the Internet.
• Install Windows operating systems to a NTFS partition.
• Ensure that you use a strong local administrator password during setup.
Using NT File System (NTFS)
To store data on a local partition on a Windows server, you have to format it with a file system.
The system that you use determines the manner in which data is stored on the disk. It also
specifies the security that can be defined for folders and files stored on the partitions. While
Windows operating systems offer support for the File Allocation Table (FAT) file system, NT
file system (NTFS), and CDFS (Compact Disc File System), the file systems generally utilized
by local partitions is the FAT file system and NTFS file system. The file system that offers the
best level of security is NT file system (NTFS).
NTFS partitions enable you to specify security for the file system after a user has logged on.
NTFS permissions control the access users and groups have to files and folders on NTFS
partitions. You can set an access level for each particular user to the folders and files hosted on
NTFS partitions. You can allow access to the NTSF files and folders, or you can deny access to
the NTFS files and folders. The NTFS file system also includes other features such as
encryption, disk quotas, file compression, mounted drives, NTFS change journal, and multiple
data streams. You can also store Macintosh files on NTFS partitions.
Encrypting File System (EFS) enables users to encrypt files and folders, and entire data drives on
NTFS formatted volumes. Users that are utilizing EFS can share encrypted files with other users
on file shares and even Web folders. You can configure EFS features through Group Policy and
command-line tools. Through disk quotas, you can manage disk space utilization of your users
for critical NTFS volumes. Disk quotas are used to track disk space usage on a per user, per
NTFS volume basis.
Before you can apply NTFS permissions, you have to format the disk partition as an NTFS
partition. NTFS permissions are applied through Windows Explorer. You simply have to right-
click the particular file or folder that you want to control access to and select Properties from the
shortcut menu. The Properties dialog box of NTFS files and folders contains a Security tab. This
the tab utilized to apply NTFS permissions.
Deploying Service Packs and Hotfixes
A service pack is a collection of updates, or executable files that relate to an operating system
(OS). Service packs typically deal with setup, security, and application compatibility
enhancements or issues. Service packs are issued by Microsoft every couple of months to ensure
that the operating system is up to date, and to correct any existing issues. Service packs improve
on the functionality of a computer when they include new tools and capabilities. They can also
contain device drivers.
A hotfix consists of one or multiple files that are applied to the operating system to fix a specific
critical problem. Hotfixes corrects a particular critical operating system fault. A hotfix can
include once-off fixes for a server or client problem. Hotfixes can be downloaded from the
Windows Update site, or from the TechNet Security page at
www.microsoft.com/technet/security/default.asp. The Microsoft Network Security Hotfix
Checker (HFNetChk) included with the Microsoft Baseline Security Analyzer (MBSA) tool can
be used to determine whether your network computers have all the necessary hotfixes. This
powerful tool can speedily check all your network computers. The MBSA tool can also be used
to identify security misconfigurations and weaknesses.
Microsoft Baseline Security Analyzer (MBSA) can be run on Windows 2000, Windows XP and
Windows Server 2003 computers to scan for security weaknesses and missing hotfixes. MBSA
works for:
• Windows 2000 Server, Windows 2000 Advanced Server, Windows 2000 Professional,
Windows XP Professional, Windows NT 4.0, SQL Server 2000, SQL Server 7.0, Internet
Information Server 4.0 / 5.0, IE 5.01, and Office 2000, and Office 2002 - XP
The Microsoft Network Security Hotfix Checker (HFNetChk) included in the Microsoft Baseline
Security Analyzer tool can be used to analyze one or multiple computers for necessary service
packs. The attractive feature of this tool is that it can be scripted to scan a number of different
configurations. It can also scan for necessary updates for one or multiple products. The
HFNetChk tool uses a XML file when it runs that contains detailed information on all the
available hotfixes for many products. The XML file is downloaded from the Microsoft Web site
when it is not included in the directory from where HFNetChk is run.
HFNetChk can scan the following:
• Windows 2000 Server, Windows 2000 Advanced Server, Windows 2000 Professional,
Windows XP Professional, Windows NT 4.0, Windows Media Player, Microsoft Data
Engine 1.0, Exchange Server 5.0, and 2000, SQL Server 2000, SQL Server 7.0, Internet
Information Server 4.0 / 5.0, IE 5.01, and Office 2000 and Office 2002 - XP
You can use either of the following methods or technologies to deploy necessary updates on your
existing computers:
• Windows Update, Automatic Updates, Software Update Services (SUS), Scripting,
Systems Management Server (SMS), or Group Policy
• You can also manually deploy an update from a network share or CD-ROM after you
have obtained it.
Automatic Updates, manual deployment, and Windows Update can only deploy the update to a
single computer or a small number of computers. Software Update Services (SUS), Group
Policy, and scripting, can apply updates to multiple computers. Software Update Services (SUS)
can only be used to deploy service packs and hot fixes for Windows 2000, Windows XP and
Windows Server 2003 computers. Scripting and SMS can be used to deploy hot fixes and service
packs to all the versions of Windows computers. The Software Installation and Maintenance
feature of Group Policy, and scripting work well when a large number of network computers
require the identical update.
You can only use Automatic Updates on:
• Windows 2000 Server, Windows 2000 Advanced Server, Windows 2000 Professional
with SP2 or above, Windows XP Professional Windows XP Home Edition with SP1
You can use Systems Management Server (SMS) to install service packs on SMS client
computers from a network distribution share. Using SMS for deploying updates involves the
following steps:
• You have to create a SMS package that includes the location of the service pack source
files and the package definition file (.pdf) for distributing the service pack. The package
definition file includes the information that would be needed to create the SMS package.
The SMS package includes command-line executables as well. These executables runs on
the SMS client computers to manage how the SMS package executes.
• You then have to distribute the SMS package to the distribution points that you have
identified
• Lastly, you have to create an SMS advertisement that will inform the SMS clients of the
available service packs.
Disabling Unnecessary Services
When you install the Windows Server 2003 operating system, there are a few services which are
automatically installed with the operating system. These services are usually configured with the
Automatic startup type. This means that the service starts automatically when the operating
system starts. The startup type specified for the service controls when and how the service starts.
The configuration of a service is stored in the following location in the Registry
• HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services key
A service can also be configured with one of the startup types listed below:
• Automatic; the service starts automatically when the operating system starts or boots.
Some services that have the Automatic startup type configured when you install
Windows Server 2003 are Automatic Updates, DHCP Client, DNS Client, IPSec
Services, Remote Procedure Call (RPC), Server, Security Accounts Manager, and System
Event Notification.
• Manual; this service needs to be started manually by an Administrator. However, if a
service or process needs to start a particular service, it can start the service.
• Disabled; for a service with the Disabled startup type to start, the actual startup type
needs to be changed to either Automatic or Manual. A service cannot start another
service if that particular service’s startup type is Disabled.
For the following services, it is recommended that you configure the Disabled startup type, if the
server does not require the service:
○ Alerter
○ Application Management
○ ClipBook
○ Distributed File System
○ Distributed Transaction Coordinator
○ Fax Service
○ Indexing Service
○ Internet Connection Sharing (ICS)
○ Internet Connection Firewall (ICF)
○ License Logging
○ Messenger
○ NetMeeting Remote Desktop Sharing
○ Network DDE
○ Network DDE DSDM
○ Print Spooler
○ Remote Access Auto Connection Manager
○ Remote Access Connection Manager
○ Removable Storage
○ Routing And Remote Access
○ Secondary Logon
○ Task Scheduler
○ Telephony
○ Telnet
○ Uninterruptible Power Supply
The System Services area of the Security Configuration and Analysis management console is
used to manage startup and permissions for system services. If you have unnecessary services
running within your environment, you can disable the services. When services are disabled, they
are stopped from starting when the computer starts. The components of the service which you
disable are not uninstalled.
To check the status of a service,
1. Open the Computer Management console
2. Right-click Computer Management in the left console pane, and click Connect To
Another Computer on the shortcut menu.
3. Specify whether you want to check the status of a service on the local computer, or on a
remote computer.
4. Proceed to expand the Services And Applications node.
5. Select Services.
6. The Services window displays the service name, startup type and status of the service, as
well as other information.
To disable unnecessary services,
1. Open the Computer Management console.
2. Right-click Computer Management in the left console pane, and click Connect To
Another Computer on the shortcut menu. Specify whether you want to manage services
on the local computer, or on a remote computer.
3. Expand the Services And Applications node, and select Services
4. Right-click the particular service which you want to disable, and then select Properties
from the shortcut menu.
5. On the General tab of the Properties dialog box, select Disabled in the Startup Type drop-
down list box.
6. Click OK.
Disabling Unnecessary Accounts
All accounts which are not being utilized should be deleted or disabled.
• For employees that are no longer employed at the company, delete this specific
employee’s user account.
• For employees or users that have some form of definite temporarily absence period,
disable the specific employee’s user account.
Additionally, it is recommended that you also disable the following accounts:
• Administrator account: The Administrator account is a well-known account which
provides access to services, files and directories. The Administrator account has full
system access. Once the system is installed, administrators are typically made members
of the Administrators group. You can easily remove administrative rights when
administrators are members of the Administrators group. Ensure that the local
Administrator account has a secure password. If the Administrator account’s password is
weak, unauthorized individuals might be able to access the domain or system. You can
also rename the account, and create a fake Administrator account that has no permissions.
• Guest Account: The Guest account is normally used for users who need infrequent access.
The Guest account is by default disabled when Windows Server 2003 is installed.
Because the Guest account is a member of the Everyone group, it has access to files and
folders. It is recommended to restrict the utilization of the Guest account. You can also
rename the Guest account, and you should change the password regularly.
Allowing users and computers unlimited access to system resources and network resources can
ultimately compromise the security organization. Even though users and computers need to
access network and system resources to perform certain tasks, the access that they require should
be limited to those necessary to perform their required tasks.
User accounts are required to log on to a Windows NT, Windows 2000, Windows XP and
Windows Server 2003 network. User accounts are used for authentication, authorization, and
auditing. A user account enables a user to log on to the domain and to access resources. A local
user account enables a user to log on to a computer and access local resources on that particular
computer. A domain user account enables a user to log on to a domain, and access network
resources. Built-in user accounts are typically used for administrative tasks. You should strive to
assign users, services, and computers with the least number of privileges necessary to perform
the tasks they need to.
Enforce Strong Password Usage
Passwords are used to protect networks and computers from unauthorized individuals from
accessing network resources. A strong password stands a better chance of protecting network
resources because they are harder to interpret by unauthorized individuals. A good strong
password should not be an alteration of the logon name, and should definitely not be the name of
the user. It should at least be seven characters in length, and should include two alphabetic
characters and a non-alphabetic character.
Passwords are probably the component that presents the most vulnerability in an authentication
implementation. Passwords that are weak can easily be identified, even when password
encryption is used. Password encryption is the process whereby the password of the user is
encrypted. What this means is that the password is not transmitted over the network in clear text.
When users actually use strong complicated passwords, an unauthorized individual attempting to
access the system should not easily be able to interpret or decipher the password. Regularly
having users change their passwords also ensures that even when a strong password is
deciphered by an unauthorized user, the password would probably be invalid.
A weak password is a password that includes some of the following information:
• The name of the user
• The name of the organization
• The login ID of the user
• The word ‘password’
• Blank passwords
A strong password contains none of the above mentioned pieces of information. Strong
passwords have the following characteristics:
• The password is intricate so that it cannot be deciphered by unauthorized network users,
but can also be remembered by the user. The user should not need to document the
password to remember it.
• The password should be at least seven characters in length.
• The password should include characters from three of the following groups:
• Uppercase characters: Letters A through to Z
• Lowercase characters: Letters a through to z
• Non-alphabetic characters such as: $, #, %
• Numeric digits such as 0 through to 9
Password rules are based on the settings defined in password policies. You can define password
policies by:
• Enforce Password History. Used to prohibit users from using the identical password
when they are specifying a new password. By default, 24 passwords are remembered.
• Maximum Password Age. Indicates the time, in days, that a user can have the identical
password. The default setting is 42 days
• Minimum Password Age. Indicates the time, in days, that a user is required to use the
identical password. The default setting is 1 day.
• Minimum Password Length. Indicates the least number of characters a password has to
have. The default setting is 7 characters.
• Password Must Meet Complexity Requirements. The password in this case has to be at
least six characters in length, and cannot include the account name of the user. The
password also has to include characters from three of these groups: Numbers, non
alphabetic numbers, English uppercase letters, And English Lowercase Letters. The
default setting is enabled.
• Store Passwords Using Reversible Encryption. Indicates whether the operating system
uses reversible encryption when storing the password of the user. The default setting is
disabled.
Perform Regular Backups
A backup is the process of archiving data and system files on a computer to a different location
on a hard disk, or other media type.
Backups are typically preformed for a number of reasons, including the following:
• Protect the network environment from the accidental deletion of, or modification of data,
and from hardware failures: Backups prove invaluable when authorized users
intentionally delete or modify data. The backup would enable you to restore data to its
previous state of integrity. Because certain hardware failures such as corrupted hard disk
drives can cause considerable loss of data, backing up your data would ensure that the
company can continue to perform its mission critical functions when such an event does
occur.
• Store mission critical data: It is recommended to regularly back up mission critical data
so that any previous version of information can be accessed, if necessary, at some time in
the future.
A backup plan should be drawn up to detail the data that has to be backed up, the manner in
which the data should be backed up, the frequency at which the backups should occur, and the
manner in which data restorations should occur. Mission critical data should be backed up, while
temporary files do not possibly need to be backed up. System State data should be backed up.
System State data contains the files which the operating system utilizes, such as the boot files
and system files, and any additional files which the Windows operating system needs to restore
the system. System state data basically contains the main configuration information in Windows
2000, and Windows Server 2003. What actual information is included in system state data is
determined by operating system configuration.
System state typically includes the following important data, files and components:
• The Windows Registry
• The contents of the SYSVOL directory
• Files which are protected by the Windows File Protection system
• Boot and system files: Ntdetect.com, Ntldr and Bootsect.dat.
• The COM+ Class Registration database
• The Active Directory database (Ntds.dit), including all log files and checkpoint files
• Cluster service files
• Certificate service files
• The Internet Information Server (IIS) metabase
It is recommended to backup all data on a server and System State data. You are then prepared
for a disaster such as a hard disk failure on the server because a full backup exists to restore the
server.
The Windows Server 2003 Backup utility offers a few methods that you can use to create backup
jobs and execute backup jobs. You create a backup job by specifying the drives, directories and
files that should be backed up, the storage medium for the backup, the time when the backup
should occur, and other backup options.
1. Click Start, Programs, Accessories, System Tools, and Backup to start the Windows
Server 2003 Backup utility.
2. The Welcome page for the Backup Or Restore Wizard is displayed.
The Backup Or Restore Wizard guides you through the process of backing up the server, and
restoring an existing backup from the hard disk or other media. You can use the Welcome page
of the Backup Or Restore Wizard to open Backup in Advanced Mode. The Advanced Mode
provides more features and flexibility. Clear the checkbox for Always Start In Wizard mode and
select the Advanced Mode link.
With Backup in Advanced Mode, you are given the following options:
• Start the Backup Wizard
• Start the Restore Wizard
• Start the Automated System Recovery Wizard
Previously in Windows NT and Microsoft Windows 2000 operating systems, the emergency
repair disk (ERD) feature was used to recover the system when disasters occurred. Windows XP
Professional and Windows Server 2003 now include the Automated System Recovery (ASR)
feature for recovering the system in disaster situations. The Automated System Recovery (ASR)
feature is a new feature found in the Windows Backup utility.
The ASR disk contains vital configuration information which can be used to fix the following:
• Boot sector
• System files
• Startup environment
When a server failure occurs, all you have to do is restart the computer using the Windows XP
Professional or Windows Server 2003 installation CD-ROM. During Setup, select the Automated
System Recovery option. The information on the ASR disk is then utilized to restore all standard
drivers and files, and the ASR backup is used to restore the rest of the files.
The Windows Backup utility is used to create ASR sets. You can access the Backup Utility
through one of the following methods:
• Click Start, click Run, and enter Ntbackup.exe in the dialog box.
• Click Start, All Programs, Accessories, System Tools and then select the Backup utility.
Simply follow the prompts of the Automated System Recovery Preparation Wizard to back up
your system configuration and to create the ASR floppy disk listing the information for restoring
your system. The ASR floppy disk that is created is specific to the system and the time when
ASR set was created
Access control
deals with
determining whether a user that has been authenticated can perform particular activities. When
an attempt is made to access objects, access control determines whether the object can be
accessed. Objects include Active Directory objects, files and folders, shared folders, network
services, printers, registry keys and values, Windows Management Interface objects, and
Terminal Services connections. Windows Server 2003 simplifies access control management by
using a standard model which utilizes access control lists (ACLs), inherited permissions, and
standard and special permissions, for all the different types of objects.
Before exploring access control any further, you should familiarize yourself with the following
terms:
• Security principal: Any user, group, computer or service can be a security
principal. A security principal has accounts. Local accounts are maintained by
the Local Security Accounts Manager (SAM) on the computer. Accounts in a
Windows 2000 Server, or Windows Server 2003 domain are managed by
Active Directory. Accounts in a Windows NT 4.0 domain are managed by the
SAM database. This database resides on the primary domain controller (PDC).
• Security identifier (SID): When accounts are created, they receive a unique
SID. A SID therefore identifies a user, group, computer or service in the
organization. What this means is that security principals are identified via
SIDS and not their associated names.
• Security descriptor: A security descriptor includes the security information of
an object, and utilizes the SID of the object to identify its owner. When an
object has permissions set up for it, the security descriptor includes the
discretionary access control list (DACL) and the SIDs of the users and groups
which are either allowed or denied access to the secured object.
• Security context: This is information that indicates the identity of a security
principle and its permitted activities on the computer. The security
subsystem utilizes the security context to ascertain what actions can be
performed to the objects on a computer.
• Security groups: These are groups utilized to manage users and domain
objects. Through security groups, you can configure security permissions to
users or members of a particular group.
• Security Settings: These are security configuration settings which can be
applied to computers locally or through the Security Settings extension of
Group Policy.
• Access token: Access tokens contain the following:
○ The SID for a security principal
○ The SIDs for the groups that the security principal is a member of
○ A list of a rights of the security principle on the local computer
An Access token supply the security context for the actions of the security
principle on the computer; and it supply the security context for application
threads utilized by the security principle.
• Object: An object refers to a resource that can be utilized by a process or
program. Objects are files, printers, registry keys, Active Directory objects,
sessions, access tokens, and processes and threads
• Inheritance: This is the means by which access control information is moved
via an associated tree of objects, and the child objects obtain the access
control information of its parent object. This typically happens with files
inheriting access control information from its parent folder.
• Access control lists (ACLs): ACLs contain access control entries (ACEs) that
describe the permissions associated with objects and object properties. For a
security principal, an ACE defines the rights which are denied, allowed and
audited for a particular security principal. Access control lists basically deal
with the following layers of security:
○ NTFS permissions: NTFS permissions are applied to files and folders.
This is the more favourable permissions because it can support
intricate file and folder structures.
○ Share permissions: Share permissions basically apply to users that are
connecting over the network to a network resource. Share permissions
do not support inheritance, and are not as flexible as NTFS
permissions.
• Owner: The owner of an object can deny or allow access to the particular
object that it is the owner of. The owner of an object can also enable a
different security principal to take ownership of the ownership.
• Permissions: Permissions are assigned to Active Directory objects, registry
objects, and files and folders. Permissions basically specify the type of access
given to a user, group, or computer, and can be applied to any user, group or
computer. Permissions can also be applied to special identities such as the
creator owner, interactive group, local system, network group, and service
group. Because permissions are inherited, you can configure child objects to
inherit its parent object permissions.
• Rights: Rights enable a user to carry out certain activities such as restarting
the computer.
Registry permissions
Access to registry keys and values are typically restricted because recklessly changing these keys
or values can have catastrophic consequences. The standard permissions that can be applied to
registry keys and values are summarized below:
• Full Control enables users to perform numerous actions on a registry key and
value. This includes creating and deleting registry subkeys and values
• Read: Enables users to view registry subkeys and values.
• A few special permissions can also be assigned to a user or group.
Printer permissions
The standard permissions that can be applied to printers are summarized below:
• Print: Members of the Everyone group are by default assigned the Print
permission. This permission enables users to connect to a printer, and
transmit documents for printing.
• Manage Printers: This permission enables users to control the activities of the
printer including pausing/restarting the printer, setting Print permissions,
changing printer properties, and sharing the printer.
• Manage Documents allow users to pause, restart, cancel, resume, and
rearrange the order by which documents were submitted to the printer.
• A few special permissions can be assigned for users and groups.
Built-in Groups
When you create an Active Directory domain, a few built-in groups are automatically created
which can be utilized to manage access to shared resources and to delegate particular domain
wide administrative roles. When the built-in groups are created, they are typically also
automatically assigned with specific user rights. These user rights in turn determine which
activities a group and its associated members can perform in the domain or forest. A few built-in
groups are summarized below:
• Account Operators: Members of the Account Operators group have the Allow
logon locally and Shut down the system user rights. Members of these groups
can create, modify and delete accounts for users, groups and computers
residing in the organizational units (OUs), Users container and Computers
container in the domain.
• Administrators: Members of the Administrators group have most of the
available user rights, and have full control over the server. Its members can
assign server rights and access control permissions for other users.
• Backup Operators: The Backup Operators group has no default members. Any
members added to the Backup Operators group have the Allow logon locally,
Back up files and directories, Restore files and directories and Shut down the
system user right by default.
• Network Configuration Operators: Members of this group can modify the
Transmission Control Protocol/Internet Protocol (TCP/IP) settings. They
typically manage the network configuration settings of servers and
workstations within the domain.
• Incoming Forest Trust Builders: Members added to this group can create
incoming forest trusts (one way) to the forest root domain.
• Print Operators: Members of the Print Operators group can manage Active
Directory printer objects in the domain, and can create, share and delete
printers that are connected to domain controllers. Group members have the
Allow logon locally and Shut down the system default user rights.
• Server Operators: This group's members have the Allow logon locally, Back
up files and directories, Change the system time, Force shutdown from a
remote system, Restore files and directories, and Shut down the system
default user rights.
• Remote Desktop Users. Members can remotely log on to domain controllers.
• Terminal Server License Servers: Members of the Terminal Server License
Servers group have permission to access the Terminal Server License
servers.
• Performance Log Users: Members added to the Performance Log Users can
manage performance counters, logs and alerts on domain controllers.
• Performance Monitor Users: This group's members can monitor performance
counters on domain controllers.
• Users: Members of the Users group can run applications, and use network
printers.
• Local
computer
(local security policies)
• Active Directory site, domain, or organizational unit (domain security policies
)
Local security policies are managed through Local Computer Group Policy Objects (GPOs), and
domain security policies are managed through Group Policy with the Active Directory Domain
Controller GPOs. However, domain security policies override local security policies.
In Windows Server 2003 Active Directory environments, group policies include configuration
settings for the following:
• Software policies
• Scripts
• Security policies
• Application and file deployment policies
What is Group policy and GPOs?
Group Policy settings are stored in a Group Policy Object (GPO). Group Policy is an Active
Directory feature that provides the means for you to effectively and efficiently manage large
numbers of computers. You can manage both user and computer configuration settings centrally.
You can define group policies that affect a computer, irrespective of the particular user logging
on to the computer. For instance, you can through a policy, configure the proxy server settings
for a computer. You can define group policies that affect a user, irrespective of the computer
which the user utilizes to log on to the system. For instance, you can use group policies to
specify the applications or programs which are available to the user, and the programs which
should exist on the user's desktop
You can define group policies as being a collection of user and computer configuration settings
which you can link to computers, sites, domains and organizational units (OUs). Once linked,
Group Policy defines the manner in which the operating system, network resources, and
applications and programs operate for users within the organization.
A group policy object (GPO) is an Active Directory object which contains one or more Group
Policy settings which affect the configuration settings for users or computers. A GPO acts as a
container for the settings configured in Group Policy files. The Active Directory components that
can be linked to a GPO are computers, sites, domains, organizational units (OUs). By linking a
GPO to sites, domains, and OU actually applies the GPO settings to any user or computer objects
within that particular container.
An important Group Policy concept is that Group Policy settings are hierarchical. What this
means is that it can be linked and applied at different levels, as illustrated below:
• Sites: You can define GPOs, and link it to an entire site in Active Directory.
The GPOs would then apply to each domain and server that belongs to the
particular site. If the site contains multiple domains, the GPOs are applied to
all the domains within the site.
• Domains: When you define GPOs, and link it to a particular domain in Active
Directory, it is applied to all Computer objects and User objects that belong
to, or are stored within that particular domain.
• Organizational Units (OUs): As is the case with the other two levels at which
you can link and apply GPOs, you can define and link GPOs to a specific OU in
Active Directory. The GPOs are then applied to all Active Directory objects
stored within the particular OU.
All computers and users located beneath the container that the GPO is linked to, is automatically
within the scope of the particular GPO. They will therefore be affected by each and every Group
Policy setting specified in the GPO.
Because multiple GPOs can be linked to sites, domains, and OUs, they are applied to either the
user or to the computer in a particular sequence or order. This concept is illustrated below:
1. Local GPO: A computer running Windows Server 2003 has a local GPO. The
local GPO is applied first and therefore has the least precedence when group
policies are applied. They are always overridden by Active Directory based
GPOs. Active Directory based GPOs are also referred to as nonlocal GPOs.
2. Site GPOs: A GPO linked to a site in Active Directory is applied after the local
GPO is applied. Because multiple GPOs can be linked to a particular site, the
site GPOs are applied in the order as specified by the Administrator.
3. Domain GPOs: Domain GPOs are applied next, and therefore have higher
precedence than site GPOs and the local GPO. Again, when multiple GPOs are
linked to a particular domain, they are applied in the order as defined by the
Administrator.
4. OU GPOs: OU GPOs have the highest precedence. Group Policy application
starts at the top of the tree, and then moves down to the OU containing the
user object or computer object.
Group Policy settings are usually passed from a parent OU to a child OU. This is known as
Group Policy inheritance. When Group Policy settings are specified for a parent OU, the Group
Policy settings are applied to each child OU associated with the particular parent OU. If the same
Group Policy setting is specified for a parent OU and a child OU, the setting of the child OU
overrides the setting of the parent OU. You can however override Group Policy inheritance to
prevent a child OU from receiving the Group Policy settings of its parent OU.
To configure and manage policy settings in GPOs, and link GPOs to computers, sites, domains
and organizational units (OUs), Windows Server 2003 provides the following set of management
tools:
• The Active Directory Users And Computers (ADUC) console
• The Group Policy Management console
• The Group Policy Object Editor
• The Resultant Set Of Policy snap-in
• The Windows Settings node in the Computer Configuration node and in the
User Configuration node contains the following nodes: Scripts extension: You
can define the following types of scripts:
○ In Computer Configuration: Startup and shutdown scripts execute
when the computer starts, or shuts down
○ In User Configuration: Logon and logoff scripts execute when the user
logs on or logs off the particular computer.
• When more than one script exists for a user or computer, logoff scripts are
processed before shutdown scripts.
• Security Settings node: You can define the security levels assigned to a local
GPO or nonlocal GPO.
Kerberos Policies
The Kerberos authentication does not transmit passwords during the authentication process.
Instead, it uses tickets. Tickets are specially formatted data packets that allow a client to access a
resource. The Kerberos authentication type is dependant on the Key Distribution Center (KDC)
to issue tickets. Each network client makes use of DNS to find the closest available KDC to
obtain a Kerberos ticket. The ticket usually remains active for about 8 or 10 hours. The Key
Distribution Center (KDC) is a service which runs as a component of Active Directory. In fact,
each domain controller in a Windows Server 2003 domain operates as a Key Distribution Center
(KDC). It is the Key Distribution Center (KDC) which manages the database of security account
information for each security principal within a domain. Security principals that form the
foundation of the Active Directory security architecture are user accounts, security groups, and
computer accounts.
• Kerberos policies are used to define and configure Kerberos specific settings
for domain user accounts only. The following Kerberos policy settings are
located within the Kerberos Policy area of the Account Policies node: Enforce
User logon restrictions: When enabled, the Kerberos Key Distribution Center
(KDC) validates each request received for a session ticket against the user
rights policy of the user account sending the request.
• Maximum lifetime for service ticket: Specifies the time (in minutes) that a
user can utilize a Kerberos session ticket to access a specific service.
• Maximum lifetime for user ticket: Specifies the maximum time duration for
which a user is allowed to utilize a ticket granting ticket (TGT) before the user
has to request a new ticket granting ticket. The default setting is 10 hours.
• Maximum lifetime for user ticket renewal: Specifies the amount of time that a
user can renew a ticket granting ticket (TGT). The default value is 7 days.
• Maximum tolerance for computer clock synchronization: Specifies the
maximum time difference which can be present between the server and the
client computer.
Network Attacks
Understanding Network Attacks
A network attack can be defined as any method, process or means used to maliciously attempt to
compromise the security of the network.
Password policy settings can be used to specify and enforce a number of rules for
passwords:
○ Define whether passwords are simple or complex.
○ Define whether password history is maintained.
○ Define the minimum length for passwords.
○ Define the minimum password age.
○ Define the maximum password age.
○ Define whether passwords are stored using reversible encryption or irreversible
encryption.
Account lockout policies should be implemented if your environment is particularly
vulnerable to threats arising from passwords which are being guessed. Implementing an
account lockout policy ensures that the account of a user is locked after an individual has
unsuccessfully tried for several times to provide the correct password. The important
factor to remember when defining an account lockout policy is that you should
implement a policy that permits some degree of user error, but that also prevents hackers
from using your user accounts. The following password and account lockout settings are
located in the Account Lockout Policy area in Account Policies:
○ Account lockout threshold: This setting controls the number of times after which
an incorrect password attempt results in the account being locked out of the
system.
○ Account lockout duration: This setting controls the duration that an account which
is locked, remains locked. A setting of 0 means that an administrator has to
manually unlock the locked account.
○ Reset account lockout counter after: This setting determines the time duration that
must pass subsequent to an invalid logon attempt occurring prior to the reset
account lockout counter being reset.
• Brute force attack: Brute force attacks simply attempt to decode a cipher by trying each
possible key to find the correct one. This type of network attack systematically uses all
possible alpha, numeric, and special character key combinations to find a password that is
valid for a user account. Brute force attacks are also typically used to compromise
networks that utilize Simple Mail Transfer Protocol (SNMP). Here, the network attacker
initiates a brute force attack to find the SNMP community names so that he/she can
outline the devices and services running on the network. A few methods of preventing
brute force attacks are listed here:
○ Enforce the use of long password strings.
○ For SNMP use long, complex strings for community names.
○ Implement an intrusion detection system (IDS). By examining traffic patterns, an
IDS is capable of detecting when brute force attacks are underway.
• Denial of Service (DoS) attack: A DoS attack is aimed at preventing authorized,
legitimate users from accessing services on the network. The DoS attack is not aimed at
gathering or collecting data. It is aimed at preventing the normal use of computers or the
network by authorized, legitimate users. The SYN flood from 1996 was the earliest form
of a DoS attack which exploited a vulnerability of the Transmission Control Protocol
(TCP). A DoS attack can be initiated by sending invalid data to applications or network
services until the server hangs or simply crashes. The most common form of a DoS attack
is TCP attacks. DoS attacks can use either of the following methods to prevent authorized
users from using the network services, computers, or applications:
○ Flood the network with invalid data until traffic from authorized network users
cannot be processed.
○ Flood the network with invalid network service requests until the host providing
that particular service cannot process requests from authorized network users. The
network would eventually become overloaded.
○ Disrupt communication between hosts and clients through either of the following
methods:
Modification of system configurations.
Physical destruction of the network. Crashing a router for instance would
prevent users from accessing the system.
There are a number of tools easily accessible and available on the Internet which can be
used to initiate DoS attacks:
○ Bonk
○ LAND
○ Smurf
○ Teardrop
○ WinNuke
A network attacker can increase the enormity of a DoS attack by initiating the attack
against a single network from multiple computers or systems. This type of attack is
known as a distributed denial of service (DDoS) attack. Network administrators can
experience great difficulty in fending off DDoS attacks, simply because blocking all the
attacking computers, can also result in blocking authorized users. The following
measures can be implemented to protect a network against DoS attacks:
○ Implement and enforce strong password policies.
○ Back up system configuration data regularly.
○ Disable or remove all unnecessary network services.
○ Implement disk quotas for your user and service accounts.
○ Configure filtering on your routers and patch operating systems.
The following measures can be implemented to protect a network against DDoS attacks:
○ Limit the number of ICMP and SYN packets on router interfaces.
○ Filter private IP addresses using router access control lists.
○ Apply ingress and egress filtering on all edge routers.
• Man-in-the-middle (MITM) attack: A man-in-the-middle (MITM) attack occurs when a
hacker eavesdrops on a secure communication session and monitors, captures and
controls the data being sent between the two parties communicating. The attacker
attempts to obtain information so that he/she can impersonate the receiver and sender
communicating. For a man-in-the-middle (MITM) attack to be successful, the following
sequence of events has to occur:
○ The hacker must be able to obtain access to the communication session to capture
traffic when the receiver and sender establish the secure communication session.
○ The hacker must be able to capture the messages being sent between the parties
and then send messages so that the session remains active.
There are some public key cryptography systems, such as Diffie-Hellman (DH) key
exchange which are rather susceptible to man-in-the-middle attacks. This is due to the
Diffie-Hellman (DH) key exchange using no authentication.
What are viruses?
A virus can be defined as a malicious code which affects and infects files on a system. Numerous
instances of the files are then recreated. Viruses usually lead to some sort of data loss, and/or
system failure.
There are numerous methods by which a virus can get into a system:
• Through infected floppy disks.
• Through an e-mail attachment infected with the virus.
• Through downloading software infected with the virus.
A few common types of viruses are listed here:
• Boot sector viruses: These are viruses that infect a hard drive's master boot record. The
virus is then loaded into memory whenever the system starts or is rebooted.
• File viruses or program viruses or parasitic viruses: These are viruses that are attached
to executable programs. Whenever the particular program is executed, the viruses are
loaded into memory.
• Multipartite viruses: These are viruses which are a combination of a boot sector virus and
a file virus.
• Macro viruses: These are viruses that are written in macro languages utilized by
applications, of which Microsoft Word is one. Macro viruses usually infect systems
through e-mail.
• Polymorphic viruses: These viruses can be considered as being the more difficult viruses
to fend against because they can modify their code. Virus protection software often finds
polymorphic viruses harder to detect and remove.
If you discover that a virus has infected your system, use the recommendations listed here:
• Scan each of your systems to gauge how infected your infrastructure is.
• To prevent the virus from spreading any further. You should immediately disconnect all
infected systems.
• All infected systems should be installed from a clean backup copy, that is, a back up
which was taken when the system was clean from virus infections.
• Inform the antivirus vendor so that the vendor's virus signature database is updated
accordingly.
A few methods of protecting your network infrastructure against viruses are listed here:
• Install virus protection software on systems.
• Regularly update all installed virus protection software.
• Regularly back up systems after they have been scanned for viruses, and are considered
clean from virus infection.
• Your users should be educated to not open any e-mail attachments which were sent from
individuals they do not recognize.
What are worms?
As mentioned previously, a virus is a form of malicious code that infects files on the system. A
worm on the other hand is an autonomous code that propagates over a network, targeting hard
drive space and processor cycles. Worms not only infects files on one system but can propagate
to other systems on the network. The purpose of a worm is to deplete available system resources.
Hence the reason why a worm makes copies of itself over and over and over. Worms basically
make copies of itself or replicate until available memory is used, bandwidth is unavailable, and
legitimate network users are no longer able to access network resources or services.
There are a few worms that are sophisticated enough to corrupt files, render systems un-
operational, and even steal data. These worms usually have one or numerous viral codes.
A few previously encountered worms are listed here:
• The ADMw0rm worm took advantage of a buffer overflow in Berkeley Internet Name
Domain (BIND).
• The Code Red worm utilized a buffer overflow vulnerability in Microsoft Internet
Information Services (IIS) version 4 and IIS version 5.
• The LifeChanges worm exploited a Microsoft Windows weakness which allowed scrap
shell files to be utilized for running arbitrary code.
• The LoveLetter worm used a Visual Basic Script to replicate or mass mail itself to all
individuals in the Windows address book.
• The Melissa worm utilized a Microsoft Outlook and Outlook Express vulnerability to
mass mail itself to all individuals in the Windows address book.
• The Morris worm exploited a Sendmail debug mode vulnerability.
• The Nimda worm managed to run e-mail attachments in Hypertext Markup Language
(HTML) messages through the exploitation of HTML IFRAME tag.
• The Slapper worm exploited an Apache Web server platform buffer overflow
vulnerability.
• The Slammer worm exploited a buffer overflow vulnerability on un-patched machines
running Microsoft SQL Server.
What are Trojan Horses?
A Trojan horse or simply Trojan, is a file or e-mail attachment which is disguised as being a
friendly, legitimate file. When executed though, the file corrupts data and can even install a
backdoor which hackers can utilize to access the network.
A Trojan horse differs to a virus or worm in the following ways:
• Trojan horses disguise themselves as friendly programs. Viruses and worms are much
more obvious in their actions.
• Trojan horses do not replicate like worms and viruses do.
A few different types of Trojan horses are listed here:
• Keystroke loggers monitor the keystrokes that a user types and then e-mails the
information to the network attacker.
• Password stealers are disguised as legitimate login screens which wait for users to
provide their passwords so that they can be stolen by hackers. Password stealers are
aimed at discovering and stealing system passwords for hackers.
• Remote administration tools (RATs) are used by hackers to gain control over the network
from some remote location.
• Zombies are typically used to initiate distributed denial of service (DDoS) attacks on the
hosts within a network.
Predicting Network Threats
To protect your network infrastructure, you need to be able to predict the types of network
threats to which it is vulnerable. This should include an analysis of the risks that each identified
network threat imposes on the network infrastructure.
A model known as STRIDE is used by security experts to classify network threats:
• Spoofing identity: These are attacks that are aimed at obtaining user account information.
Spoofing identity type attacks typically affect data confidentiality.
• Tampering with data: These are attacks that are aimed at modifying company
information. Data tampering usually ends up in affecting the integrity of data. A man-in-
the-middle attack is a form of data tampering.
• Repudiation: Repudiation takes place when a user performs some form of malicious
action on a resource and then later denies carrying out that particular activity. Network
administrators usually have no evidence which they can use to back up their suspicions.
• Information disclosure: Here, private and confidential information is made available to
individuals who should not have access to the particular information. Information
disclosure usually impacts data confidentiality and network resource confidentiality.
• Denial of service: These attacks affect the availability of company data and network
resources and services. DoS attacks are aimed at preventing legitimate users from
accessing network resources and data.
• Elevation of privilege: Elevation of privilege occurs when an attacker escalates his/her
privileges to obtain a high level of access like administrative privileges, in an attempt to
gain control of the network system.
Identifying Threats to DHCP Implementations
A few threats specific to DHCP implementations are listed here:
• Because the IP address number in a DHCP scope is limited, an unauthorized user could
initiate a denial of service (DoS) attack by requesting or obtaining a large numbers of IP
addresses.
• A network attacker could use a rogue DHCP server to offer incorrect IP addresses to your
DHCP clients.
• A denial of service (DoS) attack can be launched through an unauthorized user
performing a large number of DNS dynamic updates via the DHCP server.
• Assigning DNS IP addresses and WINS IP addresses through the DHCP server increases
the possibility of hackers using this information to attack your DNS and WINS servers.
protect your DHCP environment from network attacks, use the following strategies:
• Implement firewalls
• Close all open unused ports
• If necessary, use VPN tunnels.
• You can use MAC address filters.
Identifying Threats to DNS Implementations
A few threats specific to DNS implementations:
• Denial of service (DoS) attacks occurs when DNS servers are flooded with recursive
queries in an attempt to prevent the DNS server from servicing legitimate client requests
for name resolution. A successful DoS attack can result in the unavailability of DNS
services, and in the eventual shut down of the network.
• In DNS, footprinting occurs when an intruder intercepts DNS zone information. When
the intruder has this information, the intruder is able to discover DNS domain names,
computer names, and IP addresses which are being used on the network. The intruder
then uses this information to decide on which computers he/she wants to attacks.
• IP Spoofing: After an intruder has obtained a valid IP address from a footprinting attack,
the intruder can use the IP address to send malicious packets to the network, or access
network services. The intruder can also use the valid IP address to modify data.
• In DNS, a redirection attack occurs when an intruder is able to make the DNS server
forward or redirect name resolution requests to the incorrect servers. In this case, the
incorrect servers are under the control of the intruder. A redirection attack is achieved by
an intruder corrupting the DNS cache in a DNS server that accepts unsecured dynamic
updates.
To protect an external DNS implementation from network attacks, use the following list of
recommendations:
• DNS servers should be placed in a DMZ or in a perimeter network.
• Access rules and packet filtering should be configured firewalls to control both source
and destination addresses and ports.
• Host your DNS servers on different subnets and ensure that the DNS servers have
different configured routers.
• Install the latest service packs on your DNS servers
• All unnecessary services should be removed.
• Secure zone transfer data by using VPN tunnels or IPSec.
• Ensure that zone transfer is only allowed to specific IP addresses.
• For Internet facing DNS servers, disable recursion, disable dynamic updates, and enable
protection against cache pollution
• You can use a stealth primary server to update secondary DNS servers which are
registered with ICANN.
Identifying Threats to Internet Information Server (IIS) servers (Web servers)
The security vulnerabilities of the earlier versions of Internet Information Server (IIS), including
IIS version 5, were continuously patched up by service packs and hotfixes available from
Microsoft. Previously when IIS was installed, all services were enabled and started; all service
accounts had high system rights; and permissions were assigned to the lowest levels. This
basically meant that the IIS implementation was vulnerable to all sorts of attacks from hackers.
Microsoft introduced the Security Lockdown Wizard in an attempt to address the security
loopholes and vulnerabilities which existed in the previous versions of IIS. The Security
Lockdown Wizard in IIS 6 has been included in the Web Service Extensions (WSE).
IIS is installed in locked-down mode with IIS 6. The only feature immediately available is to
access static content. You actually need to utilize the WSE feature in the IIS Manager console
tree to manually enable IIS to run applications and its features. By default, all applications and
extensions are prohibited from running.
To protect IIS servers from network attacks, use the following recommendations:
• To prevent hackers from using default account names, all default account names,
including the Administrator account and Guest account should be changed. You should
utilize names for these accounts which are difficult to guess.
• To prevent a hacker from compromising Active Directory should the Web server be
compromised, the Web server should be a stand-alone server or a member of a forest,
other than the forest which is used by the private network.
• All the latest released security updates, service packs, and hotfixes should be applied to
the Web server.
• All sample applications should be removed from a Web server. A few sample application
files are installed by default with IIS 5.0.
• All unnecessary services should be removed or disabled. This would ensure that network
attackers cannot exploit these services to compromise the Web server.
• Disable the utilization of parent paths. Hackers typically attempt to access unauthorized
disk subsystem areas through parent paths.
• Apply security to each content type. Content should be categorized into separate folders,
based on content type. You should then apply discretionary access control lists for each
content type you have identified.
• To protect commonly attacked ports, use IPSec.
• To protect the secure areas of the Web server, use the Secure Socket Layer (SSL)
protocol.
• To detect hacking activity, implement an intrusion detection system (IDS).
• A few recommendations for writing secure code for ASP or ASP.NET applications are
summarized here:
○ ASP pages should not contain any hard-coded administrator account names and
administrator account passwords.
○ Sensitive and confidential information and data should not be stored in hidden
input fields on Web pages and in cookies.
○ Verify and validate form input prior to it being processed.
○ Do not use information from HTTP request headers to code decision branches for
applications.
○ Be wary of buffer overflows generated by unsound coding standards.
○ Use Secure Sockets Layer (SSL) to encrypt session cookies.
Identifying Threats to Wireless Networks
A few threats specific to DNS implementations:
• Eavesdropping attacks: The hacker attempts to capture traffic when it is being transmitted
from the wireless computer to the wireless access point (WAP).
• Masquerading: Here, the hacker masquerades as an authorized wireless user to access
network resources or services.
• Denial of service (DoS) attacks: The network attacker attempts to prevent authorized
wireless users from accessing network resources by using a transmitter to block wireless
frequencies.
• Man-in-the-middle attacks: If an attacker successfully launches a man-in-the-middle
attack, the attacker could be able to replay, and modify wireless communications.
• Attacks at wireless clients: The attacker starts a network attack at the actual wireless
computer which is connected to an untrusted wireless network.
To protect wireless networks from network attacks, use the following strategies:
• Administrators should require all wireless communications to be authenticated and
encrypted. The common technologies used to protect wireless networks from security
threats are Wired Equivalent Privacy (WEP), Wi-Fi Protected Access (WPA), and IEEE
802.1X authentication
• Regularly apply all firmware updates to your wireless devices.
• Place the wireless network in a wireless demilitarized zone (WDMZ). A router or firewall
should isolate the private corporate network from the WDMZ. DHCP should not be used
in the wireless demilitarized zone.
• To ensure a high level of wireless security, your wireless devices should support 802.1X
authentication using Extensible Authentication Protocol (EAP) authentication; Temporal
Key Integrity Protocol (TKIP); and use IPSec to secure communication between the AP
and the RADIUS server.
• The default administrative password utilized to manage the AP should be a complex,
strong password.
• The SSID should not contain the name of the company, the address of the company, and
any other identification-type information
• You should not utilize shared key encryption because it can lead to the compromise of
the WEP keys.
• To protect the network from site survey mechanisms, disable SSID broadcasts.
Determining Security Requirements for Different Data
Types
When determining security requirements for different data types it is often helpful to categorize
data as follows:
• Public data: This category includes all data which is already publicly available on the
company's Web site or news bulletins. Because the data is already publicly available, no
risk is typically associated with the data being stolen. You do however need to maintain
and ensure the integrity of public data.
• Private data: Data that falls within this category is usually well-known within your
organization's environment but is not well-known to the outside public. A typical
example of data that falls within this category is data on the corporate intranet.
• Confidential data: Data that falls within this category is data such as private customer
information that should be protected from unauthorized access. The organization would
almost always suffer some sort of loss if confidential data is intercepted.
• Secret data: This is data which can be considered more confidential and sensitive in
nature than confidential data. Secret data consists of trade secrets, new product and
business strategy information, and patent information. Secret data should have the highest
levels of security.
Creating an Incidence Response Plan
The terminology, incident response, refers to planned actions in response to a network attack or
any similar event that affects systems, networks and company data. An Incident Response plan is
aimed at outlining the response procedures that should take place when a network is being
attacked or security is being compromised.
The Incident Response plan should assist an organization with dealing with the incident in an
orderly manner. Reacting to network attacks by following a planned approach defined by a
security policy is the better approach.
These security policies should clearly define the following:
• The response to follow for each different type of incident.
• The individual(s) who are responsible for dealing with these incidents.
• The escalation procedures which should be followed.
An Incident Response plan can be divided into the following four steps:
• Response: Determine how network attacks and security breaches will be dealt with.
• Investigation: Determine how the attack occurred, why the specific attack occurred, and
the extent of the attack.
• Restoration: All infected systems should be taken offline and then restored from a clean
backup.
• Reporting: The network attack or security breach should be reported to the appropriate
authorities.
Before you attempt to determine the existing state of a machine that is being attacked, it is
recommended that you first record the information listed here:
• The name of the machine.
• The IP address of the machine.
• The installed operating system, operating system version, and installed service packs.
• All running processes and services.
• List all parties that are dependent on the server. These are the individuals which you need
to inform of the current situation.
• Obtain the following valuable information:
○ Application event log information.
○ System event log information.
○ Security event log information.
○ All other machine specific event logs, such as DNS logs, DHCP logs, or File
Replication logs.
• Record all information which indicates malicious activities. This should include:
○ All files that have been modified, corrupted, or deleted.
○ All unauthorized processes running.
• Try to identify and record the source of the network attack.