-SAMBA-PDC-WIN2K-NIS-BSD-Mini-Tutorial-

Intro :

Le but de ce mini How-To est de presenter rapidement la mise en place d'une gestion centralisée d'utilisateurs dans un environnement hétérogene. Quand je parle environnement hétérogene cela veut dire que l'on a un parc de micro composé de PC sous Windows ou Unix et des stations de travail sous Unix. Cette situation est tres souvent rencontré dans les entreprises, et se pose alors la question de la mobilité des utilisateurs et du “single sign-on” (un seul compte/mot de passe quel que soit l environnement utilisé). Cet exemple propose une solution simple et qui marche à ce probleme.

Environnement de test :

Comme on ne peut pas couvrir tout les environnements ni tous les OS possible, nous allons nous limiter à l utilisation d'un serveur de connexion sous OpenBSD et des clients utilisants Win2k et FreeBSD.

Le serveur de connexion centralisera les comptes utilisateurs (c est a dire leurs infos et leurs “home directories”). Quand un utilisateur voudra se connecter sur une station il interogera ce serveur pour valider sa connexion et acceder a ces informations personnelles. Ce serveur sera un serveur Unix OpenBSD.

De quoi avons nous besoin ? :

Treve de generalités; nos clients sont soit Unix; soit Win2k (win2k professionnal). Notre serveur va donc jouer le role de master NIS /serveurs NFS pour les clients Unix; et de PDC (primary domain controleur) pour les clients Windows. Qui dit clients Windows dit Samba; NIS/NFS etant installés en standard sous OpenBSD.

Configuration du serveur :

Toutes ces manipulations sont a effectuer sur le serveur OpenBSD (pour ceux qui ont pas suivis ;).

NIS :

NIS est une sorte d annuaire qui va exporter des infos disponibles sur le reseau (typiquement les passwords; les hostnames; etc.. ).

Nous avons besoin d exporter les maps passwords, groups plus quelques autres maps relatives a l automounter ( a voir + tard)

Nous devons definir un nom de domaine NIS

$ cat mon_domaine > /etc/defaultdomain
$ domainname
mon_domaine
$

Maintenant initialisons les bases NIS (nous n avons pas de serveurs NIS esclaves pour le moment).

$ ypinit -m 
Server Type: MASTER Domain: mon_domaine

Creating an YP server will require that you answer a few questions.
Questions will all be asked at the beginning of the procedure.

Do you want this procedure to quit on non-fatal errors? [y/n: n]n

At this point, we have to construct a list of this domains YP servers.
raf2 is already known as master server.
Please continue to add any slave servers, one per line. When you are
done with the list, type a <control D>.
        master server   :  le_nom_de_votre_serveur
        next host to add:  localhost
        next host to add:  ^D
The current list of NIS servers looks like this:

raf2
localhost

Is this correct?  [y/n: y] y
Building /var/yp/mon_domaine/ypservers...
Running /var/yp/mon_domaine/Makefile...
updated passwd
updated group
updated hosts
couldn't find /etc/ethers
updated networks
updated rpc
updated services
updated protocols
updated netid
couldn't find /etc/netgroup
couldn't find /etc/amd.master
updated aliases

le_nom_de_votre_serveur has been setup as an YP master server without any errors.

Voila ce que vous devriez obtenir (ou quelque chose d approchant). Les bases NIS etant maintenant initialisées, nous pouvons lancé le service NIS (s assurer que le demon 'portmap' tourne avant).

$ portmap
$ ypserv

et voila; on peut maintenant tester si tout marche bien.

$ ypbind          # lance le service NIS client
$ ypcat passwd    # par exemple; doit vous retourner le contenu
                  # du fichier passwd + les passwords

On note au passage que les shadow-password ne serve plus a rien puisqu'un simple utilisateur peut obtenir le password crypté d'un utilisateur :(

Le service NIS est lancé automatiquement lancé au démarage sous OpenBSD quand le répertoire /var/yp/binding/ existe ce qui est le cas maintenant, donc rien à faire de plus. Les démons ypserv et ypbind seront automatiquement lancés, par contre le démon rpc.yppaswdd est aussi lancé en même temps, ce qui va nous poser un probleme pour la suite. Ce démon permet le changement de mot de passe (et des informations GECOS et shell d'un utilisateur) à distance. Nous ne voulons pas autoriser ce genre de chose (voir pourquoi dans la suite). Editons donc le fichier /etc/rc.conf et mettre

...
yppasswdd_flags=" -nogecos -nopw"
...

et au passage pour la suite des operations

...
portmap="YES"
nfs_server="YES"
nfsd_flags="-tun 4"
...

NFS :

Le service NFS permet de partager des repertoires sur les reseaux; en clair il permet d exporter des files systems que des clients pourront monter de maniere transparente à travers le réseau. Ici pas grand chose à faire. Nous voulons exporter /Home ou nous allons stocker les repertoires privés des utilisateurs (/Home pour ne pas melanger avec /home des utilisateurs locaux). Editons le fichier /etc/exports qui contient les repertoires à exporter et ajoutons :

/Home -alldirs 192.168.0

Le premier parametre specifie le repertoire à exporter; le deuxieme parametre -alldirs dit que nous pourrons monter tout les repertoires contenus dans /Home (typiquement on voudra monter /Home/user1; le repertoire privé de l'utilisateur user1). Le dernier paramétre spécifie le sous-réseau dont les machines sont autorisés à se connecter (ici le reseau local 192.168.0.0/24).

Il est à noter qu'il doit s'agir d'un file-system monté sur /Home sinon nous exportons aussi la racine ce qui peut etre un probleme de sécurité. On peut maintenant lancer le démon NFS (on a déjà configuré le fait qu'il soit lancé au démarage) :

$ mountd
$ nfsd -tun 4

Si on veut tester que tout se passe bien on peut creer un répertoire dans /Home et le monter en local :

$ mkdir /Home/plop
$ mount le_nom_de_votre_serveur:/Home/plop /mnt

Voila pour NFS.

Automontage (AMD) :

Tout ceci est tres bien mais cela obligerai chaque machine client à monter le répertoire /Home du serveur à chaque démarage. Une meilleure solution serait de monter le répertoire privé de l'utilisateur au moment ou il y accéde. L'automounter est la justement pour ca. Note au passage, nous utilisons AMD le démon d'automontage BSD et pas le couple automount/autofs car ce dernier est plus specifique alors qu'AMD existe partout (à ma connaissance).

Il faut bien comprendre à ce stade que ce sont les machine clientes sous Unix qui vont lancer le démon amd(le démon pour l automontage BSD).

Néanmoins nous voulons controler la configuration de ces démons depuis le serveur. Et la NIS va encore nous aider. Il existe deja une map amd.master qui est cree à partir du fichier /etc/amd/amd.master. Nous allons rajouter une map qui s appelera amd.home. Pour cela nous editons le fichier /var/yp/Makefile.yp en prennant comme modele la map amd.master. Il suffit de recopier tout ce qui se rapporte à amd.master (en changeant amd.master par amd.home ;) :

...
all: passwd group hosts ethers networks rpc services protocols netid netgroup amd.home amd.master aliases
...

...
amd.home.time: $(AMDDIR)/amd.home
        -@if [ -f $(>) ]; then \
                $(SED) -e "s/#.*$$//" -e "/^$$/d" $(>) | \
                $(AWK) '{ \
                            for (i = 1; i <= NF; i++) \
                                if (i == NF) { \
                                    if (substr($$i, length($$i), 1) == "\\") { \
                                        printf("%s", substr($$i, 1, length($$i)
- 1)); \
                                    } \
                                    else \
                                        printf("%s\n", $$i); \
                { print $$1, $$0} \ - | $(MAKEDBM-S) - master.passwd.byname; \
                                else \
                                    printf("%s ", $$i); \
                        }' | \
                $(MAKEDBM) - amd.home; \
                $(TOUCH) $(@); \
                $(ECHO) "updated amd.home"; \
                if [ ! $(NOPUSH) ]; then \
                        $(YPPUSH) -d $(DOMAIN) amd.home; \
                        $(ECHO) "pushed amd.home"; \
                else \
                        : ; \
                fi \
        else \
                $(ECHO) "couldn't find $(>)"; \
        fi
...
amd.home: amd.home.time
...
$(AMDDIR)/amd.home:
...

Rajouter aussi amd.home dans /var/yp/Makefile et dans /var/yp/Makefile.main. Copier /var/yp/Makefile.yp vers /var/yp/mon_domaine/Makefile

$ cp /var/yp/Makefile.yp /var/yp/mon_domaine/Makefile

Nous allons maintenant créer et editer les fichiers /etc/amd/amd.master et /etc/amd/amd.home.

/etc/amd/amd.master :

/Home   amd.home

/etc/amd/amd.home :

/defaults type:=nfs;rhost:=le_nom_de_votre_serveur
*         rfs:=/Home/${key}

Explication : le fichier amd.master defini sur les clients Unix les repertoires qui seront geres par AMD (ici seulement le repertoire /Home mais on pourrait en rajouter) et le fichier de configuration associé (ici amd.home). Le fichier amd.home est defini de tel sorte que quand on voudra à acceder à un répertoire dans /Home il sera automatiquement monté en NFS depuis le serveur NFS. Cette maniere est tres flexible car si on veut modifier la configuration (rajouter un partage par exemple) on a juste à modifier les fichiers sur le serveur. Ne pas oublier de reconstruire la base NIS à chaque modif :

$ cd /var/yp
$ make

La partie configuration du serveur pour les clients Unix et maintenant fini, nous allons nous attaquer à la gestion des clients Win2k.

Samba :

Samba est une implémentation open-source sous Unix des services réseaux Microsoft ! C'est un logiciel complet bien qu'en dévelopement constant. Samba va pouvoir simuler le fonctionnement d'un PDC sur notre serveur. Un PDC permet l'authentification des utilisateurs de maniére centralisé pour des clients Windows. Samba permet aussi le partage de répertoire (donc les répertoires privés de nos utilisateurs).

Premiere chose à faire recuperer l'archive de Samba sur http://samba.org (samba2.2.4 à l'heure ou j'ecris ces lignes). On compile et on installe Samba :

$ tar xvzf samba-2.2.4.tar.gz
$ cd samba-2.2.4/source/
$ ./configure; make ; make install

Samba s'installe par défaut dans /usr/local/samba/ (c'est tres bien à mon gout).

La configuration de Samba se fait via l'intermédiaire du fichier /usr/local/samba/lib/smb.conf.

Voila ce qu'il doit contenir :

; smb.conf PDC 4 win2k
[global] 
 
;nom du serveur
netbios name = le_nom_du_serveur
 
;nom du domaine
;le meme que le domaine NIS pour simplifier
workgroup = mon_domaine
 
;description du serveur
server string = mon bo serveur
 
;on autorise toutes les machines du reseau local
;a se connecter 
hosts allow = 192.168.0.
 
;chaque utilisateurs doit avoir
;un compte sur le serveur SMB
;c plus pratique pour un PDC ;)
security = user
 
;divers params
guest account = nobody
log file = /var/log/smbd.%m
max log size = 50
socket options = TCP_NODELAY 
dns proxy = no 
preserve case = yes
short preserve case = yes
 
;on encrypte les pass
;obligatoire avec win2k
encrypt passwords = yes
 
;on est un PDC donc...
local master = yes
domain master = yes 
domain logons = yes
os level = 64
 
;les differents path pour les 
;profiles, netlogon, etc...
logon script = net.bat
logon path = \\%L\homes\Profiles\
logon drive = H:
logon home = \\%L\homes\
 
;on synchronise les passwd
;SMB et les passwd UNIX
;on update via un script les bases NIS
unix password sync = yes
passwd program = /usr/bin/npasswd %u
passwd chat = *password* %n\n *password* %n\n 
 
[homes]
comment = Home Directories
browseable = no
writable = yes
 
 
[netlogon]
comment = Network Logon Service
path = /usr/local/samba/netlogon
writable = no
 
 
[Profiles]
path = /usr/local/samba/profiles
writeable = yes
create mask = 0600
directory mask = 0700
 
 
[store]
comment = Temporary file space
path = /tmp/
read only = no
public = yes
guest ok = yes
browseable = yes

On cree ensuite le répertoire /usr/local/samba/netlogon et le fichier net.bat :

$ mkdir /usr/local/samba/netlogon

net.bat :

net use T: \\le_nom_du_serveur\store
net time \\raf2 /SET /YES

! Attention ce fichier doit etre au format MSDOS… Donc de preference le creer sous Windows avec Notepad :(

On peut maintenant lancer Samba :

$ /usr/local/samba/bin/smbd
$ /usr/local/samba/bin/nmbd

au passage si on veut que Samba se lance au démarage on peut rajouter ces 2 memes lignes à la fin du fichier /etc/rc.local.

Samba utilise sa propre base de compte utilisateur, et de mot de passe. Samba stocke ces informations dans le fichier /usr/local/samba/private/smbpasswd et se manipule via le programme /usr/local/samba/bin/smbpasswd.

La prochaine chose à faire est d'ajouter un utilisateur root à Samba. Ceci est nécessaire pour l'ajout d'une machine cliente au domaine.

$ /usr/local/samba/private/smbpasswd -a root

Attention il faut rentrer un mot de passe différent de celui du compte root Unix pour des raisons de sécurité.

Ensuite il faut créer des trusts accounts. Il est nécessaire d'avoir un compte par machine cliente Windows. Ces comptes doivent avoir le nom de la machine terminé par un $. Attention le compte Unix doit exister pour que Samba puisse ajouter un compte dans sa base. La ou cela se complique c'est que les scripts useradd (ou adduser) sous OpenBSD ne peuvent pas ajouter d'utilisateur dont le nom se termine par un $ :( Le plus simple alors etant alors de creer le compte sans le $ et de le rajouter a la main avec vipw.

Soit une machine cliente Windows dont le nom est toto (le nom Netbios de la machine; rien a voir avec le nom DNS).

$ useradd -p * -b /nonexistent -s /sbin/nologin toto
$ vipw  # on rajoute le $ a la fin de toto !
$ /usr/local/samba/private/smbpasswd -m toto

On voit bien que cette methode est relativement fastidueuse, surtout si on a beaucoup de machines clientes. Il existe une solution néanmoins c'est d'utiliser le parametre 'add user script' du fichier smb.conf (voir man smb.conf). Le script reste à écrire (il vous reste donc un peu de travail).

Un autre probleme est la synchronisation des mots de passe. Quand un utilisateur change de mot de passe depuis Windows pas de probleme car on a configuré Samba pour mettre à jour automatiquement les mots de passe NIS : c'est les parametres

unix password sync = yes
passwd program = /usr/bin/npasswd %u
passwd chat = *password* %n\n *password* %n\n 

du fichier smb.conf. Le script /usr/bin/npasswd cree à l'occasion permet d'updater directment les bases NIS apres changement du mot de passe Unix.

script /usr/bin/npasswd :

#!/bin/sh
pass_status=`/usr/bin/passwd $1`
 
if [ "$pass_status" = "Changing local password for $1." ];then
    cd /var/yp
    make >/dev/null 2>/dev/null
    #echo "Password changed"
    exit 0
else
    #echo "Password unchanged"
    exit 1
fi

Par contre lorsqu'un utilisateur voudra changer son password depuis Unix se pose un probleme. En effet on ne peut pas utiliser passwd -y car dans ce cas le mot de passe Samba ne serait pas updater. C'est pour cela que l'on à desactivé cette fonctionalité de rpc.yppasswdd. La solution est d'utiliser le programme smbpasswd qui permet de changer le mot de passe samba depuis Unix (en fait comme on l aurait fait sous Windows). La syntaxe est pour un utilisateur :

$ /usr/local/samba/bin/smbpasswd -r le_nom_du_serveur 

Il peut etre aussi utile de creer un alias vers passwd pour ne embrouiller les utilisateurs dans le script .cshrc (ou autre chose suivant le shell) du repertoire skel.

alias passwd '/usr/local/samba/bin/smbpasswd -r le_nom_du_serveur'

Bon il nous reste maintenant qu'a rajouter des utilisateurs. Les homes directories se trouvent dans /Home. On cree un groupe netuser pour rassembler ces utilisateurs (enfin apres c'est votre cuisine interne).

$ mkdir /Home
$ groupadd netuser

Comme on est faineant on cree un petit script pour ajouter automatiquement un utilisateurs dans NIS et SAMBA.

script /usr/sbin/addnetuser :

#!/bin/sh
# default pass is "azertyu1op"
 
 
if [ $# -ne 1 ];then
        echo "addnetuser 2002 - Mazelier Raphael(c)"
        echo "usage : ./addnetuser username"
        exit 1;
fi
 
 
/usr/sbin/useradd -p \$2a\$06\$tR7GJJyDuUmOSSqB9hdCwehcAkB53eZCet/ZW1asyuOwTmRq6k3N. -s /bin/csh -d /Home/$1 -m -g netuser -k /etc/netskel $1
useradd_status=$?
 
if [ $useradd_status -eq 0 ];then
        cd /var/yp
        make >/dev/null
        /usr/local/samba/bin/smbpasswd  -a $1 azertyu1op
        echo "User $1 succesfully added"
        exit 0
else
        echo "User $1 unsuccesfully added"
        exit 1
fi

On oublie pas de mettre les droits qui vont bien. Hop on peut donc ajouter des utilisateurs de tests :

$ addnetuser test1
$ addnetuser test2

On peut facilement créer le script correspondant pour deleter un user. La configuration du serveur est maintenant fini; ouf ! On peut passer à la configuration des clients ce qui sera beaucoup plus rapide heuresement.

Si vous m'avez suivi jusqu'ici ca ne devrait pas vous poser trop de probleme.

Configuration des clients :

Client FreeBSD :

Sur une machine cliente FreeBSD on a besoin de NIS client, de NFS client et du démon AMD. Toute la configuration peut se faire en éditant le fichier /etc/rc.conf :

nis_default_domain="mon_domaine"
nis_client_enable=YES
nfs_client_enable=YES
amd_enable=YES
amd_map_program=" 'ypcat -k amd.master' "

Si vous m'avez suivi jusqu'ici ca ne devrait pas vous poser trop de probleme. On peut ensuite rebooter et ensuite tester une connexion avec l'utilisateur net1. On peut aussi essayer le changement de password avec la commande passwd.

Si vous m'avez suivi jusqu'ici ca ne devrait pas vous posez trop de probleme.

Client Linux, Solaris ou autres unix :

Le principe est le meme que sous FreeBSD; il faut activer NIS , NFS (partie cliente), et AMD. Pour amd il faudra surement l'installer voir www.am-utils.org. On peut aussi essayer de ruser en utilisant autofs/automount ou il est disponible et des maps NIS differentes (genre auto.master et auto.home).

Client Win2k :

Il faut joindre le domaine NT mon_domaine. Je ne detaille pas la manip ici (c'est trivial). Le seul point à noter c'est lorqu'on vous demande le nom d'un compte autorisé il faut mettre root et le password associé (le password Samba pas unix !). Si tout c'est bien passé Windows affiche un joli PopUp : machine joined mon_domaine succesfully ou quelque chose du genre. On peut rebooter ensuite et tester de se loguer avec le compte net1 ou net2 precedement crée.

Conclusion :

Cette méthode pour faire une gestion “unifiée” des utilisateurs à le merite de marcher. Elle est par contre absolument pas sécurisé du fait de l'emploi de NIS par exemple. On peut envisager de remplacer NIS par NIS+. Tout ceci fait un peu bricolage; il y a d autre solutions basées sur LDAP ou sur pam_smb par exemple. A suivre donc.

Vous pouvez me contacter à raf@ztrip.ath.cx pour tout renseignement, commentaire, ajout constructif !

-raf-

unix/samba_nis.txt · Last modified: 2010/01/12 13:29 (external edit)