Share via

SCCM Mixed Mode client approval process and troubleshooting

  • Article

This article is intended to describe how client approval works when the Management Point is configured in NLB, the site is in Mixed Mode and is configured to automatically approve every client in the trusted domain.

When the site has more than one Management Point, they need to be configured in an NLB Cluster. If the site in mixed mode, running the IIS Web Site application pool for the site system Web site, using the local system account of the site system computer, does not allow clients to authenticate the site system using Kerberos authentication. In such case a domain user account must be configured to run the IIS Web site application pool for the systems. To use Kerberos you need to configure a service principal name (SPN) for the management point clustered site system name configured in NLB on the domain user account configured to run the application pool.

To do so you create an account inside the Domain and set on it the principal name for the cluster using the command setspn –A HTTP/<NLB Cluster Name FQDN> domainName\userName (for step-by-step instruction refer to the technet link https://technet.microsoft.com/en-us/library/bb735879.aspx)

Once the SPN has been registered, use the account to run the application pool and make it member of the local Administrators Group and IIS_IUSRS Group on each Management Point.

To configure the user account to run the application pool, open IIS and expand the Application Pools. Right click the CCM Windows Auth Server Framework Pool and in the Advanced Settings configure the Identity to run with the specified account rather than the LocalService ; enter its password and finish the configuration.

image image

To ensure that the authorization works as planned, open the applicationhost.conf (c:\windows\system32\inetsrv\config\) and Locate the website you wish to configure. Search something like <windowsAuthentication enabled="true" useKernelMode="true" /> and change it to include useAppPoolCredentials="true": <windowsAuthentication enabled="true" useKernelMode="true" useAppPoolCredentials="true" />. At the end restart IIS.

The approval process works, in a short version, like this:

1. Right after the client SCCM installs the new client performs a CCM_POST to CCM_System_WindowsAuth on the MP;

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

3. At this point the client requests a Kerberos thicket for https://managementPointFqdn;

4. After obtaining the Kerberos thicket , the client performs another CCM_POST including the security data;

5. If the Management Point accepts the ticket, than the client is authenticated and is consider to be trusted;

6. Whether the client is trusted or not, the Management Point execute the spUpdateClientRegistration stored procedure to update the database. If the client has authenticated, both the @ApprovalMethod and @IsIntegratedAuth parameters will be set to 1, otherwise to 0.

The first place to check for errors is the IIS logs at %systemdrive%\Inetpub\Logs\LogFiles\W3SVC1\. Here you have to look for these lines that indicate unauthorized access.

These lines contain:

CCM_POST /ccm_system_windowsauth/request - <http port number> - <IP Address> ccmhttp 401 2 2148074254

If you find 2 consecutive lines recording di 401 then the process cannot authenticate the request, otherwise you should find a single line with the 401 following with a new line indicating the code 200: CCM_POST /ccm_system_windowsauth/request - <http port number> - <Domain\ComputerName$> <IP Address> ccmhttp 200 0 0 (the code 200 stands for authenticated).

To check why the authentication fails you can run a network trace, with Network Monitor, for the entire process, starting from the client installation to client refuse. In the trace, search for the KerberosV5 protocols and the lines after that. This should explain the possible cause.

One of the simplest reason the authentication fails may be the SPN not registered or the DNS not resolving the name. Also check if the time skew is in the 5 min limit, otherwise Kerberos will fail. If all these are correct then check the applicationhost.conf file as explained early (some time it is the only resolution).