Chapter 5. Security Services

Article
06/30/2006

Summary of Security Requirements

Rationale

In order for Client/Server applications to provide secure access to resources and security for their interactions, the application must configure and run the client and server portions in the correct security contexts. This provides access to the resources needed in a secure manner and provides a secure communication channel between the client and the server. The proper configuration depends on:

Running the server in the appropriate security context.
Providing connection authentication between the client and the server.
Using standard security credentials and security descriptors to validate access to resources and data.

If a service or service account password is compromised, then the scope of damage that can occur is limited to the capabilities of the account under which the service is running. To minimize such damage, service accounts should run with the least privileges necessary to perform the functions required by the service. Running the server in the appropriate security context also allows the administrator to easily provide desired partitioning of access to resources.

Single Sign-On (SSO) allows enterprise network users to seamlessly access all authorized network resources, on the basis of a single authentication that is performed when they initially access the network. SSO can improve the productivity of network users, reduce the cost of network operations, and improve network security.

Customer benefits

Documenting the services that require more than User-level privileges provides customers with the information necessary to make one of the following choices:

Run the service under a non-Admin context and grant explicit permissions to that service account in order to allow specific features to succeed.
Run the service under an Admin (or Domain Admin) context and accept the inherent security risks.
Deploy a different product that offers similar functionality that can run under a more secure context.

SSO allows users to access all authorized network resources on the basis of a single authentication that is performed when they initially access the network. This results in the following benefits:

Better network security. All SSO methods available under Windows 2000 provide secure authentication and provide a basis for encrypting the user's session with the network resource. Eliminating multiple passwords also reduces a common source of security breaches-users writing down their passwords.
Improved user productivity. Users are no longer required to remember multiple logons, nor are they required to remember multiple passwords in order to access network resources. This is also a benefit to help desk personnel, who need to field fewer requests for forgotten passwords.
Simpler administration. SSO-related tasks are performed transparently as part of normal maintenance, using the same tools that are used for other administrative tasks.
Better administrative control. All SSO-specific information is stored in a single repository, the Active Directory. Because there is a single, authoritative listing of each user's rights and privileges, the administrator can change a user's privileges and know that the results will propagate network wide.
Consolidation of heterogeneous networks. By joining disparate networks, administrative efforts can be consolidated, ensuring that administrative best practices and corporate security policies are being consistently enforced.

Requirements

Document services that require more than user-level privileges to run
Win32 clients running in the context of a trusted domain account must support Single Sign-On.

References

Single Sign-On in Windows 2000 Networks
www.microsoft.com/security/Resources/SSOWhite.asp

Additional Windows 2000 Security white papers
www.microsoft.com/windows2000/library/

How to Comply with Security Requirements

1. Document Services That Require More Than User-Level Privileges To Run

Services execute in the context of a "service account." If a service or service account password is compromised, then the scope of damage that can occur is proportional to the capabilities of the account under which the service is running. Therefore, service accounts should run with the least privileges necessary to perform the functions required by the service.

For each service account that requires more than User-level privileges, the following must be documented:

The specific system resources that normal Users do not have sufficient access to by default.
The specific User Rights that normal Users do not have by default in order for the service to run properly.

The minimum permissions to the resources identified in #1 that the service account must have in order to run properly.

For example:

Service	Resource or User Right	Minimum resource permission required by service
Fax	%systemroot%	Write (This Directory, subdirectories and files)
Mail	HKLM\Software\CompanyA\Mail	Write (This directory, subdirectories and files)
Backup	Backup and Restore Privilege	N/A
Software Distribution	Admin Shares	Read\Write
Web Server	HTTP Service	Stop\Start
Disk Manager	NTFS Volumes	Open Handle for Modify

Note Some applications may unjustifiably require elevated privileges for a service. Consider the first three hypothetical examples in the above table.

Fax Service-Assume that the Fax Service is using the %systemroot% directory to store incoming faxes. While it is true that administrative-level privileges are needed to write to %systemroot%, there is no justifiable reason for the fax service to use this directory as a storage location in the first place. If the faxes were stored in a non-system location, the service may not require administrative-level privileges in order to run.

Mail-Assume that the Mail service only needs to retrieve some configuration parameters from the HKLM\Software\CompanyA\Mail key. In this case, it does not need to open the key for write access and therefore requiring write access to this key is unjustified.

Backup-Assume that the Backup Service runs under an administrative context because administrators have the backup and restore privilege by default. This is not justified because the Backup and Restore privilege could be explicitly granted to a non-admin account. The Backup Service could then run under the non-admin account and accomplish its tasks without inheriting all of the other permissions that are given to administrators by default.

Note The Certification program does not require any specific default service account setting, nor does it evaluate the appropriateness of using elevated privileges. You must document your need for elevated privileges to provide customers with the information necessary to make one of the following choices:

Run the service under a non-Admin context and grant explicit permissions to that service account in order to allow specific features to succeed.
Run the service under an Admin (or Domain Admin) context and accept the inherent security risks.
Deploy a different product that offers similar functionality that can run under a more secure context.

2. Win32 Clients Running in the Context of a Trusted Domain Account Must Support Single Sign-On

Win32 clients must correctly support Single Sign-On, which means that when a user is logged on in the context of an account in a trusted domain:

The client does not prompt for logon credentials.
The client uses the credentials the user logged on with.
The Windows 2000 server application authenticates the client as that user.

Note It is acceptable (and sometimes desirable) to support logon with alternate credentials as needed, provided the client also supports Single Sign-On. For example, the Net Use command supports a "/u:" option to allow use of alternate credentials when authenticating to a remote file server. Additionally, the Windows shell supports a "Run As..." option to start a process in a different logon context.

Implementation Details

You can implement Single Sign-On by using any Windows networking protocols that support integrated authentication, such as RPC, Distributed Component Object Model (DCOM), and named pipes.

If you are using named pipes, you will automatically pass this requirement.
Using RPC calls (RpcBindingSetAuthInfo and RpcServerRegisterAuthInfo), you can set a particular authentication provider. The Security Support Provider Interface (SSPI) supports multiple providers-NTLM, Kerberos, SSL, etc. Any of these providers can be used for Single Sign-On. We recommend you use:
```
RPC_C_AUTHN_GSS_NEGOTIATE (for automatically negotiating Kerberos or NTLM) or
RPC_C_AUTHN_GSS_SCHANNEL (for Public key authentication).
```
DCOM provides options similar to RPC (CoInitializeSecurity). See Windows SDK for details.

If you do not use any of these protocols, then you should use the Security Support Provider Interface (SSPI) on top of your application protocol. See the Security section in the Windows SDK for details.

Best practice

While not required for Certification, it is recommended that the server impersonate the client's security context to access objects and resources outside the server's immediate control (such as other local files and the registry) when performing operations on behalf of the client. This ensures that the proper security context is used to validate the operation. However, if the server implements its own access control model for server-private data, then client impersonation is not needed, but the authenticated user identity should be used to determine access permissions. It is recommended that server applications leverage the Windows 2000 access control model by storing permissions in security descriptors using Win32 Private Object Security APIs and checking them using Win32 Access Check APIs.

Client impersonation by the server is implemented using the access token in the negotiated security context. In order to accomplish this, the server calls ImpersonateSecurityContext passing the handle of the client security context. When this call returns successfully, the server thread that made the call has assumed the identity of the client. Access to system resources or data or to data or resources maintained by the server can be validated against standard Windows 2000 Security Descriptors.

When the server wishes to return to using its own security context, then it should call RevertSecurityContext. For example:

  // Server impersonates the client using the security context that was
// created during the mutual authentication.
ImpersonateSecurityContext (pContextHandle);      

// Server gets the Windows 2000 standard security descriptor for its 
// private object using a server routine. The object is stored and 
// manipulated by server-specific routines, but the Security Descriptor 
// associated with the data is the Windows 2000 standard format.
MyStatus = GetObjectSD(Object,…,&SD);

// Obtain client's token. Since we are impersonating the client, the token 
// returned is the client access token.
Status = OpenThreadToken(…,&Token);

// Perform Access Check using the Windows 2000 standard access check API. 
// Since the SD on the private object is Windows 200 standard Security 
// Descriptor, the Windows API can make the access check.
Status = AccessCheck( SD, Token, DesiredAccess, GenericMapping,
             &PrivsUsed, &PrivLength, &GrantedAccess,
             &Allowed);
// Act as per the result
if (Allowed) {
}

How to Pretest Applications for Security Support

To Test If Your Server Runs in the Correct User Context

Clean-Install Windows 2000 Server onto an NTFS partition joining a domain as necessary
Log in as an Administrator
Install the application
If the service account created/used by setup is
- NOT the local system account, and
- NOT a member of the Administrators group, and
- NOT a member of the Domain Administrators group, and
- NOT a member of the Power Users group
Then,

4a. Verify that User Rights granted to the service account are properly documented.

4b. Quit.

Otherwise, continue on with Step 5.
Create local or domain user accounts for each service that will be installed. Create local accounts if the service does not need network access; otherwise create domain accounts
If necessary, reconfigure the service(s) to run as a member of the local User's group
- If a service is configured to run as local system, use the services applet to run the service (see Endnote 4) under an account created in Step 5.
- If a service is configured to run under the local administrator account, use the services applet to run the service under an account created in Step 5.
Remove all members of the local Administrators group except for Administrator and Domain Administrators
Remove all members of the Domain Administrators group except for the Administrator.
Remove all members of the Power Users group.
As specified in the your documentation, explicitly grant all User rights required by the service to the user account that the service is running under. If the setup program has already accomplished this, then verify that the user rights granted by setup are the same as the user rights listed in the ISV documentation. If not, the documentation must be updated.
As specified in the your documentation, explicitly grant all permissions to all resources required by the service accounts on the both local and remote machines.

Note It may not be possible to completely perform this task. If a service account requires permissions that are "hardwired" only for the Administrators group, then there will be no way to grant those permissions to the service account. Such permissions include:
- The ability to access admin only ($) shares
- The ability to install other services or drivers
- The ability to read/write device drivers via IOCTLS
Verify that the application functions properly.
If the application requires "hardwired" administrative privileges such as those listed in the note to Step 11, verify that the service fails when those permissions are requested.

How To Pretest Support for Single Sign-On

If the server-side of the application has an option for anonymous or authenticated logon, select authenticated logon. If the server does not have this option, use the default.

Run the client in the context of an anonymous, unauthenticated account and try to access the server. The client should either prompt you for an authenticated user logon or deny you access to resources.
Run the client in the context of an authenticated trusted domain account. The client should provide access to expected resources as per the access control policy, without prompting you for a logon.

Note If the server allows anonymous, unauthenticated logon by default and there's no option to allow only authenticated logon, the application cannot be Certified for Windows 2000.