Titre 1
Titre 2
Titre 3
Titre 4
Titre 5
Titre 6
Elément en italique
Élément en italique aussi (étoiles)
Élement en gras
Elément en italique
Élément en italique aussi (étoiles)
Élement en gras
Sous Linux, il arrive que, pour économiser de l’énergie, la carte son se mette en veille après quelques temps d’inactivité. Ceci génère chez moi des craquements assez désagréables lors de sa remise en fonctionemment, ou parfois un craquement très régulier tout le long de la veille.
Pour voir si la mise en veille est activée :
cat /sys/module/snd_hda_intel/parameters/power_save
S’il contient autre chose que 0, alors le mode powersave est activé.
Pour le désactiver, on peut ajouter le fichier /etc/modprobe.d/snd_disable_powersave.conf et entrer dedans la ligne suivante :
options snd_hda_intel power_save=0
Puis redémarrer, ou bien décharger/recharger le module.
Mac OS a tendance à laisser des fichiers un peu partout dans les répertoires auxquels il a accès en écriture.
Pour les supprimer, sous Windows :
cd /d X:\infected\folder
del /s /q /f /a .DS_STORE
del /s /q /f /a:h ._.*
del /s /q /f /a:h ._* # cela peut suprrimer aussi certains fichiers de chrome, attention s'il y'a un profil dans le chemin !
del /s /q /f /a __MACOSX
Le /a permet de matcher quels que soient les attributs.
Sous linux :
find ./ \( -name ".AppleDouble" -o -name .DS_Store -o -name ._.* \) -exec rm -Rf {} \;
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
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
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.
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.
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.
Les enregistrements DNS de type SPF et DMARC servent à essayer d’assurer la bonne provenance d’un mail en identifiant l’IP du serveur qui a envoyé le message (SPF), et en définissant des attitudes à adopter dans le cas d’un échec (DMARC).
Il est aussi possible de signer cryptographiquement des messages (DKIM), mais ceci n’est pas couvert ici.
Un enregistrement spf est de type TXT, s’applique au (sous-)domaine dont on veut essayer de légitimer les mails. Il peut ressembler à ceci, pour example.com :
v=spf1 mx ip4:1.2.3.4 include:spf.fournisseurmailing.fr -all
v= déclare la versionmx déclare que tous les serveurs MX de example.com ont le droit d’envoyer des mails en tant que someone@example.comip4: déclare une adresse (ou une plage grâce à un masque) qui a le droit d’envoyer des mailsinclude: donne une (sous-)domaine sur lequel aller chercher un enregistrement spf qui déclarerait encore d’autres entrées.Danc cet exemple, via l’entrée include, tous les serveurs que mon fournisseur de mailing-list a lui-même autorisé via le paramétrage spf de son domaine on le droit d’envoyer des mails en notre nom. On peut vérifier le contenu de ce spf via la commande dig TXT spf.fournisseurmailing.fr.
Le -all sert à définir strictement ces serveurs autorisés, voir cette page.
Dans un cas où il y’aurait besoin d’entrer beaucoup d’adresses ip différentes, cela peut ne pas rentrer dans un seul champ DNS. Il est alors possible de se créer un sous-domaine (par exemple spf.example.com), qui sera inclus dans le spf principal.
Par exemple, pour example.com :
v=spf1 mx ip4:1.2.3.4 ip4:5.6.7.8 ip4:9.10.11.12 include:spf.example.com -all
et pour spf.example.com
v=spf1 ip4:188.12.0.0/16 -all
pour autoriser les adresses IP 1.2.3.4 , 5.6.7.8 , 9.10.11.12 ainsi que toutes les adresses de type 188.12.X.X à envoyer des mails au nom de example.com
Attention, il ne faut toutefois pas déclencher plus 10 requêtes DNS pour évaluer le SPF (y compris les requêtes DNS provoquées par des entrées au sein d’un include).
DMARC est apparu après, et a pour objectif de dire aux serveurs qui reçoivent des mails d’une adresse nous appartenant comment recouper les tests SPF et/où DKIM, et quelle action appliquer dans le cas d’un échec.
Ceci se fait également sous la forme d’une entrée DNS, qui doit être appliquée au domaine _dmarc.example.com, et est aussi une entrée TXT.
Elle peut ressembler à ceci :
v=DMARC1; p=quarantine; pct=100; sp=quarantine; aspf=s; adkim=r;
v= déclare la versionp= déclare la politique à appliquer en cas d’échec, pour une adresse du domaine. Peut être none, quarantine ou rejectpct= déclare le pourcentage de mails auxquels on doit appliquer ce filtrage (permet de l’appliquer au fur et à mesure)sp= déclare la politique à appliquer en cas d’échec pour une adresse d’un sous-domaineaspf= déclare l’alignement concernant SPF. Peut être r (relaxed) ou s (strict)adkim= déclare l’alignement concernant DKIM.Par défaut, le DMARC est passé lorsque soit DKIM soit SPF passe avec succès. Si l’un de ces 2 alignements est défini sur strict, alors il devra être passé avec succès pour que DMARC soit validé.
On peut aussi voir dans des mails une en-tête de type Authentication-Results qui contient les résultats d’un analyse ARC. Elle peut notamment contenir les chaînes dmarc=pass spf=pass dkim=none par exemple. Cette chaîne ARC peut être mise en place lors du transfert d’un mail (par ex liste de diffusion)
Certains sites interdisent à un utilisateur de coller une adresse mail dans le champ prévu à cet effet.
N’étant plus un enfant, je souhaite pouvoir le faire malgré tout. Pour ceci :
about:config
puis chercher la valeur dom.event.clipboardevents.enabled et la passer à “false”.
Source : https://www.pcastuces.com/pratique/astuces/4713.htm
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.
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.
Source principale : la FAQ (ou en tout cas un mirroir) de cryptsetup
dm-crypt chiffre/déchiffre à la volée les données grâce à la master key, qui est directement dérivée du mot de passe fourni. Aucune structure spéciale n’est visible sur le disque, c’est un pur chiffrement 1:1. Si des secteurs sont corrompus, cela n’affectera aucunement les autres secteurs. Il n’y a aucun garde-fou intégré ; si on se trompe dans la clé entrée, ou dans les paramètres de chiffrement, les données seront lues/écrites avec la mauvaise clé, donc risque non-négligeable de perte de données si fausse manipulation.
LUKS (Linux Unified Key Setup) est une surcouche à dm-crypt qui stocke la master key salée puis chiffrée dans une en-tête LUKS, qui précède les données chiffrées. Cette clé est déchiffrable grâce à plusieurs mots de passe (jusqu’à 8 différents) stockés dans des “key slots”, situés dans le header également. On peut donc ajouter/supprimer des mots de passe différents pour un même volume. Avec un mauvais mot de passe, LUKS ne nous laissera pas lire/écrire des données incorrectes.
Il est essentiel de backuper ce header à part, car sans lui, il sera impossible d’utiliser les données chiffrées. Il “décrit” la manière dont les données doivent être déchiffrées. Notamment grâce au sel, qui est cryptographiquement non-retrouvable.
On installe
apt install cryptsetup
Il faut consacrer un périphérique (disque, partition…) à LUKS. Toutes les données dessus seront bien sûr détruites. Ici, c’est sdX.
Il est conseillé d’effacer tous les headers d’anciens FS sur la cible, pour être sûr de ne pas avoir de fsck automatique ou autres joyeusetés qui détruiraient les données chiffrées :
sudo wipefs -a /dev/sdX
On crée le conteneur luks
sudo cryptsetup -y -v luksFormat /dev/sdX
-y : double check du mot de passe
-v : verbose
On déverrouille et mappe le conteneur :
sudo cryptsetup open /dev/sdX c1
Le conteneur sera accessible sur /dev/mapper/c1 (plus tard, lorsque udisks reconnaitra tout seul le conteneur (ou le FS dessus ?), ce sera typiquement /dev/mapper/luks-bla-bla-uuid)
On formate en ext4
sudo mkfs.ext4 /dev/mapper/c1
On peut ensuite monter la partition
sudo mount /dev/mapper/c1 /mnt
Et on a une partition chiffrée, qui s’utilise comme n’importe quel périphérique !
On peut la fermer avec
sudo cryptsetup close c1
sudo dmsetup ls --target crypt
lsblk --fs
peut aussi être utile.
Une fois que l’on compte se servir du périphérique pour stocker durablement des vraies données, il est indispensable de backuper le header du conteneur. Sans lui (corruption, création d’une table de partition sur le disque…), plus de données !
cryptsetup luksHeaderBackup /dev/sdX --header-backup-file /path/to/backup.img
Et pour restaurer en cas de besoin :
cryptsetup luksHeaderRestore /dev/sdX --header-backup-file /path/to/backup.img
On peut créer un fichier clé aléatoire via le périphérique /dev/urandom, et le passer en read-only pour root. Pour ceci :
sudo dd if=/dev/urandom of=/root/keyfile bs=1024 count=4
sudo chmod 0400 /root/keyfile
pour un fichier de 4ko.
Puis on ajoute ce fichier clé à notre conteneur LUKS (qui doit déjà exister, et avoir donc au moins 1 mot de passe) :
sudo cryptsetup luksAddKey /dev/sdX /root/keyfile
Attention, l’en-tête du conteneur ayant été modifiée, il faut penser à mettre à jour le backup !
luksKillSlot ??
luksRemoveKey ??
Pour déverrouiller automatiquement une partition chiffrée via LUKS au démarrage du système, il faut créer une entrée dans le fichier /etc/crypttab, de ce format :
mapper_name UUID=01234567-89ab-cdef-0123-456789abcdef none luks
mapper_name correspond au nom du mapper qui sera présent dans le dossier /dev/mapper/, et on peut remplacer none par (par exemple) /root/keyfile si on souhaite utiliser un fichier de clé pour déverrouiller le conteneur. Il est bien sûr conseillé de laisser ce fichier clé à un endroit non accessible (par exemple sur une partition déverouillée manuellement par mot de passe).
Il suffit ensuite d’ajouter les lignes nécessaires dans le fstab, soit sous la forme /dev/mapper/mapper_name, soit avec l’UUID de la partition.
Enfin, il me semble qu’il faut regénérer l’initramfs :
sudo update-initramfs -k all -u
debian-installer propose de chiffrer la partition slash. Pour ceci, il faut avoir :
/boot à part (pour se simplifier la vie ; ça semble être possible autrement, mais galère)Lors de la phase de partitionnement, on peut séléctionner “Configurer les volumes chiffrés”. On sélectionne la partition qui deviendra le slash chiffré, on laisse les options par défaut ; on choisit une phrase de passe. On peut annuler l’opération d’effacement si on ne la juge pas nécessaire. Lorsque l’on clique sur “Terminer”, le contenu du volume chiffré devient disponible, généralement en haut de la liste. On peut donc le définir en tant que partition slash.
J’ai eu des soucis lorsque j’ai voulu chiffrer le swap et le home depuis l’install. Tout a bien fonctionné en ne chiffrant que le slash lors de l’install, puis le swap et le home directement depuis l’installation.
Si il y’a besoin de faire une réparation depuis un live-cd, penser à vérifier/modifier le nom du mapper dans /dev/mapper via sudo dmsetup rename oldname newname, et le nom sous lequel il est monté dans /proc/mounts (il faut démonter/remonter si le nom du mapper a changé après le mount).
S’il y’a besoin de regénérer l’initramfs, vérifier que le nom du mapper correspond bien au nom dans /etc/crypttab.
Pour voir des infos sur le conteneur LUKS :
cryptsetup luksDump /dev/sdX
Pour voir des infos sur un conteneur LUKS une fois mappé (dans cet exemple sur /dev/mapper/c1) :
cryptsetup -v status c1
Voir la master key lorsque le périphérique est déverrouillé (attention aux yeux trop curieux)
sudo dmsetup table --target crypt --showkey /dev/mapper/c1
Pour agrandir un conteneur :
sudo cryptsetup resize c1 # mapper namePour réduire un conteneur, GParted plante si c’est un conteneur LUKS2, ce qui est le cas par défaut.
Pour le faire à la main :
PAS ENCORE OK !!
- BACKUP DES DONNÉES !
- # démonter le conteneur, le réparer
- sudo umount /dev/mapper/mon-conteneur
- sudo fsck -f /dev/mapper/mon-conteneur
- sudo resize2fs /dev/mapper/mon-conteneur
- # déterminer la taille de secteur du conteneur LUKS2, ainsi que sa taille tout court :
- sudo cryptsetup status mon-conteneur | grep "size" | grep "sector"
- # déterminer la nouvelle taille, en soustrayant l'espace souhaité (en secteurs) ;
# par exemple, pour libérer 20G, on fait :
- new_size = ${luks_size} - (20 * 1024 * 1024 * 1024 / ${sector_size} )
- # dimensionner le conteneur :
- sudo cryptsetup resize mon-conteneur -b ${new_size}
- # si c'est une partition et qu'on veut la réduire (par exemple /dev/sdX5) :
- # déterminer le début et la fin actuels de la partition sous-jacente (en secteurs) :
- sudo parted /dev/sdX -> unit -> s -> p # noter les valeurs "Start" et "End" pour la partition qui nous intéresse.
- # trouver l'offset du conteneur LUKS :
- sudo cryptsetup status mon-conteneur | grep offset
- # calculer la nouvelle fin de partition :
- new_end = (${start_sector} + ${new_size} + ${offset} -1)
- # redimensionner la partition elle-même :
- sudo parted /dev/sdX -> unit -> s -> resizepart 5 ${new_end} # adapter le numero de partition -> yes -> q
Une source et une autre.
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.
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.