WINDOWS NT SECURITY is a combination of techniques that ensure a
consistent level of protection against unwanted access. To implement security,
you must protect your network, the operating system, and your data. You do so by
using NT's logon authentication, object security, and user rights. To take
advantage of NT's highest security capabilities, C2-level security, you need the
correct software and hardware in the specified configuration. NT provides
auditing tools to help you assess your NT security situation, but you also need
to be aware of the security issues involved with communications over the
Internet. So to ensure that you're protected on all fronts, you need to know
about all the issues and techniques involved with NT security.
The Security Spectrum
Security breaks down into three main functional areas: over-the-wire network
security, OS security, and data encryption.
Network security provides authentication (making sure the data
server and the recipient are correct and secure) and ensures data integrity
(making sure the data received is the same as the data sent). Achieving network
security means implementing a network protocol, such as NetBEUI and TCP/IP,
tailored to the data you're transmitting (for more information about network
security, see John Enck, "Confronting Your Network Security Nightmares,"
page 81). On the Internet, security protocols, such as Kerberos, are mostly
services that run on top of TCP/IP.
These protocols offer various levels of security, performance (mostly
achieved by minimizing security protocol overhead), flexibility, and
availability across multiple platforms. After the network infrastructure is in
place, adding and extending a security protocol is theoretically
straightforward. All you need is a consensus among the members of the networking
community--a process like herding cats.
OS security must be integrated from the start. If basic security
features aren't present, adding them later is almost impossible. For example,
Microsoft was unable to add meaningful security to 16-bit versions of Windows
after development. A new 32-bit OS, Windows NT, and a new programming model (the
Win32 API) were necessary. NT has robust security features to control user
access to objects such as files and directories, the system Registry, and
printers.
NT also includes a security auditing system that lets administrators track
access to files or other objects, logon attempts, system shutdowns or restarts,
and so on (for more on security auditing, see Mike Reilly, "Find Holes in
Your NT Security," page 87). In contrast, Windows 95 has only rudimentary
logon security, no object security, and only limited logging capabilities.
Data encryption can work in several ways. Many applications have
encryption built-in. Some protocols, such as Secure Simple Mail Transfer
Protocol (SSMTP), support automatic encryption. Third-party encryption, such as
Pretty Good Privacy (PGP), is also available. Microsoft has even added a basic
encryption system, the Cryptography API (CAPI), to the Win32 API.
CAPI is a set of functions that let application and systems software
developers access independent cryptographic services. NT has a base
cryptographic service provider that lets you encode data for secure storage and
transmission with a combination of public and private keys. The method of
encryption is similar to PGP's method. (For more on data encryption, see
Lawrence Hughes, "Secure Enterprise Email," May 1996, "Digital
Envelopes and Signatures," September 1996, and "Exchange Email:
Signed, Sealed, Delivered," page 103.)
The Facets of NT Security
NT provides security in three fundamental areas. These areas are logon
authentication, object security, and user rights.
NT's Local Security Authority validates interactive and remote (via Remote
Access Service--RAS) logons to both local and global (domain) accounts, checking
them against the Security Account Manager (SAM) database of account names and
passwords. The Local Security Authority also manages audit messages.
The Security Reference Monitor checks whether a user has permission to
access an object and perform the requested action. It's also responsible for
generating audit messages. With the Permissions dialog in NT's File Manager (or
Explorer under NT 4.0), you can secure most objects. For example, NT 4.0's
Distributed Component Object Module (DCOM) object server activation and access
security is fully integrated into the NT security model (for more on DCOM, see
my article, "NT 4.0's Distributed Component Object Model," September
1996).
Besides object security, NT lets you control an account's ability to
perform system-related functions. With NT's User Manager (or User Manager for
Domains), you can control which account or group can, for example, add
workstations to a domain (for information about domains, see Mark Minasi, "Domains
and Workgroups," April 1996, and Ed Tittel and Mary Madden, "Domains,
Trust Relationships, and Groups," June 1996), back up or restore files and
directories, change the system time, log on locally, manage auditing and
security logs, and shut down the system. The Local Security Authority maintains
the Account Policy.
Administering Accounts: Logon Authentication
NT manages both machines and users. So it must validate authorized
users and provide them with the means to access the system.
At the highest level, an NT domain is a collection of machines that
domain controllers administer as one and that share a security database.
That database maintains information for all users with accounts in that domain
and for groups (collections of users). An NT domain account--a global
account--has the form domain\user. If you log on to an NT machine, you
can use this style of reference in the Connect As option of the Map
Network Drive dialog to connect to a resource as a different user--even in a
different domain. (The system will prompt you for that user's password.)
Besides domain accounts, each machine can have a local security
database containing information about users--and groups--that only that machine
knows about. Local machines behave like standalone domains. Accounts on local
machines have the form machine\user, but these accounts or groups are
not available on other machines.
The primary tool for administering users and groups on a domain is
usrmgr.exe, or User Manager for Domains, which ships with NT Server. A
reduced-functionality version, musrmgr. exe or User Manager, ships with NT
Workstation and displays information only for the local system. Screen 1 shows
usrmgr.exe, which can display both domain and local information, depending on
the commands you use to start it: usrmgr manages the domain the user is
currently logged on to, usrmgr domainname manages a specific domain, and
usrmgr \\machinename manages a specific machine.
Loading domains in organizations with thousands of domain users can take
several minutes. The ability to start with a particular machine or domain can
save an administrator time. usrmgr also lets administrators manage trust
relationships with domains, so users in domain A can access resources in domain
B as if those users were part of domain B.
A permanent unique value, a Security Identifier (SID), identifies
individual users and groups. After the system assigns the SID, the system won't
use that ID again. If you delete a user or group and then re-create it, that
group or user must receive a new SID, and you have to reestablish any object
access rights for the new SID.