You are running an Active Directory Domain with Domain Members where you want to use Bitlocker to secure local data stores. You want the members to publish their recovery information to Active Directory and set the policies accordingly, and don't allow encryption when publishing the recovery information to Active Directory fails.
When starting the encryption, the wizard displays an error "Server is unwilling to perform" and stops.
You see that there is no msFVE-RecoveryInformation object created under the computer account, and also the volume is not encrypted.
The "Bitlocker Drive Encryption Service" (BDESVC) builds the server information with an explicit reference to the Domain Controller IP address. This is done to avoid a problem when Bitlocker is used on Domain Controllers. A side-effect of this approach is that only NTLM can be used to authenticate with the Domain Controller when publishing the recovery information.
In Windows Server 2008 R2 Security Group Policy Admin Tools, you can set policies on the NTLM behavior for processes running as LocalSystem in the Security Option "Network security: Allow Local System to use computer identity for NTLM". This affects BDESVC as well. Since this setting "UseMachineID" is now also available on Windows Vista and Server 2008, these operating systems might also affected by this problem.
When the policy is set to "Disabled", NTLM authentication as computer account is not allowed and thus authenticating with the Domain Controller fails. The error "LDAP_UNWILLING_TO_PERFORM" is returned by the LDAP client when it sees that the signing of traffic (Default of LdapClientIntegrity=1) is not possible as the session has to fall back to anonymous where you don't have key material for signing of traffic.
This is just the first error encountered by the LDAP client, later on the session would fail as the DC does not accept any request over an anonymous session by default.
Customers might want to restrict the use of NTLM in their environment as they try to get their authentication to work over Kerberos which they consider more secure than NTLM. The security level of NTLM is largely governed by the LmCompatibilityLevel setting where NTLMv2 offers pretty good security.
So the use of NTLMv2 is not a security issue. This only becomes an issue if legacy systems in your network force you to use a low value for LmCompatibilityLevel.
- Fix that makes UseMachineId available on Windows Vista and Server 2008:
972069 A terminal server that is running Windows Server 2008 cannot obtain terminal licenses from a Terminal Server license server that is running Windows Server 2008 after you enable the "License Server Security Group" Group Policy setting