L’intérêt de ce genre de manip est multiple, communiqué avec une baie Promise, un routeur Cisco, un Serveur, etc.

Voyons voir maintenant comment faire en sorte que l’écriture sur cette zone soit protégée par un secret partagé.

English version

Vous vous souvenez certainement que dans le deuxième article de cette série nous avions utilisé une ligne de commande pour faire en sorte que la clef bonjourRegistration de notre zone WAB prenne la valeur open. Nous allons maintenant modifier cette valeur pour la mettre à secure.

root@office / 18:17 % serveradmin settings dns:views:_array_id:2247116D-446D-4254-AEB0-8BD7377D4256:primaryZones:_array_id:0AC3AE46-8D87-4679-9EA0-CCEDB87FF11F:bonjourRegistration = "secure"

Cette commande à un effet sur le fichier /etc/dns/publicView.conf.apple qui contient la définition de nos domaines géré. Regarder votre zone WAB, elle devrait ressembler à ceci :

	zone "bonjour.office.inig-services.com." {
		type master;
		file "db.bonjour.office.inig-services.com.";
		allow-transfer {none;};
		allow-update {key com.apple.ServerAdmin.DNS.bonjour.sharedSecret;};
	};

L’intéressant ici se trouve sur la ligne allow-update qui est réglé par Server Admin pour utiliser uniquement la clef com.apple.ServerAdmin.DNS.bonjour.sharedSecret. Il nous reste donc à définir cette clef puis à la transmettre sur nos clients.

Pour définir cette clef, l’outil à utiliser en ligne de commande est rndc-confgen, il va également falloir lui indiquer où stocker la clef, pour ma part j’ai choisi /etc/dns/bonjour.key.

root@office / 18:27 % rndc-confgen -a -c /etc/dns/bonjour.key -k com.apple.ServerAdmin.DNS.bonjour.sharedSecret

Si vous regardez le contenue de ce fichier vous devez avoir quelque chose de ce genre :

key "com.apple.ServerAdmin.DNS.bonjour.sharedSecret" {
	algorithm hmac-md5;
	secret "lasZZ9TN+AILCl+TpNgUiw==";
};

Notez donc le secret entre guillemets, il vous servira sur les machines clients.

Cette clef étant générée, il reste à indiquer à Bind où elle se trouve, pour cela nous allons modifier le fichier /etc/named.conf pour faire en sorte que le début ressemble à cela :

//
// Include keys file
//
include "/etc/rndc.key";
include "/etc/dns/bonjour.key";
 
// ...

Il ne vous reste plus qu’à redémarrer le service DNS :

root@office / 18:33 % serveradmin stop dns && serveradmin start dns

Il nous reste ici à configurer les machines clientes, rendez-vous dans les préférences systèmes, section partage pour aller configurer l’enregistrement WAB de votre client en utilisant com.apple.ServerAdmin.DNS.bonjour.sharedSecret comme nom d’utilisateur et lasZZ9TN+AILCl+TpNgUiw== comme mot de passe.

Vous savez déjà comment vérifier que votre zone fonctionne, Bonjour Browser est votre ami :-)

English version

Pour commencer, une petite explication de ce qu’est l’implémentation de Bonjour en tant que développeur (l’activité de développement d’application Mac/iPhone compte pour un tiers de mon activité, je pense pouvoir vous en parler).

Quand on crée une application Mac et que l’on souhaite utiliser Bonjour pour la découverte du réseau la chose est plutôt simple. Il nous suffit de donner un nom unique pour le service (avec le type de communication utilisée), _http._tcp par exemple puis de demander un enregistrement (ou une recherche) sur un domaine. Ce domaine peut être local pour se limiter au Bonjour local ou, tel que le conseil la documentation, une chaîne de caractères vide. Ce dernier choix, pris par beaucoup de développeur, permet de laisser le système choisir quelle est la meilleur zone d’enregistrement Bonjour.

La question est de savoir comment est choisi la meilleure zone. C’est très simple, par défaut c’est la zone locale, sauf si une autre zone est définie comme zone par défaut (dans ce cas l’enregistrement est fait dans les deux, la locale et la supplémentaire).

Pourquoi savoir tout cela ? Si comme moi, vous avez des logiciels (dont je ne citerais pas le nom) qui ne fonctionne qu’avec du Bonjour, où vous n’avez pas la possibilité de rentrer votre serveur à la main (ce qui à mon sens est un logiciel mal développé), vous rencontrerez des problèmes si vous utilisez ces logiciels dans un grand réseau ou avec du VPN.

L’idée sera donc ici de faire en sorte que la majorité des logiciels (ceux laissant le système choisir la zone) utilise notre zone WAB. À vrai dire, seul certains services s’enregistrent sur les zone « secondaire ».

Ré-ouvrez donc votre terminal sur votre serveur pour aller rajouter quelques lignes sur le fichier de configuration statique de votre zone de recherche par défaut, pour ma part c’est /var/named/db.office.inig-services.com.

Nous avions déjà fait des modifications dans ce fichier pour y spécifier la délégation de zone pour le WAB, nous allons y rajouter trois lignes pour arriver à ceci :

;THE FOLLOWING INCLUDE WAS ADDED BY SERVER ADMIN. PLEASE DO NOT REMOVE.
$INCLUDE /var/named/zones/db.office.inig-services.com.zone.apple
 
db._dns-sd._udp IN  PTR bonjour.office.inig-services.com.
r._dns-sd._udp IN  PTR bonjour.office.inig-services.com.
dr._dns-sd._udp IN  PTR bonjour.office.inig-services.com. 
 
bonjour.office.inig-services.com. 86400 IN NS office.inig-services.com.

Examinons cela avec la documentation dns-sd.org :

• db._dns-sd permet de définir notre domaine comme domaine de recherche Bonjour par défaut
• r._dns-sd permet de marquer notre domaine comme domaine d’enregistrement potenitel
• dr._dns-sd quant à lui permet de définir notre domaine comme domaine d’enregistrement par défaut

D’autre part, le fait d’activer la zone WAB dans Server Admin dans le premier article à rajouté deux entrées à tout vos domaines :

• b._dns-sd pour signaler votre domaine comme domaine de recherche potentiel
• lb._dns-sd pour que les clients utilisent votre domaine en complément du local (et ainsi forcer toutes les applications à lire son contenue)

Ceci étant fait, il ne reste plus qu’à redémarrer les services qui utilisent Bonjour.

Et voilà une grosse partie des logiciels que vous utilisez sont accessibles à travers votre VPN !

English version

Les manipulations que nous allons voir ici considère que vous avez déjà mis en place votre zone WAB avec des informations statiques comment vu dans l’article précédent. Nous allons simplement préparer cette zone pour accueillir des mises à jour d’informations de la part des clients sans aucune authentification. Ce sera donc une zone WAB ouvert.

Apple nous facilite grandement le travail aujourd’hui, un peu d’analyse sur les outils d’OS X Server et d’intuition montre comment faire. Regardons sur notre serveur les paramètres du serveur dns via la ligne de commande :

root@office / 18:30 % serveradmin settings dns
dns:loggingLevel = "info"
dns:forwarders:_array_index:0 = "8.8.4.4"
dns:forwarders:_array_index:1 = "8.8.8.8"
dns:acls:_array_index:0:addressMatchList:_array_index:0 = "localnets"
dns:acls:_array_index:0:name = "com.apple.ServerAdmin.DNS.public"
dns:isBonjourClientBrowsingEnabled = yes
...
dns:views:_array_id:2247116D-446D-4254-AEB0-8BD7377D4256:primaryZones:_array_id:0AC3AE46-8D87-4679-9EA0-CCEDB87FF11F:serial = "2010011704"
dns:views:_array_id:2247116D-446D-4254-AEB0-8BD7377D4256:primaryZones:_array_id:0AC3AE46-8D87-4679-9EA0-CCEDB87FF11F:expire = 3600
dns:views:_array_id:2247116D-446D-4254-AEB0-8BD7377D4256:primaryZones:_array_id:0AC3AE46-8D87-4679-9EA0-CCEDB87FF11F:refresh = 3600
dns:views:_array_id:2247116D-446D-4254-AEB0-8BD7377D4256:primaryZones:_array_id:0AC3AE46-8D87-4679-9EA0-CCEDB87FF11F:nameservers:_array_index:0:name = "bonjour.office.inig-services.com."
dns:views:_array_id:2247116D-446D-4254-AEB0-8BD7377D4256:primaryZones:_array_id:0AC3AE46-8D87-4679-9EA0-CCEDB87FF11F:nameservers:_array_index:0:value = "office.inig-services.com."
dns:views:_array_id:2247116D-446D-4254-AEB0-8BD7377D4256:primaryZones:_array_id:0AC3AE46-8D87-4679-9EA0-CCEDB87FF11F:negativeTimeToLive = 345600
dns:views:_array_id:2247116D-446D-4254-AEB0-8BD7377D4256:primaryZones:_array_id:0AC3AE46-8D87-4679-9EA0-CCEDB87FF11F:adminEmail = "admin@bonjour.office.inig-services.com."
dns:views:_array_id:2247116D-446D-4254-AEB0-8BD7377D4256:primaryZones:_array_id:0AC3AE46-8D87-4679-9EA0-CCEDB87FF11F:allowZoneTransfer = no
dns:views:_array_id:2247116D-446D-4254-AEB0-8BD7377D4256:primaryZones:_array_id:0AC3AE46-8D87-4679-9EA0-CCEDB87FF11F:selfResolvingHostname = "0"
dns:views:_array_id:2247116D-446D-4254-AEB0-8BD7377D4256:primaryZones:_array_id:0AC3AE46-8D87-4679-9EA0-CCEDB87FF11F:name = "bonjour.office.inig-services.com."
dns:views:_array_id:2247116D-446D-4254-AEB0-8BD7377D4256:primaryZones:_array_id:0AC3AE46-8D87-4679-9EA0-CCEDB87FF11F:reverseMappings:_array_index:0:value = "Office._http._tcp.bonjour.office.inig-services.com."
dns:views:_array_id:2247116D-446D-4254-AEB0-8BD7377D4256:primaryZones:_array_id:0AC3AE46-8D87-4679-9EA0-CCEDB87FF11F:reverseMappings:_array_index:0:ipAddress = "_http._tcp"
dns:views:_array_id:2247116D-446D-4254-AEB0-8BD7377D4256:primaryZones:_array_id:0AC3AE46-8D87-4679-9EA0-CCEDB87FF11F:serviceRecords:_array_index:0:weight = 0
dns:views:_array_id:2247116D-446D-4254-AEB0-8BD7377D4256:primaryZones:_array_id:0AC3AE46-8D87-4679-9EA0-CCEDB87FF11F:serviceRecords:_array_index:0:port = 80
dns:views:_array_id:2247116D-446D-4254-AEB0-8BD7377D4256:primaryZones:_array_id:0AC3AE46-8D87-4679-9EA0-CCEDB87FF11F:serviceRecords:_array_index:0:serviceType = "_http._tcp"
dns:views:_array_id:2247116D-446D-4254-AEB0-8BD7377D4256:primaryZones:_array_id:0AC3AE46-8D87-4679-9EA0-CCEDB87FF11F:serviceRecords:_array_index:0:instanceName = "Office"
dns:views:_array_id:2247116D-446D-4254-AEB0-8BD7377D4256:primaryZones:_array_id:0AC3AE46-8D87-4679-9EA0-CCEDB87FF11F:serviceRecords:_array_index:0:host = "office.inig-services.com."
dns:views:_array_id:2247116D-446D-4254-AEB0-8BD7377D4256:primaryZones:_array_id:0AC3AE46-8D87-4679-9EA0-CCEDB87FF11F:serviceRecords:_array_index:0:priority = 0
dns:views:_array_id:2247116D-446D-4254-AEB0-8BD7377D4256:primaryZones:_array_id:0AC3AE46-8D87-4679-9EA0-CCEDB87FF11F:serviceRecords:_array_index:0:txt = "path=/"
dns:views:_array_id:2247116D-446D-4254-AEB0-8BD7377D4256:primaryZones:_array_id:0AC3AE46-8D87-4679-9EA0-CCEDB87FF11F:timeToLive = 3600
dns:views:_array_id:2247116D-446D-4254-AEB0-8BD7377D4256:primaryZones:_array_id:0AC3AE46-8D87-4679-9EA0-CCEDB87FF11F:retry = 3600
dns:views:_array_id:2247116D-446D-4254-AEB0-8BD7377D4256:primaryZones:_array_id:0AC3AE46-8D87-4679-9EA0-CCEDB87FF11F:bonjourRegistration = "off"
dns:views:_array_id:2247116D-446D-4254-AEB0-8BD7377D4256:primaryZones:_array_id:0AC3AE46-8D87-4679-9EA0-CCEDB87FF11F:allow-update = "none;"
...

On retrouve ici les informations de notre zone bonjour.office.inig-services.com stocké d’une manière un peu spéciale : dns:views:_array_id:2:primaryZones:_array_id::

Peut importe ce que ça représente, faites attention à utiliser les bonnes valeurs.

Vous avez peut-être remarqué qu’il y a une valeur dont le nom est bonjourRegistration et qui est à off pour le moment, nous allons tout simplement passer cette valeur à open pour que Server Admin configure pour nous les différents outils permettant la mise à jour de la zone par tous les clients.

root@office / 18:38 % serveradmin settings dns:views:_array_id:2247116D-446D-4254-AEB0-8BD7377D4256:primaryZones:_array_id:0AC3AE46-8D87-4679-9EA0-CCEDB87FF11F:bonjourRegistration = "open"

À la fin de cette commande vous devriez avoir un nouveau fichier dans /etc/dns qui se nomme dnsextd.conf

root@office / 18:40 % ls -l /etc/dns
total 32
-rw-r--r--@ 1 root  wheel   204B Jan 17 18:38 dnsextd.conf.apple
-rw-r--r--@ 1 root  wheel   130B Jan 17 18:38 loggingOptions.conf.apple
-rw-r--r--@ 1 root  wheel   324B Jan 17 18:38 options.conf.apple
-rw-r--r--@ 1 root  wheel   1.3K Jan 17 18:38 publicView.conf.apple

dnsextd est un démon se chargeant de la communication entre les clients et le serveur DNS.

On voit également que les autres fichiers ont été modifiés, Server Admin y a en effet rajouté toutes les informations nécessaires au bon fonctionnement du WAB.

Notre serveur est maintenant prêt à accueillir les informations de nos clients, il ne reste plus qu’à dire à nos machines qu’elles peuvent s’enregistrer et sous quel nom.

Pour cela nous allons dans les Préférences Système de notre Mac OS X Client puis dans la section Partage. Dans le panneau de gestion de services de partage vous trouverez en haut le champ permettant de modifier le nom de votre machine ainsi qu’un bouton modifier sur lequel vous allez cliquer, il permet de modifier les informations Bonjour.

Un panel apparait, cochez la case « Utiliser un nom d’hôte dynamique global », rentrez le nom d’hôte de la machine, pas d’identifiant puis cocher la case « Annoncer les services de ce domaine via Bonjour ».

Une fois validé, votre client a dû s’enregistrer auprès de votre serveur (sous condition qu’il utilise le bon serveur DNS).
Voici comment vérifier que tout s’est bien déroulé, depuis un Mac OS X Client, ouvrez un terminal et tapez les commandes suivantes et comparez vos résultats :

yoann@Yoanns-Laptop ~ 19:00 % dns-sd -E
Looking for recommended registration domains:
Timestamp     Recommended Registration domain
19:00:26.729  Added     (More)               local
19:00:26.730  Added     (More)               mac.com
                                                                 - >; members
                                                                 - - >; yoann
19:00:26.730  Added                          inig-services.com
                                                                 - >; office
                                                                 - - >; bonjour

Cette commande m’indique la liste des domaines Bonjour recommandé pour l’enregistrement, j’y retrouve mon domaine .local (celui utilisé normalement), le domaine de MobileMe (et oui, MobileMe se sert de WAB pour vous fournir les services de Back to my Mac) et notre domaine, tout va bien donc !

Autre commande (qui nécessite que votre client enregistré ai le partage AFP d’actif) :

yoann@Yoanns-Laptop ~ 19:00 % dns-sd -B _afpovertcp._tcp bonjour.office.inig-services.com.
Browsing for _afpovertcp._tcp.bonjour.office.inig-services.com.
Timestamp     A/R Flags if Domain                    Service Type              Instance Name
19:03:30.913  Add     2  0 bonjour.office.inig-services.com. _afpovertcp._tcp.         Yoann's Laptop

Je liste ici tous les enregistrements pour les services de type _afpovertcp._tcp sur ma zone bonjour.office.inig-services.com.

Si je veux maintenant obtenir les informations pour un service sur une machine, voici ce que j’ai à faire :

yoann@Yoanns-Laptop ~ 19:05 % dns-sd -L "Yoann's Laptop" _afpovertcp._tcp bonjour.office.inig-services.com.
Lookup Yoann's Laptop._afpovertcp._tcp.bonjour.office.inig-services.com.
19:05:26.225  Yoann's\032Laptop._afpovertcp._tcp.bonjour.office.inig-services.com. can be reached at yoann-laptop.office.inig-services.com.:548 (interface 0)

Un autre moyen de voir facilement les informations publiées sur les domaines Bonjour est d’utiliser l’excellent Bonjour Browser ici lancé depuis une autre machine :

Et voilà, votre zone WAB open est fonctionnelle. Ne seront enregistrés sur cette zone que les clients ayant les options adéquats de coché dans leurs préférences système. Pour les autres, ils verront ce qui est publié par les machines configuré sous condition d’avoir le bon serveur DNS et la bonne zone de recherche de configuré.

Voici par exemple la vue réseau d’un client connecté en VPN sur mon serveur :

Et pour Safari :

Si vous avez des questions ou des commentaires, n’hésitez pas.

N’oubliez pas que vous pouvez me retrouver comme formateur pour les centres de formation suivant :

• Terkane (Fréjus/St Raphaël)
• Apaxxdesigns (Paris)

English version

Si vous êtes depuis longtemps dans le monde OS X Server vous devez savoir que Wide Area Bonjour (WAB) fait partie des technologies les plus génial, mais aussi des plus incompréhensibles à mettre à œuvre au premier abord.

Pour ma part j’essaye de faire marcher cette techno depuis Tiger, mais il faut dire que les documentations sont pauvres à ce sujet, j’en veux pour preuve le site officiel dns-sd.org qui ne contient que quatre pages…

Cela dit, à force de discussion avec d’autres administrateurs j’ai réussi à collecter toutes les informations utiles pour un fonctionnement « out of the box ». J’en profie pour remercier Guillaume Gete pour m’avoir transféré les documentations qu’il avait lui-même collecté, elles se sont montrée bien utiles.

Avant d’attaquer cet article je tiens à dire que j’ai réussi à faire marcher tout ceci un samedi soir vers 1h du matin. Autant dire que je n’ai pas encore poussé les expérimentations dessus. La série d’article que je vais écrire à ce propos s’adresse donc à des administrateurs avertis souhaitant s’intéresser à cette technologie. À vous de tester ses possibilités avant de le mettre en production.

J’ai choisi d’écrire plusieurs petits articles pour ce sujet plutôt qu’un seul gros, certaines choses sont plus fiables que d’autre et que WAB peut être utilisé de plusieurs manière.

L’intérêt d’un tel évincement serait d’avoir le contrôle maximum sur son service mail et ainsi éviter une suppression de mail important par un service anti-spam un peut trop agressif ou encore de laisser plus d’espace mail disponible pour vos utilisateurs. Pour autant il a un très net désavantage, il faut que votre serveur mail soit toujours en ligne. Autant dire que si ce serveur est hébergé dans les locaux de votre TPE/PME il y a de forte chance qu’un jour ou l’autre il y ai une coupure d’électricité ou d’Internet.

L’objectif ici va être d’avoir à la fois les avantages d’un serveur interne et la sécurité d’un serveur fournis par votre hébergeur.

Pour comprendre à quoi va ressemblé le fonctionnement de ce système, rien de mieux qu’un schéma :

Autrement dit, notre serveur va se servir du protocole POP3 pour se connecter au serveur mail de notre FAI et récupérer les mails pour les transférer en local. Une configuration permettra de régler l’association entre les identifiants du serveur de notre fournisseur et nos comptes locaux.

L’outil qui permet de faire cela sous Mac OS X Server n’est nul autre que Fetchmail. Avec Microsoft Exchange vous connaissez ce système via le « Connecteur POP3″.

Cet article portera donc sur la configuration initiale du service mail d’OS X ainsi que de fetchmail dans cet optique de déploiement.

]]> http://blog.inig-services.com/archives/175/feed 1 http://blog.inig-services.com/archives/51 http://blog.inig-services.com/archives/51#comments Fri, 17 Jul 2009 08:39:23 +0000 Yoann http://blog.inig-services.com/?p=51 Aujourd’hui tous les systèmes d’exploitation sont conçus pour être multi-utilisateurs, ce qui est en soit pratique mais qui peut également devenir rapidement problématique si nous nous posons la question des droits d’accès. Autrement dit, comment dans un environnement multi-utilisateur pouvons nous êtres certain que des données privées le reste ? La réponse n’est autre que les droits d’accès.

Cet article ne traitera que de la partie théorique des droits d’accès et que très peut de la partie pratique (uniquement pour les exemples), il vous est donc recommandé de lire le manuel de fonctionnement des commandes ls, chown et chmod du système Mac OS X.

Le système Mac OS X (qui inclut Mac OS X Server) est construit sur une base UNIX (Darwin). Cette information peut paraître anodine mais elle nous donne un premier élément de réponse à notre gestion des droits d’accès, le système POSIX.

Le terme POSIX désigne une série de standards définissant le comportement des systèmes de la famille UNIX, pour plus de précision sur l’ensemble du standard je vous invite à consulter l’article Wikipedia, nous nous attarderons ici seulement sur la partie droit d’accès que nous résumerons ainsi :

Un fichier ou un dossier d’un système UNIX voit ses accès contrôlé à trois niveaux : l’utilisateur, le groupe et les autres; et par trois droits possibles : lecture, écriture, exécution. Cela entend que nous allons pouvoir, grace à ce système, préciser quel utilisateur est propriétaire de la ressource, quel est le groupe associé, et quel comportement adopter pour le reste des utilisateurs. À chacun de ces niveaux nous allons pouvoir dire si l’entité concerné a le droit de lire, d’écrire ou d’exécuter la ressource.

La notation adopté pour ces trois droits est R (Lecture), W (Ecriture), X (Exécution) et s’interprète de la sorte :

Pour un fichier :

• R : Lire le contenu du fichier
• W : Modifier le fichier
• X : Exécuter le fichier (utiliser dans le cas de fichier binaire ou de scripts)

Pour un dossier, les droits sont identiques mais l’interprétation est légèrement différente :

• R : Lister le contenu du dossier
• W : Modifier le contenu du dossier (ajouter ou supprimer une ressource)
• X : Traverser le dossier

Si les deux premiers droits applicable pour un dossier sont simples, le dernier mérite une explication. Le droit de traverser un dossier entend le droit de l’écrire dans un chemin d’accès. Si l’ont regarde l’utilisation d’un système d’exploitation par une ligne de commande, nous sommes obliger d’écrire le chemin d’accès à nos ressources. Si par exemple je veux lire le contenu de mon fichier comment_devenir_riche.txt se trouvant dans le dossier Documents de mon dossier personnel en ligne de commande je utilise cette commande :

less /Users/yoanngini/Documents/comment_devenir_riche.txt

Pour accéder à ma formule secrète pour devenir riche je dois partir de la racine (/) de mon système puis le dossier Users, mon dossier personnel yoanngini et enfin mon dossier Documents. pour que mon action réussisse ici seul deux droits seront necessaire, celui d’exécution sur les trois dossiers Users, yoanngini, Documents, et le droit de lecture sur mon fichier comment_devenir_riche.txt.

En effet il n’est pas nécessaire d’avoir les droits de lecture (lister) sur un dossier pour accéder à son contenue mais uniquement le droit d’exécution.

Si nous prenons un exemple existant dans le système OS X, la drop box (ou boite de dépots en français) se trouvant dans votre dossier personnel/Public et que nous regardons les droits d’accès avec notre terminal (commande ls) nous obtenons ceci :

ls -l ~/Public
total 0
drwx-wx-wx+ 3 yoanngini staff 102B 24 mai 2008 Drop Box/

La première série de caractère nous indique le type de la ressource listé (premier caractère), ensuite par groupe de trois caractères nous avons les droits d’accès pour le propriétaire (indiqué en colonne trois); pour le groupe (colonne quatre) et pour les autres. Soit :

• d : indique que la ressource est un dossier (peut être un l pour un lien symbolique ou un – pour un fichier)
• rwx : droit de lecture, d’écriture et d’exécution pour le propriétaire yoanngini
• -wx : droit d’écriture et d’exécution pour le groupe staff
• -wx : droit d’écriture et d’exécution pour les autres

Pour l’utilisateur qu’est-ce que cela entend ?

• Le propriétaire a tous les droits sur son dossier
• Le reste (staff + les autres) a le droit de traverser et d’écrire dans le dossier, mais pas de lister son contenue

C’est ici le comportement même de la drop box, un dossier ou tout le monde pourra écrire mais où seul le propriétaire pourra lire.

Maintenant que nous connaissons les droits d’accès avec le système POSIX, prenons un cas d’espèce pour mettre en lumière ses limites.

Nous sommes dans l’entreprise Protovision, éditeur de jeux vidéo pour ordinateur. L’entreprise est divisé en équipe en fonction des jeux en cours de production en plus des équipes administratives. Ce qui nous donne coté informatique cette liste de groupe :

• Direction (nom court : direction)
• Comptabilité (nom court : compta)
• Equipe Global Thermonuclear War (nom court : e_gtw)
• Equipe The Dead Code (nom court : e_tdc)

L’équipe du jeu Global Thermonuclear War a fait du très bon travail et toute l’entreprise prépare une soirée surprise pour eux, pour se faire toutes les informations sur cette soirée sont mise sur un dossier commun dans lequel les organisateurs peuvent lire et écrire, et tout le monde sauf l’équipe du jeu doit pouvoir y lire.

Pour réaliser ceci avec les droits d’accès POSIX nous allons devoir créer deux nouveaux groupes :

• Organisateurs de la soirée (nom court party_o)
• Complices de la soirée (nom court party_c) — Ce groupe inclus le groupe des organisateurs

Et ensuite créer une arborescence particulière en commençant par créer un dossier A dont le propriétaire sera l’administrateur, il disposera de tous les droits (rwx); le groupe sera celui des complices de la soirée en lecture seule (r-x); et les autres n’auront aucuns droits (—). Ensuite à l’intérieur du dossier A nous devrons créer un dossier B , le propriétaire sera toujours l’administrateur avec tous les droits (rwx); le groupe sera cette fois ci celui des organisateurs et disposera de tous les droits également (rwx) et les autres auront ici un accès en lecture seul (r-x).

Si on analyse ce qu’il va se passer au niveau du système, l’utilisateur devra en premier accéder au dossier A, pour cela il faudra qu’il soit soit administrateur soir complice de la soirée, les membres de l’équipe Global Thermonuclear War seront donc bloqué à partir de la. Ensuite à l’intérieur du dossier A il ne se passera rien, tout se passera dans le dossier B ou tout le monde pourra accéder en lecture et seul l’administrateur et le groupe des organisateurs pourra écrire.

L’astuce à voir ici est que la limitation d’accès s’est fait en combinant deux séries de droits POSIX pour arriver à nos fins, ce qui, vous en conviendrez, peut très vite devenir complexe et impose la création de nouveau groupe.

Pour aller plus loin dans notre gestion des droits d’accès nous allons donc avoir besoin d’un autre système de droit, les ACL, pour Access Control List (Liste de contrôle d’accès). Ce système vient en complément du système POSIX, il vous faudra donc connaître les deux parfaitement pour être efficace.

Le système des ACL introduit la possibilité d’avoir une liste de droits appliquer à autant d’utilisateur ou de groupe que nécessaire et pour une ressource et une précision sur les droits eux même accrue.

Vous retrouverez la liste des droits ACL dans la page de manuel de la commande chmod, dans la section ACL MANIPULATION OPTIONS, les voici expliqué :

Droits applicables à toutes les ressources :

• delete : Permission de supprimer la ressource sur laquelle le droit est appliqué
• readattr : Permission de lire les attributs standards d’une ressource
• writeattr : Permission de modifier les attributs standards d’une ressource
• readextattr : Permission de lire les attributs étendus d’une ressource
• writeexattr : Permission de modifier les attributs étendus d’une ressource
• readsecurity : Permission de lire les attributs de sécurité d’une ressource (les ACL, le propriétaire, etc) — Nécessaire pour savoir qu’on a les droits sur la ressource
• writesecurity : Permission de modifier les attributs de sécurité d’une ressource (ACL, droit POSIX, propriétaire, etc)
• chown : Permission à l’utilisateur de prendre la propriété POSIX de la ressource

Droits applicables aux dossiers uniquement :

• list : Le droit de lister le contenu d’un dossier
• search : Le droit de faire une recherche par nom de fichier à l’intérieur de ce dossier
• add_file : Le droit de créer un nouveau fichier à l’intérieur du dossier en question
• add_subdirectory : Le droit de créer un nouveau dossier à l’intérieur du dossier en question
• delete_child : Le droit de supprimer un élément inclus, dossier ou fichier

Droits applicables aux fichiers uniquement :

• read : Permission de lire un fichier
• write : Permission de modifier un fichier dans son intégralité
• append : Permission de modifier un fichier sans pour autant modifier l’existant (ne marche pas avec tous les types de fichier, essentiellement le droit de rajouter des informations à la fin du fichier)
• execute : Permission d’exécuter le programme ou le script

Notion d’héritage (s’applique sur les dossiers) :

• file_inherit : Les fichiers inclus hériterons de l’ACL
• directory_inherit : Les dossier inclus hériterons de l’ACL
• limit_inherit : Limite l’héritage aux premier niveau de sous dossier, pour éviter que l’ACL soit appliqué aux sous dossier inclus dans les dossiers enfants de premier niveau
• only_inherit : L’ACL ne sera pas interprété pour le dossier sur lequel elle est appliqué mais uniquement pour ses éléments enfants (peut permettre de donner le droit d’ajouter des fichiers dans les dossiers inclus mais pas dans le dossier lui même)

Chacune de ces options pourra être utiliser donner ou refuser des droits aux utilisateurs via les mots clef allow et deny lors de la création des droits

Si nous reprenons notre exemple avec les ACL nous auront toujours besoin d’un groupe organisateur mais pas d’un groupe invité, et d’un seul dossier. Voici comment faire :

Nous partons donc avec un dossier C sur lequel nous allons utiliser ingénieusement ACL en complément des droits POSIX. Le propriétaire sera toujours l’administrateur avec tous les droits, le groupe sera le groupe des organisateurs avec tous les droits également et les autres n’auront que les droits de lecture. Il nous reste simplement à rajouter une ACL interdisant tout type d’accès à l’équipe Global Thermonuclear War.

Enfantin ! N’est-ce pas ?

Comme vu dans un précédent article nous avons différents fichier de configuration à notre disposition, entre autre /var/named/zones/db.inig-services.lan.zone.apple et /var/named/db.inig-services.lan..

Il faut se rappeler que le premier est celui modifier par Server Admin nous ne devons donc pas l’éditer à la main sous peine de perdre toutes nos modifications à la prochaine utilisation de l’outil de configuration.

Regardons dons le second : /var/named/db.inig-services.lan.

Il contiens ceci :
;THE FOLLOWING INCLUDE WAS ADDED BY SERVER ADMIN. PLEASE DO NOT REMOVE.
$INCLUDE /var/named/zones/db.inig-services.lan.zone.apple


C’est à dire l’inclusion du fichier de définition de zone faite par Server Admin, il nous reste donc a modifier se fichier en se plaçant après l’inclusion.

Le serveur DNS de Mac OS X Server est BIND, il nous suffit donc (en se rapportant à la documentation) de rajouter des entrée NS et A pour définir une zone délégué, son serveur ainsi que l’adresse IP du serveur.

Voici donc le fichier final :

;THE FOLLOWING INCLUDE WAS ADDED BY SERVER ADMIN. PLEASE DO NOT REMOVE.
$INCLUDE /var/named/zones/db.inig-services.lan.zone.apple

lab IN NS server.lab.inig-services.lan.
server.lab.inig-services.lan. IN A 10.1.1.1


Pour une question de confort, il faudra rajouter notre serveur en serveur secondaire du serveur maitre de la zone délégué, sans quoi le support des entrées MX et autres posera problème.

Pourtant il peut être intéressant de faire certaine chose en ligne de commande. Commençons par le DNS.

Comme vous le savez peut être, le serveur DNS embarqué par OS X Server n’est autre que le projet open source BIND. Pour comprendre comment marche ses fichiers de configuration, je vous renvois vers la documentation. Voyons ici simplement où son les fichier et comment sont-ils agencé, de sorte a garder une compatibilité entre les fichier que nous pourrions créer à la main et l’interface graphique. Pour les exemples nous prendrons le domaine home.lan.

Premièrement, déclarons des zone DNS, cela se passe dans : /etc/dns/publicView.conf.apple

Dans se fichier vous rajouterez quelques ligne pour indiquer à votre serveur qu’il est contrôleur principale d’un domaine. Voici ces quelques lignes :

zone "home.lan." IN {
      type master;
      file "db.home.lan.";
      allow-transfert {none;};
      allow-update {none;};
};

Faites attention à bien conserver le db devant le nom de domaine pour le nom de fichier ainsi que le « . » final, ce sera le nom du futur fichier destiné a recevoir la définition de la zone.

Maintenant il faut définir la zone en elle même, ici le fonctionnement est peut communs. Nous allons devoir définir dans le dossier /var/named/zones nos différentes zone et ensuite créer un lien dans /var/named pour que le fichier soit pris en compte.

Définissons une zone : /var/named/zones/db.home.lan.zone.apple


$TTL 259200
home.lan. IN SOA ns1.home.lan. admin.home.lan. (
      2008083001      ;Serial
      86400                ;Refresh every 24 hours
      3600                  ;Retry
      604800              ;Expire after 7 days
      345600              ;Negative caching TTL
)

home.lan.      IN      NS                 ns1.home.lan.
home.lan.      IN      MX      10      mail.home.lan.

ns1                IN      A                   192.168.1.5
mail               IN      A                   192.168.1.5

www              IN      CNAME          ns1.home.lan.

Rajoutons son lien : /var/named/db.home.lan.

Le lien en question est tout simplement un fichier texte qui contiens ceci :
$INCLUDE /var/named/zones/db.home.lan.zone.apple

Une fois cela terminé, vous devrez penser à faire la zone de recherche inverse (ex: 1.168.192.in-addr.arpa.)

Il ne vous reste qu’à démarrer le service DNS avec la commande :
sudo serveradmin start dns

Si vous avez déjà utilisé l’outil graphique de configuration du DNS vous avez remarqué qu’il y a d’autres options, dans la partie générale cette fois çi, qui va concerner le fonctionnement globale du service. Ces options sont définie dans le fichier /etc/dns/options.conf.apple. Vous pourrez entre autre y régler des serveur DNS de redirection (forward). Cette entrée définie le serveur DNS à utiliser lorsque la requette conserne une zone non gérer.
forwarders { 192.168.1.1; };

Vous pourrez aussi interdire le transfert de zone si vous le souhaitez :
allow-transfer { none; };

Tant qu’à y être, pourquoi de pas assigner le serveur utiliser par la connexion réseau de votre serveur (en toute logique dire à votre serveur qu’il doit s’utiliser lui même en serveur DNS).

Pour se faire nous avons quelques commande à tapper :
sudo networksetup -setdnsservers Ethernet 127.0.0.1
sudo networksetup -setsearchdomains Ethernet home.lan.

Ces commandes vous permettrons de définir le serveur DNS 127.0.0.1 ainsi que le domaine de recherche par défaut home.lan. pour l’interface nommé Ethernet.

Et pour finir pourquoi ne pas vérifier que le nom d’hôte de votre serveur est bien synchronisé avec celui que vous avez déclaré dans votre serveur DNS ? Utilisez pour cela la commande :
sudo changeip -checkhostname