Gérer Windows Server Update Services c’est bien, mais on n’a pas toujours envie de se connecter à un ou plusieurs serveurs pour le faire. Et si on troquait l’interface graphique pour Powershell ?
I- Les prérequis
- Depuis un poste client en Windows 7 :
Pour un poste en Windows 7 il faut installer le RSAT "Windows Server Update Services 3.0 SP2" disponible ici:
https://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=5216
- Depuis un serveur en Windows Server 2012 R2 :
Pour un serveur en Windows Server 2012 R2 il faut installer la fonctionnalité "Windows Server Update Services Tools"
II - Connexion au Serveur WSUS
Pour se connecter il va falloir déterminer 3 variables:
- Le nom du serveur WSUS
- L'utilisation ou non du SSL ($true ou $false)
- Le port de connexion (8530, 8531, 80 ou 443)
Dans l'exemple que j'utilise je me connecterai sur le port 8530 sans SSL, d'où la présence du $false.
$WsusServer = "Mon-Server-WSUS"
$WsusPort = "8530"
[void][reflection.assembly]::loadwithpartialname("microsoft.updateservices.administration")
$Wsus = [microsoft.updateservices.administration.adminproxy]::getupdateserver($WsusServer,$false,$WsusPort)
Avec ces 4 lignes vous êtes connecté au serveur WSUS, pour le vérifier rien de plus simple, appelez $Wsus
III - Cmdlet disponibles
Pour déterminer les actions possibles sur le serveur regardons les cmdlet disponibles, pour cela utilisons :
$Wsus | gm
Comme vous pouvez le voir nous avons un grand nombre d'actions possibles.
Dans la prochaine partie nous verrons les informations que nous pouvons récolter avec quelques lignes de commandes.
Bien souvent, en entreprise on se retrouve avec des dossiers contenant des fichiers *.ini d'installation ou autres avec des mots de passe stockés en claire. Prenons, le cas des installations SQL , le DBA enregistre les mots de passe dans un fichier de paramètre et ne pense pas à le supprimer. Les mots de passe en claire posent un problème de sécurité au SI. Le script en powershell ci-dessous permettrait de remplacer tous les mots de passes en claire par des étoiles (**********).
#############################################
#Author: KARUPPANNAN Seevadassen #
#Date: 27/03/2017 #
#############################################
$networkPath = "\\chemin\dossier\"
$iniS = Get-ChildItem -Path $networkPath -Filter *.ini -Recurse
foreach ($file in $iniS) {
$fileName = $file.Name
$filePath = $file.FullName
Write-Host "File name: " $fileName -ForegroundColor yellow
Write-Host "Full path: " $filePath -ForegroundColor yellow
$array = $filePath.split("\")
$server = $array[8]
Write-Host "Server: " $server
$password = Get-Content $filePath | Where-Object { $_.Contains("SAPWD") -or $_.Contains("SQLSVCPASSWORD") -or $_.Contains("AGTSVCPASSWORD") -or $_.Contains("FTSVCPASSWORD") -or $_.Contains("ISSVCPASSWORD") -or $_.Contains("ASSVCPASSWORD") -or $_.Contains("RSSVCPASSWORD") -or $_.Contains("FARMPASSWORD")}
Write-Host $password
Write-Host $password.GetType()
foreach ($line in $password){
$row = $server + ";" + $line
Write-Host "row value: " $row -ForegroundColor Green
Write-Host "line: " $line
$param1,$param2 = $line.split('=')
Write-Host "partie1: " $param1
$replacetxt = $param1 + '=' + '"' + "********" + '"'
Write-Host "replace with " $replacetxt
try {
(Get-Content $filePath) -replace $line,$replacetxt | Set-Content $filePath
Write-Host "SUCCESS:Password has been replaced!" -ForegroundColor Green
}catch{
Write-Host "ERROR:Password has NOT been replaced!" -ForegroundColor red
$ErrorMessage = $_.Exception.Message
Write-Host $ErrorMessage
}
}
Write-Host "---"
}
Dans les fichiers *.ini, le script powershell va chercher toutes les lignes qui contiennent les mots clés "SAPWD","SQLSVCPASSWORD","AGTSVCPASSWORD","FTSVCPASSWORD"... et replacer par la suite les mots de passe par des étoiles.
Par défaut dans les Outils d'administration des serveurs distant (Remote Server Administration Tools = RSAT) la console WSUS (Windows Server Update Services) n'est pas présente.
Il est possible d'installer la console en ajoutant la KB972455 pour Windows Server Update Services 3.0 SP2 disponible ici:
https://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=5216
Une fois l'installation finie vous disposez de la console WSUS dans vos RSAT.
Contexte :
Le problème décrit ci-dessous a été rencontré sur le moteur anti-spam de la gamme SOPHOS UTM XG v15
Problème rencontré :
Les utilisateurs ne recevaient pratiquement plus aucuns mails de l’extérieur et les clients avaient en retour le message d’erreur suivant « internal Server Error » :
Analyse :
Les seuls mails qui passaient sont ce dont le domaine était autorisé dans le groupe « XXX Allowed Senders ».
Car une règle de bypass est créée pour ce groupe :
Résolution :
Pour résoudre cet incident il faut changer l’URL vers laquelle la liste Standard RBL pointe car le problème semble venir de cette liste (ou de son provider).
Pour cela vous allez dans Email -> Address Goup :
- Cliquer sur Premium RBL puis récupérer l’URL qui sera affichée.
- Se rendre dans Standard RBL et remplacé les URL présentes par celle de la Premium.
- Copier les URL Standard avant de les supprimer pour les remettre par la suite.
Pour information, l'erreur venait de certaines versions des boitiers UTM de SOPHOS et non d'une mauvaise configuration. Depuis un correctif est sorti afin que cet incident ne se reproduise plus si jamais le fournisseur des RBL Standards s’arrête de fonctionner.
Description
Le pack de contenu Office 365 Adoption dans Power BI permet d’obtenir des informations sur la façon dont votre organisation a adopté les différents services au sein de Office 365 pour communiquer et collaborer. Vous pouvez visualiser et analyser les données d’utilisation Office 365, créer des rapports personnalisés et les partager au sein de votre organisation.
Configuration
Pour profiter de cette nouvelle fonctionnalité il faut utiliser votre compte d’administration Office 365 et se rendre à l’adresse suivante : https://app.powerbi.com
Une fois dessus créer un compte en rentrant votre compte :
Une fois sur votre espace de travail cliquez sur « obtenir des données » depuis le volet de navigation
Cliquez sur « Obtenir » au niveau de la tuile Services
Vous pouvez maintenant choisir et installer l’application dont vous avez besoin. Par exemple vous pouvez installer l’application « Azure Active Directory Activity Logs » qui vas vous permettre d’avoir plusieurs statistiques sur votre infrastructure :
Le prérequis pour cette application est de rentrer le nom de domaine suivi de la procédure d’authentification.
Voici un autre exemple avec l’application « Office 365 Adoption Preview » :
Le prérequis pour cette application est de rentrer le nom de tenant suivi de la procédure d’authentification.
Information
Pour plus d’information concernant la configuration, je vous invite à consulter les liens suivants :
Le rançongiciel Petya est apparu fin juin en Ukraine pour ensuite se propager rapidement partout dans le monde.
Il s’agirait d’une variante de WannaCrypt qui était apparu en début d’année.
Se protéger
Si vous n’avez pas encore été infectée, vous devez vérifier que vos postes disposent des dernières mises à jour et de les installer si ce n’est pas le cas.
Pour agir rapidement vous pouvez installer uniquement la KB qui correspond à votre système d’exploitation en regardant la liste sur cette article https://blog.piservices.fr/post/2017/05/30/securite-kb-pour-wanna-cry et de se rendre sur le catalogue de Microsoft pour le télécharger http://www.catalog.update.microsoft.com/home.aspx.
Vérifier avec WSUS
Si vous disposez d’un serveur WSUS vous pouvez vérifier depuis la console si votre parc informatique est protégé. Pour se faire il faut se rendre dans l’onglet Updates -> Security Updates -> Search
Dans la fenêtre qui apparaît vous devez rentrer la KB souhaitez par exemple : 4012212
Lorsque vous regardé le report de la KB (en double cliquant dessus) vous verrez :
- La description de la KB
- Les groupes qui approuvent cette KB
- L’état de déploiement par rapport à vos machines
Microsoft a également sorti un script qui permet de savoir si votre machine dispose du patch ou non. Le seul prérequis est de disposer au minimum de Windows PowerShell 2.0. https://support.microsoft.com/fr-be/help/4023262/how-to-verify-that-ms17-010-is-installed
Voici le script :
[reflection.assembly]::LoadWithPartialName("System.Version")
$os = Get-WmiObject -class Win32_OperatingSystem
$osName = $os.Caption
$s = "%systemroot%\system32\drivers\srv.sys"
$v = [System.Environment]::ExpandEnvironmentVariables($s)
If (Test-Path "$v") { Try { $versionInfo = (Get-Item $v).VersionInfo $versionString = "$($versionInfo.FileMajorPart).$($versionInfo.FileMinorPart).$($versionInfo.FileBuildPart).$($versionInfo.FilePrivatePart)" $fileVersion = New-Object System.Version($versionString) } Catch { Write-Host "Unable to retrieve file version info, please verify vulnerability state manually." -ForegroundColor Yellow Return } }
Else { Write-Host "Srv.sys does not exist, please verify vulnerability state manually." -ForegroundColor Yellow Return }
if ($osName.Contains("Vista") -or ($osName.Contains("2008") -and -not $osName.Contains("R2"))) { if ($versionString.Split('.')[3][0] -eq "1") { $currentOS = "$osName GDR" $expectedVersion = New-Object System.Version("6.0.6002.19743") } elseif ($versionString.Split('.')[3][0] -eq "2") { $currentOS = "$osName LDR" $expectedVersion = New-Object System.Version("6.0.6002.24067") } else { $currentOS = "$osName" $expectedVersion = New-Object System.Version("9.9.9999.99999") } }
elseif ($osName.Contains("Windows 7") -or ($osName.Contains("2008 R2"))) { $currentOS = "$osName LDR" $expectedVersion = New-Object System.Version("6.1.7601.23689") }
elseif ($osName.Contains("Windows 8.1") -or $osName.Contains("2012 R2")) { $currentOS = "$osName LDR" $expectedVersion = New-Object System.Version("6.3.9600.18604") }
elseif ($osName.Contains("Windows 8") -or $osName.Contains("2012")) { $currentOS = "$osName LDR" $expectedVersion = New-Object System.Version("6.2.9200.22099") }
elseif ($osName.Contains("Windows 10")) { if ($os.BuildNumber -eq "10240") { $currentOS = "$osName TH1" $expectedVersion = New-Object System.Version("10.0.10240.17319") } elseif ($os.BuildNumber -eq "10586") { $currentOS = "$osName TH2" $expectedVersion = New-Object System.Version("10.0.10586.839") } elseif ($os.BuildNumber -eq "14393") { $currentOS = "$($osName) RS1" $expectedVersion = New-Object System.Version("10.0.14393.953") } elseif ($os.BuildNumber -eq "15063") { $currentOS = "$osName RS2" "No need to Patch. RS2 is released as patched. " return } }
elseif ($osName.Contains("2016")) { $currentOS = "$osName" $expectedVersion = New-Object System.Version("10.0.14393.953") }
elseif ($osName.Contains("Windows XP")) { $currentOS = "$osName" $expectedVersion = New-Object System.Version("5.1.2600.7208") }
elseif ($osName.Contains("Server 2003")) { $currentOS = "$osName" $expectedVersion = New-Object System.Version("5.2.3790.6021") }
else { Write-Host "Unable to determine OS applicability, please verify vulnerability state manually." -ForegroundColor Yellow $currentOS = "$osName" $expectedVersion = New-Object System.Version("9.9.9999.99999") }
Write-Host "`n`nCurrent OS: $currentOS (Build Number $($os.BuildNumber))" -ForegroundColor Cyan
Write-Host "`nExpected Version of srv.sys: $($expectedVersion.ToString())" -ForegroundColor Cyan
Write-Host "`nActual Version of srv.sys: $($fileVersion.ToString())" -ForegroundColor Cyan
If ($($fileVersion.CompareTo($expectedVersion)) -lt 0) { Write-Host "`n`n" Write-Host "System is NOT Patched" -ForegroundColor Red }
Else { Write-Host "`n`n" Write-Host "System is Patched" -ForegroundColor Green }
#
Voici le résultat de se script exécuté sur un poste patché et non patché.
Information :
Si vous êtes déjà touché par le rançongiciel, la première chose à faire est d’isoler tous les équipements identifiés comme étant contaminés en les débranchant du réseau afin de contenir l’action du programme. De plus vous devez si possible mettre en veille prolongé la machine ou de la mettre hors tension pour arrêter l’action du programme et de ne surtout pas payer la rançon.
Vous pouvez lire également deux notes de l’Agence Nationale de la Sécurité des Systèmes d’Information (ANSSI) qui permet de savoir quelle attitude adopter avant et après une attaque rançongiciel.
http://www.cert.ssi.gouv.fr/site/CERTFR-2017-INF-001/CERTFR-2017-INF-001.html
http://www.ssi.gouv.fr/actualite/alerte-campagne-de-rancongiciel-3/
1. Se rendre sur l'interface d'administration de SharePoint Online
Sélectionner : Nouveau > Collection de sites privée
2. Renseigner les champs suivants
- titre
- addresse du site web
- la langue
- le modèle (choisir personalisé)
- le fuseau horaire
- l'administrateur du site
- le quota
3. Patienter pendant la création du site
4. Application du template de site
Se rendre sur le site qui a été créé et cliquer sur "Galerie solutions" pour charger le template personalisé.
Sélectionner "Télécharger la solution"
Sélectionner le fichier template à injecter puis valider par OK
Activer le module et patienter pendant le chargement du template.
FIN.
Lors du déploiement du client SCCM sur un serveur hébergeant déjà le rôle Management Point, l’installation échoue.
Une analyse du log c:\windows\ccmsetup\logs\ccmsetup.log révèle le message d’erreur suivant :
"MSI: Setup was unable to register the CCM_Service_HostingConfiguration endpoint
The error code is 80041002"
"File C:\Windows\ccmsetup\{72875A95-4007-4DAC-88D8-66366F9A5045}\client.msi installation failed. Error text: ExitCode: 1603
Action: CcmRegisterHostingConfiguration.
ErrorMessages:
Setup was unable to register the CCM_Service_HostingConfiguration endpoint
The error code is 80041002"
Une rapide recherche permet de trouver la KB suivante, qui indique de supprimer le rôle MP, d’installer le client puis de réinstaller le rôle MP : https://support.microsoft.com/en-us/help/2905359/installation-of-the-configuration-manager-client-agent-fails-with-error-code-80041002
Cette solution, bien que fonctionnelle, n’est pas très satisfaisante : d’autres clients SCCM peuvent dépendre de ce serveur MP, qui peut se trouver dans un réseau isolé etc.
Heureusement, une autre solution existe : il faut installer le client via la ligne de commande, en spécifiant manuellement le chemin vers le patch le plus récent disponible, copié manuellement dans un dossier de votre choix au préalable :
C:\SMS\Client\ccmsetup.exe /mp;SERVEURMP.LAN.LOCAL INSTALL="ALL" SMSSITECODE="XXX" CCMHTTPPORT="80" CCMHTTPSPORT="443" CCMHTTPSSTATE="480" FSP="XXX.LAN.LOCAL" CCMFIRSTCERT="1" patch="C:\SMS\Client\configmgr2012ac-sp2r2sp1-kb3100144-x64.msp"
Et le tour est joué !
Suite à un nouveau déploiement de WSUS, toutes les tentatives de synchronisation échouent :
SoapException: Fault occurred
at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)
at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
at Microsoft.UpdateServices.ServerSyncWebServices.ServerSync.ServerSyncProxy.GetUpdateData(Cookie cookie, UpdateIdentity[] updateIds)
at Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.WebserviceGetUpdateData(UpdateIdentity[] updateIds, List`1 allMetadata, List`1 allFileUrls, Boolean isForConfig)
at Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.GetUpdateDataInChunksAndImport(List`1 neededUpdates, List`1 allMetadata, List`1 allFileUrls, Boolean isConfigData)
at Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.ExecuteSyncProtocol(Boolean allowRedirect)
L’étude des fichiers de log Wsus et IIS montrent que l’appel au ServerSyncWebService échoue avec une erreur 500 :
Mais il s’agit d’une fausse piste.
En réalité, le problème provient d’une installation précédente de WSUS sur ce serveur. Bien qu’il ait été désinstallé proprement préalablement à la réinstallation (suppression du rôle Windows et de la base WID), le dossier C:\Windows\Softwaredistribution était toujours présent.
Après sa suppression (ou son renommage) et le redémarrage du service wuauserv, la synchronisation se lance.
Bonjour à tous,
Aujourd'hui nous allons partir à la découverte du fichier NetLogon.dns
Vous trouverez ce fichier, propre à chaque contrôleur de domaine, dans le dossier %systemroot%\System32\Config.
Comme vous le savez surement, les services AD et DNS sont très étroitement liés car les informations relatives aux différents contrôleurs de domaine ou aux différents sites AD sont stockées dans la zone DNS de la forêt AD correspondante.
Celle-ci contient donc des enregistrements A faisant référence directement aux adresses IP des contrôleurs de domaine ou des enregistrements SRV permettant aux postes clients de la forêt AD de pouvoir accéder aux services essentiels AD.
Ce fichier intéressera donc en premier lieu :
- Ceux qui doivent résoudre des problèmes relatifs au fonctionnement des services AD et qui ont localisé des irrégularités au niveau des enregistrements stockés dans la zone DNS AD
- Ceux dont la zone DNS correspondant à la forêt AD se trouve sur un serveur DNS non Microsoft (gestion "manuelle" des enregistrements)
Un exemple valant mieux que 1000 mots, vous trouverez ci-dessous le contenu de ce fichier avec l'ensemble des enregistrements mentionnés ci-dessus :
Bonne exploration !