Security

This section discusses Microsoft® Windows® Server 2003 family security; how you can ensure that data access, storage, and exchange complies with your security needs.

This section covers:
  • New features in security
  • New ways to do familiar tasks
  • Best practices for security
  • Security overview
  • Authentication
  • Access Control
  • Authorization Manager
  • Security Configuration Manager
  • Software Restriction Policies
  • Auditing Security Events
  • Encrypting File System
  • Public Key Infrastructure
  • Internet Protocol security (IPSec)
  • Windows Time Service
  • Resources
  • Troubleshooting


New features in security

New features | More information
Authorization Manager. Authorization Manager gives application developers a flexible framework for integrating role-based access control into their applications, and it lets administrators who use those applications provide access in a natural, intuitive way: through assigned user roles relating to job function. | Authorization manager
Stored user names and passwords. This utility provides secure storage for user names and credentials that are needed to access network or Internet resources. | Stored user names and passwords
Software restriction policies. This new security policy enables administrators to prevent software applications from running based on a hash algorithm of the software, the software's associated file path, the software publisher's certificate, or the Internet zone that hosts the software. | Software restriction policies
Changes to existing technologies |
Certification authoritities. Numerous improvements and added features are included for certification authorities. | New features in Certificate Services
Constrained delegation. With this new security feature, you can specify what services you want to trust for delegation for a server. | Delegating authentication
Effective permissions tool. This tool calculates the permissions that are granted to a specified user or group. | Effective permissions
Encrypting File System (EFS) no longer requires a recovery agent. | Encrypting File System
Everyone membership. The built-in Everyone group includes Authenticated Users and Guests, but no longer includes members of the Anonymous group. | Differences in default security settings
Operation-based auditing. Operation based auditing offers more descriptive auditing events and provides you with the opportunity to choose what operations you want to audit when auditing object accesses. | Operation-based auditing on files or folders
Reapplying security defaults. This procedure enables you to easily reapply the default security settings for the Windows Server 2003 family. | To reapply default security settings


New ways to do familiar tasks

The following table lists common tasks for managing domain security. For most tasks, the user interface is different in Windows Server 2003 family than in Windows NT 4.0.

Note

  • XOX
If you want to | In Windows NT 4.0, use | In this version of Windows, use
Edit user rights for domain groups and users that apply to domain controllers | User Manager for Domains | Active Directory Users and Computers. For more information, see To define a security template.
Edit account policies for users in a domain | User Manager for Domains | Active Directory Users and Computers. For more information, see To define a security template.
Edit audit policies for groups and users that apply to domain controllers or specific computers | User Manager for Domains | Active Directory Users and Computers. For more information, see To define or modify auditing settings for an event category.
Establish domain trust relationships | User Manager for Domains | Active Directory Domains and Trusts.
Promote member server to a domain controller | Not available | Active Directory Installation Wizard
Assign permissions to files, folders, and registry keys | Appropriate object manager and Properties page | Appropriate object manager and Properties page. For more information, see the How to page for Access Control.
Audit security events | User Manager for Domains | Appropriate object manager and Properties page. For more information, see To apply or modify auditing settings for a local file or folder.
View security log | Event Viewer | Event Viewer. For more information, see To view the security log.
Create users and groups | User Manager for Domains | Active Directory Users and Computers. For more information, see To add a user account and To add a group.
Manage a Windows NT 4.0 domain | User Manager for Domains | User Manager for Domains


Best practices

Restrict physical access to computers, especially domain controllers, to trusted personnel

  • Physical access to a server is a high security risk. Physical access to a server by an intruder could result in unauthorized data access or modification as well as installation of hardware or software designed to circumvent security. To maintain a secure environment, you must restrict physical access to all servers and network hardware.

For administrative tasks, use the principle of least privilege

  • Using the principle of least privilege, Administrators should use an account with restrictive permissions to perform routine, nonadministrative tasks and use an account with broader permissions only when performing specific administrative tasks.
  • To accomplish this without logging off and back on, log on with a regular user account and use the Runas command to run the tools that require the broader permissions.

    • For more information, see To run a program with administrative credentials and Runas.

Define groups and their membership

  • When deciding on the default level of computer access that end users will have, the determining factor is the installed base of applications that need to be supported. If your organization uses only applications that belong to the Windows Logo for Software Program, then you can make all your end users members of the Users group. If not, you may have to make your end users part of the Power Users group or relax the Users group's permissions security settings. Both are less secure options.

    • Running legacy programs on Windows 2000 or XOX often requires you to modify access to certain system settings. The same default permissions that allow Power Users to run legacy programs also make it possible for a Power User to gain additional privileges on the system, even complete administrative control. Therefore, it is important to deploy Windows 2000 or XOX programs in the Windows Logo Program for Software in order to achieve maximum security without sacrificing program functionality.

    For more information, see the Windows Logo Program for Software page at the Microsoft Web site. (http://www.microsoft.com/)

  • All domain administrators (including child domain administrators) who can modify the system software on domain controllers in a forest must be equally trusted.
  • Domain administrators and enterprise administrators should be the only users allowed to link a Group Policy object to an organizational unit. This is the default setting.

    Authenticated users only need Read and Apply Group Policy object permissions.

Secure data on computers

  • Ensure that the system files and the registry are protected using strong access control lists.

    For more information, see Access Control.

  • Use Syskey to provide additional protection of the security account manager (SAM), especially on your domain controllers.

    • For more information, see the system key utility.

Use strong passwords throughout your organization

  • Most authentication methods require the user to provide a password to prove their identity. These passwords are normally chosen by the user, who may want a simple password that is easily remembered. In most cases, these passwords are weak and may be easily guessed or determined by an intruder. Weak passwords can circumvent this security element and become the weak point of an otherwise strong security environment. Strong passwords tend to be more difficult for an intruder to discern and, as a result, help provide an effective defense of your organization’s resources.

    • For more information, see Strong passwords.

Do not download or run programs that come from untrusted sources

  • Programs can contain instructions to violate security in a number of ways including data theft, denial of service and data destruction. These malicious programs often masquerade as legitimate software and can be difficult to identify. To avoid these programs, you should only download and run software that is guaranteed authentic and obtained from a trusted source. You should also ensure a current virus scanner is installed and functioning in case this type of software does inadvertently wind up on your computer.

Keep virus scanners up to date

  • Virus scanners frequently identify infected files by scanning for a signature, which is a known component of a previously identified virus. The scanners keep these virus signatures in a signature file, which is usually stored on the local hard disk. Because new viruses are discovered frequently, this file should also be updated frequently for the virus scanner to easily identify all current viruses.

Keep all software patches up to date

  • Software patches provide solutions to known security issues. Check software provider Web sites periodically to see if there are new patches available for software used in your organization.

    • For more information and for the latest recommendations on security, see Security .

In order to subscribe to the Product Security Notification Service, see "Product Security Notification" at the Microsoft Web site (http://www.microsoft.com/)

For more information, see:

  • Best practices for access control
  • Best practices for auditing
  • Best practices for Encrypting File System
  • Best practices for Software Restriction Policies
  • Best practices for Certificate Services
  • Best practices for Certificate Templates

For more information on creating and maintaining security policy, see:

  • Best practices for security configuration and analysis
  • Best practices for security templates
  • Best practices for applying security through Group Policy


Security overview

The primary features of the Microsoft® Windows® Server 2003 family security model are user authentication and access control. The Active Directory® directory service ensures that administrators can manage these features easily and efficiently. The following sections describe these features of the security model.

Authentication

  • Interactive logon confirms the user's identification to the user's local computer or Active Directory account.

  • Network authentication confirms the user's identification to any network service that the user is attempting to access. To provide this type of authentication, the security system includes these authentication mechanisms: Kerberos V5, public key certificates, Secure Sockets Layer/Transport Layer Security (SSL/TLS), Digest, and NTLM (for compatibility with Windows NT® 4.0 systems).

    Single sign-on makes it possible for users to access resources over the network without having to repeatedly supply their credentials. For the Windows Server 2003 family, users need to only authenticate once to access network resources; subsequent authentication is transparent to the user.

Authentication in the Windows Server 2003 family also includes two-factor authentication, such as smart cards. For more information, see Smart Cards.

For more information, see Authentication protocols overview.

Object-based access control

Along with user authentication, administrators are allowed to control access to resources or objects on the network. To do this, administrators assign security descriptors to objects that are stored in Active Directory. A security descriptor lists the users and groups that are granted access to an object and the specific permissions assigned to those users and groups. A security descriptor also specifies the various access events to be audited for an object. Examples of objects include files, printers, and services. By managing properties on objects, administrators can set permissions, assign ownership, and monitor user access.

Not only can administrators control access to a specific object, they can also control access to a specific attribute of that object. For example, through proper configuration of an object's security descriptor, a user could be allowed to access a subset of information, such as employees' names and phone numbers but not their home addresses. For more information, see Access control.

For more information, see "Authorization and access control" at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)

Security policy

You can control security on your local computer or on multiple computers by controlling password policies, account lockout policies, Kerberos policies, auditing policies, user rights, and other policies. To create a systemwide policy, you can use security templates, apply templates using Security Configuration and Analysis or edit policies on the local computer, organizational unit, or domain. For more information, see Security Configuration Manager.

Auditing

Monitoring the creation or modification of objects gives you a way to track potential security problems, helps to ensure user accountability, and provides evidence in the event of a security breach. For more information, see Auditing.

Active Directory and security

Active Directory provides protected storage of user account and group information by using access control on objects and user credentials. Because Active Directory stores not only user credentials but also access control information, users who log on to the network obtain both authentication and authorization to access system resources. For example, when a user logs on to the network, the security system authenticates the user with information stored in Active Directory. Then, when the user attempts to access a service on the network, the system checks the properties defined in the discretionary access control list (DACL) for that service.

Because Active Directory allows administrators to create group accounts, administrators can manage system security more efficiently. For example, by adjusting a file's properties, an administrator can permit all users in a group to read that file. In this way, access to objects in Active Directory is based on group membership.

Data protection

Stored data (online or offline) can be protected using:

  • Encrypting File System (EFS). EFS uses public key encryption to encrypt local NTFS data. For more information, see Storing data securely.
  • Digital signatures. Digital signatures sign software components, ensuring their validity. For more information, see Digital signatures.

Network data protection

Network data within your site (local network and subnets) is secured by the authentication protocol. For an additional level of security, you can also choose to encrypt network data within a site. Using Internet Protocol security, you can encrypt all network communication for specific clients, or for all clients in a domain.

Network data passing in and out of your site (across intranets, extranets, or an Internet gateway) can be secured using the following utilities:

  • Internet Protocol Security (IPSec). A suite of cryptography-based protection services and security protocols.
  • Routing and Remote Access. Configures remote access protocols and routing. For more information, see Routing overview.
  • Internet Authentication Service (IAS). Provides security and authentication for dial-in users. For more information, see Internet Authentication Service (IAS).

Public key infrastructure

Public key encryption is an important aspect of security. For more information, see Public key infrastructure.

Trusts

The Windows Server 2003 family supports domain trusts and forest trusts.

Domain trust allows a user to authenticate to resources in another domain. For more information on establishing and managing domain trust relationships, see Trust direction.

In a Windows Server 2003 forest, administrators can create a forest to extend two-way transitivity beyond the scope of a single forest to a second Windows Server 2003 forest. For more information, see Forest trusts.

For more information about authorization and access control, see "Domain Trust" at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)


Authentication

  • Authentication Protocols
  • Smart Cards
  • Stored User Names and Passwords
  • Passwords


Authentication protocols

This section covers the authentication protocols.

  • For help with specific tasks, see How To.
  • For general background information, see Concepts.


How to...

  • Configure Kerberos policy
  • Allow a computer to be trusted for delegation for specific services
  • Allow a user to be trusted for delegation for specific services
  • Allow a computer to be trusted for delegation
  • Allow a user to be trusted for delegation
  • Map an account from a trusted non-Windows kerberos realm to a user account


Configure Kerberos policy

Microsoft Windows Graphic

To configure Kerberos policy

  1. Open Active Directory Users and Computers.
  2. In the console tree, right-click the domain or organizational unit for which you want to set Group Policy.
  3. Click Properties, and then click the Group Policy tab.
  4. Do one of the following:
    • To edit an existing Group Policy object (GPO), in Group Policy Object Links, click the GPO that you want to edit, then click Edit.
    • To create a new GPO, click New, type the name of the new GPO, and then click Edit.
  5. In the console tree, click Kerberos Policy.

    Where?

    • Computer Configuration
    • Windows Settings
    • Security Settings
    • Account Policies
    • Kerberos Policy
  6. In the details pane, double-click the Kerberos policy you want to modify.
  7. Modify the policy, and then click OK.

Notes

  • XOX
  • XOX
  • Any modifications to Kerberos policy will affect all the computers in the domain.
  • The Kerberos policies in the Windows Server 2003 family refer to the ticket-granting ticket as a user ticket.

Related Topics


Allow a computer to be trusted for delegation for specific services

Microsoft Windows Graphic

To allow a computer to be trusted for delegation for specific services

  1. Open Active Directory Users and Computers.
  2. In the console tree, click Computers.

    Where?

    • DomainName
    • Computers
  3. In the details pane, right-click the computer you want to trust for delegation and then click Properties.
  4. On the Delegation tab, click Trust this computer for delegation to specified services only.
  5. Do one of the following:
    • Confirm that Use Kerberos only is selected.
    • Click Use any authentication protocol.
  6. Click Add and, in Add Services, click Users and Computers.
  7. In Enter the object names to select (examples), type the name of the user or computer that the computer will be trusted to delegate for, and then click OK.
  8. In Add Services, click the service or services that will be trusted for delegation and click OK. Repeat this step as necessary.

Notes

  • XOX
  • XOX
  • If you cannot see the Delegation tab, do one or both of the following:
    • Register a Service Principal Name (SPN) for the computer account using the Setspn utility in the support tools that are on your CD. Delegation is only intended to be used by service accounts, which should have registered SPNs, as opposed to a regular user account which typically does not have SPNs.
    • Raise the functional level of your domain to Windows Server 2003. For more information, see Related Topics.
  • Constrained delegation, delegation of authentication for only specified services, can only be enabled on a member of the Windows Server 2003 family.

Related Topics


Allow a user to be trusted for delegation for specific services

Microsoft Windows Graphic

To allow a user to be trusted for delegation for specific services

  1. Open Active Directory Users and Computers.
  2. In the console tree, click Users.
  3. Right-click the user you want to be trusted for delegation, and click Properties.
  4. Click the Delegation tab and click Trust this user for delegation to specified services only.
  5. Select Use Kerberos only (default) or select Use any authentication protocol, where the initial client-to-server authentication protocol can be any protocol supported by the Windows Server 2003 local security authority. Typically, this could be NTLM, SSL client certificate mapping or Digest.
  6. Click Add and, in Add Services click Users and Computers.
  7. In Select Users or Computers, enter the name of the user or computer that the user will be trusted to delegate for.
  8. In Add Services, select the service or services that will be trusted for delegation and click OK. Repeat as necessary.

Notes

  • XOX
  • XOX
  • If you cannot see the Delegation tab, do one or both of the following:
    • Register a Service Principal Name (SPN) for the user account with the Setspn utility in the support tools on your CD. Delegation is only intended to be used by service accounts, which should have registered SPNs, as opposed to a regular user account which typically does not have SPNs.
    • Raise the functional level of your domain to Windows Server 2003. For more information, see Related Topics.
  • Constrained delegation, which is trusting a computer for delegation of specified services, can only be enabled for a computer in a Windows Server 2003 domain.

Related Topics


Allow a computer to be trusted for delegation

Microsoft Windows Graphic

To allow a computer to be trusted for delegation

  1. Open Active Directory Users and Computers.
  2. In the console tree, click Computers.

    Where?

    • DomainName
    • Computers
  3. In the details pane, right-click the computer you want to be trusted for delegation, and click Properties.
  4. Do one of the following.
    • If in a Windows Server 2003 domain, on the Delegation tab, click Trust this computer for delegation to any service (Kerberos only), and then click OK.
    • If in a Windows 2000 native domain, click the General tab, click Trust this computer for delegation, and then click OK.

Notes

  • XOX
  • XOX
  • If you cannot see the Delegation tab, do one or both of the following:
    • Register a Service Principal Name (SPN) for the computer account using the Setspn utility in the support tools that are on your CD. Delegation is only intended to be used by service accounts, which should have registered SPNs, as opposed to a regular user account, which typically does not have SPNs.
    • Raise the functional level of your domain to Windows Server 2003. For more information, see Related Topics.
  • For security reasons, do not allow servers on the enterprise network to perform delegation at will on behalf of any network connection.

Related Topics


Allow a user to be trusted for delegation

Microsoft Windows Graphic

To allow a user to be trusted for delegation

In a Windows Server 2003 domain

  1. Open Active Directory Users and Computers.
  2. In the console tree, click Users.

    Where?

    • DomainName
    • Users
  3. In the details pane, right-click the user you want to be trusted for delegation, and click Properties.
  4. Click the Delegation tab, select the Account is trusted for delegation check box, and then click OK.

Note

  • If you cannot see the Delegation tab, do one or both of the following:
    • Register a Service Principal Name (SPN) for the user account with the Setspn utility in the support tools on your CD. Delegation is only intended to be used by service accounts, which should have registered SPNs, as opposed to a regular user account which typically does not have SPNs.
    • Raise the functional level of your domain to Windows Server 2003. For more information, see Related Topics.

In a Windows 2000 native domain

  1. Open Active Directory Users and Computers.
  2. In the console tree, click Users.
  3. In the details pane, right-click the user you want to be trusted for delegation, and click Properties.
  4. Click the Accounts tab, select the Account is trusted for delegation check box, and then click OK.

Notes

  • XOX
  • XOX
  • For security reasons, do not allow servers on the enterprise network to perform delegation at will on behalf of any network connection.

Related Topics


Map accounts from trusted non-Windows kerberos realms to a user account

Microsoft Windows Graphic

To map an account from a trusted non-Windows kerberos realm to a user account

  1. Open Active Directory Users and Computers.
  2. On the View menu, click Advanced Features.
  3. In the console tree, click Users.

    Where?

    • Active Directory User and Computers
    • Domain Name
    • Users
  4. In the details pane, right-click the user account to which you want to map a certificate, and then click Name Mappings.
  5. On the Kerberos Names tab, click Add.

Notes

  • XOX
  • XOX

Related Topics


Concepts

For more information on authentication protocols, see the following:

  • Authentication overview
  • Introduction to authentication
  • Kerberos V5 authentication
  • Enabling Kerberos V5 authentication
  • Delegating authentication
  • Interoperability with RFC-1510 Kerberos implementations
  • Secure Sockets Layer/Transport Layer Security authentication
  • NTLM authentication
  • Passport authentication


Authentication

Microsoft Windows graphic

Authentication protocols overview

Authentication is a fundamental aspect of system security. It confirms the identity of any user trying to log on to a domain or access network resources. Windows Server 2003 family authentication enables single sign-on to all network resources. With single sign-on, a user can log on to the domain once, using a single password or smart card, and authenticate to any computer in the domain.

Authentication types

When attempting to authenticate a user, several industry-standard types of authentication may be used, depending on a variety of factors. The following table lists the types of authentication that the Windows Server 2003 family supports.

Authentication protocols | Description
Kerberos V5 authentication | A protocol that is used with either a password or a smart card for interactive logon. It is also the default method of network authentication for services.
Secure Sockets Layer/Transport Layer Security (SSL/TLS) authentication | A protocol that is used when a user attempts to access a secure Web server.
NTLM authentication | A protocol that is used when either the client or server uses a previous version of Windows.
Digest authentication | Digest authentication transmits credentials across the network as an MD5 hash or message digest. For more information, see "Digest Authentication" in the Internet Information Services Documentation.
Passport authentication | Passport authentication is a user-authentication service which offers single sign-in service.For more information, see "Passport authentication" in the Internet Information Services documentation.

For more information on authentication types, see "Logon and Authentication" at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)


Introduction to authentication

A key feature of authentication in the Windows Server 2003 family is its support of single sign-on. Single sign-on allows a user to log on to the domain once, using a single password, and authenticate to any computer in the domain.

Single sign-on provides two main security benefits:

  • For a user, the use of a single password or smart card reduces confusion and improves work efficiency.
  • For administrators, the amount of administrative support required for domain users is reduced, because the administrator only needs to manage one account per user.

Authentication, including single sign-on, is implemented as a two-part process: interactive logon and network authentication. Successful user authentication depends on both of these processes.

Interactive logon

Interactive logon confirms the user's identification to either a domain account or a local computer. This process is different, depending on the type of user account:

  • With a domain account, a user logs on to the network with a password or smart card, using single sign-on credentials stored in the Active Directory directory service. By logging in with a domain account, an authorized user can access resources in the domain and any trusting domains. If a password is used to log on to a domain account, Kerberos V5 is used for authentication. If a smart card is used instead, Kerberos V5 authentication is used with certificates.
  • With a local computer account, a user logs on to a local computer, using credentials stored in Security Account Manager (SAM), which is the local security account database. Any workstation or member server can store local user accounts, but those accounts can only be used for access to that local computer.

Network authentication

Network authentication confirms the user's identification to any network service that the user is attempting to access. To provide this type of authentication, the security system supports many different authentication mechanisms, including Kerberos V5, Secure Socket Layer/Transport Layer Security (SSL/TLS), and, for compatibility with Windows NT 4.0, NTLM.

Users who use a domain account do not see network authentication. Users who use a local computer account must provide credentials (such as a user name and password) every time they access a network resource. By using the domain account, the user has credentials that can be used for single sign-on.

For more information about authentication, see "Logon and Authentication" at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)


Kerberos V5 authentication

Kerberos V5 is the primary security protocol for authentication within a domain. The Kerberos V5 protocol verifies both the identity of the user and network services. This dual verification is also known as mutual authentication.

An overview of how Kerberos V5 works

The Kerberos V5 authentication mechanism issues tickets for accessing network services. These tickets contain encrypted data, including an encrypted password, that confirms the user's identity to the requested service. Except for entering a password or smart card credentials, the entire authentication process is invisible to the user.

An important service within Kerberos V5 is the Key Distribution Center (KDC). The KDC runs on each domain controller as part of the Active Directory directory service, which stores all client passwords and other account information.

The Kerberos V5 authentication process works as follows:

  1. The user on a client system, using a password or a smart card, authenticates to the KDC.
  2. The KDC issues a special ticket-granting ticket to the client. The client system uses this TGT to access the ticket-granting service (TGS), which is part of the Kerberos V5 authentication mechanism on the domain controller.
  3. The TGS then issues a service ticket to the client.
  4. The client presents this service ticket to the requested network service. The service ticket proves both the user's identity to the service and the service's identity to the user.

The Kerberos V5 services are installed on each domain controller, and a Kerberos client is installed on each workstation and server.

Every domain controller acts as a KDC. A client uses a Domain Name Service (DNS) lookup to locate the nearest available domain controller. That domain controller then functions as the preferred KDC for that user during the user's logon session. If the preferred KDC becomes unavailable, the system locates an alternate KDC to provide authentication.

For more information on how Kerberos V5 provides authentication, see the XOX Resource Kit.

For more information about Kerberos, see "Logon and Authentication" at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)


Enabling Kerberos V5 authentication

The Kerberos V5 authentication protocol is enabled by default for all computers joined to a Windows Server 2003 or Windows 2000 domain during installation. Kerberos provides single sign-on to resources within a domain, and to resources residing in trusted domains.

You can control certain aspects of Kerberos configuration through Kerberos security settings which are part of the account policies. For example, you can set the lifetime of users' Kerberos V5 tickets. As an administrator, you can use the default kerberos policy or you can change it to suit the needs of your environment.

Successful authentication using Kerberos V5 requires that both the client system must run the Windows 2000, Windows Server 2003 family, or XOX operating system.

If a client system tries to authenticate to a server running another operating system, the NTLM protocol will be used as the authentication mechanism.

Note

  • Computers using Kerberos for authentication must have their time settings synchronized with a common time service within five minutes or authentication fails. Computers running members of the Windows Server 2003 family, XOX, or Windows 2000 automatically update the current time, using the domain controller as a network time service.

For more information about configuring Kerberos policy, see Kerberos policy and Account policies.

For more information about Kerberos, see "Logon and Authentication" at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)


Delegating authentication

Delegation is the act of allowing a service to impersonate a user account or computer account in order to access resources throughout the network. When a service is trusted for delegation, that service can impersonate a user to use other network services.

For more information about delegation, see "Designing an Authentication Strategy" at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)

To set up delegation on a computer, the following conditions must be met:

  • The account doing the delegation must be set to Trusted for delegation to any service or Trusted for delegation to specified services only.
  • The account that the service is delegating for must not have the Account is sensitive and cannot be delegated option chosen.
  • An administrator must have the Enable computer and user accounts to be trusted for delegation privilege on the computer in order to enable delegation.

For more information about how to allow users or computers to be trusted for delegation, see How To.

Differences in Windows Server 2003 family delegation

Windows 2000 | Members of the Windows Server 2003 family
Delegation requires the Kerberos authentication protocol. | Delegation can be used when the client authenticates to the service using protocols other then Kerberos because of a new feature of the Windows Server 2003 family, Protocol Transition.
The Key Distribution Center (KDC) embeds a copy of the user's ticket-granting ticket (TGT) inside the service ticket that is sent to the server. With this TGT, the server that has been trusted for delegation can request service tickets for the user to any other service on the network. | A ticket-granting ticket (TGT) is not needed. With protocol transition, a service can use a service ticket for delegation.
Delegation allows the server to connect to any resource in the domain on behalf of the client. | An administrator can specify which Service Principal Names (SPNs) an account is able to delegate to with constrained delegation.

Constrained delegation

Constrained delegation is a new option and can only be used on members of the Windows Server 2003 family. With this option, the administrator can specify which Service Principal Names (SPNs) an account is able to delegate to. A service can be trusted for delegation, but that trust can be limited to a select group of services explicitly specified by a domain administrator.

In a Windows Server 2003 domain, there are three options to consider in trusting a computer for delegation:

  • Do not trust this computer for delegation. This option was available in Windows 2000 and is the default setting for members of the Windows Server 2003 family.
  • Trust this computer for delegation to any service (Kerberos only). This option was available in Windows 2000. This setting is only as secure as the service and the actions of all its administrators. When this option is selected on a computer, all services under the Local System account on the computer will be trusted for delegation. This means an administrator on that computer may install any service and then that service will have the ability to access any network resource by impersonating a user.
  • Trust this computer for delegation to specified services only. This is a new feature for the Windows Server 2003 family, and it is commonly referred to as constrained delegation. With constrained delegation, the administrator can specify which Service Principal Names (SPNs) this account is able to delegate to. If an application requires delegation for best functionality, this is the most secure option. Delegation for specified services allows an administrator to choose what services on the network can be delegated to by choosing a specific service or computer account. By only allowing delegation to specific services, an administrator can control what network resources the service or computer can use.

For more information on functional levels, see Understanding domain and forest functionality.

For information on about configuring constrained delegation, see

  • To allow a computer to be trusted for delegation for specific services
  • To allow a user to be trusted for delegation for specific services

For information on about configuring delegation, see

  • To allow a computer to be trusted for delegation
  • To allow a user to be trusted for delegation


Interoperability with RFC-1510 Kerberos implementations

Kerberos V5 is designed for interoperability with other security services that are based on the RFC-1510 Kerberos reference implementation.

Windows Server 2003 family supports two types of Kerberos V5 interoperability:

  • A trust relationship can be established between a domain and an MIT-based Kerberos realm. This means that a client in a Kerberos realm can authenticate to an Active Directory directory service domain to access network resources in that domain.
  • Within a domain, UNIX clients and servers can have Active Directory accounts and therefore obtain authentication from a domain controller.

Kerberos V5 interoperates with other RFC-1510 implementations of the Kerberos protocol in the following ways:

  • A domain controller can provide authentication for client systems running implementations of RFC-1510 Kerberos, including clients running an operating system other than XOX or Windows 2000.
  • XOX systems can authenticate to a Kerberos V5 server within a realm, with single sign-on to both the server and a local XOX account.
  • Client applications for Win32 and operating systems other than XOX that are based on the General Security Service Application Program Interface (GSS API) can obtain session tickets for services within a domain.

For more information, see the Step-by-Step Guide to Kerberos 5 (krb5 1.0) Interoperability on the Microsoft Web site (http://www.microsoft.com/) and the Kerberos Network Authentication Service (V5).

Note

  • XOX


SSL/TLS authentication

For conceptual information about certificates and Secure Socket Layer (SSL) connections and authentication, see the Internet Information Services (IIS) 6.0 documentation.

With Secure Socket Layer/Transport Layer Security (SSL/TLS), you have the ability to control what ciphers are allowed. By default, all ciphers can be used; however, you can control what ciphers your computer can use. For more information, see article Q216482, "How to Control the Ciphers for SSL and TLS," in the Microsoft Knowledge Base (http://www.microsoft.com/).

For instructions on how to map certificates to user accounts in Internet Information Services (IIS), see "Mapping Client Certificates to User Accounts" in the Internet Information Services (IIS) 6.0 documentation.

Note

  • You must have IIS installed to have access to the documentation.


NTLM authentication

In a networking environment, NTLM is used as the authentication protocol for transactions between two computers where one or both computers are running Windows NT 4.0 or earlier. Networks with this configuration are referred to as mixed-mode, the default setting in the Windows Server 2003 family.

As examples, the following configurations would use NTLM as the authentication mechanism:

  • A Windows 2000 or XOX client authenticating to a Windows NT 4.0 domain controller.
  • A Windows NT 4.0 Workstation client authenticating to a Windows 2000 or Windows Server 2003 domain controller.
  • A Windows NT 4.0 Workstation client authenticating to a Windows NT 4.0 domain controller.
  • Users in a Windows NT 4.0 domain authenticating to a Windows 2000 or a domain running Windows Server 2003 family.

In addition, NTLM is the authentication protocol for computers that are not participating in a domain, such as stand-alone servers and workgroups.

For more information about NTLM and NTLMv2, see "Logon and Authentication" at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)


Passport authentication

Passport authentication is a centralized service provided by Microsoft that offers single logon and core profile services for member Web sites. This benefits Web site users by making it unnecessary to log on again to access additional protected resources or Web sites. You can make your business Web site compatible with Passport authentication and authorization by using the Passport authentication provider.

The Microsoft .NET Passport Home Web page provides information for:

  • Consumers, who want to manage their .NET Passports and change their passwords.
  • Businesses, which can license and use .NET Passport on their Web sites.
For more information, see the Microsoft .NET Passport Home Web page at the Microsoft Web site.(http://www.passport.com/)

Web site administrators can use the Microsoft Passport Manager Administration utility to change registry settings that affect the default behavior of the Passport Manager object. For information about the Passport Manager Administration utility, see the MSDN Web site (http://msdn.microsoft.com/). For information about the Microsoft .NET Passport Software Development Kit, see the MSDN Web site (http://msdn.microsoft.com/).

Note

  • To start the Passport Manager Administration utility, click Start, click Run, type msppcnfg.exe, and then click OK.


Security Configuration Manager

The Security Configuration Manager tool set allows you to create, apply and edit the security for your local computer, organizational unit, or domain.

  • Before configuring security, see Checklist: Securing computers using Security Configuration Manager.
  • For tips about using Security Configuration Manager, see Best practices for Security Configuration and Analysis, Best practices for Security Templates, and Best practices for Security Settings.
  • For help with specific tasks, see How to.
  • For general background information, see Concepts.
  • For problem-solving instructions, see Troubleshooting.
Security Configuration Manager tool | Description
Security Templates | Defines a security policy in a template. These templates can be applied to Group Policy or to your local computer.
Security Settings extension to Group Policy | Edits individual security settings on a domain, site, or organizational unit.
Local Security Policy | Edits individual security settings on your local computer.
Secedit commands | Automates security configuration tasks at a command prompt.


Best practices

  • Best practices for Security Configuration and Analysis
  • Best practices for Security Templates
  • Best practices for Security Settings


How to...

  • Analyze and configure security
  • Modify local security policy
  • Modify security settings


Analyze and configure security

  • Add Security Configuration and Analysis to an MMC console
  • Add Security Templates to an MMC console
  • Analyze system security
  • Configure local computer security
  • Import a security template to a Group Policy object
  • Import a security template
  • Export a security template
  • Edit the analysis database
  • Customize a predefined security template
  • Define a security template
  • Set a new security template path


Modify local security policy

  • Edit local security settings
  • Apply a security template to local policy
  • Assign user rights for your local computer
  • Reapply default security settings


Modify security settings

  • Edit security settings on a Group Policy object
  • Permit users to log on locally to a domain controller


Permit users to log on locally to a domain controller

Microsoft Windows graphic

To permit users to log on locally to a domain controller

  1. Open Domain Controller Security Policy.
  2. In the console tree, click User Rights Assignment.

    3. Where?

    • GroupPolicyObjectName [DomainControllerName] Policy
    • Computer Configuration
    • Windows Settings
    • Security Settings
    • Local Policies
    • User Rights Assignment
  3. In the details pane, double-click Allow log on locally.
  4. If this security setting has not yet been defined, select the Define these policy settings check box, and click Add User or Group.
  5. In Add user or group, specify the user or group who will be granted permission to log on locally, and then click OK twice.

Notes

  • XOX
  • You can also explicitly deny users or groups the permission to log on locally by configuring the "Deny log on locally" user right. For more information, see Related Topics.
  • Setting changes are applied every five minutes on a domain controller. Every 16 hours, there is a forced refresh on the settings, regardless of any changes.
  • User Rights are defined by default in the Default Domain Controller Group Policy object, which is associated with the Domain Controllers organizational unit. As a result, all domain controllers have the same User Rights policy.

Related Topics


Concepts

This section provides general background information about Security Configuration Manager:

  • Security Configuration Manager overview
  • Understanding Security Configuration Manager
  • Using Security Configuration Manager


Security Configuration Manager overview

  • Security Configuration and Analysis overview
  • Security Templates overview
  • Local Security Policy overview
  • Security settings overview


Understanding Security Configuration Manager

This section covers:

  • Account and local policies
  • Event log security settings
  • Security settings for file system, registry, and system services
  • Local computer security for file system, registry, system services


Using Security Configuration Manager

This section covers:

  • Applying security settings
  • Predefined security templates
  • Importing and exporting security templates
  • Analyzing security and viewing results
  • Resolving security discrepancies
  • Automating security configuration tasks
  • Security Setting descriptions


Public Key Infrastructure

A public key infrastructure, often shortened to PKI, is a system of digital certificates, certification authorities (CAs) and other registration authorities (RAs) that verify and authenticate the validity of each party involved in an electronic transaction through the use of public key cryptography.

  • Certificates
  • Certificate services
  • Certificate Templates


Troubleshooting

  • Securing Data troubleshooting
  • Stored User Names and Passwords troubleshooting
  • Passwords troubleshooting
  • Software Restriction Policies troubleshooting
  • Encrypting File System troubleshooting
  • Certificates troubleshooting
  • Certificate Services troubleshooting
  • Certificate Templates troubleshooting
  • Windows Time Service troubleshooting


How to...

  • Use security templates to secure your computers
  • Configure and analyze your computers
  • Manage security settings
  • Automating security configuration tasks


Using authentication protocols

This section covers:

  • Enabling Kerberos V5 authentication