Bonjour,
Je migre une grosse application d'un vieux serveur RHEL3 vers RHEL9.
L'appli a été adaptée, réécrite, .. il reste à la faire interagir avec son environnement client.
Et en particulier 2 tâches, samba pour partage de fichier, et "résolution" pour identifier le client.
Contexte :
Un domain "maboite.com" avec un AD sous Windows (DNS, DHCP, ..) "vm-ad.maboite.com"
Un Linux RHEL9 qui héberge l'application
Des clients qui se connectent :
* soit en ssh, pour accéder à l'appli
* soit en partage de fichier (chemin réseau sur des PC Windows), afin de fournir des fichiers de travail à un module de l'appli
Chaque utilisateur (qui navigue dans la boite et se connecte à l'appli sur différents PC répartis dans l'usine) connecté en ssh utilise des ressources (imprimantes, robot, machine outil, ..) en fonction de l'endroit où il est, et en particulier au nom du PC sur lequel il se connecte.
Sur le vieux RHEL3, la résolution de nom permet de savoir sur quel PC il a ouvert une session ssh sur cette appli.
Sur le nouveau RHEL9, l'instruction "who am I" répond l'adresse IP, qui change en fonction du DHCP…
Malgré 1 mois à m'arracher les cheveux et lire des centaines de docs et forums, tutos et autres manuels "officiels"… très peu d'info sur cela.
Détails :
winbind est connecté à l'AD, le "login" (ouverture de session sur l'appli) se fait bien avec les identifiants AD (même si smb est arrêté).
Le fait de lancer smb a une influence sur le partage de fichiers, mais aucune incidence sur la résolution de nom.
Question : quel outil gère la résolution de nom ? Winbind ? Nsswitch ? Samba ?
Quel paramètre de quel outil faut-il activer (/paramétrer) pour faire fonctionner cette résolution.
Merci beaucoup à toute info sur ce labyrinthe.
# à verifier sur ton RHEL
Posté par NeoX . Évalué à 6 (+3/-0). Dernière modification le 05 novembre 2025 à 19:18.
en faisant une recherche avec ton probleme sur mon moteur de recherche favori
sinon, ben c'est un RHEL donc soumis à licence, tu paies des licences expres, donc tu as droit de demander du support à RedHat :D
[^] # Re: à verifier sur ton RHEL
Posté par jomi49 . Évalué à 1 (+0/-0).
@NeoX : Merci de ta réponse.
Concernant RHEL, effectivement il faudrait inscrire le serveur sur le support (ce n'est pas le cas aujourd'hui). Je vais voir ça avec mon chef…
Quant aux systèmes configurés, je confirme, je ne comprends pas tout sur les briques krb5, sssd, winbind, realm, … Il me semble avoir compris que la couche la plus basse est krb5. Ensuite sssd et winbind sont 2 système "coucurrents" qui "utilisent" krb5. J'ai testé avec sssd, mais j'ai perdu la possibilité de se connecter sur Linux avec les identifiants AD. Alors qu'avec winbind ça marche assez facilement. Et Samba est indépendant, s'appuie sur les autres systèmes, et permet "juste" de partager des répertoires Linux… et pour moi realm est une instruction pour configurer winbind…
En gros, c'est un joli saladier :)
# Le DNS
Posté par WhiteCat . Évalué à 3 (+1/-0). Dernière modification le 05 novembre 2025 à 23:08.
Je suis pas sûr d'avoir bien compris le fonctionnement de ton système, mais pour répondre à :
C'est le DNS qui va te répondre. Il faut juste que ton client interroge le DNS…
Normalement dans ta config réseau, tu dois définir un serveur DNS.
Et c'est dans nsswitch que tu peux définir vers quoi les résolutions de noms doivent être faites en priorité, généralement /etc/hosts, puis DNS, etc.
Selon les distributions (c'est pas le cas sur RHEL normalement, mais sur Fedora oui) il y a parfois le mDNS qui est fait avant le DNS, ce qui peut poser problème dans les domaines Windows stupidement nommés en .local
[^] # Re: Le DNS
Posté par jomi49 . Évalué à 1 (+0/-0). Dernière modification le 06 novembre 2025 à 13:40.
Merci de l'info.
Mais le fichier de config du nsswitch est incompréhensible pour moi.
que sont "ethers", "shadow", "rpc", "services", "publickey" ??
Pour moi j'ai :
* shadow : files
* networks: files dns
* aliases: files
* hosts: files dns myhostname
entre autres …
PS: sur mon "ancien" systeme, j'ai
* shadow : files ldap
* networks: files
* aliases: nisplus
* hosts: files dns
[^] # Re: Le DNS
Posté par MicP . Évalué à 2 (+1/-0). Dernière modification le 06 novembre 2025 à 14:37.
Bonjour jomi49
Tu devrais lire le manuel du fichier de configuration
nsswitch.confqui s'affichera en lançant la ligne de commande suivante :
… et dans ce royaume, ceux qui y voient un peu plus clair sont parfois très mal vus.
[^] # Re: Le DNS
Posté par jomi49 . Évalué à 1 (+0/-0).
Oh, bien évidemment que j'ai lancé cela, vieux réflexe linuxien…
Malheureusement, ça ne m'éclaire pas beaucoup…
entre hosts: files dns
et hosts: files ldap
… de là à comprendre qui s'occupe de la résolution de nom …
[^] # Re: Le DNS
Posté par WhiteCat . Évalué à 2 (+0/-0). Dernière modification le 06 novembre 2025 à 20:32.
La ligne "hosts" est la ligne qui va définir comment les résolutions de noms se font sur le système.
Les paramètres sont pris en priorité par ordre d’apparition.
Donc par exemple pour la ligne "hosts: files dns", la résolution va d'abord vérifier via le système "files" (ça correspond au fichier /etc/hosts pour être plus clair :-) ), puis s'il ne trouve rien dans "files", il va regarder dans le système "dns".
Au final, pour la résolution DNS en tant que telle, ça n'a pas vraiment de lien avec ton Samba/Winbind, etc.
[^] # Re: Le DNS
Posté par jomi49 . Évalué à 1 (+0/-0).
Merci à toi.
C'est bien les conclusions auxquelles j'arrive aussi.
mais visible, il ne suffit pas d'écrire "hosts:files dns" pour que ça marche… Comme dans le jeu Siberia "Il manque quelque chose pour que ça fonctionne" :)
Je pars en WE, et je me remets à cette tâche mercredi.
[^] # Re: Le DNS
Posté par NeoX . Évalué à 3 (+0/-0).
ca veut dire que la machine linux va d'abord chercher dans /etc/hosts avant de faire une requete au DNS qui aurait besoin de resoudre un NOM de machine vers une IP
dans ton cas, ce n'est probablement pas le cas
ton client (ordi eleve) qui va se connecter sur le partage, arrive avec ses options, et c'est par celles-ci que tu dois recuperer le nom du client
# il faut utiliser adcli pour la configuration de sssd
Posté par sagoum . Évalué à 1 (+0/-0).
pour moi il faut faire un truc du genre, cf doc redhat
https://access.redhat.com/solutions/2653771
export LDAPTLS_CACERT=CA_certificate_file_path
adcli info ad.example.com
adcli join --use-ldaps ad.example.com -U <username> --verbose
adcli update --use-ldaps -v
par exemple, si tu veux par exemple te connecter avec le nom d'utilisateur sans indiquer le domaine il faut mettre "use_fully_qualified_names = false"
https://access.redhat.com/solutions/6931691
[^] # Re: il faut utiliser adcli pour la configuration de sssd
Posté par jomi49 . Évalué à 1 (+0/-0).
Bonjour,
J'avais fait qq tentatives avec cela. Mais tout ça c'est du sssd. Et je n'ai pas vraiment insisté avec, je me suis orienté vers winbind… (qui marche très bien pour ce qui est login des users par l'AD)…
Je continue mes tests… et mes recherches.
# Documentation RedHat
Posté par Pierre-Alain TORET (Mastodon) . Évalué à 2 (+1/-0).
Salut,
tu peux peut-être tenter de regarder dans https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/integrating_rhel_systems_directly_with_windows_active_directory/index
Pour répondre à ton interrogation, la documentation commence par
SSSD et Windbind sont donc deux alternatives concurrentes pour réaliser la même chose : rejoindre un domaine porté par un Active Directory.
Pour la résolution de nom, c'est normalement nsswitch qui est à configurer pour décider dans quel ordre les différentes alternatives sont interrogées (fichier /etc/hosts, résolveur, etc.)
Sinon il y a d'autres documentations sur https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9
[^] # Re: Documentation RedHat
Posté par jomi49 . Évalué à 1 (+0/-0).
Bonjour, et tout d'abord merci de cette réponse.
Effectivement j'ai vite vu que sssd et winbind font à peu près pareil, winbind étant "livré" avec samba. J'ai tenté de désactiver winbind et joindre mon domaine avec sssd… Réaction immédiate, les utilisateurs ne pouvaient plus se connecter avec leurs identifiants AD. J'ai cherché un peu, puis j'ai fini par couper sssd et refaire le "join" avec winbind, ça a remarché.
Je suis maintenant convaincu que c'est le nsswitch qui fait le job (et qui s'appuie sur krb5), mais le seul fait de mettre "hosts:dns" ne suffit visiblement pas.
Quand je fais juste "who am i", c'est mon adresse IP qui s'affiche, alors je j'aimerais le n° du PC.. Donc non seulement il faut écrire "hosts:dns", mais il faut probablement lui préciser qui est "dns"… Pourtant il le sais puisque les utilisateurs peuvent se connecter avec leurs identifiants AD…
… ou alors il faut préciser quelques part les différents éléments de l'AD (OU, utilisateurs, DNS, DHCP, ..)
[^] # Re: Documentation RedHat
Posté par MicP . Évalué à 2 (+1/-0).
Je n'utilise pas RHEL9 et n'ai pas accès à la réponse proposée dans cette page web, mais tu y as peut-être accès :
https://access.redhat.com/solutions/3152101
Je ne sais pas de quel N° il s'agit, mais s'il s'agit d'un numéro qui serait contenu dans le nom d'hôte du système, tu pourrais peut-être utiliser la commande
hostnameou alors avec la commande
hostnamectl… et dans ce royaume, ceux qui y voient un peu plus clair sont parfois très mal vus.
[^] # Re: Documentation RedHat
Posté par WhiteCat . Évalué à 4 (+2/-0).
Ça dit qu'il faut bien s'assurer que l'option "UseDNS YES" de SSHd soit configurée.
[^] # Re: Documentation RedHat
Posté par Pierre-Alain TORET (Mastodon) . Évalué à 3 (+2/-0).
Je confirme que l'ajout de l'option UseDNS à yes dans sshd_config permet bien d'obtenir un nom au lieu d'une ip. Testé dans Fedora.
[^] # Re: Documentation RedHat
Posté par jomi49 . Évalué à 2 (+1/-0).
Oh magique.
Ca marche !
Il suffit de "décommenter" cette option dans le fichier /etc/ssh/sshd_config, et mettre yes….
… puis un systemctl restart sshd !
C'est vraiment magique, quel bonheur de s'adresser à des experts.
Et dire que je galère depuis plusieurs mois dans les samba, les sssd, les winbind, les krb5, les …
Et je reconnais humblement de mon côté que je n'ai pas accès à ce support, parce que notre machine n'est pas enregistrée. Et que souvent ça me manque car je suis convaincu que beaucoup de réponses s'y trouvent.
Merci donc à tous les contributeurs, et en tout particulièrement à WhiteCat qui a donné la réponse décisive.
[^] # Re: Documentation RedHat
Posté par sagoum . Évalué à 2 (+1/-0).
il existe la "redhat developer subscription" qui est gratuite et te permet d'avoir une license pour quelques serveurs, et permet aussi l’accès à toute la doc redhat.
SI tu fais du redhat sans accéder aux doc redhat, ca ne doit pas etre facile…
# sécu
Posté par santevvv . Évalué à 1 (+0/-0).
Et niveau sécu vous en pensez quoi ?
[^] # Re: sécu
Posté par Voltairine . Évalué à 2 (+0/-0).
La sécu c'est bien, en abuser ça craint.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.