Overblog
Suivre ce blog Administration + Créer mon blog
4 septembre 2021 6 04 /09 /septembre /2021 14:00

2022 apporte beaucoup de nouveautés, surtout en ce qui concerne la sécurité. Mais Microsoft en profite pour durcir sa politique.

Quelques conseils (mais pas beaucoup après plusieurs mois de tests) :

  • Oubliez les vieilles commandes que je vois trop souvent. S i vous utilisez Netdom pour intégrer votre futur DC, prévoyez une bonne sauvegarde. En effet, si vous utilisez Netdom, vous allez perdre votre forêt.
  • Attention au nouveau système de fichier. Mes tests avec un HDD et une clef USB ont montrés qu'une fois mis sur le 2022, le stockage devient inaccessible sur les anciens OS

Et puis, il ne faut pas oublier que Microsoft impose le chiffrage des disques et des identités pour les DCs. On s'appuie sur la TPM... qui n'est pas toujours disponible dans le cloud. Par exemple, Amazon ne délivre pas cette fonctionnalité. Leur palliatif n'est pas compatible... Si MS garde cette politique, beaucoup de sociétés vont devoir revoir leur copie.

Et pour ceux qui sont allergique au PowerShell... dommage !

Je mets des informations complémentaires concernant différents points. A noter tout de même, que toutes les améliorations sont entièrement compatible avec Windows 11. C'est entre autre pour cela que Windows 2022 est sortie quelques semaines avant Windows 11 (prévu le 5 octobre).

Sécurité

  • Secured-Core Server : Un serveur Secured-core protège le serveur contre les attaques sophistiquées et peut fournir une assurance accrue lors du traitement des données critiques dans certains secteurs sensibles. Il repose sur trois piliers : une sécurité simplifiée, une protection avancée et une défense préventive.
  • La sécurité simplifié se base uniquement sur le matériel du fabricant (OEM). Le matériel est le firmware, hardware et les drivers qui seront compatible. L'activation se fait simplement dans l'Admin Center.
  • La protection avancée : Elle s'appuie sur la TPM 2.0. Elle est utilisée pour Bitlocker par exemple. Egalement, il y a une protection des firmware. En effet, des virus se mettent de plus en plus dans les firmware. Pour protéger le serveur, on va s'appuyer sur DRTM (côté processeur) et DMA ce qui va permettre de renforcer l'isolation de l'hyper-viseur pour bloquer ce type d'ataque.
  • Enfin, la défense préventive : Elle permet d'être proactive et de bloquer les chemins connus par les attaquants. Je n'ai pas approfondi ce point, mais j'ai l'impression qu'il fait office d'EDR ou d'un équivalent. A vérifier...

La connectivité

  • Le HTTPS et TLS 1.3 sont activés par défaut, les anciennes version et les protocoles obsolètes ne sont pas activés, voir inexistants
  • DNS Sécurisé prendre en charge DoH (DNS over HTTPS). Elle permet de chiffrer les requêtes DNS à l'aide de HTTPS, et donc d'un certificat venant d'une PKI entreprise.
  • SMB ! Et oui, SMB toujours là pour vous écouter :-) Sauf que maintenant, on se base sur de l'AES-256-GCM et AES-256-CCM. Cependant, l'AES-CMAC-128 est toujours présent pour assurer une certaine compatibilité. Mais bon, on ne descend pas à Windows XP (oui, il y a encore des sociétés qui en ont encore). Cela veut dire que SMB v2 est mort... Petite précision, avec Windows 2022 et Windows 11, le transfert de fichier via SMB sont compressés (et ça c'est top).
  • Pour Azure, SMB over QUIC est mis à jour avec SMB 3.1.1

Virtualisation

  • La virtualisation imbriquée (pour les processeurs AMD uniquement) permet de faire fonctionner un Hyper-V dans une VM sous Hyper-V. Très cool pour l'apprentissage !

Navigateur

  • IE est mort, vive Edge ! Bon, tout comme la version actuelle de Edge, il fonctionne en utilisant de l'Open Source : Chromium. Chose que je ne comprends pas, il peut être utilisé avec une installation Desktop Experience ou en Server Core...
Partager cet article
Repost0
24 janvier 2021 7 24 /01 /janvier /2021 11:48

Bon, les mots de passes font parti de notre quotidien. Et même si maintenant il y a des technologies qui permettent de ne plus avoir de mot de passe, c'est loin d'être démocratisé.

Donc, il faut des mots de passes. Mais quoi comme mot de passe ?

Dans un environnement Microsoft, il y a 3 catégories (pour simplifier) de comptes qui doivent avoir des stratégies de mots de passe :

  • Un compte utilisateur
  • Un compte à pouvoir
  • Un compte de service

Bien sur, la liste ne représente pas l'ensemble des types de comptes qui peuvent exister. Mais ce sont 3 types de comptes que l'on retrouvent partout. 

Les mots de passes, doivent respecter une stratégie différente en fonction de ces types. Un compte utilisateur va avoir une stratégie moins forte qu'un compte admin par exemple.

Même si les stratégies sont bien faite, je vois trop souvent des mots de passe générique. Du style, je crée un mot de passe générique pour tous les comptes créés. Ce n'est pas top car une tel politique veut dire qu'il y a 90% de chance que les mots de passe administrateur locaux subissent le même sort !

La gestion des mots de passes des admin locaux, fera l'objet d'un article futur. Aujourd'hui, je vais m'attarder sur comment générer un mot de passe aléatoire via PowerShell. 

Pourquoi PowerShell ? Simplement que, pour moi, les créations de comptes, quel qu'il soit, doivent être scripté pour que toutes les créations soient identiques. Donc, la génération du mot de passe en fait partie !

Alors voici le code :

Add-Type -AssemblyName System.Web
[System.Web.Security.Membership]::GeneratePassword(25,6)

La 1ère ligne est a mettre au début du code pour charger le module 1 fois.

La 2ème ligne, génère le mot de passe. Il y a 2 paramètres à utiliser : 

  1. La longueur du mot de passe. Dans l'exemple, la longueur est de 25 caractères
  2. Le nombre de caractère non alphanumérique que vous voulez. Dans l'exemple, 6 caractères non alphanumérique seront présents

A noter que les caractères non alphanumérique ne s'ajoute pas à la longueur du mot de passe. Dans notre exemple, le mot de passe fera 25 caractères et contiendra 6 caractères spéciaux.

Egalement, vous ne pouvez pas mettre un nombre plus important de caractères spéciaux que la longueur du mot de passe !!!

Autre point important, la génération du mot de passe ne contient pas forcément de chiffre ! Mais vous aurez (je ne suis pas tomber sur un cas contraire) une minuscule et une majuscule. Ajoutez des caractères spéciaux, et vous aurez 3 des 4 critères de complexité requis.

Voici des exemples :

[System.Web.Security.Membership]::GeneratePassword(5,1)
e%Ns!

[System.Web.Security.Membership]::GeneratePassword(5,5)
/{/=+

[System.Web.Security.Membership]::GeneratePassword(25,6)
j@C>]0;N0h4[UFGUe|1|yz!#X

[System.Web.Security.Membership]::GeneratePassword(25,6)
TWtoJc>$cSgxU[.oY}#J]sy=G
 

Voici l'erreur que vous aurez si vous demandez un mot de passe dont le nombre de caractères spéciaux est supérieur à la longueur du mot de passe :

[System.Web.Security.Membership]::GeneratePassword(5,6)
Exception lors de l'appel de «GeneratePassword» avec «2» argument(s): «La valeur spécifiée dans le paramètre 'numberOfNonAlphanumericCharacters' doit se trouver dans une plage comprise entre zéro et la valeur spécifiée dans 
le paramètre de longueur du mot de passe.»
Au caractère Ligne:1 : 1
+ [System.Web.Security.Membership]::GeneratePassword(5,6)
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : ArgumentException

Partager cet article
Repost0
25 novembre 2018 7 25 /11 /novembre /2018 14:04

Je vais vous parler d'un petit Bug de Powershell (parmis tant d'autre). Ce comportement va être montré sur une commande, mais elle valable sur d'autres. Donc, soyez vigilent quand vous avez des erreurs.

Pour exemple, la commande Remove-ADComputer. Cette commande permet de supprimer un objet Ordinateur de l'AD. Ok... mais...

Pour que la commande s'exécute bien, il faut lancer la console PowerShell avec les privilèges suffisant. Perso, je la lance toujours en tant qu'administrateur. Ensuite, je me connecte sur un contrôleur de domaine sur lequel je lance la commande : Remove-ADComputer MyServer

Alors que je suis connecté avec un compte Domain Admin, je reçois le message suivant : Remove-ADComputer : Access is denied

Non, il n'y a pas d'erreur dans la commande et vous avez les bons droits. En fait, PowerShell n'aime pas trop se donner des ordres. Du coup, se demander à soi-même (le DC sur lequel je me suis connecté, içi MyDC1) de supprimer un objet AD... Non, c'est trop pour lui. Alors ? Et bien il faut lui demander de le faire faire par quelqu'un d'autre... La commande à utiliser devient : Remove-ADComputer MyServer -Server MyDC2 . Maintenant, la commande passe correctement !

Pour prendre une autre commande dans le même cas : Set-ADObject ou encore Remove-ADObject

Ma recommandation est d'utiliser un serveur d'administration. Par ce biais, toutes ces erreurs ne seront plus présentes vu que la commande va forcément s'adresser à un DC !

Ce n'est qu'un petit détail, mais ça peut changer notre vie !

Partager cet article
Repost0
24 juillet 2018 2 24 /07 /juillet /2018 13:32

Tout ceux qui ont migré des comptes AD d'un domaine à un autre, se sont confrontés aux problèmes de SID.

En effet, ce qui donne les droits, ce ne sont pas les samAccountName d'un utilisateur, mais son SID. Lorsque celui-ci est migré, afin de garder les droits sur l'ancien domaine, il est possible d'avoir du SID History qui reprend l'ensemble des SID que le compte a eu dans sa vie. De cette manière, il n'y a aucune perte de droits.

Le problème est que l'utilisateur garde ses droits dans l'ancien domaine, et ce n'est pas forcément ce que l'on souhaite. De plus, pour certaines migrations, il est fortement recommandé, quand ce n'est pas un prérequis, de vider ces données.

Problème : 

  • Il n'est pas possible de les supprimer en utilisant la console DSA
  • Les commandes "standard" PowerShell ne fonctionnent pas.

Heureusement, sans avoir recours à des logiciels tiers, il y a la possibilité de mettre à zéro cet SID History.

1) Suppression sur 1 utilisateur

Get-ADUser -filter {samAccountName -eq 'MonCompteAD'} -searchbase "dc=MonDomaine" -searchscope subtree -properties sidhistory | foreach {Set-ADUser $_ -remove @{sidhistory=$_.sidhistory.value}}

 

2) Suppression sur tous les utilisateurs

Get-ADUser –filter ‘sidhistory –like “*”’ –searchbase “dc=MonDomaine” –searchscope subtree –properties sidhistory | foreach {Set-ADUser $_ -remove @{sidhistory=$_.sidhistory.value}}

 

Attention tout de même pour le point 2. Tous les SIDHistory des utilisateurs du domaine vont être supprimés, ce qui veut dire des potentiels perte de droits.

Partager cet article
Repost0
18 juillet 2018 3 18 /07 /juillet /2018 18:15

Un mot de passe sert à sécuriser un compte. Mais dans une entreprise, des comptes sont plus sensible que d'autre, et encore plus avec le Cloud.

Mais qu'appelle-t-on un bon mot de passe ?

Un bon mot de passe est sa capacité à résister contre une attaque. La qualité d'un mot de passe dépend de sa longueur, que l'on va appeler L, et du nombre de caractère possible pour chaque caractère, que l'on appellera N. Les possibilité d'un mot de passe peut se calculer avec la formule NL.

Ok, c'est bien beau, mais comment je sais que mon mot de passe est bon ?

En fait, et sans rentrer dans le détail, la qualité d'un mot de passe peut être comparé avec la cryptographie. Aujourd'hui, on estime qu'une clef en dessous de 100 bits est considéré non sûre. Mais attention, une clef de cryptographie est composée de 0 et de 1. En revanche, un mot de passe est composé de multiple caractères.

Si on doit comparer une clef et un mot de passe on pourrait dire :

Taille de la clef de cryptageForce d'un mot de passe équivalent
64Très faible
64<80Faible
80<100Moyen
>100Fort

Comme je le disais, le mot de passe utilise des caractères. Ces caractères sont différents en fonction de l'alphabet, et plus précisément dans la table ASCII utilisé. Par exemple :

  • Une longueur de mot de passe dit "classique" de 8 caractères alphanumérique (alphabet de 62 symboles : 0 à 9, de a à z et de A à Z), représente une équivalence de cryptage de 48 bits.
  • Une longueur de mot de passe  de 16 caractères alpha numérique (alphabet de 36 symboles : 0 à 9 et de A à Z), représente une équivalence de cryptage de 83 bits. Cela représente le minimum pour des mots de passes sûrs. Si on ne change pas la longueur du mot de passe mais juste l'alphabet (90 symboles : 9, A à Z, a à z et € ! #$*% ?&[|]@^µ§ :/ ;.,&lt;&gt;°²³), la force du mot de passe devient 104 bits. 

A noter que pour un équivalent d'un cryptage AES 128, il faut un mot de passe de 20 caractères de l'alphabet de 90 symboles.

Source : ANSSI

Partager cet article
Repost0
19 octobre 2017 4 19 /10 /octobre /2017 20:07
[Microsoft] - Les mots de passes

Qu'est-ce qu'ils ont mes mots de passes ? Ils sont sécurisés, non ?

Très bonne question. D'autant plus que la complexité d'un mot de passe n'est pas aussi simple que ça. Par exemple, un mot de passe de 15 caractères est-il plus sécurisé qu'un mot de passe de 21 caractères ? On pourrait imaginer que oui... mais non.

Le mot de passe est protégé par un Hash. Le "hachage" du mot de passe permet de le chiffrer et donc de garantir sa sécurité. Mais le hash est calculé sur 7 caractères. Ce qui veut dire que la sécurité du mot de passe est renforcé par paquet de 7 caractères.

En gros, un mot de passe qui a entre 1 et 7 caractères aura la même sécurité. En revanche, un mot de passe qui a entre 8 et 14 caractères sera plus protégé. Donc, un mot de passe de 8 caractères est beaucoup plus fort que le mot de passe de 7 caractères et possède la même sécurité qu'un mot de passe de 14 caractères.

En conclusion, n'obligez pas vos utilisateurs à avoir un mot de passe d'une longueur aléatoire ! Tenez compte du hashage par paquet de 7 caractères... Ce serait dommage de passer à côté d'une sécurité accrue à 1 caractères prêt !

Partager cet article
Repost0
28 septembre 2017 4 28 /09 /septembre /2017 20:10
[Microsoft] - Encryption DES

Lors de migration Active Directory, certaines choses sont à prendre en compte. Normal...

En voici une parmi d'autre : l'encryption DES.

En effet, présent jusqu'à Windows 2008R2, il devient optionnel et à installer avec Windows 2012 pour être totalement supprimée avec Windows 2016. Il est donc important de connaitre son environnement avant de migrer de version.

Alors, voici un petit script qui peut vous aider dans votre audit. Ce script permet d'auditer le journal de sécurité pour savoir si une encryption DES est utilisée :

 

<#
.DESCRIPTION
Kerberos-Encryption is used to get the Kerberos Encryption type that is used
.PARAMETER ComputerName
Specify remote server names to check. Default: The Local Computer
.PARAMETER Records
Specify the maximum number of events to be retrieved from each computer. Default: 10000
.EXAMPLE
.\Kerberos-Encryption.ps1 -ComputerName server1 | Format-Table -AutoSize
Retrieve 10000 logon events from server1 and display them on the screen in a table.
.EXAMPLE
.\Kerberos-Encryption.ps1 -ComputerName server1, server2 -Records 30 | Export-Csv -NoTypeInformation -Path d:\tmp\kerberosEncryption.csv
Retrieve 30 logon events from server1 and 30 from server2. Save the results as a CSV file located in the specified path.
#>
param
 (
  $ComputerName = $Env:ComputerName,
  $Records = 10000
 )
 $functions =
  {
   function Get-EncryptionTypeName
    {
     Param($LogonTypeNumber)
     switch ($LogonTypeNumber)
   {
       0x1 {"des-cbc-crc"; break;}
       0x2 {"des-cbc-md4"; break;}
       0x3 {"des-cbc-md5"; break;}
       0x4 {"[reserved]"; break;}
       0x5 {"des3-cbc-md5"; break;}
       0x6 {"[reserved]"; break;}
       0x7 {"des3-cbc-sha1"; break;}
       0x9 {"dsaWithSHA1-CmsOID"; break;}
       0xa {"md5WithRSAEncryption-CmsOID"; break;}
       0xb {"sha1WithRSAEncryption-CmsOID"; break;}
       0xc {"rc2CBC-EnvOID"; break;}
       0xd {"rsaEncryption-EnvOID"; break;}
       0xe {"rsaES-OAEP-ENV-OID"; break;}
       0xf {"des-ede3-cbc-Env-OID"; break;}
       0x10{"des3-cbc-sha1-kd"; break;}
       0x11{"aes128-cts-hmac-sha1-96"; break;}
       0x12{"aes256-cts-hmac-sha1-96"; break;}
       0x17{"rc4-hmac"; break;}
       0x18{"rc4-hmac-exp"; break;}
       0x41 {"subkey-keymaterial"; break;}
       default {"Unknown"; break;}
      }
 }
  }
Function StartAudit {
$dcs=Get-ADDomainController -Filter *
foreach($dc in $dcs){
Start-Job -ScriptBlock {param($dc,$Records)
$computername = $dc.HostName
$ComputerName | ForEach-Object {Get-Winevent -Computer $_  -LogName "Security" -MaxEvents $Records -FilterXPath "*[System[(EventID=4769)]]" | ? {$_.Properties[5].Value  -eq "0x1" -or $_.Properties[5].Value  -eq "0x2" -or $_.Properties[5].Value  -eq "0x3" -or $_.Properties[5].Value  -eq "0x5" -or $_.Properties[5].Value  -eq "0x7" -or $_.Properties[5].Value  -eq "0xf" -or $_.Properties[5].Value  -eq "0x10"} |
select @{Name='Time';e={$_.TimeCreated.ToString('g')}},
@{l="Encryption Type";e={Get-EncryptionTypeName $_.Properties[5].Value}},
@{l='User Name';e={$_.Properties[0].Value}},
@{l='Client Name';e={$_.Properties[2].Value}},
@{l='Client Address';e={$_.Properties[6].Value}},
@{l='Server Name';e={$_.MachineName}}} | 
Export-Csv "d:\tmp\kerberosEncryption_$ComputerName.csv" -Delimiter ";" -Append
} -ArgumentList $dc, $Records -InitializationScript $functions}
}
$i = 0
While ($i -lt 1153) {Write-Host "Itération :" $i "/ 1152" ; $i++ ; sleep 600 ; if ((Get-Job | ? {$_.State -eq "Running"}).Count -eq 0) {StartAudit}}

 

Ce script va donc auditer le journal de sécurité d'un DC. Cela veut dire que c'est long ! Si vous avez d'autres outils qui permettent d'audit, ce sera plus performant. Mais à défaut, ces quelques lignes feront très bien l'affaire.

Partager cet article
Repost0
22 septembre 2017 5 22 /09 /septembre /2017 20:36
[Microsoft] - Comptes AD et DES

Lors de migration Active Directory, certaines choses sont à prendre en compte. Normal...

En voici une parmi d'autre : l'encryption DES.

En effet, présent jusqu'à Windows 2008R2, il devient optionnel et à installer avec Windows 2012 pour être totalement supprimée avec Windows 2016. Il est donc important de connaitre son environnement avant de migrer de version.

Alors, voici une petite commande qui peut vous aider dans votre audit. Ce script permet d'auditer l'ensemble des comptes utilisateurs et de ressortir tous ceux qui ont DES dans les encryptions autorisé. Elle vous permettra de cibler vos investigations pour migrer en toute sérénité !

La commande Powershell est :

Get-ADUser -Filter 'useraccountcontrol -band 2097152' -Properties useraccountcontrol | FT Name

A noter qu'il n'y a pas besoin d'avoir des droits spécifique. Un compte utilisateur "simple" suffit largement.

Maintenant, si vous voulez auditer d'autre points, voici un petit tableau avec les codes "band"

Property FlagValue in HexadecimalValue in Decimal
SCRIPT0x00011
ACCOUNTDISABLE0x00022
HOMEDIR_REQUIRED0x00088
LOCKOUT0x001016
PASSWD_NOTREQ0x002032
PASSWD_CANT_CHANGE0x004064
ENCRYPTED_TEXT_PWD_ALLOWED0x0080128
TEMP_DUPLICATE_ACCOUNT0x0100256
NORMAL_ACCOUNT0x0200512
INTERDOMAIN_TRUST_ACCOUNT0x08002048
WORKSTATION_TRUST_ACCOUNT0x10004096
SERVER_TRUST_ACCOUNT0x20008192
DONT_EXPIRE_PASSWORD0x1000065536
MNS_LOGON_ACCOUNT0x20000131072
SMARTCARD_REQUIRED0x40000262144
TRUSTED_FOR_DELEGATION0x80000524288
NOT_DELEGATED0x1000001048576
USE_DES_KEY_ONLY0x2000002097152
DONT_REQ_PREAUTH0x4000004194304
PASSWORD_EXPIRED0x8000008388608
TRUSTED_TO_AUTH_FOR_DELEGATION0x100000016777216
PARTIAL_SECRETS_ACCOUNT0x400000067108864

Bien évidemment, vous gardez la liberté de mélanger les propriétés en additionnant les valeurs. Par exemple, pour avoir la liste des utilisateurs qui ont "Password never expires", "Store password using reversible encryption" et "Use Kerberos DES encryption" il faut faire l'addition 0x10000+0x0080+0x200000

Pour faire simple, voici le code :
$Ma_Valeur = 0x10000 + 0x0080 + 0x200000
Get-ADUser -Filter {UserAccountControl -band $Ma_Valeur}

Bien évidemment, cela fonctionne aussi avec les valeurs décimales.

Voila, vous savez tout !

Partager cet article
Repost0
18 septembre 2017 1 18 /09 /septembre /2017 20:15
[Microsoft] - Schéma Active Directory

Ce n'est qu'un rappel, mais ça fait du bien de temps en temps.

Pour pouvoir accéder au schéma AD, il faut accéder au composant Schema Active Directory dans la mmc.

Par défaut, le composant n'est pas présent. Alors pour l'ajouter il suffit juste d'exécuter dans une invite de commande (en mode administrateur) la commande : regsvr32 C:\Windows\system32\schmmgmt.dll

Et voila, dans la mmc le composant est maintenant accessible.

Ma petite note : Comme c'est un composant sensible, il faut garantir que cette console ne soit accessible qu'à un nombre limité de comptes. Egalement, il faut limiter le nombre de compte au groupe Schema Administrator pour éviter des modifications irréversibles.

Partager cet article
Repost0
11 septembre 2017 1 11 /09 /septembre /2017 21:01
[Microsoft] - Erreur 2147942667 dans le planificateur de tâche

Le planificateur de tâche est un outil bien sympa. Mais les codes erreurs sont parfois une énigme.

Il y a un code que je souhaite expliquer la résolution car, je trouve, qu'elle n'est pas forcément bien documentée : 2147942667

Voici un exemple d'erreur :

Task Scheduler failed to launch action "C:\Windows\SYSTEM32\cmd.exe" in instance "{2a7cc950-fad9-4633-9701-af75a0fd220d}" of task "\stmm\Daemon". Additional Data: Error Value: 2147942667.
 Task Scheduler failed to start instance "{2a7cc950-fad9-4633-9701-af75a0fd220d}" of "\stmm\Daemon"  task for user "GBLADHEDANI\N011940" . Additional Data: Error Value: 2147942667

La chose qui peut dérouter, c'est que tout fonctionne bien quand on exécute la tâche à la main (clic droit / run) ou quand l'option "Run only when user is logged" est cochée. En revanche, quand on passe à l'option "Run whether user is logged on or not", rien ne va plus !

Pas de panic ! Ne cherchez pas un bug dans votre commande, tout est bon. En revanche, c'est le paramètre "Start in (optional)" qui pose problème. Enlevez les guillemets (") dans le champs et validez la fenêtre. Vous verrez, tout ira mieux et vous serez le roi du Task Scheduler !

Ce problème est arrivé avec Windows Vista et continue de nous hanter !!!

Partager cet article
Repost0