PI Services

Le blog des collaborateurs de PI Services

Active Directory : NETDOM et les contrôleurs de domaine en français

7. août 2017 Mickael-GUILLON (0)

Bonjour à tous !

Aujourd'hui, nous allons parler de la commande Netdom trust (nous allons donner plus de détails sur cette commande dans un prochain article).

Quand vous êtes dans le cadre d'une migration de forêt/domaine Active Directory, il est probable que vous vouliez autoriser l'utilisation des SidHistory afin de préserver les accès aux ressources du domaine historique pour les postes/utilisateurs migrés.

Pour se faire, nous utilisons deux commandes (depuis un contrôleur de la nouvelle foret) :

  • netdom trust DomaineHistorique /D:NouveauDomaine /UO:Utilisateur_Nouveau_Domaine /PO:* /Quarantine:yes/no
  •  netdom trust DomaineHistorique /D:NouveauDomaine /UO:Utilisateur_Nouveau_Domaine /PO:* /EnableSidHistory:yes/no

Mais que se passe t'il si vous entrez cette commande sur un contrôleur de domaine en langue française ?

Nous entrons donc la commande suivante afin d'avoir le statut de la mise en quarantaine des SID : netdom trust DomaineHistorique /D:NouveauDomaine /UO:Utilisateur_Nouveau_Domaine /PO:* /Quarantine

Nous voulons maintenant effectuer une action en désactivant la mise en quarantaine des SID : netdom trust DomaineHistorique /D:NouveauDomaine /UO:Utilisateur_Nouveau_Domaine /PO:* /Quarantine:no

Bizarre, nous obtenons le même message que pour la commande précédente ...

Après vérification, la commande n'a pas désactivé le filtrage.

En revanche, si vous entrez la version suivante de la commande, vous obtiendrez un résultat fort différent ! 

netdom trust DomaineHistorique /D:NouveauDomaine /UO:Utilisateur_Nouveau_Domaine /PO:* /Quarantine:non

Et voilà ! La commande marche enfin ! Elle n'a été traduite que pour un seul paramètre.

Il est à noter qu'il faut faire exactement la même chose pour le paramètre /EnableSidHistory.

Vous êtes désormais averti, ce bug est encore présent même sous Windows Server 2012 R2.

Remplacer tous les mots de passe en claire dans un dossier donné en powershell

31. juillet 2017 Seevadassen-KARUPPANNAN (0)

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.

 

Windows 7 : RSAT WSUS

24. juillet 2017 Mathieu-ADELAIDE (0)

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.

Compteurs de performance Exchange en erreur

15. juillet 2017 Julien-LANCHAS Exchange 2013, Messagerie (0)

Problème:

Après une installation d'Exchange avec un chemin d'installation différent de celui par défaut, certains compteurs de performance remontent en erreur dans les journaux d'événements.

Solution:

Reconstruire les compteurs de performance à l'aide du script suivant:

 

Add-Pssnapin Microsoft.Exchange.Management.PowerShell.Setup

$Fichiers =get-childitem "E:\Exchange Server\Setup\Perf\" *.xml |where-object {!($_.psiscontainer)}

foreach ($fichier in $fichiers) {

Remove-perfcounters -Definitionfilename $file.fullname

}
foreach ($fichier in $fichiers) {

New-perfcounters -Definitionfilename $file.fullname

}

 

 

SOPHOS – Anti-Spam erreur “Internal Server Error”

3. juillet 2017 Robin-MATHE Sophos (0)

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 » :

clip_image002

Analyse :

Les seuls mails qui passaient sont ce dont le domaine était autorisé dans le groupe « XXX Allowed Senders ».

image

Car une règle de bypass est créée pour ce groupe :

image

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 :

clip_image007

  • 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.

Office 365 - VIsualiser des rapports avec Power BI

3. juillet 2017 Robin-MATHE Office 365 (0)

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 :

clip_image002

Une fois sur votre espace de travail cliquez sur « obtenir des données » depuis le volet de navigation

clip_image003

Cliquez sur « Obtenir » au niveau de la tuile Services

clip_image005

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 :

clip_image007

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 » :

clip_image009

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 :

Sécurité : Windows KB pour Ransomware – PETYA

3. juillet 2017 Robin-MATHE Poste de travail , Sécurité, Windows 10, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016, Windows Server 2016 Nano, WSUS (0)

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

clip_image002

Dans la fenêtre qui apparaît vous devez rentrer la KB souhaitez par exemple : 4012212

clip_image003

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

clip_image004

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é.

clip_image005

clip_image006

 

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/

Création d'un site SharePoint online via un template personalisé

3. juillet 2017 Seevadassen-KARUPPANNAN Office 365, SharePoint (0)

1. Se rendre sur l'interface d'administration de SharePoint Online

Sélectionner : Nouveau > Collection de sites privée

2. Renseigner les champs suivants

  1. titre
  2. addresse du site web
  3. la langue
  4. le modèle (choisir personalisé)
  5. le fuseau horaire
  6. l'administrateur du site
  7. 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.

 

 

SCCM – Le déploiement du client sur un Management Point additionnel échoue

30. juin 2017 Cyril-AZOULAY (0)

 

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é !

WSUS – La synchronisation échoue pour un nouveau déploiement

30. juin 2017 Cyril-AZOULAY (0)

Suite à un nouveau déploiement de WSUS, toutes les tentatives de synchronisation échouent :

clip_image002

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 :

clip_image004

clip_image006

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.

 

clip_image009

clip_image007

clip_image011