TP Instructeur Linux NT

ADC BODIN
PMS TURIER
PROJET INTERCONNEXION NT / LINUX
ETUDE DE L’EXISTANT...............................................................................................................................................3
ENVIRONNEMENT.................................................................................................................................................................3
NOC................................................................................................................................................................................3
SITOPS...........................................................................................................................................................................3
CHRONOS.....................................................................................................................................................................3
CONSTITUTION LOGIQUE ET PHYSIQUE.............................................................................................................5
CONSTITUTION DU RÉSEAU NT .............................................................................................................................................5
CONSTITUTION DU RÉSEAU LINUX..........................................................................................................................................6
PLAN D’ADRESSAGE.............................................................................................................................................................8
BILAN................................................................................................................................................................................8
PARTAGE DES RESSOURCES NT / LINUX............................................................................................................10

OUTILS SOMMAIRES...........................................................................................................................................................10
PARTAGE DES RÉPERTOIRES : NFS.......................................................................................................................................10
PARTAGE SAMBA........................................................................................................................................................11
PRÉSENTATION..................................................................................................................................................................11
MISE EN ŒUVRE................................................................................................................................................................12
INSTALLATION D’UN SERVEUR D’IMPRESSION..............................................................................................17
INSTALLATION SUR LE SERVEUR SAMBA............................................................................................................................17
INSTALLATION SUR LE SERVEUR NT.....................................................................................................................................17
DÉCLARATION DANS LE FICHIER SMB.CONF DE L’IMPRIMANTE DISTANTE.....................................................................................17
INSTALLATION DU SERVICE DNS SUR LE SERVEUR LINUX........................................................................17
LE DNS DU SERVEUR NT N’EST PAS STANDARD ; ON DÉCIDE DONC DE METTRE EN ŒUVRE LE DNS LINUX..................................17
RAPPEL SUR DNS STANDARD.............................................................................................................................................17
MISE EN ŒUVRE................................................................................................................................................................17
OUTILS D’ADMINISTRATION À DISTANCE........................................................................................................17
ADMINISTRATION DU DOMAINE NT......................................................................................................................................17
ADMINISTRATION DES STATIONS LINUX.................................................................................................................................17
INTERCONNEXION DES ORGANISMES................................................................................................................18
ANALYSE.........................................................................................................................................................................18
CONNEXIONS DES 3 RÉSEAUX..............................................................................................................................................21
CONSTITUTION LOGIQUE ET PHYSIQUE...................................................................................................................................22
BILAN..............................................................................................................................................................................23
ANNEXES........................................................................................................................................................................24
TELNET SOUS NT.............................................................................................................................................................24
TABLES DE ROUTAGE.........................................................................................................................................................25
FICHIERS SAMBA...........................................................................................................................................................26
COMMENTAIRES SUR LE FICHIER SMB.CONF............................................................................................................................32
ADMINISTRATION SAMBA DISTANTE.................................................................................................................................32
ADMINISTRATION STATION LINUX À DISTANCE.......................................................................................................................33
RÉSOLUTION DES NOMS PAR FICHIER LMHOSTS.................................................................................................................38
/opt/scribd/conversion/tmp/scratch2/23243453.doc 1
DNS NT HIÉRARCHIQUE...................................................................................................................................................38
DROITS EN INTER DOMAINES................................................................................................................................................42
FICHIER IFCFG-ETH0..........................................................................................................................................................44
FICHIER INETD.CONF..........................................................................................................................................................45
FICHIER ETC/SERVICES........................................................................................................................................................47
AUTRES PRODUITS DE PARTAGES NT / UNIX.........................................................................................................................53
MISE EN ŒUVRE VNC......................................................................................................................................................53
PROTOCOLE D’INSTALLATION DES STATIONS LINUX.................................................................................................................55
MISE EN ŒUVRE DE CUPS................................................................................................................................................56
LES IMPRIMANTES SOUS UNIX.............................................................................................................................................57
Le 12/06/2001
PROJET INTERCONNEXION NT / LINUX
Le but de ce projet est de concevoir un système d’information en milieu hétérogène. Nous

partirons d’une situation concrète proche de celle du SI TRIDENT (KFOR).
Etude de l’existant
Environnement
Le SI TRIDENT raccorde de nombreux bataillons français et étrangers ; il permet la mise à
disposition immédiate de toutes les informations vitales : compte-rendu, photos, vidéo,
visioconférence. Ces renseignements sont exploités par l’Etat-Major de la KFOR.
Le SI TRIDENT est composé de plusieurs services :

1. NOC (Networks Operating Center), administré par l’Armée de Terre
2. SITOPS, administré par l’Armée de l’Air et la Marine,
3. CHRONOS, administré par une équipe étrangère
NOC
Le Noc soutient environ 150 ordinateurs sur le théâtre.
Ces stations clients sont raccordées par de multiples supports : liaison cuivre, fibre optique,
liaison RITA, satellite par Syracuse, TFH 701 et 150 (faisceau Hertzien) ; les débits sont donc
très différents et vont de 9200 Bps (liaison RITA avec modem analogique) à 100 Mbits/s (FO).
Ces limites techniques conditionnent l’organisation des tâches administratives. (mise à jour anti-
virus, stratégies systèmes locales, station en Workgroup mais clients du serveur de messagerie
etc.)
Matériels utilisés : 1 PDC, 1 BDC, 1 workstation, 1 station Linux et 1 serveur WEB Apache ; ces
5 stations sont reliées au sein du réseau DOM-NOC
SITOPS
L’équipe SITOPS administre un parc d’environ 60 ordinateurs.
Peu de contraintes matérielles pour ce SI ; ce système est toutefois le seul à pouvoir établir des
communications inter théâtres en visioconférence.
Matériels utilisés : 1 PDC, 1 BDC, 1 Workstation, 1 station Linux et 1 serveur WEB Apache ; ces
5 stations sont reliées dans le réseau DOM-SITOPS
CHRONOS
L’équipe de CHRONOS doit maintenir des outils de messageries opérationnelles très
sensibles ; ce service est international ; les relèves sont donc assurées par les divers pays de la
KFOR.
Matériels utilisés : 1 PDC, 1 BDC, 1 workstation, 1 station Linux et 1 serveur WEB Apache ; ces
5 stations sont reliées au sein du réseau DOM-CHRONOS
Ces services sont donc complètement dissociés sur des réseaux différents ; ils ne peuvent pas
partager leurs travaux ni utiliser l’espace disque ou l’imprimante d’autres services.
Le COMSICIAT demande à l’administrateur système du théâtre de revoir l’organisation

physique et logique du système d’information ; le but est de permettre à tous les utilisateurs
d’utiliser les ressources distantes, de manière transparente tout en assurant la sécurité et une
administration souple.
Nous devons étudier pour chaque organisme :

- la constitution logique et physique,
- les services à déployer,
- la sécurité
NOC
C
S
H
I
R
T
O
O
N
P
O
S
S
Constitution logique et physique
Les 3 organismes du SI TRIDENT sont pour l’instant autonomes ; cette situation évoluera
sûrement pour permettre des échanges transparents d’un organisme à l’autre.
Note instructeur :
- nécessité de s’organiser, (qui fait quoi) dans le groupe et avec les autres groupes
(interconnexion future => pb @IP, routage etc.)
- les groupes doivent donc réfléchir : @IP, plan de nommage etc.
Constitution du réseau NT
Temps utile : 2h00
Mise en place des stations

- implantation et raccordement physique (identifier les stations par post-it) ; mise en place
d’un hub.
- installation du PDC avec les services :
o DNS : nom de domaine sera celui de l’organisme : .KSV (ex : noc.ksv)
Note instructeur : on notera qu’un nom de machine de type PDC_N est automatiquement
transformé en nom d’hôte pdc-c (dans applet Réseau/DNS) ; ceci pour compatibilité
avec les systèmes DNS Unix qui ne reconnaissent pas le caractère _.
o WEB : IIS standard sans Gopher
o FTP : ce service sera utilisé pour l’installation de Linux pour montrer sans prétention,
que l’on peut installer une station Linux à partir d’un serveur FTP sous NT.
- Installation du BDC : serveur de fichier ; l’arborescence sera la suivante :
Disque Répertoires
D : donnees
MSG
Msg1 Répertoire privé de msg1
Msg2 Répertoire privé de msg2
OPS
Ops1 Répertoire privé de ops1
Ops2 Répertoire privé de ops2
NEWS Répertoire de publication
INTERCO Répertoire d’échange pour les autres
organismes qui seront raccordés
L’accès aux répertoires sera contrôlé par les permissions en utilisant les objets courants
(utilisateur, groupe) ;
Note instructeur : on peut rappeler le principe de création d’un utilisateur et les notions de
groupes locaux (accord des permissions) et global (regroupement par fonction et permet
l’accord de permissions sur un répertoire d’un domaine A pour un groupe global d’un
domaine B que l’on aura inséré dans un groupe local du domaine A).
(utilisateur => groupe global => groupe local)
Chaque utilisateur accède à son répertoire privé par un lecteur logique sur la lettre P
- Installation de la Workstation dans le domaine
- Installation d’une imprimante réseau (raccordée au hub) : il faut la configurer par la

procédure suivante :
o Récupération de son @MAC : appuyer sur le bouton de la carte réseau de
l’imprimante jusqu’à édition du setup de l’imprimante.
o Attribution d’une adresse IP : l’imprimante est reliée à un hub auquel on relie
également une station NT ;
On utilise ensuite la commande arp pour affecter une @IP à l’imprimante :
 Arp –s @IP @MAC
 Attention à respecter la syntaxe de l’@MAC (ex : 00 :00 :40 :FX :48 :47)
Note instructeur : la station sur la quelle on lance la commande arp doit être
dans le même masque pur (ex :255.255.0.0) que l’imprimante pour pouvoir
modifier l’adresse IP de cette imprimante.
On doit ensuite modifier le masque de réseau de l’imprimante pour l’insérer dans

notre sous réseau (ex :255.255.240.0) ; on utilise Telnet (si l’imprimante le permet):
• telnet @IP : on accède aux options de configuration de l’imprimante.
- Mise en place de stratégies système : étape optionnelle ; les stratégies pourront être mises
en œuvre en fin de TP suivant le temps disponible en précisant :
o Stratégie par groupe d’utilisateur
o Stratégie installée en local en raison du faible débit de la majorité des liaisons,
o Action :
 Bannière d’ouverture de session,
 Pas de voisinage réseau (d’où nécessité du lecteur logique à
l’ouverture de session),
 Verrouillage de l’applet affichage dans le panneau de configuration,
On s’appuie en fait sur le document du CERSIAT qui est la référence pour l’Armée de
terre.
Constitution du réseau Linux

Temps utile : 2h00
Les installations Linux se feront en mode sécurité faible.
Note instructeur : si l’on choisit un mode sécurité élevé, de nombreuses actions sont
impossibles) ; on préfère donc présenter ce cours en ouvrant la sécurité ; chaque stagiaire pourra
sécuriser son système par la suite. (voir fichier HOSTS.DENY)
- installation du serveur Linux

o 3 partitions :
 / : 1,2 Go
 swap : 128 Mo
 /home : tout le reste
o service WEB non activé pour l’instant
o arborescence d’un disque
Disque Répertoires
/home
ops Répertoire des données opérationnelles
msg Répertoire de sauvegarde des messages
NEWS Répertoire de publication
- installation de la station Linux : pas de lecteur CD-ROM sur cette station !!!
Comment installer ?
- par NFS sur le serveur Linux : impossible car l’instructeur ne le veut pas !
- par FTP sur le serveur NT (ATTENTION : 52Mo de RAM nécessaire !):
o créer une disquette de boot Linux à partir du CD de Linux ; lancer le
programme \dosutils\rawwrite.exe ; on choisira l’image (network.img)
adéquate,
o lancer le service FTP sur le serveur NT
o créer un répertoire virtuel (ex : linux) qui pointe sur le lecteur CD du serveur
o insérer le CD d’installation de Linux sur le serveur NT
o insérer la disquette de boot sur la station Linux et la démarrer : suivre les
indications d’installations.
Note instructeur : cette procédure sensibilise à l’utilisation de système différent.
- Insertion des stations dans le DNS NT,

- Installation de l’imprimante réseau : nous pouvons utiliser la commande printtool ; on notera
le répertoire de spool /var/spool/lpd/lp.
Note instructeur : on peut également utiliser Cups qui permet de superviser les imprimantes sous
interface Web ; on notera la commande d’impression qui devient : lpr-cups.
Le package est cups-drivers-03.6-25mdk.i586.rpm (voir son utilisation en annexe)
Note instructeur : la mise en œuvre du réseau est parfois difficile sous Linux ; en cas de
problème, il faut vérifier que le proccess tourne par la commande lsmod 3c509 par exemple (ou
lsmod eepro100).
Si ce n’est pas le cas :
- vérifier le fichier etc/modules.conf et éventuellement ajouter un alias (ex alias eth0 3c509 pour
les cartes 3COM ou alias eth0 eepro100 pour les cartes des Compaq de la salle 118) ; le
fichier du module 3c509 se trouve sous /lib/modules/ »version-noyau »/net ; il est également
possible de détecter des conflits par la commande isapnp isapnp.conf.
- vérifier le contenu du fichier /etc/sysconfig/network-scripts/ifcfg-eth0 (voir en annexe) ; il doit
contenir tous les paramètres de la carte réseau : @IP, netmask, network, broadcast et onboot
(=YES). Lancer ensuite ifdown eth0 puis ifup eth0 ; le ping doit fonctionner. Pour automatiser
le démarrage du réseau, créer un fichier de nom /etc/rc.d/rc5.d/S99eepro100@ (avec les
droits adéquats chmod +x) qui contiendra la commande modprobe eepro100 par exemple (ou
modprobe 3c509)
- Pour les problèmes d’interface graphique, lancer /usr/x11r6/lib/x11/x86config
- Création des comptes Linux (exemple pour la 2ème station Linux rattachée au réseau
chronos:
- clx21, clx22, clx23 et clx24 dans le groupe clx
- création du groupe ops
On aura donc une file d’impression NT et une file Linux ; la mise en œuvre de l’imprimante réseau
nécessite d’en connaître l’adresse IP ; voir la commande ARP et la procédure de modification
éventuelle de l’adresse IP d’une imprimante réseau.
Plan d’adressage
Il faut ici établir un plan d’adressage et de nommage des stations (et même plus tôt ! ! !)
Note instructeur : on n’utilise pas de caractère souligne (_) dans le nom des stations : ce
caractère pose en effet des problèmes dans le DNS Linux. Sous NT, un nom de machine du
type pdc_noc sera automatiquement transformé en pdc-noc ; ceci entraîne donc un nom
NETBIOS différent du nom d’hôte (nom utilisé par le DNS) de la station : A PROSCRIRE =>
risque de confusion !
ATTENTION : prise en compte d’éventuelle réorganisation ! ! !
Nous opterons pour le plan suivant sachant que les stations sont déjà reliées à des hub en 3
réseaux distincts dont les adresses sont figées comme suit :
Nom du réseau Station Services @IP Masque Observations

DOM-NOC PDC-N DNS 160.192.51.101 255.255.240.0 NT 4.0
WEB IIS
FTP
BDC-N CSD 160.192.51.102 255.255.240.0 NT 4.0
WKS1-N Workstation 160.192.51.103 255.255.240.0 NT 4.0
LX1-N Serveur WEB 160.192.51.104 255.255.240.0 Mandrake 7.2
LX2-N Station 160.192.51.105 255.255.240.0 Mandrake 7.2
IMP-NOC 160.192.51.200 255.255.240.0
DOM-SITOPS PDC-S DNS 160.193.51.106 255.255.240.0 NT 4.0
WEB IIS
FTP
BDC-S CSD 160.193.51.107 255.255.240.0 NT 4.0
WKS1-S Workstation 160.193.51.108 255.255.240.0 NT 4.0
LX1-S Serveur WEB 160.193.51.109 255.255.240.0 Mandrake 7.2
LX2-S Station 160.193.51.110 255.255.240.0 Mandrake 7.2
IMP-SITOPS 160.193.51.200 255.255.240.0
DOM-CHRONOS PDC-C DNS 160.194.51.111 255.255.240.0 NT 4.0
WEB IIS
FTP
BDC-C CSD 160.194.51.112 255.255.240.0 NT 4.0
WKS1-C Workstation 160.194.51.113 255.255.240.0 NT 4.0
LX1-C Serveur WEB 160.194.51.114 255.255.240.0 Mandrake 7.2
LX2-C Station 160.194.51.115 255.255.240.0 Mandrake 7.2
IMP-SITOPS 160.194.51.200 255.255.240.0
Note instructeur :
Ce plan d’adressage ne permettra pas l’interconnexion puisque les stations appartiennent
historiquement à des réseaux physiques différents ; nous sommes ici sur des réseaux de
classes C (160.192 à 194) ; voir notions classes d’adresses, identificateur de réseau et d’hôte.
Ceci sera vu en fin de TP lors de l’interconnexion des 3 organismes
Bilan
Temps utile : 0h20
- l’ensemble NT fonctionne pour chaque utilisateur :
o accès aux ressources communes et privées,
o impression correcte
o test du DNS par ping
Conclusion : pas d’échange direct entre les stations NT et Linux.
Partage des ressources NT / LINUX
Temps utile 1h00
Outils sommaires
- LINUX => NT
o Ftp
o Telnet : pas de serveur Telnet NT ; il existe des produits tiers (voir en annexe)
o http : accès au serveur WEB NT : http :\\PDC-n.noc.ksv (on vérifie ainsi le DNS)
o la commande rcp (remote copy)
- NT => LINUX
o Ftp : on pourra tester un FTP par l’explorateur
o Telnet
o Hyperterminal : avec un modem ; supporte 4 protocoles de transfert de fichiers
(XMODEM, YMODEM, ZMODEM, KERMIT) ; le serveur Unix doit supporter un
des ces protocoles.
Partage des répertoires : NFS

NFS se définit habituellement par machine et non utilisateur comme c’est le cas pour NT.
Le partage s'effectue en 2 étapes :

- configuration du serveur NFS : il exporte
la configuration du serveur peut se faire par linuxconf/tâches serveur/système de
fichier/exporte
on vérifie que le démon nfsd tourne (ps fax) et la liste des ressources exportées (exportfs)
Pour installer le package : ls grep nfs
- configuration des clients NFS : ils importent

la configuration du client peut se faire par linuxconf/système de fichier/accéder au volume
NFS ; il faut y ajouter :
- Server : "nom_du_serveur" (ici LX1_X)
- Volume : "/nom_du_volume"
- Point de montage : /mnt/essai
En cas de problème, il faut installer le package knfsd-clients-1.2.2.rpm ; la commande est
alors : rpm –ivh nom_package (i = install, v= verbose, h= historique)
La suite TCP/IP de Microsoft offre des possibilités limitées en matière de transfert de fichiers en
milieu hétérogène : FTP, Telnet ou Hyperterminal qui permet de transférer des fichiers depuis et
vers Unix (supporte les protocoles xmodem, ymodem, zmodem et kermit qui doivent bien sûr être
actif sur le système Unix).
Ces solutions sont lentes et ne fonctionnent pas dans les environnements ou plusieurs utilisateurs
partagent un fichier. De plus, Telnet ne peut transférer que des fichiers ASCII et non des fichiers
binaires.
C'est pourquoi des produits NFS offrent une passerelle entre PC et ressources NFS ; ceci évite
d'installer des logiciels sur chaque machine NT : c'est le cas de SAMBA. A la différence de
VisionFS de SCO, il est gratuit.
Conclusion : ces modes ne permettent pas un échange convivial ; nous allons donc mettre en
œuvre l’outil SAMBA.
Partage SAMBA
Temps utile :4h00
Présentation
Samba offre la possibilité aux utilisateurs NT d’employer les services de partage de fichiers et
d’impression d’une station Linux. Samba exploite le protocole SMB (Server Message Block)
Protocole SMB
SMB est une variante du protocole LAN MANAGER TCP/IP développé par IBM. SMB se base
sur le principe client/serveur par requêtes SMB grâce à la couche NetBios implémentée au-
dessus de TCP/IP.
Pour avoir accès au serveur Samba, TCP/IP et NetBios doivent être installés sur les stations
NT (ou Windows 9.x).
Pour qu’un poste Windows 3.11 devienne client SMB, il faut installer le patch TCP32B.EXE.
Les démons
- smbd (/usr/local/samba/bin/smbd) : serveur SMB ; il reçoit les connexions des clients
Windows LanManager et fournit les services de partage de fichiers et d’impression.
- nmbd (/usr/local/samba/bin/nmbd) : serveur de nom NetBios qui permet d’associer un nom

à une @ IP ; il peut en principe jouer le rôle d’un serveur Wins (/etc/hosts doit être
configuré et la ligne Wins support = Yes doit être présente dans le smb.conf.) Sinon, il faut
installer un serveur DNS ou configurer les fichiers LMHOSTS de chaque poste.
- Commande : /etc/rc.d/init.d/smb start et stop ou smbd restart.
Les fichiers de configuration

Mode d’accès :
- éditeur classique : spartiate mais la meilleure solution car on voit exactement ce qui se
passe. (option fortement recommandée)
- SWAT : convivial (il s’exécute à partir d’une station quelconque du réseau en tapant
@IP :901 du serveur Samba sous réserve d’avoir configuré le serveur) mais recrée un
smb.conf personnel ; pas de maîtrise de ce qui se fait ; son avantage réside dans
l'ergonomie.
ATTENTION : pour activer SWAT, il faut décommenter la dernière ligne du fichier
/etc/inetd.conf
#swat stream tcp nowait.400 root /usr/sbin/swat swat
- Test de la syntaxe de smb.conf par la commande Testparm
Mise en œuvre
Les répertoires NT vu de clients Linux

L'accès aux ressources NT depuis Linux/Samba est assez simple ; 2 modes sont possibles :
Smbclient : interface de type Ftp

Smbclient //svr-NT/dossier_de_partage_linux – I adrresse_ip_de_svr-NT – U
utilisateur_de_svr_NT%mot_de_passe
Smbmount : permet de monter une ressource NT sur le serveur Samba

Smbmount // svr-NT/dossier_de_partage_linux – I adrresse_ip_de_svr-NT – U
utilisateur_de_svr_NT%mot_de_passe –c 'mount point_de_montage'
La ressource se comporte comme une ressource locale.
A partir de la version Mandrake 7.1, les commandes différent : on utilise mount et umount
Exemple de la commande de montage :

Mount –t smbfs –o username=clx21, password=toto //@ip/nom_partage /point_montage
Mount –t smbfs –o username=clx21, password=toto //nom_machine/nom_partage
/point_montage
(ex : Mount –t smbfs –o username=clx21, password=toto //svrnt/partage /mnt/disk)
Exemple de la commande de démontage :

Umount –t smbfs /mnt/test
Note instructeur : lorsque le DNS hiérarchique NT sera en place, on pourra indiquer le nom
DNS du serveur qui partage ses fichiers.
Exemple : mount –t smbfs –o username=administrateur, password=
//pdc_n.noc.trident.ksv/interco /mnt/windows
(on vérifiera les droits sur le point de montage /mnt/windows)
Les répertoires Linux vu de clients NT
La configuration de Samba se situe à plusieurs niveaux :
Il faut configurer 3 fichiers :

- smbpasswd
- smbusers
- smbconf
Suivant les versions, on utilisera la commande smbaddusers (Mandrake 7.1), qui automatise la
mise à jour de 2 fichiers (smbpasswd et smbusers), ou les 3 fichiers dans l’ordre indiqué.
- la version Mandrake 7.1 intègre l’outil smbaddusers qui effectue la création des users
Samba, l’association à un mot de passe et le mappage avec les users Linux. L’appel de la
commande indique la procédure.
Dans notre TP, on veut permettre aux utilisateurs NT de se connecter aux ressources
Linux via Samba avec leur login NT sur un répertoire personnel (/home) et sur un
répertoire commun OPS pour les utilisateurs NT ops1 et ops2.
On va donc ajouter les utilisateurs Samba comme suit :
o smbaddusers login_linux :login_nt
o exemple : smbaddusers clx21 :msg1
 L’utilisateur Linux clx21 est mappé avec l’utilisateur NT msg1,
 Le fichier smbpasswd est créé et contient l’utilisateur Samba clx21.
On doit obtenir le fichier smbusers joint en annexe ?
 ATTENTION : dans ce cas, décommenter la ligne suivante dans le
fichier smb.conf :
# Unix users can map to different SMB User names
username map = /etc/smbusers
Si cette ligne n’est pas décommentée, les clients NT accèdent aux répertoires
Samba en tapant un login et son mot de passe reconnu sur les stations Linux
(exemple clx21) ; cette procédure implique alors pour l’utilisateur de mémoriser
2 comptes (NT et Linux).
Pour l’accès au répertoire OPS, on va simplement indiquer pour le groupe Linux OPS, qu’il
contient les utilisateurs ops1 et ops2 (login NT) que l’on aura mappés avec les comptes
clx23 et cl24 dans le fichier smbusers. On saisira directement le mappage avec un éditeur
de texte classique (type kwrite).
Note instructeur : ce fichier est, comme tous les fichiers de configuration Linux, lu
séquentiellement. Il faut donc respecter l’ordre de mappage indiqué dans le fichier
smbusers joint en annexe :
o le mappage clx23 :ops1
o le mappage clx24 :ops2
o le mappage ops : ops1 ops2
Ops1 et ops2 sont les logins des utilisateurs du domaine NT.
On veut également permettre à l’administrateur NT de contrôler le serveur Samba au

travers du gestionnaire de serveur du PDC ; il faut lui donner les droits.
On utilisera la commande suivante :
 Smbdaddusers nom_administrateur_linux:nom_administrateur_nt
 Exemple : smbdaddusers root:administrateur
Note instructeur : cette procédure pourra être appliquée uniquement au moment ou l’on
demande de produire une copie d’écran présentant les répertoires partagés d'un serveur
Samba avec le gestionnaire de serveur.
En effet, sans l’ajout de ce mappage, l’administrateur NT aura un message d’accès refusé
lorsqu’il va cliquer sur le Serveur Samba dans le gestionnaire de serveur.
Les 3 fichiers seront instanciés comme suit (ils peuvent créer manuellement) :
- /etc/smbpasswd : fichier des utilisateurs SAMBA
- création des utilisateurs Samba : commande smbpasswd –a
Nous créerons les mêmes utilisateurs que sous Linux clx21, clx22, clx23 et clx24 ; la
commande est la suivante : smbpasswd –a "nom_utilisateur" "mot_de_passe"
- /etc/smbusers : fichier des utilisateurs : mappage des utilisateurs Linux <=> Samba
<=NT.
La correspondance entre les comptes Linux et NT au travers de Samba est assurée
dans le fichier smbusers sous condition de décommenter la ligne adéquate dans le
fichier smb.conf.; il suffit de l'éditer et d'insérer les mappages voulus. (voir en annexe)
- smb.conf : intégration du serveur Samba dans le domaine NT.
Ce fichier peut être configuré de plusieurs manières (voir en annexe) ; on préféra utiliser
un éditeur classique (Kedit) ; voir en annexe les lignes importantes.
Nota : dans le fichier smb.conf, les entrées de partage [nom_de_partage] sont limitées
à 8 caractères. (conforme à LANMANAGER)
La configuration de ce fichier peut donc être manuelle, s’appuyant sur le fichier exemple
smb.conf, ou assisté par l’utilitaire SWAT.
Note instructeur : l’utilitaire SWAT génère un fichier smb.conf sommaire (au moins dans
la version testée Mandrake 7.1) ; on perd donc toutes les informations très instructives du
fichier smb.conf d’origine. A utiliser donc avec précaution.
On remarque 2 sections :
 Section GLOBAL : attention au paramètre os level = 33 ; il conditionne l’élection du

Maître Explorateur ; si un serveur Samba est Maître Explorateur, il perturbe fortement
le domaine NT.
On notera les lignes en gras importantes.
La ligne username map = /etc/smbusers est décommentée ; en effet, les noms
d’utilisateurs Samba sont différents de ceux de Linux ; nous avons ici voulu que le nom
d’utilisateur Samba soit le même que celui de l’utilisateur NT : il n’y a donc pas à
ressaisir un nom et un mot de passe pour que chaque utilisateur accède aux partages
Samba.
 Section SHARE : partage des ressources pour les clients NT.

Cette section est dans notre exemple utilisée pour :
o le partage d’un répertoire personnel pour chaque client Samba
o le partage d’un répertoire OPS pour les membres du groupe Linux OPS c’est
à dire clx23 et clx24 dont les login sont mappés avec les login NT ops1 et ops2.
o On remarquera la syntaxe pour l’autorisation d’accès à un groupe
- démarrage du serveur : /etc/rc.d/init.d/smb start ; on pourra vérifier les démons par un ps –ef
smbd ou nmbd.
Note instructeur :
Plus généralement, pour relancer un démon, on doit :
- connaître son numéro de processus(commande ps -ef)
- relancer le démon : commande kill -HUP processus
Lorsque tous les partages fonctionnent, il est demandé :

- édition des fichiers commentés de configuration de SAMBA :
o smbpasswd
o smbusers
o smbconf
- édition d’une copie d’écran de l’explorateur NT présentant les répertoires partagés du
serveur SAMBA (voir exemple ci-dessous)
- édition d’une copie d’écran du gestionnaire de serveur présentant :
o le serveur SAMBA : on notera qu’il est identifié comme un serveur NT version 4.2 !
o les partages accessibles sur le serveur SAMBA (si le fichier smbusers contient la
ligne root :nom_administrateur_NT)
Installation d’un serveur d’impression
L’imprimante réseau est HS : c’est une panne de l’interface réseau.
On va donc connecter cette imprimante en locale et la partagée pour les stations du groupe.
Installation sur le serveur SAMBA

Configuration du fichier smb.conf
Installation sur le serveur NT

Déclaration dans le fichier smb.conf de l’imprimante distante.
Installation du service DNS sur le serveur LINUX

Le DNS du serveur NT n’est pas standard ; on décide donc de mettre en œuvre le DNS Linux.
Rappel sur DNS standard
Mise en œuvre
Outils d’administration à distance

L’administration peut, et doit le plus souvent, être déportée sur une console. Les outils disponibles
en standard, sont les suivants :
Administration du domaine NT
- Installation des outils déportés sur la Workstation.
- Accès aux services et partages sur chacune des stations par le gestionnaire de serveur.
- VNC : prise de contrôle à distance ; il y a alors un serveur VNC et un client VNC
- DameWare
- Hyena
Administration des stations Linux

- A partir d’un navigateur sur une station NT : cette procédure est très confortable et permet
de configurer ou voir la majorité des renseignements nécessaires.
Procédure sur la station Linux
o Activer les accès réseau en précisant l’adresse IP d’une station ou un masque de
réseau autorisé.
Procédure sur la station NT quelconque (voir annexe)
o lancer un navigateur à l’adresse de la station Linux sur le port 98 (98 = port de
linuxconf)
- VNC (voir mise en œuvre en annexe)
Interconnexion des organismes
Nos 3 organismes sont maintenant obligés de communiquer ; ils utilisent déjà une messagerie
mais le volume de pièces jointes et volontairement limité : on préfère passer par les serveurs de
fichiers ; on utilisera le répertoire INTERCO qui a été crée sur chaque domaine NT.
Tous les utilisateurs doivent pouvoir accéder aux ressources des autres organismes (DOM_N
possède entre autre une table traçante).
Analyse
Problèmes d’accès aux objets : permissions, identification

Lorsque les réseaux sont dissociés, chaque serveur principal (PDC secondé dans notre cas par
un BDC) assurent la sécurité dans son domaine (DOM-NOC, DOM-SITOPS et DOM-
CHRONOS) ; les tâches d’administration sont donc assez lourdes : gestion des comptes, des
droits d’accès etc.
L’intégration des stations NT dans chacun de leur domaine ne permet pas immédiatement un
allégement et surtout une cohérence dans l’administration. Il faudra pour cela mettre en œuvre
les relations d'approbation.
La réunion physique, par les routeurs, des 3 réseaux NT, doit faciliter cette administration dans
la plus grande transparence pour les utilisateurs ; nous devons également prendre en compte
les stations Linux.
La gestion des accès aux ressources est cependant très différente dans les systèmes NT et
Linux.
Il y a en fait 3 problèmes à résoudre :
• Premier problème : savoir qui fait quoi ; quel utilisateur de quel domaine peut
accéder à quelles ressources ; à cette étape, un bon schéma vaut mieux……………. !
Donc voir schéma en annexe…
• Le second est lié à la différence de définition des accès à des ressources
particulières ; sous NT, on trouve les ACL tandis que sous Linux NFS est définit
(habituellement) par machine.
• Le troisième au fait que le système stocke et gère différemment les informations
sur les utilisateurs (ceci doit en principe être résolu sous Windows 2000 par Kerberos) ;
sous Linux, comme NT, on trouve les utilisateurs et les groupes mais les listes
d’utilisateurs sont stockées dans des fichiers textes ; il est aussi impossible d’insérer un
groupe dans un groupe sans NIS (Network Information Service)
Par les relations d’approbation, on peut :

- Centraliser la création des comptes utilisateurs et des groupes globaux sur le domaine
approuvé aussi appelé domaine de comptes
- Offrir l’accès à des ressources sur un domaine dit de ressources
Dans ce TP, on veut dans un premier temps que tous les utilisateurs des domaines DOM-SITOPS
et DOM-CHRONOS accèdent au répertoire INTERCO du domaine DOM-NOC
Relations d’approbation
Une relation d’approbation est établie entre 2 domaines ; elle n’est pas transitive. Elle offre des
avantages à l’administrateur mais pas à l’utilisateur ; cette relation peut être matérialisée par
une flèche qui pointe vers l’emplacement de la base de donnée des comptes centralisés du ou
des domaines approuvant (domaine qui approuve les comptes des domaines approuvés : il
contient donc la liste de ces domaines) vers le domaine approuvé.
On commence toujours par le domaine de compte : on indique le nom du domaine qui l’autorise
à approuver puis un mot de passe.
On va ensuite sur le domaine de ressource pour autoriser le domaine précédent avec le même
mot de passe.
La mise en œuvre des relations d’approbation sera facilitée par le schéma vu précédemment.
Note instructeur : la relation d’approbation nécessite la résolution du nom de domaine ; or

sans WINS, la résolution n’est pas possible ; donc la relation d’approbation va échouer par le
message « Contrôleur de domaine introuvable ».
La seule solution sera de forcer une résolution par le fichier LMHOSTS (copie en annexe)
Domaine approuvé
Le domaine approuvé est aussi appelé domaine de comptes car il centralise la gestion des
comptes ; création des comptes utilisateurs et groupes locaux.
L’administrateur du domaine approuvé peut administrer les comptes du domaine approuvant et

gérer les serveurs. Il est également possible d’installer une relation d’approbation
bidirectionnelle.
Domaine approuvant
Le domaine approuvant est également nommé domaine de ressource car ces ressources
peuvent être offertes aux utilisateurs de tous les autres domaines ; il suffit de :
- créer des groupes locaux sur le domaine approuvant,
- y placer des groupes globaux des domaines approuvés,
- accorder les permissions à ces groupes locaux sur les ressources désirées (disque,
imprimante etc.)
S’il existe un compte administrateur commun, même nom et même mot de passe sur un
domaine approuvant et sur le domaine approuvé, l’administrateur du domaine approuvant peut
administrer les comptes du domaine approuvé à partir de son domaine
L’utilisateur
L’utilisateur ouvre une session sur son compte dans son domaine ; si sa station est inscrite
dans un domaine approuvant, lors de l’ouverture de session, la liste des domaines affiche
son domaine d’appartenance (le domaine approuvant) et le domaine maître (approuvé) ;
La stratégie (POLEDIT) s’applique sur le domaine de d’ouverture de session.
Schéma
Domaine dit de ressources : Le domaine NOCapprouve les

offre le partage INTERCO comptes des 2 autres domaines
NOC
INTERCO
SITOPS CHRONOS
Domaines dit de comptes : accède au partage INTERCO
Pour établir la relation d’approbation, il faut appliquer la procédure suivante :

- sur le domaine de compte : indiquer le nom de « Domaine autorisé à approuver » avec un mot
de passe (ici le domaine DOM-NOC)
- sur le domaine de ressources : indiquer le nom de « Domaine approuvé» en indiquant le
même mot de passe (ici les domaines DOM-SITOPS et DOM-CHRONOS)
- La relation d’approbation échouera dans notre cas : le nom de domaine ne peut pas être
résolu : il faut mettre en œuvre la résolution par fichier lmhosts.
Rappel sur les différents modèles d’approbation
Modèle à domaine maître unique

Les relations d’approbations sont unidirectionnelles
- Gestion centralisée des comptes.
- Gestion décentralisée des ressources
- Regroupement logique des ressources
Modèle à domaines maîtres multiples

Les relations d’approbations sont bidirectionnelles
- Gestion centralisée des comptes.
- Gestion centralisée des ressources : à l’ouverture de session, l’administrateur se
connecte sur l’un des domaines (ex : dom1) avec le mot de passe administrateur de ce
domaine (ex : dom1) ; par la gestion des utilisateurs il accède à la SAM de ce domaine
(dom1) et peut l’administrer.
- Regroupement logique des ressources
Modèle d’approbation totale
Connexions des 3 réseaux
On pourra donc accorder des permissions aux membres de chaque domaine NT par les relations
d’approbation.
Il faut cependant qu’un lien physique existe entre nos 3 organismes.
Solutions envisagées pour interconnecter les stations :

Première proposition
- modifier le plan d’adressage pour insérer toutes les stations dans le même réseau ; ce
choix entraînera la modification des adresses IP, transfert des comptes sur le contrôleur
primaire désigné etc.(on pourra établir le bilan des actions à mener)
Réponse : les plages d’adresses ne peuvent être modifiées (attribution par la DCTEI) :
IMPOSSIBLE
Deuxième proposition :
- insérer des routeurs pour interconnecter les stations NT ; on pourra utiliser les fonctions de
routage intégrées à NT.
- mettre en place un système de résolutions des noms.
Réponse : ok
Autres propositions :
Constitution logique et physique
On va chaîner les réseaux NT en DOM-NOC, DOM-SITOPS et DOM-CHRONOS.
Ils seront physiquement reliés par les 2 stations WKS1-S et WKS1-C configurées comme routeur.
Le routage
Un routeur permet la connexion de réseaux dans des plages d’adresses différentes ; suivant la
classe d’adresses, il faudra s’assurer du fonctionnement théorique du routeur.(rappel sur le rôle
des identificateurs de réseau et d’hôte)
Sous NT, nous pouvons utiliser un routage statique, en ajoutant manuellement les routes sur
chacun des routeurs, ou dynamique en installant RIP sur les serveurs ; les tables de routage sont
mises alors mise à jour automatiquement mais le trafic augmente.
Nous choisirons le routage statique ; il faut définir une adresse IP pour la deuxième carte réseau
de chaque routeur.
- Pour la station WKS1-S : 160.192.51.106 (160.193.51.106 pour son réseau)
- Pour la station WKS1-C : 160.193.51.113 (160.194.51.113 pour son réseau)
Le routage doit être configuré :

- sur les routeurs :
• Installation d’une deuxième carte réseau et liaison au hub de l’autre réseau.
• Pour la station WKS1-C du réseau 160.194.0.0 :
• Raccord au hub du réseau SITOPS (160.193.0.0)
• @IP : 160.193.51.113 (@ conforme à celle du réseau SITOPS)
• elle doit atteindre le réseau en 160.192.0.0 par la passerelle 160.193.51.108
(station WKS1-S).
• Pour la station WKS1-S du réseau 160.193.0.0 :

• Raccord au hub du réseau NOC
• @IP : 160.192.51.106 (@ conforme à celle du réseau NOC)
• elle doit atteindre le réseau en 160.194.0.0 par la passerelle 160.193.51.113
(station WKS1-C).
• mise à jour de la table de routage : dans notre cas, chaque routeur doit
contenir l’@IP de la passerelle permettant l’accès au réseau contigu.
Pour ajouter une route, il faut lancer route.exe avec les arguments :
Route add –p 160.192.0.0 mask 255.255.0.0 160.193.51.106
-p = route persistante (enregistrée dans la base de registre à
HLM/System/CurrentControlSet/Services/TCPIP/Parameters/PersistantRoutes) ; si
ce paramètre est omis, le routage n’est pas assuré après le redémarrage de la
station routeur.
160.192.0.0 : @ du réseau de l’autre passerelle
255.255.0.0 : masque de réseau
160.193.51.106 : @IP de la passerelle.
- sur les stations : indiquer la passerelle par défaut (voir schéma)
Note instructeur : ce routage fonctionne mais n’est pas propre. Les stations du réseau
160.193.0.0 accèdent automatiquement au réseau 160.192.0.0 ; un routage possède un chemin
que l’on doit respecter surtout si, dans ce TP, un 4ème réseau devait être raccordé.
On devra donc modifier la passerelle des stations du réseau 160.193.0.0 en indiquant la
passerelle de début du chemin de routage c’est à dire la station WKS1_C en 160.193.51.113.
(voir documentation Microsoft Serveur : Complément sur la gestion des réseaux page 25 et 67 à
75)
Présentation des outils de diagnostic : ping, arp, ipconfig ou winipcfg, nbtstat, route print et tracert.
Le routage permet la communication par adresses IP uniquement ; les services FTP et Telnet
sont accessibles.
Pour améliorer l’ensemble, il est indispensable de résoudre les noms IP en nom NETBIOS des
stations ; sous NT, le plus simple serait de mettre en œuvre des serveurs WINS ?
Résolution des noms

WINS : ce service est strictement interdit en opération ; d’autre part, son intérêt est d’alimenter
le DNS et de fonctionner avec un serveur DHCP qui n’est alors plus standard.
Note instructeur : fichier LMHOSTS qui est un fichier de résolution utilisable uniquement en
milieu Microsoft.
On pourra alors créer un DNS hiérarchique dont la racine sera NOC.TRIDENT.KSV ; cette
structure est opérationnelle. (voir annexes) ; ce DNS sera cependant mis en œuvre sous NT
par manque de compétences sur le DNS hiérarchique Linux.
On peut utiliser un fichier LMHOSTS centralisé sur le serveur DNS ; la procédure sur chaque
station est de créer un fichier LMHOSTS (voir en annexe).
Bilan
Tous les utilisateurs doivent :
- accéder au répertoire \\INTERCO de chaque domaine à partir d’une station NT ou LINUX
Note instructeur : les utilisateurs des autres réseaux ne voient pas le réseau DOM-NOC
car il s’agit de réseau physique différent que l’explorateur ne connaît pas.
Pour accéder à cette ressource, on doit utiliser un script de connexion ou, pour ce tp, la
connexion par le menu Démarrer, Exécuter on indique ici le chemin UNC d'accès à la
ressource ; la station (ici bdc-n) qui partage sa ressource peut être identifiée par son
adresse IP ou son nom DNS.
Exemple : \\bdc_n.noc.trident.ksv\interco ou \\160.192.51.102\interco.
- imprimer sur toutes les imprimantes

- accéder à tous les serveurs web par le nom du serveur http.
-
Chaque groupe présentera :
- les copies d’écrans,
- une copie des tables de routage, (commande c:\route > route.txt)
- un dossier d’administration
Annexes
Telnet sous NT
Ataman Software, Inc.
749 S. Lemay, Suite A3-411
Fort Collins, CO 80524
Phone: (970) 225-9131
E-mail: info@ataman.com
E-mail: sales@ataman.com
E-mail: support@ataman.com
Anonymous FTP: rmii.com/pub2/ataman/products/atrls_cv.zip
Compuserve Forums: WUGNET, WINCOM, MSWIN32, WINSHARE
Hummingbird Communications Ltd.
1 Sparks Avenue, North York, Ontario
Canada, M2H 2W1
Phone: (416) 496-2200
BBS: (416) 496-9233
E-mail: sales@hummingbird.com
E-mail: support@hummingbird.com
Anonymous FTP: ftp.hummingbird.com
World Wide Web: http://www.hummingbird.com/realindex.html
Seattle Lab
9606 Northeast 180th Street
Bothell, Washington 98011
Phone:(425) 402-6003
BBS:(425) 402-6388
E-mail: info@seattlelab.com
E-mail: support@seattlelab.com
Anonymous FTP: ftp.accessone.com/pub/slab
World Wide Web: http://www.seattlelab.com/
The products discussed here are manufactured by vendors independent of Microsoft;
we make no warranty, implied or otherwise, regarding these products' performance
or reliability.
Tables de routage
Table de routage de la station routeur WKS1-S
===========================================================================
Liste d'Interfaces
0x1 ........................... MS TCP Loopback interface
0x2 ...00 60 08 30 86 90 ...... ELNK3 Ethernet Adapter.
0x3 ...00 08 c7 0a ca 62 ...... Compaq 10 or 10/100 PCI Intel Controller Driver
===========================================================================
Itinéraires actifsÿ:
Destination réseau Masque réseau Adr. passerelle Adr. interface Métrique
0.0.0.0 0.0.0.0 160.192.51.106 160.192.51.106 1
0.0.0.0 0.0.0.0 160.193.51.108 160.193.51.108 1
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
160.192.48.0 255.255.240.0 160.192.51.106 160.192.51.106 1
160.192.51.106 255.255.255.255 127.0.0.1 127.0.0.1 1
160.192.255.255 255.255.255.255 160.192.51.106 160.192.51.106 1
160.193.48.0 255.255.240.0 160.193.51.108 160.193.51.108 1
160.193.51.108 255.255.255.255 127.0.0.1 127.0.0.1 1
160.194.0.0 255.255.0.0 160.193.51.113 160.193.51.108 1
224.0.0.0 224.0.0.0 160.192.51.106 160.192.51.106 1
224.0.0.0 224.0.0.0 160.193.51.108 160.193.51.108 1
255.255.255.255 255.255.255.255 160.192.51.106 160.192.51.106 1
===========================================================================
Table de routage de la station routeur WKS1-C
===========================================================================
Liste d'Interfaces
0x1 ........................... MS TCP Loopback interface
0x2 ...00 60 08 2a 46 ef ...... ELNK3 Ethernet Adapter.
0x3 ...00 08 c7 0a d5 f8 ...... Compaq 10 or 10/100 PCI Intel Controller Driver
===========================================================================
Itinéraires actifsÿ:
Destination réseau Masque réseau Adr. passerelle Adr. interface Métrique
0.0.0.0 0.0.0.0 160.193.51.113 160.193.51.113 1
0.0.0.0 0.0.0.0 160.194.51.113 160.194.51.113 1
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
160.192.0.0 255.255.0.0 160.193.51.108 160.193.51.113 1
160.193.48.0 255.255.240.0 160.193.51.113 160.193.51.113 1
160.193.51.113 255.255.255.255 127.0.0.1 127.0.0.1 1
160.193.255.255 255.255.255.255 160.193.51.113 160.193.51.113 1
160.194.48.0 255.255.240.0 160.194.51.113 160.194.51.113 1
160.194.51.113 255.255.255.255 127.0.0.1 127.0.0.1 1
224.0.0.0 224.0.0.0 160.193.51.113 160.193.51.113 1
224.0.0.0 224.0.0.0 160.194.51.113 160.194.51.113 1
255.255.255.255 255.255.255.255 160.193.51.113 160.193.51.113 1
===========================================================================
Fichiers SAMBA
Smbpasswd
clx21:500:AAD3B435B51404EEAAD3B435B51404EE:31D6CFE0D16AE931B73C59D7E0C089
C0:[U ]:LCT-3B335D8E:
C0:[U ]:LCT-3B335DA3:
root:0:AAD3B435B51404EEAAD3B435B51404EE:31D6CFE0D16AE931B73C59D7E0C089C0:
[U ]:LCT-3B335DC5:
C0:[U ]:LCT-3B33645D:
C0:[U ]:LCT-3B336472:
Smbusers
root = administrateur
clx21 = msg1
clx22 = msg2
clx23 = ops1
clx24 = ops2
ops = ops1 ops2
Smb.conf
# This is the main Samba configuration file. You should read the
# smb.conf(5) manual page in order to understand the options listed
# here. Samba has a huge number of configurable options (perhaps too
# many!) most of which are not shown in this example
#
# Any line which starts with a ; (semi-colon) or a # (hash)
# is a comment and is ignored. In this example we will use a #
# for commentry and a ; for parts of the config file that you
# may wish to enable
#
# NOTE: Whenever you modify this file you should run the command "testparm"
# to check that you have not many any basic syntactic errors.
#
#======================= Global Settings =====================================
[global]
# workgroup = NT-Domain-Name or Workgroup-Name

workgroup = DOM-CHRONOS
# server string is the equivalent of the NT Description field

server string = Serveur Samba %v
# This option is important for security. It allows you to restrict

# connections to machines which are on your local network. The
# following example restricts access to two C class networks and
# the "loopback" interface. For more examples of the syntax see
# the smb.conf man page
; hosts allow = 192.168.1. 192.168.2. 127.
# Enabling internationalization:
# you can match a Windows code page with a UNIX character set.
# Windows: 437 (US), 737 (GREEK), 850 (Latin1 - Western European),
# 852 (Eastern Eu.), 861 (Icelandic), 932 (Cyrillic - Russian),
# 936 (Japanese - Shift-JIS), 936 (Simpl. Chinese), 949 (Korean Hangul),
# 950 (Trad. Chin.).
# UNIX: ISO8859-1 (Western European), ISO8859-2 (Eastern Eu.),
# ISO8859-5 (Russian Cyrillic), KOI8-R (Alt-Russ. Cyril.)
# This is an example for french users:
; client code page = 850
; character set = ISO8859-1
# CHANGES TO ENABLE PRINTING ON ALL CUPS PRINTERS IN THE NETWORK

# (as cups is now used in linux-mandrake 7.2 by default)
# if you want to automatically load your printer list rather
# than setting them up individually then you'll need this
printcap name = lq1070
load printers = yes
# It should not be necessary to spell out the print system type unless
# yours is non-standard. Currently supported print systems include:
# bsd, sysv, plp, lprng, aix, hpux, qnx, cups
printing = cups
# Uncomment this if you want a guest account, you must add this to /etc/passwd
# otherwise the user "nobody" is used
; guest account = pcguest
# this tells Samba to use a separate log file for each machine
# that connects
log file = /var/log/samba/log.%m
# Put a capping on the size of the log files (in Kb).

max log size = 50
# Security mode. Most people will want user level security. See
# security_level.txt for details.
security = user
# Use password server option only with security = server
; password server = <NT-Server-Name>
# Password Level allows matching of _n_ characters of the password for

# all combinations of upper and lower case.
; password level = 8
; username level = 8
# You may wish to use password encryption. Please read

# ENCRYPTION.txt, Win95.txt and WinNT.txt in the Samba documentation.
# Do not enable this option unless you have read those documents
encrypt passwords = yes
smb passwd file = /etc/smbpasswd
# The following are needed to allow password changing from Windows to

# update the Linux sytsem password also.
# NOTE: Use these with 'encrypt passwords' and 'smb passwd file' above.
# NOTE2: You do NOT need these to allow workstations to change only
# the encrypted SMB passwords. They allow the Unix password
# to be kept in sync with the SMB password.
; unix password sync = Yes
; passwd program = /usr/bin/passwd %u
; passwd chat = *New*UNIX*password* %n\n *ReType*new*UNIX*password* %n\n
*passwd:*all*authentication*tokens*updated*successfully*
# Unix users can map to different SMB User names

username map = /etc/smbusers
# Using the following line enables you to customise your configuration

# on a per machine basis. The %m gets replaced with the netbios name
# of the machine that is connecting
; include = /etc/smb.conf.%m
# Most people will find that this option gives better performance.
# See speed.txt and the manual pages for details
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
# Configure Samba to use multiple interfaces

# If you have multiple network interfaces then you must list them
# here. See the man page for details.
; interfaces = 192.168.12.2/24 192.168.13.2/24
# Configure remote browse list synchronisation here

# request announcement to, or browse list sync from:
# a specific host or from / to a whole subnet (see below)
; remote browse sync = 192.168.3.25 192.168.5.255
# Cause this host to announce itself to local subnets here
; remote announce = 192.168.1.255 192.168.2.44
# Browser Control Options:

# set local master to no if you don't want Samba to become a master
# browser on your network. Otherwise the normal election rules apply
; local master = no
# OS Level determines the precedence of this server in master browser

# elections. The default value should be reasonable
; os level = 33
# Domain Master specifies Samba to be the Domain Master Browser. This

# allows Samba to collate browse lists between subnets. Don't use this
# if you already have a Windows NT domain controller doing this job
; domain master = yes
# Preferred Master causes Samba to force a local browser election on startup

# and gives it a slightly higher chance of winning the election
; preferred master = yes
# Use only if you have an NT server on your network that has been
# configured at install time to be a primary domain controller.
; domain controller = <NT-Domain-Controller-SMBName>
# Enable this if you want Samba to be a domain logon server for

# Windows95 workstations.
; domain logons = yes
# if you enable domain logons then you may want a per-machine or

# per user logon script
# run a specific logon batch file per workstation (machine)
; logon script = %m.bat
# run a specific logon batch file per username
; logon script = %U.bat
# Where to store roving profiles (only for Win95 and WinNT)
# %L substitutes for this servers netbios name, %U is username
# You must uncomment the [Profiles] share below
; logon path = \\%L\Profiles\%U
# All NetBIOS names must be resolved to IP Addresses

# 'Name Resolve Order' allows the named resolution mechanism to be specified
# the default order is "host lmhosts wins bcast". "host" means use the unix
# system gethostbyname() function call that will use either /etc/hosts OR
# DNS or NIS depending on the settings of /etc/host.config, /etc/nsswitch.conf
# and the /etc/resolv.conf file. "host" therefore is system configuration
# dependant. This parameter is most often of use to prevent DNS lookups
# in order to resolve NetBIOS names to IP Addresses. Use with care!
# The example below excludes use of name resolution for machines that are NOT
# on the local network segment
# - OR - are not deliberately to be known via lmhosts or via WINS.
; name resolve order = wins lmhosts bcast
# Windows Internet Name Serving Support Section:

# WINS Support - Tells the NMBD component of Samba to enable it's WINS Server
; wins support = yes
# WINS Server - Tells the NMBD components of Samba to be a WINS Client

# Note: Samba can be either a WINS Server, or a WINS Client, but NOT both
; wins server = w.x.y.z
# WINS Proxy - Tells Samba to answer name resolution queries on

# behalf of a non WINS capable client, for this to work there must be
# at least one WINS Server on the network. The default is NO.
; wins proxy = yes
# DNS Proxy - tells Samba whether or not to try to resolve NetBIOS names
# via DNS nslookups. The built-in default for versions 1.9.17 is yes,
# this has been changed in version 1.9.18 to no.
dns proxy = no
# Case Preservation can be handy - system default is _no_

# NOTE: These can be set on a per share basis
; preserve case = no
; short preserve case = no
# Default case is normally upper case for all DOS files
; default case = lower
# Be very careful with case sensitivity - it can break things!
; case sensitive = no
#============================ Share Definitions ==============================

[home]
comment = Répertoire privé de chaque utilisateur %U sur %h
path = %H
browseable = yes
read only = no
create mode = 0750
[ops]
comment = Répertoire pour les menbres du groupe OPS
path = /ops
browseable = yes
read only = no
public = yes
create mode = 0775
valid users = @ops
# Un-comment the following and create the netlogon directory for Domain Logons
; [netlogon]
; comment = Network Logon Service
; path = /home/netlogon
; guest ok = yes
; writable = no
; share modes = no
# Un-comment the following to provide a specific roving profile share

# the default is to use the user's home directory
;[Profiles]
; path = /home/profiles
; browseable = no
; guest ok = yes
# NOTE: If you have a CUPS print system there is no need to

# specifically define each individual printer.
# You must configure the samba printers as "Generic PostScript Printer"
# on your Windows clients.
# If you wish to configure the printers directly on the Windows clients
# (i.e. use the windows drivers on the clients) you must swap the
# 'print command' line below with the commented one.
[printers]
comment = All Printers
path = /var/spool/samba
browseable = yes
# to allow user 'guest account' to print.
guest ok = yes
writable = no
printable = yes
create mode = 0700
# =====================================
# print command: see above for details.
# =====================================
; print command = lpr-cups -P %p -o raw %s # using client side printer
drivers.
print command = lpr-cups -P %p %s # using cups own drivers (use generic
PostScript on clients).
lpq command = lpstat -o %p
lprm command = cancel %p-%j
#Partage de l’imprimante Epson

[epson]
comment = Imprimante Epson sous Samba
path = /var/spool/samba
printer name = epson
public = yes
writable = no
printable = yes
print command = lpr –r –h –P %p %s
create mode = 0750
# This one is useful for people to share files

;[tmp]
; comment = Temporary file space
; path = /tmp
; read only = no
; public = yes
# A publicly accessible directory, but read only, except for people in

# the "staff" group
;[public]
; comment = Public Stuff
; path = /home/samba
; public = yes
; writable = yes
; printable = no
; write list = @staff
# Other examples.
#
# A private printer, usable only by fred. Spool data will be placed in fred's
# home directory. Note that fred must have write access to the spool directory,
# wherever it is.
;[fredsprn]
; comment = Fred's Printer
; valid users = fred
; path = /homes/fred
; printer = freds_printer
; public = no
; writable = no
; printable = yes
# A private directory, usable only by fred. Note that fred requires write
# access to the directory.
;[fredsdir]
; comment = Fred's Service
; path = /usr/somewhere/private
; valid users = fred
; public = no
; writable = yes
; printable = no
# a service which has a different directory for each machine that connects
# this allows you to tailor configurations to incoming machines. You could
# also use the %u option to tailor it by user name.
# The %m gets replaced with the machine name that is connecting.
;[pchome]
; comment = PC Directories
; path = /usr/pc/%m
; public = no
; writable = yes
# A publicly accessible directory, read/write to all users. Note that all files
# created in the directory by users will be owned by the default user, so
# any user with access can delete any other user's files. Obviously this
# directory must be writable by the default user. Another user could of course
# be specified, in which case all files would be owned by that user instead.
;[public]
; path = /usr/somewhere/else/public
; public = yes
; only guest = yes
; writable = yes
; printable = no
# The following two entries demonstrate how to share a directory so that two
# users can place files there that will be owned by the specific users. In this
# setup, the directory should be writable by both users and should have the
# sticky bit set on it to prevent abuse. Obviously this could be extended to
# as many users as required.
;[myshare]
; comment = Mary's and Fred's stuff
; path = /usr/somewhere/shared
; valid users = mary fred
; public = no
; writable = yes
; printable = no
; create mask = 0765
Commentaires sur le fichier smb.conf
Variables reconnues :
%u : nom de l’utilisateur
%g : groupe de l’utilisateur
%S : nom du partage
%m : le nom NETBIOS de la machine cliente
%L : le nom NETBIOSdu serveur
%M : le nom internet de la machine cliente
Niveaux de sécurité
Security=share : un mot de passe est demandé pour la connexion au partage ; smbd demande
toujours une identification d’utilisateur Linux.
Security=user : le client doit s’authentifier par un nom et un mot de passe valides ; c’est le
mode par défaut.
Security=server : l’authentification est déléguée à un serveur (par exemple un serveur NT) ;
pour le client, le fonctionnement est identique à security=user.
Security=domain : l’authentification est réalisée par le premier serveur de domaine qui répond
(dans un domaine NT, ce sera le PDC ou l’un BDC) ; pour le client le fonctionnement est
identique à security=user.
La directive password server permet de désigner la machine d’authentification pour les 2

derniers cas (et donc le fameux serveur NT).
Niveau OS
OS level = 33 : le niveau OS d’un PDC NT est de 32 ; afin d’éviter les conflits avec le monde
NT en général, on laisse cette ligne en commentaire (sauf si l’on veut que le serveur SAMBA
soit contrôleur de domaine (?!!!???)
Partage d’un disque

Browesable : permet de publier le service pour les voisinages réseaux
Create mask : donne les droits affectés à un nouveau fichier
Directory mask : donne les droits affectés à un nouveau répertoire
Writeable : autorise ou non la création de fichiers.
Valide users : donne la liste des utilisateurs autorisés à utiliser le service ; si le nom commence
par @, il désigne un groupe –préférable).
Administration SAMBA distante

Il est possible d’administrer une station Linux à partir d’un client HTTP NT ou autre.
Il faut, appliquer la procédure suivante :
- fichier inetd.conf : décommenter la ligne :
swat stream tcp nowait.400 root /usr/bin/swat swat
- fichier etc/services : vérifier la présence du service : swat 901/tcp
- vérifier dans le fichier smb.conf les options liées à la sécurité : lignes allow hosts et deny
hosts
On obtient alors une interface de ce type :
Administration station Linux à distance
Il est possible d’administrer une station Linux à partir d’un client HTTP NT ou autre.
Il faut, appliquer la procédure suivante :

- station Linux : lancer Linuxconf
- dans paramètres réseaux/autres :
- autoriser linuxconf par le réseau (port 98 par défaut)
- Indiquer le réseau autorisé (ex : 160.192.0.0) comme indiqué dans l’aide ; sinon on
obtiendra chez le client l’erreur 500 (accès refusé)
Note instructeur : il est souvent plus facile de lancer Linuxconf à parti d’une console
en mode caractère (accès par ALT F2 puis taper Linuxconf).
- station client
- Ouvrir un navigateur en indiquant : http://160.192.60.134 :98 par exemple
- une fenêtre invite à taper le mot de passe pour le root Linux
La fenêtre suivante apparaît.
Note instructeur : en cas d’accès refusé (suite à une installation en mode de sécurité élevée par
exemple), il faut vérifier :
- dans le fichier /etc/services : présence de la ligne linuxconf 98/tcp
- dans le fichier inetd.conf : présence de la ligne :
linuxconf stream tcp wait root /bin/linuxconf linuxconf –http
Le chemin /bin/linuxconf dépende de l’endroit où est installé linuxconf ; il se peut qu’il
diffère et soit donc /sbin/linuxconf
- dans le fichier hosts.deny : mettre, si ce n’est pas déjà fait, en commentaire la dernière ligne
qui indique la liste de stations qui n’ont pas accès à celle-ci
- relancer linuxconf
Présentation des options de Linuxconf : les copies d’écran suivantes ont été réalisées à partir
d’une station NT.
Résolution des noms par fichier LMHOSTS
Sans WINS, la mise en œuvre des relations d’approbation est impossible ; le système ne peut en
effet pas résoudre le nom de domaine approuvé ou approuvant.
On crée donc un fichier LMHOSTS et on indique ensuite à la station d’utiliser ce fichier (applet
Réseau/WINS/case à cocher)
On notera les commandes précédées d’un # : ce ne sont pas des commentaires ; la résolution est
assurée par recherche du fichier lmhosts soit sur le serveur pdc-n soit sur le serveur bdc-n si le
premier ne répond pas.
Exemple de fichier LMHOSTS d’une station cliente :
160.192.51.106 WKS1-N
160.192.51.101 PDC-N #PRE #DOM :DOM-NOC
160.192.51.102 BDC-N #PRE #DOM :DOM-NOC
#BEGIN_ALTERNATE
#INCLUDE \\PDC-N\host\lmhosts
#INCLUDE \\BDC-\host\lmhosts
#END_ALTERNATE
DNS NT hiérarchique
Nota : les copies d’écran suivantes contiennent des noms de stations avec un caractère
souligné : cette syntaxe est incompatible avec le DNS standard.
DNS du DOM-NOC.
C’est le serveur DNS le plus haut dans la hiérarchie.
Il contient les domaines DNS du domaine DNS.TRIDENT.KSV
DNS du domaine DOM_CHRONOS.
On notera la présence des stations Linux et celle d’un alias wsitops sur le serveur du
domaine DOM_SITOPS ; cet alias permet d’attaquer le serveur WEB SITOPS par
l’adresse : http://wsitops.
Le DNS du domaine SITOPS est identique à celui de CHRONOS.
Pour que le DNS fonctionne, il faut indiquer aux sous-domaines (chronos et sitops) l’adresse du
serveur DNS de niveau supérieur (ici dom-noc) : c’est le redirecteur.
Droits en inter domaines
On insère ici les groupes globaux des domaines autorisés à approuver dans un groupe local du
domaine de ressources (ici DOM-CHRONOS)
Depuis les autres domaines, on accède à la ressource partagée Interco du domaine DOM-NOC
par le menu Démarrer, Exécuter \\bdc-n.noc.trident.ksv\interco.
Les DNS sont, pour chaque serveur DNS, enregistrés dans des fichiers textes sous le répertoire
dns.
Voici le contenu de cers fichiers pour chaque serveur DNS.
Serveur DNS du domaine DOM-NOC : c’est le plus haut niveau

;
; Database file ksv.dns for ksv zone.
; Zone version: 12
;
@ IN SOA noc-svr2.noc.ksv. administrateur.noc.ksv. (

12 ; serial number
300 ; refresh
60 ; retry
86400 ; expire
3600 ) ; minimum TTL
;
; Zone NS records
;
@ NS noc-svr2.noc
;
; Zone records
;
noc-lx2w.noc.trident A 160.192.51.44
noc-svr2.noc.trident A 160.192.51.42
noc_svr1.noc.trident A 160.192.51.41
routeur.noc.trident A 160.192.51.101
;
; Delegated sub-zone: chronos.trident.ksv.
;
chronos.trident NS chronos-svr1.chronos.trident
chronos-svr1.chronos.trident A 160.194.51.1
; End delegation
;
; Delegated sub-zone: sitops.trident.ksv.
;
sitops.trident NS sitops-svr1.sitops.trident
sitops-svr1.sitops.trident A 160.193.51.1
; End delegation
Serveur DNS du domaine DOM-SITOPS
;
; Database file sitops.trident.ksv.dns for sitops.trident.ksv zone.
; Zone version: 18
;
@ IN SOA sitops-svr1.sitops.ksv. administrateur.sitops.ksv. (

18 ; serial number
3600 ; refresh
600 ; retry
86400 ; expire
;
; Zone NS records
;
@ NS sitops-svr1.sitops.ksv.
;
; Zone records
;
partage CNAME noc_svr1.noc.trident.ksv.

rn CNAMErouteur.noc.trident.ksv.
sitops-lx1 A 160.193.51.11
sitops-lx2 A 160.193.51.12
sitops-nt1 A 160.193.51.3
sitops-svr1 A 160.193.51.1
sitops-svr2 A 160.193.51.2
web CNAME sitops-lx1
La zone in-addr-arpa conteint les enregistrements permettant la résolution inverse :

;
; Database file 193.160.in-addr.arpa.dns for 193.160.in-addr.arpa zone.
; Zone version: 11
;
@ IN SOA sitops-svr1.sitops.ksv. administrateur.sitops.ksv. (

11 ; serial number
3600 ; refresh
600 ; retry
86400 ; expire
;
; Zone NS records
;
@ NS sitops-svr1.sitops.ksv.
;
; Zone records
;
1.51 PTR sitops-svr1.

PTR sitops-svr1.sitops.trident.ksv.
10.51 PTR lpr-lx2080.sitops.ksv.
11.51 PTR sitops-lx1.sitops.ksv.
12.51 PTR sitops-lx2.sitops.ksv.
2.51 PTR sitops-svr2.sitops.ksv.
PTR sitops-svr2.sitops.trident.ksv.
3.51 PTR sitops-nt1.sitops.ksv.
Pour administrer un DNS, on peut utiliser l’utilitaire commun NT / Linux NSLOOKUP.

Sous invite de commande taper nslookup nom_dns_du_serveur_DNS (taper ensuite la
commande help pour accéder à l’aide).
Exemple : consultation des enregistrements du domaine DNS .KSV (voir dans le lutin, un
exemple du DNS de l’ESAT).
> ls -d ksv
[UnKnown]
ksv. SOA noc-svr2.noc.ksv administrateur.noc.ksv. (13 300 60 86400 3600)
ksv. NS noc-svr2.noc.ksv
chronos.trident NS chronos-svr1.chronos.trident.ksv
chronos-svr1.chronos.trident A 160.194.51.1
noc-lx2w.noc.trident A 160.192.51.44
noc-svr2.noc.trident A 160.192.51.42
noc-svr2.noc.trident HINFO Pentium NT4.0
noc_svr1.noc.trident A 160.192.51.41
routeur.noc.trident A 160.192.51.101
sitops.trident NS sitops-svr1.sitops.trident.ksv
sitops-svr1.sitops.trident A 160.193.51.1
ksv. SOA noc-svr2.noc.ksv administrateur.noc.ksv. (13 300 60 86400 3600)
Cet utilitaire est très intéressant pour générer une documentation sur les serveurs DNS d’un site.
On peut en effet rediriger le résultat de la commande ls (liste des enregistrements du domaine
DNS) vers un fichier texte ; on pourra alors l’importer dans logiciel plus adapté au tri, mise en
page etc tel Excel ou Access.
Fichier ifcfg-eth0
DEVICE=eth0
IPADDR=160.192.51.103
NETMASK=255.255.0.0
NETWORK=160.192.0.0
BROADCAST=160.192.255.255
ONBOOT=yes
BOOTPROTO=none
Fichier inetd.conf
ON notera la dernière ligne qui doit être décommentée pour utiliser l’utilitaire SWAT.
#
# inetd.conf This file describes the services that will be available
# through the INETD TCP/IP super server. To re-configure
# the running INETD process, edit this file, then send the
# INETD process a SIGHUP signal.
#
# Version: @(#)/etc/inetd.conf 3.10 05/27/93
#
# Authors: Original taken from BSD UNIX 4.3/TAHOE.
# Fred N. van Kempen, <waltje@uwalt.nl.mugnet.org>
#
# Modified for Debian Linux by Ian A. Murdock <imurdock@shell.portal.com>
#
# Modified for RHS Linux by Marc Ewing <marc@redhat.com>
#
# <service_name> <sock_type> <proto> <flags> <user> <server_path> <args>
#
# Echo, discard, daytime, and chargen are used primarily for testing.
#
# To re-read this file after changes, just do a 'killall -HUP inetd'
#
#echo stream tcp nowait root internal
#echo dgram udp wait root internal
#discard stream tcp nowait root internal
#discard dgram udp wait root internal
#daytime stream tcp nowait root internal
#daytime dgram udp wait root internal
#chargen stream tcp nowait root internal
#chargen dgram udp wait root internal
#time stream tcp nowait root internal
#time dgram udp wait root internal
#
# These are standard services.
#
ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -l -a
telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
#
# Shell, login, exec, comsat and talk are BSD protocols.
#
shell stream tcp nowait root /usr/sbin/tcpd in.rshd
login stream tcp nowait root /usr/sbin/tcpd in.rlogind
#exec stream tcp nowait root /usr/sbin/tcpd in.rexecd
#comsat dgram udp wait root /usr/sbin/tcpd in.comsat
talk dgram udp wait root /usr/sbin/tcpd in.talkd
ntalk dgram udp wait root /usr/sbin/tcpd in.ntalkd
#dtalk stream tcp waut nobody /usr/sbin/tcpd in.dtalkd
#
# Pop and imap mail services et al
#
#pop-2 stream tcp nowait root /usr/sbin/tcpd ipop2d
#pop-3 stream tcp nowait root /usr/sbin/tcpd ipop3d
#imap stream tcp nowait root /usr/sbin/tcpd imapd
#
# The Internet UUCP service.
#
#uucp stream tcp nowait uucp /usr/sbin/tcpd /usr/lib/uucp/uucico
-l
#
# Tftp service is provided primarily for booting. Most sites
# run this only on machines acting as "boot servers." Do not uncomment
# this unless you *need* it.
#
#tftp dgram udp wait root /usr/sbin/tcpd in.tftpd
#bootps dgram udp wait root /usr/sbin/tcpd bootpd
#
# Finger, systat and netstat give out user information which may be
# valuable to potential "system crackers." Many sites choose to disable
# some or all of these services to improve security.
#
finger stream tcp nowait root /usr/sbin/tcpd in.fingerd
#cfinger stream tcp nowait root /usr/sbin/tcpd in.cfingerd
#systat stream tcp nowait guest /usr/sbin/tcpd /bin/ps -
auwwx
#netstat stream tcp nowait guest /usr/sbin/tcpd /bin/netstat
-f inet
#
# Authentication
#
auth stream tcp nowait nobody /usr/sbin/in.identd in.identd -l -e
-o
#
# End of inetd.conf
linuxconf stream tcp wait root /bin/linuxconf linuxconf --http

#swat stream tcp nowait.400 root /usr/sbin/swat swat
Fichier etc/services
Visualisationdes ports ; on remarque la dernière ligne qui indique le port SWAT.
# /etc/services:
# $Id: services,v 1.4 1997/05/20 19:41:21 tobias Exp $
#
# Network services, Internet style
#
# Note that it is presently the policy of IANA to assign a single well-known
# port number for both TCP and UDP; hence, most entries here have two entries
# even if the protocol doesn't support UDP operations.
# Updated from RFC 1700, ``Assigned Numbers'' (October 1994). Not all ports
# are included, only the more common ones.
tcpmux 1/tcp # TCP port service multiplexer

echo 7/tcp
echo 7/udp
discard 9/tcp sink null
discard 9/udp sink null
systat 11/tcp users
daytime 13/tcp
daytime 13/udp
netstat 15/tcp
qotd 17/tcp quote
msp 18/tcp # message send protocol
msp 18/udp # message send protocol
chargen 19/tcp ttytst source
chargen 19/udp ttytst source
ftp-data 20/tcp
ftp 21/tcp
fsp 21/udp fspd
ssh 22/tcp # SSH Remote Login Protocol
ssh 22/udp # SSH Remote Login Protocol
telnet 23/tcp
# 24 - private
smtp 25/tcp mail
# 26 - unassigned
time 37/tcp timserver
time 37/udp timserver
rlp 39/udp resource # resource location
nameserver 42/tcp name # IEN 116
whois 43/tcp nicname
re-mail-ck 50/tcp # Remote Mail Checking Protocol
re-mail-ck 50/udp # Remote Mail Checking Protocol
domain 53/tcp nameserver # name-domain server
domain 53/udp nameserver
mtp 57/tcp # deprecated
bootps 67/tcp # BOOTP server
bootps 67/udp
bootpc 68/tcp # BOOTP client
bootpc 68/udp
tftp 69/udp
gopher 70/tcp # Internet Gopher
gopher 70/udp
rje 77/tcp netrjs
finger 79/tcp
www 80/tcp http # WorldWideWeb HTTP
www 80/udp # HyperText Transfer Protocol
link 87/tcp ttylink
kerberos 88/tcp kerberos5 krb5 # Kerberos v5
kerberos 88/udp kerberos5 krb5 # Kerberos v5
supdup 95/tcp
# 100 - reserved
hostnames 101/tcp hostname # usually from sri-nic
iso-tsap 102/tcp tsap # part of ISODE.
csnet-ns 105/tcp cso-ns # also used by CSO name server
csnet-ns 105/udp cso-ns
# unfortunately the poppassd (Eudora) uses a port which has already
# been assigned to a different service. We list the poppassd as an
# alias here. This should work for programs asking for this service.
# (due to a bug in inetd the 3com-tsmux line is disabled)
#3com-tsmux 106/tcp poppassd
#3com-tsmux 106/udp poppassd
rtelnet 107/tcp # Remote Telnet
rtelnet 107/udp
pop-2 109/tcp postoffice # POP version 2
pop-2 109/udp
pop-3 110/tcp # POP version 3
pop-3 110/udp
sunrpc 111/tcp portmapper # RPC 4.0 portmapper TCP
sunrpc 111/udp portmapper # RPC 4.0 portmapper UDP
auth 113/tcp authentication tap ident
sftp 115/tcp
uucp-path 117/tcp
nntp 119/tcp readnews untp # USENET News Transfer Protocol
ntp 123/tcp
ntp 123/udp # Network Time Protocol
netbios-ns 137/tcp # NETBIOS Name Service
netbios-ns 137/udp
netbios-dgm 138/tcp # NETBIOS Datagram Service
netbios-dgm 138/udp
netbios-ssn 139/tcp # NETBIOS session service
netbios-ssn 139/udp
imap2 143/tcp imap # Interim Mail Access Proto v2
imap2 143/udp imap
snmp 161/udp # Simple Net Mgmt Proto
snmp-trap 162/udp snmptrap # Traps for SNMP
cmip-man 163/tcp # ISO mgmt over IP (CMOT)
cmip-man 163/udp
cmip-agent 164/tcp
cmip-agent 164/udp
xdmcp 177/tcp # X Display Mgr. Control Proto
xdmcp 177/udp
nextstep 178/tcp NeXTStep NextStep # NeXTStep window
nextstep 178/udp NeXTStep NextStep # server
bgp 179/tcp # Border Gateway Proto.
bgp 179/udp
prospero 191/tcp # Cliff Neuman's Prospero
prospero 191/udp
irc 194/tcp # Internet Relay Chat
irc 194/udp
smux 199/tcp # SNMP Unix Multiplexer
smux 199/udp
at-rtmp 201/tcp # AppleTalk routing
at-rtmp 201/udp
at-nbp 202/tcp # AppleTalk name binding
at-nbp 202/udp
at-echo 204/tcp # AppleTalk echo
at-echo 204/udp
at-zis 206/tcp # AppleTalk zone information
at-zis 206/udp
qmtp 209/tcp # The Quick Mail Transfer Protocol
qmtp 209/udp # The Quick Mail Transfer Protocol
z3950 210/tcp wais # NISO Z39.50 database
z3950 210/udp wais
ipx 213/tcp # IPX
ipx 213/udp
imap3 220/tcp # Interactive Mail Access
imap3 220/udp # Protocol v3
rpc2portmap 369/tcp
rpc2portmap 369/udp # Coda portmapper
codaauth2 370/tcp
codaauth2 370/udp # Coda authentication server
ulistserv 372/tcp # UNIX Listserv
ulistserv 372/udp
https 443/tcp # MCom
https 443/udp # MCom
snpp 444/tcp # Simple Network Paging Protocol
snpp 444/udp # Simple Network Paging Protocol
saft 487/tcp # Simple Asynchronous File Transfer
saft 487/udp # Simple Asynchronous File Transfer
npmp-local 610/tcp dqs313_qmaster # npmp-local / DQS
npmp-local 610/udp dqs313_qmaster # npmp-local / DQS
npmp-gui 611/tcp dqs313_execd # npmp-gui / DQS
npmp-gui 611/udp dqs313_execd # npmp-gui / DQS
hmmp-ind 612/tcp dqs313_intercell# HMMP Indication / DQS
hmmp-ind 612/udp dqs313_intercell# HMMP Indication / DQS
#
# UNIX specific services
#
exec 512/tcp
biff 512/udp comsat
login 513/tcp
who 513/udp whod
shell 514/tcp cmd # no passwords used
syslog 514/udp
printer 515/tcp spooler # line printer spooler
talk 517/udp
ntalk 518/udp
route 520/udp router routed # RIP
timed 525/udp timeserver
tempo 526/tcp newdate
courier 530/tcp rpc
conference 531/tcp chat
netnews 532/tcp readnews
netwall 533/udp # -for emergency broadcasts
uucp 540/tcp uucpd # uucp daemon
afpovertcp 548/tcp # AFP over TCP
afpovertcp 548/udp # AFP over TCP
remotefs 556/tcp rfs_server rfs # Brunhoff remote filesystem
klogin 543/tcp # Kerberized `rlogin' (v5)
kshell 544/tcp krcmd # Kerberized `rsh' (v5)
kerberos-adm749/tcp # Kerberos `kadmin' (v5)
#
webster 765/tcp # Network dictionary
webster 765/udp
#
# From ``Assigned Numbers'':
#
#> The Registered Ports are not controlled by the IANA and on most systems
#> can be used by ordinary user processes or programs executed by ordinary
#> users.
#
#> Ports are used in the TCP [45,106] to name the ends of logical
#> connections which carry long term conversations. For the purpose of
#> providing services to unknown callers, a service contact port is
#> defined. This list specifies the port used by the server process as its
#> contact port. While the IANA can not control uses of these ports it
#> does register or list uses of these ports as a convienence to the
#> community.
#
ingreslock 1524/tcp
ingreslock 1524/udp
prospero-np 1525/tcp # Prospero non-privileged
prospero-np 1525/udp
datametrics 1645/tcp old-radius # datametrics / old radius entry
datametrics 1645/udp old-radius # datametrics / old radius entry
sa-msg-port 1646/tcp old-radacct # sa-msg-port / old radacct entry
sa-msg-port 1646/udp old-radacct # sa-msg-port / old radacct entry
radius 1812/tcp # Radius
radius 1812/udp # Radius
radacct 1813/tcp # Radius Accounting
radacct 1813/udp # Radius Accounting
cvspserver 2401/tcp # CVS client/server operations
cvspserver 2401/udp # CVS client/server operations
venus 2430/tcp # codacon port
venus 2430/udp # Venus callback/wbc interface
venus-se 2431/tcp # tcp side effects
venus-se 2431/udp # udp sftp side effect
codasrv 2432/tcp # not used
codasrv 2432/udp # server port
codasrv-se 2433/tcp # tcp side effects
codasrv-se 2433/udp # udp sftp side effect
mysql 3306/tcp # MySQL
mysql 3306/udp # MySQL
rfe 5002/tcp # Radio Free Ethernet
rfe 5002/udp # Actually uses UDP only
cfengine 5308/tcp # CFengine
cfengine 5308/udp # CFengine
bbs 7000/tcp # BBS service
#
#
# Kerberos (Project Athena/MIT) services
# Note that these are for Kerberos v4, and are unofficial. Sites running
# v4 should uncomment these and comment out the v5 entries above.
#
kerberos4 750/udp kerberos-iv kdc # Kerberos (server) udp
kerberos4 750/tcp kerberos-iv kdc # Kerberos (server) tcp
kerberos_master 751/udp # Kerberos authentication
kerberos_master 751/tcp # Kerberos authentication
passwd_server 752/udp # Kerberos passwd server
krb_prop 754/tcp # Kerberos slave propagation
krbupdate 760/tcp kreg # Kerberos registration
kpasswd 761/tcp kpwd # Kerberos "passwd"
kpop 1109/tcp # Pop with Kerberos
knetd 2053/tcp # Kerberos de-multiplexor
zephyr-srv 2102/udp # Zephyr server
zephyr-clt 2103/udp # Zephyr serv-hm connection
zephyr-hm 2104/udp # Zephyr hostmanager
eklogin 2105/tcp # Kerberos encrypted rlogin
#
# Unofficial but necessary (for NetBSD) services
#
supfilesrv 871/tcp # SUP server
supfiledbg 1127/tcp # SUP debugging
#
# Datagram Delivery Protocol services
#
rtmp 1/ddp # Routing Table Maintenance Protocol
nbp 2/ddp # Name Binding Protocol
echo 4/ddp # AppleTalk Echo Protocol
zip 6/ddp # Zone Information Protocol
#
# Services added for the Debian GNU/Linux distribution
poppassd 106/tcp # Eudora
poppassd 106/udp # Eudora
mailq 174/tcp # Mailer transport queue for Zmailer
mailq 174/tcp # Mailer transport queue for Zmailer
ssmtp 465/tcp # SMTP over SSL
gdomap 538/tcp # GNUstep distributed objects
gdomap 538/udp # GNUstep distributed objects
snews 563/tcp # NNTP over SSL
ssl-ldap 636/tcp # LDAP over SSL
omirr 808/tcp omirrd # online mirror
omirr 808/udp omirrd # online mirror
rsync 873/tcp # rsync
rsync 873/udp # rsync
simap 993/tcp # IMAP over SSL
spop3 995/tcp # POP-3 over SSL
socks 1080/tcp # socks proxy server
socks 1080/udp # socks proxy server
rmtcfg 1236/tcp # Gracilis Packeten remote config server
xtel 1313/tcp # french minitel
support 1529/tcp # GNATS
cfinger 2003/tcp # GNU Finger
ninstall 2150/tcp # ninstall service
ninstall 2150/udp # ninstall service
afbackup 2988/tcp # Afbackup system
afbackup 2988/udp # Afbackup system
icp 3130/tcp # Internet Cache Protocol (Squid)
icp 3130/udp # Internet Cache Protocol (Squid)
postgres 5432/tcp # POSTGRES
postgres 5432/udp # POSTGRES
fax 4557/tcp # FAX transmission service (old)
hylafax 4559/tcp # HylaFAX client-server protocol (new)
noclog 5354/tcp # noclogd with TCP (nocol)
noclog 5354/udp # noclogd with UDP (nocol)
hostmon 5355/tcp # hostmon uses TCP (nocol)
hostmon 5355/udp # hostmon uses TCP (nocol)
ircd 6667/tcp # Internet Relay Chat
ircd 6667/udp # Internet Relay Chat
webcache 8080/tcp # WWW caching service
webcache 8080/udp # WWW caching service
tproxy 8081/tcp # Transparent Proxy
tproxy 8081/udp # Transparent Proxy
mandelspawn 9359/udp mandelbrot # network mandelbrot
amanda 10080/udp # amanda backup services
kamanda 10081/tcp # amanda backup services (Kerberos)
kamanda 10081/udp # amanda backup services (Kerberos)
amandaidx 10082/tcp # amanda backup services
amidxtape 10083/tcp # amanda backup services
isdnlog 20011/tcp # isdn logging system
isdnlog 20011/udp # isdn logging system
vboxd 20012/tcp # voice box system
vboxd 20012/udp # voice box system
binkp 24554/tcp # Binkley
binkp 24554/udp # Binkley
asp 27374/tcp # Address Search Protocol
asp 27374/udp # Address Search Protocol
tfido 60177/tcp # Ifmail
tfido 60177/udp # Ifmail
fido 60179/tcp # Ifmail
fido 60179/udp # Ifmail
# Local services
linuxconf 98/tcp
swat 901/tcp # Add swat service used via inetd
Autres produits de partages NT / Unix
- VisionFS de SCO : pas de fonctions de domaines comme Samba. ; inconvénient : le prix : 1
licence par cleint.
- NFS NT de Sun : Solstice NFS Client.
- AccessNFS de Intergraph : acchété par Microsoft est livré dans NT 2000
- NIS (Network Information Service) : permet d’insérer des groupes Unix dans d’autres groupes
Unix. = NT.
Mise en œuvre VNC

Ce logiciel peut être installé comme :
- serveur : il offre l’accès à la station sur laquelle il est installé
- client : il permet l’accès à un serveur VNC.
-
Configuration du serveur VNC :
- Lancer le serveur
- L’écran suivant apparaît :
- l’argument Display Number est le port de connexion
- le mot de passe est celui qui sera demandé au client
Configuration du client VNC :
- lancer VNC Viewer
- l’écran suivant apparaît : on doit indiquer l’adresse IP suivie du port VNC du
serveur VNC ; on pourra vérifier les options qui sont, par défaut, celles présentées ensuite.
Si l’on valide, on doit ensuite saisir le mot de passe défini par le serveur VNC
.
On prend ensuite la main sur la station distante : toutes les actions du client sont visibles du
côté serveur ; la souris, les fenêtres sont manipulées sur le client comme sur le serveur.
Prise de contrôle de la machine distante serveur VNC : ici la station noc_svr1
Protocole d’installation des stations Linux
Nous utiliserons la version Mandrake 7.2 livrée sur 1 seul CD-ROM.
Afin de limiter la durée de l’installation, nous appliquerons le protocole suivant :

- nettoyage de la station :
- delpart (avec une disquette de boot)
- fdisk /mbr
Installation
- MODE DE SECURITE FAIBLE
- installation personnalisée
- station de travail ou serveur suivant le cas
- partitionnement manuel :
 / : 1,2 G0 Mo
 swap : 256 Mo
 /home : tout le reste
- paquetages : groupes par défaut.
- KDE
- Outils internet
- Outils de communications
- Documentation
- Développement C et C++
- Utilitaires consoles
- Utilitaires
- Divers
Mise en œuvre de CUPS
Cet outil permet de gérer les imprimantes sous Linux sous interface Web . Le port http utilisé est
le 631.
Dans le TP, nous installons une imprimante réseau. Il faut donc choisir le protocole socket en
indiquant l’adresse IP de l’imprimante ; cette adresse sera précédemment attribuée par la
commande arp.
Les copies d’écran suivantes ont été obtenues à parti d’une station NT.
Ecran d’accueil
Ajout d’une imprimante
Visualisation de l’imprimante
On notera l’adresse http : il s’agit du nom DNS de la station Linux sur laquelle est installée CUPS.
Les imprimantes sous Unix
Création d’une imprimante
Interface graphique
REDHATE 6.0
- taper au clavier alt. F2
- commande control-panel
MANDRAKE 7
- choisir l'icône DRAKCONF
- configuration imprimante
Ensuite dans les 2 cas
1. création imprimante en parallèle

PC serveur
name=espon
parallèle
dans la liste choisir espon stylus 800 et ESC/P 2 – 180dpi – A4
Queue=/var/spool/lpd/espon
mettre à jour ou créer le fichier /etc/hosts.lpd sur le pc serveur avec les @ip des pc qui veulent
imprimer
ensuite relancer le démon lpd sur LE pc qui gère l'imprimante
printoll lpd test help
restart lpd (/etc/rc.d/init.d/lpd restart)
2. création imprimante en remote

PC client
name =réseau
remote host @ip du pc qui gère l'imprimante
remote Queuenom de l'imprimante définie en parallèle sur le pc distant
@ip 160.192.61.151
SERVEUR
CLIENT
/var/spool/lpd/réseau
imp209
/var/spool/lpd/imp209
Exemples de fichier /etc/printcap
Il contient les imprimantes sous UNIX
# Imprimante Locale
monImpri|impHP: \ /* nom imprimante et alias (séparateur Alt Gr 6)
:sd=/var/spool/lpd/monImpri:\ /* mettre une tabulation création d'un spool local
:mx#0:\ /* Taille maxi d'1 fic 0 non limitée.
:sh:\ /* suppression entête si pas cette ligne alors entête.
:lp=/dev/lp0:\ /* /dev/lp0 est le nom du 1er périphérique port parallèle
:if=/var/spool/lpd/monImpri/filter: /* rep.qui contient le filtre (config imprimante)
↔ attention
La dernière ligne ne fini pas par :\ mais :
D'autres Options sont disponibles voir : man printcap
# Imprimante distante Locale à un autre ordinateur

monImpri2 : \ /* nom imprimante
:sd=/var/spool/lpd/monImpri2:\ /*mettre une tabulation création d'un spool local
:mx#0:\ /*Taille maxi d'1fic 0 non limitée.
:rm=c201-0209-1260:\ /* Nom ou @IP de machine qui à l'imprimante en locale
:rp=monImpri: /* Nom de l'imprimante telle qu'elle est déclarée en locale
↔ attention
Sur la machine locale, il faut :
- imprimante déclarée en exemple 1,
- le fichier /etc/hosts.lpd renseigné avec les nom de machine ou @IP des machines qui
peuvent imprimer sur l'imprimante.
Ex /etc/hosts.lpd
C201-0209-1261
C201-0209-1262
C201-0209-1264
C201-0209-1265
# Imprimante réseau
Ireseau : \ /* nom imprimante
:sd=/var/spool/lpd/Ireseau:\ /*mettre une tabulation création d'un spool local
:mx#0:\ /*Taille maxi d'1fic 0 non limitée.
:rm=160.192.61.1965:\ /* @IP de l'imprimante réseau
:rp=raw:\ /* car l'imprimante est réseau
:if=/var/spool/lpd/Ireseau/filter: /* rep.qui contient le filtre (config imprimante)
↔ attention

TP Instructeur Linux NT

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

TP Instructeur Linux NT

Hochgeladen von

Copyright:

Verfügbare Formate

ADC BODIN

PROJET INTERCONNEXION NT / LINUX

PARTAGE DES RESSOURCES NT / LINUX............................................................................................................10

PROJET INTERCONNEXION NT / LINUX

Le but de ce projet est de concevoir un système d’information en milieu hétérogène. Nous

Le SI TRIDENT est composé de plusieurs services :

Le COMSICIAT demande à l’administrateur système du théâtre de revoir l’organisation

Nous devons étudier pour chaque organisme :

Mise en place des stations

o WEB : IIS standard sans Gopher

- Installation du BDC : serveur de fichier ; l’arborescence sera la suivante :

- Installation de la Workstation dans le domaine

- Installation d’une imprimante réseau (raccordée au hub) : il faut la configurer par la

On doit ensuite modifier le masque de réseau de l’imprimante pour l’insérer dans

Constitution du réseau Linux

- installation du serveur Linux

Note instructeur : cette procédure sensibilise à l’utilisation de système différent.

- Insertion des stations dans le DNS NT,

- Pour les problèmes d’interface graphique, lancer /usr/x11r6/lib/x11/x86config

Nom du réseau Station Services @IP Masque Observations

Partage des répertoires : NFS

Le partage s'effectue en 2 étapes :

- configuration des clients NFS : ils importent

- nmbd (/usr/local/samba/bin/nmbd) : serveur de nom NetBios qui permet d’associer un nom

- Commande : /etc/rc.d/init.d/smb start et stop ou smbd restart.

Les fichiers de configuration

- Test de la syntaxe de smb.conf par la commande Testparm

Les répertoires NT vu de clients Linux

Smbclient : interface de type Ftp

Smbmount : permet de monter une ressource NT sur le serveur Samba

Exemple de la commande de montage :

Exemple de la commande de démontage :

Les répertoires Linux vu de clients NT

La configuration de Samba se situe à plusieurs niveaux :

Il faut configurer 3 fichiers :

Ops1 et ops2 sont les logins des utilisateurs du domaine NT.

On veut également permettre à l’administrateur NT de contrôler le serveur Samba au

 Section GLOBAL : attention au paramètre os level = 33 ; il conditionne l’élection du

 Section SHARE : partage des ressources pour les clients NT.

Lorsque tous les partages fonctionnent, il est demandé :

Installation sur le serveur SAMBA

Installation sur le serveur NT

Installation du service DNS sur le serveur LINUX

Rappel sur DNS standard

Outils d’administration à distance

Administration des stations Linux

- VNC (voir mise en œuvre en annexe)

Problèmes d’accès aux objets : permissions, identification

Par les relations d’approbation, on peut :

Note instructeur : la relation d’approbation nécessite la résolution du nom de domaine ; or

L’administrateur du domaine approuvé peut administrer les comptes du domaine approuvant et

La stratégie (POLEDIT) s’applique sur le domaine de d’ouverture de session.

Domaine dit de ressources : Le domaine NOCapprouve les

Domaines dit de comptes : accède au partage INTERCO

Pour établir la relation d’approbation, il faut appliquer la procédure suivante :

Rappel sur les différents modèles d’approbation

Modèle à domaine maître unique

Modèle à domaines maîtres multiples

Modèle d’approbation totale

Il faut cependant qu’un lien physique existe entre nos 3 organismes.

Solutions envisagées pour interconnecter les stations :

Le routage doit être configuré :

• Pour la station WKS1-S du réseau 160.193.0.0 :