Tag: EFS

EFS protects data from being read, not deleted. Because attempts to copy an EFS-encrypted file fail, many assume that an unauthorized user cannot delete the file either; however, it can be deleted.

EFS protects data stored on a local NTFS partition. It does not protect data when it is sent across a network. This is a big issue. Because EFS was designed to be transparent to end users, when the user who encrypted the file copies it across the network or sends it via e-mail, the file is automatically decrypted before it is sent across the network so that it can be readable on the target system. For a user who does not understand this, and believes that his or her sensitive data is secure, the mistake can be costly.

EFS is not usable across the network on mapped drives unless the server and client operate within the same Active Directory forest and the server has been trusted for delegation. Only domain controllers in an ADS environment are trusted for delegation by default. Understanding these limitations is important for EFS to be used effectively. As Microsoft had intended, EFS is easy to use, but using it still requires proper end-user training. How many users on your network understand these concepts? Or possibly more important: How many users on your network have access to the use of
EFS, yet do not understand it?

One of the first things that should concern any support tech or network admin is the fact that any users with modify permission (the ability to write) to a file or folder can encrypt it. This can certainly be applied to files they did not create. Could this cause a problem in your environment? Do multiple users share the same system? If so, problems can certainly arise. Do you have domain controllers that also act as file servers in your Active Directory environment? If so, a user could encrypt a file that many people are allowed to modify and accidentally make it inaccessible to everyone else. Having EFS enabled by default gives end users the roundabout ability to make such a problematic change.

Used properly and with the right preparation, EFS can add the additional security you may need on your network. Hopefully, making that decision is easier after reading this article. If you do decide that EFS is needed, definitely take a look at Microsoft’s white papers on the subject and review its best practices. Microsoft makes EFS sound easy in its ads, but the white papers will give you a much better idea on what is needed for proper implementation.

[rsslist:http://ah.pricegrabber.com/export_feeds.php?pid=hjehfab&document_type=rss&limit=25&topcat_id=all&category=topcat:all&col_description=1&form_keyword=vista]

The problems with EFS can be greatly compounded if you are not looking for it as a possible culprit. When a user tries to access a file that has been encrypted by someone else, depending on the type of access attempted or the application being used, the user will generally get one of two messages: Access Denied or This File Appears To Be Corrupted.

If the Access Denied message appears, most end users assume that an admin has improperly locked them out, so they contact the help desk. If the person troubleshooting the problem just looks at the permissions on the file or folder, there’s no indication that a user has been denied access. Only bringing up the file’s advanced properties will reveal the problem. Many man-hours can be wasted pursuing other potential problems, such as group permission conflicts.

Of the two common messages users receive when they are not allowed to read the file due to EFS, the Access Denied message is the good one. Users receiving a message indicating that the file appears corrupted may go so far as to delete the file. Since EFS will not stop the deletion, users will be able to do so. If the person troubleshooting the situation is not looking for EFS as the potential problem, things can get far worse when the message This File Appears To Be Corrupted occurs. There are quite a few horror stories already being attributed to this scenario. Take the following example:

Two users working different shifts share the same Vista system. The user working the evening shift has a fair amount of downtime and uses it to explore different aspects of the system. Upon discovering the Encrypt Contents To Secure Data setting, he decides to activate this feature. "What’s wrong with securing the data?" he says to himself.

He has selected a file in a folder shared by both users, and the default EFS setting indicates that not only should the file be encrypted, but the parent folder as well. The user accepts this and clicks OK. Now every file created in this folder will be encrypted to the user who created it and unreadable by the other user. The user in the evening modifies these files without issue and believes everything is working fine.

When the daytime user tries to open a file in this folder, she receives a message indicating that the file’s data appears to be corrupted. She calls the help desk and indicates that there’s a problem. The files in this folder needs to be written to every day as part of their jobs, so the problem needs to be solved quickly. A help desk tech shows up and begins troubleshooting the problem. The tech tries deleting and restoring the file from the nightly backup, but unfortunately EFS files back up encrypted. So the restored file also comes up corrupted. The tech believes this signals a problem with the application used to edit the file. The tech reinstalls the application, but the problem persists.

Needing to solve the problem quickly, the tech decides to reload the operating system, since there is a backup of the data. The reload of the OS erases the keys used to encrypt the data, and it’s now completely unreadable!

[rsslist:http://ah.pricegrabber.com/export_feeds.php?pid=hjehfab&document_type=rss&limit=25&topcat_id=all&category=topcat:all&col_description=1&form_keyword=vista]

Vista includes two encryption technologies: Encrypting File System (EFS) and BitLocker Drive Encryption. As with most technology, once you implement either encryption technology, you might encounter some common problems. In this series of articles, we will take a look at some of the common issues that can arise with both technologies.

If you cannot enable BitLocker Drive Encryption on your computer, you need to check if your motherboard is TPM compliant. This is not so much as a problem but more of a configuration issues. Without a TMP, BitLocker will not be enabled by default and you will see a message indicating that a TPM was not found.

You can still take advantage of BitLocker without a TPM compliant motherboard. The workaround is to get an external USB key to store the encrypted keys. Each time you boot the computer, you will need to insert the USB key into the USB port.

On the topic of configuration issues, if your hard disk is not configured properly (refer to the Lockergnome article called ‘Planning For Encryption In Vista’), you will receive the following message:

The drive configuration is unsuitable for BitLocker Drive Encryption. To use BitLocker, please re-partition your hard drive according to the BitLocker requirements.

To use BitLocker, your hard disk needs at least two partitions. The first partition contains startup information and the second contains the operating system and user data. You can download and run the BitLocker Drive Preparation Tool to prepare your hard drive.

[rsslist:http://ah.pricegrabber.com/export_feeds.php?pid=hjehfab&document_type=rss&limit=25&topcat_id=all&category=topcat:all&col_description=1&form_keyword=vista]

In the Part II of this series, you learned how to encrypt files in Vista and verify that users are unable to open the encrypted files. An important point to keep in mind is that although the user is unable to open the file, they can delete the file. You might be confused as to how this is possible.

Here is the answer: The user has full-share and NTFS permissions to the file. These permissions include reading, modifying, and deleting the file. If the user does not try to open the file, the EFS subsystem isn’t required. If the user tries to open the file, the EFS subsystem intervenes and denies access. But users can simply delete the file, which they have rights to do as defined by the NTFS permissions. Remember, file encryption is used to protect the contents of a file from prying eyes. It is not designed to protect the file itself. That’s why a properly designed share and NTFS structure is still critical even when using EFS.

In Vista, multiple users can be granted rights to read and modify encrypted files. Right click the encrypted file that you want to share and click Properties. From the General tab, click the Advanced button. From the Advanced Attributes dialog box, click the Details button. Click the Add button. Select the user to whom you want to grant access to the encrypted file. Click OK. Once the appropriate user has been granted permission, they will be able to open the file.

When an encrypted file is moved or copied from its source location to a new location, it is first decrypted. But this isn’t a hole in the security scheme. To copy or move an encrypted file, you must have the ability to open the encrypted file. In fact, even if a user has NTFS rights but doesn’t have rights to decrypt the file, he or she will be greeted with an error message.

[rsslist:http://ah.pricegrabber.com/export_feeds.php?pid=hjehfab&document_type=rss&limit=25&topcat_id=all&category=topcat:all&col_description=1&form_keyword=vista]

Getting started with a basic EFS setup is as easy as a few mouse clicks for a simple configuration. For these steps, I will assume that you’re using roaming profiles to avoid the certificate confusion. From the client, browse to the file that you would like to encrypt. Right-click it and choose Properties from the shortcut menu. On the General tab, click Advanced. The Advanced Attributes window will appear.

From the Advanced Attributes window, select the box marked Encrypt Contents To Secure Data, and click OK. When you are done, the file name will appear in green, which indicates that it has been encrypted.

To see who has access to an encrypted file, you can view the file’s encryption details by right-clicking it, choosing Properties, clicking the Advanced tab, and clicking Details on the Advanced Options window.

EFS creates a Data Recovery Agent (DRA) automatically so that this step is not skipped, which would result in inaccessible files. To change the user whose certificate is used by default, you need to change the EFS group policy by going to Active Directory Users And Computers | Domain Properties | Group Policy | Edit | Computer Configuration | Windows Settings | Security Settings | Public Key Policies | Encrypting File System.

The easiest way to make sure that an encrypted file is inaccessible to other users is by trying to access it. For proper testing, make sure that another user has the share and NTFS permissions necessary to access the file. When the user logs in and tries to access the encrypted file, they will get an error message stating that access is denied.

[rsslist:http://ah.pricegrabber.com/export_feeds.php?pid=hjehfab&document_type=rss&limit=25&topcat_id=all&category=topcat:all&col_description=1&form_keyword=vista]

Vista includes two encryption technologies: Encrypting File System (EFS) and BitLocker Drive Encryption. In this series of articles, you will learn how to set up both technologies in Vista.

To use BitLocker Drive Encryption (assuming you are not using hardware cryptography) you need to first configure the local computer policy to allow you to use USB key mode. Within the local computer policy, navigate to the following location: Computer Configuration Administrative Templates Windows Components BitLocker Drive Encryption. Open Control Panel Setup: Enabled advanced startup options. Select the Enabled option and the Allow BitLocker Without a Compatible TPM option.

To turn on BitLocker Drive Encryption:

1. Open the Control Panel, select Security and click BitLocker Drive Encryption.
2. Click the Turn On BitLocker option for the operating system volume.
3. Choose one of the available options to save the recovery password. The recovery password can be saved to a USB drive, in a folder or it can be printed. This password is required to move the drive to another computer or if changes are made to system start up. Therefore, it is crucial that it is kept in a secure location.
4. Once you have selected the password recovery option, click Next to continue encrypting the operating system volume.
5. Next, verify that the Run BitLocker System Check option is selected. Click Continue.

The computer will restart and proceed with the volume encryption.

Additional settings for configuring BitLocker Drive Encryption are available through the local computer policy. You can find these settings under the following container: Computer Configuration Administrative Templates Windows Components BitLocker Drive Encryption.

Once BitLocker Drive Encryption is enabled, it will lock the drive that Windows is installed on in specific situations that include:

• A possible security risk is detected on start-up.
• The computer is operational but the BitLocker startup key or pin is lost or the startup key is damaged.
• The computer is not operational and you have transferred the hard drive to another computer.

In these cases, you have to unlock the drive using the BitLocker recovery password to gain access to you files.

[rsslist:http://ah.pricegrabber.com/export_feeds.php?pid=hjehfab&document_type=rss&limit=25&topcat_id=all&category=topcat:all&col_description=1&form_keyword=vista]

In Part I of this series, you learned about some of the things to consider before implementing EFS. BitLocker Drive Encryption has some very specific requirements so lets take a look at some of the things to consider before implementing it on a computer.

BitLocker requires local or Active Directory Group Policy modification to enable. It also has very specific hardware requirements.
There are two basic options for running BitLocker:

Option 1

1. TPM 1.2 hardware module
2. 1.5 GB NTFS Active System partition
3. 50+ GB Boot partition

Option 2

1. Generic USB data key
2. 1.5 GB NTFS Active System partition
3. 50+ GB Boot partition

The 1.5 GB Active System partition is where the unencrypted bare essential bootstrap files for the Vista operating system are located. The 50+ GB Boot partition is where Windows is installed and where your page files and temporary files should be located, since EFS can’t protect these things but BitLocker can.

The best way to set this up is to create a 1.5 GB partition along with a 50 GB partition when you first install Vista. However, if you have already installed Vista, you can use the BitLocker Drive Preparation Tool to automatically redo the partitions. If you have already made the 1.5 GB partition, you will still need the preparation tool to transfer the necessary files from your Windows partition to the 1.5 GB partition.

To get the BitLocker Drive Preparation Tool, you can go to Windows Update and look under Vista Ultimate Extras. There, you simply check BitLocker Drive Preparation Tool to download and install.

[rsslist:http://ah.pricegrabber.com/export_feeds.php?pid=hjehfab&document_type=rss&limit=25&topcat_id=all&category=topcat:all&col_description=1&form_keyword=vista]

Vista includes two encryption technologies: Encrypting File System (EFS) and BitLocker Drive Encryption. Some prior planning is required to implement either technology effectively.

EFS is designed so that it’s not necessary to have a Certificate Authority (CA) on the network to use file encryption. If there’s no CA, the EFS component will issue a self signed certificate to each user the first time the user requests to encrypt a file. There are, however, some advantages to using a CA to create EFS certificates, if you’re in a high-security or enterprise environment. It allows the network administrator to manage the certificates centrally, and using certificate services, you can revoke certificates and specify the length of time certificates are valid. It’s also possible to set up computers as dedicated recovery computers and issue specific recovery certificates to them, instead of issuing the recovery certificate to the domain controller.

In a domain environment, a recovery policy is normally defined at the domain controller, and, by default, the domain administrator is the designated recovery agent. A recovery agent is issued a special recovery agent certificate that allows for decrypting files that were encrypted by other users. There must be at least one recovery key configured on the system; otherwise, no one will be able to encrypt files. When you try, you will get an error message.

When considering an EFS implementation as a part of your overall security infrastructure, also consider implementing roaming profiles. EFS works by using sets of public and private certificates. The certificate for the currently logged in user is used to encrypt the file and access to this certificate is required for successful decryption.

When running in an environment without roaming profiles, if a user encrypts files using different client computers, he or she will be unable to access the files from other systems. For example, if the user encrypts a file on the server named file1 from the system Vista1, and he encrypts a file named file2 from Vista2, the user will be unable to access file2 from Vista1 and vice versa. This could quickly become a significant problem for an organization.

When roaming profiles are used, users don’t experience such problems. Because the certificate is stored with the central profile, the same certificate will always be used for encryption regardless of which machine the user accesses.

[rsslist:http://ah.pricegrabber.com/export_feeds.php?pid=hjehfab&document_type=rss&limit=25&topcat_id=all&category=topcat:all&col_description=1&form_keyword=vista]

EFS is primarily intended to protect the file system on a computer that is not physically secure. For example, a server kept behind locked doors that has no removable storage devices is not a likely candidate for EFS, as someone would have to break into your server room, remove the drive(s), and get out without being caught if they wanted to steal the information on the drives (assuming you’ve protected the data adequately from network-borne attacks.) However, systems that are physically insecure are a candidate for EFS.

For example, any notebook that contains company-sensitive data should use encryption to protect its contents. Consider the thefts in recent years of notebook computers-many of which contained sensitive information-from government employees in public airports and even government offices, and you can appreciate the need to protect your own portable data.

Protecting notebooks is just one use for EFS. Desktop systems that are publicly accessible, such as those in public offices, courtrooms, government offices, and other locations where the public has access to systems and where the systems contain sensitive or private information, should be protected by EFS to prevent data theft and the potential embarrassment, legal trouble, or even loss of business that could ensue. In the server realm, removable storage devices such as Storage Area Network (SAN) devices that contain sensitive data should be protected through encryption. It only takes one unscrupulous or disgruntled employee to hand a drive over to your competition to destroy your company.

Encrypting individual files is certainly a start, but that doesn’t really provide the level of security you might need. Applications typically create temporary files containing at least portions of a document, and if these files are not protected by encryption, they pose a security risk. So, rather than look to solutions that provide file-by-file encryption or encrypting individual files with EFS, you need a solution that can automatically encrypt and decrypt files in an entire folder or volume. EFS does just that.

So how do these two technologies work together? EFS comes into play after Windows boots up, while BitLocker works before Windows and seamlessly operates beneath the operating system. EFS works on the file system level and encrypts at the file level based on user permissions and PKI-protected session keys; BitLocker is a low-level mechanism that encrypts an entire volume and is oblivious to the concept of users and PKI. This means that EFS offers high-level manageability, while BitLocker operates at a low level without the manageability features–but it can protect those spots EFS can’t. Files encrypted by EFS can’t be cracked, although the filename and directory structure is not protected. The Windows partition encrypted by BitLocker is completely scrambled so you can’t even tell what the filename and directory structure is.

[rsslist:http://rss.api.ebay.com/ws/rssapi?FeedName=SearchResults&siteId=0&language=en-US&output=RSS20&catref=C5&sacur=0&from=R6&saobfmts=exsif&fts=2&dfsp=1&saslc=0&floc=1&sabfmts=0&saaff=afcj&ftrv=1&ftrt=1&fcl=3&frpp=25&afcj=471546&satitle=bitlocker&saslop=1&sacat=-1&fss=0]

Setting proper permissions is a good place to start when securing your Vista workstation, but you can go one-step further by encrypting files on your workstation. Encryption provides another layer of protection for information that must be kept private. Vista includes two encryption technologies, Encrypting File System (EFS) and the new Bitlocker, that when used together, provide a high level of storage security.

Bitlocker Drive Encryption is new in Vista. It is designed to protect a computer against data theft by encrypting the entire Windows volume. It ensures that your data remains encrypted, even if the computer is tampered with. For example, if a malicious user moves the hard drive to another computer, he or she will not be able to view the contents of it.

Beginning with Windows 2000, Microsoft built encryption capabilities into the operating system, and the encryption functionality has been improved in Vista. Microsoft’s EFS gives you the ability to encrypt data at the file or folder level.

EFS is a technology by which the files on the NTFS partition are encrypted to protect against unauthorized access. While share and NTFS permissions can be used to handle this task over the network, these permissions don’t protect the data in the event that someone has physical access to the server or workstation.

[awsbullet:encryption]