Gotchas Macintosh

8

Jusqu'à présent, je n'ai géré que des réseaux avec des utilisateurs Windows et le serveur occasionnel * nix. Bientôt, quelques utilisateurs de Mac seront ajoutés à notre réseau. Quels sont les "pièges" à rechercher lors de l'ajout de Mac au réseau? Principales préoccupations ici: compatibilité avec Active Directory et sécurité

Dinah
la source

Réponses:

11

Vous souhaiterez peut-être investir dans un utilitaire qui désactive la création de fichiers .DS_Store sur les volumes réseau. Sinon, vous verrez ces petits fichiers apparaître sur tous les volumes de votre réseau lorsque les utilisateurs Mac les utilisent.

J'utilise une application appelée Cocktail pour cela.

Paul Lefebvre
la source
3
vous pouvez également le faire à partir du terminal - il existe un programme appelé "par défaut" qui vous permet d'écrire des clés de configuration (qui rappellent le registre) "par défaut, écrivez com.apple.desktopservices DSDontWriteNetworkStores true"
reconbot
D'après les informations trouvées <a href=" support.apple.com/kb/TA21373?viewlocale=en_US"> ici </… >, c'est un petit prix à payer pour simplement désactiver la valeur par défaut comme le suggère l'assistant
Adrian Anttila
2

Mises à jour ... bien qu'OS X puisse s'authentifier auprès d'AD, rien ne les oblige à mettre à jour leurs ordinateurs. Assurez-vous de leur parler de l'installation des mises à jour dès leur sortie. Il n'y a vraiment aucun moyen de les forcer à le faire.

trent
la source
2

Si votre domaine interne est .local, vous aurez un problème pour résoudre les noms via DNS. Il existe un ancien article sur Mac OS X Hints qui décrit une solution:

J'ai créé un company.localfichier dans /etc/resolveret rempli ce fichier avec les serveurs de noms pour le company.localdomaine AD. Cela permet à Mac OS X d'utiliser le DNS standard pour résoudre company.local(ou subdomain.company.local), tout en permettant à Rendezvous de fonctionner comme prévu.

Le seul inconvénient que j'ai vu dans cette approche est que les serveurs de noms de ce company.localfichier ne sont pas mis à jour via DHCP, je dois donc les mettre à jour manuellement.

Voici un document d'assistance plus officiel d'Apple qui analysera votre existant /etc/resolv.confpour remplir le fichier /etc/resolvers.

Jared Oberhaus
la source
hmm. je pense que vous pouvez simplement ajouter "local" à "Domaines de recherche" dans Network Prefs. Cela devrait forcer le Mac à rechercher les noms d'hôte ".local" sur le serveur DNS au lieu d'utiliser Bonjour
nom d'utilisateur
La réponse à une autre question ServerFault prétend que cela ne fonctionne pas. serverfault.com/questions/6509/…
Jared Oberhaus
2

Si vous avez suffisamment de Mac, je vous suggère d'ajouter un serveur Mac - pour créer ce qu'on appelle la "Holy Trinity". Vous n'avez même pas besoin d'acheter un Xserve - le serveur OSX fonctionne sur un Mac Mini!

Les Mac utilisent AD pour tous les accès / autorisations normaux et le serveur Mac pour les tâches spécifiques au Mac telles que les mises à jour (vous trouverez une version Mac de WSUS appelée Software Update Server). Vous pouvez également utiliser les options de déploiement du serveur Mac (NetInstall) pour les installations.

Jon Rhoades
la source
J'en avais toujours entendu parler comme du Triangle d'Or, mais Holy Trinity est certainement intéressant.
Chealion
1

Certaines versions d'OSX se bloquent beaucoup lorsqu'elles sont connectées à un serveur Windows 2003 sur lequel Active Directory est activé. Ils semblent l'avoir corrigé à un moment donné mais je ne pouvais pas vous dire quand. Alors restez à jour.

Selon qui obtient la machine, vous pouvez ou non souhaiter activer la connexion réseau. Bien que vous puissiez restreindre l'accès des utilisateurs (à l'aide du contrôle parental), vous souhaiterez peut-être simplement que l'utilisateur ne soit pas un administrateur et le laisser comme autant d'applications se mettent à jour et génèrent d'autres applications, donc les restreindre peut entraîner des problèmes. J'ai toujours accordé à mes utilisateurs Mac un accès complet à l'administration et je n'ai jamais vu aucun problème surgir dans lequel j'ai vu mes utilisateurs Windows se connecter lorsqu'ils ont un accès administrateur complet à leurs boîtes. Il n'y a fondamentalement aucun logiciel espion ou virus pour le mac, il est beaucoup plus facile à entretenir.

Vous devez également noter que chaque Mac dispose d'une fonction de «partage Internet» fournie avec un serveur DHCP, ce qui peut provoquer des problèmes.

Activez également imap en échange et laissez-les utiliser le "Mail" d'Apple. C'est mieux que l'entourage. Le carnet d'adresses a également un support LDAP intégré. Il n'y a rien d'autre de spécial pour le Mac qui me vient à l'esprit.

reconbot
la source
0

Voici une bonne astuce, ne vous embêtez pas à essayer de faire en sorte qu'OSX se connecte à votre AD - cela peut être fait mais je pense que ce n'est pas si simple et peut prendre un peu de support. Achetez quelque chose appelé «AdmitMac» sur http://www.thursby.com/ - cela enlève toute la douleur et est bien sûr soutenu directement par eux. Oh et ne laissez pas vos Mac utiliser des protocoles dont vous n'êtes pas satisfait, ils sont très flexibles, mais ils devraient vous contourner et non l'inverse.

Chopper3
la source
0

Je connais quelques problèmes d'assistance aux utilisateurs finaux que vous pourriez rencontrer:

Avery Payne
la source
0

Une chose m'a pris du temps à comprendre: si vous définissez une ACL "hériter" sur un dossier, cela n'affectera que les fichiers nouvellement créés - le "gotcha" étant que si un utilisateur "fait glisser et dépose" un fichier dans le dossier en question, les autorisations pour le dossier ne changeront en aucune façon (à moins qu'il ne soit glissé depuis un volume différent, où il sera, par essence, copié et collé). Pour que les fichiers supposent l'ACL héritée que vous définissez, ils devront «copier-coller» ou définir manuellement les autorisations ... peut-être (puisque le comportement de l'ACL devrait en théorie être le même), cela se produit également sous Windows, je ne le fais pas » t sais, mais ça vaut la peine de répéter.

Nom d'utilisateur
la source