Linux et authentification AD - Page 1

redangel wanted to continue a side discussion in a new topic. Original discussion can be found in topic topics/132745-linux/253#post-7572 while drifted discussion continues in topic topics/190926-linux-et-authentification-ad where related posts have been copied.

Je suis en train de devenir fou au boulot (oui comme d'autres, je sais ).
Je chercher à:
-activer l'authentification AD sur un Ubuntu Server (18.04).

J'ai déjà réussi plusieurs fois (souvent en changeant plusieurs fichiers...) mais là j'y arrive pas J'ai pourtant suivi un paquet de tutos différents (le plus concis étant https://www.server-world.info/en/note?os=Ubuntu_18.04&p=realmd)
Enfin c'est pire que ça : après 1/2j j'avais réussi à le faire marcher, puis j'ai voulu ranger le Computer dans la bonne OU sur l'AD, ça a cassé l'authentification. J'ai essayé de tout refaire et bordel, ça veut plus marcher ! La machine s'enrolle dans l'AD, mais l'authentification SSH d'un compte se solde avec un "Access denied".
Est-ce que vous connaîtriez un site/ressource "simple" pour faire ça ? (et troubleshooter ? Je me perds dans les 10 fichiers de logs différents....) Je comprends pas pourquoi il y a 22 méthodes différentes pour faire un même truc, et pourquoi 1000 paramètres différents dans les fichiers de conf peuvent marcher ou non.

Ça fait bien trop longtemps que je n'ai pas fait ça :/ (c'était avec du Windows 2000 server et Samba 2.x, donc ça a probablement bien changé). Mais si tu ne veux que gérer l'authentification utilisateur (sans forcément avoir la machine enrôlée dans l'AD), tu ne peux pas simplement mettre en place une authentification LDAP ? Et si tu as des partages réseau à monter, tu peux le faire au travers de PAM.

Quelle authent’ AD ? À ma connaissance (je n’ai jamais fait de Windows), tu peux faire un bind LDAP, du NTLM (déconseillé) ou du Kerberos (le mieux).

Je pense que ce qu'il cherche à faire est d'utiliser les client Samba pour une intégration transparente et totale à l'AD (du coup, l'ordinateur se retrouve enregistré dans l'AD, et les utilisateurs se connectent au domaine en utilisant les mécanismes SMB sans se préoccuper du mécanisme d'authentification sous-jacent, c'est le client Samba qui s'occupe de toutes les négociations).

Nonon je pense bien à utiliser Kerberos (avec SSSD qui est sensé faire le café).
J'avoue que je ne connais vraiment pas la chaîne d'authentification entre ad, kerberos, pam, smb.

De ce que je trouve sur internet, normalement à l'installation du paquet krb5-user, il devrait me demander un domaine (dans une fenêtre CLI violette), or je n'ai jamais cette invit. Le fichier krb5.conf, même supprimé/purgé entre 2 essais, est systématiquement rempli avec le bon domaine (mais d'où il le sort ?????)

Arf, du coup je ne peux pas t'aider :/

Merci quand même
Tu conseillerais d'utiliser les mécanismes liés à Samba, plutôt ?

Ca existe un outil qui nettoie pam/nss/kerberos/ldap/smb ? J'aimerais retourner dans l'avant configurations, mais il y a des trucs en cache partout, je m'y perds... si c'était ma VM je la redéploierai, malheureusement c'est chez notre hébergeur

À tester, je n'ai suivi les évolutions après la version 2.6 que de très loin, et ça reste du boulot.
Je sais que j'irais plus naturellement vers ce que que je connais, et qui était la norme à l'époque de la version 2.6 de Samba (authentification LDAP avec pam_ldap avec un bind sur l'AD, montage des partages Windows avec le client Samba durant le processus d'authentification géré par PAM), mais je pense que les versions actuelles de Samba permettent de tout gérer de façon plus "naturelle", sans trop savoir comment t'aider, par contre :/

redangel (./7550) :
Ca existe un outil qui nettoie pam/nss/kerberos/ldap/smb ?

Tu ne peux pas réinstaller ces packages avec les fichiers de configuration par défaut ?

Ca n'ecrase que tres rarement les fichiers modifés. Apres il y a peut etre moyen de forcer suivant la distro

apt-get purge au lieu de remove ?

Très risqué mais a tester

Je suis pas sur que purger PAM soit une tres bonne idée

(désinstaller non plus ceci dit)

Oui parce qu'après, tu vas pouvoir faire "pam pam pam" sur la porte de la boite, mais il te dira "nope nope nope"

Au pire je demande de rollback un snapshot (ça en prend la direction d'ailleurs.... je vais devoir retirer la mention "*nix" de mon CV si ça continue... :'()

Nil (./7552):
Tu ne peux pas réinstaller ces packages avec les fichiers de configuration par défaut ?

Je cherche comment !

Godzil (./7553):
Ca n'ecrase que tres rarement les fichiers modifés.

Ca le dit par moment au milieu des messages, mais ça va tellement vite...

flanker (./7554):
apt-get purge au lieu de remove ?

-get est déprécié () mais oui, c'est ce que j'ai fait. Sur krb5* et sssd*, mais ça suffit pas.

Godzil (./7555):
Très risqué mais a tester

Je suis plus à ça près xD

Godzil (./7555) :
Très risqué mais a tester

Je suis pas sur que purger PAM soit une tres bonne idée

(désinstaller non plus ceci dit)

bah pour tout ce qui contient krb…

au fait, Heimdal ou MIT ? Je ne sais pas si les deux sont compatibles AD.

Au boulot, je travaille sur un projet où il y a une installation du gros bazar FreeIPA, qui tire plein de dépendances dont SSSD, pour monter une CA et l'auth Kerberos + LDAP, mais je ne peux probablement pas apporter d'aide efficace pour deux raisons:
* c'est pour CentOS, et je sais que FreeIPA est moins bien supporté hors des distros RH;
* je reste un utilisateur haut niveau de ce truc: la recette d'installation fonctionne bien, elle est même assez simple, mais ce n'est pas moi qui l'ai créée et qui ai passé du temps à chercher à droite et à gauche comment la faire fonctionner - je m'amusais avec d'autres problèmes de mon côté. Avec celui qui l'a faite, on a debuggé plusieurs fois des problèmes annexes ensemble (config NTP; en désespoir de cause, pour debugger une erreur générique "ça n'a pas marché côté serveur" pour laquelle les logs n'indiquaient rien, strace dans les processus lancés par Apache pour trouver quel était le worker concerné, ce qui nous a indiqué immédiatement que c'était un pauvre petit problème de droits sur un fichier...), mais je n'ai que peu mis les mains dans LDAP et Kerberos.

accessoirement, que veux-tu faire exactement ?
- que l'utilisateur s'authentifie en AD mode Kerberos pour sa session Gnome/KDE ? si oui, en mdp ou en PKCS11 ?
- que l'utilisateur ouvre un partage réseau Samba kerberisé ?
- que l'utilisateur récupère ses infos depuis l'AD mode LDAP ? (mais dans ce cas, si l'accès en lecture LDAP est lui-même kerberisé, il faut un keytab pour la machine et configurer correctement nslcd/nscd pour charger le keytab) ?

Première étape : installe un client Kerberos sur une machine, et il faut arriver à faire un kinit après avoir configuré /etc/krb5.conf.

Sinon, question bête et méchante : les machines sont-elles à l'heure ? Si tu n'as pas de ntp sur le réseau, oublie Kerberos ^^
Et quand tu utilises des services kerberisés, l'expérience m'a montré que le plus simple est de lancer strace pour voir les soucis.

flanker (./7558):
au fait, Heimdal ou MIT ? Je ne sais pas si les deux sont compatibles AD.

Bien que j'ai vu mention de ces 2 "technos" (??) sur les divers liens visités, tu me parles quand même chinois Je ne sais pas, moi, je chercher juste à m'authentifier à partir d'un AD 2012. Tout est possible.

Lionel Debroux (./7559):
FreeIPA, qui tire plein de dépendances dont SSSD, pour monter une CA et l'auth Kerberos + LDAP

Je peux peut-être fouiller du côté de FreeIPA alors. J'utilisais beaucoup RH/CentOS dans mon boulot d'avant, je peux à peu près transposer certaines connaissances sur Ubuntu Server.

flanker (./7560):
accessoirement, que veux-tu faire exactement ?
- que l'utilisateur s'authentifie en AD mode Kerberos pour sa session Gnome/KDE ? si oui, en mdp ou en PKCS11 ?

Merci pour ta question Pas de session GUI, c'est un Ubuntu Server sans autre chose que du CLI.

flanker (./7560):
- que l'utilisateur ouvre un partage réseau Samba kerberisé ?

Nope.

flanker (./7560):
- que l'utilisateur récupère ses infos depuis l'AD mode LDAP ?

Non plus (enfin sauf si c'est nécessaire à l'authentification et oui, ça l'est pour définir quel groupe AD a droit d'être sudoer, mais ça c'est bon je sais où c'est (==visudo)).
Je ne cherche qu'une chose: ne pas utiliser ni root ni le compte générique (qu'on a appelé admxxx), mais bien des comptes authentifiés pour SSH. Je suppose que je pourrais configurer ldap sur l'ad (je sais que ça marche), mais je pensais qu'utiliser des paquets qui connaissent nativement ActiveDirectory (et donc Kerberos, je dis pas de bêtise?) était une meilleure idée. Surtout que normalement, c'est "simple" à configurer ! (Là où pour ldap, il faut ne serait-ce qu'un utilisateur qui sait browser l'ad, et donc un mdp).

flanker (./7560):
Sinon, question bête et méchante : les machines sont-elles à l'heure ? Si tu n'as pas de ntp sur le réseau, oublie Kerberos ^^

Oui je me suis assuré que nos AD sont synchros avec un NTP (que j'ai installé moi-même), et la machine Ubuntu server en question est bien synchro avec le DC primaire de l'ad.

flanker (./7560):
lancer strace pour voir les soucis.

J'ai fait 2 ou 3 fois (vu sur certains articles de troubleshoot), c'est... verbeux J'ai pu voir une fois mention d'un fichier utile, sinon c'est que du fichier temporaire (ai-je l'impression).

(Merci à vous).

Chez moi ça marche© depuis longtemps, du coup j'ai un peu oublié, mais voilà en gros :

Kerberos a été implémenté par le MIT, mais a été bridé à cause des lois américaines sur l'export (c'est vieux).
Du coup, il y a eu une seconde implémentation, Heimdal (le gardien d'Asgard), qui n'est pas bridée.
Théoriquement, tu peux utiliser un client MIT avec un serveur Heimdal et réciproquement… mais c'est très théorique ^^

Bon, du coup : tu as trois machines impliquées :
- l'AD (qui va servir de KDC),
- ton Ubuntu serveur S qui aura un ou plusieurs services kerberisés (apache ou ssh),
- ton poste d'administration A (bien évidemment sur un réseau distinct du réseau bureautique ).


1) commence par jouer avec un apache et non SSH comme service kerberisé (plus simple, pas de PAM, et pas de risque de te scier la branche sur laquelle tu es)
2) voici le principe de Kerberos :
- tu fais un kinit sur A pour avoir un ticket de session TGS (valable un jour, en gros un passeport)
- tu fais une requête (curl, firefox, …) sur S (utilise curl -u : --anyauth) qui t'envoie balader (HTTP/401)
- curl (via libkrb5) fait une requête au KDC avec ton TGS pour avoir un TGT (valable 5 minutes et uniquement pour S : un visa sur ton passeport)
- curl retourne vers S en présentant ton TGT
- S voit ton TGT et le vérifie auprès du KDC puis accepte ton authentification.


3) ça veut dire que :
- S doit avoir un compte (chaque service a son compte différent) et être authentifié de façon permanente auprès du KDC (via un Keytab, qui est en gros un fichier avec ton mot de passe en clair),
- ton compte d'admin A doit avoir un compte sur l'AD et être authentifié.

Du coup :
- as-tu un compte sur l'AD ?
- as-tu configuré Kerberos sur ton poste d'admin ?
- as-tu fait un kinit (un klist devrait te le dire) ?
- est-ce que A est à l'heure ?
- S a-t-il un keytab ?
- qu'il y a-t-il dans le keytab (ça va dépendre de l'application : pour un serveur web avec un alias, "HTTP/mon.alias.domain" devrait être bon ) ?
- le keytab est-il au bon endroit avec les bons droits ?

Le strace sera pour lancer apache et chercher toutes les occurrences de krb/keytab/ … pour voir les fichiers testés.

Merci pour tous tes détails bien instructifs !

Je le (re)dis, ça a marché à un moment (mon compte adm.adrienxxx a pu s'authentifier en SSH sur le serveur Ubuntu...), donc tous les prérequis que tu listes sont bons (ou l'ont été !)
kinit est une bonne question : j'ai joué avec, mais je ne l'ai pas fait pour que ça marche, je pense que sssd doit le faire dans son coin une fois qu'il connaît le nom du domaine (dont je ne sais toujours pas où il va le piocher...)
Pourquoi tu parles de kerberos sur mon poste d'admin ? (= windows 10, où j'ai un autre compte sur un autre ad; mais ça n'a rien à voir, du moment que je peux joindre le serveur en SSH, l'origine de la connexion n'a aucune importance).

Il y a bien un keytab (au même endroit que le krb5.conf)... sauf quand je le détruis en espérant cleaner. Je ne sais pas quelle commande le crée (realm discover ? realm join ? kinit ? apt install krb5-user?) Et pour l'avoir affiché avec cat, pour moi c'est pas un fichier en clair.

Je referai une passe un peu plus complète lundi (sauf si le presta m'a bien fait le rollback demandé ). Merci !

Je ne connais rien à Windows, notamment pas les équivalents de kinit et klist, désolé.

Sur un Ubuntu cliente, si tu te connectes avec succès, tu dois avoir la trace dans klist. Ça permet d'être sûr que la phase Kerberos a bien fonctionné et que ce n'est pas autre chose (genre une clef privée qui traîne…)

Tu *dois* être authentifié en Kerberos sur A (ça tombe bien, l'authentification AD sur un Windows récent fait du Kerberos), sur le même AD (ou sur un AD du même domaine) que S.
Le principe de Kerberos est de t'authentifier (à partir de A) sur S : il faut donc fournir une identité. Cette pièce identité t'est fournie par le KDC quand tu te loggues sur A (ou que tu fais un kinit).
Tu vas la retransmettre à S pour prouver ton identité… mais ça veut dire que S a le même dealer d'identité KDC que A. L'avantage est que tu ne fournis à S qu'un token fait sur mesure pour lui : il n'a aucun accès à ton vrai secret (que tu ne donnes qu'à ton KDC).
Sinon S te voit arriver avec une pièce d'identité en laquelle il n'a aucune raison de faire confiance…


Le keytab n'est pas lisible facilement, il faut regarder ce qu'il y a dedans avec ktutil (la syntaxe dépend de MIT ou Heimdal).

Je ne connais rien à Windows

C’est un système d’exploitation de la société américaine Microsoft.

(et ça se dit docteur en informatique )

()

./7564 J'ai l'impression que le but n'est pas d'être authentifié par le système hôte de l'utilisateur lorsqu'il se connecte via SSH au serveur Ubuntu. J'ai l'impression que le but est de pouvoir entrer ses identifiants lors de la commande SSH pour un compte de l'annuaire avec lequel le serveur Ubuntu est associé.

Le problème est que l'entrée d'Ubuntu dans un AD est assez complexe et les méthodes qu'on trouve sur internet ne fonctionnent souvent pas. Par exemple, je viens de tester celle du lien de ./7543 sur une installation neuve et ça n'a pas fonctionné. La découverte semble se faire correctement, mais pas l'intégration (ça ne dit pas pourquoi, seulement qu'il ne peut pas). Il n'y a aucun problème avec Windows dans la même situation.

J'ai l'impression que le but est de pouvoir entrer ses identifiants lors de la commande SSH pour un compte de l'annuaire avec lequel le serveur Ubuntu est associé.

C'est exactement ce qu'il ne faut surtout pas faire, et Kerberos a été conçu pour éviter ça. Je ne suis d'ailleurs pas sûr que SSH le permette, vu que ce n'est pas du tout ce qui est prévu par le protocole gssapi.
Je sais que le module Kerberos d'Apache le permet : il authentifie l'utilisateur en BASIC et utilise le mot de passe fourni pour faire un kinit à la place de l'utilisateur. L'authentification HTTP n'est pas Kerberos mais BASIC et Kerberos est vu comme une base de stockage du mdp.

Au passage, l'utilisation de bi-clefs RSA n'est-elle pas possible, tout simplement ?

Folco (./7565) :

Je ne connais rien à Windows

C’est un système d’exploitation de la société américaine Microsoft.

(et ça se dit docteur en informatique )

flanker (./7564):
Tu *dois* être authentifié en Kerberos sur A (ça tombe bien, l'authentification AD sur un Windows récent fait du Kerberos), sur le même AD (ou sur un AD du même domaine) que S.

Alors je suis désolé, mais ton "tu DOIS" est faux. J'imagine que c'est ta casquette de sécurité qui parle, et que tu voulais écrire "tu DEVRAIS"
Je dis que c'est faux car ça a marché pour ce serveur, mais surtout ça marche pour 5 autres (sous Ubuntu) pas tous sur le même AD (donc je pensais avoir compris... en fait non )

flanker (./7564):
Le keytab n'est pas lisible facilement, il faut regarder ce qu'il y a dedans avec ktutil

Merci, c'est noté (encore un utilitaire CLI dont on se serait passé... ah là là, on est loin d'un truc plug'n'play).

RHJPP (./7567):
J'ai l'impression que le but n'est pas d'être authentifié par le système hôte de l'utilisateur lorsqu'il se connecte via SSH au serveur Ubuntu. J'ai l'impression que le but est de pouvoir entrer ses identifiants lors de la commande SSH pour un compte de l'annuaire avec lequel le serveur Ubuntu est associé.

!

flanker (./7568):
C'est exactement ce qu'il ne faut surtout pas faire, et Kerberos a été conçu pour éviter ça. Je ne suis d'ailleurs pas sûr que SSH le permette, vu que ce n'est pas du tout ce qui est prévu par le protocole gssapi.

Ah bin c'est sûr que SSH le permet puisque ça marche pour plein d'autres machines. Mon but est que le serveur soit dans l'AD, donc soit authentifié en direct, pas indirectement par une machine d'admin.
Je sais que dans un monde parfait, on passe par une machine d'admin fiable (une machine de rebond(->Ca viendra) ou une workstation béton (==pas notre cas du tout)), mais dans l'immédiat je suis 3 niveaux en-dessous : je veux simplement pas qu'on utilise des comptes locaux, donc S authentifié par l'AD.

flanker (./7568):
Au passage, l'utilisation de bi-clefs RSA n'est-elle pas possible, tout simplement ?

Des clés SSH ? Si bien sûr que c'est possible. Mais c'est une manipulation supplémentaire dont les autres admins (moins linuesques que moi) se passeraient bien pour l'instant.

Mais es-tu sûr que ce soit de l’authent’ Kerberos et non un bind LDAP ?
Ce que tu décris ne correspond pas au protocole Kerberos.

Je ne sais pas

adm.BLBLBLA@TRUC-ci05:~$ klist
Ticket cache: FILE:/tmp/krb5cc_62402728_D7ksT4
Default principal: adm.BLBLBLA@CORPO.LOCAL

Valid starting Expires Service principal
01/01/1970 00:00:00 01/01/1970 00:00:00 krbtgt/CORPO.LOCAL@CORPO.LOCAL

Ca te paraît pas être du kerberos ?

Pour info, ils m'ont restauré ma VM. Miracle, l'authentification marche. Ca c'est avant que je mette la VM dans la bonne OU sur l'AD (là le serveur est dans l'OU par défaut "Computer".
Je vais tenter la modif du fichier realmd.conf pour déplacer dans la bonne OU.

EDIT: realmd.conf pour indiquer l'OU