30

Je ne sais pas sad
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
avatarL'homme qu'a vu l'homme qu'a vu l'ours, qu'a mangé l'facteur..

31

J'ai modifié /etc/realmd.conf pour préciser le bon chemin de la bonne OU. Mais ça n'est pas pris en compte comme indiqué là: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/windows_integration_guide/realmd-conf
Changing the configuration as described in this section only works if the realm join command has not been run yet. If a system is already joined, changing these settings does not have any effect. In such situations, you must leave the domain, as described in Section 3.5, “Removing a System from an Identity Domain”, and then join again, as described in the section called “Joining a Domain”.
J'ai peur de quitter/rejoindre le domaine... fear
avatarL'homme qu'a vu l'homme qu'a vu l'ours, qu'a mangé l'facteur..

32

Et voilà, j'ai tout recassé sad
1- Modif le fichier /etc/realmd.conf pour ajouter la bonne OU
2- sudo realm leave -U='adm.BLBLBL'
3- sudo realm join --verbose --user=adm.BLBLBLB corpo.local --install=/

* Computer account for MACHIN-CI05$ does not exist
! Couldn't find a computer container in the ou, creating computer account directly in: ou=TRUC-CI,ou=Serveurs,DC=corpo,DC=local

[...]
* Modifying computer account: userPrincipalName
! Couldn't set service principals on computer account CN=MACHIN-CI05,ou=TRUC-CI,ou=Serveurs,DC=corpo,DC=local: 00002083: AtrErr: DSID-03151785, #1:
0: 00002083: DSID-03151785, problem 1006 (ATT_OR_VALUE_EXISTS), data 0, Att 90303 (servicePrincipalName)

[...]
* Successfully enrolled machine in realm
Hormis l'erreur sur le principals, la machine arrive bien dans le domaine.
Dans la bonne OU.

Mais l'authentification SSH ne marche plus: "Access denied"
avatarL'homme qu'a vu l'homme qu'a vu l'ours, qu'a mangé l'facteur..

33

Purée, je m'en suis sorti top

Pour mémoire....
Ton utilitaire ktutil m'a bien aidé, Flan, merci ! bisoo
Il y avait 60 mauvaises entrées dans le keytab après avoir re rejoint le domaine, voici un exemple:
71 0 /▒C▒3▒▒▒*▒"▒7▒@
72 0 CORPO.LOCAL/RestrictedKrbHost@
TRUC-CI05
Comme j'avais un backup du keytab, j'ai écrasé le keytab recréé par le keytab dont je savais qu'il marchait...
J'ai redémarré le service sssd et victoire : l'authentification AD pour SSH marche ET le serveur est enfin bien rangé...

J'ai pas tout compris pour autant.
Bon désolé pour le spam fil. Si j'avais su qu'il y aurait autant de messages, j'aurais fait un topic dédié.tsss
avatarL'homme qu'a vu l'homme qu'a vu l'ours, qu'a mangé l'facteur..

34

flanker (./7575):
L’authent’ SSH est en login - mot de passe, il passe tes identifiants à pam qui lui fait un kinit. SSH en soi n’est pas kerberisé.
Autrement dit, tu as le pire des deux mondes. Si ta VM est corrompue, l’attaquant récupère les TGT de tous les gens qui s’y sont connectés et se sert de leur compte pour se connecter sur tous les services kerberisés. Et au prochain login, il récupère le login et le mot de passe.

Et en toute logique, tu n’as pas spécialement besoin de keytab vu que le kinit est fait sur le serveur.
avatarL'homme qu'a vu l'homme qu'a vu l'ours, qu'a mangé l'facteur..

35

Flan> Je ne sais pas trop quoi dire à ton dernier message, je suis d'accord sur le fond...

Par contre je pense que keytab est requis dans mon cas.

Bon bin c'était trop beau : ça marche... que pour moi. C'est-à-dire que comme mon compte AD était déjà présent (ainsi que celui d'un compte de service pour le monitoring), donc ça marche. Mais je peux pas authentifier d'autres utilisateurs sad
Donc ça marche pas comme prévu. Je sais plus où j'en suis. fou2
avatarL'homme qu'a vu l'homme qu'a vu l'ours, qu'a mangé l'facteur..

36

Coup de gueule ? Pourquoi pas plutôt ici ?
avatarAll right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

37

J'ai hésité...
Mais comme je deviens fou, ça devient un coup de gueule avant le reste.:'(
Enfin si tu penses que ça a plus sa place là-bas, je voudrais bien que tu déplaces s'il te plaît happy
avatarL'homme qu'a vu l'homme qu'a vu l'ours, qu'a mangé l'facteur..

38

redangel (./35) :
Flan> Je ne sais pas trop quoi dire à ton dernier message, je suis d'accord sur le fond...

Par contre je pense que keytab est requis dans mon cas.
Si c'était un serveur Kerberos classique (comprendre : pas un AD), j'aurais pu te garantir que l'inscription dans l'AD et le keytab étaient facultatifs.
Je sais que le protocole Kerberos a des sécurités supplémentaires avec un AD, donc j'en suis moins sûr.

En revanche, je suis sûr que le keytab n'a pas besoin d'être lisible par sshd, vu c'est pam qui fait l'authentification.

Sinon, pour les autres comptes… peut-être que c'est lié à pam. Que renvoie la commande getent passwd ? En gros ça liste les utilisateurs visibles, en agrégeant toutes les sources de données.


Y a pas moyen de faire de l'authentification LDAP plutôt ? Avec une authentification par bind, tant qu'à faire. Ça t'éviterait d'avoir un keytab et de laisser traîner les credentials de tous les admin sur chaque VM grin

Au passage, vu que tu en parles, on m'a plutôt fortement déconseillé les rebonds, qui ne sont pas des machines d'admin fiables. En pratique, ça sert surtout à faire des points de faiblesse dans le réseau : tu corromps un rebond, et tu récupères les credentials de tout le monde pour toutes les machines. La bonne machine fiable, c'est le poste d'admin qui ne sert qu'à ça (et surtout pas à aller sur Facebook ou yN embarrassed).
avatar<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

39

Moi qui pensait que Kerberos était une techno microsoft... pardon.

getent passwd renvoie exactement la même chose que cat /etc/passwd. La seule chose qui ressemble à de l'ad là-dedans, c'est sssd: "sssd:x:112:117sorrySSD system user,,,:/var/lib/sss:/usr/sbin/nologin"

J'ai résolu mon problème hier en suivant une autre procédure (hyper vieille:
Ubuntu 14.04 Active Directory AuthenticationLeave No Bit UnturnedIn a post a couple of years ago I gave an example on how to configure an Ubuntu 12.04 server to authenticate to Active Directory. Things used to be hard back then. Now we have the realmd realm enro…
):
realm discover corpo.local

realm join corpo.local --user=adm.BLBLBL

realm list

realm deny --all

realm permit administratruc

realm permit -g 'GRP_TRUCTRUC'

realm list
Je n'ai toujours pas compris grand chose... mais les utilisateurs AD du groupe permis peuvent s'authentifier en SSH.
flanker (./38):
Y a pas moyen de faire de l'authentification LDAP plutôt ? Avec une authentification par bind, tant qu'à faire.
Du coup ça veut dire activer la fonctionnalité ldap côté AD ? Je pensais (bêtement) que ça serait moins sécurité et plus obsolète comme manière de faire.
flanker (./38):
Au passage, vu que tu en parles, on m'a plutôt fortement déconseillé les rebonds, qui ne sont pas des machines d'admin fiables.
Ah ?! Ca m'intéresse et me surprend beaucoup. Je suis pas expert en sécu, mais à HPE on jurait beaucoup par ça, avec une (ou plusieurs dépendamment du nombre d'utilisateurs) vm point d'entrée, tout désactivé par défaut, et avec uniquement les flux en destination concernant tel ou tel projet. Si tu as de la littérature là-dessus, ça m'intéresse, car on pensait faire ça partout (quand on aura le temps...) dans ma nouvelle boîte.
flanker (./38):
En pratique, ça sert surtout à faire des points de faiblesse dans le réseau : tu corromps un rebond, et tu récupères les credentials de tout le monde pour toutes les machines.
Je comprends pas trop ton point : si la VM est chiffrée, comment tu récupères les credentials de tout le monde ? Qui doivent être hashés par ailleurs (selon les technos bien sûr). Par ailleurs, ça me paraît plus facile de sécuriser un point sur le réseau (firewall tout activé, aucune fonctionnalité, un antivirus virulent, toutes les limitations possibles... le truc calvaire sur un laptop) que les machines de chacun.
flanker (./38):
La bonne machine fiable, c'est le poste d'admin qui ne sert qu'à ça
Tu parles d'une machine physique ? Comment tu gères multi-utilisateurs ? Simultané ? Si ces personnes sont pas au même étage ?
avatarL'homme qu'a vu l'homme qu'a vu l'ours, qu'a mangé l'facteur..

40

redangel (./39) :
Du coup ça veut dire activer la fonctionnalité ldap côté AD ? Je pensais (bêtement) que ça serait moins sécurité et plus obsolète comme manière de faire.
AD est un annuaire LDAP, ce n'est pas une fonctionnalité à activer ou pas smile
Un annuaire LDAP avec quelques spécificités microsoftiennes (l'attribut utilisé pour le mot de passe est write-only, par exemple, et c'est un attribut qu'il est interdit de modifier si on n'a pas ouvert une connexion chiffrée).

Après, j'imagine qu'il doit tout de même y avoir la possibilité de faire une vraie kerberification de SSH (je ne vois pas pourquoi ça ne serait pas possible), mais ça risque de ne pas faire ce que tu souhaites faire : au moment de la connexion au serveur SSH, la séquence d'authentification ne passerait plus par une demande d'authentification traditionnelle, mais irait juste vérifier s'il existe un jeton de SSO pour l'utilisateur qui est déjà connecté dans son environnement d'appel du SSH (c'est a priori ce type de configuration qui est décrit ici : https://centrify.force.com/support/Article/KB-4303-How-to-troubleshoot-SSH-Single-Sign-On-SSO-and-nested-SSO/ ).

Après, comme dit plus haut, je n'ai jamais mis en place de service Kerberos. On a mis en place du SSO uniquement pour les applications Web, là où je travaille, et encore, uniquement celles qui ne sont pas critiques pour éviter les problèmes de personnes qui ne verrouillent pas leurs sessions de façon systématique. Du coup on utilise CAS comme mécanisme de SSO (et CAS+Shibboleth pour le SSO avec authentification à des services externes). Pour tout le reste, on a des authentifications en bind LDAP (contre un AD ou un serveur OpenLDAP suivant les environnements : il y a des choses qui sont plus ou moins évidentes avec l'une ou l'autre des solutions).
avatar

41

redangel (./39) :
Moi qui pensait que Kerberos était une techno microsoft... pardon.

getent passwd renvoie exactement la même chose que cat /etc/passwd. La seule chose qui ressemble à de l'ad là-dedans, c'est sssd: "sssd:x:112:117sorrySSD system user,,,:/var/lib/sss:/usr/sbin/nologin"
Dans ce cas, à chaque fois qu'un nouvel utilisateur se connecte, un nouvel utilisateur local va être créé. Il y aura des uid différents sur chaque machine : ça peut poser des problèmes si tu utilises un stockage partagé.
De la même façon, les groupes ne seront pas récupérés par l'AD. Ça doit être nslcd qui doit être configuré pour ça, de mémoire.


flanker (./38):
Y a pas moyen de faire de l'authentification LDAP plutôt ? Avec une authentification par bind, tant qu'à faire.
Du coup ça veut dire activer la fonctionnalité ldap côté AD ? Je pensais (bêtement) que ça serait moins sécurité et plus obsolète comme manière de faire.
Non, si tu fais bien du LDAPS (ou du LDAP + startTLS, ce qui revient au même). Les TGT ne traîneraient plus sur les VM, mais à part ça c'est la même chose.


Ah ?! Ca m'intéresse et me surprend beaucoup. Je suis pas expert en sécu, mais à HPE on jurait beaucoup par ça, avec une (ou plusieurs dépendamment du nombre d'utilisateurs) vm point d'entrée, tout désactivé par défaut, et avec uniquement les flux en destination concernant tel ou tel projet. Si tu as de la littérature là-dessus, ça m'intéresse, car on pensait faire ça partout (quand on aura le temps...) dans ma nouvelle boîte.
Mais si l'ordi d'un des administrateurs est piégé, il va piéger les rebonds et à partir de là, le rebond va permettre de récupérer les accès de tous les admins.

Par contre, je n'ai pas des masses de littérature. Perso, comme je n'ai aucune légitimité en sécurité informatique, je me base sur le site de l'ANSSI et j'ai quelque contacts (kissiconnaissent) quand j'ai des questions.
https://www.ssi.gouv.fr/entreprise/bonnes-pratiques/
https://www.ssi.gouv.fr/administration/bonnes-pratiques/


Je comprends pas trop ton point : si la VM est chiffrée, comment tu récupères les credentials de tout le monde ? Qui doivent être hashés par ailleurs (selon les technos bien sûr). Par ailleurs, ça me paraît plus facile de sécuriser un point sur le réseau (firewall tout activé, aucune fonctionnalité, un antivirus virulent, toutes les limitations possibles... le truc calvaire sur un laptop) que les machines de chacun.
Même si ton rebond est blindé, si c'est le poste d'admin lui-même qui est piégé, c'est mort d'avance dans la mesure où celui qui s'y connecte est administrateur.

L'idée est que la propagation d'un malware va globalement suivre les flux légitimes. Si tu as un flux qui va de A vers R puis vers S (ton poste d'admin vers ton rebond puis le serveur), un malware pourra facilement le suivre et se propager de A à R puis S, plus difficilement de R vers A (mais pas impossible : il y avait récemment une faille dans Ansible qui permettait de corrompre le poste d'admin à partir du serveur configuré par Ansible).

[quoteTu parles d'une machine physique ? Comment tu gères multi-utilisateurs ? Simultané ? Si ces personnes sont pas au même étage ?[/quote]
Les bonnes pratiques recommandent d'avoir des postes séparés (et des réseaux distincts) pour l'administration et les autres activités (bureautique, mail, surf, …). Au pire des VM distinctes sur un même poste.
avatar<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant