Professional Windows Server 1002003 Security A Technical Reference [Electronic resources] نسخه متنی

In some cases, an administrator may not be able to directly implement her choice. For example, she might prefer Kerberos rather than NTLM for network authentication, but there is no absolute way to prevent NTLM from being used. She can only strongly support the use of Kerberos by removing machines that rely on NTLM, or she can promote the use of NTLM by continuing to use legacy systems; however, she cannot flip a switch and limit network authentication to a single protocol.

An administrator may not be able to implement what he knows is the most secure option or configure what must be available in the most secure manner. The organization's security policy, possible detrimental results, or the impracticability of the choice may hinder his efforts. Security implementation should be based on risk, which must consider security and usability.

LM

The LM protocol was originally developed to provide a network authentication scheme that could be used with MS-DOS and Windows 3.1. It is the native algorithm used by Windows 95/98 and Windows ME. It may be used by Windows Server 2003 to authenticate users whose computers use these earlier versions of Windows on the network. Later, more secure versions of the protocol were developed: NTLM and NTLMv2. NTLM addresses the weaknesses in LM and was introduced with Windows NT. NTLMv2 addresses the weaknesses of NTLM and was introduced with service pack 3 for Windows NT 4.0. Although all three protocols are authentication protocols, using NTLMv2 for session security improves the level of protection applied to the data being communicated after authentication.

LM Authentication Algorithm

In all three protocols, the authentication process consists of a challenge/response composed of four parts:

Differences in processing between the versions of LM are presented in Table 2-2.

LM Password Requirements

Although in most cases the user determines the characteristics of the password, the LM algorithm used and the password policy restrictions limit choices. An LM password can be composed of up to 14 characters, and the available character set is limited to uppercase letters, the numbers 0 to 9, and the special characters or punctuation marks. (If the user enters lowercase letters, the letters are converted to uppercase before the password is hashed.)

TIP: Use Unicode Characters in Passwords

NTLM and NTLMv2 passwords can include Unicode characters. Unicode characters can be good choices for passwords because common password-cracking programs do not include them in their brute force algorithms. Password-cracking programs could be extended to test for Unicode characters, but the larger the character set that the program has to test for, the longer the program will take to work. To include Unicode characters, hold down the ALT key and enter a three- or four-digit number using the numeric keypad. Not all Unicode characters will improve security, as some may simply represent characters that can be entered from the keyboard. ALT+0100, for example, is converted to "d." To determine if your favorite Unicode character translates into a common keyboard character, entering it in Notepad to see the results.

The Microsoft document "Selecting Secure Passwords" at http://www.microsoft.com/smallbusiness/gtm/securityguidance/articles/select_sec_passwords.mspx includes a table of numbers that will create Unicode characters that do not translate into ordinary characters.

LM/NTLM Configuration

The LM legacy weakens security in a Windows domain in two ways. First, passwords hashed for use with the LM algorithm are easier to crack, and several tools exist that capitalize on this weakness. When LM is used for network authentication, the authentication material can be captured and the password may be deduced. Second, even if LM is not used to authenticate network clients, a password hash that might be used by the LM algorithm may be stored in the password database. An attacker who is able to obtain access to the weaker LM-compatible hash may be able to crack it and use the results to obtain the NTLM password required for authentication. If no LM password hash is available, it will be more difficult for passwords to be cracked. Where all clients can be configured to use NTLM, you should prevent the storing of the LM password hash in the database, as described in the following. To ensure no storage of an LM password hash, use passwords longer than 14 characters. If the password is longer than 14 characters or contains characters not allowed in the LM character set, no LM-compatible password hash will be stored.

By default, a Windows Server 2003 domain does not allow the use of the LM network authentication algorithm, but it does not prevent the storage of the LM-compatible password hash. If Windows 95 or Windows 98 clients must be used by users who need to log on to a Windows Server 2003 domain, you can weaken authentication by allowing use of the LM algorithm in the domain, or you can update clients to enable them to use NTLM or NTLMv2. The domain may be made more secure by eliminating the storage of the LM-compatible hash.

To update Windows 95 and Windows 98 clients so that the more secure NTLM algorithm can be used, you must load the Active Directory client and configure the client to use NTLM or preferably NTLMv2. Depending on your choice, you may also be able to tighten security on the server by requiring the use of NTLMv2. If this is not possible, you will either have to upgrade these clients to Windows 2000 Professional or XP Professional or weaken domain security by making a change to Group Policy. Before you tighten or weaken security, you must understand the NTLM configuration options, how they are configured on each operating system, and how some legacy applications may prevent you from applying the most secure version of LM.

Reduce Security

It is possible to weaken security by accepting LM authentication in a Windows Server 2003 domain. Because the default domain controller setting does not allow the use of LM authentication, if you cannot configure the client, you must change the NTLM/LM configuration settings on the domain controller. This is not advised. To do so, adjust the default domain security policy by changing the Security Option LAN Manager Authentication Level to Send LM And NTLM Responses. Security Options are located in the Windows Configuration, Security Settings, Local Policy section of the Group Policy object. Verify that the Security Option Network Security: Do Not Store LAN Manager Hash Value On Next Password Change is set to Disabled (the default). This means that the LM-compatible hash will be stored and available for use. If you will be allowing LM authentication, you want the LM hash to be present in Active Directory.

Improve Security on Legacy Clients

To improve security on legacy clients (Windows 95, Windows 98, and Windows NT 4.0 post service pack 4), you may need to install the Active Directory client and/or make registry changes that enforce the use of the stronger NTLM or NTLMv2 authentication protocols on every Windows 95 and Windows 98 computer used to authenticate to the domain. The Active Directory Client software is available for download from Microsoft.com at http://support.microsoft.com/default.aspx?kbid=288358#2. Although a copy is available on the Windows Server 2000 installation CD-ROM, you should obtain the latest version from Microsoft. Make registry changes on all legacy clients.

NOTE: The Windows NT 4.0 Active Directory Client is Not Necessary for NTLM Configuration

A Windows NT 4.0 version of the Active Directory client is available. However, it is not necessary to install it to make Windows NT 4.0 require the use of NTLM or NTLMv2. You may want to install it to provide other advantages such as site awareness (the ability to log on to the domain controller closest to the client rather than to the Primary Domain Controller (PDC) emulator), availability of a DFS fault-tolerant client (NT 4.0 clients will be able to use Windows 2000 fault-tolerant and fail over file shares specified in Active Directory), and to provide a common programming interface for programmers developing Active Directory scripts.

Warning: Editing the Registry Can Produce Catastrophic Results

The registry editing tools allow changes to system and application configuration without requiring confirmation and without warning of the results. Caution should be used whenever editing the registry, and it is always appropriate to make a backup of the registry before making changes.

Registry changes for NTLM are made by doing the following:

Improving Security on the Windows 2000, Windows XP Professional, and Windows Server 2003 Servers and Domain Controllers

Newer versions of Windows based on Windows NT technologies can be configured to require NTLM or NTLMv2 by adjusting Group Policy LAN Manager Security Option settings, as shown in Figure 2-2.

Table 2-3 describes the use of each of the available Security Option settings and the corresponding registry key values.

Considerations

Before making changes that will reduce or improve security, you should evaluate the possible negative impact of doing so. There are three LM issues to consider:

All clients in the domain may need to be adjusted to use the more secure protocol when domain controllers are configured to reject the weaker ones. If you leave out any clients, they will not be able to communicate with the domain controller. Users will not be able to log on.

All domain controllers in the domain must be configured the same way. If you leave out any, some clients will not be able to communicate with the domain controller. Users will not be able to log on. Use Group Policy to ensure that changes are implemented on all domain controllers.

Some services might not work when the LM controls are configuredspecifically, legacy services including RAS and RRAS on Windows NT 4.0, the print spooler service on some systems, and browsing services in Windows NT. If you must use these services, you will have to wait until these services are updated before modifying these settings past the elimination of LM. Of course, as you upgrade servers and migrate users to Windows 2000 Professional, Windows XP Professional, Windows Server 2003, and operating systems that can use Kerberos for authentication, you will ultimately improve the authentication security for your domain.

Remove the LM Hash from the Account Database

For additional security, you should remove the LM hash from the account database. To do so, you must change the Security Option Network Security: Do Not Store LAN Manager Hash Value On Next Password Change to Enabled and require all users to change their passwords. Alternatively, you can modify a registry key. To modify the registry entry, follow these steps:

Change the user account setting User must change password at next logon so that users will be required to do so. The LM hash will remain in the database until the user next changes his password.

Session Security

Enhanced session security can increase the likelihood that attacks fail. If client and server support NTLMv2, two Security Options can be used to configure session security; alternatively, a registry entry may be set.

The Security Options Network Security: Minimum Session Security for NTLM SSP based (including secure RPC based) clients and Network Security: Minimum Session Security for NTLM SSP based (including secure RPC based) servers include choices that set session security. The choices are listed in the "Options" column of Table 2-4. Registry key values are also listed.

To configure session security, select the required options or configure the registry key.

TIP: Combine Session Security Options Using Hexadecimal Numbers

The advantage of using the registry key is the ability to combine the session security options. You can do so by using the Windows Calculator program. Simply change the calculator to scientific view and use the logical OR button. You can combine any number of hexadecimal numbers quickly by entering the number for the first value you want, clicking the OR button, and repeating this process until the last number has been OR'd. Click the = button to get the final result. For example, combining the values for integrity and confidentiality from Table 2-4 results in the hexadecimal number 0x00000030. Enter this value in the registry key NtlmMinClientSec or NtlmMinServerSec to require that confidentiality and integrity be used in an NTLMv2-based session.

Kerberos

Kerberos is the default network authentication protocol for Windows 2000, Windows XP Professional, and Windows Server 2003 computers that are joined in a Windows 2000 or Windows Server 2003 domain. These systems will use NTLM if they are not in a domain and are attempting to access remote resources. They may also fall back to NTLM when Kerberos can't be used. An example is that drives mapped from domain members using the IP address of the file server will use NTLM, while the same drive mapping using the computer name of the file server will use Kerberos. Domain members may also use NTLM when mapping drives using computer names if the client or server does not have network connectivity with a DC.

The use of Kerberos for authentication in Windows systems starting with Windows 2000 is an important development on two fronts. First, Kerberos is an IETF standard (RFC 1510), and versions exist for multiple operating systems. Security algorithms of any type are usually judged to be more secure if they are public standards in use by many people. The rationale is that many people can inspect the algorithm, increasing the chance that flaws will be found and corrected. Over time, a hardened, tested security algorithm is developed, as is experience in coding it. Therefore, there is a smaller chance that vulnerabilities exist that an attacker could use to compromise the systems that use them. Second, because it is a standard in wide use, interoperability between operating systems is possible. It is possible to configure Kerberos authentication between Windows and other operating systems.

NOTE: Will the Use of Kerberos Create a Dangerous Monoculture?

When only one process is used throughout many systems, it is often referred to as a monoculture. The extraordinary number of Windows desktops in use is often so defined. Although it is true that well-known standards tend to provide more secure processes because it is more likely that their flaws will be found and corrected, it is also possible that if a flaw is discovered and not reported, more machines will be susceptible to compromise. If most computers use one security protocol for authentication, a directed attack against some flaw in that authentication protocol could impact more than one operating system.

Kerberos offers security functionality far beyond that offered by the challenge/response-type authentication processes such as NTLM. Kerberos offers the following security characteristics:

Secure transmission
All Kerberos messages are encrypted using a variety of encryption keys. The password is never sent across the network; instead, the password hash may be used as an encryption key.

Mutual authentication
The client verifies a server's identity; the server verifies the identity of the client.

Replay protection
When authentication messages cross the network, they can be captured. It might be possible for an attacker to reuse them to compromise the system. Kerberos provides protection against these replay-type attacks. To do so, it requires that each message include an authenticatoran encrypted timestamp. The time on the client can be compared to the time on the server, and delayed messages (those possibly captured and replayed) are rejected.

Windows 2000, Windows XP Professional, and Windows Server 2003 computers joined in Windows 2000 or Windows Server 2003 domains may use Kerberos as their authentication protocol of choice.

Kerberos Components

The Kerberos algorithm is complex but easily understandable if broken into the separate processes that it is used for: logon, resource access, access to resources in other domains, and delegated authentication. The components of the Kerberos process are as follows:

Key distribution center (KDC)
Manages shared secrets for client and server and supplies ticket granting tickets (TGT) and service tickets to users and computers on the network. The Windows Server 2003 KDC service exists on every domain controller.

Kerberos tickets
The Kerberos process identifies specific data structures as tickets to make them easier to talk about. In reality, each ticket is a collection of data and includes information about the client, the user, the request, and the KDC. Parts of the ticket are encrypted using the password hash of the user/client, which may be inspected by the user, and parts of the ticket are encrypted using the password hash of the KDC so that the KDC can recognize it as its own. Two types of tickets and a variation are used in Windows Server 2003 Kerberos.

Ticket Granting Ticket (TGT)
Provided to the authenticated user when he or she first logs on to the network. The TGT is used to request a service ticket when access to a new service is required.

Service Ticket
Required to obtain access to a service or resource.

Referral ticket
When a service ticket is required to access a resource that exists outside of the user's logon domain, the user's KDC issues a special kind of TGT: a TGT for another KDC. If the resource is not in that domain, that domain can issue a referral ticket to another domain and so on until the appropriate domain has been reached.

Authenticator
An extra piece of information that enables authentication. A small piece of unique data (the time stamp at the client computer) is encrypted using a password hash. A fresh authenticator always accompanies the ticket whether the ticket is a TGT, a service ticket, or a referral ticket. Although a ticket could be captured and used in a replay attack, because the authenticator is created fresh each time a ticket is used, the tickets can be validated for their authenticity.

User Logon

User logon consists of an authentication request, validation, TGT issue, request for a service ticket for access to the user's desktop, and issuance of the service ticket, after which, if the user is authorized to log on from this machine, the user gets her desktop.

One way to think about this two-ticket transaction is to think about the process you follow when traveling by air. When you purchase a ticket over the Internet, you receive an electronic receipt, or if you request it, perhaps a paper ticket. This alone will not get you on board the plane. The receipt or the paper ticket may be compared to the TGT. You have to present credentials as part of the process. At the airport, you present the receipt or paper ticket and your photo ID (or if your original purchase was done electronically, it should be in the ticket agent's database, and it will not be necessary to present a receipt at all). In exchange, you receive a boarding pass. The boarding pass may be compared to the session ticket. It's a ticket that can be presented to go through security checkpoints and board the plane. At security, you present the boarding pass and your photo ID (the authenticator) to get through to the gate. At the gate, you use this "session" ticket to board the plane. You may also be required to present your authenticator at boarding to ensure that the service ticket is valid. Figure 2-4 illustrates the Kerberos logon process, as listed in the following.

Resource Access

In the previous example, Kerberos was used to authenticate the user to the domain. However, another process also occurredthe user was authorized to log on to the domain from that specific computer during that time frame and was granted access to resources on the computer. As a user uses the computer to do work throughout the day, she will request access to resources both on the local computer and on servers and systems connected to the local network and elsewhere. That process, authorization, is described in Chapter 3, "Authorization: Limiting System Access and Controlling User Behavior." For now, simply remember that Kerberos plays a role in authorization. During the logon process, information about the user's membership in groups and rights on systems is collected and recorded as part of the Kerberos ticket. This information, the user's domain credentials, is therefore available and can be used for authorization by processes that the user may run. The credentials are used to authorize use of system(s) resources.

The user's credentials are added to the authorization data field of the TGT at the time it is created at the KDC. The authorization field data is copied to each service ticket. On each machine the user visits, data specific to her rights and privileges on that local machine is combined with that in the authorization field to create the access token used during the authorization process. The user's credentials are her SID, the SIDs of the groups of which she is a member, and the user rights that belong to her. This data can be compared to the rights and membership required for resource access. The approval or authorization process is not part of the Kerberos algorithm. An example of the authorization process when Kerberos is the network authentication protocol is shown in Figure 2-5 and listed in the following.

Accessing Resources in Other Domains in the Forest

If a resource does not exist in the local domain, the local KDC provides a referral ticket for another KDC. This is possible because each Windows domain shares a domain password with its parent and child domain. Before issuing such a ticket, the KDC will determine the trust path required to reach the domain in which the desired resource resides. The trust path is a list of domains that must be traversed to reach the resource domain. When this path is known, the client begins the process of obtaining a TGT for the resource domain by obtaining, one after another, referral tickets from domains along the trust path. Figure 2-6 illustrates a trust path between the west.indiania.fizzrep.org domain where user JoeyP's account resides and the fachunk domain where the file share \\vegas\motel6 exists. In the drawing, dotted lines represent domain relationships, wheras arrows represent the steps along the trust path.

The process can be described simply as:

Trusted for Delegation

Kerberos works well when the security principal that needs access to a remote resource is making the request for access. However, some applications are built in tiers, and sometimes the application is making a request for resources at a remote location. One such application is the typical web application that requires access to a remote database. Kerberos-delegated authentication can be used to solve this two-tier application issue. This scenario is illustrated in Figure 2-7. In the figure, a user authenticates to the web server; however, the web application must obtain or store data in a database on a third machine. Prior to the Kerberos implementation in Windows 2000, there was no built-in way for Windows web applications to impersonate or use the user's credentials to obtain access to the database. (NTLM does not support "two-hop" authentication.) This lack of capability to impersonate a user's credentials limited the granularity of access controls on the database and the capability to provide accountabilityan audit of the database activity could not provide specific records that would indicate which user accessed the database. Using Kerberos and Windows 2000, the web server can be "trusted for delegation," and the user's credentials can be used to access the database. The web server application, in essence, "impersonates" the user.

Delegation can be configured by checking the trusted for delegation check box in the server's properties in Active Directory. The user whose account will be impersonated must also be Trusted for delegation and not have the This account is sensitive and must not be trusted for delegation selection made in his or her Account properties.

However, trusting a server for delegation can create a serious security issue. The problem is that by default, no limit is placed on the delegation. (Windows Server 2003 delegation can be constrained; Windows 2000 delegation cannot be.) Although the purpose of the delegation may be to provide granularity in access control to a database, when delegated, the credentials could be used to provide access anywhere that the user has been assigned access. A malicious person might take advantage of this. For this reason, unconstrained delegation of Administrator accounts is not recommended. If delegation is a requirement for web or other multitier applications, the risks should be evaluated before delegation is considered. If delegation is required, where possible, constrained delegation should be used.

Constrained Delegation

Constrained delegation provides the ability to limit the use to which the server can put the delegated user's credentials. (Constrained delegation is only available on a Windows Server 2003 server and only when the Windows Server 2003 domain functional level is set to Windows Server 2003a functional level that can only be set when no NT 4.0 or Windows 2000 domain controllers are part of the domainsee Chapter 7, "Active Directory's Role in Domain Security.") An example of constrained delegation would be to limit the credentials for use in accessing SQL server database services.

Constrained delegation uses a new Kerberos request type called Service-for-User-to Proxy (S4u2Proxy) Extension. This request type, if enabled by constrained delegation, is used when a service 1 on server A uses the client's credentials to request a ticket for service 2 on server B. The domain controller will check to see if service 1 is allowed to use the user credentials to obtain access to service 2; it checks to make sure the service is allowed to delegate credentials. In our web application example, a Windows 2000 server trusted for delegation gets a copy of the client's TGT and uses it to obtain its own session ticket for the database server. In Windows Server 2003, the server trusted for delegation can request on its own, a user's session ticket if the user account is trusted for delegation. When constrained delegation is configured, the capability of the server to use this request can be limited to those services approved for its use.

Configuring constrained delegation is usually part of a complex multitiered web-based application that includes server configuration and application development efforts. The proper development and implementation will depend on understanding both the new technology and the application requirements. For example, a service running on the web server may need to impersonate the account of a user to access data in a Microsoft SQL Server database. Constrained delegation is configured on the property pages for the web server computer in Active Directory Users and Computers, and user accounts that may be impersonated must not be marked Account is sensitive and cannot be delegated in the user Account properties. In addition, if special user accounts are created for services that must be delegated; a server principal name (SPN) must be registered for the account. Application and configuration need to be developed hand-in-hand.

Constrained delegation can be configured to provide delegated access to any services running on the target computer.

To configure constrained delegation:

The user account property Account is sensitive and cannot be delegated is not selected by default. If it is, access using this user's credentials cannot be delegated. To check the status of a user account, do the following:

If special user accounts are created for services that will be used, an SPN must be registered, and the user account must be marked as delegated to specific services only. Restricting the account in this way makes its use in other unauthorized delegation scenarios less likely because an administrator would have to reconfigure the account. The ability to restrict the account is only configurable if an SPN has been registered for it.

Register an SPN by using the setspn command with the following syntax:

Setspn A nameofservice/useraccount computername

In the command, nameofservice is the system name for the service, and computername is the name of the computer. The following line registers an SPN for the user account User1 on the computer reaglinn in the domain chicago.local for the Themes service.

Setspn -A shsvcs/user1 regalinn

Protocol Transition

Constrained delegation requires the service to use the client's user's Kerberos session ticket to obtain a TGT using the client's user's credentials. But many web browsers and web applications are not configured to use Kerberos authentication. In this case, another Kerberos extension, S4U2Self (Service-for-User-to-Self) allows the service to obtain a user's service ticket. Delegation can occur even if the original client authentication is some protocol other than Kerberos. This process is known as protocol transition. To configure protocol transition, do the following:

This extra step is necessary to ensure that not just any service can obtain this information. A second check is placed on the service. During the process, both S4u2Self and S4u2Proxy are used. If the user's account is set as Sensitive and cannot be delegated, then S4u2Proxy cannot be used. If the client's account is not so marked, the process is still governed by the list of services added to the server's properties page.

Additional steps may be necessary to configure the web server. More information on S4U2Proxy and S4U2Self is contained in the MSDN Magazine article, "Exploring S4U Kerberos Extension in Windows Server 2003" at http://msdn.microsoft.com/msdnmag/issues/03/04/SecurityBriefs/ and in the article "Kerberos Protocol Transition and Constrained Delegation" at http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/constdel.mspx.

Configuring KerberosThe Kerberos Policy

Although you cannot turn Kerberos "off" or "on," you can influence how Kerberos works. These configuration parameters are located in the Group Policy, Account Policy, Kerberos Policy. They can also be manipulated via the registry on domain controllers. The Kerberos policy can only be adjusted in the domain security policy. More information on the domain security policy and policy processing can be found in Chapter 7.

Kerberos policy consists of five elements. Table 2-5 lists the parameters, discusses their meanings, and provides the default settings.

^[*] The Kerberos policy refers to a TGT as a "user" ticket.

Certificates, Smart Cards, Tokens, and Biometrics

Certificates and biometrics can also be used for network authentication. Several certificate uses are defined in other chapters, including the use of certificates in IPSec for machine authentication in Chapter 15, "Protecting Data in Flight," and in web server and web client authentication using SSL/TLS in Chapter 14, "Securing Remote Access." A discussion of the specifics of certificate authentication is reserved until that time, as a background in Microsoft Certificate Services is required. Certificate Servers are discussed in Chapter 12, "PKI Basics" and in Chapter 13, "Implementing a Secure PKI."

Built-in support for smart cards is present in Windows Server 2003. Certificate Services must be available. In addition, many other token-based authentication systems that are built for Windows Server 2003 rely on the use of certificates. Application Programming Interfaces (APIs) are available for the use of biometric forms of authentication. Biometric authentication relies on some physical proof, such as fingerprints, voiceprints, retinal or iris scans, and so on. No default application support is available, but the hooks, in the form of APIs, are available. Third-party biometric-based authentication packages are available for both local and network authentication. They may or may not be fully integrated with Active Directory.

Network Authentication Protocols Selection and Cached Logon Credentials

Previous sections outlined how the type of network authentication protocol used depends on these elements:

The client operating system

The domain controller or network server operating system

Configuration of Both Client and Server Operating Systems

Table 2-6 lists possible clients in a Windows Server 2003 domain, the default authentication process they will attempt to use, whether they can use this to authenticate to a Window Server 2003 domain, and what configuration choices are available to secure network authentication.

All of these possibilities are dependent on the ability of the client to connect to a domain controller. If no connection is possible, network authentication is impossible. This can occur when the domain controller is down or unavailable for some other reason, or when the client computer has been removed from the network. For example, a laptop can be removed from the network when it is carried away from the building. In this case, the user may be able to authenticate locally using a domain account if that account's credentials are cached.

By default, the last 10 logon credentials are cached. This number can be changed using the Group Policy Security Option Interactive Logon: Number Of Previous Logons To Cache. Valid settings are 0 through 50. When set to 0, this feature is disabled. Do not set this option to 0 when it might affect laptops, when users must log on to a domain controller across a WAN, or where the domain controller is often not available. If you do, users will not be able to log on. This can be more serious than you think. A laptop user may be miles from the office and unable to access her laptop, and hence email and other company resources, until she can return to the office.