OLC is a company created by the Indiana Bureau of Motor Vehicles to provide a new service to licensed drivers. This new service provides drivers the opportunity to renew licenses and license plates over the Internet. OLC is an extension of the Indiana Bureau of Motor Vehicles and therefore shares the bureau's records database.

The pressure from a newly elected "high-tech" governor to provide these services caused the OLC development team to rush delivery of the system. In doing so, it did not implement adequate security and has recommended to OLC that the bureau implement new security features.

The system was developed using Active Server Pages (ASP) and Dynamic HTML (DHTML), which work together to provide user interface functionality, and an ODBC connection to the state's UNIX-based Informix database. The entire Web system runs on a Windows NT 4.0 platform and uses a TCP/IP connection (via ODBC) to the database.

OLC would like to move the Windows NT 4.0 platform to Windows 2000 to take advantage of several security enhancements. Because internal OLC employees need to connect to the Informix database to query for new records, they must log on to the UNIX environment with different usernames and passwords. OLC would like to provide single sign-on services to its employees.

Although measures were taken to make the code in the system secure, none were taken to secure the Web site or any data transmissions. OLC would like to provide authentic and secure connections for licensed drivers as they utilize the online services. Additionally, data connections and transmissions within the OLC offices must be secured at all times to prevent any possibility of eavesdropping.

Performance is not too much of a concern in the OLC environment. New state-of-the-art servers and networking backbone are in place and working at optimal efficiency.

Since a team of developers wrote all code internally, OLC can easily maintain the system itself. All code must be checked in and out using Visual Source Safe, and standard code maintenance procedures are in place.”

The Internet is driving organizations to open up and interact with vendors, partners, and customers using new and often unproven technologies. To remain competitive, corporations quite often end up trading a well-thought-out security plan for just simply getting a server on the Internet to do eCommerce, a risk that could end up costing quite a bit more than the amount of profit the Internet can generate.

This drastic change in business is what causes some to expose too much of the wrong information to the wrong people. To implement a solid security plan, a security implementer must always be of the mindset that a hacker is out there, looming, waiting to break in and steal vital confidential documents. Companies such as OLC that are under pressure to deliver that new product or service swiftly often underestimate the value of security.

Disgruntled employees are dangerous. They know the environment and the people within it, and could cause harm without the proper precautions in place. Take, for example, the case of Iva Bincanned, a network administrator who has been with a company for a number of years. She developed relationships with other employees and was generally liked among her peers. When she was given a pink slip due to downsizing, she became very angry and wanted revenge. Because she was an administrator, it was easy for her to create a backdoor account she could use to access the network. When the other network administrators deleted her account, they did not delete her backdoor account. Iva dialed up the night she was let go, logged right onto the system, and proceeded to delete everything she had access to. She had given that account domain admin permissions.

Cases similar to Iva's happen every day. That's why security is so critical. Could this have been prevented? Probably.

The NTLM authentication protocol exists in Windows 2000 for the primary purpose of authentication with previous versions of Windows. NTLM is the core authentication protocol for Windows NT 3.5x and 4.0. You should determine whether you're going to carry on with support for NTLM, because you do have the opportunity to remove it from a Windows 2000 environment. When deciding whether to keep NTLM around, use Table 7.1 as a roadmap.

Figure 7.1 graphically represents the NTLM authentication process.

Figure 7.1. The NTLM authentication process is based on security access tokens granted by the domain controller each time access to a resource is needed.

Kerberos is the default Windows 2000 authentication protocol. An entire book could be written about it. This section, as long as it may be, is really just a detailed overview of the protocol's implementation. We'll cover features of Kerberos throughout this chapter and, by its end, you should have a good understanding at where it fits within the security and authentication architecture of Windows 2000, as well as how it provides authentication services outside Windows 2000.

MIT Kerberos version 5 replaces NTLM as the default authentication protocol for Windows 2000. Kerberos is an industry-standard protocol that is supported by a wide variety of platforms. The Kerberos protocol defines the interactions between clients and its authentication service, the Key Distribution Center (KDC). The KDC uses Active Directory as its accounts database. The benefits of using Kerberos are as follows:

The name Kerberos comes from the Greek mythological figure "Cerberos," a fierce, three-headed dog that guarded the gates of the underworld. The three heads of Cerberos map to the three pieces of Kerberos: client, server, and trusted intermediary (the KDC).

Session Tickets

The data structure used to return the session key to the client is called a session ticket. The session ticket is comprised of the client's copy of the session key encrypted with the secret key that the KDC shares with the client. The server's copy of the session key is embedded, along with information about the client, in the session ticket. The entire session ticket is then encrypted with the key that the KDC shares with the server. This session ticket is then cached on the client workstation and may be used to directly authenticate with the server until it expires.

To continue the example, when Lea wants to talk to Rex now, she sends a request to the trusted authority, the KDC, which returns her a session ticket. Upon receipt, Lea extracts her copy of the session key and stores it in volatile cache (when Lea goes to sleep, she forgets everything!). To talk to Rex, she sends him the session ticket (which is still encrypted with the server's secret key), and an authenticator, which is encrypted with the session key. The ticket and authenticator together become Lea's qualifying credentials in talking to Rex.

When Rex receives a request to talk from someone claiming to be Lea, he decrypts the session ticket using his secret key. Once decrypted, he extracts the session key and uses it to decrypt Lea's authenticator. Rex will know that the request to talk came from who the sender is claiming to be if he is able to decrypt everything successfully. If so, he and Lea establish a connection and begin their conversation. Figure 7.2 describes this entire process.

Figure 7.2. The initial Kerberos authentication process.

The beauty of using session tickets is that the server has absolutely no responsibility in terms of remembering session tickets. It is totally on the client to retain the session ticket in its cache until the ticket expires. Another benefit is that session tickets are reusable, so every subsequent time a user needs to communicate with a server, it can use the cached copy of the session ticket for that server, as shown in Figure 7.3.

Note

SSPI . The Security Support Provider Interface defines Windows security APIs for network authentication.

Kerberos Integration

Kerberos is fully integrated with the Windows 2000 security architecture for authentication and access control. WinLogon, the initial Windows domain logon service, uses the Kerberos security provider to obtain an initial Kerberos ticket. Other services, such as the redirector, use the Windows 2000 Security Support Provider Interface (SSPI) when they need to connect to the Kerberos security provider.

Figure 7.3. Once a session ticket has been issued, subsequent connections to the server only require the client to present its session ticket for that server.

Warning

Authorization Data . Keep in mind that authorization data is application service specific and does not support user authorization in heterogeneous environments.

Kerberos v5 contains an encrypted field for applications to use for authorization data in the session ticket. Windows 2000 uses the authorization data to carry SIDs for user and group membership. The server-side Kerberos security provider uses this authorization data to build security access tokens, which represent the user on the system. It can then use this data to impersonate the client before attempting to access local resources protected by ACLs.

Two additional fields, implemented as Boolean flags, are used in the delegation of authentication features supported by Kerberos. The proxy and forwarding fields in session tickets can be set to allow servers to obtain session tickets for other servers on behalf of the client.

In the Field: It's All in the Name of Security

One very good example of where you would benefit from the delegation of authentication (forwarding) feature of Microsoft's implementation of Kerberos is with a two-tier, Web-enabled email access package.

Consider the scenario in which back-end mail servers for an organization are inside the firewall and front-end Web-based email access servers (such as Outlook Web access) are on a secure DMZ. A client may securely log on to Active Directory using the X.509 certificate PKI extensions of Kerberos by connecting to the front-end Web servers. These servers then may forward the user's request to log on to a domain controller. Once authenticated, the user would then be able to access email.

Exactly how this process works is covered in the Kerberos reference material at the end of this chapter, but you can see easily that a main benefit is that the front-end server can be configured to perform delegated tasks for only specific clients—a very powerful security implementation.

Single Sign-On with Kerberos

A huge benefit to having an industry standard protocol as the core for authentication and security is the ability to step outside the Windows 2000 platform by creating trust relationships with other platforms. Operating platforms that support the MIT Kerberos v5 protocol are illustrated in Figure 7.4.

Figure 7.4. Microsoft's vision of providing SSO with other platforms.

Establishing the cross-platform trust with Kerberos is relatively easy, provided all the pieces are in place on both sides. The administrator creates a trust relationship between the Windows 2000 KDC and the other platform's KDC, which are in different realms. The Kerberos tickets are provided via cross-realm referrals. The Windows 2000 administrator simply sets up user accounts with rights and permissions for the incoming users to use, and that's it.

One downfall to SSO with Kerberos in a heterogeneous environment is the management of the connection. Some of the things that are managed in the background under Windows 2000 need to be manually handled in this environment. For example, when a trust is established in a heterogeneous environment, the administrator must manually synchronize keys between Active Directory and the other platform's KDC. Additionally, the administrator loses the single set of administration tools and a single repository for SSO information.

The final core authentication protocol is Secure Sockets Layer/ Transport Layer Security (SSL/TLS). Windows 2000 uses SSL/TLS and X.509 certificates to provide mutual authentication, message integrity, and confidentiality. The Windows 2000 implementation of SSL/TLS supports logon through the use of smart cards, and is used to protect connections on unsecured networks.

Public key cryptography refers to the use of two keys: a public key designed to be shared, and a private key, which must be guarded. These keys complement each other, meaning that if you encrypt something with your public key, it can only be decrypted with the corresponding private key. This works both ways. Either way, the goal of public key cryptography—the ability to obscure data in such a way that it can only be interpreted by the intended party—is achieved.

Another component of PKI includes digital signing. This task is a way to prove the origin of a piece of data. This does not provide privacy of data.

Public key cryptography provides three core capabilities that are important to businesses. These three capabilities are highlighted using some potential business cases in Table 7.2.

Public keys are packaged as digital certificates, which contain a public key and a set of attributes, such as the keyholder's name. These attributes are relative to the keyholder and define the keyholder's identity, what he's allowed to do, and where the certificate is valid. This binding is appropriate because the certificate is digitally signed by the issuing CA to validate its authenticity.

A good analogy when discussing certificates is a standard credit card. Your Visa card contains a unique key in the form of the credit card number. It contains attributes, such as your name and the card's expiration date, and maybe even your picture. A trusted authority issues it, and its authenticity is sealed in the magnetized strip (assuming it cannot be tampered with). Anyone who trusts the issuing bank will allow you to use the card. Of course, how companies determine whether to accept or reject your credit card is where this analogy needs a bit of help.

Certificate authorities are a hierarchical grouping of public key certificate servers that are responsible for signing digital certificates they issue. This hierarchy can go as deep as needed, although there always will be a finite top level, known as the root. Figure 7.5 presents a certificate authority hierarchy.

The important thing about certificate authorities is that each certificate issued by a CA must be digitally signed and certified by the next higher level of CA. So (referring Figure 7.5) if you had a certificate issued by an entity certificate authority, it would have to be signed by the intermediate certificate authority, which would have to be signed by the root CA.

Figure 7.5. The certificate authority hierarchy may go as many levels deep as needed, but will always have a single root.

Windows 2000 provides two types of CAs: Enterprise and Standalone, which are discussed in the following sections.

There are five components that make up a complete PKI. These five components are responsible for creating, validating, transporting, and using the digital certificates that PKI depends on. These components are as follows:

The Windows 2000 implementation of PKI builds on Microsoft's already robust PKI components. The foundation is built on interoperability, security, flexibility, and ease of use. The primary components of the Windows PKI are as follows:

Standards bodies, such as the World Wide Web Consortium (W3C), the Internet Engineering Task Force (IETF), and the International Telecommunication Union (ITU) have been working hard with vested interest in promoting the interoperability between multi-vendor implementations of PKI. Microsoft has worked, and continues to work, alongside these impartial bodies to ensure the correct and fully interoperable implementation of the Windows PKI.

Table 7.3 lists the standards, definitions, and justification supported by the Windows 2000 implementation of PKI.

The Windows 2000 implementation of PKI inherits the security features built into Windows 2000. This is made possible because the major PKI components are part of the core OS. Because they rely on widely available, open Internet standards, PKI components reap the benefit of years of experience and maturity. Computer security and cryptography experts, who took significant input from computer, banking, financial, legal, and government experts, developed the security standards listed in Table 7.3. The end result is a rock-solid security infrastructure that meets the demands of real-world needs. Microsoft has been very careful to use mature security and encryption algorithms that have stood the test of time and prolonged public use. Table 7.4 lists Windows 2000's support for cryptographic algorithms.

Because Windows 2000 offers an open security architecture, it integrates well with third-party PKIs. It is important to remember, however, that because of its integration with the OS, the Windows 2000 PKI provides the best, most seamless integration with Active Directory, native security protocols, and other security services.

Because Windows 2000 supports the creation of automatic two-way transitive Kerberos trusts between a child domain and its parent domain within a domain tree, the security and management tasks are greatly reduced in this area. With Windows NT 4.0, administrators not only had to manually create the trust and secure it with a password, but also had to manage two distinctly different SAM databases full of user credentials and, in most cases, had to synchronize user accounts and passwords with both domains. With Kerberos authentication under Windows 2000, a user can authenticate across domain boundaries to anywhere within the domain tree or forest without administrative intervention and, most importantly, without needing an account setup on the other domain.

Active Directory does support the creation of one-way manual "explicit" trust relationships. These types of trusts are still required for interoperability with down-level Windows NT domains and with other operating platforms. An explicit trust is required in our case study to integrate the UNIX and Windows 2000 operating systems. Figure 7.6 illustrates Windows 2000 trust relationships.

Figure 7.6. Windows trust relationships now can take two forms—automatic Kerberos trusts or one-way, manual, Windows NT-style trusts. In addition, the existence of UNIX may require an explicit two-way Kerberos trust.

A highly touted new feature of Windows 2000 and Active Directory is the ability to delegate administrative authority. This process allows administrators to deputize special users or other administrators with granular and specific administrative duties. Granting the technology contact from a business unit the ability to reset passwords for a subset of users in that business unit would be a good example of delegated administration. This person would have no additional administrative powers—just the ability to reset passwords for a specific set of users. Imagine what you could do with this! In Windows NT, the only way to delegate any administrative authority was to give the person or persons requesting authority too much by sticking them in the Domain Admins group (or other built-in group), or to flat-out create another trusted domain. Windows 2000 has fixed that problem and then some by incorporating the Delegation of Administrative Control Wizard. We'll discuss delegation in much more detail in Chapter 12, "Designing an OU and Group Policy Management Structure."

How many times have you as an administrator needed to allow a contractor the right to temporarily create user accounts, or perform some other administrative function, in your Windows NT domain? If you've ever been in that situation, you realized one of Windows NT's downfalls: no granular control. In the case of creating user accounts, it was literally an all-or-nothing Domain Admin role. Not a good position to be in when that contractor you trusted with the Domain Admin permission burns you by doing something stupid!

Windows 2000 incorporates an incredibly fine-grained access rights model. This model allows administrators to grant or deny access rights on the ACL of an object at the following levels:

By default, when an object is created in Active Directory, the creator of the object is granted uniform read/write access to all properties of the object.

Container objects also provide granular access with respect to who has permission to create child objects. For example, you can define who in the organization can create child objects, such as other containers or user and printer objects. This is a fabulous method of keeping Active Directory clean, because you can allow delegates to create only what they need.

Inheritance of access rights defines how access control defined at higher-level "parent" containers of the directory flows down to "child" containers and then to "leaf" objects. Generally speaking, there are two models for implementing inheritance: dynamic and static.

Because you have such a high degree of flexibility in securing Active Directory, you should take great care in designing a security standard.

As with Windows NT, you should always assign permissions to groups rather than users. The administration of user-level permission assignments, especially in a large corporate environment with several administrators, is cumbersome and simply not a good practice.

In addition to using groups to assign permissions, you should also set a standard for where you assign them. For example, don't make it a practice to assign permissions at the property level. As with user-level permissions, property-level permission assignments can make for an extremely difficult environment to keep a good handle on. You should consider assigning inheritable permissions at the domain level to enforce global security standards, and at the OU level to enforce decentralized security needs. Of course, where you choose to standardize your inheritable permissions will reign heavily on your administrative needs.

Be careful with the Deny permission. It works the same way the No Access permission works in the NTFS file system. A viable use of this permission is to deny a user in a group access to a particular object without removing the user from a group.

Keep a close eye on the users in the organization who have Domain Admin or Enterprise Admin permissions. Only a select group of individuals should have this type of access. Periodically, do a permissions audit to uncover any forgotten permissions assignments.

As with any NOS, change the Domain Admins group members' passwords frequently, and make them difficult to crack.

IPsec stores its policy information in Active Directory. An IPsec policy consists of rules, filters, and negotiation policies that are retrieved from Active Directory when a system starts. IPsec is disabled by default, so to begin using it, you'll either have to create your own policy or choose from one of the three predefined policies:

All of the predefined policies are designed for computers that are members of a secure Windows 2000 domain. They may be assigned as is without further action, modified, or used as a template for defining custom IPsec policies.

In our case study, OLC requires secure data transmissions internally. They have the option of using the predefined Secure Server IPsec policy, or customizing their own. Whatever they choose, they must require encryption on all data transmissions.

Similar to the predefined policies, the default response rule for an IPsec policy is provided without need for modification. It may be activated without further action or customized to fit specific needs. It is automatically added to each new IPsec policy you create, but not automatically activated. The purpose of the default rule is to prepare any computers that do not require security to respond appropriately when another computer requests secure communications.

Similar to the predefined rules, predefined filter actions are provided for activation without any need of modification. Like the policies and rules, the filters can be modified to fit specific needs, or used as a template to create additional customized filter actions.

Security policy defines a security configuration file that is stored as part of a Group Policy Object. You create these files using the Security Configuration Toolset. You can configure several types of security configuration files using the security configuration editor:

These policies can work together to form policies with a large and generalized scope, such as a domain-wide policy, or they can be saved as security configuration files with a specific purpose, such as defining a different minimum password length for a subset of users. These security files may then be attached to OUs as Group Policy Objects.

There are three places—local machine, domain, and OU—where policies can be applied, which means they must carry some sort of priority ranking when being applied since a computer may exist in a domain under an OU. The order of precedence for applying security policy is as follows:

Local policy, which is defined on the computer itself, carries the least precedence. The domain policy sits in the middle, and the OU policy carries the most weight. The domain policy is applied to all computers in a given domain and then any specific OU policies are applied for computers that exist in OUs with defined policies. The net effect of all this is if there are conflicting policies, the domain policy overrides the local machine policy, and the OU policy overrides the domain policy. Figure 7.7 shows a GPO being created for an OU.

Figure 7.7. Group Policy Object being created for an Organizational Unit.

It is important to note here that unlike previous versions of Windows NT, Windows 2000 domain policy actually filters down to the workstation level. For example, in Windows NT 4.0 when you had a domain policy that forced the domain password to 15 characters, it was applied only to domain controllers (primary and backup). In Windows 2000, the same domain-wide password policy also applies to your workstations and member servers local accounts database.

It is no secret that Windows NT system policies were cumbersome to create, implement, and manage. Microsoft has done a superb job in re-engineering policies and integrating them with the core OS in Windows 2000. Do not let the name "Group Policy" fool you. These policies really have nothing to do with groups, other than when you implement them, you typically "group" similar computers or users together in an OU and apply a Group Policy Object to it.

One of the key fundamental differences between NT system policies and Windows 2000 Group Policy is in the way they are applied. With Windows NT System Policies, an administrator uses the System Policy Editor in policy file mode to create an NTCONFIG.POL file and must save it the \SERVERPDC netlogon share. The policy is not applied until the user logs on.

In Windows 2000, Group Policy has one mode that is somewhat of a cross between Policy File mode and Registry mode. Modifications made to a GPO are saved immediately to that GPO, but the change is not immediately implemented on the target machines. Instead, GPOs are refreshed automatically at given intervals during a process called policy propagation. Policy propagation is triggered by the target computer every 5 minutes for domain controllers, and every 60–90 minutes for member servers and workstations. The net benefit of this is in administration. Administrators have only one place to configure policy and one mode to configure policy in. The rest "just happens."

During the initial configuration of Active Directory, the domain security GPO is created and attached to the domain object. The domain security policy is just that: a policy that is applied by default to all computers within a domain. The domain security file describes the following three security policy group settings:

Step by Step 7.1 will assist you in opening the default domain security policy. You must be logged onto your Windows 2000 domain as an administrator for this to work.

Expand the Account Policy item and then click on one of the three settings to view the default domain security configuration. Figure 7.8 illustrates the domain security policy.

Figure 7.8. Windows 2000 domain security policy window containing the domain password policy configuration settings.

By default, all Active Directory domain controllers are added to the Domain Controllers OU. The domain controller security policy defines the security policy common to all domain controllers in that OU. The default domain controllers security policy is created when the first Active Directory domain controller joins the network. It can be opened in much the same way the default domain GPO can, the only difference being that instead of selecting properties from the domain object, you select properties from the domain controllers OU. Refer to Step by Step 7.1 and make the aforementioned replacement to view the default domain controller GPO.

The most significant settings made in the default domain controller GPO are the user rights assignments. User rights were moved out of the User Manager for Domains (in Windows NT 4.0) and into policy-based administration (in Windows 2000). Audit policy and security options policy are also defined in the default domain controllers GPO. This policy is applied with higher precedence than the default domain policy. Figure 7.9 shows the domain controller security policy settings.

Figure 7.9. Windows 2000 domain controller security policy illustrating the default domain controller user rights settings.

The account policies security area is unique in terms of how it takes place on computers in the domain. All domain controllers receive their account policies from GPOs configured at the domain node, no matter where the domain controllers computer object lies in Active Directory. This is to ensure consistency across the domain for all domain accounts.

As far as workstations and member servers in the domain go, they follow the normal GPO hierarchy with account policy. Remember that Windows 2000 propagates the account policy down to the workstation level, so even the (Windows 2000 Professional) workstations local accounts database adheres to the domain policy.

Some questions you may end up seeing on the exam are questions relating to defining a security policy. Security policies must address the following:

A security policy includes guidelines and standards whose purpose is to eliminate security breaches that can lead to certain kinds of attacks and threats. Our case study in this chapter is a good example of a company in need of a security policy. OLC provides a great service, but without the proper security in place, the company could be heading for disaster. One thing is for certain; it is extremely difficult to cover all bases of security and implement a completely secure system without trading off some sort of functionality. For this reason, most companies, when forming a security policy, define what security means to them. This could be totally different from what it means to the next company. A security policy will address the following types of questions:

Of course, this is not an exhaustive list, but should get you thinking along the right lines.