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.

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

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

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"

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

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)

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.

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.

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.

Mot de passe pour un répertoire

Le fichier .htaccess est un fichier en texte clair, qui permet de définir le message affiché lors de la demande de mot de passe, ainsi que le fichier dans lequel Apache ira vérifier que l’utilisateur/mot de passe est correct (le .htpasswd).
Dans mon cas, je choisis de faire un fichier .htpasswd par répertoire, car tous les répertoires ne doivent pas être accessibles aux mêmes utilisateurs.

Je crée le .htpasswd :

cd /path/to/site/files
htpasswd -c .htpasswd user1

L’option -c sert à créer/réécrire le fichier. Si on ne la spécifie pas, ça rajoute une nouvel utilisateur qui pourra lire ce répertoire.

Ensuite, on ajoute le .htaccess, qui va directement protéger le répertoire

nano .htaccess

Dans lequel on met :

AuthType Basic
AuthUserFile "/path/to/site/files/.htpasswd"
AuthName "Identification pour ce dossier ?"
Require valid-user

Il semble indispensable d’indiquer le chemin complet vers le .htpasswd, sans quoi le serveur retourne une erreur 500.

Dans le cas où le repértoire est en dehors des répertoires standards de Apache (/usr/share ou /var/www), il faut les ajouter à la main dans le /etc/apache2/apache2.conf ou dans /etc/apache2/sites-available/00X-mon-site.conf :

<Directory /path/to/site/files/>
	    Options Indexes FollowSymLinks
	    AllowOverride AuthConfig
	    Require all granted
</Directory>

Ceci permet respectivement de suivre les liens symboliques (utile pour mon setup), de permettre d’outrepasser les droits localement (et donc d’utiliser le htaccess), et permet à tout le monde (toutes les IPs notamment) d’accéder au site.

AllowOverride

Cette directive doit être présente dans le fichier de configuration d’apache (dans /etc/apache2/ sous Debian, dans /usr/local/apache2/conf/httpd.conf pour l’image docker d’apache) pour autoriser, entre autres, le .htaccess.

Par défaut, c’est None, qui n’autorise rien dans les htaccess (et renverra une erreur 500 si un htaccess est utilisé). On peut remplacer None par les différents mot-clés (AuthConfig FileInfo Indexes Limit Options) ou All pour l’ensemble. Chacune de ces directives est un ensemble de sous-directives.

Pour un filtrage plus granulaire, on peut utiliser la directive AllowOverrideList pour autoriser uniquement certaines sous-directives.

Équivalences AD / O365 / EAC si ADConnect paramétré

Globalement, l’autorisation “Gérer” de AD correspond au status “Propriétaire” sous O365.
Ce qui existe dans l’AD est transmis vers O365/EAC, l’inverse n’est pas (forcément) vrai. Si on souhaite avoir les éléments en local, il FAUT les créer en local.
Les autorisations d’envoyer un mail “en tant que” (par ex. en tant qu’un groupe de distribution) se gèrent dans tous les cas dans l’EAC, car dans le setup actuel, il n’y a pas de serveur Exchange en local, seulement sur O365.

Utilisateurs

Un utilisateur créé sous AD apparaîtra dans O365 sous “Utilisateurs actifs” et dans EAC sous “Destinataires -> Boîtes aux lettres”. C’est un utilisateur à part entière avec boîte mail dédiée.

Groupes de sécurité

Un groupe de sécurité créé sous AD peut avoir une adresse mail renseignée ou non.

Si adresse, il apparaîtra dans O365 sous “Groupes” (en tant que “Sécurité avec extension messagerie”) et dans EAC sous “Destinataires -> Groupes” (en tant que “Sécurité à extension courrier”).

Si aucune adresse mail n’est renseignée, il apparaitra sous O365 sous “Groupes” (en tant que “Sécurité”) et n’apparaitra PAS dans EAC.

C’est avant tout un groupe pour l’organisation de l’entreprise (GPO de l’AD, etc.), qui peut également être utilisé pour remettre un courrier à tous les membres de ce groupe.
Si un autre groupe est lui-même membre du groupe, les utilisateurs de cet autre groupe ne recevront le mail QUE SI cet autre groupe a une adresse de messagerie renseignée dans ses propriétés (ceci permet de couper le transfert vers les N+1 par exemple, si on ne met pas d’adresse mail).

Groupes de distribution

Un groupe de distribution créé sous AD apparaitra dans O365 sous “Groupes” en tant que “Liste de distribution” et dans EAC sous “Destinataires -> Groupes” en tant que Liste de distribution. Il faut lui définir une adresse mail, sans quoi son intérêt est très limité (il semble qu’il n’apparaisse as dans EAC si pas d’adresse mail renseignée).

C’est un alias qui va rediriger le courrier envoyé à l’adresse en question vers tous les membres inclus dedans (permet une gestion différente des groupes de sécurité).
Si un sous-groupe est lui-même membre du groupe, les utilisateurs de ce sous-groupe ne recevront le mail QUE SI le sous-groupe a une adresse de messagerie renseignée dans ses propriétés.

L’autorisation “Send As” ne peut être définie que directement dans le EAC. Par contre, si le groupe a été créé sur AD, l’autorisation “Send On Behalf” est définie dans ADSI, sous l’attribut “publicDelegates”. Il faut toujours attendre quelques (dizaines de) minutes pour que les changements soient effectifs sous Exchange.
Dans certains cas, le client Outlook d’un utilisateur peut rester “bloqué” sur l’intention d’envoyer “de la part de” (on behalf), ce qui echouera si la seule autorisation accordée est “send as”. Pour “réinitialiser” le comportement du client, il faut désactiver puis réactiver le mode “en cache” du compte Exchange.

Boîte au lettres partagées

Il s’agit d’une boîte à part entière, avec son propre stockage/quota (quota de 99Go à l’heure de cet article). Elle permet de centraliser des messages partagés par plusieurs utilisateurs, ainsi que le calendrier. Sur l’Outlook de l’utilisateur, la boîte sera distincte de celle de l’utilisateur.
Elle permet également de partager un calendrier entre tous les utilisteurs.

Comme nous n’avons dans le cas présent pas de serveur Exchange en local, il ne me semble pas possible d’en créer une sur l’AD. Elle peut être créée dans l’EAC sous “Destinataires -> Boîte aux lettres partagée”.

Elle n’apparaitra pas dans l’AD, mais dans O365 sous les “Utilisateurs actifs”, et bien sûr dans l’EAC.

Création d’une boite aux lettres partagées avec déploiement automatique (dont calendrier)

Dans le centre d’administration Exchange (EAC), on peut aller dans Recipients -> Shared, et créer une boite aux lettres partagées. Tous les utilisateurs qui sont entrés dans les propriétés de la boite partagée -> Mailbox delegation -> Full access verront la boite mail ainsi que son calendrier se déployer automatiquement sur leur client Outlook (avec toutefois un délai jusqu’à une heure).
Ceci correspond à une vraie boîte mail à part entière, avec son propre espace de stockage (quota de 99Go à l’heure de cet article) et apparaitra sur le client outlook séparée de la boite principale.

Il semblerait que l’ajout d’un groupe de sécurité, même avec adresse mail renseignée, ne déploie pas automatiquement les boites et calendriers chez les membres du groupe.

Liste de distribution (alias) sur EAC

Dans le EAC -> Recipients -> Groups, on peut créer des listes de distributions. Ceci ne correspond pas à une vraie boîte mail, mais plutôt à un alias. Les messages sont transférés à tous les utilisateurs définis dans les propriétés de la liste -> Membership.
Si on souhaite qu’un utilisateur puisse écrire depuis l’adresse de la liste de distribution, il faut ajouter l’utilisateur en question dans les propriétés de la liste -> Group delegation, et ajouter son nom sous Send As (envoi en tant qu’alias) ou bien Send on Behalf (envoi en tant que user au nom de alias).

Pour que l’utilisateur puisse envoyer des messages depuis sont Outlook (version de bureau), il faut ajouter le champ De qui est masqué par défaut. Sous 2016, ceci peut se faire dans la fenêtre de rédaction d’un message, sous l’onglet Options. Ensuite, on ajoute à la main le nom de l’alias qui doit servir à envoyer le message. Si les paramètres serveur sont corrects, l’envoi devrait fonctionner. Sinon, essayer de désactiver puis réactiver le mode “en cache” du compte Exchange.