Cette semaine j’ai été soumis à un très gros problème sur le fonctionnement d’une architecture System Center Configuration Manager 2007 quasi neuve ! Pour résumer le problème, les clients qui étaient installés, n’étaient jamais approuvé par le serveur. Le serveur lui-même affichait un simple « Not Approved ». Mon premier réflexe a été de modifié la méthode d’approbation vers « Automatically approve all computers » pour voir si les clients suivants allaient être approuvé. Ce fut le cas. En chercheant un peu, notamment dans le log MP_Registration.log, je suis tombé sur le message : « MP Reg : Failed to get client (GUID : ***) public key : 0x80040238 ».
En cherchant sur Internet, j’ai trouvé un post de Wally sur le forum Technet traitant du même problème. Il expliquait qu’une désinstallation du serveur Web IIS et du Management Point résoudrait cette erreur… (Petites bouffées de chaleur…)
J’ai donc repris un post de l’équipe SCCM pour tenter de débuguer le mécanisme d’approbation. J’ai ainsi commencé à ouvrir l’application Network Monitor pour voir si le client recevait bien le ticket Kerberos qu’il avait demandé au contrôleur de domaine.
Voilà en gros les étapes qui constituent l’approbation d’un client par Active Directory :
1. Le nouveau client opère une requête CCM_POST à CCM_System_WindowsAuth sur le Management Point.
2. Le Management Point répond avec un code 401 comme une requête anonyme et ne contenant aucune donnée de sécurité.
3. Le client effectue une demande de ticket Kerberos pour l’adresse http://MP_FQDN à Active Directory (c’est à dire http://SCCMMP.Contoso.com).
4. Lorsqu’il obtient le ticket Kerberos, le client effectue une nouvelle requête CCM_POST qui inclut les données de sécurité.
5. Si le MP accepte le ticket alors le client est authentifié et considéré comme sûr.
Je vous renvoie vers ce très bon article qui explique très très bien le processus : http://blogs.technet.com/b/configurationmgr/archive/2010/01/20/how-it-works-automatic-client-approval-in-configuration-manager-2007.aspx
Pour revenir à mon problème, il s’avère que chaque site web IIS dispose de fournisseurs d’authentification. L’authentification Windows dispose notamment du fournisseur NTLM et Negotiate. Le fournisseur Negotiate est un prérequis à l’approbation automatique par Active Directory.
C’est lui qui permet au serveur d’accepté les requêtes du client contenant le ticket Kerberos.
Il s’avère que dans mon infrastructure, ce fournisseur avait été écrasé à l’aide du script adsutil.
Pour remettre le fournisseur sur l’authentification Windows, vous pouvez utiliser la console d’administration IIS si vous utilisez IIS 7.5 :
Sinon utilisez les outils de script IIS et notamment le script adsutil :
« cscript adsutil.vbs set w3svc/NTAuthenticationProviders "Negotiate, NTLM" ”
