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:
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.
Documenting the services that require more than User-level privileges provides customers with the information necessary to make one of the following choices:
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:
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/
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:
For example:
| Service | Resource or User Right | Minimum resource permission required by service |
| Fax | %systemroot% | Write (This Directory, subdirectories and files) |
| 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:
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:
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.
RPC_C_AUTHN_GSS_NEGOTIATE (for automatically negotiating Kerberos or NTLM) or
RPC_C_AUTHN_GSS_SCHANNEL (for Public key authentication).
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.
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) {
}
Then,
4a. Verify that User Rights granted to the service account are properly documented.
4b. Quit.
Otherwise, continue on with Step 5.
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:
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.
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.