Tickets, Please! Limit User Access with Windows 2000
Use Windows 2000's default security to make sure no one gets in without your permission. First step: Understand what ships in the product.
- By Roberta Bragg
In the dream world of systems folks, operating systems
would install automatically as unpenetrable fortresses.
Windows 2000 moves closer toward that Nirvana; but rest
assured you’re still guaranteed employment in setting
it up correctly and securely. Having said that, there’s
no need to make your job any harder than it already is.
Follow my explanations here to understand how to make
a clean Win2K installation as secure as possible from
Day 1. Doing so will also make any extra security you
decide to install later easier to learn about and add.
So, what security features come with Win2K? Which install
automatically, and which will need some tweaking? For
starters, here’s a list of some of the major security
enhancements you’ll find in the product:
- More granular file access permissions
- Tighter default Registry settings
- Security Configuration Tool Set and Secedit
- Group Policy Editor
- IP Security (IPSec)
- Built-in smart card integration services
- Windows File Protection
- Built-in public key infrastructure (PKI)
- Encrypting File System (EFS)
The list also includes a host of smaller-but-still-handy
security features like a way to eliminate NetBIOS, which
was a source for many system attacks; tighter file and
program access; “super” hidden files that are difficult
to view; and a write-protected kernel mode.
Although the product ships with all these features, is
it secure on installation? Well, if you buy a house with
an alarm system but don’t understand the key codes and
therefore don’t set it, is it secure? As with any product
you want to secure, you’ll need to delve into the features
and how to use them. Let’s begin by taking a look at each
security service in Windows 2000 and what you must do
to make each work for you.
Like the classical guardian of the gates to Hades, Kerberos
denies access to your OS—or any other resource in your
enterprise—until you prove your identity. The Kerberos
protocol has been an industry standard for many years
and is well-proven to be secure.
On one level, Kerberos works by matching your logon identity
and the password entered against its own Key Distribution
Center; it then provides you with a ticket-granting ticket.
Win2K caches this ticket for later use.
For example, if you want to visit the corporate email
server to read your mail, use this ticket to hop on board
the Kerberos security train. Next stop is the ticket-granting
server. This server makes no judgment about your rights
to access a particular mailbox; it merely verifies the
authenticity of your ticket and issues you another ticket
for the mail server. This second ticket authenticates
you—it tells the mail server that “the bearer of this
document is who he says he is.” The mail server then checks
to see if you have permission to read the mail. And so
Whew! It sounds complicated. But to users, all this extra
security is transparent. It’s also transparent to administrators,
because Win2K uses Kerberos by default for network authentication.
The widespread use of this protocol to secure other distributed
systems offers the potential of integration with other
implementations of Kerberos Version 5. Here at last is
the opportunity for an integrated, truly cross-operating-system,
enterprise-wide authentication security system. Of course,
implementing that integration and understanding the causes
of authentication problems, error messages, and so on,
requires an in-depth understanding of this new protocol.
(For starters, see Microsoft’s white paper on Kerberos
integration at www.microsoft.com/security.)
And Kerberos is no different than any other security based
on passwords—you must implement a tight password policy
in your environment.
Kerberos provides Windows 2000 with a more secure, industry-recognized
replacement for logon than the much-maligned NTLM algorithm
(also known as “challenge/response”) used in Windows NT
(LM is used in Windows 9x). It also adds the capability
for single sign-on through SSPI, Microsoft’s implementation
of the General Security Service Application Program Interface
(GSS-API) standard. GSS-API is an IETF-proposed standard
API (RFC 1964) that can be used with Kerberos for this
purpose. Single sign-on means interoperability between
non-Windows 2000 clients that support the standard, and
Windows 2000 clients and non-Windows 2000 Kerberos realms
(MIT Kerberos domains).
One caveat: If you choose to integrate previous clients
(NT or Windows 9x), you still need support for LM and
NTLM logon. By default, support for these protocols is
enabled; so to secure a 100-percent Win2K organization,
you must remove this support. To limit use of LM and NTLM,
implement Registry support for NTLMv2. (For more information
on this, see my article, “Top 10 NT Security Fixes” online
in this issue.)
Euripides, and a Dog Named Kerberos
|“Athena and Euripides are
working at neighboring terminals...” Thus
begins a delightful, fictitious account
written a dozen years ago about the design
of Kerberos. In this account, Athena is
tired of sharing a mainframe with others
and wants to develop a system in which
users can access resources across a network
from their PCs. Euripides sees the inherent
insecurity of such an arrangement. Together
they hash out the design of a secure authentication
protocol, which Athena names Kerberos
after her Uncle Hades’ three-headed watchdog.
This story, written by Bill Bryant and
added to by Theodore Ts’o, is a good,
easily understandable introduction to
the Kerberos protocol. To read it, go
to “Designing an Authentication System:
a Dialogue in Four Scenes” at http://web.mit.edu/kerberos/www/dialogue.html.
You’ll also find additional information
on Kerberos at this MIT site.
More Granular File Access Permissions
With NT, you can explicitly deny file or folder access
to any user or group. With Win2K, you can explicitly deny
any permission to a file or folder to any user or group.
That’s right—you can deny full control, or deny read,
or deny write permission. This gives you much more granular
Let’s say Sharon Rollins is a member of both the Accountants
Group and the Managers Group. The Managers Group is given
read and write permissions to a folder; the Accountants
group is given read permission. Without any other entries,
Sharon has read and write access. In NT, giving Sharon
read-only access to a certain file while maintaining read
and write permission for the Managers Group meant you
either had to make a new group, or remove Sharon from
the Managers Group. You could deny her access, but that
wasn’t what you really wanted. With Win2K, you simply
deny Sharon write access to this particular file. She
still maintains any other access granted by each group
to other files and folders, and read access provided by
the Accountants Group.
You also have the choice of stopping inheritance. To
do this, uncheck the “allow inheritable permission from
parent to propagate” box on the “security” tab of the
file or folder properties dialog box when setting permissions.
You can do this for any file or folder. If inheritance
is blocked on subfolders, you can’t destroy their settings
by bulk propagation from higher-level folders. (That closes
a security hole in NT in which the OS could be destroyed
by removing the group Everyone from the root and selecting
“replace permission on subdirectories.”
Tighter Default Registry Settings
Fire up good old regedt32.exe and peek at the security
settings for sensitive keys. You’ll find that many formerly
wide-open areas are more tightly controlled. For example,
the System group is already entered everywhere for you,
with access rights of Full Control. The new thing here
is that it’s actually listed. Remember trying to implement
tighter security in NT? If you forgot to enter the System
and give it Full Control, you were in danger of locking
the OS out of its own files. Win2K prevents that administrative
blunder by entering System controls for you.
Check out a few keys, and you’ll run into a new group
called “Restricted.” This is an implicit group whose membership
is determined by membership in one of the built-in sensitive
groups, such as Administrators, Server Operators, Print
Operators, and Account Operators (you can add your own
groups to the Restricted group as well). Having this identity
can serve to automatically provide security membership,
and thus give or maintain special access to resources.
The Restricted identity can also be leveraged to control
membership in these sensitive groups.
In many cases, Administrators are given full control,
Authenticated Users given read permission, and Server
Operators given special permission. (Server Operators
are not initially given permission to change permissions,
make links, or change ownership.) Creator Owner is given
Full Control, but only at the sub-key level. One of the
keys thus treated is HKLM/SOFTWARE/Microsoft. Other keys
are tightened, giving Server Operators read access only.
Those keys are HKLM/SYSTEM/CurrentControlSet, and both
HKLM/SOFTWARE/Microsoft/Windows/Current Version/Run and
An insidious hole is closed by assigning Creator Owner’s
“Full Control” access to sub-keys only. In Win2K, applications
may create Registry keys and can rightfully control those
keys. Users running these applications can be given rights
to access and modify keys, but this right doesn’t translate
into the ability to create or modify other keys in that
branch. This permission definition can also help control,
at a granular level, exactly what can be done if key ownership
But what about applications that had problems running
in NT because they didn’t have access to needed areas
of the Registry? Applications written to Win2K logo standards
will ensure that users can run the applications they have
the right to run, without compromising security. In truth,
though, legacy applications and applications not written
to standard will continue to have problems; you’ll need
to audit their activities to find out which keys and what
types of access they need. This is the bane of tighter
security—additional work for administrators. Many applications
will require twiddling with Registry and file security
settings to maintain your sanity and security, while still
allowing users access to their applications. To curtail
this, be sure to shop for the Win2K application logo on
new purchases. Developers, check out the specifications
at www.msdn.microsoft.com/winlogo/win2000.asp and write
your applications to conform to them. [See News in this
issue to read about the slow growth of the Windows 2000
product certification program.—Ed.]
Security Configuration Tool Set and Secedit
The Security Configuration Tool Set is implemented in
the Security Configuration and Analysis Snap-In in Win2K.
It’s a collection of tools that lets you analyze, configure,
and maintain anything from the security policy of a local
computer to that of an entire Win2K enterprise. This tool
became available the same time as NT 4.0 Service Pack
4, but was known as the Security Configuration Editor
and could manage only a local computer.
In Win2K, this tool can be used to reduce administrative
costs and ease the burden of maintaining security. Think
about it. Security means constant vigilance. Most of the
time, you’re too busy responding to new requests and fighting
inaccurate or inadequate configuration to give maintenance
the place it deserves. Besides which, don’t you like to
think that once something’s put into place, it shouldn’t
arbitrarily change? Get real. Things don’t arbitrarily
change, but people change them. Maybe there was a temporary
need to give a group special permission or access until
a better solution could be found. Then life intervened,
and no one remembered to reset it. Maybe corporate politics
have placed you in the position of having to deal with
immature or vindictive administrators. And what happens
when there are 10 new servers to put into production without
adequate time to apply a thorough security lockdown?
In Win2K, you can address these problems with the Security
Configuration Tool Set, which has several pre-configured
templates that can be modified to your specifications.
You use Group Policy to apply security settings across
an organizational unit (OU) or a domain. Want to make
sure settings are maintained? Settings applied at this
level override settings made at a lower level. Need to
configure several new computers? No problem, since settings
can be configured to propagate. Are auditors knocking
at your door looking for a way to analyze your compliance
with corporate security policy? No problem. You can easily
ask for an analysis of current settings against any policy
Now the real kicker: Secedit is a command-line tool that
you can use to run these programs in batch mode, or as
a task while you sleep. Take two seconds to make sure
the task is active, then view the results in the morning.
You’ll still have to do an analysis to determine what
the settings should be for your systems and then put them
into place. When first installed, the Windows 2000 default
security settings (known as the local computer policy)
are disappointingly weak. The default length of the password
is zero characters, account lockout policy isn’t set,
and no auditing is turned on. On the upside, some new
user rights and security options give us more granularity
in the interface to lock down the system. Study the available
settings in the local policy, and make your own policy
part of any installation in your site.
for Stiffening Default Win2K Settings
- _ Assign access control rights on
a group basis.
- _ Rely on inheritance from group
- _ Apply rights to propagate through
the container tree.
- _ Delegate container administration
to administrators of the computers
where the containers reside—that is,
decentralize administrative operations
- _ Set Auditing On, and use the following:
- _ Failure audit for logon/logoff.
- _ Success audit for user and
group management, security change
policy, restart, shutdown, and
- _ Success and failure audit
for file access and object access
for suspect users and sensitive
- _ Failure audit for printers
that print sensitive documents
- _ Success and failure audit
for write access for program files
(.EXE and .DLL).
- _ Train users in the proper use
of EFS. Have them encrypt their My
Documents and temp folders. Encrypt
folders rather than files.
- _ Use the Secedit command line tool
for batch analysis when a large number
of computers needs to be configured
- _ Use the Security Configuration
Tool Set with Group Policy to implement
security settings at the domain or
site level, not at the local computer
- _ Create personal databases into
which you import security templates
- _ Test predefined templates before
applying them to production systems.
- _ Make the size of the security
event log large, and don’t allow event
log wrapping. Archive frequently so
as not to miss events.
- _ Track system services used on
a computer, and set unnecessary or
unused services to manual start.
- _ Enforce password history, remembering
the last 12 passwords.
- _ Use a maximum password age of
- _ Set minimum password age to 30
- _ Set minimum password length to
- _ Set “Passwords must meet complexity
- _ Set “Store passwords using reversible
encryption for all users in the domain.”
- _ Set Account lockout policy.
- _ After trust development, set additional
restrictions for anonymous connections
to a minimum of “Do not allow enumeration
of SAM accounts and shares” and maximum
of “No access without explicit anonymous
- _ Enable “Automatically log off
users when logon time expires.”
- _ Enable “Clear virtual memory pagefile
when system shuts down.”
- _ Enable “Do not display last user
name in logon screen.”
- _ Create a logon banner.
- _ Configure LAN manager authentication
level: minimum =”Send LM &NTLM,
use NTLMv2 session security if negotiated.”
Group Policy Editor
You use Group Policies in Win2K to define a user’s desktop,
and the Group Policy Editor to create Group Policies.
It’s similar to using the Systems Policy Editor in NT.
However, Group Policies aren’t primarily applied to groups
of users. Instead, they’re applied to affect Active Directory
objects such as the Site, Domain, or Organization. That
lets you use Group Policies to control such things as
programs available to users; programs that appear on a
desktop; application settings; Start menu options; restrictions
to files, folders, and Registry keys; rights granted to
users and groups; when and what scripts run; and account
policy settings. Group Policy, then, provides a single
place for configuring, analyzing, and maintaining security
for a Win2K enterprise. Group Policy Settings override
settings made at the local computer level.
When you install a Win2K system, it’s configured with
default security settings. You can view them by accessing
“Local Security Policy” from the Administrative Tools
menu. This opens the “secpol” Microsoft Management Console
(MMC) snap-in, which displays security settings for this
machine. You can view settings on Account Policies, Local
Policies (Audit policy, User Rights Assignments, and Security
Options), Public Key Policies, and IP Security Policies.
You can gain additional information by examining file
and folder settings, and security on Registry keys. If
you join the system to a domain that has a policy configured
for it, the local security policy will propagate to this
It’s important to note that “override” does not mean
all settings at the lower level are overwritten. Settings
not explicitly set in the Active Directory will take on
the settings from the local computer policy. I’ll address
this in more detail in an upcoming article.
IPSec is an enterprise standard for secure communication
over IP. It can be used to create a virtual private network
(VPN) with branch offices or trusted business partners
by tunneling across the Internet. It can also be used
to secure network communications between two users, or
between a user and an application interface. After it’s
configured, IPSec acts like an upside-down firewall. Whereas
a firewall filters external access to your internal network
or individual computer, IPSec filters packets leaving
your network or individual computer. You can establish
conversations between computers or security gateways (routers,
firewalls) with a high degree of granularity. A policy
database records the settings, and every packet is reviewed
before it leaves the system. If a filter is found, it’s
applied. If there’s no filter, the packet is dropped.
Here’s how IPSec works:
- Fred Smith wants secure communication over the network
with Peter Jones.
- Fred uses an IPSec-enabled application to send a
message to Peter. (Note that most inter-process communication
mechanisms will work with IPsec transparently to the
application itself, so no special application is needed
- The driver on Fred’s computer checks the IP filter
list (policy database) for an address or traffic-type
match, and finds one.
- The driver starts security negotiations with Peter’s
- The computers do a secret key exchange, create a
secure connection, and create a session key. More security
negotiations ensue to determine the correct level of
- Packets leaving Fred’s computer are signed by the
IPSec driver (to maintain integrity), and may be encrypted
for confidentiality if desired.
- When they arrive at Peter’s computer, they’re checked
for integrity and decrypted if necessary.
Fred and Peter are unaware of, and do not participate
in, any of this. The policy establishing this activity
has been pre-configured for them. Any routers between
their computers don’t have to be configured for IPSec.
(However, if any of these routers are acting as a firewall,
they need to be configured to allow IPSec traffic to pass
IPSec comes with Windows 2000, but you’ll need to plan
and configure an IPSec policy before it can be used. (This
is typically done after installation, unless you create
installation scripts to do it for you.) You don’t have
to install the protocol since it’s part of the new TCP/IP
stack, but it isn’t used unless you configure it—no simple
Built-in Smart Card Integration Services
Smart cards are credit card-sized hardware devices that
add an additional layer of security to Win2K systems.
They provide additional support for software implementations
used for logon, authentication, and secure email. Used
as a part of a public key infrastructure (PKI), they can
provide tamper-resistant storage for private keys and
other pieces of personal information. Security-critical
computations are isolated from other parts of the system.
Credentials can be made portable. Win2K supports the Personal
Computer/Smart Card specifications developed for the PC/SC
Workgroup (www.pcscworkgroup.com). Based on ISO 7816 standards,
these standards are compatible with the Europay, MasterCard,
and VISA (EMV) specifications, and with the European telecommunications
Global System for Mobile Communications (GSM) spec.
To use smart cards with Win2K, you must install a smart
card reader device and use a vendor-supplied installation
Windows File Protection
Ever been to DLL hell? Sure you have—that’s where an
application installs a newer version of a DLL when an
existing app needs that older DLL to work. It’s an unintentional
denial of service (DoS) attack. If it’s this easy to replace
DLLs, what about the system DLLs? Yep, I can see you’ve
been there, too. Win2K, however, has two new features
that will help prevent DLL hell.
First, DLLs for applications designed for Win2K will
all use side-by-side DLLs. This means vendors should be
writing applications to allow the use of different copies
of DLLs for their new versions of products instead of
writing new versions of Windows DLLs. (For more information,
refer to Microsoft’s list of Win2K application logo standards.
Second, Microsoft has implemented Windows File Protection
(WFP) in Windows 2000. This means that all .SYS, .DLL,
.EXE, and .OCX files, along with some fonts that are part
of the system itself, can’t be replaced except through
a special file replacement mechanism controlled by Microsoft.
That means that vendor applications (or viruses, or Trojans,
or malicious mavericks) won’t be able to replace system
files. Ever. When the system detects an application trying
to change a system file, Win2K will change it right back.
The only (supported) way to replace system files will
be using Microsoft service packs and hot fixes. This makes
for a more stable OS, and one that is less vulnerable
to this type of attack.
Virus protection programs need to be aware of this function,
as well as any backup or restore applications.
Built-in Public Key Infrastructure
Win2K provides the pieces to establish a Public Key Infrastructure,
but you’ll have to configure them yourself. Why would
you want to?
Perhaps it’s overkill to obsess about the dangers posed
by internal users of your networked systems, but what
about that Internet access you give them? Do you have
trading partners that you work with? What will prevent
unauthorized access to monitoring or altering email, electronic
commerce transactions, and file transfers? Do you supply
your users with multiple passwords because they must access
multiple systems? Perhaps you can’t implement single sign-on
in your networks just yet. But in the multiple-password
world, be aware that users typically choose less secure
passwords because they’re easier to remember.
As a systems administrator, network administrator, manager,
auditor, or concerned user, how can you be sure of the
identity of anyone accessing your systems? Can you be
sure you’re controlling what information they have access
to? How can identification credentials (user ID, password,
etc.) be securely distributed across an organization and
with trading partners? Kerberos will solve some of these
issues, such as authentication, but you might also need
a public key infrastructure. This so-called PKI feature
is a major security enhancement in Win2K.
A public key infrastructure (PKI) includes digital certificates,
certificate authorities (CAs), and other components that
authenticate and verify legitimate access using public
key cryptography. (See my column on cryptography, “Keeping
Your Secrets Secret,” in the October 1999 issue for more
In a public key infrastructure, you issue certificates
rather than passwords. Certificates bind a public key
to the identity of a person who holds the corresponding
private key. With Win2K, you can take advantage of Certificate
Services integration with the Active Directory and Group
Data and files can be securely exchanged over public
networks such as the Internet. Secure email can be implemented
with Secure Multipurpose Internet Mail Extensions (S/MIME),
and secure Web connections can be made using Transport
Layer Security (TLS). Non-repudiation can be established
whereby the author of digitally-signed data can’t deny
being the author, whether it’s the person placing the
e-commerce order or the merchant receiving the information
for that online order.
Win2K uses a standard X.509v3 digital certificate. Certificate
Services are used to create and manage Certificate Authorities,
which are responsible for establishing and verifying the
identity of certificate holders. The CA also revokes certificates
and publishes a certification revocation list (CRL). Win2K
also sets up Web enrollment pages when a CA is created.
These Web pages allow certificate requestors to submit
certificate requests via a Web browser. Certificates can
be used for authentication and authorization and are used
with smart cards and to identify recovery agents in the
encrypting file system (see “Understanding the Encrypting
You can find additional information on Certificate Services
at www.microsoft.com/security and www.microsoft.com/windows2000/
Miscellaneous Security Features
Along with the biggies like Kerberos, PKI, and Group
Policy Editor are a host of smaller security features,
many of which are installed right out of the box. Here’s
a sampling of what you’ll get.
Unprivileged User Account Privileges
Applications that install or require user accounts to
run a service will no longer have the same rights as the
regular user accounts you and I log on with. These service
accounts, called unprivileged user accounts, will have
fewer privileges on the system than user accounts. Thus,
while they can be used by the service, it will be harder
to use them to attack the system. For example, this type
of account can’t write to any part of the systems directory.
If service accounts are given additional rights, or are
members of groups other than Users, these rights aren’t
No More NetBIOS!
Well, almost. The default configuration for Win2K will
include NetBIOS, but unlike NT, it will be possible to
set up your system so that NetBIOS isn’t loaded or present.
Hurrah! You’ve just eliminated the source for many attacks
and scans on your system information. Applications that
try to use NetBIOS on a system where it’s no longer present
will return errors.
Write-Protected Kernel Mode
Many existing device drivers are written improperly for
NT. They override the protections on write-protected regions
of memory and can cause NT to crash. To respect these
areas of memory, drivers written specifically for Win2K
will be required. Device drivers that are correctly written
can be certified; their code will be signed by Microsoft
and provided through Microsoft channels. You can configure
Windows 2000 to accept only signed device drivers, to
warn you that an unsigned driver is trying to load, or
to accept any device driver. Any OEM device driver provided
by Microsoft will be an approved driver, for example.
Configure your policy to accept only signed drivers, and
you can help protect your system from corruption.
the Encrypting File System
|The ease with which you
can use EFS during installation belies
its usefulness. Simply right-click on
the file or folder that you want to encrypt
and click Properties. From the General
tab, click Advanced, then select the “Encrypt
contents to secure data” check box. Presto!
Now your data’s secure! This new feature
of NTFS v5 allows encryption of files
and folders. Encrypt at the folder level
to encrypt all folders in the file and
to ensure all new files added to the folder
are encrypted. Encrypt the Temp folder
if using programs that add temporary files.
No files are encrypted by default, but
the feature is. By the way, it isn’t necessary
for users to apply passwords separately
to files. And use of the system is transparent
to the user.
Proper use of the encrypting file system
can keep files safe, but there are some
rules to learn:
- Files can become unencrypted if
copied or moved to FAT volumes.
- Files created in encrypted folders
will be encrypted automatically.
- Use Edit/Copy and Edit/Paste to
retain encryption when moving encrypted
files into encrypted folders. Don’t
use drag-and-drop, as files aren’t
automatically encrypted that way.
- Compressed files can’t be encrypted.
- Users can’t share encrypted files.
- Encryption doesn’t protect against
deletion. If users have the right
to delete files in a folder, they
can delete files encrypted by other
- Temporary files created by applications
will be encrypted only if they’re
created in an encrypted folder. To
maintain encryption, encrypt the Temp
- Users can encrypt or decrypt folders
and files on a remote computer if
it has been configured for remote
- Data transferred over the network
isn’t encrypted during the transfer—you
must use an encryption protocol, such
as SSL/PCT or IPSec.
Tighter Default File and Program Access
A clean installation of the new OS onto an NTFS partition
creates file system permissions designed to prevent users
from compromising the integrity of the operating system
and installed applications. Users can’t modify settings
on operating system files or program files, and can only
install applications that can be run by themselves (if
they’re provided access to the file system) and not by
other users. Win2K Professional “Power Users” may install
applications for use by others (this eliminates the need
for an administrator to do so, or for us to give users
administrative privileges on a machine just for this purpose.)
A Power User’s default settings are backward-compatible
with NT 4.0 user settings. Power Users can install any
application that doesn’t install system services.
Some files will be marked with System and Hidden attributes
and won’t be visible in Windows Explorer even if the option
“Show Hidden Files” is checked. These files can, of course,
be used, and an attribute on the folder can be checked
to make them visible—but it must be checked on every folder
that might have hidden files in it. This feature should
be useful in keeping users away from certain system files.
And Now, for Our Next Act...
Win2K ships with a variety of security services. Although
I’ve outlined some suggestions, you’ll still need to make
choices about which ones to implement in your enterprise.
I’m afraid you’ll still have to work hard to establish
security in your Win2K enterprise. Remember, if you don’t
know what you need to secure, or how tightly, all these
new gee-gaws don’t mean much. Yes, Virginia, you still
need to design a security structure, then put Win2K security
services to work for you. The beauty is this: It’s now
the design that’s difficult, not the implementation, maintenance,