Archive for AFP

High Sierra : comment s’y préparer en entreprise (et pas que)

High Sierra, alias macOS 10.13, approche à grands pas, et à ce titre, Apple a diffusé plusieurs articles techniques en amont, tous résumés dans cet article. Intéressons-nous y donc de plus près…

Abandon des certificats signés SHA-1 utilisés avec le protocole TLS.

Cela peut avoir un impact si vous utilisez d’anciens certificats sur d’anciennes versions de Mac OS X Server, par exemple. Notez cependant cette phrase pas anodine en italique dans le document :

Les certificats CA racine signés SHA-1, les certificats SHA-1 distribués par des entreprises et les certificats SHA-1 installés par les utilisateurs ne sont pas concernés par cette modification.

Cela n’est donc surtout vrai que si, par exemple, vous hébergez un site web sur un serveur, site protégé par TLS avec un certificat considéré désormais comme non fiable. Depuis macOS 10.12.4 et iOS 10, Safari affichait une alerte en cas de certificat non fiable, mais désormais, la connexion est carrément refusée. À vous de mettre à jour votre certificat sur votre site. Ça ne sera pas un mal dans tous les cas…

Et dans tous les cas, même pour vos certificats d’entreprise, ou autres, il vaut mieux basculer vers des certificats signés de façon plus sûre.

Les certificats utilisant des clés RSA d’une taille inférieure à 2048 bits à travers toutes les connexionsMacos aofs maj TLS ne seront plus considérées comme sûres.

Là encore, il s’agit d’une amélioration de la sécurité au vu des évolutions technologiques. Apple pousse la sécurité vers le haut, et préfère abandonner des technologies considérées comme obsolètes côté sécurité. Si vous êtes administrateur informatique, attention donc si vous utilisez par exemple des services comme des VPN utilisant des clés RSA un peu trop faibles.

Un exemple de clé RSA non valide sous macOS High Sierra (chiffrement 1024 bits).

TLS 1.2 par défaut pour les configuration EAP-TLS

Important surtout si vous utilisez une authentification de type entreprise exploitant le protocole EAP-TLS pour vos connexions Wi-Fi ou Ethernet. Vos points d’accès devront désormais utiliser TLS 1.2 et non plus 1.0. Dans le cas où vos points d’accès ne peuvent être mis à jour, vous devrez appliquer un profil de configuration sur vos Mac pour forcer l’utilisation de TLS 1.0.

APFS : tout ce qui va mettre le souk dans vos systèmes informatiques

J’ai déjà longuement abordé APFS, je ne reviendrai pas dessus, même si il va falloir éduquer quelque peu vos utilisateurs (« je comprends pas pourquoi désormais quand je duplique des fichiers de 10 Go, la copie se fait toute seule et la taille du disque ne bouge pas… »). Apple y a carrément dédié un article spécifique, pas encore disponible en VF (mais le lien que j’ai utilisé devrait pointer sur la VF dès qu’elle sera disponible).

Il va cependant falloir noter certains points TRÈS importants lors de la migration vers High Sierra.

  • High Sierra va automatiquement convertir tous vos disques de type flash (internes ?) vers APFS, et à priori, on ne peut pas l’éviter. Or, si vous avez des disques partagés via le protocole AFP, ceux-ci ne pourront plus être partagés en utilisant ce protocole (obsolète). Ça peut être gênant si vous avez des anciens clients sous Mac OS X, ou des logiciels qui supportent mal le SMB (<Tousse> Adobe CC <Tousse tousse>), dans ce cas vous ne pourrez plus vous connecter en forçant AFP plutôt que SMB.En clair, si vous avez des serveurs tournant sous des versions récentes de macOS, évitez le passage sous High Sierra si vous avez encore besoin du protocole AFP.
Macos aofs maj

Si vous voyez cette case sur un disque dur classique, vous ne la verrez pas lors de l’installation de la version finale de macOS High Sierra sur un disque flash.

  • Notez que le passage ne sera automatique que pour les disques intégralement Flash, donc pas de migration si vous utilisez un Fusion Drive ou un disque dur classique.
  • Si vous utilisez Time Machine via AFP, vous devrez basculer la connexion en SMB. Du coup, vos postes clients devront peut-être être reconfigurés pour être à nouveau sauvegardés via Time Machine.
  • Les versions de macOS antérieures à macOS 10.12.6 ne pourront pas lire ou écrire sur un disque APFS. Si vous devez assurer l’échange de fichiers avec des disques externes vers d’anciens systèmes, ne les convertissez pas vers APFS. Utilisez Mac OS Étendu pour l’échange vers des Mac, ou exFAT si vous devez également transférer des fichiers vers des PC (évitez FAT-32 (pas de gestion des gros fichiers) et NTFS (pas géré nativement par macOS en écriture)) (et oui je sais il y a trop de parenthèses dans cette phrase).
  • Boot Camp est supporté si vous mettez à jour votre Mac vers macOS Sierra, SAUF si le volume Boot Camp est d’une taille supérieure à 3 To ET réside sur un disque Fusion Drive. Que se passe-t-il si vous avez un volume Boot Camp de plus de 3 To sur un Fusion Drive ? Ben… on ne sait pas. Mystère total. Est-ce que le volume devient non bootable ? Est-ce qu’il faut recréer la partition Boot Camp intégralement ? Au cas où, vous pouvez quand même réduire le volume avec Camptune X (testé avec succès chez moi).
  • Dans tous les cas, Boot Camp ne gèrera pas APFS, en tout cas pour le moment. Cependant, la phrase d’Apple est ambiguë : Boot Camp doesn’t support Read/Write to APFS-formatted Mac volumes. Est-ce que ça veut dire que Boot Camp supportera au moins la lecture des volumes APFS ? SI vous avez la réponse à cette question, ça m’intéresse :)
  • Et évidemment, il faudra mettre à jour la totalité de vos utilitaires de gestion/réparation de disque avec des versions compatible APFS. Mais ça, vous vous en doutiez, n’est-ce pas.

Du côté des services d’annuaires…

Pas grand chose à signaler de ce côté. Ah si, quand même un truc important :

  • Les postes sous High Sierra ne pourront plus être reliés à un annuaire Active Directory dont le niveau de fonctionnalités est inférieur à 2008. Exit Windows Server 2003. Mais de toute façon, en tant que bon sysadmin, ça fait longtemps que vous avez dégagé vos serveurs 2003, n’est-ce pas (enfin je l’espère pour vous).
  • Y’a un deuxième point à savoir, si vous faites partie des 2 administrateurs à encore utiliser NIS, vous ne pourrez pas intégrer vos postes High Sierra. Je sais, c’est un coup dur.

Extensions de kernel… UAKEL bordel ! 1

Du côté des extensions de noyau, ou kernel pour les intimes, il y a énormément de changements. Tout d’abord, rappelons ce qu’est une extension de noyau. Il s’agit d’un fichier doté d’une extension .kext qui ajoute des fonctionnalités au micro-noyau de macOS. La plupart du temps, les extensions de noyau sont plutôt des pilotes matériels, des protocoles réseau, des systèmes de fichiers… Dans l’absolu, Apple invite fortement les développeurs à se passer des extensions de noyau pour éviter qu’un crash d’une extension provoque la chute du système (et donc un reboot obligatoire). Et il est rare qu’un logiciel ait vraiment besoin de charger des extensions de noyau. Mais cela arrive !

Avant High Sierra, une application pouvait installer une extension de kernel et se lancer tranquillou billou, sans que l’utilisateur en soit averti. Mais désormais, le comportement de macOS va changer. Un nouveau mécanisme appelé User Approved Kernel Extension Loading (UAKEL, c’est moche) va désormais inviter l’utilisateur à valider les applications à utiliser une extension de noyau à se charger.

Alors, j’avoue que quelque part, ça me laisse perplexe. En effet, dans cela fait seize ans que macOS charge des extensions d’applications tierce sans qu’Apple s’en émeuve, et d’un coup, ça devient un méga-problème. C’est très bien qu’Apple veuille que les utilisateurs sachent que des trucs se passent sur leur Mac, mais d’un autre côté, ça implique que l’utilisateur comprenne ce qu’est une extension de noyau, et aille valider dans un dialogue s’il souhaite ou non utiliser une extension sans comprendre vraiment à quoi ça sert. Mouaaaaaaaaaais. D’autant plus que l’utilisateur n’aura pas besoin d’être administrateur pour activer l’extension. Ce qui, à mon goût, tue un peu l’intérêt du truc. Cela me fait furieusement penser au concept de l’UAC sous Windows… Erik Gomez a longuement écrit (en anglais) sur ce qu’il appelle Kextpocalypse. Heureusement, Apple a modifié le comportement de l’UAKEL pour rendre la gestion bien plus simple que prévue :

  • UAKEL ne s’activera que pour les nouvelles extensions installées après ou pendant l’installation de High Sierra. Si vous avez déjà des applications installées qui utilisaient des extensions, elles seront automatiquement validées. Ça devrait déjà éliminer un paquet de problèmes.
  • Si une extension remplace une extension déjà validée, elle ne demandera pas la validation.
  • Surtout, si vos Mac sont enrôlés dans une solution de gestion de mobilité (MDM), telle Jamf Pro, Jamf Now, Airwatch, Filewave, Profile Manager… UAKEL sera automatiquement désactivé. Plus de crainte de centaines d’appels affolés après une migration en masse vers High Sierra !
  • Par ailleurs, Apple précise que vous pourrez désactiver UAKEL à la main sur vos postes à l’aide de la commande spctl en démarrant sur la partition Recovery (processus lourd). Et réinitialiser la NVRAM réactivera automatiquement  l’UAKEL.

Mettre à jour vers macOS High Sierra… ou déployer une image de High Sierra ?

Depuis l’arrivée du programme DEP pour le déploiement des appareils, la question de déployer un système en s’appuyant sur une image-disque avec un outil comme Deploy Studio ou autre se pose de plus en plus. Dans le cas du passage à High Sierra, la question ne se pose même pas :

Vous DEVREZ déployer au moins une fois High Sierra via l’application de mise à jour.

L’explication est simple : lors du déploiement de High Sierra, une mise à jour de firmware sera également automatiquement installée par le logiciel d’installation de macOS, comme l’explique cet article. Impossible également de mettre à jour un système sur un disque externe ou sur un Mac en mode disque cible.

Apple a d’ailleurs ajouté de façon très claire et bien visible dans son article :

Apple doesn’t recommend or support monolithic system imaging when upgrading or updating macOS.

C’est clair non ?
 
CEPENDANT.

Vous pourrez toujours faire une image d’un Mac après qu’il ait été migré en High Sierra une première fois, puis déployer l’image SI CES MACS ONT ÉTÉ DÉJÀ MIS À JOUR UNE PREMIÈRE FOIS VERS HIGH SIERRA.

En clair : si vous avez déjà mis une première fois vos Mac à jour vers High Sierra, rien ne devrait vous empêcher de déployer une image monolithique par la suite, une fois que le firmware a été déployé. Mais ça ne reste pas une solution que je recommande, pour plein de raisons qu’il serait trop long de lister ici.

Par contre, imaginons que vous commandiez un lot d’iMac ces jours-ci auprès d’Apple, et que ces iMac vous soient livrés avec macOS 10.12 Sierra. Là, vous vous dites, « les machines sont neuves, j’attends High Sierra et je les déploie avec un nouveau master tout beau tout propre vers High Sierra avant de les déployer, ni vu ni connu j’t’embrouille ». Ben là, c’est complètement non supporté et vous risquez de rencontrer des problèmes (kernel panics, chute de cheveux, nouvelle émission d’Hanouna, que sais-je). Donc, vous devrez passer par la case mise à jour de logiciels :

  • Par la partition Recovery avec Option + Commande + R (si vous utilisez Cmd + R, vous réinstalleriez la version de l’OS fournie avec votre Mac !) ;
  • En lançant l’installation de macOS depuis le Finder ;
  • Avec un disque d’installation  de macOS créé avec la commande createinstallmedia OU DiskMaker X (Et oui, cela signifie aussi que Diskmaker X sera sûrement d’actualité pour High Sierra ;-) ) ;
  • En créant une image d’installation avec l’utilitaire d’image-système et en la déployant avec la fonction Netinstall de macOS Server.

Le plus simple sera sûrement de déployer l’application High Sierra (à l’aide d’un logiciel d’installation customisé) en exploitant votre solution de déploiement habituelle, Jamf, Filewave, Munki, etc).

Conclusion

Ne migrez pas tout de suite vers High Sierra dès sa sortie. Si vous le pouvez, bloquez la mise à jour autant que possible, et attendez la version .2 ou .3 pour la déployer, comme d’habitude. N’oubliez pas que vous pouvez simplement désactiver le téléchargement des mises à jour en arrière-plan. Jamf Pro permet aussi de bloquer le lancement des applications

Et surtout, testez, testez et testez. La meilleure solution pour les déploiements de ce type consiste souvent à déterminer deux ou trois utilisateurs avancés/passionnés capables de vous faire des vrais retours d’expérience, capables d’assumer les conséquences d’une migration anticipée vers un nouvel OS, de vous indiquer clairement les soucis rencontrés.

N’hésitez pas à renvoyer à Apple vos rapports de bugs. Oui, ils sont bien lus et ils sont pris en compte, surtout si ils sont nombreux. Mais cela pourrait être l’objet d’un autre article.

Et dans tous les cas, enjoy macOS High Sierra !

  1. Je me rends compte que je n’ai jamais fait de vanne sur Kernel et Lion, alors que les Kernel de Lion, ça aurait pu faire un super gag gastronomique. C’est triste.

Lion Server 10.7.4 : corriger un refus des connexions AFP

Problème étonnant chez un de mes clients : après le passage de la version 10.7.3 à la 10.7.4, plus possible pour certains postes de se connecter en AFP ! Lors de la tentative de connexion, qu’on utilise le dialogue de connexion (Cmd + K) ou qu’on clique sur la barre latérale puis sur Connexion, une fenêtre s’ouvre quelque secondes, et… c’es tout. Pas de fenêtre d’authentification. Le message suivant apparaît alors dans system.log : 

Jun 5 21:34:41 iMac-1 com.apple.launchd.peruser.503[111] (com.apple.netauth.useragent[256]): Job appears to have crashed: Segmentation fault

Plus étonnant encore : le même poste client arrive à se connecter à un serveur AFP à l’extérieur du réseau sans souci. Et les postes clients hors du réseau se connectent au serveur sans problème également !

Après beaucoup (beaucoup) de recherche et un peu de déduction, j’ai découvert que dans les réglages du service AFP, la ligne kerberosPrincipal affichait via la commande

sudo serveradmin settings afp

affichait parmi tous ces résultats cette ligne :

afp:kerberosPrincipal = "afpserver"

Ah ! Bizarre, car normalement elle devrait indiquer le principal du service AFP au sein de Kerberos. Ce principal devait être de la forme :

 afpserver/server.example.com@SERVER.EXAMPLE.COM

 

Qu’à cela ne tienne ! Stoppons AFP, modifions le principal puis relançons AFP : 

% sudo serveradmin afp stop
% sudo serveradmin settings afp:kerberosPrincipal = afpserver/server.example.com@SERVER.EXAMPLE.COM
% sudo serveradmin afp start

Remplacez évidemment server.example.com par le nom DNS de votre serveur et SERVER.EXAMPLE.COM par le nom du domaine Kerberos de votre domaine maitre Open Directory.

Après modification, le service est de nouveau accessible. Ouf !

Régler les problèmes de permission avec AFP sous Leopard Server

Pour la rentrée, je vous propose un article plus long que la moyenne, et qui aborde les problématiques de gestion des permissions sous AFP. Car sous Mac OS X Server 10.5, j’ai constaté que de nombreux administrateurs (moi y compris, avant de me pencher vraiment sur le sujet il y a quelques mois de cela) ont eu du mal avec le fonctionnement des permissions. Cas classique :

      • Un utilisateur A appartenant à un groupe (appelons-le Travail) crée un fichier Toto.doc.
      • Un administrateur a créé un point de partage « Boulot » sur un serveur AFP sous 10.5. Il lui a attribué les autorisations POSIX suivantes :

    1. Possesseur : lui-même, en lecture/écriture ;
    2. Groupe : Travail, en lecture et écriture ;
    3. Autres : lecture seule
      • L’utilisateur A copie son fichier toto.doc sur le point de partage, via AFP ;
      • L’utilisateur B, appartenant aussi au groupe Travail, essaie de modifier le fichier toto.doc.

Et là… impossible ! Le système lui indique qu’il n’a pas les autorisations suffisantes pour modifier le fichier. Pourtant, en toute logique, le fichier devrait avoir des permissions en lecture/écriture pour les membres du groupe travail… sauf que ce n’est pas le cas, le groupe attribué au fichier ne disposant que de la lecture seule. Comment est-ce possible ? Pourquoi les autorisations sont attribuées de façon incorrecte au fichier ?

On pourrait croire qu’il s’agit d’un bug. Pourtant, le comportement est exactement celui attendu. Le problème est plus insidieux, et la faute en incombe aux… ACLs. Mais l’explication est particulièrement tordue, et pour la comprendre, il faut remonter de quelques années en arrière…

Avant Mac OS X Server 10.2.4

Avant l’arrivée de Jaguar Server dans sa version 10.2.4, le comportement du partage de fichier respectait les autorisations Posix. Cela signifie que les autorisations d’un fichier copié sur un serveur étaient les mêmes que celles du fichier source, c’est à dire que le masque appliqué est identique entre le fichier source et la copie sur le serveur. En pratique, un fichier dont le groupe est en lecture seule sur la machine cliente restera en lecture seule s’il est copié sur le serveur.

Mais cela posait de nombreux problèmes pour les utilisateurs et les administrateurs informatiques, car cela empêchait le transfert des informations entre utilisateurs. Pourquoi ? Parce que le masque appliqué par défaut à tous les fichiers créés sur Mac OS X est 022, ce qui fait qu’un fichier est toujours en lecture/écriture pour son possesseur, mais en lecture seule pour son groupe.

Quand on copie un fichier sur le serveur, c’est ce masque qui est conservé. Si chaque fichier généré sous Mac OS X se voyait attribué un masque en lecture/écriture pour le groupe (002), il n’y aurait aucun souci, le masque étant transféré sur le serveur, et les autorisations seraient alors correctes.

De Mac OS X 10.2.4 à 10.4 : l’héritage des permissions

Comme modifier le comportement de Mac OS X impliquait des soucis de sécurité un peu plus larges, Apple a donc modifié le client et le service AFP en 10.2.4 pour permettre l’héritage des permissions, comme expliqué dans l’article 107623 de la Knowledge Base. Ainsi, un fichier récupère les permissions d’accès du groupe associé au dossier où il est placé. Il suffit de cocher la case Recevoir les autorisations des parents, et hop, on est tranquille.

Autorisations des parents

C’est ce que l’on attend en fait la plupart du temps, et c’était d’ailleurs le comportement de ce bon vieil AppleShare IP ou du partage de fichiers personnel sous Mac OS 9. Et finalement, ça marchait très bien. Sauf qu’une des grosses nouveautés de Mac OS X Server 10.4 allait imposer un nouveau changement, très attendu mais assez pernicieux.

Mac OS X Server 10.4 : bienvenue aux ACL !
Les ACL (Access Control Lists, appelées aussi listes de contrôle d’accès ou LCA) ont apporté une grande souplesse d’utilisation dans la gestion des permissions. Cependant, sous Mac OS X Server 10.4, il faut explicitement activer les ACL pour chaque volume.

Si les ACL ne sont pas actives, les permissions d’un partage peuvent toujours être attribuées façon POSIX ou via l’héritage des permissions. Mais si elles sont actives, l’héritage ne fonctionne plus, d’ailleurs la case ad hoc est désactivée. Et devinez quoi ? Dans ce cas, c’est l’attribution des autorisations façon POSIX qui prend le relais par défaut ! Il faut alors éventuellement rajouter des autorisations via des ACL pour que les différents utilisateurs puissent modifier le fichier.

Mac OS X Server 10.5 : ACL obligatoires

Après toute cette description, vous comprendrez peut-être ce qui se passe sous Mac OS X Server 10.5 : les ACL sont systématiquement actives par défaut et ne peuvent pas être désactivées (il n’y a aucune case qui le permette dans Server Admin ou ailleurs). Ce qui implique que par défaut, c’est toujours le comportement POSIX qui prime. Et du coup, il est relativement simple de corriger le souci et permettre à nos deux utilisateurs de s’échanger leurs fichiers : il suffit de rajouter le groupe en lecture/écriture… sous forme d’entrée dans les ACL. C’est à dire, dans Server Admin, de glisser le groupe Travail dans la ligne LCA, et non pas la ligne Groupe en POSIX, et lui attribuer les autorisations en lecture/écriture.

Autorisations sous 10.5

Mais pourquoi tant de confusion ? D’abord, l’interface de Server Admin a souffert durant quelques versions d’un oubli gênant : jusqu’à Mac OS X Server 10.5.2 inclus, la case d’héritage des permissions du parent était toujours visible dans l’interface graphique, quand bien même elle n’avait aucun effet. Cela a été corrigé en 10.5.3, les options d’héritage ayant disparu :

Depuis Mac OS X Server 10.5.3, l\'option d\'héritage des permissions a disparu
La faute aussi à la documentation de Mac OS X Server, qui manque probablement de clarté quand à la différence entre la gestion POSIX et les ACL, et leur influence sur un modèle de partage de fichiers assez courant. Une grande partie des problèmes vient également du masque par défaut appliqué aux fichiers sous Mac OS X : si chaque groupe avait par défaut l’accès en lecture et écriture sur tout nouveau fichier généré, on aurait beaucoup moins de soucis…

Enfin, une partie de ce comportement vient de la difficulté à concevoir un modèle où la sécurité, les origines UNIX de Mac OS X et les besoins des utilisateurs d’un système graphique puissent coexister paisiblement. Et finalement, quand on comprend le fonctionnement de Mac OS X, on comprend aussi que l’héritage des permissions était un patch qu’il était nécessaire de supprimer, les ACL étant gérées au niveau du noyau de Mac OS X et non pas du seul client AFP.

Vous savez donc désormais comment agir : ne vous occupez plus spécialement des autorisations POSIX, et concentrez-vous sur les ACL. Vous pourrez ainsi gérer vos autorisations du partage de fichiers plus efficacement et de façon bien plus souple. Au passage, lisez la documentation de Mac OS X Server 10.5, en particulier celle-ci (PDF, 1,4 Mo).

N.B. : ceux qui ont installé leur serveur 10.5 en mode standard (et non pas avancé) n’ont même pas souffert de ce problème. Pourquoi ? Parce que dans l’interface des Préférences Serveur, la notion de POSIX n’est pas représentée : en réalité, tout est géré via les ACL…

N.B.2 : une autre solution aurait pu consister à modifier le masque global appliqué aux fichiers, mais il faut le faire aussi sur chaque poste client… Voir ce document pour la méthode.

Mac OS X Server 10.4.9 et copie via Mac OS 9 :la solution

afpclient.pngProblème récurrent des postes clients Mac OS 9 vers Mac OS X Server 10.4.9 : lors de la copie de fichiers d’une taille supérieure à 1,5 Mo, la copie se vautrait comme il faut (pas).

Une solution est enfin disponible via l’article 305420 de la KBase. Il suffit d’éditer une valeur cachée (TCPQuantum) et de relancer le service pour prendre en compte les nouveaux réglages.