P1: GSB/FFX P2: GSB/FFX QC: IML/FFX T1: IML
WL040C-63 WL040/Bidgoli-Vol III-Ch-64 June 23, 2003 16:45 Char Count= 0
798 WINDOWS2000 SECURITYfrom going across the network and encrypting sessions
and providing users with tickets (“service tickets”) that
enable users to connect to servers to access resources and
services therein. Kerberos security is based on “Key Dis-
tribution Centers” (KDCs), servers that store user creden-
tials and set up encrypted sessions on behalf of users who
need to authenticate and then access resources and ser-
vices. Each KDC distributes a unique, short-term session
key for the client and KDC to use when they authenti-
cate each other. The server’s copy of the session key is
encrypted in the server’s long-term key. The client’s copy
of the session key is encrypted in the client’s long-term key
(which is usually based on the user’s password).
In Kerberos, when a client wants to connect to a server
(e.g., via a share), the following chain of events trans-
pires:The client sends a request to the KDC.
The KDC sends the client two copies of a session key. The
client’s copy of the session key has been encrypted using
the key that the KDC and the client share. The server’s
copy of the session key and data concerning the client
are contained in a “session ticket” that then becomes
encrypted with the key that the KDC shares with the
resource server that the client wants to access.
Once the client receives a reply from the KDC, the KDC
removes both the ticket and the client’s session key and
then caches them.
When the client wants access to the server, it transmits a
message containing the ticket and an authenticator that
contains data about the user and a time stamp from
the client to the resource server. The ticket will still be
encrypted by the server’s secret key; the authenticator
will be encrypted by the session key.
The KDC now sends a user ticket (often termed the
“Ticket Granting Ticket”—a TGT) to the client.
The client fetches the appropriate logon session key
from its cache, using this key to create an authen-
ticator and then sending the authenticator, the user
ticket, and a request for a service session ticket to the
KDC.
The client sends both the authenticator and user ticket
back to the KDC. The KDC responds by giving the client
a server session key.
The client needs to send the service ticket that is en-
crypted with the server session key to the resource
server.In W2K Native Mode each DC also functions as a KDC.
Kerberos not only authenticates users and authorizes ac-
cess to resources and services in Native Mode, but also
serves as the basis for trust relationships between domains
in W2K Native Mode. When trust is established between
Native Mode domains, Kerberos keys for each domain are
sent to the other domain for each KDC within it to use in
authenticating and authorizing trusted access for users
in the first domain. Another nice thing about Kerberos is
that it is almost entirely transparent to users. Kerberos
works only in Native Mode, however; this consideration
provides strong impetus for migrating to this mode.Security Support Provider Interface (SSPI)
SSPI consists of a Win32 interface between security-
related “service providers” (dynamic link libraries or
DLLs) and applications that run at the session level of
networking as well as between other types of authenti-
cation packages. SSPI supports a variety of interfaces,
enabling applications to call security providers to obtain
authenticated connections. SSPI is potentially a consider-
able advantage for security in W2K systems because it pro-
vides an interface for third-party authentication products,
such as the products developed by smart card vendors.
Third-party authentication is much stronger than con-
ventional, password-based authentication in that third-
party authentication generally requires “something that
you have” or “something that you are” plus “something
that you know” (e.g., a Personal Identification Number or
PIN) instead of only “something that you know” (i.e., a
password).Auditing
W2K can provide up to six types of logging, depending on
the particular types that the system administrator enables.
Types of logging include the following:System Logging—this reports events concerning errors,
warnings, and information about the status of system
operations and is nonconfigurable.
Security Logging—this configurable log captures data
about successful and failed access to objects such as
files, directories, and printers, logons and logoffs, use
of rights, policy changes, and so on.
Application Logging—this log, which is configurable by
application programmers, records application-related
events (e.g., such as when Norton AntiVirus finds and
eradicates a virus).
Directory Service Logging—this configurable logging
capability captures access (reads, writes, deletions, and
so forth) to Active Directory objects.
DNS Server Logging—various DNS-related events are
recorded by the DNS Server logging capability, which is
configurable.
File Replication Logging—this configurable logging ca-
pability reports events related to Active Directory repli-
cation.Of these six types of logs, the Security Log (as its name
implies) is the most fundamental to security. The Security
Log can be configured to capture successful and failed
events from each of the following nine event categories:Audit account logon events
Audit account management (e.g., creating, disabling and
deleting accounts; group changes, and so on)
Audit directory service access
Audit logon events (e.g., every service logon)
Audit object access
Audit policy change
Audit privilege use