Utilisateurs et permissions dans Windows Server

Votre machine est livrée avec un seul compte administrateur. Travailler sous celui-ci en permanence est une mauvaise habitude : la moindre erreur ou un fichier malveillant obtient immédiatement un contrôle total. Séparez les rôles dès le départ.

Créer un utilisateur

$pw = Read-Host -AsSecureString "Password"
New-LocalUser -Name "app" -Password $pw -FullName "Application Service" -PasswordNeverExpires
Add-LocalGroupMember -Group "Users" -Member "app"

Autorisez-le à se connecter via le Bureau à distance :

Add-LocalGroupMember -Group "Remote Desktop Users" -Member "app"

Sur une image en anglais, les groupes s'appellent Users et Remote Desktop Users. Une option universelle consiste à les référencer par identifiant : Get-LocalGroup | Where-Object SID -like "*-555" pour le groupe RDP.

Pour voir qui est sur la machine et qui appartient aux administrateurs :

Get-LocalUser | Select-Object Name, Enabled, LastLogon
Get-LocalGroupMember Administrators

Permissions des dossiers

Accordez l'accès aux répertoires plutôt que l'appartenance au groupe des administrateurs. Exemple : donnez à l'utilisateur app un accès complet à son propre répertoire et un accès en lecture seule au répertoire partagé.

icacls "C:\apps\myapp" /grant "app:(OI)(CI)M" /T
icacls "C:\shared" /grant "app:(OI)(CI)R" /T
icacls "C:\apps\myapp"          # view current permissions

Décodage : M — modification, R — lecture, F — contrôle total, (OI)(CI) — héritage vers les fichiers et sous-dossiers, /T — appliquer au contenu existant.

Comptes de service

Un service qui accède à Internet ou traite des fichiers téléversés ne doit pas s'exécuter en tant que LocalSystem. La meilleure option est un compte géré :

New-Service -Name myapp -BinaryPathName "C:\apps\myapp\myapp.exe" -StartupType Automatic
sc.exe config myapp obj= "NT SERVICE\myapp" password= ""

Plus simples et presque aussi sûrs, les comptes intégrés NT AUTHORITY\LocalService et NT AUTHORITY\NetworkService avec des permissions accordées uniquement aux répertoires dont ils ont besoin.

Politique de mots de passe

net accounts /minpwlen:14 /maxpwage:unlimited
net accounts /lockoutthreshold:5 /lockoutduration:30

Le verrouillage après cinq tentatives échouées est particulièrement important si le RDP est accessible depuis l'extérieur — consultez Protection RDP pour plus de détails.

Erreurs courantes

• Travailler en administrateur en permanence. Créez un compte ordinaire pour vous-même et élevez vos droits uniquement là où c'est nécessaire.
• Ajouter un utilisateur au groupe des administrateurs pour que « ça marche tout simplement ». Neuf fois sur dix, ce dont vous avez réellement besoin, c'est d'un accès à un seul dossier ou du droit « Ouvrir une session en tant que service » (secpol.msc → Stratégies locales → Attribution des droits utilisateur).
• Désactiver l'administrateur intégré sans vérifier une seconde connexion. Assurez-vous d'abord que le nouveau compte peut réellement se connecter via RDP, et seulement ensuite exécutez : Disable-LocalUser -Name adm-local.
• Stocker un mot de passe de service en clair dans un script. Les scripts situés dans des répertoires où les utilisateurs peuvent écrire sont lisibles par n'importe qui.

Si vous avez verrouillé tous les comptes, vous pouvez toujours obtenir l'accès via l'onglet « Console » du panneau à l'adresse /hosting/vds/m/<id> en mode « Screen ». Le mot de passe administrateur délivré à la création est toujours disponible dans l'onglet « Accès ».