More Fun With Check Name
I just closed a case where the customer was trying to create a profile but Check Name was constantly prompting for credentials and then failing. This wasn’t the reconfig issue I mentioned before – they couldn’t create the profile in the first place. Even GCReconnect showed the same behavior – repeated prompts for credentials, then failure, with the error MAPI_E_USER_CANCEL. We took a network trace of the attempt to create the profile to see where the failure came from. The trace showed us attempting to set up NTLM authentication, sending the request to the Exchange server. Exchange passed the packet on the the GC, which promptly returned 0x721: RPC_S_SEC_PKG_ERROR.
This is a common error to get when attempting to use Kerberos authentication. Configuring Kerberos at times can be tricky, and if it’s not all set up right, this is the error you expect to get. One workaround usually given is to make sure NTLM is set up and fall back to NTLM when Kerberos doesn’t work. However, in this case, we were trying NTLM in the first place!
After some poking around, we took a look at the local policy settings on the three machines. Here’s what we found:
Client
Network security: Minimum session security for NTLM SSP based (including secure RPC) clients- Not defined
Network security: Minimum session security for NTLM SSP based (including secure RPC) servers- Not defined
Exchange
Network security: Minimum session security for NTLM SSP based (including secure RPC) clients- Require NTLMv2 session security, Require 128-bit encryption
Network security: Minimum session security for NTLM SSP based (including secure RPC) servers- Require NTLMv2 session security, Require 128-bit encryption
GC
Network security: Minimum session security for NTLM SSP based (including secure RPC) clients- Require NTLMv2 session security, Require 128-bit encryption
Network security: Minimum session security for NTLM SSP based (including secure RPC) servers- Require NTLMv2 session security, Require 128-bit encryption
Since the client was not configured to use NTLMv2, it tried to authenticate with NTLMv1. Since the server required NTLMv2, it rejected the request, with the appropriate error message: RPC_S_SEC_PKG_ERROR. Once the customer configured the policy on the client (it had just been overlooked during setup), they were able to complete profile configuration.