Sommaire
Ces derniers jours, je me suis un peu acharné à remettre en service un serveur dont les droits avaient sauté un peu partout suite à un hardening un peu « poussé »… En dernier lieu, il a également fallu remettre en service WSUS. Cela m’a demandé pas mal de patience mais m’a permis d’en apprendre beaucoup plus sur les droits nécessaires pour que le service fonctionne. Si donc vous avez ce beau message sur la console d’administration :
Alors ce guide devrait vous aider à remettre le tout en ordre… Attention, on fonctionne avec une base de données interne Windows.
Les services
Comme tout bon rôle, celui s’appuie sur plusieurs services Windows pour assurer son bon fonctionnement. Ils doivent être configurés comme ci-dessous :
- Base de données interne Windows
- Démarrage : automatique
- Ouverture de session : NT SERVICE\MSSQL$MICROSOFT##WID
- Service WSUS
- Démarrage : automatique
- Ouverture de session : Service réseau
- Service de publication World Wide Web
- Démarrage : automatique
- Ouverture de session : Système local
- Service d’administration IIS
- Démarrage : automatique
- Ouverture de session : Système local
- Editeur VSS de base de données interne Windows
- Démarrage : manuel
- Ouverture de session : Service local
Deux d’entre eux sont essentiels : la Base de Données Interne Windows qui contient toute la configuration et le Service WSUS qui permet la synchronisation avec le serveur central Microsoft (ou un serveur maître). Bien sûr, vous ne pouvez pas vous passer d’IIS, celui-ci étant le socle même du fonctionnement de WSUS. Si l’un de ces deux services est arrêté, vous obtiendrez le message d’erreur.
World Wide Web & WSUS
Les services Web de WSUS doivent être configurés comme ci-dessous :
- ClientWebService
- Directory: %ProgramFiles%\Update Services\WebServices\ClientWebService
- Application Pool: WsusPool
- Security: Anonymous Access Enabled
- Execute Permissions: Scripts Only
- Content
- Directory[the location of the WSUS content directory]
- Security: Anonymous Access Enabled
- Execute Permissions: None
- DssAuthWebService
- Directory: %ProgramFiles%\Update Services\WebServices\DssAuthWebService
- Application Pool: WsusPool
- Security: Anonymous Access Enabled
- Execute Permissions: Scripts Only
- Inventory
- Directory: %ProgramFiles%\Update Services\ Inventory
- Application Pool: WsusPool
- Security: Anonymous Access Enabled
- Execute Permissions: Scripts Only
- ReportingWebService
- Directory: %ProgramFiles%\Update Services\WebServices\ReportingWebService
- Application Pool: WsusPool
- Security: Anonymous Access Enabled
- Execute Permissions: Scripts Only
- ServerSyncWebService
- Directory: %ProgramFiles%\Update Services\WebServices\ServerSyncWebService
- Application Pool: WsusPool
- Security: Anonymous Access Enabled
- Execute Permissions: Scripts Only
- SimpleAuthWebService
- Directory: %ProgramFiles%\Update Services\WebServicesSimpleAuthWebService
- Application Pool: WsusPool
- Security: Anonymous Access Enabled
- Execute Permissions: Scripts Only
- ApiRemoting30
- Directory: %ProgramFiles%\Update Services\Administration
- Application Pool: WsusPool
- Security: Integrated Windows Authentication, Digest Authentication
- Execute Permissions: Scripts Only
- SelfUpdate
- Directory: %ProgramFiles%\Update Services\SelfUpdate
- Security: Anonymous Access Enabled
- Execute Permissions: Scripts Only
Vous pouvez trouver plus d’informations ici : https://technet.microsoft.com/fr-fr/library/dd939903(v=ws.10).aspx (en anglais toutefois).
Le dossier Update Service
WSUS est déployé par défaut dans C:\Program Files\Update Services :
Iil faut veiller à ce que le service Web puisse utiliser correctement les ressources. Voici les permissions que vous devez avoir (WSUSInstallDir correspond au dossier d’installation de WSUS):
Dossiers web :
WSUSInstallDir\WebServicesapiremoting30
WSUSInstallDir\WebServicesclientwebservice
WSUSInstallDir\WebServicesdssauthwebservice
WSUSInstallDir\WebServicesreportingwebservice
WSUSInstallDir\WebServicesserversyncwebservice
WSUSInstallDir\WebServicessimpleauthwebservice
WSUSInstallDir\Inventory
Permissions pour ces dossiers :
Services Réseau (Lecture/Exécution), Utilisateurs (Lecture/Exécution), Utilisateurs authentifiés (Lecture/Exécution), Administrateurs (Contrôle total), Système (Contrôle total)
Dossier SelfUpdate :
WSUSInstallDir\Selfupdate
Permissions SelfUpdate :
Utilisateurs (Lecture/Exécution), Administrateurs (Contrôle total), Système (Contrôle total)
Base de registre
La base de registre doit également avoir les droits positionnés comme ci-dessous (à minima) :
| HKLM\Software\Microsoft\Update Services\Server | WSUS Reporters (accès en lecture)Utilisateurs (accès en lecture) |
| HKLM\Software\Microsoft\Update Services\Server\Setup | Service Réseau (Contrôle total)WSUS administrators (Contrôle total)
Administrateurs (Contrôle total) Système (Contrôle total) |
La base de données interne Windows
Enfin, la base de données interne est située ici : C:\Windows\WID
Le dossier DATA contient les fichiers de la base de données : il faut impérativement que NT SERVICE\MSSQL$MICROSOFT##WID puisse y accéder en lecture/écriture !
Si vous étiez donc face à un problème de sécurité, ce devrait maintenant être résolu. À bientôt !
@micalement, Loïc.
Article utile et intéressant si on rencontre un problème de ce type. Merci
Moi je me suis acharné sur les postes qui n’envoient pas leurs rapports, n’apparaissent pas dans la console ou avec la jolie croix rouge pour les erreurs d’installation des mises à jour sur les postes.
J’ai donc fait ce petit script en powershell à mettre dans une GPO. C’est simple, mais très pratique.
$path = “c:windowsSoftwareDistribution”
Stop-Service wuauserv
Push-Location
Set-Location -Path “HKLM:SOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdate”
Remove-ItemProperty . -Name SUSclientid
Remove-ItemProperty . -Name SusClientIdValidation
Remove-ItemProperty . -Name PingID
Remove-ItemProperty . -Name AccountDomainSid
Pop-Location
Remove-Item -path $path -force -recurse
Start-Service wuauserv
Invoke-Command {wuauclt.exe /resetauthorization /detectnow}
Votre solution consiste à recréer le lien entre le serveur WSUS et le client. C’est un peu brutal mais efficace 🙂
Avez-vous pensé à regarder le contenu de WindowsUpdate.log ? souvent, les erreurs indiquées permettent de comprendre l’origine du problème.
Exemple ici : http://www.metsys.fr/blog/?p=285
@micalement, Loïc.
LOL oui on dira que je suis adepte de l’efficacité.Merci pour le lien.Vos procédures sont très bien documentés.Je connaissais le fichier de log mais je dois gérer beaucoup trop de choses et pas toujours le temps de vérifier chaque erreurs poste par poste.Je trouve un problème et j’automatise la solution.Avec le script je ne me soucis plus de wsus.