07 Jun 2021, 00:00

Envoi d'un mail d'avertissement lorsque le mot passe AD est proche de l'expiration

Préambule

Le but est d’avertir les utilisateurs d’un domaine Active Directory lorsque leur mot de passe est proche de l’expiration, pour leur permettre de le renouveler avant l’expiration.

Le renouvellemnt se fait sans problème lorsque l’on est connecté directement au réseau, mais dans le cas d’un accès via OpenVPN avec authentification auprès de l’AD, la connexion VPN sera bloquée lorsque le mot de passe est expiré. D’où la procédure ici-présente.

Stockage du mot de passe de manière chiffrée

Source

Le but, si je comprends bien, est d’enregistrer une empreinte du mot de passe (ou le mot de passe chiffré) dans un fichier, pour qu’il soit utilisable sans interaction humaine, sans pour autant être exposé en clair sur le disque.

Le fichier obtenu sera spécifique à ce compte utilisateur, et cette machine. Il devra être recréé si l’opération doit être effectuée depuis un autre compte, ou le même compte sur une autre machine.

Lancer powershell, puis les commandes suivantes (adapter le chemin de fichier si besoin) :

$credential = Get-Credential # entrer identifiant et mot de passe à conserver
$credential.Password | ConvertFrom-SecureString | Set-Content D:\encrypted_password.txt

Le fichier D:\encrypted_password.txt contient le hash qui nous intéresse.

À noter que ceci a été réalisé en utilisant un utilisateur qui possède une licence valide auprès d’Office 365. Non testé auprès d’autres fournisseurs SMTP.

Script pour générer et envoyer les mails

Il s’agit du script de Robert Pearman que j’ai légèrement modifié, et francisé.

Le script en question, qui doit être enregistré avec l’extension .ps1 (penser à modifier les variables de début de script) :

#################################################################################################################
#
# Version 1.4 February 2016
# Robert Pearman (WSSMB MVP)
# TitleRequired.com
# Script to Automated Email Reminders when Users Passwords due to Expire.
#
# Requires: Windows PowerShell Module for Active Directory
#
# For assistance and ideas, visit the TechNet Gallery Q&A Page. http://gallery.technet.microsoft.com/Password-Expiry-Email-177c3e27/view/Discussions#content
# Or Checkout my Youtube Channel - https://www.youtube.com/user/robtitlerequired
#
##################################################################################################################
# Please Configure the following variables....

$smtpServer="smtp.office365.com"
$expireindays = 14
$mailfrom = "expediteur@example.com"
$passwordFile = "D:\encrypted_password.txt"
$from = "Mot de passe <$mailfrom>"

$logging = "Enabled" # Set to Disabled to Disable Logging
$logFile = "C:\log_mail.csv" # ie. c:\mylog.csv

$testing = "Enabled" # Set to Disabled to Email Users
$testRecipient = "debug@example.com"

#
###################################################################################################################


# Force TLS1.2
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

# get password from file
$encryptedPassword = Get-Content $passwordFile | ConvertTo-SecureString
$Credential = New-Object System.Management.Automation.PsCredential($mailfrom, $encryptedPassword)

# Check Logging Settings
if (($logging) -eq "Enabled")
{
    # Test Log File Path
    $logfilePath = (Test-Path $logFile)
    if (($logFilePath) -ne "True")
    {
        # Create CSV File and Headers
        New-Item $logfile -ItemType File
        Add-Content $logfile "Date,Name,EmailAddress,DaystoExpire,ExpiresOn,Notified"
    }
} # End Logging Check

# System Settings
$textEncoding = [System.Text.Encoding]::UTF8
$date = Get-Date -format ddMMyyyy
# End System Settings

# Get Users From AD who are Enabled, Passwords Expire and are Not Currently Expired
Import-Module ActiveDirectory
$users = get-aduser -filter * -properties Name, PasswordNeverExpires, PasswordExpired, PasswordLastSet, EmailAddress |where {$_.Enabled -eq "True"} | where { $_.PasswordNeverExpires -eq $false } | where { $_.passwordexpired -eq $false }
$DefaultmaxPasswordAge = (Get-ADDefaultDomainPasswordPolicy).MaxPasswordAge

# Process Each User for Password Expiry
foreach ($user in $users)
{
    $Name = $user.Name
    $emailaddress = $user.emailaddress
    $passwordSetDate = $user.PasswordLastSet
    $PasswordPol = (Get-AduserResultantPasswordPolicy $user)
    $sent = "" # Reset Sent Flag
    # Check for Fine Grained Password
    if (($PasswordPol) -ne $null)
    {
        $maxPasswordAge = ($PasswordPol).MaxPasswordAge
    }
    else
    {
        # No FGP set to Domain Default
        $maxPasswordAge = $DefaultmaxPasswordAge
    }


    $expireson = $passwordsetdate + $maxPasswordAge
    $today = (get-date)
    $daystoexpire = (New-TimeSpan -Start $today -End $Expireson).Days

    # Set Greeting based on Number of Days to Expiry.

    # Check Number of Days to Expiry
    $messageDays = $daystoexpire

    if (($messageDays) -gt "1")
    {
        $messageDays = "dans " + "$daystoexpire" + " jours."
    }
    else
    {
        $messageDays = "aujourd'hui."
    }

    # Email Subject Set Here
    $subject="Votre mot de passe ESCDA expire $messageDays"

    # Email Body Set Here, Note You can use HTML, including Images.
    $body ="
    $name,
    <p> Votre mot de passe va expirer $messageDays<br>
    Pour changer votre mot de passe, appuyer sur Ctrl+Alt+Suppr et choisir Modifier un mot de passe <br>
    <p>Merci, <br>
    </P>"


    # If Testing Is Enabled - Email Administrator
    if (($testing) -eq "Enabled")
    {
        $emailaddress = $testRecipient
    } # End Testing

    # If a user has no email address listed
    if (($emailaddress) -eq $null)
    {
        $emailaddress = $testRecipient
    }# End No Valid Email

    # Send Email Message
    if (($daystoexpire -ge "0") -and ($daystoexpire -lt $expireindays))
    {
        $sent = "Yes"
        # If Logging is Enabled Log Details
        if (($logging) -eq "Enabled")
        {
            Add-Content $logfile "$date,$Name,$emailaddress,$daystoExpire,$expireson,$sent"
        }
        # Send Email Message
        Send-Mailmessage -Credential $Credential -smtpServer $smtpServer -from $from -to $emailaddress -Port "587" -useSsl -subject $subject -body $body -bodyasHTML -priority High -Encoding $textEncoding

    } # End Send Message
    else # Log Non Expiring Password
    {
        $sent = "No"
        # If Logging is Enabled Log Details
        if (($logging) -eq "Enabled")
        {
            Add-Content $logfile "$date,$Name,$emailaddress,$daystoExpire,$expireson,$sent"
        }
    }

} # End User Processing


# End

Ce script va parcourir les utilisateurs et isoler chaque utilisateur dont le mot de passe :

  • possède une date d’expiration
  • n’est pas encore expiré

et pour chacun d’eux, envoie un mail à l’adresse mail spécifiée dans leur profil AD, ou à l’adresse “$testRecipient” si aucune adresse n’est spécifiée.
(Note : en l’état, le script est en mode de test, et n’écrit donc qu’à l’adresse $testRecipient. pour activer l’envoi réel des mails aux utilisateurs, il faut passer $testing à Disabled dans les variables de début de script)

On retrouve la liste des utilisateurs traités (que leur adresse expire bientôt ou non) dans le fichier de log, par défaut C:\log_mail.csv. Ceci peut se désactiver en passant $logging à Disabled.

Tâche planifiée

Enfin, il faut activer l’éxécution automatique de ce script. Pour ceci, dans taskschd.msc, créer une tâche de base, mettre en programme/script powershell et en argument -windowstyle hidden -File "C:\chemin\vers\le\script\password_notification.ps1"

Lister les dates d’expiration de mot de passe

En powershell :
get-aduser -filter * -properties passwordlastset, passwordneverexpires |ft Name, passwordlastset, Passwordneverexpires

Source

09 Sep 2020, 00:00

Généralités sur les GPO

Généralités

La GPO est présente dans “Objets de Stratégies de groupe”. Elle n’y a aucun effet.

Elle doit être liée à un objet, qui peut être le Local system, un Domaine, un Site ou une OU (unité d’organisation).
Une fois liée, elle s’applique à cet objet, et tout ce qu’il contient.
On peut laisser le lien en place, mais le désactiver, via clic-droit sur le lien. ATTENTION, il s’agit de la notion de “Lien activé”, et non la notion d’“Appliquer” (qui est là pour forcer l’application de la GPO à la descendance).
Il est possible de désactiver les paramètres ordinateur et/ou utilisateurs d’une GPO.
Cela vaut le coup, après modification d’un GPO, d’attendre ~ une minute avant de faire gpupdate /force sur les clients, le temps qu’elle soit bien prise en compte et synchronisée sur les différents PDC.

Événements

On peut observer l’application des GPO dans l’observateur d’events
Journaux des apps et des services -> Microsoft -> Windows -> Group Policy -> Opérationnel

Quelques IDs d’events pratiques :

4004 : démarrage de l'application des GPO ordinateurs
8004 : fin de l'application des GPO ordinateurs

4005 : démarrage de l'application des GPO utilisateurs
8005 : fin de l'application des GPO utilisateurs

Filtrage et permissions

Lorsqu’on sélectionne une GPO, dans l’onglet Étendue, on peut voir le filtrage de sécurité, qui détermine les entités auxquelles cette GPO s’applique.
Par défaut, c’est “Utilisateurs authentifiés” qui, contrairement à ce que son intitulé laisse penser, contient les utilisateurs ET les ordinateurs du domaine.
C’est uniquement une inclusion positive, on ne peut pas faire d’exclusion.

Lorsqu’on va dans l’onglet Délégation, on peut gérer les droits d’accès à cette GPO ; notamment le droit de l’appliquer.
Si on clique sur “Avancé” (en bas à droite), on peut affiner les permissions, et on peut notamment refuser l’application de la GPO à certains utilisateurs/groupes choisis. Ceci permet de les exclure dans modifier toute la structure (OUs etc).

Attention, pour pouvoir ajouter un ordinateur, il faut sélectionner “Ordinateurs” dans les “Types d’objet” (par défaut, il est non-coché).

Priorité et héritage

Les GPO sont appliquées dans l’ordre suivant, avec priorité à la dernière occurence :

  1. Local
  2. Site
  3. Domaine
  4. OU

Il est possible de bloquer l’héritage, ce qui bloque l’héritage reçu et non l’héritage légué.
On peut également “Appliquer” (Enforced) un lien vers une GPO. Ceci aura pour effet que cette GPO ne pourra pas être outrepassée par une GPO dans une OU descendant de celle-ci, et l’héritage sera forcé vers les descendants, même si ceux-ci le bloquent.

Application unique

Dans l’onglet “Commun”, certains paramètres de GPO (uniquement la catégorie Préférences ?) ont l’option “Appliquer une fois et ne pas réappliquer”.
Ceci fonctionne comme indiqué : ça s’applique à la 1e actualisation des GPO, et plus par la suite.

Si on voulait à nouveau les réappliquer, mais 1 seule fois, on décoche la case, on valide, puis on recoche la case, et on valide ; ainsi elle sera à nouveau appliquée 1 fois à chaque poste/utilisateur, puis ignorée.

Groupes, OUs, Ordinateurs

La gestion des OUs et de leurs membres se fait dans Utilisateurs et Ordinateurs Active Directory. Les ordinateurs sont présents, en tant qu’objet Ordinateur, dans la catégorie Computers, mais également en tant que Groupe de sécurité “Ordinateurs du domaine” (donc dans la catégorie Users).
On peut sortir un ordinateur de la catégorie Computer, par exemple pour le mettre dans une OU, il restera par défaut dans le groupe “Ordinateurs du domaine”. Ceci permet de l’inclure quand même via les filtres de sécurité.

Lorsqu’on applique un filtre de sécurité, pour déterminer les (sous-)objets auxquels s’appliquer la GPO, ce sont des objets de type utilisateur, groupe, ordinateur, mais PAS des OU.
Les objets hors de ce filtre de sécurité n’ont, semble-t-il, pas le droit de lecture sur la GPO, donc impossibilité de l’appliquer.
Il me semble que cette mécanique empêche un compte hors du domaine (par exemple l’administrateur local d’un poste joint au domaine) d’appliquer quelque GPO que ce soit.

Lorsqu’une GPO est liée au domaine lui-même, elle concerne tous les objets du domaine, dont le groupe “Utilisateurs du domaine” et le groupe “Ordinateur du domaine”. Les paramètres utilisateurs et ordinateurs s’appliquent donc.
Toutefois, si on crée une OU SPECIAL_COMPUTER et une OU SPECIAL_USER, dans lesquelles on glisse respectivement un ordinateur, et un utilisateur, et que l’on lie une même GPO à ces 2 OUs, seuls les paramètres ordinateur s’appliqueront à la l’OU SPECIAL_COMPUTER et seuls les paramètres utilisateur s’appliqueront à l’OU SPECIAL_USER.

Il est possible de configurer un Loopback Processing Mode : on crée une GPO avec des règles utilisateurs, et on la lie à une unité contenant des ordinateurs. Avec l’activation du loopback, les stratégies utilisateurs s’appliquent aux utilisateurs loggés sur ces ordinateurs.
Pour ceci : modifier la GPO qui doit s’appliquer aux utilisateurs, et aller dans Config ordinateur / Stratégies / Modèles d'administration / Système / Stratégie de groupe et activer “Configurer le mode de traitement par bouclage de la stratégie de groupe utilisateur”.
La différence entre Remplacer et Fusionner est décrite dans le cadre de droite ; a priori il faut vraiment penser à choisir “Fusionner”.
Si les Modèles d’administration sont absents, il faut les ajouter.

Diagnostic des GPO qui ne s’appliquent pas

  • La GPO est-elle liée à l’objet désiré ? Directement ou via héritage ?
  • Le lien est-il activé ?
  • Des paramètres utilisateurs et/ou ordinateurs sont-ils désactivés ?
  • Le filtrage de sécurité donne-t-il les autorisations de lecture à l’objet qui doit les appliquer ?
  • Est-elle outrepassée par une autre GPO avec une priorité plus élevée ?
  • Pour les installations de logiciel, ceci se produit avant l’ouverture de la session ; l’emplacement du fichier doit donc être accessible en lecture par le groupe “Ordinateurs du domaine”
  • Pour les déploiements d’imprimante, il faut généralement déco/reco la session

http://woshub.com/group-policy-not-applied-troubleshooting/

Liste de paramétrages

https://memo.raphaelguetta.fr/post/gpo-settings

09 Sep 2020, 00:00

Liste de certains paramétrages GPO

Délai GPO

Forcer une fréquence de rafraichissement des GPO certains postes et/ou utilisateurs.

Config ordi :
Stratégies -> Modèles d’administration -> Système/Stratégie de groupe  
 - Configurer le mode de traitement par bouclage de la stratégie de groupe utilisateur : activé
 - Définir l’intervalle d’actualisation de la stratégie de groupe pour les ordinateurs : activer (choisir délai)

Config util :
Stratégies -> Modèles d’administration -> Système/Stratégie de groupe  
 - Définir l’intervalle d’actualisation de la stratégie de groupe pour les ordinateurs : activer (choisir délai)

Il faut un redémarrage (ou une déco session pour les users) pour que la fréquence d’actualisation soit respectée.

Défaire/désactiver le lien vers l’OU semble suffisant pour réinitialiser le réglage.

Powershell

Politique d’exécution des scripts

Config ordi
Stratégies -> Modèles d'aministration -> Composants Windows -> Windows Powershell
Activer l'exécution des scripts
 -> Activer, et choisr la politique

Verrouillage écran automatique

Voir détail ici :
https://memo.raphaelguetta.fr/post/windows-veille-verrouillage-ecran/

Customisation Explorer

Per-user : registre

HKCU
Software\Classes\CLSID\{86CA1AA0-34AA-4E8B-A509-50C905BAE2A2}\InprocServer32
(par défaut)
REG_SZ

Afficher secondes

Per-user : registre

HKCU
Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced
ShowSecondsInSystemClock
REG_DWORD
1

Customiser options affichage

Per-user

Config utilisateur -> Préférences -> Paramètres du panneau de configuration -> Options des dossiers
Nouveau -> Options des dossiers (au minimum Win Vista)
Choisir en graphique les options souhaitées

Office

Désactiver lancement auto Teams

Per-user ; 2 actions : une qui s’active à la première ouverture de session, et une systématique

Après install :

Config utilisateur -> Stratégies -> Modèles d'administration -> Microsoft Teams
Empêcher le démarrage automatique de Microsoft Teams après l’installation -> Activé

Par registre (option systématique) :

HKCU
Software\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppModel\SystemAppData\MSTeams_8wekyb3d8bbwe\TeamsTfwStartupTask
State
REG_DWORD
0

06 Dec 2019, 00:00

Serveur OpenVPN ponté sous Debian Buster

Mentionné sans aucun password, en rajouter si désiré.
Prévu pour permettre un lien avec le réseau local distant, mais sans redirection de l’ensemble du trafic via VPN.

Préparation générale

apt install bridge-utils openvpn

Création de la PKI et des certificats/clés

cd /etc/openvpn
make-cadir easy-rsa/
cd easy-rsa
nano vars

Trouver les lignes qui définissent les noms de notre organisation et les modifier comme souhaité ;
Passer la taille de clés à 4096b ;
Changer le temps d’expiration par défaut du CA et des certificats en nombre de jours(ici, 10 ans)

set_var EASYRSA_REQ_COUNTRY    "FR"
set_var EASYRSA_REQ_PROVINCE   "IDF"
set_var EASYRSA_REQ_CITY       "Paris"
set_var EASYRSA_REQ_ORG        "Ma badass orga"
set_var EASYRSA_REQ_EMAIL      "me@example.net"
set_var EASYRSA_REQ_OU         "Mon OU qui déchire"

set_var EASYRSA_KEY_SIZE        4096

set_var EASYRSA_CA_EXPIRE       3650

set_var EASYRSA_CERT_EXPIRE     3650

# Le CRL a aussi une date d'expiration, on la passe à 10 ans
set_var EASYRSA_CRL_DAYS        3650

Puis on lance toute la procédure

# Initier la PKI ;
# Supprime la PKI si déjà existante
./easyrsa init-pki

# Créer les params Diffie-Hellman
./easyrsa gen-dh

# Créer les fichier de l'autorité de certif
./easyrsa build-ca nopass  # nopass pour absence de mot de passe
# Génération et signature de la CSR (signing request) du server, avec définition du Common Name
./easyrsa gen-req mon-server-vpn nopass
./easyrsa sign-req server mon-server-vpn # le "server" indique le type
# Vérification si souhaitée
openssl verify -CAfile pki/ca.crt pki/issued/mon-server-vpn.crt

# Génération et signature d'un kit de connexion pour un client
./easyrsa gen-req mon-pc-client nopass
./easyrsa sign-req client mon-pc-client

Les certificats sont dans issued, les clés dans private.

Génération TLS
Ce fichier devra être présent sur chacun des clients

openvpn --genkey --secret ta.key
mv ta.key /etc/openvpn/easy-rsa/pki/

Réseau

Activer forward IPv4

echo 'net.ipv4.ip_forward = 1' >> /etc/sysctl.d/10-network.conf

Fichier /etc/network/interfaces qui crée le bridge et l’adaptateur TAP au démarrage ;
vérifier la cohérence des noms d’interface

auto lo
iface lo inet loopback

auto br0
iface br0 inet static
    pre-up openvpn --mktun --dev tap0
    post-down openvpn --rmmtun --dev tap0
    bridge_hw 00:11:22:aa:bb:cc
    bridge_ports eth0 tap0
    address 192.168.1.2
    netmask 255.255.255.0
    gateway 192.168.1.1

Les interfaces impliquées dans le bridge (eth0, tap0) n’ont pas besoin d’être configurées dans ce fichier.
La directive bridge_hw permet de spécifier l’adresse MAC du bridge (qui sera constatée depuis le réseau, le routeur etc). Par souci de simplicité, je conseille de la fixer à la même valeur que la carte réseau physique (eth0 par exemple). Sinon, il me semble qu’elle prendra la première valeur “alphabétique” entre les différentes cartes réseau impliquées, et l’adresse de la carte tap0 peut varier d’un démarrage à l’autre.

Définition du fichier de conf du server

On peut récupérer le fichier d’exemple ainsi :

cd /etc/openvpn/server
cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz ./
gunzip ./server.conf.gz
mv server.conf mon-server-vpn.conf

En voici une version minimaliste, à mettre dans /etc/openvpn/server/ :

port 1194
proto udp
dev tap0 # doit être en accord avec le fichier interfaces
ca /etc/openvpn/easy-rsa/pki/ca.crt
cert /etc/openvpn/easy-rsa/pki/issued/mon-serveur-vpn.crt
key /etc/openvpn/easy-rsa/pki/private/mon-server-vpn.key  # This file should be kept secret
dh /etc/openvpn/easy-rsa/pki/dh.pem
server-bridge
keepalive 10 120
cipher AES-256-CBC
compress lz4-v2
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
log-append /var/log/openvpn/openvpn.log
verb 3
explicit-exit-notify 1

# Pour TLS
tls-auth /etc/openvpn/easy-rsa/pki/ta.key 0  #" 0 pour le server, 1 pour les clients
#auth SHA256  ## ???

On peut vérifier qu’il se lance bien via

openvpn /etc/openvpn/server/mon-server-vpn.conf

Si “Initialization Completed”, c’est gagné.

Rotation des logs

Dans la section précédente, on a défini /var/log/openvpn/openvpn.log comme chemin pour les journaux de connexion.
On peut le logrotater avec le fichier /etc/logrotate.d/openvpn qui contiendra ceci :

/var/log/openvpn/openvpn.log {
    missingok
    weekly
    compress
    rotate 8
}

Source

Activation du service (donc démarrage automatique) via systemd

systemctl enable openvpn-server@mon-server-vpn.service

Le nom entre @ et .service doit correspondre au nom du fichier de configuration.

Ajout du timestamp dans les logs

nano /etc/systemd/system/multi-user.target.wants/openvpn-server@mon-server-vpn.service
et supprimer --suppress-timestamps de la ligne ExecStart=

(même remarque que ci-dessus concernant le nom du fichier)

Client

Installer le client VPN souhaité selon la plateforme.
Le fichier de conf doit être en conformité avec le serveur.
Sous Windows, avec OpenVPN GUI, si on met les chemins complets, syntaxe de type :

"C:\\Users\\myuser\\OpenVPN\\ca.crt"

Si les fichiers sont dans le même dossier que la conf, on peut mettre simplement les noms de fichier.
Un fichier de conf client compatible avec le fichier de conf serveur ci-dessus :

client

# Adapter les noms de fichier
ca ca.crt
cert mon-pc-client.crt
key mon-pc-client.key

# Adapter l'IP/domaine et le port
remote example.com 1194

dev tap
proto udp
resolv-retry infinite
nobind
persist-key
persist-tun
cipher AES-256-CBC
compress lz4-v2
verb 3
tls-auth ta.key 1

Pour lancement auto via systemd :

systemctl enable openvpn-client@mon-pc-client.service

Révocation de certificat

cd /etc/openvpn/easy-rsa/
./easyrsa revoke mon-pc-client
./easyrsa gen-crl   ## Crée/update pki/crl.pem

## Ajouter le fichier dans la conf server
echo "crl-verify /etc/openvpn/easy-rsa/pki/crl.pem" >> /etc/openvpn/server/mon-server-vpn.conf

Puis restart le server ; la clé de mon-pc-client ne sera désormais plus acceptée.
Il faut relancer la commande ./easy-rsa gen-crl à chaque fois qu’un certificat est révoqué, pour mettre à jour le fichier crl.pem.

Attention : le CRL a aussi une durée d’expiration ! Elle peut être paramétrée dans le fichier vars. Pour la visualiser :
openssl crl -in pki/crl.pem -text | grep "Next Update"

Réactivation d’un certificat révoqué

Je n’ai pas trouvé de commande intégrée pour ce faire. Voici comment le faire à la main, bien que ça semble un peu hacky.

D’abord on trouve le serial correspondant au client à réactiver (ici, “monClientRevoque”) :
cd /etc/openvpn/easy-rsa && cat pki/index.txt | grep monClientRevoque qui donne un résultat de ce genre :
R 300956789123Z 200356789123Z 40FDF33486D24371D96668D056CBF883 unknown /CN=monClientRevoque

Il faut éditer ce fichier pour remplacer le R initial par un V, et supprimer le 3e champ (ici 200356789123Z) ; on a donc une ligne de ce genre :
V 300956789123Z 40FDF33486D24371D96668D056CBF883 unknown /CN=monClientRevoque
ATTENTION, il faut que le nombre de tabulations aligne correctement la ligne avec les autres lignes valides, sinon on aura des erreurs plus tard.

Puis on regénère le CRL avec la commande suivante :
./easy-rsa gen-crl

Le client devrait à nouveau avoir le droit de se connecter. Si on besoin de récupérer les fichiers du kit de connexion, ils sont disponibles dans ./pki/revoked/certs_by_serial, ./pki/revoked/private_by_serial et ./pki/revoked/reqs_by_serial et nommés en fonction du numéro de série (ici 40FDF33486D24371D96668D056CBF883).

Il est conseillé de replacer ces 3 fichiers à leurs emplacements initiaux (pki/issued/, pki/private/ et pki/reqs/), et avec le nom initial (monClientRevoque), pour éviter des erreurs si l’on souhaite révoquer à nouveau ce client.
Il y’aura toutefois un message d’impossibilité de supprimer le fichier dans pki/certs_by_serial/, mais ce message n’est pas bloquant.

Lister les clients connectés

cat /var/log/openvpn/openvpn-status.log | sed '/CLIENT_LIST/!d' | cut -d"," -f2 | sed '/CLIENT_LIST/d' | sort -d

05 Nov 2019, 00:00

Let's encrypt / Certbot

Visualiser les certificats existants :

cerbot certificates

Il vaut mieux créer un certificat par domaine, plutôt qu’un pour tous les domaines (ce qui est le cas par défaut si non précisé) Pour créer un nouveau certificat pour un domaine précis :

sudo certbot --apache -d example.com --rsa-key-size 4096

Les fichiers se retrouvent dans /etc/letsencrypt/archive/ et sont linkés dans /etc/letsencrypt/live/

Pour rajouter un domaine à un certificat existant :

certbot --expand -d example.com,new.example.com

Pour supprimer un certificat, il semble qu’il n’y ait d’autre moyen que de supprimer les dossiers concernés dans les dossiers live, archive et renewal (dans /etc/letsencrypt/ )

Pour renouveler tous les certificats :

certbot renew

Pour renouveler seulement un domaine précis, au choix :

certbot certonly -d example.com

Vérifier la longueur d’une clé en appel direct d’un site web :

echo | openssl s_client -connect example:443 2>/dev/null | openssl x509 -text -noout | grep "Public-Key"

28 Sep 2019, 00:00

Gestion des GPO et ajout de fichiers ADMX

gpedit.msc sert uniquement à modifier les stratégies de groupes locales. La commande est disponible sur les Windows standards (Pro en tout cas).
gpmc.mmc sert à modifier, sur un controlleur de domaine, les GPO qui seront déployées chez les clients via Active Directory. Si cette commande n’est pas disponible sur un serveur, c’est probablement que le rôle de gestion des stratégies de groupes n’a pas été installé (ajouter des fonctionnalités -> Gestion des stratégies de groupe).

Par défaut, toutes les GPO ne sont pas disponibles dans l’outil gpmc.msc. Notamment, la catégorie “Modèles d’aministration”. Or, si on lance gpedit.msc, on voit que beaucoup de stratégies sont disponibles sous cette catégorie.

Pour ajouter des stratégies à l’outil gpmc.msc, on utilise des fichiers ADMX (ou, historiquement, ADM). Ils sont généralement déployés via les mises à jour Windows, mais ne sont disponibles que pour le système local. On les trouve dans le dossier %windir%\PolicyDefinitions, sous la forme de fichiers ADMX associés à des fichiers de localisation ADML dans des répertoires de langue (par exemple fr-FR).
On peut prendre tous ces fichiers, et les copier dans le dossier %windir%\SYSVOL\sysvol\mon.domaine.fr\Policies\PolicyDefinitions

27 Sep 2019, 00:00

FQDN d'un controlleur de domaine dans une mauvaise zone de sécurité d'Explorer

Description du problème chez Microsoft Tuto pour l’activation par GPO

Dans certains cas, lorsque l’on est dans un domaine, et que l’on cherche à accéder à un serveur via son nom complet(FQDN, du type server.domain.example.com), alors le poste considérera que ce domaine appartient à la zone de confiance “internet”, et donc bloquera l’ouverture de certains documents, scripts, exécutables etc.
Pour corriger ce problème, on peut aller dans les options internet du poste en question, et passer les sites *.domain.example.com en zone Intranet.

Mais on peut aussi déployer ceci sur tous les postes du domaine, via GPO, ce qui évite d’avoir à le faire à la main sur chaque poste. Pour ceci, sur un controlleur de domaine :

  • S’assurer que les ficheirs ADMX ont été installés
  • gpmc.msc
  • Configuration utilisateur -> Stratégies -> Modèles d'administration -> Composants Windows -> Internet Explorer -> Panneau de configuration Internet -> Onglet Sécurité et activer le paramètre Liste des attributions de site aux zones Lorsqu’on rentre dans les propriétés du paramètre, on peut afficher les zones, et associer *.domaine.example.com à la valeur 1.
    (1 : zone intranet ; 2 : sites de confiance ; 3 : internet ; 4 : sites ensibles)

17 Apr 2019, 00:00

Renommage d'un domaine Windows

But de la manoeuvre : transformer travail.domaine.com en work.ville.nouveaudomaine.fr, ainsi que les noms NetBIOS de TRAVAIL vers WORK.

Sources : Pour du Server 2003
Pour du Server 2008
Une synthèse
Une autre synthèse

Note préalables

  • Les serveurs Exchange ne supportent pas le changement de nom (sauf Exchange 2003, et uniquement le nom DNS, pas le nom NetBIOS)
  • Je n’aborde pas ici la mise à jour des relations de confiance entre domaines, elle est détailée dans l’article de chez Microsoft
  • Il est très fortement conseillé de backuper les données, ainsi que l’état du système, pour pouvoir le restaurer si besoin
  • Il faut faire les opérations depuis un serveur intégré au domaine, mais qui n’est pas un contrôleur de domaine. Celui-ci devra avoir la fonctionnalité “Administration de serveur distants” (qui donne notamment accès à la commande rendom)
  • Si une relation de basculement entre 2 serveurs DHCP existe, elle ne fonctionnera (peut-être) plus après renommage du domaine ; il me semble que le plus simple est d’identifier 1 serveur DHCP principal, à jour, de déconfigurer le basculement, d’effectuer le renommage, puis de reconfigurer e basculement avec le nouveau nom.

Création de la nouvelle zone DNS

Il faut au préalable créer une nouvelle zone DNS. Pour ceci, Gestionnaire DNS -> nouvelle zone
Dans un cas simple, laisser les choix par défaut (zone principale, intégrée à l’AD, vers tous les serveurs DNS executés sur des DC dans ce domaine). Adapter si besoin.
Nom de la zone à créer : work.ville.nouveaudomaine.fr

Changement du nom de domaine

Depuis la station de contrôle, on lance une invite de commande en administrateur. Je conseille de dédier un répertoire à la migration

mkdir C:\migration_domaine
cd C:\migration_domaine

Puis

rendom /list

Ceci crée un fichier domainList.xml dans le répertoire courant, qu’il faut éditer en remplaçant l’ancien nom de domaine par le nouveau (il est sage de le backuper avant modification).
On remplace dedans les occurences de travail.domaine.com par work.ville.nouveaudomaine.fr.

On lance ensuite

rendom /showforest

Ceci affiche les infos updatées selon le fichier DomainList.xml modifié. Il ne modifie rien, mais permet de vérifier que la nouvelle organisation est bien celle attendue.

Ensuite,

rendom /upload

Ceci crée le fichier Dclist.xml et l’envoie sur les controlleurs de domaine. Cette étape freeze la foret pour éviter les interactions indésirables entre la migration de domaine, et d’éventuelles modifications sur la forêt.

Microsoft conseille ensuite de répliquer les infos de configuration depuis le serveur Domain Naming Master (mettre son hostname à la place dans la commande suivante) :

repadmin /syncall /d /e /P /q DomainNamingMaster

Si besoin de le connaitre le serveur qui joue le rôle de DNM, on a la commande

dsquery server -forest -hasfsmo Name

Vérifier dans le serveur DNS que nous avons IMPÉRATIVEMENT toutes les entrées définies dans cet article

On peut ensuite lancer la commande

rendom /prepare

qui va vérifier que tous les DCs sont aptes à être mis à jour. Ceci se vérifie sur le fichier Dclist.xml (les DC doivent être en état Prepared).

Enfin,

rendom /execute

qui lance effectivement la mise à jour. Les DCs vont rebooter automatiquement.

Penser à vérifier après reboot que le login se fait bien en utilisant le nouveau domaine, ainsi que les panneau de conf Système.
Vérifier le fichier Dclist.xml, les DCs doivent être à l’état Done.
Si il subsiste un état “Error”, il est possible de compléter la ligne <Retry><Retry> en <Retry>yes<Retry>, puis de réaplliquer cette étape (les DCs à l’état Done ne seront pas réaffectés par la manipulation).
Si un DC reste malgré tout à l’état Error, il faut lui enlever (puis remettre) les rôles AD-DS.

Puis sur un (chaque?) DC après redémarrage :

gpfixup /olddns:travail.domaine.fr /newdns:work.ville.nouveaudomaine.fr

qui met à jour et répare les dépendances de nom de domaine dans le stratégies de groupe après changement.

De même,

gpfixup /oldnb:TRAVAIL /newnb:WORK

qui met à jour le nom NetBIOS du domaine.
À ce stade, il faut redémarrer 2 fois chaque poste client, puis vérifier que son FQDN prend bien en compte le nouveau domaine.

On peut enfin lancer la commande

rendom /clean

qui supprime les références à l’ancien domaine.
Attention, les postes non rebootés 2 fois après cette étape devront être manuellement retirés de l’ancien domaine, puis réintégrés dans le nouveau domaine.

Enfin,

rendom /end

qui finalise la procédure et dévérouille la forêt.

Après connexion d’un client, on peut vérifier que celui-ci est bien présent dans la zone récemment créée des serveurs DNS.

Actions manuelles pour finaliser le changement

Vérifier/updater les chemins du DFSN, des partages réseaux déployés et des imprimantes déployées

  • Les FQDN des clients intègrent automatiquement le nouveau nom de domaine, mais pas les serveurs. Pour les renommer correctement, il faut ajouter le FQDN du nouveau domaine, puis le mettre en principal. Pour ceci,

    netdom computername DC1.travail.domaine.com /add:DC1.work.ville.nouveaudomaine.fr netdom computername DC1.travail.domaine.com /makeprimary:DC1.work.ville.nouveaudomaine.fr

  • Les partages réseaux déployés par les GPO ne sont pas mis à jour automatiquement pour utiliser le nouveau domaine/nom d’hôte, il faut le faire à la main

  • De même pour les imprimantes déployées par GPO. Si le serveur les hébergeant a changé de nom d’hôte, il faut les mettre à jour

  • si un espace de nom DFS (DFSN) est utilisé, il ne sera pas non plus mis à jour automatiquement

  • lorsque tout fonctionnait bien j’ai backupé (exporté) puis supprimé la zone DNS de l’ancien domaine des serveur DNS pour en effacer les traces et m’assurer que tout reposait bien sur le nouveau domaine

  • la synchronisation user/password avec Azure AD Connect ne fonctionnait plus, il a fallu la réinitialiser selon ce post

Dcdiag /test:DNS /DnsRecordRegistration /s:domaincontroller

Vérifier le serveur DHCP et le validité du basculement de l’étendue, s’il existe.

16 Apr 2019, 00:00

Désactivation et réactivation des services de synchronisation Azure AD Connect

Source principale

Il peut parfois être nécessaire de reconfigurer complètement les services de synchronisation entre un Active Directory local et les services Office 365 (Azure Active Directory Connect).

Pour ceci, il faut les désactiver chez O365 via Powershell, les désinstaller du serveur local, puis réinstaller AAD Connect sur le serveur local.

On ouvre une session Powershell en admin.
Si les outils de gestion PS vers O365 ne sont pas installés, on le fait via
Install-Module -Name MSonline

(si message de commande introuvable, il est nécessaire d’installer les PackageManagement, dispo ici

On initialise la variable de connection via
$msolcred = get-credential
en rentrant les ids d’un admin sur O365.

On établit la connection aux services O365
connect-msolservice -credential $msolcred
Il est ensuite temps de supprimer les applis AAD Connect du serveur local (ajout/suppression de programme).
Une fois désinstallés, on lance la commande PS :
Set-MsolDirSyncEnabled -EnableDirSync $false
et on valide avec Y.

pour obtenir l’état de synchro, on lance la commande
Set-MsolDirSyncEnabled -EnableDirSync $false
qui doit désormais renvoyer “false”.

Il faut plusieurs heures (voire une nuit) à Microsoft Azure pour prendre réellement en compte l’arrêt de la synchro. Lorsque ce sera fait, l’interface d’admin O365 n’affichera plus le status AAD Connect, ni l’état (Synchronisé/Dans le cloud) des Utilisateurs O365. Les utilisateurs anciennement synchronisés seront de facto considérés comme utilisateurs cloud.

Une fois que la suppression de la synchro est bien prise en compte par les serveurs O365, il suffit de réinstaller Azure AD Connect, avec éventuellement une passe préalable de IdFix.
Cf. ce post

La synchro reprend normalement assez rapidement, et quelques heure plus tard, l’état AAD Connect réapparait dans le centre d’administration O365.

10 Feb 2019, 00:00

Notes sur fail2ban

Généralités

2 articles qui m’ont inspiré :
http://xmodulo.com/configure-fail2ban-apache-http-server.html
https://www.digitalocean.com/community/tutorials/how-to-protect-ssh-with-fail2ban-on-centos-7

fail2ban se base sur l’analyse des logs pour bannir des adresses ip (via, par défaut, la création de règles iptables) qui auraient enfreint certaines règles.
Les expressions régulières qui servent à analyser les fichiers de conf se trouvent dans le dossier /etc/fail2ban/filter.d/.

Les fichiers de conf sont lus dans l’ordre suivant, sachant que c’est la dernière mention d’un paramètre redondant qui sera prise en compte :

/etc/fail2ban/jail.conf
/etc/fail2ban/jail.d/*.conf
/etc/fail2ban/jail.local
/etc/fail2ban/jail.d/*.local

Il est conseillé de ne pas toucher aux fichier .confs (ce qui permet entre autres de ne pas perturber les mises à jour système) mais de rajouter nos propres règles dans des fichiers .local.

On voit dans jail.conf des paramètres par défaut (sous la balise [DEFAULT]) :

# "bantime" is the number of seconds that a host is banned.
bantime  = 600

# A host is banned if it has generated "maxretry" during the last "findtime"
# seconds.
findtime  = 600

# "maxretry" is the number of failures before a host get banned.
maxretry = 5

On voit que si une ip échoue à se connecter 5 fois de suite (maxretry) en moins de 600 secondes (findtime), alors elle sera bannie pendant 600 secondes (bantime).
Il y’a aussi dans cette même section un nom fichier de filtre par défaut, qui reprend le nom de la jail :

filter = %(__name__)s

Cela dit que le fichier de filtre qui sera récupéré est le même que le nom de la jail.

Plus bas, on voit des exemples de jails, de type

[sshd]

port    = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s

Ces jails sont définies par défaut, mais non activées. Pour ceci, il faut leur donner le paramètre enabled = true. Par défaut, sous Debian, seul le service sshd est protégé par fail2ban, via le fichier /etc/fail2ban/jail.d/defaults-debian.conf.

Installation et configuration

Pour installer :

sudo apt install fail2ban

On peut ensuite créer par exemple un fichier /etc/fail2ban/jail.d/ssh.local qui contiendra :

[sshd]
enabled = true
port = 12345
findtime  = 60
maxretry = 5

afin de spécifier un port custom, et laisser le droit à 5 essais par minute.

On peut aussi créer /etc/fail2ban/jail.d/apache.local pour activer fail2ban pour apache :

# detect password authentication failures
[apache-auth]
enabled  = true
port     = http,https
findtime  = 60
maxretry = 5

pour un fail2ban sur l’authentification par mot de passe.