Bonjour à tous,

Je me permet d'ouvrir une nouvelle discussion car je n'arrive pas à trouver de solution et mon ami Google n'a pas grand chose en stock.
Par ailleurs je pense que le problème est connu de tous ceux qui utilise Fedora 26/27 avec une authentification Kerberos (FreeIPA).
J'espère ne pas tromper, le problème touche à Gnome, SSSD et Fedora... Je ne rencontre pas le problème sous CentOS 7 & à l'époque sous Fedora 25 ça marchait également.

Initialement sur une nouvelle installation de Fedora 27, tout fonctionne normalement, le ciel est bleu et les oiseaux chantent.
L'orage arrive quand on intègre la machine au domaine. Le client rejoint bien le domaine, l'utilisateur se connecte et le $HOME est bien créé.
Seulement au prochain redémarrage, la connexion à gnome ne se fera plus, on entre le mot de passe, un écran noir s'affiche et retour à l'écran de sélection des utilisateurs.

Solution temporaire :
1. Ouvrir TTY2
2. Se connecter avec le même utilisateur et lancer un startx
3. Revenir sur TTY1 puis se connecter
Il se peut que le Pulseaudio ne démarre pas, du coup depuis le TTY1 il faut tuer le processus startx et gnome-session.
Puis fermer sa session TTY1 et l'ouvrir de nouveau sans fermer TTY2.

Je ne suis pas un expert dans les LOGS de Gnome & SSSD et je n'ai pas vu de chose qui saute aux yeux.
Suis-je le seul à utiliser Fedora avec FreeIPA ?

Il y a ce ticket red had qui semble correspondre mais sous CentOS 6 et pas de solution à ce jour.
Le problème ne semble pas venir de SELinux, Wayland peut être ?

Cordialement
RJames
Non, sous Xorg c'est aussi le cas, l'ayant sous sddm.

Il semble y avoir un souci avec la liaison avec le serveur freeipa par moment. Je travail dessus étant sans doute l'un des seuls ici à travailler avec Freeipa...

Vérifie le service ipa.service : 
systemctl status ipa.service
Perso je dois le relancer car j'ai un souci si je le reboot.
J'ai vérifié sur le serveur IPA pas de problème avec le service il est UP et le redémarrage du service se fait correctement.
Sur mes clients aucun changement. J'aurais peut être dû le préciser, je n'ai aucun problème avec une liaison SSH utilisant kerberos.
L'authentification se fait correctement, le problème est uniquement sur l'ouverture des sessions GNOME.

Votre serveur FreeIPA est sous quelle distribution ?
Sous CentOS, ça fait 5 ans que je l'utilise aucun problème à signaler sur la stabilité des services.

Cordialement
RJames
Même souci par moment avec sddm.

Pas de souci pour lancer une session utilisateur en ligne de commande.

Je tourne actuellement sur Fedora 27 sur mon infra virtualisé de validation. C'était un problème avec la gestion du DNS de la box. C'est rentré dans l'ordre au niveau du serveur.

Concernant le client, je dois tester quelques solutions pour voir si cela améliore ce genre de problème, car j'en ai d'autres à résoudre du même genre. Surtout quand il y a des soucis de détection du serveur IPA par exemple.

Sur CentOS la dernier souci que j'ai eu était un bogue avec l'utilisation de l'UTF8 comme encodage. C'est normalement résolu, mais je n'ai pas remis de serveur FreeIPA sous CentOS depuis.
J'ai récemment découvert qu'il fallait éviter d'utiliser un DNS autre que celui du serveur FreeIPA.
Par exemple pour l'intégration des machines dans le domaine la détection du serveur se fait automatiquement si on utilise son DNS.
Avant j'utilisais deux DNS dont FreeIPA en secondaire, ça marche mais c'est moins efficace.

Cordialement
RJames
Même recommandation sur de l'Active directory sous MS windows 😉 .
En fait c'est parce que j'avais déclaré le DNS de FreeIPA dans la box.

Après tu peux laisser la gestion à un autre DNS externe à la place et le gérer par FreeIPA, mais c'est galère car il y a pas mal de manipulation à faire en plus.
Il faudrait surveiller le /var/log/audit/audit.log quand une connexion échoue. Pour vraiment mettre de côté SELinux. Et rouvrir une session en mode texte ça passe ? Peut être un message d'erreur qui donnerait une piste. En tout cas un mauvais contexte SELinux sur un fichier qui fait mal, ça fait se genre de comportement.

Et tester avec Xorg en effet. Mais je vois pas pourquoi avec Wayland ça marcherait à la 1ere connexion du coup et pas aux suivantes.
Bon toujours mon bogue au redémarrage de la machine. Je pense que c'est à cause du replica que cela déconne.

Donc, vérifie que tu as bien ces options dans /etc/pam.d/(gdm, sddm, autres) : 
auth    required   pam_sss.so
account required   pam_sss.so
session required pam_oddjob_mkhomedir.so umask=0022 skel=/etc/skel
Cela vas forcer à créer comme il faut le /home.

Perso plus de souci, je test pour voir avec un nouvel utilisateur.

Edit :
Bon cela fonctionne très bien avec un nouvel utilisateur. Par contre SDDM ne permet pas de changer le mot de passe à la première connexion... Du coup ça bloque. Une fois fait, pas de souci de ce coté là 🙂.

Enfin bon c'est déjà pas mal, il y a qqes versions sddm ne permettait pas de lancer une session ldap/ipa. Je me souvient qu'il était obligatoire d'utiliser gdm ou kdm. A voir si il est possible de passer outre...

Je le rajoute à la doc sur le client que je prépare en douce... voir si remplacer "required pam_oddjob_mkhomedir.so" par "optionnal ...." ne serait pas mieux...

Source pour bricoler ce genre de solution : https://www.redhat.com/archives/freeipa-users/2016-November/msg00032.html

Je prépare aussi un script pour configurer ce genre de chose sans faire 36 manipulations (bizarre que ce ne soit pas le cas par défaut à l'installation du client...).
Bonsoir,

J'ai essayé de modifier le /etc/pam.d/gdm-password comme mentionné mais ça ne change rien sur un utilisateur existant. Je vais essayé avec un nouvel utilisateur.
Je vais regarder. Est ce que tu as suivi les informations défini sur cette partie de la doc :
https://www.freeipa.org/page/Web_App_Authentication#Host_and_service_based_access_control

Perso plus de soucis en dehors du problème concernant la demande de changer le mdp à la première connexion.

Je vais tester avec gdm sur une vm pour voir si je reproduit ton souci. Cela vas me permettre de commencer à tester le script qui automatisera le tout.
Alors... j'ai peut être trouvé une partie du problème rencontré dans le sujet.
A savoir l'impossibilité de se reconnecter par la suite en mode graphique.

J'ai eu la présence d'esprit de vérifier si les utilisateurs n'avaient pas encore des processus en route, il s'avère que si l'on ne quitte pas la session correctement il laisse le processus (ainsi que ces liaisons) ksmserver (sous plasma/KDE, mais ce doit être dans le même style sous gnome) en mémoire et bloque donc le lancement de la session. Cela se passe même si il y a un redémarrage. Une fois fais le ménage dans les processus lancé par les utilisateurs du domaine, tout revient à la normal.
A voir si c'est un bogue ou si c'est un comportement normal.

Par contre ce que j'ai indiqué plus haut reste valable, à savoir la ligne à rajouter pour créer le home de l'utilisateur avec le desktop manager et le souci avec le mdp et sddm. je regarde aussi du coté de cette partie : https://www.freeipa.org/page/Web_App_Authentication#Host_and_service_based_access_control
Je vais l'intégrer dans mon script (en ligne de commande dans un premier temps, je prépare un modèle pour pouvoir le faire avec une interface graphique en QT) pour ne plus à avoir à y penser.

Je trouve que c'est un peu mal expliqué dans la doc officiel, je n'ai pas vraiment trouvé de docs/process sur le sujet qui réuni toutes les parties utiles au même endroit.

Pour le problème avec les processus, c'est peut être une bonne idée de rajouter dans le script de création des utilisateurs la possibilité de faire le ménage automatiquement en cas de pépin.
C'est du même genre que ce que mon collègue et moi avions commencé à développer pour le client SCCM (gestionnaire de parc informatique chez MS) quand les processus (services) partaient en cacahuète lors de mon ancienne mission chez un client.
Peut être ajouter la possibilité de ciblage à distance pour intervenir sur un client IPA en particulier pour lancer la procédure de "kill" de processus par exemple. Voir ajouter dans l'interface cette possibilité...