Délégation Centre-Auvergne-Limousin

- Home - News - Conseils - SécuritéMise à jour  -  Liens  -  Accès  -

Délégation Centre-Auvergne-Limousin

Livre blanc Windows Services for UNIX 3.5

Dernière mise à jour le 22 avril 2004

Télécharger la version SFU 3.5

Charlie Russel

Microsoft MVP pour l’interopérabilité Windows Server 2003

Résumé

Microsoft® Windows® Services for UNIX (SFU) 3.5 offre un large éventail de services réseau inter-plate-forme pris en charge et totalement intégrés, destinés aux clients professionnels qui doivent intégrer des environnements Windows et UNIX. Il permet à ces clients d’accéder de manière transparente aux informations stockées dans plusieurs plates-formes, consolide la gestion réseau entre plates-formes et réutilise les applications et scripts UNIX sous Windows. Ce livre blanc étudie les fonctionnalités de SFU 3.5 et s’adresse à l’administrateur système, au développeur ou à l’intégrateur d’un réseau mixte UNIX et Windows.

Sur cette page
Introduction Introduction
Nouvelles fonctionnalités SFU 3.5 Nouvelles fonctionnalités SFU 3.5
Pourquoi Services for UNIX ? Pourquoi Services for UNIX ?
Interix Interix
Choix d’installation personnalisés Choix d’installation personnalisés
Scénarios d’utilisation Scénarios d’utilisation
Résumé Résumé
Liens connexes Liens connexes

Introduction

Depuis son introduction en 1999, Microsoft® Windows® Services for UNIX (SFU) a joué un rôle majeur pour ceux qui souhaitent faire cohabiter le mieux possible les réseaux Windows et UNIX. Lorsque Windows Services for UNIX 3.0 a été publié en 2002, Microsoft a ajouté de nouvelles fonctionnalités significatives via l’ajout de la technologie Interix, un environnement complet d’application et de script UNIX qui s’exécute en tant que sous-système Windows natif. Avec la publication de Windows Services for UNIX 3.5 en 2004, Microsoft améliore son ensemble d’outils d’interopérabilité en ajoutant à Interix la prise en charge de l’internationalisation et un ensemble d’API de pthread, afin d’étendre sa suite d’interopérabilité.

Avec SFU 3.5, Microsoft a étendu le kit SDK Interix afin de prendre en charge les applications à threads tout en mettant à jour les utilitaires et les API afin de prendre en charge l’internationalisation. La prise en charge du système de fichiers réseau (NFS) a également été étendue afin d’améliorer l’authentification dans les environnements Microsoft Windows Server™ 2003 Active Directory® natifs.

Nouvelles fonctionnalités SFU 3.5

Microsoft a beaucoup investi pour améliorer les performances de SFU. Par exemple, le sous-système Interix comporte des améliorations dans tous les aspects des performances, allant d’améliorations de 30 % des performances fork et exec, à des améliorations de 75 % en termes de bande passante de canaux, en passant par des améliorations plus de 100 % dans les E/S de fichiers et plus de 150 % en termes de latence fstat. L’écart entre les performances des E/S de fichiers et celles du sous-système Win32 ne dépasse plus 10 %. D’autres améliorations ont également été apportées en termes d’évolutivité multiprocesseur. Des améliorations substantielles des performances ont également été apportées dans les composants Serveur pour NFS et Serveur pour NIS de SFU.

Windows Services for UNIX 3.5 fonctionne avec un large éventail de plates-formes UNIX et Linux, via des protocoles et utilitaires standard. Il a été testé explicitement pour l’interopérabilité avec Solaris 7, Solaris 8, HP-UX 11, AIX 5L 5.2 et Red Hat Linux 8.0. Windows Services for UNIX 3.5 fonctionne sous Microsoft® Windows 2000 (versions Professionnel et Server), Microsoft® Windows XP Professionnel et Windows Server 2003.

Windows Services for UNIX 3.5 ajoute des fonctionnalités et améliorations significatives à la gamme des produits Windows Serveur et représente une avancée majeure en termes d’interopérabilité des scripts et des programmes. Le tableau 1 récapitule les principales nouvelles fonctionnalités de Windows SFU 3.5 depuis la version SFU 2.0.

Tableau 1. Fonctionnalités nouvelles et améliorées de SFU 3.5

Fonctionnalité Description

Client NFS

Prend en charge setuid, setgid et les sticky bits

 

Prise en charge des liens symboliques

 

Améliorations des performances

 

Internationalisation : options de langage supplémentaires

Serveur NFS

Améliorations significatives des performances

 

Prise en charge des clusters actif-actif de partages NFS

 

Prise en charge des setuid, setgid et sticky bits

 

Gestion par partage de l’accès racine et anonyme

 

Amélioration du modèle de mise en correspondance des permissions entre Windows et UNIX

 

Améliorations de l’internationalisation

SFU 3.5

Prise en charge du service de cliché instantané de volume Windows Server 2003

SFU 3.5

Authentification simplifiée et améliorée dans les environnements Windows Server 2003 Active Directory

NFS Gateway

Améliorations de l’internationalisation

Serveur de mise en correspondance

Serveur de mise en correspondance avec prise en charge des clusters

 

Améliorations des performances, de la sécurité et de l’évolutivité

 

Prise en charge des serveurs de mise en correspondance redondants

 

Améliorations de l’internationalisation

Server for NIS

Prise en charge du cryptage MD5

 

Améliorations de l’évolutivité et des performances

 

Nombreuses améliorations de l’utilisation et de l’administration

Synchronisation de mot de passe

Nouvelle prise en charge de la configuration de mots de passe avec le modèle PAM (Pluggable Authentication Model) sous UNIX

Serveur Telnet

Améliorations de la sécurité et de l’évolutivité

 

Prise en charge du protocole Internet Protocol version 6 (Ipv6)

 

Prise en charge des terminaux Dumb (périphériques portatifs)

Client Telnet

Prise en charge du protocole IPv6

 

Internationalisation

Interix et le kit SDK Interix

Nouveauté de SFU 3.0

 

Amélioration du débit et de la stabilité

 

Système de fichiers à racine unique

SFU 3.5

Mise à jour des utilitaires pour l’internationalisation

SFU 3.5

Prise en charge des pthreads dans le kit SDK

SFU 3.5

Prise en charge des API pour l’internationalisation

Nous allons examiner chacun des domaines et améliorations ajoutés depuis la version SFU 2.0, puis nous allons nous concentrer sur l’intégration du sous-système Interix.

Pourquoi Services for UNIX ?

Avec l’adoption croissante du système d'exploitation Windows dans les environnements UNIX existants, la nécessité de l’interopérabilité des deux plates-formes augmente. Windows Services for UNIX 3.5 offre un ensemble de fonctionnalités complémentaires à Windows 2000, Windows XP et Windows Server 2003, permettant une plus grande interopérabilité avec les systèmes basés sur UNIX tout en permettant la migration sous Windows des applications écrites à l’origine pour fonctionner sous UNIX et Linux.

Windows Services for UNIX 3.5 offre un éventail complet de composants d’interopérabilité pris en charge et totalement intégrés, ainsi qu’un kit SDK complet prenant en charge plus de 2 000 API UNIX. Windows Services for UNIX 3.5 offre :

Des composants d’interopérabilité qui permettent l’intégration transparente des systèmes Windows et UNIX.

Des composants de gestion permettant aux organisations de simplifier l’administration réseau et la gestion des comptes entre les deux plates-formes.

Des composants de développement offrant un environnement de développement complet qui tire parti de l’expertise UNIX.

Des composants de migration qui permettent aux organisations de recibler les applications et scripts UNIX sur Windows via la technologie Interix de Windows Services for UNIX, offrant ainsi un environnement robuste et peu coûteux pour les applications UNIX, tout en offrant une avancée vers les fonctionnalités .NET.

Windows Services for UNIX offre quatre scénarios pour le réseau hétérogène UNIX et Windows, qui vous permet de tirer le meilleur parti des deux environnements afin de simplifier et de gérer votre entreprise. Les quatre scénarios sont les suivants :

Utilisation des ressources réseau UNIX.

Simplification de l’administration réseau.

Simplification de la gestion des comptes.

Utilisation de l’expertise UNIX.

Dans cette section, nous allons examiner plus en détail les trois premiers scénarios. Dans la section suivante, nous allons examiner comment Windows Services for UNIX peut apporter une valeur ajoutée et améliorer la gestion informatique entre divers environnements en vous permettant d’utiliser sous Windows votre expertise et vos applications UNIX.

Utilisation des ressources réseau UNIX

Windows Services for UNIX offre quatre outils importants qui vous permettent d’utiliser les ressources réseau UNIX pour vos clients et serveurs Windows tout en permettant à vos clients UNIX d’utiliser les ressources des serveurs Windows. Ces quatre outils sont les suivants :

Client pour NFS. Cet outil permet à Windows 2000, Windows XP et Windows Server 2003 d’accéder aux ressources des serveurs NFS sur un réseau.

Server for NFS. Cet outil permet aux clients NFS d’un réseau d’accéder aux ressources Windows via NFS. Le service NFS Server prend désormais totalement en charge les clusters, notamment les clusters actif-actif.

Gateway for NFS. Cet outil permet à Windows 2000 Server ou Windows Server 2003 d’offrir aux ressources NFS d’un réseau un accès transparent aux ordinateurs Windows en aval, sans qu’il soit nécessaire d’installer d’autres logiciels sur les ordinateurs Windows.

Server for PCNFS. Cet outil permet à Windows de jouer le rôle de serveur PCNFSD, permettant l’authentification utilisateur pour l’accès des serveurs NFS aux fichiers.

Gestion et configuration

La console MMC (Microsoft Management Console) Administration de Services for UNIX permet d’administrer les services Client for NFS et Server for NFS, mais pas le service Gateway for NFS. Pour ouvrir la console, vous pouvez soit la lancer à partir du menu Démarrer, soit ouvrir le composant logiciel enfichable Sfumgmt.msc à partir d’une console MMC. Vous pouvez également administrer la plupart des options NFS à partir de la ligne de commande. La syntaxe de ligne de commande complète est disponible en tapant ce qui suit sur la ligne de commande :

nfsadmin [client | server | gw] /?

Client for NFS

Les propriétés que vous pouvez modifier pour Client for NFS sont les suivantes :

Authentification. Serveur de mise en correspondance à utiliser pour l’authentification.

Permissions de fichiers. Permissions par défaut d’accès aux fichiers. Les permissions par défaut sont les suivantes :

rwxr-xr-x

Performances. Les paramètres des facteurs suivants liés aux performances (et leurs valeurs par défaut) :

Tableau 2. Paramètres de performance

Paramètre Valeur par défaut

Protocole de transport

UDP

Type de montage

Logiciel

Tentatives

1

Expiration

0,8 secondes

Taille du tampon de lecture

32 ko

Taille du tampon d’écriture

2 ko

Connexion à un export NFS

Vous pouvez vous connecter à un export NFS de différentes façons en utilisant la syntaxe Windows standard (\\serveur\partage) ou la syntaxe UNIX standard (serveur:/partage). À partir de la ligne de commande, vous pouvez utiliser les commandes réseau Windows standard ou la commande de montage de type UNIX avec l’une ou l’autre de ces syntaxes. Vous pouvez également parcourir le Voisinage réseau dans l’Explorateur. À partir de la ligne de commande, les commandes suivantes sont équivalentes :

net use * server1:/home

net use * \\server1\home

mount server1:/home *

mount \\server1\home *

Conseil : lorsque vous êtes certain que vous vous connectez à un export NFS, utilisez la syntaxe UNIX serveur:/partage pour une configuration plus rapide de la connexion.

Server for NFS

Windows Services for UNIX offre un outil Server for NFS robuste offrant les ressources de disque de vos systèmes Windows 2000, Windows XP et Windows Server 2003 à n'importe quel ordinateur du réseau prenant en charge NFS. Pour administrer Server for NFS, utilisez la console MMC Windows Services for UNIX, ou utilisez nfsadmin à partir de la ligne de commande.

À partir de la console MMC Windows Services for UNIX, vous pouvez configurer les options suivantes :

Tableau 3. Options de la console

Option Description

Journalisation

Définit la taille et l’emplacement du fichier de journalisation, ainsi que les opérations à auditer.

Verrouillage

Définit la période de grâce pour les verrous, ainsi qu’une liste de verrous actuels.

Groupes de clients

Regroupe les ordinateurs clients afin de faciliter la définition des permissions.

Paramètres serveur

Affecte les performances, l’authentification et la gestion des noms de fichiers.

Partages

Vous créez les partages via l’Explorateur Windows en sélectionnant l’onglet Partage NFS dans la page Propriétés. Vous pouvez partager des dossiers individuels ou des lecteurs entiers. Pour partager un dossier à partir de l’invite de commande, tapez :

nfsshare sharename=lecteur:chemin

lecteur:chemin est l’emplacement du dossier que vous souhaitez partager. Comme dans UNIX, vous ne pouvez pas partager un sous-dossier d’un partage existant. Pour cette raison, chaque lettre d’unité est traitée comme un répertoire racine distinct. La syntaxe de ligne de commande complète est disponible en tapant ce qui suit sur la ligne de commande :

nfsshare /?

Permissions de partage

Les permissions de partage sont définies par ordinateur client ou par groupe d’ordinateurs. Pour définir les permissions des partages, ouvrez la boîte de dialogue des propriétés du dossier que vous partagez, sélectionnez l'onglet Partage NFS, puis cliquez sur le bouton Permissions. La valeur par défaut est l’accès en lecture seule pour tous les ordinateurs sans accès racine et sans accès anonyme.

Permissions de fichiers

Server for NFS utilise les droits d’accès Windows des listes de contrôle d’accès discrétionnaires (DACL, Discretionary Access Control Lists) pour simuler les permissions typiques dans les environnements UNIX et NFS. Les permissions par défaut sont lecture/écriture pour tous les utilisateurs.

Attention : Il est important de comprendre qu’il existe des ensembles de permissions différents dans les modèles de sécurité UNIX et Windows et que dans certains cas, l’alignement est purement une approximation.

Gateway for NFS

Gateway for NFS peut être installé sur les produits serveur uniquement, c'est-à-dire Windows 2000 Server et Windows Server 2003. Après l’installation, vous pouvez utiliser l’application Partage Gateway for NFS (Gwconfig.exe) pour créer des partages de passerelle. Un partage de passerelle prend une ressource de système de fichiers NFS d’un ordinateur UNIX ou d’un autre serveur NFS et met en correspondance ce système de fichiers NFS avec une lettre d’unité sur un serveur Gateway. La lettre d’unité est ensuite partagée avec les clients Windows partout sur un réseau, via les protocoles SMB (Server Message Block) standard. Les ordinateurs Windows clients n’ont pas besoin de logiciels supplémentaires et voient les partages de passerelles comme s’ils résidaient localement sur le serveur de passerelle.

Démarrez l’application Partages Gateway for NFS à partir du groupe de programmes Windows Services for UNIX ou via la ligne de commande. À partir de là, vous pouvez créer un partage de passerelle qui sera disponible pour tous les clients Windows comme s’il s’agissait d’un partage local de l’ordinateur de passerelle. Chaque partage de passerelle utilise une lettre d’unité de l’ordinateur de passerelle, ce qui a pour effet de limiter le nombre de partages au nombre maximum de lettres d’unité disponibles sur l’ordinateur de passerelle.

À partir de la ligne de commande, les partages Gateway for NFS sont gérés par l'intermédiaire de l’utilitaire Gwshare.exe. Pour plus d’informations sur l’utilisation de cet utilitaire, consultez l’aide de Windows ou tapez :

gwshare /?

Conseil : les partages Gateway for NFS sont limités par le nombre de lettres d’unité disponibles sur un serveur Gateway. Cependant, si vous avez besoin de partages supplémentaires au-delà de ce nombre, vous pouvez (et devez) utiliser plusieurs serveurs Gateway pour fournir les partages supplémentaires afin de répartir la charge.

Server for PCNFS

Server for PCNFS offre la prise en charge PCNFSD. Vous pouvez entrer les informations nécessaires afin de créer des utilisateurs et des groupes en utilisant la console MMC Windows Services for UNIX qui permet à Server for PCNFS de gérer l’authentification des ressources de fichiers NFS pour tous les clients NFS.

Remarque : Windows Services for UNIX n’utilise pas PCNFS pour l’authentification et l’utilisation de Server for PCNFS est destinée exclusivement à la prise en charge d’autres clients PCNFS qui nécessitent un serveur PCNFS.

Simplification de l’administration réseau

Windows Services for UNIX offre des outils Windows importants afin d’améliorer et de simplifier l’administration de votre réseau. Ces outils sont les suivants :

Client Telnet. Cet outil permet l’accès distant et l’administration basés sur les caractères et les scripts, via différentes plates-formes.

Serveur Telnet. Cet outil permet l’administration à distance de Windows basée sur les caractères et les scripts, à partir de différents clients.

Composant logiciel enfichable MMC. Ce composant logiciel enfichable crée un point de gestion cohérent et central pour toutes les fonctionnalités Windows Services for UNIX.

ActivePerl. Cet outil permet aux scripts existants et nouveaux de tirer partir de l’interface WMI (Windows Management Interface) pour automatiser les tâches d’administration réseau.

Client Telnet

Windows Services for UNIX offre un client Telnet en mode caractère qui va au-delà de celui inclus dans Windows 2000 afin de prendre en charge le mode flux et le mode console. Il offre également la journalisation ainsi que des paramètres (voir la commande set du tableau suivant) et commandes (voir la commande send du tableau suivant) de configuration supplémentaires qui le rendent plus robuste dans un environnement mixte.

La configuration Telnet est gérée à partir d’une session Telnet par échappement vers l’invite Telnet. Appuyez sur CTRL + ] (crochet droit) afin d’afficher l’invite Telnet lorsque vous avez démarré une session Telnet. À partir de la, vous pouvez taper ce qui suit.

Tableau 4. Commandes Telnet

Clé Fonction

?

Pour obtenir de l’aide

close

pour fermer la connexion en cours

display

Pour afficher les paramètres d’exploitation actuels

open <nom_ordinateur>

Pour ouvrir une connexion à un ordinateur (vous pouvez également utiliser une adresse IP)

send

Pour envoyer des chaînes au serveur Telnet. Les chaînes sont envoyées telles quelles, à l’exception des chaînes spéciales suivantes :

ao    Envoyer la commande Telnet Abort Output au serveur

ayt    Envoyer la commande Telnet Are You There au serveur

brk    Envoyer la commande Telnet brk au serveur

esc    Envoyer le caractère d’échappement Telnet au serveur

ip    Envoyer la commande Telnet Interrupt Process au serveur

synch    Envoyer la commande Telnet synch au serveur

status

Pour envoyer les informations d’état élémentaires sur la session en cours

quit

Pour quitter totalement le client Telnet

set

Pour définir un paramètre d’exploitation. Accepte les paramètres suivants :

?    Obtenir de l’aide sur d’autres options set

bsasdel    Configurer la touche Retour arrière afin qu’elle soit envoyée comme touche Suppr

delasbs     Configurer la touche Suppr afin qu’elle soit envoyée comme touche Retour arrière

crlf    Définir la touche Retour afin d’envoyer un retour chariot et un saut de ligne (0x0D,0x0A)

esc x    Utiliser x comme caractère d’échappement afin d’entrer l’invite de commande client Telnet (ctrl + ] par défaut)

localecho    Activer l’affichage local des caractères tapés

logging    Activer la journalisation

logfile nom_fichier    Définit le nom de fichier comme fichier journal actuel

mode x    Où x est console ou stream

ntlm    Activer l’authentification ANTLM

term <valeur>    Définir l’émulation de terminal demandée : ANSI, VT52, VT100, VTNT

unset

Pour annuler les options définies avec la commande set

Conseil : Si vous utilisez le client Telnet essentiellement pour vous connecter à des systèmes UNIX, définissez term sur ANSI et désactivez NTLM. Si vous vous connectez fréquemment à des systèmes Windows et UNIX, ou essentiellement à des systèmes Windows, l’émulation VTNT constitue le meilleur choix et vous pouvez utiliser ANSI lors de la connexion à un système ne prenant pas en charge VTNT.

Serveurs Telnet

Windows Services for UNIX inclut deux serveurs Telnet, à savoir le serveur Telnet par défaut, basé sur Windows et dont le fonctionnement est similaire à celui inclus avec toutes les versions de Windows depuis Windows 2000, et le démon Interix telnetd, contrôlé par inetd. Un seul de ces serveurs Telnet peut être activé à la fois. Par défaut, aucun serveur Telnet n’est activé, pour des raisons de sécurité.

Tel qu’il est installé, le serveur Telnet basé sur Windows fonctionne de manière optimale pour la plupart des installations. Il accepte les ouvertures de session à partir d’un large éventail de clients, y compris les clients Telnet fournis avec Windows 2000, Microsoft Windows NT® et Microsoft Windows 95/98, ainsi qu’un large éventail de clients terminal en mode caractère, de presque n'importe quel système d'exploitation. En outre, il peut être configuré pour satisfaire aux exigences de sites spécifiques afin d’améliorer la sécurité, de simplifier les ouvertures de session, de prendre en charge le mode stream ou console, etc.

Différences

Le serveur Telnet par défaut, basé sur Windows, doit être familier pour les utilisateurs de Windows 2000, Windows XP et Windows Server 2003. Il est pour l’essentiel identique au serveur inclus dans Windows XP Professionnel et Windows Server 2003 et est proche de celui inclus dans les versions Windows 2000. Il utilise le shell de commande Windows (Cmd.exe) comme shell par défaut. Ce serveur peut être démarré et arrêté à partir de la console MMC Services ou via la console MMC Administration Windows Services for UNIX (Sfumgmt.msc). Consultez les paramètres du serveur Telnet ci-dessous afin d’en savoir plus sur les paramètres et leur signification.

Le démon Telnet Interix, telnetd, est normalement exécuté sous le contrôle de inetd. Il utilise le shell Interix comme shell d’ouverture de session. Consultez la page du manuel telnetd pour plus d’informations sur toutes les options du démon Telnet Interix.

Activation d’Interix telnetd

Pour activer le serveur Telnet Interix, commencez par arrêter le serveur Telnet Windows en utilisant la console MMC Services for UNIX afin de le configurer pour un démarrage manuel ou de le désactiver. Ensuite, à partir d’un shell Windows Services for UNIX (tel que ksh), modifiez le fichier /etc/inetd.conf en utilisant un éditeur Windows Services for UNIX (tel que vi) afin de supprimer la marque de commentaire de la ligne suivante :

#telnet stream tcp nowait NULL /usr/sbin/in.telnetd in.telnetd –i

Ensuite, à partir du shell Korn Interix avec un compte doté de privilèges suffisants, exécutez la commande suivante :

$ kill -1 $(ps –ef | grep inetd | grep –v grep | tr –s " " \

| cut –f2 –d " ")

Pour ceux que les détails intéressent, ce script d’une ligne recherche l’ID du processus inetd, puis exécute la commande kill -1 (NOHUP) sur ce processus, ce qui entraîne la relecture du fichier de configuration par inetd.

Authentification

Le serveur Telnet Windows prend en charge Windows NT LAN Manager (NTLM) pour l’authentification des ouvertures de session clients Telnet Windows. L’utilisation de NTLM permet aux utilisateurs d’être authentifiés automatiquement auprès du serveur Telnet sur la base de leur ouverture de session Windows. Cette fonctionnalité rend l’utilisation de Telnet totalement transparente pour les utilisateurs, tout en garantissant que les mots de passe en texte clair ne transitent pas via un réseau. NTLM doit être pris en charge du côté client d’une ouverture de session, comme avec le client Telnet Windows.

Remarque : L’utilisation de NTLM uniquement dans un environnement mixte UNIX et Windows empêche les utilisateurs UNIX d’accéder aux serveurs Windows, car les utilisateurs UNIX ne possèdent pas de client prenant en charge l’authentification NTLM. Les serveurs Interix telnet et telnetd ne prennent pas en charge l’authentification NTLM.

Lors de l’utilisation de l’ouverture de session NTLM, les utilisateurs sont limités aux lecteurs locaux de l’ordinateur sur lequel ils ont ouvert une session. S’ils doivent mettre en correspondance des ressources réseau, ils peuvent le faire via une mise en correspondance explicite avec des informations d’identification complètes. Par exemple :

net use g: \\server\share /user:domain\username

Administration

Le serveur Telnet Windows est administré via le composant logiciel enfichable MMC Windows Services for UNIX ou le programme tnadmin. Pour voir les options pour tnadmin.exe, tapez :

tnadmin /?

Le tableau suivant affiche les options disponibles pouvant être définies.

Tableau 5. Options d’administration Telnet

•Option Description

Authentification

Les choix sont NTLM et Nom d’utilisateur/Mot de passe.

Audit

Définit la journalisation des événements sur un fichier journal distinct, ou sur le journal des événements, et définit les événements à consigner.

Paramètres serveur

Définissez les options suivantes :

Nombre maximum de connexions simultanées : il s’agit par défaut du nombre de connexions avec licence au serveur. Sous la version Professionnel, la valeur par défaut est 1.

Nombre maximal d'échecs d'ouvertures de sessions : la valeur par défaut est de 3.

Mettre en correspondance la touche Alt avec Ctrl + A : la valeur par défaut est Oui.

Port Telnet : la valeur par défaut est de 23.

Mode de fonctionnement : choisissez Console ou Flux. La valeur par défaut est Console.

Nom de domaine par défaut : tapez un nom de domaine ajouté automatiquement au nom de l’utilisateur d’ouverture de session. La valeur par défaut est « . », ce qui a pour effet de désactiver cette fonctionnalité.

Délai d’expiration de la session inactive : spécifie le délai jusqu’à la déconnexion forcée d’une session inactive.

Terminer tous les programmes lors de la déconnexion : bascule avec l’option suivante.

Continuer l’exécution des programmes démarrés avec la commande bgjob : permet aux travaux de poursuivre leur exécution après la fin de la session. La valeur par défaut est Non.

Sessions

Vous permet de voir les données sur les sessions actuellement actives (telles que utilisateur, domaine, ordinateur, date/heure d’ouverture de session) et d’envoyer un message à la session ou d’y mettre fin.

Le serveur Interix telnetd est basé sur le démon Telnet BSD (Berkeley Software Distribution). Pour plus d’informations sur les options de configuration, reportez-vous aux pages du manuel concernant telnetd.

Console MMC Services For UNIX

Windows Services for UNIX inclut une console MMC unique pour la gestion de tout à l’exception de Gateway for NFS. La console MMC offre une interface de gestion cohérente et facile à utiliser qui vous permet d’administrer tous les ordinateurs Windows Services for UNIX d’un réseau à partir de n'importe quelle console. Ensuite, étant donné que Windows Services for UNIX prend en charge WMI, la gestion peut être intégralement contrôlée par l'intermédiaire de scripts à partir de la ligne de commande.

ActiveState ActivePerl 5.8

Windows Services for UNIX inclut ActiveState ActivePerl 5.8 pour Windows, une version complète de Perl 5.8 et Perl Script qui fonctionne sous Windows 2000, Windows XP et Windows Server 2003. Parmi les nombreuses améliorations, ActivePerl 5.8 inclut la prise en charge complète de la commande fork(), ce qui améliore grandement la portabilité des scripts et des modules à partir de la distribution Perl générale. ActivePerl prend en outre totalement en charge Windows Scripting Host, ce qui en fait un excellent outil pour les tâches d’administration système.

Simplification de la gestion des comptes

Windows Services for UNIX offre des outils importants pour simplifier la gestion des comptes dans un réseau mixte Windows et UNIX. Ces outils sont les suivants :

Assistant Migration NIS. Cet assistant permet de déplacer des fichiers source NIS UNIX du domaine NIS vers Active Directory afin de consolider la gestion des comptes.

Server for NIS. Cet outil permet à un contrôleur de domaine Windows 2000 ou Windows Server 2003 de jouer le rôle de serveur principal pour NIS, en intégrant les domaines NIS aux domaines Windows et en permettant aux administrateurs de gérer les deux domaines avec Active Directory.

Synchronisation (bidirectionnelle) des mots de passe. Cette fonctionnalité permet de synchroniser les mots de passe des deux plates-formes, ce qui permet aux utilisateurs de gérer un mot de passe pour Windows et UNIX.

Mise en correspondance des noms d’utilisateur. Cette fonctionnalité associe les noms d’utilisateur Windows et UNIX, ce qui permet aux utilisateurs de se connecter aux ressources NFS sans avoir à se connecter séparément aux systèmes UNIX.

Assistant Migration NIS vers Active Directory

L’Assistant Migration NIS offre un outil simple à utiliser qui permet la migration d’un environnement NIS existant vers Server for NIS. Il prend les fichiers source NIS UNIX et les migre vers Active Directory.

Vous pouvez soit rendre les fichiers source disponibles pour le serveur Windows qui exécutera l’Assistant Migration NIS en utilisant NFS, soit les envoyer via ftp vers un répertoire local sur le serveur. Tous vos fichiers source doivent résider dans le même répertoire. Vous pouvez exécuter l’Assistant Migration plusieurs fois afin de migrer les fichiers par étape, ou exécuter toutes les migrations en une seule étape. Si vous migrez les fichiers par étapes, vous devez migrer le fichier passwd avant de tenter de migrer le groupe ou les fichiers instantanés qui en dépendent.

Server for NIS

Server for NIS permet à un contrôleur de domaine Windows 2000 ou Windows Server 2003 d’être un serveur maître NIS ou un serveur subordonné NIS (esclave) en intégrant NIS dans Active Directory. Si Server for NIS est utilisé comme serveur subordonné, le serveur maître doit être un contrôleur de domaine Windows 2000 Server ou Windows Server 2003. Un serveur maître Server for NIS peut prendre en charge à la fois les serveurs subordonnés NIS UNIX et Windows.

Synchronisation de mot de passe

L’outil de synchronisation de mot de passe inclus dans SFU 3.5 est un utilitaire de synchronisation bidirectionnel qui vous permet de synchroniser les changements de mot de passe entre Windows et UNIX. Les changements de mot de passe peuvent commencer dans Windows ou UNIX pour les systèmes d'exploitation suivants :

HP-UX 11i

Sun Solaris 7, Solaris 8

IBM AIX 5L 5.2

Red Hat Linux 8.0

Conseil : Si votre plate-forme UNIX n’est pas répertoriée dans cette liste, vous pouvez quand même utiliser la synchronisation de mot de passe bidirectionnelle par compilation sur votre plate-forme. Windows Services for UNIX inclut le code source et les fichiers make afin de faciliter la compilation.

La synchronisation de mot de passe bidirectionnelle utilise un démon de connexion unique (SSOD) qui s’exécute sur le serveur UNIX afin d’accepter les changements de mot de passe de Windows. Il utilise un PAM (Password Authentication Mapper), qui s’exécute également sur le serveur UNIX, afin de transmettre les changements de mot de passe UNIX à l’environnement Windows.

Notes de déploiement

Si vous prévoyez d’utiliser la fonctionnalité de synchronisation de mot de passe de Services for UNIX, tenez compte des informations suivantes :

Domaines Windows 2000 et Windows Server 2003. Lors de la synchronisation des domaines Windows 2000 et Windows Server 2003 avec les ordinateurs UNIX, le service de synchronisation de mot de passe doit être installé et en cours d’exécution sur tous les contrôleurs du domaine, ainsi que sur tous les ordinateurs UNIX sur lesquels les utilisateurs peuvent changer leur mot de passe. Si vous désinstallez le service à partir de l’un des contrôleurs de domaine, vous pouvez rencontrer des problèmes avec les autres serveurs.

Serveurs ou groupes de travail autonomes. Lors de l’utilisation du service Synchronisation de mot de passe pour synchroniser les mots de passe entre les ordinateurs Windows autonomes ou de groupe de travail et les ordinateurs UNIX, vous devez installer le service sur tous les ordinateurs Windows. Dans ce cas, le service de synchronisation de mot de passe synchronise uniquement les comptes locaux de chaque ordinateur Windows avec UNIX.

Pour synchroniser correctement les mots de passe entre les systèmes Windows et les systèmes UNIX, les noms des comptes utilisateur doivent être exactement les mêmes sur tous les ordinateurs Windows et UNIX qui utilisent le service. Soyez conscients que contrairement aux comptes Windows, les noms des comptes UNIX distinguent les majuscules des minuscules. En outre, tous les ordinateurs UNIX doivent être configurés correctement avec le SSOD fourni sur le CD Services for UNIX. Si vous souhaitez utiliser Synchronisation de mot de passe pour synchroniser un domaine Windows avec un domaine NIS, vous devez inclure les serveurs maîtres NIS dans la liste des ordinateurs pouvant recevoir des changements de mot de passe. Vous devrez également configurer votre démon sur le serveur UNIX en apportant les modifications appropriées à la configuration et aux fichiers make afin d’utiliser NIS.

Mise en correspondance des noms d’utilisateur

La fonctionnalité Mise en correspondance des noms d’utilisateur offre un mécanisme permettant de mettre en correspondance les noms différents pouvant exister entre les environnements UNIX et Windows. La mise en correspondance des noms d’utilisateurs est utilisée lorsque les noms sont les mêmes dans les deux environnements, mais sa force réelle consiste à vous permettre de mettre en correspondance les utilisateurs dont les noms ne sont pas les mêmes dans les deux environnements. Étant donné que les noms d’utilisateur UNIX distinguent les majuscules des minuscules, contrairement aux noms d’utilisateur Windows, cette fonctionnalité peut simplifier considérablement la gestion et la maintenance des comptes dans les deux environnements.

Un serveur de mise en correspondance de noms d’utilisateur est un service hautement disponible, qui prend en charge les clusters et un pool redondant de serveurs de mise en correspondance des noms d’utilisateur. Grâce à la mise en correspondance des noms d’utilisateur, vous pouvez créer des correspondances simples entre les comptes d’utilisateur Windows et les comptes UNIX correspondants, et utiliser la fonctionnalité de mise en correspondance avancée afin de mettre en correspondance les comptes présentant des noms différents. En outre, la mise en correspondance des noms d’utilisateurs prend en charge la correspondance un à plusieurs entre les comptes UNIX et Windows, ce qui vous permet de mettre en correspondance un compte UNIX unique avec plusieurs comptes Windows. Cela vous permet par exemple de mettre en correspondance plusieurs comptes administratifs Windows avec le compte UNIX racine.

La mise en correspondance des noms d’utilisateur utilise NIS pour authentifier les utilisateurs, ou des fichiers locaux mot de passe/groupe. Ces fichiers peuvent avoir leur origine dans l’environnement UNIX mais doivent résider localement, normalement dans le répertoire /etc (%SFUDIR%\etc). En outre, le serveur de mise en correspondance des noms d’utilisateur utilise désormais un fichier spécial appelé .maphosts, situé dans le répertoire /Mapper (%SFUDIR%\Mapper) afin d’implémenter la sécurité des hôtes sécurisés.

Utilisation de l’expertise UNIX

Grâce à une gestion réseau et une connectivité UNIX familières, ainsi qu’à l’intégration totale du sous-système Interix, des shells, des utilitaires et du kit SDK (étudié dans la section suivante), Windows Services for UNIX 3.5 permet aux entreprises d’utiliser leurs investissements dans l’expertise et les scripts UNIX lors de l’intégration de Windows dans leurs environnements.

Interix

Windows Services for UNIX 3.5 inclut la technologie de sous-système Interix, un environnement de script et d’application UNIX robuste et complet qui s’exécute en tant que sous-système natif sur le noyau Windows.

Un sous-système natif, pas une émulation

L’environnement d’exécution d’applications Interix, contrairement au Korn shell et aux utilitaires Windows des versions antérieures à SFU 3.0, est un sous-système entièrement intégré et un kit SDK qui s’exécute de manière native sous Windows 2000, Windows XP et Windows Server 2003. Interix offre une prise en charge complète de la compilation puis de l’exécution des applications UNIX dans Windows, ce qui permet aux entreprises d’utiliser et de migrer facilement leurs applications personnalisées existantes. Il offre également aux développeurs UNIX la prise en charge complète de plus de 2 000 API UNIX, ce qui permet aux scripts et aux applications écrits pour s’exécuter sous UNIX d’être transférés facilement et naturellement vers Windows.

Scripts

Windows Services for UNIX  3.5 inclut les environnements Korn Shell et C Shell, plus de 350 utilitaires UNIX, ainsi que Perl 5.6.1 compilé sous Interix. Cela confère aux développeurs et administrateurs UNIX l’environnement de script le plus large, le plus familier et le plus compatible possible. Les utilitaires sont awk, grep, sed, tr, cut, tar, cpio et beaucoup d’autres, tous fonctionnant conformément aux attentes de l’utilisateur, de l’administrateur ou du programmeur UNIX. Sont également inclus plus de 40 utilitaires et compilateurs GNU, tels que gawk, gcc, g++ et g77.

Système de fichiers à racine unique

Windows Services for UNIX 3.5 implémente un système de fichiers à racine unique dans l’environnement Interix, permettant aux utilitaires, scripts et applications de fonctionner comme prévu avec une racine unique pour tous les systèmes de fichiers. Cette possibilité simplifie de façon notoire les problèmes de portabilité, car les fichiers résident dans leur emplacement traditionnel. Les lettres d’unité individuelles sont accessibles via /dev/fs/C, /dev/fs/D, etc., tandis que les partages de fichiers réseau sont accessibles via /net/<NETNAME>/<nom_partage> (par exemple "/net/SERVER1/Users").

Shells

Le Korn Shell et le C Shell sont tous deux inclus dans Windows Services for UNIX, et tous deux se comportent comme dans un environnement UNIX. Contrairement au Korn shell des versions antérieures à SFU 3.0, ces shells utilisent un système de fichiers à racine unique. La nécessité de convertir les scripts pour prendre en charge la syntaxe de lettre d’unité a disparu, de même que les problèmes concernant la signification particulière du caractère deux-points (":"). Par exemple, dans les versions antérieures de SFU, le chemin entièrement qualifié du script « build.ksh » des utilisateurs dans leur répertoire bin personnel serait :

U:/bin/build.ksh

Dans Windows Services for UNIX 3.5, ce script se trouverait dans l’emplacement suivant :

/dev/fs/U/bin/build.ksh

Ou :

~/bin/build.ksh

Ajoutez un lien symbolique :

Dans –s /net/SERVER1/UserHome  /home

Et vous obtenez :

/home/$USERNAME/bin/build.ksh

Les scripts et programmes courants peuvent résider là où la plupart des utilisateurs UNIX et Linux s’attendent à les trouver. Par exemple, vim/gvim est installé dans le répertoire suivant :

/usr/local/bin/vim

/usr/local/bin/gvim -> /usr/local/bin/vim

Ce listing illustre une deuxième nouvelle fonctionnalité importante fournie dans le cadre du sous-système Interix ; les liens symboliques sont désormais totalement pris en charge dans les systèmes de fichiers NTFS, ainsi que dans NFS.

La prise en charge d’un système de fichiers à racine unique facilite le portage des scripts d’UNIX vers Windows pour deux raisons importantes. Non seulement les applications, programmes et fichiers système se trouvent là où les programmes et utilisateurs UNIX s’attendent à les trouver, mais le caractère deux-points conserve sa signification normale de séparateur de champ dans les variables PATH, etc.

Une autre différence importante est que les fichiers spéciaux qui contrôlent le comportement du shell portent les mêmes noms dans l’environnement Interix que dans UNIX. Cela facilite la maintenance d’un fichier « .profile » et « .kshrc » unique (ou .login et .environ pour les utilisateurs du C Shell) dans plusieurs environnements. Cela permet également aux utilisateurs d’utiliser Client for NIS ou Server for NFS afin d’offrir une structure de répertoires de départ partagée et unique dans les environnements Windows et UNIX.

Langages

Le sous-système Interix offre un environnement de script et de programmation familier et compatible, avec prise en charge de plusieurs langages et bibliothèques de script et de programmation, tels que Perl, C, fortran77 et C++. Il inclut la prise en charge des compilateurs GNU gcc, g77 et g++, ainsi que du compilateur Microsoft Visual C/C++ en tant que cc et c89.

Outils et utilitaires

Tous les outils et utilitaires UNIX standard font partie de SFU ; il n’est pas nécessaire d’acquérir de package tiers supplémentaire pour disposer des outils dont vous avez besoin pour votre travail. Tous les outils familiers sont disponibles et fonctionnent comme l’administrateur UNIX l’attend. Les utilitaires incluent des outils de traitement de texte familiers, tels que grep, less, awk, sed, pr, tr, etc., des outils de traitement par lot tels que at, cron et batch, des outils de contrôle de tâche, tels que ps, nice et kill, des utilitaires graphiques, tels que xterm, xrdb, xset et xclock, des outils de développement, tels que gcc, gdb, make, ainsi que des outils de connectivité, tels que bind, sendmail et ftp. Ils sont tous présents et fonctionnent comme prévu. Même la commande man est la même.

Programmation

Non seulement Windows Services for UNIX fournit un ensemble complet d’API, de compilateurs et d’utilitaires pour la création et la migration d’applications UNIX, notamment les applications basées sur XWindows(X11R6.6) et Curses, mais il fournit également un environnement complet d’exécution d’application qui se comporte comme les applications UNIX le prévoient. Aucune considération spéciale concernant les emplacements des fichiers ou la syntaxe n’est requise. Les liens symboliques sont également totalement pris en charge, offrant ainsi une flexibilité maximale de l’emplacement. Il est alors non seulement possible, mais également relativement simple, de convertir une application UNIX existante afin qu’elle fonctionne sur le sous-système Interix. Windows Services for UNIX 3.5 comporte plus d’une centaine de nouvelles API introduites récemment pour prendre en charge les applications pthread et les chaînes de caractères élargies.

Remarque : les applications UNIX doivent être recompilées pour s’exécuter sur Interix.

Différences avec les versions antérieures d’Interix

Interix a toujours présenté un aspect familier pour les utilisateurs UNIX, mais il était moins tolérant par rapport aux attentes des utilisateurs Windows natifs. Dans les versions plus récentes d’Interix, des améliorations ont été apportées afin d’offrir un environnement plus intégré à Windows. L’utilitaire ksh d’Interix utilise désormais la variable d’environnement PATH_WINDOWS qui recherche et trouve les programmes Windows dans des répertoires spécifiques sans qu’il soit nécessaire de spécifier la casse ou le suffixe exacts du nom des fichiers. Par exemple, la recherche sur « winword » trouve le programme WINWORD.exe si PATH et PATH_WINDOWS sont configurés correctement.

Pour des questions de sécurité, depuis la version Windows XP, le système Windows est configuré par défaut pour désactiver la distinction majuscules/minuscules dans tous les sous-systèmes d’environnement, notamment Interix. Cela signifie que Interix peut être installé avec la distinction majuscules/minuscules désactivée. La distinction majuscules/minuscules est requise dans un environnement UNIX réel. Lorsque vous installez Interix sur un système Windows XP ou Windows Server 2003, vous pouvez choisir de conserver la distinction majuscules/minuscules désactivée ou de l’activer explicitement.

Le sous-système Interix est également totalement compatible avec les systèmes de fichiers NFS et il utilise le serveur de mise en correspondance de nom d’utilisateur lors de la résolution des noms de comptes sur les systèmes de fichiers NFS.

Choix d’installation personnalisés

Windows Services for UNIX 3.5 utilise l’installeur Microsoft familier illustré dans la figure 1. Cet installeur prend en charge l’installation à la demande, la suppression de Windows Services for UNIX avec contrôle complet par script, ainsi que la maintenance. Lorsque vous choisissez une installation personnalisée, vous pouvez choisir les options qui sont installées.


SFU 3.5Figure 1. Installation de Windows Services for UNIX

Windows Services for UNIX offre un certain nombre de choix différents pour l’installation. Les choix que vous faites dépendent en grande partie du type de réseau hétérogène pris en charge. Bien que de nombreuses options et combinaisons d’installation soient possibles, les combinaisons élémentaires suivantes sont utiles dans différents scénarios. Les trois scénarios élémentaires et les combinaisons prises en charge sont les suivantes :

Essentiellement Windows avec certains serveurs et clients UNIX. Installez complètement Windows Services for UNIX. Gateway for NFS peut être installé sur un ordinateur serveur afin de prendre en charge les clients lorsque l’utilisation des ressources NFS sera relativement limitée. Pour les ordinateurs Windows qui ont besoin d’un accès substantiel aux partages NFS UNIX, Client for NFS doit être installé localement.

Environnement mixte UNIX et Windows existant. Installez NFS (Server et Client/Gateway en fonction des besoins) sur vos serveurs et clients Windows, ainsi qu’au moins un serveur de mise en correspondance de noms d’utilisateur afin d’offrir un accès complet aux ressources existantes du système de fichiers UNIX. Installez NIS sur vos contrôleurs de domaine si vous souhaitez consolider vos répertoires et disposer d’un point d’administration unique. Installez les utilitaires Interix (et les utilitaires GNU s’ils sont utilisés par votre personnel) afin de prendre en charge les scripts inter-plate-forme et de fournir aux utilisateurs et administrateurs UNIX un environnement de travail familier.

Environnement UNIX existant avec nouvel environnement Windows. Dans les environnements qui introduisent Windows pour la première fois, installez le produit Windows Services for UNIX complet. Cela vous permettra de simplifier la maintenance des comptes, d’utiliser votre expertise UNIX et de migrer les scripts et applications UNIX vers Windows.

L’installation doit inclure Interix et le kit SDK Interix pour les scripts inter-plate-forme et la migration des applications, ainsi que NFS pour le partage des ressources de fichiers inter-plate-forme et la synchronisation des mots de passe. Prenez soin de créer vos noms d’utilisateur Windows avec la casse correspondant à votre environnement UNIX.

Chacun de ces types d’installation installe la combinaison des options appropriées pour l’environnement qu’il est conçu pour prendre en charge. Dans tous ces scénarios, vous souhaiterez probablement installer Interix. Il offre un ensemble complet d’utilitaires et shells UNIX, ainsi qu’un environnement complet et robuste d’interopérabilité et de migration. Examinons les différents types d’installation et dans quels cas les utiliser.

Installation complète avec Server for NIS

Dans un environnement d’entreprise dans lequel il existe des ressources UNIX substantielles et un environnement de domaine NIS existant qui implémente également Windows 2000 Server ou Windows Server 2003 et Active Directory, il peut être utile d’installer le package Server for NIS complet sur le contrôleur de domaine. Avec l’Assistant Migration NIS, vous pouvez migrer vos domaines NIS existants vers Active Directory et offrir un Server for NIS maître, répliqué et totalement redondant dans le cadre d’Active Directory. N'importe quel contrôleur de domaine Windows peut être un Server for NIS. Il ne peut y avoir qu’un seul Server for NIS maître, mais les autres contrôleurs de domaine de votre domaine Windows peuvent être des serveurs subordonnés à un serveur maître NIS basé sur Active Directory.

Remarque : Un Server for NIS SFU ne peut pas être un serveur subordonné à un serveur maître NIS UNIX, mais seulement à un Server for NIS SFU maître.

NFS et la mise en correspondance des noms d’utilisateur

Dans les environnements dans lesquels il existe des ressources de système de fichiers NFS substantielles et des clients NFS UNIX qui n’exécutent pas NIS ou dans lesquels le serveur maître NIS réside sur UNIX, vous devez envisager l’installation de Server for NFS, Client for NFS ou Gateway for NFS, ainsi que de la mise en correspondance des noms d’utilisateur. Vous devez installer un seul service de mise en correspondance des noms d’utilisateur, mais vous pouvez en installer davantage si vous êtes sur un sous-réseau ou que vous disposez d’un grand nombre de clients NFS Windows et que vous souhaitez répartir la charge de manière appropriée.

Conseils Gateway for NFS

Vous pouvez installer Client for NFS ou Gateway for NFS sur un serveur Windows 2000 ou Windows Server 2003, mais pas les deux. Si votre utilisation de NFS est relativement élevée, vous constaterez peut-être que Gateway for NFS est un choix rentable. Il offre un moyen permettant aux clients Windows de se connecter aux ressources existantes du système de fichiers NFS sans avoir à charger un Client for NFS sur leur ordinateur. Cependant, n’oubliez pas qu’une utilisation intensive de NFS peut surcharger le serveur de passerelle, créant ainsi un goulet d'étranglement dans le système.

Conseils Client for NFS

Vous devez installer Client for NFS sur n'importe quel serveur ou ordinateur Windows XP Professionnel ou Windows 2000 Professionnel qui utilisera de manière intensive les ressources du système de fichiers NFS. Si vous avez au moins un serveur qui exécute Gateway for NFS, vous pouvez utiliser ce serveur pour rendre les ressources NFS disponibles pour les clients moins exigeants et les clients Windows 9x. Cependant, vous devez installer Client for NFS sur tous les ordinateurs qui nécessiteront une utilisation importante et régulière des fichiers stockés sur les serveurs NFS.

Conseils pour l’authentification Server for NFS

Si vous partagez des ressources de système de fichiers avec des clients UNIX qui utilisent Server for NFS, installez l’authentification Server for NFS sur tous les ordinateurs qui exécutent Server for NFS et sur tous les contrôleurs de domaine de tous les domaines dans lesquels des comptes utilisateur seront authentifiés pour l’accès aux partages NFS. La seule exception concerne les domaines Windows Server 2003 dans lesquels la forêt se trouve au niveau de fonctionnalité Windows Server 2003.

Conseils pour la mise en correspondance des noms d’utilisateur

Installez la mise en correspondance des noms d’utilisateur sur un ou plusieurs serveurs, de préférence un contrôleur de domaine. Cela vous permet de mettre en correspondance les noms d’utilisateur dans chaque environnement, d’une façon globalement transparente pour les utilisateurs. Si vous disposez d’un cluster disponible, le serveur de mise en correspondance des noms d’utilisateur peut y être installé, ce qui permet d’augmenter la disponibilité.

Synchronisation (bidirectionnelle) des mots de passe

Dans un environnement dans lequel se trouve un grand nombre d’utilisateurs Windows et UNIX, et où un nombre important de ces utilisateurs travaillent avec les deux systèmes d'exploitation, vous devez installer la synchronisation des mots de passe si vos systèmes UNIX se trouvent sur une plate-forme prise en charge.

Si vos systèmes UNIX n’exécutent pas l’une des plates-formes prises en charge, vous pouvez quand même exécuter la synchronisation des mots de passe en compilant les démons fournis (SSOD et PAM) pour votre plate-forme, à l’aide du fichier make fourni.

Conseil : la synchronisation des mots de passe ne prend pas en charge les noms différents, pas plus qu’elle n’utilise la mise en correspondance des noms d’utilisateur. Dans un environnement dans lequel vous souhaitez utiliser la synchronisation des mots de passe, vous devez faire l’effort d’aligner vos noms d’utilisateur (notamment la casse, puisque UNIX distingue les majuscules des minuscules) sur les deux plates-formes afin de faciliter la gestion centrale des mots de passe.

Scénarios d’utilisation

Administration centrale des mots de passe

L’une des sources de frustration les plus importantes pour les utilisateurs et administrateurs d’un environnement mixte UNIX et Windows est la gestion et la maintenance des différents comptes dans les deux domaines. Cela s’avère particulièrement vrai dans les environnements étendus dans lesquels la sécurité est importante et où des changements de mots de passe réguliers sont imposés. Windows Services for UNIX 3.5 offre les outils permettant de simplifier ce processus.

Il existe plusieurs moyens de gérer la maintenance centrale des mots de passe, en fonction de la façon dont votre environnement est configuré et de vos besoins spécifiques. Les trois mécanismes élémentaires sont les suivants :

Serveur maître NIS basé sur Active Directory.

Mise en correspondance des noms d’utilisateur.

Synchronisation (bidirectionnelle) des mots de passe.

Chacun de ces mécanismes aborde différemment le problème de l’administration centralisée des mots de passe, mais chacun a sa place et peut être complémentaire des autres.

Dans un environnement d’entreprise étendu comporte une base bien établie d’utilisateurs et d’administrateurs UNIX, il n’est pas toujours possible d’implémenter NIS dans le cadre d’Active Directory. Dans ces environnements, vous pouvez utiliser une combinaison de synchronisation des mots de passe et de mise en correspondance des noms d’utilisateur afin d’obtenir un résultat similaire. La mise en correspondance des noms d’utilisateur vous aidera à exploiter vos ressources UNIX existantes en permettant aux utilisateurs de se connecter aux systèmes de fichiers NFS même s’ils possèdent des noms de compte différents dans les deux environnements. La synchronisation des mots de passe fonctionnera avec les comptes qui portent le même nom dans les deux environnements pour préserver la synchronisation des mots de passe, que l’environnement UNIX utilise NIS ou /etc/passwd comme mécanisme d’authentification principal.

Dans les environnements qui adoptent Windows 2000 ou Windows Server 2003 et Active Directory, il existe une opportunité majeure de simplifier et de consolider la maintenance des comptes dans un emplacement unique, facile à gérer, à savoir Active Directory. Grâce à l’Assistant Migration NIS, vous pouvez migrer votre domaine NIS existant vers Active Directory, en convertissant votre serveur NIS maître en serveur NIS subordonné qui pointe vers le nouveau serveur NIS maître basé sur Active Directory. Lorsqu’il existe des comptes différents dans les deux environnements, le service de mise en correspondance des noms d’utilisateur offre un mécanisme simple pour mettre en correspondance les comptes entre les deux.

Conseil : Server for PCNFS offre la prise en charge complète de PCNFSD et de l’authentification utilisateur pour l’accès aux ressources de fichiers NFS à tous les clients NFS qui ne peuvent pas utiliser la mise en correspondance des noms d’utilisateur (tels que les clients SFU 1.0). Vous devez installer Server for PCNFS sur le même serveur que la mise en correspondance des noms d’utilisateur, pour des questions de simplicité et de facilité de maintenance.

Systèmes de fichiers communs

De nombreuses entreprises possèdent des ressources de stockage déjà utilisées dans l’environnement UNIX et le coût associé au déplacement de ces ressources vers Windows ou, pire encore, à leur réplication dans les deux environnements serait important. Windows Services for UNIX fournit le mécanisme permettant d’unifier les systèmes de fichiers entre les deux environnements, ce qui vous donne un système de fichiers commun unique dont les deux côtés peuvent tirer parti. Utilisez Server for NFS sur vos serveurs Windows afin de permettre un accès facile aux systèmes de fichiers Windows pour vos serveurs et clients UNIX, et utilisez une combinaison de Gateway for NFS et Client for NFS pour offrir un accès transparent aux ressources de stockage UNIX existantes à vos serveurs et clients Windows.

Une considération importante lors de l’implémentation de Client for NFS ou Gateway for NFS dans l’entreprise consiste à décider lequel est adapté à chaque situation. Gateway for NFS est approprié lorsque vous devez prendre en charge une utilisation occasionnelle et relativement limitée des ressources de stockage NFS pour les clients Windows de façon totalement transparente pour les utilisateurs. Elle n’est en revanche pas adaptée à une utilisation intensive ou fréquente si un utilisateur exécute des programmes à partir de Server for NFS ou stocke des fichiers de données ou documents volumineux sur le serveur. Dans ce cas, la version complète de Client for NFS est plus appropriée, évitant à Gateway for NFS de devenir un goulet d'étranglement. Dans la plupart des environnements, un mélange de Gateway for NFS et de Client for NFS constitue le meilleur choix et le choix le plus rentable. Vous devez utiliser la version complète de Client for NFS sur les ordinateurs dont les utilisateurs ont besoin de bande passante supplémentaire, et utiliser Gateway for NFS pour prendre en charge les utilisateurs occasionnels d’une façon offrant un système de fichiers communs transparent et facile à gérer entre les deux environnements.

Migration des applications et des scripts

La technologie du sous-système Interix dans Windows Services for UNIX 3.5 en fait un excellent moyen de migrer les applications et scripts UNIX vers la plate-forme Windows. Avec le kit SDK Interix complet, ainsi que le kit SDK et les compilateurs GNU largement pris en charge dans Windows Services for UNIX 3.5, les entreprises peuvent réorienter leurs applications UNIX afin qu’elles s’exécutent de façon native sous Windows.

Interix utilise un système de fichiers à racine unique, ce qui offre aux applications et scripts UNIX l’environnement attendu, avec des fichiers et structures de répertoires familiers, nécessitant peu ou pas de modifications du code source pour la compilation et l’exécution.

Résumé

Windows Services for UNIX 3.5 est un ensemble d’outils d’interopérabilité complet pour l’intégration des environnements Windows et UNIX. Windows Services for UNIX 3.5 inclut des composants d’interopérabilité de plate-forme, des composants de gestion communs et des composants de migration d’applications dans un même produit Microsoft totalement intégré et pris en charge. Il comprend également des outils offrant une valeur ajoutée tout en améliorant la gestion informatique dans l’entreprise. Windows Services for UNIX 3.5 offre une prise en charge robuste et inter-plate-forme des systèmes de fichiers, l’administration centralisée des utilisateurs, ainsi qu’un environnement d’exécution d’applications UNIX qui s’exécute sur le noyau Windows, ce qui permet aux applications et scripts UNIX de s’exécuter de manière native sur la plate-forme Windows côté à côte avec les applications Windows.

Liens connexes

Pour les informations les plus récentes sur Windows Services for UNIX, consultez le site Web Services for UNIX à l’adresse http://www.microsoft.com/windows/sfu.

Page Up Updated  14 février 2006 Hervé Chaudret
C.N.R.S.

 -   Home   -  News   -   Conseils   -  Sécurité   -  Mise à jour   -   Liens   -  Accès   -

C.N.R.S.