AD : intégration Linux - Historique des versions

Justine le 22 juin 2022 à 11:53

2022-06-22T11:53:20Z

← Version précédente		Version du 22 juin 2022 à 11:53
Ligne 1 :		Ligne 1 :
			[[Category:windows]]
	= Description des opérations =		= Description des opérations =

Justine : /* Samba */

2022-03-01T19:52:11Z

Samba

← Version précédente		Version du 1 mars 2022 à 19:52
Ligne 291 :		Ligne 291 :

	Un autre exemple, avec wsdd2 d'installé pour la découverte sous Windows (la partie "nas" fonctionne même sans ça). J'ai simplement activé l'utilisatrice "justine" avec un "smbpasswd -a justine".		Un autre exemple, avec wsdd2 d'installé pour la découverte sous Windows (la partie "nas" fonctionne même sans ça). J'ai simplement activé l'utilisatrice "justine" avec un "smbpasswd -a justine".
	<source>		<source lang="bash">
	[global]		[global]
	workgroup = WORKGROUP		workgroup = WORKGROUP
Ligne 330 :		Ligne 330 :
	valid users = justine		valid users = justine
	</source>		</source>

			Et la ligne de fstab qui va avec pour le monter sur le client.
			//192.168.1.200/nas /home/justine/Storage cifs _netdev,users,noauto,users,credentials=/home/justine/.smb 0 0
			Celui-ci a dans son home un fichier .smb qui contient user et password:
			user=justine
			password=prout

	==== Ouvrir simplement un partage samba en ligne de commande ====		==== Ouvrir simplement un partage samba en ligne de commande ====

Justine : /* Samba */

2022-03-01T19:50:15Z

Samba

← Version précédente		Version du 1 mars 2022 à 19:50
Ligne 290 :		Ligne 290 :
	</source>		</source>

			Un autre exemple, avec wsdd2 d'installé pour la découverte sous Windows (la partie "nas" fonctionne même sans ça). J'ai simplement activé l'utilisatrice "justine" avec un "smbpasswd -a justine".
			<source>
			[global]
			workgroup = WORKGROUP
			log file = /var/log/samba/log.%m
			max log size = 1000
			logging = file
			panic action = /usr/share/samba/panic-action %d
			server role = standalone server
			obey pam restrictions = yes
			unix password sync = yes
			passwd program = /usr/bin/passwd %u
			passwd chat = Enter\snew\s\spassword:* %n\n Retype\snew\s\spassword:* %n\n password\supdated\ssuccessfully .
			pam password change = yes
			map to guest = bad user
			usershare allow guests = yes

			#Wsdd2, openly share to windows
			netbios name = NASSQLAN

			wins support = yes
			local master = yes
			preferred master = yes
			lanman auth = no
			ntlm auth = yes
			client lanman auth = no

			[nas]
			comment = home share
			path = /data
			browsable = yes
			create mask = 0644
			directory mask = 0775
			writable = yes
			guest ok = no
			public = no
			available = yes
			read only = no
			valid users = justine
			</source>
	==== Ouvrir simplement un partage samba en ligne de commande ====		==== Ouvrir simplement un partage samba en ligne de commande ====

Justine le 9 février 2022 à 11:10

2022-02-09T11:10:17Z

← Version précédente		Version du 9 février 2022 à 11:10
Ligne 516 :		Ligne 516 :

	join.sh connor		join.sh connor

			== Alternative : partager un dossier avec un groupe AD ==

			La procédure ci-dessus semble effective et semble aussi plus "propre" (même si je ne l'ai pas testée depuis longtemps); mais après quelques arrachages de cheveux, voici une autre configuration établie dans le but de partager un dossier, dans lequel les seules personnes ayant accès seraient celles positionnées dans un groupe Active Directory (ici, groupe_allowed situé dans domaine.tld, pour l'exemple).

			Configuration de Samba, basée sur winbind. Pourquoi Winbind ? Je ne sais pas, si ce n'est que ça fonctionne.

			<source>
			# See smb.conf.example for a more detailed config file or
			# read the smb.conf manpage.
			# Run 'testparm' to verify the config is correct after
			# you modified it.

			[global]
			log file = /var/log/samba/%m.log
			security = ads
			realm = DOMAINE.TLD
			workgroup = AUTH
			preferred master = no

			idmap uid = 10000-20000
			idmap gid = 10000-20000
			winbind enum users = yes
			winbind enum groups = yes
			template homedir = /home/%D/%U
			template shell = /bin/bash
			client use spnego = yes
			client ntlmv2 auth = yes
			encrypt passwords = yes
			winbind use default domain = yes
			winbind separator = +
			restrict anonymous = 2

			[partagepourmongroupe]
			comment = Espace de partage
			path = /chemin/du/dossier
			browsable = yes
			writable = yes
			public=yes
			valid users = @"DOMAINE+groupe_allowed"
			guest ok = yes
			read only = no
			create mask = 0766
			create directory mask = 0755
			</source>

			Après cela, il faut rejoindre le domaine : regarder la configuration plus haut dans cet article, ainsi que le contenu du script utilisé pour rejoindre le domaine.

			Une fois le domaine joint, samba redémarré et en place, il subsiste un problème : les utilisateurs n'ont quand même pas accès au partage. En effet, si samba les laisse entrer, leur nom et leur groupe sont inconnus au bataillon, et un "chmod 777" ni changera rien. J'imagine que cela pourrait se régler par une ligne "force user = root" dans la configuration Samba, mais on peut faire mieux que ça.

			On va positionner une acl sur le dossier partagé pour que celui-ci accepte de laisser les utilisateurs du groupe agir sur le dossier.

			<source>
			setfacl -Rm d:g:"DOMAIN+groupe_allowed":rwx /chemin/du/dossier
			</source>

			Cette commande sert, donc, à positionner des acls (qui ne sont pas une notion couramment utilisée sur Linux...). Pour le détail:
			* -R : récursif
			* -m : mask : recalculer les droits (je crois)
			* d:g:groupe:rwx : default (d) groupe (g) gid/nom du groupe suivi des permissions (rwx)

Justine : /* Samba */

2020-02-03T13:03:43Z

Samba

← Version précédente		Version du 3 février 2020 à 13:03
Ligne 289 :		Ligne 289 :
	systemctl enable smbd		systemctl enable smbd
	</source>		</source>

			==== Ouvrir simplement un partage samba en ligne de commande ====

			apt-get install cifs-utils
			mount -t cifs //FILE-SERVER-IP-ADDRESS/public /local/mountpoint -o user=utilisateur

	=== SSSD ===		=== SSSD ===

Justine : /* SSSD */

2019-11-15T17:13:48Z

SSSD

← Version précédente		Version du 15 novembre 2019 à 17:13
Ligne 301 :		Ligne 301 :
	Il va commencer par balancer des erreurs; en effet, il n'as pas de fichier de config et n'as pas non plus de domaine configuré.		Il va commencer par balancer des erreurs; en effet, il n'as pas de fichier de config et n'as pas non plus de domaine configuré.

	On créée le fichier suivant (appartient à root avec les droits 600) dans /etc/sssd:		On créée le fichier suivant (appartient à root avec les droits 600) dans /etc/sssd/sssd.conf:
	<source lang="bash">		<source lang="bash">
	[sssd]		[sssd]

Justine : /* SSSD */

2019-11-15T17:13:07Z

SSSD

← Version précédente		Version du 15 novembre 2019 à 17:13
Ligne 301 :		Ligne 301 :
	Il va commencer par balancer des erreurs; en effet, il n'as pas de fichier de config et n'as pas non plus de domaine configuré.		Il va commencer par balancer des erreurs; en effet, il n'as pas de fichier de config et n'as pas non plus de domaine configuré.

	On créée le fichier suivant (appartient à root avec les droits 600):		On créée le fichier suivant (appartient à root avec les droits 600) dans /etc/sssd:
	<source lang="bash">		<source lang="bash">
	[sssd]		[sssd]

Justine : /* Nssswitch */

2019-11-11T12:40:45Z

Nssswitch

← Version précédente		Version du 11 novembre 2019 à 12:40
Ligne 355 :		Ligne 355 :

	Quelques explications issues du man:		Quelques explications issues du man:
	</source>		<source>
	Le fichier de configuration du service de noms (« Name Service Switch » ou NSS),		Le fichier de configuration du service de noms (« Name Service Switch » ou NSS),
	/etc/nsswitch.conf, est utilisé par la bibliothèque C de GNU pour déterminer les sources		/etc/nsswitch.conf, est utilisé par la bibliothèque C de GNU pour déterminer les sources

Justine : /* Nssswitch */

2019-11-11T12:40:32Z

Nssswitch

← Version précédente		Version du 11 novembre 2019 à 12:40
Ligne 354 :		Ligne 354 :
	=== Nssswitch ===		=== Nssswitch ===

	~~{{Quote~~		Quelques explications issues du man:
	\|Le fichier de configuration du service de noms (« Name Service Switch » ou NSS),		</source>
			Le fichier de configuration du service de noms (« Name Service Switch » ou NSS),
	/etc/nsswitch.conf, est utilisé par la bibliothèque C de GNU pour déterminer les sources		/etc/nsswitch.conf, est utilisé par la bibliothèque C de GNU pour déterminer les sources
	desquelles obtenir les renseignements de service de noms en fonction des catégories, et		desquelles obtenir les renseignements de service de noms en fonction des catégories, et
Ligne 365 :		Ligne 366 :
	décrivent les sources, dans l'ordre des requêtes à réaliser, et un ensemble limité		décrivent les sources, dans l'ordre des requêtes à réaliser, et un ensemble limité
	d'actions possibles en fonction du résultat de la résolution.		d'actions possibles en fonction du résultat de la résolution.
	}}		</source>

	On vérifie le fichier /etc/nsswitch.conf pour que cela corresponde à:		On vérifie le fichier /etc/nsswitch.conf pour que cela corresponde à:

Justine : /* SSSD */

2019-11-11T12:39:56Z

SSSD

← Version précédente		Version du 11 novembre 2019 à 12:39
Ligne 292 :		Ligne 292 :
	=== SSSD ===		=== SSSD ===

	~~{{Quote~~		Le démon SSSD (de l'anglais, « System Security Services Daemon ») offre accès aux mécanismes d'identité et d'authentification distants, aussi dénommés fournisseurs. Il permet à ces fournisseurs d'être connectés en tant que serveurs SSSD, faisant abstraction de l'identité locale et réseau et des sources d'authentification, et permettant à tout type de fournisseur de données d'identité d'être connecté. Un domaine est une base de données contenant des informations sur l'utilisateur, qui peut servir de source pour les informations sur l'identité d'un fournisseur. De multiples fournisseurs d'identité sont pris en charge, permettant à deux serveurs d'identité, ou plus, d'agir en tant qu'espaces de noms d'utilisateurs séparés. Les informations rassemblées sont disponibles à toutes les applications de serveur frontal avec les interfaces PAM et NSS.
	~~\|text=~~Le démon SSSD (de l'anglais, « System Security Services Daemon ») offre accès aux mécanismes d'identité et d'authentification distants, aussi dénommés fournisseurs. Il permet à ces fournisseurs d'être connectés en tant que serveurs SSSD, faisant abstraction de l'identité locale et réseau et des sources d'authentification, et permettant à tout type de fournisseur de données d'identité d'être connecté. Un domaine est une base de données contenant des informations sur l'utilisateur, qui peut servir de source pour les informations sur l'identité d'un fournisseur. De multiples fournisseurs d'identité sont pris en charge, permettant à deux serveurs d'identité, ou plus, d'agir en tant qu'espaces de noms d'utilisateurs séparés. Les informations rassemblées sont disponibles à toutes les applications de serveur frontal avec les interfaces PAM et NSS.
	SSSD est exécuté en tant qu'ensemble de services, indépendamment des applications qui l'utilisent. Ainsi, ces applications n'ont plus besoin de créer leurs propres connexions à des domaines distants, ou même de savoir lequel (lesquels) est (sont) utilisé(s). La mise en cache locale robuste des informations d'identité et d'adhérence à un (des) groupe(s) permet d'effectuer des opérations peu importe d'où provient cette identité (par exemple, LDAP, NIS, IPA, DB, Samba, etc.), elle offre une performance améliorée, et permet à l'authentification d'être effectuée même lors d'opérations hors-ligne, et lorsque l'authentification en ligne est indisponible. SSSD permet aussi l'utilisation de multiples fournisseurs de même type (par exemple avec de multiples fournisseurs LDAP), ainsi qu'aux requêtes d'identité de domaines qualifiés d'être résolues par ces différents fournisseurs. De plus amples détails se trouvent dans le guide de déploiement Red Hat Enterprise Linux 6.		SSSD est exécuté en tant qu'ensemble de services, indépendamment des applications qui l'utilisent. Ainsi, ces applications n'ont plus besoin de créer leurs propres connexions à des domaines distants, ou même de savoir lequel (lesquels) est (sont) utilisé(s). La mise en cache locale robuste des informations d'identité et d'adhérence à un (des) groupe(s) permet d'effectuer des opérations peu importe d'où provient cette identité (par exemple, LDAP, NIS, IPA, DB, Samba, etc.), elle offre une performance améliorée, et permet à l'authentification d'être effectuée même lors d'opérations hors-ligne, et lorsque l'authentification en ligne est indisponible. SSSD permet aussi l'utilisation de multiples fournisseurs de même type (par exemple avec de multiples fournisseurs LDAP), ainsi qu'aux requêtes d'identité de domaines qualifiés d'être résolues par ces différents fournisseurs. De plus amples détails se trouvent dans le guide de déploiement Red Hat Enterprise Linux 6.
	~~\|author=~~https://access.redhat.com/documentation/fr-fr/red_hat_enterprise_linux/6/html/migration_planning_guide/ch07s02		https://access.redhat.com/documentation/fr-fr/red_hat_enterprise_linux/6/html/migration_planning_guide/ch07s02
	}}

	On commence par installer le daemon:		On commence par installer le daemon:

AD : intégration Linux - Historique des versions

Justine le 22 juin 2022 à 11:53

Justine : /* Samba */

Justine : /* Samba */

Justine le 9 février 2022 à 11:10

Justine : /* Samba */

Justine : /* SSSD */

Justine : /* SSSD */

Justine : /* Nssswitch */

Justine : /* Nssswitch */

Justine : /* SSSD */

Justine : /* Samba */

Justine : /* Samba */

Justine : /* Samba */

Justine : /* SSSD */

Justine : /* SSSD */

Justine : /* Nssswitch */

Justine : /* Nssswitch */

Justine : /* SSSD */