Par défaut, Freeipa ne fournit pas de solution de self service password.
Dans leur documentation ils vous indiquent d’utiliser des services tiers type PWM.
Celui-ci a l’air très complet, mais trop lourd pour mes besoins, car écrit en java et nécessite donc un serveur tomcat pour faire tourner la bête.
J’ai donc utilisé le service du projet LTB qui lui est écrit en PHP.

Installation

wget http://tools.ltb-project.org/attachments/download/800/ltb-project-self-service-password-0.9.tar.gz
tar xzvf ltb-project-self-service-password-0.9.tar.gz -C /var/www/ltb-password

Modifier votre virtual host pour qu’il prenne en compte vos changements.
Puis dans le dossier, modifier le fichier config.inc.php comme suit :

#==============================================================================
# Configuration
#==============================================================================
# LDAP
$ldap_url = "ldap://freeipa.domain.local";
$ldap_starttls = true;
$ldap_binddn = "cn=Directory Manager";
$ldap_bindpw = 'MY_STRONG_PASSWORD';
$ldap_base = "cn=users,cn=accounts,dc=domain,dc=local";
$ldap_login_attribute = "uid";
$ldap_fullname_attribute = "cn";
$ldap_filter = "(&(objectClass=person)($ldap_login_attribute={login}))";

$hash = "auto";
...

Ltb utilise l’attribut userPassword pour effectuer le changement de mot de passe, or FreeIPA ne laisse que le directory manager voir cet attribut, il faut donc obligatoirement passer par cet utilisateur.
Veillez bien à utiliser un certificat, même auto signée, pour avoir un minimum de sécurité.

J’utilise pour mes projets un gitlab interne.
Certains de mes projets sont aussi disponible sur mon github.

Je voulais donc que gitlab pousse directement mes commits dans github. Pourquoi gitlab et non pas mon ordinateur ? Car si je souhaite développer à partir d’une autre machine ou bien si un de mes collègues décide de contribuer à un de mes projets hébergé sur mon gitlab, je veux que github reflète les commits effectués sur mon instance gitlab locale et ce par projet.

J’utilise les packages fourni par les repositories de gitlab

Ici je vais modifier mon projet appelé « Zimbra-Collaboration-Products-Comparaison », dans les commandes ci-dessous on retrouvera en rouge le nom de mon projet.
Tout d’abord on commence par créer une clef ssh pour notre utilisateur git :

sudo -u git ssh-keygen -f /var/opt/gitlab/.ssh/Zimbra-Collaboration-Products-Comparaison_key

Veillez à ne pas mettre de passphrase

Une fois la clef créée, copier-coller la clef publique (/var/opt/gitlab/.ssh/Zimbra-Collaboration-Products-Comparaison_key.pub) dans le projet hébergé sur github :
Gitlab-GitHub-1

Veillez bien à cliquer sur « Allow Write Access »

Ensuite sur votre instance gitlab, on va configurer des hôtes ssh relatifs àvos projets avec des clefs ssh spécifiques pour chaque hôte.
Lire la suite de

Depuis la mise en place de mon Alix APU1D4 je refais une passe sur toute ma configuration pfsense. Je me souviens avoir galéré la première fois pour dédier un pool d’adresse IP spécifique via le DHCP pour mes machines virtuelles fonctionnant sous Vmware.
Alors je pose ça ici histoire d’avoir une trace écrite et si ça peut servir à quelqu’un d’autre…

L’idée est d’avoir au sein du pool principal un sous-pool uniquement réservé aux machines virtuelles. Ainsi je peux mettre des options supplémentaires telles que le TFTP ou un DNS different, utile lorsque vous utilisez une solution type foreman pour générer vos machines.

Tout d’abord dans le pool principal, on indique que les machines ayant des adresses MAC VMware ne peuvent pas bénéficier d’une adresse IP de ce pool.

L’adresse MAC des machines virtuelles Vmware lorsqu’elles sont gérées par un vCenter est la suivante :00:50:56:00:00:00-00:50:56:3F:FF:FF ref.

Pfsense-mac-control-01

Une fois que cela est fait, on créer notre pool d’addresse IP destiné à recevoir nos machines virtuelles

Pfsense-mac-control-02

Et enfin on autorise uniquement les machines Vmware a avoir une adresse de ce pool :

Pfsense-mac-control-03

Comme la majorité des personnes travaillant dans l’IT, j’utilise un agrégateur de flux afin de rester à jour des actualités.
N’ayant pas l’envie de confier mes informations à un tiers, j’héberge ça sur une instance de TinyTiny Rss. Malgré tout le bien que je pense de ce logiciel, je n’aime pas l’interface de consultation web et me suis donc tourné vers un logiciel desktop pour cet usage.
Étant sur Mac Os X mon choix s’est tourné vers MicroRss.
Après avoir paramétré MicroRss et récupéré mes flux, un problème persistait :

MicroRss-Self-Cert-1

Utilisant un certificat auto signé, le logiciel me retournait une erreur. Même en ayant coché la case dans les préférences acceptant le certificat auto signé le problème persistait.

Et la solution est toute simple, il suffit d’injecter le certificat dans votre key-chain, changer la politique SSL à Trust pour que le message n’apparaisse plus :

MicroRss-Self-Cert-2

 

Dans le cadre de mon travail, j’effectue de temps en temps des conferences avec une presence sur un stand.
Ayant un ecran a dispistion, je me suis dis que j’allais construire une « ShowBox » qui me permettait de dérouler les presentations sans avoir un PC raccordé à l’ecran.
J’ai donc pour cela pris un raspberypi en y ajoutant un clef WIFI pour les access à distance.
Je suis partie d’une raspbian et ai ajouté 2 choses :
– les access a distance via le wifi
– la lecture automatique des videos

Hotspot Wifi

Pour cette partie, j’ai repris le travail du site Hardware Libre (voir source en bas d’article) sauf que dans mon cas, le point d’acces ne servira qu’a acceder au Raspberry.

sudo apt-get install hostapd iptables dnsmasq

tout comme eux je dispose d’un carte wifi ayant un chipset Realtek donc :

cd /tmp
sudo wget http://fichiers.touslesdrivers.com/39144/RTL8188C_8192C_USB_linux_v4.0.2_9000.20130911.zip
sudo unzip RTL8188C_8192C_USB_linux_v4.0.2_9000.20130911.zip
cd RTL8188C_8192C_USB_linux_v4.0.2_9000.20130911
cd wpa_supplicant_hostapd
sudo tar -xvf wpa_supplicant_hostapd-0.8_rtw_r7475.20130812.tar.gz
cd wpa_supplicant_hostapd-0.8_rtw_r7475.20130812
cd hostapd
sudo make
sudo make install
sudo mv hostapd /usr/sbin/hostapd
sudo chown root.root /usr/sbin/hostapd
sudo chmod 755 /usr/sbin/hostapd

Lire la suite de

J’ai récemment été confronté à un problème. Je souhaitais connecter un Pfsense à un VPN Cisco.
Apres avoir glané pas mal d’informations sur le web, j’ai compris que cela n’allait pas être facile puisque les paquets permettant la connexion ne sont pas inclus dans Pfsense.
Pour se connecter au Cisco on va utiliser un utilitaire : Openconnect. Par défaut il n’est pas installé dans Pfsense, on va donc l’installer.
Le souci c’est que la version de Pfsense que j’utilise (la 2.1.5) est basée sur un FreeBSD 8.3. Hors le paquet officiel précompilé est pour la version 8.4 de FreeBSD. J’ai quand même essayé de l’installer :

pkg_add ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-8-stable/Latest/openconnect.tbz
Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-8-stable/Latest/openconnect.tbz... Done.
Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-8-stable/All/vpnc-scripts-20130311_1.tbz... Done.
Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-8-stable/All/libiconv-1.14_1.tbz... Done.
Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-8-stable/All/libxml2-2.8.0_3.tbz... Done.

A priori tout a l’air bon.
Afin que la commande soit disponible directement depuis la shell on utilise la commande rehash
A partir de maintenant vous pouvez déjà vous connecter via la commande openconnect.

openconnect --background --user=USERNAME --no-cert-check vpn.domain.tld

Openconnect va directement faire appel à vpnc et créer l’interface tun pour vous. Si vous voulez gérer cette interface via l’interface web de Pfsense, vous n’allez pas pouvoir. En effet un filtre s’applique à toutes les interfaces de type tun. Il faut donc renommer l’interface une fois que le vpn est connecté. Et pourquoi seulement après ? Car Openconnect n’accepte pas des interfaces de connexion différentes de tunX (hard codé dans le logiciel).
On peut donc renommer l’interface comme ceci :
ifconfig tun8 name ovpnc8
elle apparaitra donc dans l’interface et vous pourrez la gérer et l’affecter a une interface dans Pfsense.

Ok, maintenant on va rendre tout cela automatique via un script et le positionner dans la cron :

 #!/bin/sh
 #Variable to adjust
 HOSTPING=HOST_TO_PING
 HOSTPVN=VPN_ADDRESS
 USER=wolfyxvf
 PASS=strongpassword
 INITTUN=tun8
 NAMETUN=ovpnc8
 #Tools
 PING='/sbin/ping'
 IFCONFIG='/sbin/ifconfig'
 OPENCONNECT='/usr/local/sbin/openconnect'
 DATE=`date`
 PINGRES=`$PING -c 2 $HOSTPING`
 PLOSS=`echo $PINGRES : | grep -o '[0-9][0-9][0-9].[0-9]% packet loss' | cut -f1 -d%'`
 echo "$DATE : Loss Result : $PLOSS"
 if [ "100.0" = "$PLOSS" ];
 then
 echo "$DATE : Deleting Old Interface : $NAMETUN"
 $IFCONFIG $NAMETUN down
 $IFCONFIG $NAMETUN destroy
 echo "$DATE : Creating Interface : $INITTUN"
 $IFCONFIG $INITTUM create
 $IFCONFIG $INITTUM up
 echo "$DATE : Starting : $NAMETUN"
 echo -n $PASS | exec $OPENCONNECT --background --interface=$INITTUN --user=$USER --no-cert-check $HOSTPVN
 echo "$DATE : Renaming Interface : $INITTUN to $NAMETUN"
 $IFCONFIG tun8 name ovpnc8
 echo "$DATE : Now running : $NAMETUN"
 else
 echo "$DATE : Already running"
 fi

Puis on le met dans la cron de root :

crontab -e
*/10 * * * * /root/openconnect-vpn.sh >> /var/log/openconnect_pinger.log 2>&1

Petite note :

J’ai eu un souci lors du montage du VPN. Celui-ci me modifiait mon resolv.conf. Etant donné mon installation je ne souhaitais pas que cela arrive, j’ai donc mis en place un flag immutable

chflags schg /etc/resolv.conf

References :

  1.  : Installation des paquets FreeBSD sur Pfsense
  2. : Interface tun non disponible dans l’interface Pfsense
  3. : Script d’automatisation du VPN