Petit article que j’ai déniché expliquant comment fonctionne une authentification avec un site web utilisant le fournisseur NTLM. Note: je ne dis pas si c’est bien ou pas d’utiliser NTLM, juste de savoir comment ça marche.
Cela explique toutefois pourquoi je n’arrive pas à reverse-proxifier un site web qui utilise NTLM pour authentifier le client avec nginx.
J’ai de temps en temps besoin d’utiliser git en ligne de commande lorsque le GUI, en l’occurrence Visual Studio, ne suffit pas. Mais dans ce cas, la ligne de commande peut refuser de faire un pull ou un push si le dépôt git commun est accessible via HTTPS et qu’il utilise un certificat interne. C’est à dire que le certificat présenté par le serveur n’est pas auto-signé, mais signé par une autorité de certification non reconnue, comme c’est souvent le cas en entreprise (la vente de certificat n’est rien de plus qu’une grosse arnaque).
Ce problème existe aussi pour les autres outils graphiques qui sont basés sur git for windows, comme l’excellent TortoiseGit.
On est alors confronté au soucis suivant : même si Windows, Visual Studio, Internet Explorer ou Chrome reconnaissent ce certificat, ce n’est pas le cas de git en ligne de commande sous Windows. La raison est que le magasin des certificats racines n’est pas le même. Ce problème avec git n’existe pas sous un système *NIX. Cela arrive typiquement dans les cas suivants :
Chacune de ces applications ou runtime utilisent leur propre magasin de certificat, ce qui explique qu’une négociation SSL qui passe sous VStudio ne passe plus avec git.
J’indique dans ce billet comment ajouter un certificat racine pour git 4 windows. La commande est extrêmement simple, mais la difficulté a résidé à savoir quel est le fichier à modifier. En effet, si l’on regarde le packaging de git, on peut voir des certificats trainer un peu partout, ce n’est pas très propre:
Alors lequel est-ce ? Et bien c’est l’avant dernier.
Une fois qu’on l’a identifié, la manipulation est enfantine : il suffit d’éditer ce fichier et de lui coller tous les certificats racines supplémentaires au format PEM, comme le fait cette commande avec un shell type bash :
cat ca.crt >> /c/Program\ Files/Git/mingw64/ssl/certs/ca-bundle.crt
Cette manipulation sera à refaire après chaque mise à jour de git for windows.
Il existe un paramètre permettant d’indiquer à l’outil en ligne de commande de ne pas vérifier le certificat du serveur. Cela n’est pas du tout équivalent à ma solution en ce sens que ma solution permet bien d’authentifier le serveur, et que cette solution, si elle fonctionne pour git, ne fonctionne pas forcément pour les outils basés sur git comme TortoiseGit.
J’aime bien commencer une belle et chaude semaine d’été par une restauration autoritaire de SYSVOL. Ou comment annoncer gentillement que bordel de merde, c’est pas le moment, j’avais vraiment autre chose à faire que de me prendre le choux avec ça. Ce billet détaille ma résolution pour remettre debout l’infra Active Directory.
Avant toute chose, il est de rigueur de décrire le parc et les versions utilisées. En effet Microsoft a introduit énormément de changements à partir de Windows Server 2008, et la procédure décrite ici ne pourra en conséquence pas fonctionner pour un contrôleur de domaine Windows Server 2003 ou plus ancien. Pour être plus précis, la procédure ne peut s’appliquer que lorsque le niveau fonctionnel du domaine est au minimum fixé à Windows Server 2008.
Le parc est plutôt modeste et est, pour la partie qui nous concerne, composé de :
J’avoue qu’il s’agit d’un problème qui aurait pu être évité, mais ne connaissant aucun indicateur fiable « OK, ton domaine fonctionne normalement, tout est bien synchronisé » (en revanche si vous en connaissez un, un script ou n’importe quoi qui puisse me donner l’état de santé du domaine, je suis preneur), j’ai du faire avec les petits moyens dont je dispose.
A priori, les contrôleurs de domaine fonctionnaient normalement, les utilisateurs pouvaient se logguer, les contrôleurs étaient redémarrés régulièrement pour appliquer les mises à jour Windows. Cependant il existait un phénomène assez curieux mais sur lequel je ne me suis penché qu’assez tardivement : de temps en temps, les changements que je faisais sur le script PowerShell n’étaient pas pris en compte lorsque je le testais par la suite sur une VM de test. Ce script est mis à jour assez régulièrement car il sert à déployer tout ce qui ne repose pas sur du MSI, c’est à dire Firefox, Filezilla, les grosses mises à jour Visual Studio etc…
Après une énième occurrence du phénomène, je décide de prendre 5 minutes pour regarder de plus près ce qu’il se passe vraiment. J’accède alors au partage SYSVOL où se trouve le script sur chaque contrôleur de domaine et là, c’est le drame : chaque serveur possède une version du script différente ; le partage n’est absolument plus synchronisé, dans un sens comme dans l’autre.
Comme toujours dans ces cas là, on part à la chasse aux informations. Je trouve assez rapidement la raison pour laquelle il n’existe plus de réplication dans le journal d’événement d’un des contrôleurs de domaine.
C’est à partir d’ici où il est important de savoir dans quel niveau fonctionnel le domaine se trouve. Les contrôleurs de domaines sont tous maîtres, il n’y a pas (par défaut) de relation 1 maître – x esclaves comme c’est souvent le cas pour les serveurs de bases de données transactionnelles. Les données synchronisés entre les contrôleurs de domaine sont :
Etant donné que le problème ne se situe pas sur l’annuaire, la commande repadmin.exe ne sera d’aucun secours. A la place, il faudra utiliser la commande dfsrdiag.exe.
Vu que cette dernière est bien barbare et demande un certain nombre de paramètre non évident, j’ai préféré examiner la réplication via la console de gestion du système de fichiers distributés DFS (dfsmgmt.msc).
Cette console permet de créer un rapport d’intégrité (première option), ce que j’ai fait ou de tester la propagation (seconde option pour lancer le test, troisième option pour suivre la progression du test)
Je vous conseille fortement d’ouvrir ce rapport exclusivement avec Internet Explorer sous peine d’avoir du hachis parmentier à l’écran avec un autre navigateur.
Je suis donc la procédure décrite dans l’événement pour relancer la synchronisation, cela nous mène au second drame.
Et impose un choix à faire parmi deux propositions :
J’essaie lorsque c’est possible d’éviter la sur-multiplication des mots de passe à gérer. Dans un environnement principalement Microsoft, Active Directory permet de résoudre assez bien ce problème, c’est cool. Un annuaire pour les unir tous (et dans les ténèbres les lier).
Qu’en est-il des distributions Linux ? Je gère un petit nombre de serveurs sous Linux, pour lesquels l’intérêt de les intégrer dans un domaine Active Directory est proche du néant (sans parler du foutoir à mettre en place côté Linux). En effet, il n’y a pas de GPO, l’authentification par mot de passe est désactivé sur ces serveurs, et seul quelques personnes doivent pouvoir y avoir accès et de manière limitée.
Je me suis donc orienté vers une solution où la base utilisateurs des serveurs Linux reste locale (via /etc/passwd et /etc/shadow donc) mais en cherchant à centraliser la clé SSH de ces utilisateurs avec Active Directory.
David Gwynne (voir source) s’est déjà penché sur ce problème et a exhibé un paramètre contenu dans OpenSSH permettant de contrôler l’étape d’authentification via clé publique de manière très flexible, ce paramètre acceptant un script en entrée.
Le principe est alors très simple :
L’intérêt consiste à éviter de devoir manipuler le fichier /home/{user}/.ssh/authorized_keys2 sur chaque serveur pour chaque utilisateur, la création d’un accès se faisant alors en deux temps :
AuthorizedKeysCommand /etc/ssh/authorized_keys.pl AuthorizedKeysCommandUser _sshkeys # si ce n'est pas déjà fait, ci-dessous les paramètres à modifier pour désactiver l'identification par mot de passe PasswordAuthentication no ChallengeResponseAuthentication no
2. Contenu du fichier /etc/ssh/authorized_keys.pl. Il faudra renseigner le nom du domaine, le nom d’utilisateur et mot de passe d’un compte pour se connecter à l’annuaire.
#!/usr/bin/perl -w
use strict;
use Net::DNS;
use Net::LDAP;
use Net::LDAP::Constant qw(LDAP_SUCCESS LDAP_INVALID_CREDENTIALS);
use Net::LDAP::Util qw(escape_filter_value);
sub ad_bind($$$)
{
my $domain = shift;
my $user = shift;
my $pass = shift;
my $res = Net::DNS::Resolver->new;
my $query;
my $answer;
my $ldap_error;
$query = $res->query("_ldap._tcp." . $domain, 'SRV');
if (!$query) {
die "unable to query SRV records for $domain";
}
my @answers = $query->answer;
foreach $answer (@answers) {
# next if ($answer->port != 389)
my $ldap = new Net::LDAP($answer->target, timeout => 2);
$ldap_error = $@;
next unless ($ldap);
my $mesg = $ldap->bind(sprintf("%s@%s", $user, uc($domain)),
password => $pass);
return ($ldap) if ($mesg->code == LDAP_SUCCESS);
if ($mesg->code == LDAP_INVALID_CREDENTIALS) {
return (undef, $mesg->error);
}
$ldap_error = $mesg->error;
}
return (undef, $ldap_error);
}
if (scalar @ARGV != 1) {
die "username not specified";
}
my $username = $ARGV[0];
my $ad_filter = sprintf('(&(sAMAccountName=%s)(objectClass=user))', escape_filter_value($username));
my %d = (
'kveer.fr' => {
'user' => 'sshkeys',
'pass' => 'ton_mot_de_passe',
'base' => 'DC=kveer,DC=fr',
'filter' => $ad_filter
}
);
foreach my $domain (keys %d) {
my $param = $d{$domain};
my ($ds, $err) = ad_bind($domain, $param->{'user'}, $param->{'pass'});
next unless ($ds);
my $mesg = $ds->search(
base => $param->{'base'},
filter => $param->{'filter'},
attrs => ['altSecurityIdentities']
);
next unless ($mesg->code == LDAP_SUCCESS);
for (my $i = 0; $i < $mesg->count; $i++) {
my $entry = $mesg->entry($i);
my @ids = $entry->get_value('altSecurityIdentities');
foreach my $id (@ids) {
my ($type, $value) = split(/:/, $id, 2);
print "$value\n" if ($type eq 'SSHKey');
}
}
}
3. puis enfin quelques commandes pour terminer la configuration (à adapter en fonction de la distribution)
#!/bin/bash USERNAME=_sshkeys SCRIPT_FILE=/etc/ssh/authorized_keys.pl useradd -s /sbin/nologin -d /var/empty/ $USERNAME chmod 750 "$SCRIPT_FILE" chown root:"$USERNAME" "$SCRIPT_FILE"
Pour chaque utilisateur devant avoir un accès nunux, il suffit de déclarer leur clé publique au sein d’Active Directory, dans l’attribut altSecurityIdentities. L’avantage de cet attribut est qu’il existe déjà, et fonctionne à l’aide d’un préfixe sur les valeurs, de sorte à ce qu’il puisse être utilisé par un acteur différent (ici OpenSSH) sans impacter l’usage initial qui en est fait de cet attribut. Ci-dessous à travers l’outil de gestion graphiques de l’annuaire dsa.msc.
Sur certain écran, lorsque l’affichage est contrôlé par une carte graphique de marque AMD, on peut observer suite à une mise à jour des pilotes que l’image ne couvre pas tout l’écran. C’est à dire qu’il y a des bandes noires tout autour de l’image, alors même qu’on a réglé la résolution d’affichage correctement. C’est ce que l’on appelle « underscan ».
Habituellement, cela se règle en quelques clics en utilisant le Catalyst Control Center > Paramètres graphique (Graphics Settings) > l’écran > Mise à l’échelle (Scaling options).
Et si l’on a pas installé le Catalyst Control Center, comment qu’on fait ? C’est ce que nous allons voir.
Si comme moi vous n’avez pas le Catalyst Control Center d’installé, parce que c’est une usine à gaz, trop lent, trop lourd ou peu importe, le seul moyen de récupérer l’espace perdu est d’aller jouer avec la base de registre.
A noter : la procédure n’est pas automatisable : les paramètres se trouvent dans une clé de registre donc le nom est dynamique, le chemin est donc différent sur chaque machine.
Voici la procédure :
Ci-dessous la modification faite sur mon PC.
J’ai très fortuitement découvert une fonctionnalité dans OpenVPN permettant non plus de charger le certificat utilisateur depuis un fichier non chiffré (ou dont le chiffrage présente très peu d’intérêt) mais directement depuis le magasin de certificats Windows, rendant ainsi très difficile l’extraction du certificat une fois installé.
C’est entre autre pratique dans les cas suivants :
Cela se fait via le paramètre cryptoapicert , et remplace logiquement les paramètres cert et key . Il s’utilise de la manière suivante :
Note : OpenVPN dans sa version 2.3 ne supporte toujours pas les certificats encore exotiques, comme ceux utilisant des courbes elliptiques. Il faudra se limiter à du classique RSA/SHA1.
Depuis la version 8 de VMware Workstation, Vmware a semble-t-il combiné VMware Workstation avec VMware Server en terme de fonctionnalités. On remarquera d’ailleurs que VMware Server n’est plus mis à jour depuis 2009 et plus supporté depuis 2011 par l’éditeur.
Il est donc possible désormais de démarrer des machines virtuelles en même tant que l’hôte. Il n’est plus nécessaire d’ouvrir VMware Workstation à chaque fois, il n’est plus nécessaire d’ouvrir une session et de la laisser ouverte tant qu’on en a besoin. C’est très pratique cependant s’il est possible d’avoir un démarrage automatique, il n’y a pas d’arrêt automatique autre qu’un arrêt brutal des machines virtuelles lorsque l’hôte s’arrête. Du moins il n’y a pas d’interface graphique ni de documentation officielle permettant de paramétrer ce point.
Voici donc la documentation non-officielle pour paramétrer l’auto-stop. Je n’ai pas poussé afin de savoir s’il était possible de configurer l’auto-stop par vm ni qu’elles sont toutes les possibilités, mais je pense que la méthode décrite ci-dessous suffira.
Au cas où il y aurait des utilisateurs de VMware Workstation sous Linux (y en a-t-il ?), je suppose que la méthode est similaire et que le fichier correspondant se trouve quelque part dans /var/lib .
Mise en garde : C’est peu probable mais VMware pourrait très bien retirer cette fonctionnalités dans une prochaine version ou mise à jour de VMware Workstation.
Vu l’incapacité de l’équipe PHP à fournir des instructions d’installation correctes (genre à jour) sous Windows (ou le manque de volonté, cela revient au même), et parce qu’Apache sous Windows est une hérésie (alors que sous Linux, c’est simplement de la débilité), je m’atèle à résoudre ce problème.
Je ne m’étendrai pas beaucoup là-dessus, il suffit de suivre les instructions de cette page. La dernière fois que j’ai tenté cette installation, j’ai eu quelques soucis mineurs, on va dire que pour une install rapide, ça ne marche pas trop mal.
A quelques détails près, la procédure à suivre est similaire à celle pour IIS7. Par contre continuer à utiliser II6 et surtout pour autre chose que du .NET, ça craint d’un point de vue sécurité.
La procédure est identique en tout point à celle pour IIS Express (plus bas), sauf qu’il faut être admin de la machine et que le bon fichier de configuration se trouve dans C:\Windows\System32\inetsrv\config .
L’avantage néanmoins d’avoir un IIS pas express, c’est qu’il y a une interface graphique, c’est probablement plus simple et safe que de sortir directement le burin.
Je détaillerai prochainement la partie graphique (avec des screen) et complètement cette section.
L’équipe PHP ne propose que des builds 32 bits. Il y a des builds 64 bits, mais elles ne sont actuellement pas considérées comme stable.
J’ai eu le cas d’un serveur Exchange 2010 qui s’est mis à ne plus recevoir de messages de l’extérieur.
Tout semblait fonctionner :
Et pourtant impossible de recevoir et/ou envoyer.
J’ai pu trouver la solution, faute de mieux, en loguant une conversation SMTP avec le serveur Exchange afin de voir ce qu’il se passait réellement, et la bingo : le serveur a répondu 4.3.1 Insufficient System Resources.
Après une courte recherche, il s’est avéré qu’Exchange estimait ne plus avoir suffisamment d’espace disque pour fonctionner convenablement, c’est à dire moins de 4~5 Go de libre. C’est par design, une mesure de sécurité permettant d’avoir un système online en interdisant de dévorer le peu d’espace libre restant.
J’ai ensuite récupéré un peu d’espace disque là où je pouvais, notamment en supprimant des archives laissées par l’installation des cumulative updates Exchange (soit quelques 2Go quand même), ce qui m’a permis de constater le retour à la normal d’Exchange, me laissant ainsi le temps de planifier une petite maintenance pour étendre le disque dur devenu trop petit (facile dans un environnement virtuel ;)).
Soit une connexion VPN définie sur un PC portable Windows. Comment peut-on dans ces conditions accéder à une ressource se trouvant de l’autre côté du tunnel depuis un téléphone mobile ?
Y a qu’à ouvrir le VPN depuis le routeur et non le poste de travail ? Ça a du sens, mais :
Une autre solution est de configurer le VPN sur le smartphone ou la tablette, là encore il faut étudier la faisabilité technique. En général, ça ne passe pas.
Une solution qui fonctionne en toute autonomie est le partage de connexion internet avec une petite configuration en plus.
Le VPN est vu par Windows comme une nouvelle interface réseau. En configurant à l’avance une route statique vers les ressources mises à disposition par le VPN, le partage de connexion entre le Wi-Fi du PC portable et l’interface VPN va permettre au téléphone d’accéder au VPN.
On ajoute la route dans un prompt élevé comme suit :
route add [net] mask [mask] 0.0.0.0 metric [a low value] if [vpn interface number]
où :
