微软产品支持分析电子月刊 : Active Directory

使用组策略软件安装程序安装Office 2007

Support News Editor — Wed, 23 May 2007 05:52:00 GMT

The Office team published a great “how to” on installing Office 2007 using Group Policy. The Office 2007 Resource Kit includes this documentation. You can view it online at the Microsoft TechNet site. Here’s a direct link

http://technet2.microsoft.com/Office/en-us/library/efd0ee45-9605-42d3-9798-3b698fff3e081033.mspx?mfr=true

访问被拒绝, 以及其他访问其他Vista客户端SMB共享失败

Support News Editor — Wed, 23 May 2007 05:51:00 GMT

Some of the fun we have in product support is that, once a new product is released nowadays, we get to navigate the uncharted waters of new security settings interoperating with our customers’ real world environments.

With Windows XP and Server 2003 we saw that there were challenges brought about by the SMB signing, and LMCompatibility level security settings. SMB Signing is a way of guaranteeing the originator of the traffic since it is signed by that node. LMCompatibility, put simply, is a way of telling your computer to not use less than a certain version of NTLM authentication since older versions are less secure.

Both of these are good things from a security perspective. Frankly, if they are disabled or lessened, then your systems are less secure.

But in the real world there are plenty of people who have old computers (Windows 9x, NT) that may not be compliant with enhanced security. These types of things are may not always be disseminated well at a product’s release and we are forced to play catch up. If you saw my post regarding TCP Auto-Tuning a few months ago then you’ve heard this tune before.

LM Compatibility level is a way of setting your Windows computer to use only a specified level of LanMan authentication (NTLM). This is done via a registry value which is noticed by the LSA at boot:

hklm\system\currentcontrolset\control\lsa

Why am I bothering to post about this “old hat” stuff? Well, Vista defaults to LMcompatibliltylevel = 3. This is more secure, but can cause problems with other products that do not interoperate smoothly with some of the more secure mechanisms. Some Unix based network file sharing devices, for example. In fact, if you have an account lockout policy specified, you could end up locking out your user account if you ran into this when trying to connect to a file share on such a device.

Please check if the below symptom happens based on our support experience:

- Your problem occurs only when connecting to the resource from a Vista client, but may not occur from other operating systems

-You do not specify a custom LMcompatibliltylevel setting in any of your group policies

-Doesn’t necessarily have to be a network file sharing device back end…but more likely to be.

-Network traffic will appear similar to that below (SMB negotiation details excepted for brevity):

No. Time Source Destination Protocol Info

152 07:48:17.447552 34.52.40.213 34.224.36.2 SMB Negotiate Protocol Request

153 07:48:17.449232 34.224.36.2 34.52.40.213 SMB Negotiate Protocol Response

164 07:48:17.458380 34.52.40.213 34.224.36.2 SMB Session Setup AndX Request, User: DOMAIN\user1; Tree Connect AndX, Path: \\LOCALFILESVR\IPC$

182 07:48:20.410098 34.224.36.2 34.52.40.213 SMB Session Setup AndX Response, Error: STATUS_LOGON_FAILURE

How can you work around this behavior? Well, the best way would be to bring the same minimum level of security to all devices involved. This can be a difficult thing to do when you are stuck with inherited infrastructure and a limited budget.

If you can’t have all devices meet that minimum security then you will be forced to allow less secure authentication in order to get your business flowing. To do that, lower the LMcompatibliltylevel to a lower number that the other device can handle. Then reboot for that to take effect.

Here’s a link article that goes into good detail about NTLM authentication and what the LMcompatibliltylevel setting does:

http://www.microsoft.com/technet/technetmag/issues/2006/08/SecurityWatch/?related=/technet/technetmag/issues/2006/08/SecurityWatch

如何修复EFS文件

Support News Editor — Wed, 23 May 2007 05:50:00 GMT

Windows XP and Windows Server 2003 provide many enhancements in the area of data protection— especially Encrypting File System (EFS). This article provides some common issues and file recovery practices to prevent encrypted files being inaccessible.

We often encounter problems when accessing encrypted files. For example, not able to access the data and getting permissions denied. To prevent EFS related issues, it is necessary to be aware of some common problems before you make any changes to an EFS environment.

Here we first list some common issues when trying to access an encrypted file:

a. Cannot access files after disjoining or joining a domain

When joining a computer to a domain that has EFS encrypted files, move keys from local account profile to new domain account profile for EFS access.

b. Cannot decrypt EFS files after resetting a password

Change the user’s password back to what it was before the reset.

c. Cannot access remote EFS encrypted files from Windows 9x or Windows NT 4.0 clients

By design the server blocks Pre-windows 2000 machines from opening a remote encrypted file.

d. Access Denied error attempting to access EFS encrypted files

Locate the private key for the appropriate certificate and import it onto this computer using the Certificates snap-in. We recommend that you back up the recovery certificate (*.CER) and the private key files (*.PFX) to a safe location.

In addition, before we implement EFS, it is necessary to designate other users or recovery agents in case there are problems with the original user who encrypt the file. The following users can access the encrypted file.

1. The original user who encrypts the file

2. Users being added to give cryptographic access to that file.

Cryptographic access means the users are able to decrypt and encrypt the file, as well as add and remove other users. To add users to a file gives them cryptographic access to that file:

e. Right click on the folder or file, click Properties

f. Click Advanced. Click to check “Encrypt contents to secure data”

g. Click on the Details button brings up the Encryption Details dialog.

h. Add users to transparently access the file

3. Recovery Agents.

The Recovery Agent is optional on Windows XP Professional and Windows Server 2003 in order to provide organizations with greater flexibility in implementing data recovery strategies. The domain Administrator is the default recovery agent. To assign a Data Recovery Agent:

i. Logon to a computer with the account that you are going to be using for the EFS recovery agent.

j. Run MMC.exe and load Certificates for the current User.

k. Right click on the Personal Store. Click All Tasks, click Request New Certificate…

l. Chose the Recovery agent Certificate

m. Once you have the Recovery agent Cert. Export the Cert (without the private key to a .Cer file)

n. Copy the Cert to a DC

o. Open Active Directory Users and Computers. Edit your Default Domain Policy

p. Under Computer Configuration\Windows Settings Security Settings\Public Key Policies

q. Right Click on Encrypting File System and click on Add a recovery agent

r. Choose Folders. Browse to the .CER file and finish the wizard.

s. This will add the Recovery agent to all machines once Group Policy processing is done

The next time a new file is encrypted it will add the recovery agent to that file.

To recover an encrypted file or folder if you are a designated recovery agent:

a. Use Backup or another backup tool to restore a user's backup version of the encrypted file or folder to the computer where your file recovery certificate and recovery key are located.

b. Open Windows Explorer.

c. Right-click the file or folder and then click Properties.

d. On the General tab, click Advanced.

e. Clear the Encrypt contents to secure data check box.

f. Make a backup version of the decrypted file or folder and return the backup version to the user.