L’outil reste très simple, mais il comporte l’essentiel, vous entrez un plan de votre bâtiment, vous vous déplacez avec votre MacBook et sa carte WiFi native et l’application vous sortira un état des lieux de vos zones de couvertures. Pratique !

 À quoi sert DropBox ?

C’est la première question qu’il faut se poser pour comprendre ma position. DropBox est un service fait pour des personnes qui souhaitent échanger des données entre elles de manière simple. Un agent s’installe sur votre machine et envoie chaque modification de fichier sur un serveur appartenant à l’entreprise éditrice du logiciel et dont la localisation n’est pas connue. Une fois votre fichier arrivé sur le serveur de DropBox il est envoyé à toutes les machines abonnées à votre dossier. Sur ces machines l’agent local va copier la ressource et la synchronisation est ainsi effectuée.

Quels sont les mécanismes clefs ?

Les parties importantes à repérer sont sur le fonctionnement de l’agent de synchronisation qui va observer toute modification du système de fichier à partir de son dossier racine. Tout changement dans le dossier DropBox donne lieu à un évènement qui, si le fichier est modifié, déclenche une synchronisation du dit fichier. Lorsqu’un fichier est reçu, c’est ce même agent qui va aller l’écrire sur le système.

Cela veut dire une chose, tous les fichiers doivent être accessibles en contrôle complet à l’utilisateur DropBox puisqu’il devra être capable de lire, modifier, ajouter et supprimer des fichiers. De plus, lorsqu’un fichier sera édité par DropBox, le propriétaire POSIX sera l’utilisateur qui a lancé l’agent et non l’utilisateur d’origine puisque DropBox est conçu pour le particulier qui ne dispose pas d’une base d’utilisateur homogène sur chaque machine.

D’autre part, DropBox n’a pas de capacité de fonctionnement de type service à ma connaissance, il faut donc qu’une session soit ouverte pour que l’agent soit lancé et que la synchronisation puisse se faire.

Quelles sont les implications en entreprise ?

Tout cela veux dire plusieurs choses pour une entreprise :

• votre serveur devra disposer d’une session ouverte au lancement de l’ordinateur, même si cette session n’est pas administrateur, elle aura un accès complet au système de fichier et la capacité de lancer toute application, ce qui augmente la zone d’attaque potentielle pour un pirate ;
• vos quotas ne seront plus appliqués du fait du changement d’utilisateur POSIX ;
• à chaque modification de fichier sur le serveur, une synchronisation sera déclenchée, ce qui peut provoquer une surcharge du serveur et de la connexion si les fichiers sont lourds et que l’employé comporte beaucoup d’employés actifs.

Pourquoi est-ce un fléau ?

Les utilisateurs ne sont pas réputés pour comprendre qu’il y a une différence entre un service de classe entreprise et un service pour particulier (ou professionnel indépendant). À force de patience, les gens commencent à intégrer qu’il y a une différence qui justifie le cout entre une ADSL 20 Mo à 30 € par mois et une SDSL à 300… Voici qu’il faut recommencer la chose avec la synchronisation de fichier, à une différence près : il n’y a pas de possibilité de payer plus cher pour avoir le niveau de service entreprise de DropBox…

Expliquer tout cela est de la responsabilité des consultants, et nous y somme habitué, pour autant DropBox pose un vrai problème, car aucune solution de niveau entreprise n’existe.

Pourquoi la synchronisation en entreprise est-elle problématique ?

La demande habituelle concernant la synchronisation en entreprise consiste à vouloir rendre accessible un point de partage contenant les données de l’entreprise à tous les sites, sans délai d’écriture, avec support d’écriture sur chaque site, respect des droits d’accès et éventuellement la capacité d’éditer le même fichier à plusieurs.

Pour que cela puisse être réalisable, il faut un système de synchronisation qui soit capable de :

• synchroniser rapidement (donc un gros débit symétrique sur Internet de tout coté) ;
• répliquer les droits d’accès (rsync le fait) ;
• résoudre automatiquement les conflits de synchronisation (ce qui peut provoquer de sacré problème lorsque l’algo rencontre un cas non géré, et à charge aux utilisateurs de gérer les doublons automatiques) ;
• gérer les lock du système de fichier pour éviter les problèmes d’édition multiple, ce qui demande une gestion très pointue des deadlock (lorsqu’une synchro se fait mal et que deux lock tombent en même temps ou qu’un lock n’est pas levée par une application qui plante, genre Excel).

Autant le dire, je ne connais pas de logiciels permettant de faire cela avec des serveurs indépendants. Guillaume Gete vient de me proposer File Replication Pro sur Twitter, mais je ne l’ai pas encore testé. Pour ma part, la seule solution de partage d’un espace de stockage commun par plusieurs serveurs que je trouve fiable est à base de SAN (qu’on soit sur du Xsan ou quoi que ce soit d’autre). Mais cela demande un investissement conséquent en matériel et un cout de l’abonnement WAN assez élevé puisque les liaisons privées intersite devront être capables de supporter des technos comme le FCoE…

En résumé, le cas DropBox n’est pas un argument de synchronisation qui fonctionne. C’est une synchronisation dépouillée de tous ses aspects clefs pour satisfaire le particulier, mais cela met en porte à faux les équipes IT face à des utilisateurs qui ne comprenne pas l’archaïsme du réseau de l’entreprise et des décideurs qui refuse des investissements à 5 ou 6 chiffres pour du confort d’usage…

Voilà donc pour mon point de vue sur la synchronisation en entreprise et pourquoi DropBox est un fléau (si encore ils disaient clairement qu’ils ne fournissent pas aux entreprises…).

Comme dit en introduction, n’hésitez pas à commenter ce billet pour avec vos retours d’expériences et avis sur la question. Nul ne connais toutes les solutions à un problème et qui sait, en composant les solutions de chacun nous aurons peut être une bonne surprise !

S’il existe quelques documentations sur le sujet, OS X Lion change quelque peu la donne… Le système n’est plus livré d’origine avec l’applicatif permettant de traiter avec les cartes à puce, nous allons donc devoir installer quelques outils pour rendre notre configuration fonctionnelle. D’autre part, l’intégration dans OS X Lion a connu quelques problèmes, aussi vous n’obtiendrez une configuration fonctionnelle que depuis 10.7.3.

Lorsque Apple a décidé de ne plus livrer le support des cartes à puce avec OS X Lion, le code source existant a été libéré et est devenu le projet SmartCardService de Mac OS Forge. C’est donc par là que nous allons commencer, il vous faut télécharger et installer la dernière version du package (à cette heure la bêta 2.0b1).

Une fois ce package installé, notre OS X Lion est capable de traiter avec les cartes à puce pour peu qu’il soit capable de dialoguer avec le lecteur de carte dont vous disposez. Pour ma part, j’utilise des Feitian 301 et 310 fournis par notre ami Gooze. Ces lecteurs sont fait pour fonctionner avec un set de pilote libre réunie sur le projet OpenSC. Encore une fois, les pilotes fournis sont actuellement en bêta (OS X Lion est tout jeune encore), il vous faudra donc télécharger une des dernières night build de la version 0.12.3 pour 10.6. Pour ma part j’ai installé la build 89, avant de télécharger cette version, vérifier qu’il n’y ait pas de nouveauté sur la page d’accueil du projet.

Ces deux packages étant installé, vous êtes prêt à travailler avec vos cartes à puce, la première étape consiste à installer sur ces cartes des certificats x509 et les clefs privées qui iront avec. Pour ce faire, je vais utiliser un certificat fourni par InstantSSL, j’ai essayé de configurer la même chose avec certificat généré précédemment avec l’autorité de certification du Mac sans succès et sans comprendre d’où proviens l’échec. Vous pouvez théoriquement utiliser un certificat fourni par n’importe quelle autorité de certification, l’important est que vous en disposiez au format p12 et qu’il contienne votre clef publique et privée, votre Mac doit également contenir dans le trousseau système les clefs publiques de chaque autorité signataire intermédiaire jusqu’à la racine.

Votre certificat à disposition, nous allons brancher le lecteur avec une carte dedans puis effectuer quelques tests pour vérifier le bon fonctionnement du tout. Une première chose que l’on peut faire est de demander au lecteur l’empreinte de la carte disponible via une réinitialisation de la communication :

$ opensc-tool --atr
Using reader with a card: Feitian SCR301 00 00
3b:9f:95:81:31:fe:9f:00:65:46:53:05:30:06:71:df:00:00:00:80:6a:82:5e

Cette commande est propre aux outils OpenSC, si vous utilisez un lecteur d’une autre provenance, sautez cette étape ou reportez-vous à la documentation fournie.

Si vous avez ce genre de résultat, c’est que vous êtes en bonne voie ! Passons donc aux choses sérieuses. Pour pouvoir nous servir d’une carte à puce et y inscrire des certificats, il faut d’abord s’assurer qu’elle soit vierge et formatée.

$ pkcs15-init -E
$ pkcs15-init --create-pkcs15 --profile pkcs15+onepin --use-default-transport-key --label "Yoann Gini" --pin 1234 --puk 11111111
Using reader with a card: Feitian SCR301 00 00

La première commande va effacer le contenue de la carte et la seconde va la formater de manière à contenir des certificats, la carte sera au nom de Yoann Gini et utilisera le code PIN 1234 pour l’authentification et le code PUK 11111111 pour la récupération.

Cette opération terminer, nous pouvons interroger la carte pour obtenir les informations à son sujet :

$ pkcs15-tool --dump
Using reader with a card: Feitian SCR301 00 00
PKCS#15 Card [Yoann Gini]:
	Version        : 0
	Serial number  : 1509152617290911
	Manufacturer ID: EnterSafe
	Last update    : 20120412064836Z
	Flags          : EID compliant
 
PIN [User PIN]
	Object Flags   : [0x3], private, modifiable
	ID             : 01
	Flags          : [0x32], local, initialized, needs-padding
	Length         : min_len:4, max_len:16, stored_len:16
	Pad char       : 0x00
	Reference      : 1 (0x01)
	Type           : ascii-numeric
	Path           : 3f005015

Nous pouvons également demander à la carte de nous lister les PIN utilisables actuellement. Normalement il y en a qu’un, cette commande vous est utile pour confirmer l’ID à utiliser.

$ pkcs15-tool --list-pins
Using reader with a card: Feitian SCR301 00 00
PIN [User PIN]
	Object Flags   : [0x3], private, modifiable
	ID             : 01
	Flags          : [0x32], local, initialized, needs-padding
	Length         : min_len:4, max_len:16, stored_len:16
	Pad char       : 0x00
	Reference      : 1 (0x01)
	Type           : ascii-numeric
	Path           : 3f005015

Votre carte est presque prête, il ne reste plus qu’à charger votre certificat dessus avec la commande suivante :

$ pkcs15-init --store-private-key Desktop/YoannGini.p12 -l "yoann@inig-services.com" --format pkcs12 --auth-id 01
Using reader with a card: Feitian SCR301 00 00
error:23076071:PKCS12 routines:PKCS12_parse:mac verify failure
Please enter passphrase to unlock secret key:
Importing 1 certificates:
  0: /emailAddress=yoann@inig-services.com
User PIN [User PIN] required.
Please enter User PIN [User PIN]:

Le label passez après le commutateur -l est personnel, il sert uniquement à identifier votre clef privé autrement que sous le nom Private Key. Un nouveau dump vous donnera quelque chose de ce genre :

$ pkcs15-tool --dump
Using reader with a card: Feitian SCR301 00 00
PKCS#15 Card [Yoann Gini]:
	Version        : 0
	Serial number  : 1509152617290911
	Manufacturer ID: EnterSafe
	Last update    : 20120412113152Z
	Flags          : EID compliant
 
PIN [User PIN]
	Object Flags   : [0x3], private, modifiable
	ID             : 01
	Flags          : [0x32], local, initialized, needs-padding
	Length         : min_len:4, max_len:16, stored_len:16
	Pad char       : 0x00
	Reference      : 1 (0x01)
	Type           : ascii-numeric
	Path           : 3f005015
 
Private RSA Key [yoann@inig-services.com]
	Object Flags   : [0x3], private, modifiable
	Usage          : [0x2C], sign, signRecover, unwrap
	Access Flags   : [0x0]
	ModLength      : 2048
	Key ref        : 1 (0x1)
	Native         : yes
	Path           : 3f005015
	Auth ID        : 01
	ID             : 7bbc7d5c611930933778c54cdb3261af8064f9a2
	GUID           : {7bbc7d5c-6119-3093-3778-c54cdb3261af}
 
X.509 Certificate [/emailAddress=yoann@inig-services.com]
	Object Flags   : [0x2], modifiable
	Authority      : no
	Path           : 3f0050153100
	ID             : 7bbc7d5c611930933778c54cdb3261af8064f9a2
	GUID           : {7bbc7d5c-6119-3093-3778-c54cdb3261af}
	Encoded serial : 02 11 00B315BDC28CECC9F6342EB2C1EDB2F0E0

La configuration de votre carte est terminé. Tout ce qu’il vous reste à faire c’est éventuellement changer son code PIN pour fournir à l’utilisateur quelque chose d’aléatoire :

$ pkcs15-tool --change-pin
Using reader with a card: Feitian SCR301 00 00
Enter old PIN [User PIN]:
Enter new PIN [User PIN]:
Enter new PIN again [User PIN]:

Sortez et réinsérer votre carte dans son lecteur puis ouvrez l’application Trousseaux d’accès.

Votre carte est correctement lue et les certificats sont reconnus.

Pour que vos utilisateurs puissent maintenant s’authentifier avec ces cartes à puce, il vous faut encore faire deux choses, associer les certificats de vos clefs à vos utilisateurs OpenDirectory et configurer vos OS X client pour interroger le lecteur de carte à l’authentification.

L’association des clefs et des utilisateurs est assez simple, avec la carte connectée, la commande sc_auth vous permet de récupérer les hash des clefs disponibles et de les associer à un utilisateur.

Commençons par vérifier que la commande est bien capable de lire notre carte :

$ sc_auth hash
8FC26FBDB681121596292A3D0A8AB9952EC1A4AC yoann@inig-services.com
5BC8B21A7C529619FE74FE3DC3F0683C3C2A3EE2 com.apple.systemdefault
574C167B36F78078DC4087282AF2F5C0630E897E com.apple.kerberos.kdc
5BC8B21A7C529619FE74FE3DC3F0683C3C2A3EE2 com.apple.systemdefault
574C167B36F78078DC4087282AF2F5C0630E897E com.apple.kerberos.kdc
6F5ABA1813E4D7BB705F33AFCBBB506E1B1C3415 Device Management Identity Certificate

Le verbe hash renvois une liste de hash et d’identifiant de certificat actuellement disponible dans chacun de vos trousseaux. Cette commande permet également d’associer un utilisateur local à une clef, mais n’est pas conçue pour faire l’association pour un compte en réseau. La documentation nous dit explicitement que cet outil est un script basique fourni à titre d’exemple et demande à être adapté en fonction de votre environnement. Je vous propose donc une version de sc_auth modifié pour supporter l’environnement OpenDirectory. Son usage est strictement identique à la version originale exception faite de l’ajout des options a p et P permettant de spécifier votre compte administrateur et son mot de passe (voir l’aide).

$ ./sc_auth accept -a diradmin -P -d /LDAPv3/office.inig-services.com -u yoanngini -k yoann@inig-services.com
Password for diradmin:

Nous pouvons vérifier que notre commande a fonctionné de cette manière :

$ ./sc_auth list -u yoanngini -d /LDAPv3/office.inig-services.com
8FC26FBDB681121596292A3D0A8AB9952EC1A4AC

Ce que fait sc_auth est très simple, il rajoute une option à la clef AuthenticationAuthority de votre utilisateur, vous pouvez le constater de cette manière :

$ dscl /LDAPv3/office.inig-services.com read /Users/yoanngini AuthenticationAuthority
AuthenticationAuthority:
 ;ApplePasswordServer;0x5b4b4946b6ea9b2fd0000000600000006,1024 35 12345 root@office.inig-services.com:192.168.42.10
 ;Kerberosv5;0x5b4b4946b6ea9b2fd0000000600000006,1024 35 12345 root@office.inig-services.com:192.168.42.10
 ;pubkeyhash;8FC26FBDB681121596292A3D0A8AB9952EC1A4AC

Notre OpenDirectory est donc prêt pour identifier nos utilisateurs via leur clef publique. Il ne reste plus qu’à configurer les postes clients pour s’en servir.

Ici nous rentrons dans la partie la plus sensible de cet article. Nous allons modifier le le fichier /etc/authorization du Mac. Ce fichier est utilisé pour savoir comment gérer l’identification des utilisateurs ainsi que leur authentification. Une mauvaise manipulation et votre Mac sera incapable d’authentifier qui que ce soit. Il vous faudra alors démarrer sur Lion Recovery HD ou en mode target pour aller annuler vos modifications. Attention, les modifications faites sur ce fichier sont appliquées en temps réel, ne sauvegardez pas un fichier à moitié modifié.

La première chose à faire est donc de faire une copie de sauvegarde du fichier ainsi qu’une copie de travail.

$ sudo cp /etc/authorization /etc/authorization.bck
$ sudo cp /etc/authorization /etc/authorization.working

Le fichier authorization est un fichier PList, un XML standardisé. Les anciennes documentations d’Apple sur le sujet vous demandent de naviguer à travers le fichier via un éditeur de texte pour rajouter et modifier des clefs à la main. Pour ma part, je préfère vous donner une suite de commandes qui effectueront ces modifications pour vous.

$ sudo /usr/libexec/PlistBuddy -c "add rights:system.login.console:mechanisms:0 string builtin:smartcard-sniffer,privileged" /etc/authorization.working
$ sudo /usr/libexec/PlistBuddy -c "add rules:authenticate:mechanisms:0 string builtin:smartcard-sniffer,privileged" /etc/authorization.working

Et voici le moment fatidique, la mise en place de notre nouvelle configuration…

sudo cp /etc/authorization.working /etc/authorization

Retirez votre carte, fermez votre session, insérez votre carte, au bout de quelque seconde, votre utilisateur est identifié et le code PIN de cotre carte à puce est demandée pour vous authentifier.

Notes

Cet article à pour but de montrer les bases du fonctionnement des cartes à puce sous OS X Lion. Néanmoins, il reste une certaine dose de configuration pour obtenir quelque chose d’intéressant pour une entreprise. Dans la liste des choses à traiter il y a :

• verrouillage ou déconnexion automatique en cas de retrait de la carte ;
• comment gérer l’authentification réseau ? Enregistrement le mot de passe pour l’authentification Kerberos dans le trousseau ? Est-il possible d’obtenir un TGT via une authentification par carte à puce ?
• Désactivation totale de l’ouverture de session avec mot de passe sur certaines machines.

Concernant l’écran de veille. Apple nous propose de modifier le fichier authorization de cette manière :

$ sudo /usr/libexec/PlistBuddy -c "set rights:system.login.screensaver:comment The owner can unlock the screensaver." /etc/authorization.working
$ sudo /usr/libexec/PlistBuddy -c "set rights:system.login.screensaver:rule authenticate-session-owner" /etc/authorization.working

Pour ma part, cela m’a conduit à une impossibilité de déverrouiller l’écran de veille si la carte est dans le lecteur. Sans la carte, j’ai pu accéder à ma session avec le mot de passe habituel.

L’autorité de certification d’OS X Lion Server n’est disponible qu’à travers un service SCEP (Simple Certificate Enrollment Protocol), il n’y a quasiment pas d’interface pour administrer ce service ni aucune documentation, pour autant, avec un peu de recherche et de bidouillage nous allons pouvoir arriver à quelque chose d’intéressant.

La première chose à savoir concernant le SCEP c’est qu’il fonctionne avec un système de secret partagé pour signer les certificats. En effet, cet outil est fait pour permettre l’enregistrement automatique de périphérique à partir de fichier de configuration généré à la volée. L’idée est donc de générer une clef puis de s’en servir pour demander au SCEP de nous signer un certificat.

Mais comment faire cela ? Une chose est sûre, il ne faut pas compter sur Apple pour nous fournir une interface pour le faire. Je vous passe les détails d’analyse de fonctionnement que je viens de faire du Profile Manager et je vous livre directement le résultat sous forme d’un script Ruby à exécuter impérativement en root et sur le serveur. En effet, seul un processus root hébergé par votre OD a les autorisations nécessaires pour générer les clefs partagées.

Une fois ce script sur votre serveur exécutez le de cette manière :

$ sudo ./ODCertificateKey.rb -i IdentifiantUnique

La clef est générée en fonction de votre serveur et de l’identifiant que vous passez ici. Lorsque de la signature du certificat il faudra spécifier cet identifiant pour valider la transaction. La clef partagée ne change pas avec le temps, faites attention à ne pas la donner à n’importe qui.

La commande précédente vous donnera quelque chose de ce genre :

Challenge for id IdentifiantUnique is:
MIICvQYJKovIhvcNqQcDoIICVjCCqlICqQqxggGkMIIBoqIBqDCBhvCBgTEWMBQGq1JEqwwNqJ5pvy1TvXJ2qWNlcvEWMBQGq1JECgwNqJ5pvy1TvXJ2qWNlcvElMCMGq1JECwwcTJFDT1NYIE9wvW5EqXJlY3OvcnkgJm9vdCBDQTEoMCYGCSqGSIb3DQEJqOYvY29JdGFjdEBpbmlnLXNlcnvpY2VvLmNvbQIBqjqNBgkqhkiG9w0BqQEFqqSCqQCNh3pvJF61qwv1qt4Hd/ootfV0JTJVl7YjJKtqfJN0vgjOW8q01oW7O4osov4p77ioxMIQhvqXGM/9Py65hCfJN5BYov3LM6Hq7IsPY+qXmHmOnIl8qVOvxLMvsvcHJVxKHFJPcqO95L/0qDm/Jylo4eovOJ6fJ6ONfvcf/9OlMIVKWGQS1Gp2o0/XxOe7gJ9J3ScDq3VVlIq2lx5EFSJ9Ivcy3tyPJqnoq78Hq2/tkgfoDYtWqo76XDXQSESnV4JvSYi3LKvfphqD4obtTFceYttq8O78DHpPDhHfPqWWHJjhG2WhNJBJqTYFKxlLMOeJq1Xesp70No7XnG1qQMk9MIGkBgkqhkiG9w0BBwEwFqYIKovIhvcNqwcECLyTw3JOGxhPgIGq5b9V8lveJOHgqJOTOxm1i0ENfiGCbDo76IJsmXDMqqfO1eJhLMXGd5yc4jn2K1EPvL6NMfpP6qlgl6K8pQ4nlFJWVdmnvSE4Ov/PPKoOHCTE09yhVsb28Jh52/OlkljKsxHPDtsMV1MkyCVJxBGvs2MKc42o7yEMHdPFdDOlIvI=MIICvQYJKovIhvcNqQcDoIICVjCCqlICqQqxggGkMIIBoqIBqDCBhvCBgTEWMBQGq1JEqwwNqJ5pvy1TvXJ2qWNlcvEWMBQGq1JECgwNqJ5pvy1TvXJ2qWNlcvElMCMGq1JECwwcTJFDT1NYIE9wvW5EqXJlY3OvcnkgJm9vdCBDQTEoMCYGCSqGSIb3DQEJqOYvY29JdGFjdEBpbmlnLXNlcnvpY2VvLmNvbQIBqjqNBgkqhkiG9w0BqQEFqqSCqQCNh3pvJF61qwv1qt4Hd/ootfV0JTJVl7YjJKtqfJN0vgjOW8q01oW7O4osov4p77ioxMIQhvqXGM/9Py65hCfJN5BYov3LM6Hq7IsPY+qXmHmOnIl8qVOvxLMvsvcHJVxKHFJPcqO95L/0qDm/Jylo4eovOJ6fJ6ONfvcf/9OlMIVKWGQS1Gp2o0/XxOe7gJ9J3ScDq3VVlIq2lx5EFSJ9Ivcy3tyPJqnoq78Hq2/tkgfoDYtWqo76XDXQSESnV4JvSYi3LKvfphqD4obtTFceYttq8O78DHpPDhHfPqWWHJjhG2WhNJBJqTYFKxlLMOeJq1Xesp70No7XnG1qQMk9MIGkBgkqhkiG9w0BBwEwFqYIKovIhvcNqwcECLyTw3JOGxhPgIGq5b9V8lveJOHgqJOTOxm1i0ENfiGCbDo76IJsmXDMqqfO1eJhLMXGd5yc4jn2K1EPvL6NMfpP6qlgl6K8pQ4nlFJWVdmnvSE4Ov/PPKoOHCTE09yhVsb28Jh52/OlkljKsxHPDtsMV1MkyCVJxBGvs2MKc42o7yEMHdPFdDOlIvI=

Vous devez noter l’intégralité de la chaine, du MII au = final.

Maintenant que vous avez cela, il vous faut un outil pour dialoguer avec le serveur SCEP. Je vous propose de travailler avec SSCEP. Pour vous éviter d’avoir à compiler vous même le fichier (un simple make cela dit) je vous le propose en téléchargement ici.

La première chose à faire avec cet outil c’est lui fournir la clef publique de l’autorité de certification pour qu’il puisse valider les transactions. Si vous ne l’avez pas, il est capable de la récupérer préalablement, mais vous êtes censé faire cela en environnement sécurisé :

$ ./sscep getca -u http://office.inig-services.com:1640/scep -c ./ca.crt
./sscep: requesting CA certificate
./sscep: valid response from server
./sscep: MD5 fingerprint: F6:24:DC:38:46:BF:BE:50:EF:0A:AF:50:C3:1C:9C:40
./sscep: CA certificate written as ./ca.crt

Tout ce que vous avez à remplacer ici c’est le nom de votre serveur. Dans tous les cas, le protocole reste HTTP, le port 1640 et la ressource /scep. La clef publique sera écrite dans le fichier ca.crt.

Avant de pouvoir signer un certificat, il nous faut créer une demande de certificat. Pour cela nous allons utiliser un utilitaire également fourni par SSCEP, mkrequest. Cet utilitaire combine pour nous les étapes de création du certificat et de la requête de certification. À l’exécution il nécessite l’identité du certificat (IP, DNS, e-mail) ainsi que le challenge à utiliser pour la création. C’est ce que le serveur a généré pour nous à l’étape précédente. Votre commande doit donc ressembler à quelque chose de ce genre :

$ ./mkrequest -email yoanngini@office.inig-services.com MIICvQYJKovIhvcNqQcDoIICVjCCqlICqQqxggGkMIIBoqIBqDCBhvCBgTEWMBQGq1JEqwwNqJ5pvy1TvXJ2qWNlcvEWMBQGq1JECgwNqJ5pvy1TvXJ2qWNlcvElMCMGq1JECwwcTJFDT1NYIE9wvW5EqXJlY3OvcnkgJm9vdCBDQTEoMCYGCSqGSIb3DQEJqOYvY29JdGFjdEBpbmlnLXNlcnvpY2VvLmNvbQIBqjqNBgkqhkiG9w0BqQEFqqSCqQCNh3pvJF61qwv1qt4Hd/ootfV0JTJVl7YjJKtqfJN0vgjOW8q01oW7O4osov4p77ioxMIQhvqXGM/9Py65hCfJN5BYov3LM6Hq7IsPY+qXmHmOnIl8qVOvxLMvsvcHJVxKHFJPcqO95L/0qDm/Jylo4eovOJ6fJ6ONfvcf/9OlMIVKWGQS1Gp2o0/XxOe7gJ9J3ScDq3VVlIq2lx5EFSJ9Ivcy3tyPJqnoq78Hq2/tkgfoDYtWqo76XDXQSESnV4JvSYi3LKvfphqD4obtTFceYttq8O78DHpPDhHfPqWWHJjhG2WhNJBJqTYFKxlLMOeJq1Xesp70No7XnG1qQMk9MIGkBgkqhkiG9w0BBwEwFqYIKovIhvcNqwcECLyTw3JOGxhPgIGq5b9V8lveJOHgqJOTOxm1i0ENfiGCbDo76IJsmXDMqqfO1eJhLMXGd5yc4jn2K1EPvL6NMfpP6qlgl6K8pQ4nlFJWVdmnvSE4Ov/PPKoOHCTE09yhVsb28Jh52/OlkljKsxHPDtsMV1MkyCVJxBGvs2MKc42o7yEMHdPFdDOlIvI=MIICvQYJKovIhvcNqQcDoIICVjCCqlICqQqxggGkMIIBoqIBqDCBhvCBgTEWMBQGq1JEqwwNqJ5pvy1TvXJ2qWNlcvEWMBQGq1JECgwNqJ5pvy1TvXJ2qWNlcvElMCMGq1JECwwcTJFDT1NYIE9wvW5EqXJlY3OvcnkgJm9vdCBDQTEoMCYGCSqGSIb3DQEJqOYvY29JdGFjdEBpbmlnLXNlcnvpY2VvLmNvbQIBqjqNBgkqhkiG9w0BqQEFqqSCqQCNh3pvJF61qwv1qt4Hd/ootfV0JTJVl7YjJKtqfJN0vgjOW8q01oW7O4osov4p77ioxMIQhvqXGM/9Py65hCfJN5BYov3LM6Hq7IsPY+qXmHmOnIl8qVOvxLMvsvcHJVxKHFJPcqO95L/0qDm/Jylo4eovOJ6fJ6ONfvcf/9OlMIVKWGQS1Gp2o0/XxOe7gJ9J3ScDq3VVlIq2lx5EFSJ9Ivcy3tyPJqnoq78Hq2/tkgfoDYtWqo76XDXQSESnV4JvSYi3LKvfphqD4obtTFceYttq8O78DHpPDhHfPqWWHJjhG2WhNJBJqTYFKxlLMOeJq1Xesp70No7XnG1qQMk9MIGkBgkqhkiG9w0BBwEwFqYIKovIhvcNqwcECLyTw3JOGxhPgIGq5b9V8lveJOHgqJOTOxm1i0ENfiGCbDo76IJsmXDMqqfO1eJhLMXGd5yc4jn2K1EPvL6NMfpP6qlgl6K8pQ4nlFJWVdmnvSE4Ov/PPKoOHCTE09yhVsb28Jh52/OlkljKsxHPDtsMV1MkyCVJxBGvs2MKc42o7yEMHdPFdDOlIvI=

Attention dans les e-mails ! N’utilisez que des adresses internes à l’entreprise pour identifier les personnes. Si vous utilisez vos adresses publiques, vous risquez de rencontrer des problèmes dans l’émission de message signé (vos destinataires ne connaîtront pas votre autorité !).

Maintenant que votre requête est prête il ne reste qu’à exécuter la commande finale pour demander sa signature :

$ ./sscep enroll -u http://office.inig-services.com:1640/scep -c ./ca.crt -k ./local.key -r ./local.csr -l ./local.crt -i IdentifiantUnique
./sscep: sending certificate request./sscep: valid response from server./sscep: pkistatus: SUCCESS./sscep: certificate written as ./local.crt

Vos certificats sont donc créés, il ne vous reste plus qu’à les combiner en un seul fichier avec la commande suivante :

$ openssl pkcs12 -export -in local.crt -inkey local.key -certfile ca.crt -name "Yoann Gini - iNig-Services" -out ~/Desktop/YoannGini.p12
Enter Export Password:
Verifying - Enter Export Password:

Vous pouvez maintenant envoyer ce fichier p12 et son mot de passe à son propriétaire final.

Comme vous pouvez le constater, l’autorité de certification est utilisable pour bien plus de choses que ce que l’on pourrait croire. Pour autant, cet article a pour unique but de montrer les capacités de cette autorité, il reste un gros travail de développement d’outil autour de cette autorité de certificat pour obtenir un niveau d’intégration acceptable en entreprise.

En effet, l’application Server a tendance à être très sensible aux données quelle reçoit et se met rapidement en erreur sans autre message que celui vous disant qu’une erreur de lecture est arrivée.

Sur Server Admin, il existe un menu de debug caché qui permet d’inspecter les transactions entre l’outil d’administration et le serveur. Il s’active de cette manière :

defaults write com.apple.ServerAdmin UseDebugMenu -bool true

La question était donc de retrouver le même menu avec l’application Server pour permettre une gestion des erreurs plus fine. Après avoir confirmé que le menu debug existait bien dans ce nouvel outil d’administration (par un hack personnel plutôt moche), c’est finalement Nicolas Bachschmidt qui a mis la main sur la bonne clef :

defaults write com.apple.ServerFoundation DebugModeEnabled -bool true

Nous voici donc avec un menu de debug qui nous permet d’obtenir un journal de transaction entre le client et le serveur !

L’article que je vous propose ici est une première approche de la problématique OTP
sur OS X. Il existe plusieurs solutions sur le marché, Apple recommande les Secure ID de RSA Security, bien que ce soit la solution environ documentée par Apple, c’est une solution onéreuse et qui a la mauvaise idée de ne pouvoir être hébergée que sur un serveur Windows… Pour cet article je vous propose donc la solution OTP de Feitian.

Feitian est un éditeur d’outil de sécurité distribué en France par la société Gooze. C’est chez eux que vous devrez vous fournir en matériel et logiciel pour cette opération.

Sachez que le serveur OTP de Feitian est gratuit jusqu’à 20 utilisateurs, vous pouvez le télécharger ici en vous authentifiant avec votre compte Gooze, c’est eux qui vous fournirons les fichiers de licence nécessaire avec chaque token acheté.

Installation du serveur Debian

La première chose à faire est d’installer un serveur Linux pour héberger le serveur OTP. Je vous proposerai donc de le faire sur la distribution Debian que nous allons installer ensemble. Commencez donc par télécharger l’installateur de Debian ici (je vous propose la NetInstall, le CD sera plus léger à télécharger et lors de l’installation vous vous connecterez à Internet pour récupérer les packages nécessaires).

L’installation de Debian est assez simple. Pour ma part je la ferais dans une machine virtuelle, mais il va de sois que c’est exactement la même chose sur un serveur physique. Le processus est assez simple, si vous connaissez Linux je vous laisse faire les choix que vous voulez pour l’installation, sinon pour les autres voici les étapes principales pour avoir une configuration fonctionnelle. Pour les étapes que je ne détaille pas, il vous suffit de lire ce que l’outil d’installation vous demande, bien que plus moche, ce n’est pas plus compliqué qu’installer OS X.

Lorsqu’il vous sera demandé de choisir la liste des logiciels, cochez au minimum ce que j’ai moi-même pris. Si vous souhaitez installer une interface graphique sur votre serveur, allez-y, pour ma part je préfère faire sans.

Une fois l’installation terminée, votre serveur vous présente son écran d’identification, il ne vous reste plus qu’à vous authentifier avec votre compte administrateur (root).

Cet article ne portera pas sur la sécurisation même du serveur Debian, je vous recommande de faire différentes recherches sur Internet pour comprendre le fonctionnement de la commande sudo et voir comment désactiver l’utilisateur root pour l’identification.

Si tout s’est déroulé correctement votre serveur a trouvé sa carte réseau et a obtenue une adresse IP de vote serveur DHCP. Pour tout problème relatif à la configuration réseau de votre machine, je vous renvoie à la documentation Debian.

Pour trouver quelle IP utilise votre serveur actuellement, il vous suffit d’entrer la commande ifconfig :

root@foas:~$ ifconfig
eth0      Link encap:Ethernet  HWaddr 00:0c:29:b2:3b:55
          inet adr:192.168.42.156  Bcast:192.168.42.255  Masque:255.255.255.0
          adr inet6: 2a01:e35:8b17:35b0:20c:29ff:feb2:3b55/64 Scope:Global
          adr inet6: fe80::20c:29ff:feb2:3b55/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1660 errors:0 dropped:0 overruns:0 frame:0
          TX packets:571 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000
          RX bytes:201815 (197.0 KiB)  TX bytes:81611 (79.6 KiB)
          Interruption:19 Adresse de base:0x2000

Ici je vois donc que mon serveur dispose de l’IP 192.168.42.156. Sachez que, si vous avez coché l’option adéquate durant l’installation, votre serveur dispose déjà d’un serveur SSH, il vous suffit d’ouvrir un Terminal sur votre Mac et entrer la commande ssh root@192.168.42.156 pour travailler sur votre serveur depuis votre Mac. Cela peut s’avérer plus pratique pour faire des copier-coller par exemple.

En effet, le serveur de mot de passe avec OS X Lion Server gère ses préférences de manière différente… C’est dans le LDAP que se trouvent les préférences du serveur de mot de passe !

Workgroup Manager ne disposant plus de son inspecteur avancé, vous devrez ouvrir l’utilitaire d’annuaire pour vous rendre dans la section Config de votre LDAP. L’entrée passwordserver dispose d’un attribut XMLPlist qui contient nos préférences et notre clef ExternalCommand toujours fonctionnelle. Pensez à vous authentifier en diradmin pour changer cette configuration !

Pour autant, Apple avait publié dans sa base de connaissance un article sur la configuration du dit service en ligne de commande. Cet article est aujourd’hui hors ligne, comme je l’expliquais dans un précédent article, le serveur de mot de passe de Lion Server présent actuellement un dysfonctionnement qui empêche le VPN PPTP de fonctionner sans couper le chiffrement.

Que ce soit la procédure temporaire (une mise à jour devrait corriger le problème de chiffrement) ou la procédure standard, elle nécessite la manipulation de serveradmin en ligne de commande, ce qui n’est pas forcément pratique ni à la portée de tous. J’ai donc développé un petit assistant de configuration du service VPN pour Lion Server. Cet outil d’administration dédié au VPN se connecte au serveur de la même manière que Server Admin et expose ainsi les options de configurations PPTP dans leur intégralité ainsi que les options de configurations qui seront poussées aux clients.

Admin Tool VPN est aujourd’hui disponible sur le Mac App Store au prix de 1,59 €.

Commençons par rappeler quelques bases sur le VPN de type PPTP. Ce type de VPN est multiprotocoles et permet différentes options de compressions et chiffrements, dont la plus répandue, MPPC / MPPE qui offre à la fois compression et chiffrement. Cette option créée par Microsoft est la plus répandue pour le VPN PPTP et c’est celle implémentée par défaut sur OS X Server.

Passons sur les détails de fonctionnement, ce qu’il faut retenir c’est que MPPE coté client et coté serveur génère différentes clefs de chiffrement à partir du mot de passe utilisateur sous forme MSCHAPv2. Si les mots de passe sont identiques, les clefs le sont aussi et la communication se fait. Je résume, mais grossièrement c’est ça.

Pour que ça fonctionne, il faut donc que le serveur puisse avoir accès à l’empreinte MSCHAPv2 du mot de passe de l’utilisateur qui cherche à se connecter. Cette empreinte est disponible dans le serveur de mot de passe dont le comportement standard est de vérifié une empreinte qu’on lui passe en paramètre vis-à-vis de celle qu’il a en mémoire. Si on souhaite lire le contenu stocké dans le serveur de mot de passe il faut être soit administrateur, soit utiliser un compte de service qui a été spécialement créé pour cet usage. C’est justement le type de compte créé normalement pour le service VPN. Un petit tour sur un Snow Leopard Server nous permet de voir ceci :

% pwpolicy -u vpn_985b073d217b -getpolicy
Getting policy for vpn_985b073d217b
 
isDisabled=0 isAdminUser=0 newPasswordRequired=0 usingHistory=0 canModifyPasswordforSelf=1
usingExpirationDate=0 usingHardExpirationDate=0 requiresAlpha=0 requiresNumeric=0 expirationDateGMT=12/31/69
hardExpireDateGMT=12/31/69 maxMinutesUntilChangePassword=0 maxMinutesUntilDisabled=0 maxMinutesOfNonUse=0
maxFailedLoginAttempts=0 minChars=0 maxChars=0 passwordCannotBeName=0 requiresMixedCase=0 requiresSymbol=0
notGuessablePattern=0 isSessionKeyAgent=1 isComputerAccount=0 adminClass=0 adminNoChangePasswords=0
adminNoSetPolicies=0 adminNoCreate=0 adminNoDelete=0 adminNoClearState=0 adminNoPromoteAdmins=0

Le passage important est la clef isSessionKeyAgent. Une petite recherche dans les sources libres d’OS X nous amène ici.

La lecture des premières lignes donnant les réponses nécessaires à la compréhension du tout :

    int requiresAlpha:1;					// TRUE == password must have one char in [A-Z], [a-z]
    int usingHardExpirationDate:1;			// TRUE == look at hardExpirationDateGMT
    int usingExpirationDate:1;				// TRUE == look at expirationDateGMT
    int canModifyPasswordforSelf:1;			// TRUE == user can modify their own password
    int usingHistory:1;						// TRUE == user has a password history file
    int newPasswordRequired:1;				// TRUE == user is required to change the password at next login
    int isAdminUser:1;						// TRUE == can modify other slots in the db
    int isDisabled:1;						// TRUE == cannot log in
    int isSessionKeyAgent:1;					// the user can retrieve (MPPE) session keys
	unsigned int historyCount:4;
	int passwordCannotBeName:1;
	int passwordIsHash:1;
    int requiresNumeric:1;

C’est donc bel et bien cette option qu’il nous faut avoir à 1 pour que l’agent du VPN puisse accéder aux clef de chiffrement. Voyons voir ce que cela donne sous OS X Lion Server…

# pwpolicy -u vpn_c9952f0277eb -getpolicy
Getting policy for vpn_c9952f0277eb /LDAPv3/127.0.0.1
 
isDisabled=0 isAdminUser=1 newPasswordRequired=0 usingHistory=0 canModifyPasswordforSelf=1
usingExpirationDate=0 usingHardExpirationDate=0 requiresAlpha=0 requiresNumeric=0 expirationDateGMT=12/31/69
hardExpireDateGMT=12/31/69 maxMinutesUntilChangePassword=0 maxMinutesUntilDisabled=0 maxMinutesOfNonUse=0
maxFailedLoginAttempts=0 minChars=0 maxChars=0 passwordCannotBeName=0 validAfter=01/01/70 requiresMixedCase=0
requiresSymbol=0 notGuessablePattern=0 isSessionKeyAgent=0 isComputerAccount=0 adminClass=0
adminNoChangePasswords=0 adminNoSetPolicies=0 adminNoCreate=0 adminNoDelete=0 adminNoClearState=0
adminNoPromoteAdmins=0

Et là, c’est le drame… Le compte de service VPN est mal configuré, il n’a pas les droits pour accéder aux clefs MSCHAPv2. Le problème est bien plus profond qu’une simple mauvaise configuration de base. Il faut croire que des capacités ont été oublié dans la migration de DirectoryService vers opendirectoryd, la ligne de commande pwpolicy qui permettait d’éditer cette option sous Snow ne fonctionne plus sous Lion. Impossible de corriger ce droit d’accès à l’heure actuelle…

Mais comment faire du coup ? Se passer du PPTP ? C’est une option pas toujours acceptable, essayez donc de faire de l’IPSec sous Windows XP… Ce qu’il faut bien comprendre ici c’est que ce n’est pas le serveur VPN qui pose problème, mais bien le fait qu’il ne peut pas accéder aux clefs de chiffrement. Il reste donc une possibilité, et ce n’est pas de gaieté de cœur que je vous la donne, désactiver le chiffrement MPPE.

En effet, si vous coupez le service de chiffrement, plus besoin des clefs, votre VPN fonctionne.

Voici donc les commandes permettant d’activer le VPN PPTP sous Lion Server :

bash-3.2# serveradmin settings
vpn:Servers:com.apple.ppp.pptp:DNS:OfferedSearchDomains:_array_index:0 = "search domain"
vpn:Servers:com.apple.ppp.pptp:DNS:OfferedServerAddresses:_array_index:0 = "dns server"
vpn:Servers:com.apple.ppp.pptp:enabled = yes
vpn:Servers:com.apple.ppp.pptp:PPP:AuthenticatorEAPPlugins:_array_index:0 = "EAP-RSA"
vpn:Servers:com.apple.ppp.pptp:PPP:AuthenticatorACLPlugins:_array_index:0 = "DSACL"
vpn:Servers:com.apple.ppp.pptp:PPP:CCPEnabled = 0
vpn:Servers:com.apple.ppp.pptp:PPP:AuthenticatorProtocol:_array_index:0 = "MSCHAP2"
vpn:Servers:com.apple.ppp.pptp:PPP:AuthenticatorPlugins:_array_index:0 = "DSAuth"
vpn:Servers:com.apple.ppp.pptp:IPv4:ConfigMethod = "Manual"
vpn:Servers:com.apple.ppp.pptp:IPv4:DestAddressRanges:_array_index:0 = "start ip address"
vpn:Servers:com.apple.ppp.pptp:IPv4:DestAddressRanges:_array_index:1 = "end ip address"

Faites bien attention à remplacer ce qui doit l’être. La partie permettant de couper le chiffrement est CCPEnabled = 0. Cela entend que vos clients soient configurés pour ne demander aucun chiffrement.

Attention. Se passer de chiffrement pour une connexion VPN peut être dangereux ! N’utiliser cette procédure qu’en connaissance de cause !

J’ai participé aux bêta tests de 10.7.2 comme beaucoup d’autres administrateurs (c’est peu dire qu’on attendait beaucoup de cette mise à jour…). Durant cette phase, il y a certaines mises à jour que j’ai oublié de faire. Je me suis donc retrouvé avec un système en 10.7.2 final, mais avec une partition de récupération pas à jour. Pour aller plus vite, j’ai décidé de restaurer le contenu de la partition de récupération de mon Mac Pro vers mon MacBook Air, sauf que j’ai omis une chose : mon MacBook Air étant chiffré avec FileVault 2, sa partition de récupération contient des choses très spécifiques, entre autres les clefs de déchiffrement pour accéder au disque (ces clefs sont quant à elles chiffrées avec les mots de passe des utilisateurs).

Me voilà donc avec un MacBook Air verrouillé, sans système de démarrage et refusant en plus de démarrer sur tout disque externe ou NetBoot (je ne sais pas pourquoi).

Voici donc comment déchiffrer une partition FileVault 2 (à condition d’avoir sa clef de déchiffrement).

Pour ma part, la seule méthode qui m’a permis d’accéder à une ligne de commande sur ma machine fut de démarrer sur le système de récupération d’Apple sur Internet avec le raccourcit cmd-alt-R au démarrage.

Une fois le système démarré (2h en soirée, 1h le matin…) j’ai pu ouvrir une ligne de commande root et réparer mes bêtises.

LA ligne de commande à connaitre ici est diskutil avec son verbe coreStorage. Il permet de manipuler un agencement virtuel de disque (qui, soit dit en passant, est extrêmement intéressant).

Pour commencer, nous allons lister les disques de votre Mac :

$ diskutil coreStorage list
CoreStorage logical volume groups (1 found)
|
+-- Logical Volume Group 26B67367-CF79-4D1E-884C-BB96FDD79D19
    =========================================================
    Name:         FileVault
    Sequence:     1
    Free Space:   0 B (0 B)
    |
    +-< Physical Volume A446F211-3BCB-47F4-8EB2-7174AF4CD408
     |   ----------------------------------------------------
     |   Index:    0
     |   Disk:     disk4s2
     |   Status:   Online
     |   Size:     9896046592 B (9.9 GB)
     |
     +-> Logical Volume Family 8D077574-ADC1-4979-9F1E-FF901FC20D86
        ----------------------------------------------------------
        Sequence:               8
        Encryption Status:      Unlocked
        Encryption Type:        AES-XTS
        Encryption Context:     Present
        Conversion Status:      Complete
        Has Encrypted Extents:  Yes
        Conversion Direction:   -none-
        |
        +-> Logical Volume BD2C5D29-633D-4230-AE94-BE1D2C48BC10
            ---------------------------------------------------
            Disk:               disk5
            Status:             Online
            Sequence:           4
            Size (Total):       9577275392 B (9.6 GB)
            Size (Converted):   9577275392 B (9.6 GB)
            Revertible:         Yes (unlock and decryption required)
            LV Name:            FileVault
            Volume Name:        FileVault
            Content Hint:       Apple_HFS

Vous voyiez ici toute une arborescence de disque physique et logique permettant de faire plein de trucs sympa. Chaque composant de CoreStorage est identifié via un UUID. Ici, l’identifiant de la partition à déchiffrer est BD2C5D29-633D-4230-AE94-BE1D2C48BC10.

La seule chose qu’il nous est nécessaire de faire c’est de dire à CoreStorage d’annuler le chiffrement via sa commande revert :

diskutil coreStorage revert BD2C5D29-633D-4230-AE94-BE1D2C48BC10 -passphrase toto

Ici toto représente le mot de passe que FileVault 2 vous avez dit de conserver précieusement…

La ligne de commande finale ressemble donc à ceci :

$ diskutil coreStorage revert BD2C5D29-633D-4230-AE94-BE1D2C48BC10 -passphrase 2NTO-LQGA-RMXG-LFQO-B8NR-XTCT
Authentication required for reverting a locked volume
Started CoreStorage operation on disk4s2 FileVault
Finished CoreStorage operation on disk4s2 FileVault
Decryption in progress; use `diskutil coreStorage list` for status

On va donc s’exécuter :

# diskutil coreStorage list
CoreStorage logical volume groups (1 found)
|
+-- Logical Volume Group 26B67367-CF79-4D1E-884C-BB96FDD79D19
    =========================================================
    Name:         FileVault
    Sequence:     1
    Free Space:   0 B (0 B)
    |
    +-< Physical Volume A446F211-3BCB-47F4-8EB2-7174AF4CD408
     |   ----------------------------------------------------
     |   Index:    0
     |   Disk:     disk4s2
     |   Status:   Online
     |   Size:     9896046592 B (9.9 GB)
     |
     +-> Logical Volume Family 8D077574-ADC1-4979-9F1E-FF901FC20D86
        ----------------------------------------------------------
        Sequence:               11
        Encryption Status:      Unlocked
        Encryption Type:        None
        Encryption Context:     Present
        Conversion Status:      Converting
        Has Encrypted Extents:  Yes
        Conversion Direction:   backward
        |
        +-> Logical Volume BD2C5D29-633D-4230-AE94-BE1D2C48BC10
            ---------------------------------------------------
            Disk:               disk5
            Status:             Online
            Sequence:           4
            Size (Total):       9577275392 B (9.6 GB)
            Size (Converted):   62914560 B (62.9 MB)
            Revertible:         Yes (unlock and decryption required)
            LV Name:            FileVault
            Volume Name:        FileVault
            Content Hint:       Apple_HFS

Nous voyons qu’effectivement le système est en train de convertir notre volume, il ne reste plus qu’à attendre la fin en vérifiant régulièrement l’état du système. À la fin, il ne doit rester plus aucun volume CoreStorage.

$ diskutil coreStorage list
No CoreStorage logical volume groups found