How It Works: Automatic Client Approval in Configuration Manager 2007

This post is intended to explain how client approval works when a Mixed Mode Configuration Manager 2007 site is configured to automatically approve clients in trusted domains and to offer insight into how to troubleshoot scenarios where this is not working as expected. The configuration is shown below:

The short version:

The new client performs a CCM_POST to CCM_System_WindowsAuth on the MP.

The MP responds with a 401 as the request is anonymous and contains no security data.

On obtaining the Kerberos ticket, the client performs another CCM_POST including the security data.

If the MP accepts the ticket then the client is authenticated and is considered to be trusted.

Whether the client is trusted or not, the MP executes the spUpdateClientRegistration stored procedure to update the database. If the client has authenticated properly, both the @ApprovalMethod and @IsIntegratedAuth parameters will be set to 1. If not, they are both set to 0.

Technical details:

The following is from data obtained in my lab during a successful test where a client in a child domain (Child.A2003.VM.local) was automatically approved by the MP in Child’s parent domain (A2003.VM.local). Relevant details:

If the client is re-inserted into the database as not approved then collect the network capture (and all relevant IP details) with the IIS log and MP_RegistrationManager.log from the MP to which the client reports directly for review.

If the network capture shows the client does get a Kerberos ticket then the IIS log should contain a Win32 error code indicating why the MP rejected it.

If the client does not get a ticket then the response from the DC in the capture should detail why. Kerberos logging on the client, per KB262177, may add some useful information to the System Log in Event Viewer as well. Since Directory Services supports Kerberos, they may be engaged for assistance in determining why no ticket was acquired.

Note: The MP_RegistrationManager.log does not contain much detail by default. Enabling Verbose and Debug CCM logging will add some extra entries which may be helpful.

Known reasons why this will fail:

Duplicate GUIDs: Duplicate GUIDs can cause a myriad of client data integrity problems including client approval issues. If only a subset of the clients are impacted by the client approval failure then duplicate GUIDs should be investigated.

The HTTP SPN is registered under a user account: Normally, there is no HTTP SPN for a server so the HOST SPN, which should always be on the computer object, is used in obtaining the Kerberos ticket. If web based services, such as SQL Reporting Services, are running under user context on the MP, and the HTTP SPN is linked to that user account, the Kerberos ticket obtained by the client will be for the same user. When presented to the MP, which runs as Local Service (System), it is rejected because it is linked to the wrong user.

The solution for this is to delete the HTTP SPN from the user object, move the web service running as the user to a different web site using a different port and create a new HTTP SPN to refer to the new port. For example, for a new web site using TCP port 81, the new HTTP SPN, created under the user object in AD, would be similar to:

SPNs are only created for the HOST service and all built-in services use the HOST SPN. However, this implementation is transparent because built-in names act as an alias to the HOST service unless they have been specifically mapped to a Windows account.

And also:

When you use Windows Integrated Security, both Internet Explorer and IIS use the HTTP SPN to request service tickets and to process a request. As a result, when you use a domain user account in IIS 6.0 as the process identity, you must map the host-based HTTP SPN to the domain account that is used by the service.

Client and MP in different domains only share an external trust:

As is noted above, Kerberos is required for the client to authenticate to the MP. While Kerberos *may* work across an external domain trust, it is not supported. It is only supported across a forest trust between two Windows Server 2003 mode (or higher) forests.

When two Windows Server 2003 forests are connected by a forest trust, authentication requests made using the Kerberos V5 or NTLM protocols can be routed between forests to provide access to resources in both forests.

Anything else that causes Kerberos to fail:

Kerberos can fail for many reasons including time skews in the environment; DNS name resolution failures, etc. Generally, network capture data will show why it is failing though Kerberos logging per KB262177 can also be helpful.