doc: update notes

This commit is contained in:
Michel Decima
2021-10-20 02:18:27 -07:00
parent ccb17c7352
commit c5aaa81fd8
3 changed files with 151 additions and 12 deletions

View File

@@ -124,9 +124,12 @@ On introduit les fonctionnalités pas à pas:
- configuration PKCS#11 avec `pam_sss` - configuration PKCS#11 avec `pam_sss`
- suppression de `pam_krb5` et `pam_pkcs11` - suppression de `pam_krb5` et `pam_pkcs11`
Void [Notes_gdm.md](Notes_gdm.md) pour le fonctionnement de GDM avec PAM. Pour les détails, voir les documents:
Voir [Notes_pkcs11.md](Notes_pkcs11.md) pour la configuration `pam_pkcs11`.
Voir [Notes_sssd.md](Notes_sssd.md) pour la configuration `pam_sss`. - [Notes_gdm.md](Notes_gdm.md) : fonctionnement de GDM avec PAM.
- [Notes_pkcs11.md](Notes_pkcs11.md) : configuration `pam_pkcs11`.
- [Notes_sssd.md](Notes_sssd.md) : configuration `pam_sss`.
- [Notes_pam.md](Notes_pam.md) : configuration globale PAM.
[GNOME Configuration - Simple Greeter Configuration]: https://help.gnome.org/admin/gdm/stable/configuration.html.en#greeterconfiguration [GNOME Configuration - Simple Greeter Configuration]: https://help.gnome.org/admin/gdm/stable/configuration.html.en#greeterconfiguration

View File

@@ -1,7 +1,112 @@
D'apres [PAMConfigFrameworkSpec], `pam_sss` devrait avoir une priorité PAM et pam-auth-update
>= 512, puisqu'il s'agit d'un profil qui "authenticates against a central ----------------------
network service, with rules to exclude administrative/system accounts". Or sa
priorité définie dans `/usr/share/pam-configs/sss` est 128 ... pourquoi ? L'authentification par mot de passe est gérée par le profil `common-auth`.
Ce profil n'est pas utilisé directement, il est inclus depuis les profils
de service présents dans `/etc/pam.d`.
Le contenu de ce profil commun est généré automatiquement par la commande
`pam-auth-update` pour tous les modules PAM qui livrent une définition dans
`/usr/share/pam-configs`. Cette commande peut être invoquée en mode interactif
(menu curses) ou en ligne de commande, éventuellement depuis un script de
paquet `postinst`. Voir [pam-auth-update(8)] pour les détails.
Les fichiers de définition dans `/usr/share/pam-configs` contiennent des
fragments de profil PAM, et aussi des méta-données qui sont utilisées
pendant l'exécution de `pam-auth-update`. La propriété la plus intéressante
est `Priority`: elle détermine l'ordre d'apparition du module dans la
liste du menu curses et dans le fichier `common-auth`. Les modules sont
classés par ordre de priorité décroissante. Voir [PAMConfigFrameworkSpec].
Extrait d'un `common-auth` généré avec les définitions `krb5`, `unix` et `ccreds`:
```
# here are the per-package modules (the "Primary" block)
auth [success=4 default=ignore] pam_krb5.so minimum_uid=1000
auth [success=3 default=ignore] pam_unix.so nullok_secure try_first_pass
auth [success=2 default=ignore] pam_ccreds.so minimum_uid=1000 action=validate use_first_pass
auth [default=ignore] pam_ccreds.so minimum_uid=1000 action=update
# here's the fallback if no module succeeds
auth requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
auth required pam_permit.so
```
Les modules sont testés dans l'ordre d'apparition: d'abord `krb5`, si
l'authentification Kerberos échoue on passe à `unix`, si l'authentification
avec mot de passe local échoue on passe à `ccreds`, etc.
Important: l'option `success=N` est une instruction de saut: si le module concerné
authentifie l'utilisateur, alors les N modules suivants seront sautés, ce n'est pas
la peine de les invoquer. Autrement dit, si `pam_krb5` réussit, on passe directement
à `pam_permit`. Voir [pam.conf(5)] pour les détails sur les options.
Mise en place de `pam_sss`
--------------------------
Après avoir configuré SSSD, on active le profil `sss` avec `pam-auth-update`:
```
# pam-auth-update --remove krb5 --enable sss
```
Et là, c'est le drame : à l'ouverture de session, l'utilisateur n'obtient pas
de ticket Kerberos :-( alors que la machine est bien connectée au réseau.
Dans les logs, on a:
```
pam_unix(gdm-password:session): session opened for user meyd7400 by (uid=0)
```
C'est le module `unix` qui a authentifié l'utilisateur.
Sur une autre machine, où (par chance) le mot de passe local est différent
du mot de passe AD, le comportement est différent, le TGT est bien obtenu
à l'ouverture de session en utilisant le mot de passe AD.
Dans les logs, on a maintenant:
```
pam_unix(gdm-password:auth): authentication failure; logname= uid=0 euid=0 tty=/dev/tty1 ruser= rhost= user=meyd7400
pam_sss(gdm-password:auth): authentication success; logname= uid=0 euid=0 tty=/dev/tty1 ruser= rhost= user=meyd7400
[...]
pam_unix(gdm-password:session): session opened for user meyd7400 by (uid=0)
```
Le module `unix` a échoué (normal) et le module `sss` a réussit.
Pour comprendre ce comportement, il faut regarder dans le profil `common-auth`,
qui contient maintenant ceci:
```
# here are the per-package modules (the "Primary" block)
auth [success=4 default=ignore] pam_unix.so nullok_secure
auth [success=3 default=ignore] pam_sss.so use_first_pass
auth [success=2 default=ignore] pam_ccreds.so minimum_uid=1000 action=validate use_first_pass
auth [default=ignore] pam_ccreds.so minimum_uid=1000 action=update
```
Le module `unix` est placé en premier, donc il réussit toujours quand le
mot de passe local est synchronisé avec le mot de passe AD, et alors le
module `sss` n'est pas appelé à cause de l'option `success`, cf plus haut.
Si le module `sss` était placé en premier, comme l'était `krb5`,
alors on aurait eu le résultat attendu. Mais il est placé en second par
`pam-auth-update`, parce que sa priorité (128) est inférieure à celle de
`unix` (256).
Le module `pam_sss` en premier
------------------------------
D'apres [PAMConfigFrameworkSpec], le module `pam_sss` devrait avoir une
priorité supérieure ou égale à 512, puisqu'il s'agit d'un profil
qui "authenticates against a central network service, with rules to
exclude administrative/system accounts". Or sa priorité définie dans
`/usr/share/pam-configs/sss` est 128 ... pourquoi ?
Une réponse possible: le module `pam_sss` ne prend pas en compte l'option
PAM classique `minimum_uid` comme le font `pam_krb5` et `pam_ccreds`, il
utilise pour faire la même chose une propriéte `min_id` à définir dans
le fichier de configuration `sssd.conf`. Comme la règle d'exclusion n'est
pas explicitement dans la configuration PAM, ca pourrait expliquer le
choix d'une priorité inférieure.
=> chercher dans le bugtracker ? => chercher dans le bugtracker ?
@@ -22,15 +127,15 @@ résiste pas à une mise à jour du paquet `libpam-sss`, il faudrait mettre
en place un `trigger` ou mieux encore un `divert` ... ça reste du bricolage. en place un `trigger` ou mieux encore un `divert` ... ça reste du bricolage.
Autre solution, plus propre: Autre solution, plus propre:
- ajouter un fichier `/usr/share/pam-configs/sss-yourdev`, copie de `sss` - ajouter un fichier `/usr/share/pam-configs/sss-first`, copie de `sss`
- modifier sa propriété `Name` et augmenter la valeur de `Priority` - modifier sa propriété `Name` et augmenter la valeur de `Priority`
- rajouter une propriété `Conflicts: sss` - rajouter une propriété `Conflicts: sss`
- dans le `postinst`, activer `sss-yourdev` et désactiver `sss` - dans le `postinst`, activer `sss-first` et désactiver `sss`
Important: ne pas utiliser --force dans les scripts, seulement --package Important: ne pas utiliser --force dans les scripts, seulement --package
Important: bien verifier uid >= 1000 et users interdits. Important: bien verifier uid >= 1000 et users interdits.
Note: les deux profils `sss` et `sss-yourdev` sont en conflit, mais leur Note: les deux profils `sss` et `sss-first` sont en conflit, mais leur
propriété `Default` vaut `yes`, ce qui a une conséquence particulière propriété `Default` vaut `yes`, ce qui a une conséquence particulière
: quand on lance `pam-auth-update` une première fois en mode interactif, : quand on lance `pam-auth-update` une première fois en mode interactif,
sans avoir exécuté la configuration automatique via le `postinst`, alors sans avoir exécuté la configuration automatique via le `postinst`, alors
@@ -39,6 +144,37 @@ valide à ce moment, le dialogue se plaint qu'il y a conflit, et refuse de
valider la sélection. Il faut modifier et choisir l'un ou l'autre. Ensuite, valider la sélection. Il faut modifier et choisir l'un ou l'autre. Ensuite,
le dialogue se souvient du choix qui a été fait. le dialogue se souvient du choix qui a été fait.
Reste à faire
-------------
Avec le module `pam_sss` en premier, on a le comportement attendu,
le problème de l'obtention du TGT Kerberos à l'ouverture de session
est résolu.
Néanmoins, il doit bien y avoir une raison explicite pour que `pam_sss`
ne soit pas prioritaire dans la configuration par défaut Debian/Ubuntu,
la "réponse possible" ci-dessus n'est qu'une supposition de ma part, tant
que je n'aurais pas trouvé l'explication dans une documenation officielle
il restera un doute sur la méthode ci-dessus.
Question subsidiaire a résoudre: comment changer le mot de passe local ?
Précédemment, avec `pam_krb5`, la méthode consistait à d'abord désactiver
Kerberos via `pam-auth-update`, changer le mot de passe avec `passwd`, puis
rétablir Kerberos. On peut faire la même chose maintenant, mais c'est plus
délicat, on a deux entrées dans le menu curses : "SSSD (first)" et "SSSD",
c'est la première qu'il faut rétablir, pas la deuxième...
A creuser:
- un script pour automatiser les différentes étapes du changement de
mot de passe local
- désactiver le changement de mot de passe AD dans la configuration PAM,
via la définition de `sss-first`, puisque de toute façon ce n'est pas
une bonne méthode (desynchro AD/Gassi), il faut passer par le site
"Mot de passe attitude".
Pour éviter les confusions, il faudrait renommer la définition `sss-first`
en `yourdev`, ça serait plus explicite.
Références Références
---------- ----------

View File

@@ -136,7 +136,7 @@ Références
[SSSD - Migrating from pam_krb5]: https://sssd.io/docs/krb/krb-migration.html [SSSD - Migrating from pam_krb5]: https://sssd.io/docs/krb/krb-migration.html
[SSSD - Design / Require Smartcard authentication ]: https://docs.pagure.org/sssd.sssd/design_pages/smartcard_authentication_require.html [SSSD - Design / Require Smartcard authentication ]: https://docs.pagure.org/sssd.sssd/design_pages/smartcard_authentication_require.html
[RHEL-8 / MANAGING SMART CARD AUTHENTICATION]: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/managing_smart_card_authentication/index [RHEL-8 / MANAGING SMART CARD AUTHENTICATION]: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/managing_smart_card_authentication/index
[GUI-Login with SSSD managed users fails]: (https://ask.fedoraproject.org/t/gui-login-with-sssd-managed-users-fails/6606/2) [GUI-Login with SSSD managed users fails]: https://ask.fedoraproject.org/t/gui-login-with-sssd-managed-users-fails/6606/2
[smartcard cert mapping offline (AD)](https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org/thread/STBGBEZI6D5A3MKMB26P2FNFLURML5DB/) [smartcard cert mapping offline (AD)]: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org/thread/STBGBEZI6D5A3MKMB26P2FNFLURML5DB/