Am Fri, Apr 19, 2024 at 05:03:46PM +0000 schrieb Carlos Lopez: > Of course. Here it is: > > # PAM configuration for the Secure Shell service > > # Standard Un*x authentication. > @include common-auth > > # Disallow non-root logins when /etc/nologin exists. > account required pam_nologin.so > > # Uncomment and edit /etc/security/access.conf if you need to set complex > # access limits that are hard to express in sshd_config. > # account required pam_access.so > > # Standard Un*x authorization. > @include common-account > > # SELinux needs to be the first session rule. This ensures that any > # lingering context has been cleared. Without this it is possible that a > # module could execute code in the wrong domain. > session [success=ok ignore=ignore module_unknown=ignore default=bad] > pam_selinux.so close > > # Set the loginuid process attribute. > session required pam_loginuid.so > > # Create a new session keyring. > session optional pam_keyinit.so force revoke > > # Standard Un*x session setup and teardown. > @include common-session > > # Print the message of the day upon successful login. > # This includes a dynamically generated part from /run/motd.dynamic > # and a static (admin-editable) part from /etc/motd. > session optional pam_motd.so motd=/run/motd.dynamic > session optional pam_motd.so noupdate > > # Print the status of the user's mailbox upon successful login. > session optional pam_mail.so standard noenv # [1] > > # Set up user limits from /etc/security/limits.conf. > session required pam_limits.so > > # Read environment variables from /etc/environment and > # /etc/security/pam_env.conf. > session required pam_env.so # [1] > # In Debian 4.0 (etch), locale-related environment variables were moved to > # /etc/default/locale, so read that as well. > session required pam_env.so user_readenv=1 envfile=/etc/default/locale > > # SELinux needs to intervene at login time to ensure that the process starts > # in the proper default security context. Only sessions which are intended > # to run in the user's context should be run after this. > session [success=ok ignore=ignore module_unknown=ignore default=bad] > pam_selinux.so open > > # Standard Un*x password updating. > @include common-password > > and common-account: > > # > # /etc/pam.d/common-account - authorization settings common to all services > # > # This file is included from other service-specific PAM config files, > # and should contain a list of the authorization modules that define > # the central access policy for use on the system. The default is to > # only deny service to users whose accounts are expired in /etc/shadow. > # > # As of pam 1.0.1-6, this file is managed by pam-auth-update by default. > # To take advantage of this, it is recommended that you configure any > # local modules either before or after the default block, and use > # pam-auth-update to manage selection of other modules. See > # pam-auth-update(8) for details. > # > > # here are the per-package modules (the "Primary" block) > account [success=1 new_authtok_reqd=done default=ignore] pam_unix.so > # here's the fallback if no module succeeds > account 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 > account required pam_permit.so > # and here are more per-package modules (the "Additional" block) > # end of pam-auth-update config
Hi, so pam_sss.so is not called at all which would explain the behavior. I assume pam_sss.so is listed in common-auth. Did you add it on your own to common-auth or was it added by a system utility e.g. pam-auth-update? bye, Sumit > > Best regards, > C. L. Martinez > > ________________________________________ > From: Sumit Bose <[email protected]> > Sent: 19 April 2024 17:46 > To: FreeIPA users list > Cc: Carlos Lopez > Subject: Re: [Freeipa-users] Password expired is not requested with Ubuntu > clients > > Am Fri, Apr 19, 2024 at 08:56:36AM +0000 schrieb Carlos Lopez via > FreeIPA-users: > > Good morning, > > > > I have configured some Ubuntu clientes to authenticate via Kerberos against > > my RHEL9 IdM server. Everything works correctly: clients are authenticated, > > etc. > > > > The problem comes when a user's password has expired. In the IdM server > > logs it is clear that the user must change the password: > > > > 2024-04-19T08:38:20.946335+00:00 rhelidmsrv01 krb5kdc[21392]: AS_REQ (8 > > etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), > > aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), > > DEPRECATED:des3-cbc-sha1(16), DEPRECATED:arcfour-hmac(23), > > camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) 172.19.11.14: REQUIRED > > PWCHANGE: [email protected] for krbtgt/[email protected], Password has > > expired > > 2024-04-19T08:38:20.946413+00:00 rhelidmsrv01 krb5kdc[21392]: closing down > > fd 13 > > 2024-04-19T08:38:20.946712+00:00 rhelidmsrv01 krb5kdc[21392]: AS_REQ (8 > > etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), > > aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), > > DEPRECATED:des3-cbc-sha1(16), DEPRECATED:arcfour-hmac(23), > > camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) 172.19.11.14: > > NEEDED_PREAUTH: [email protected] for kadmin/[email protected], Additional > > pre-authentication required > > 2024-04-19T08:38:20.946747+00:00 rhelidmsrv01 krb5kdc[21392]: closing down > > fd 13 > > 2024-04-19T08:38:20.950691+00:00 rhelidmsrv01 krb5kdc[21392]: AS_REQ (8 > > etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), > > aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), > > DEPRECATED:des3-cbc-sha1(16), DEPRECATED:arcfour-hmac(23), > > camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) 172.19.11.14: ISSUE: > > authtime 1713515900, etypes {rep=aes256-cts-hmac-sha1-96(18), > > tkt=aes256-cts-hmac-sha384-192(20), ses=aes256-cts-hmac-sha1-96(18)}, > > [email protected] for kadmin/[email protected] > > > > But when accessing to Ubuntu client via ssh, it never prompts to change the > > password and you can log in. > > Hi, > > can you share your PAM configuration for the sshd service. I'm asking > because the change of expired passwords in handled in the 'account' > section and I guess with your configuration (local users with > authentication by SSSD) pam_sss.so is not called for local users during > 'account'. > > bye, > Sumit > > > > > My sssd's config in Ubuntu client is: > > > > [sssd] > > config_file_version = 2 > > services = pam > > domains = mydom.org > > > > [pam] > > pam_pwd_expiration_warning = 2 > > > > [domain/mydom.org] > > id_provider = proxy > > proxy_lib_name = files > > auth_provider = krb5 > > chpass_provider = krb5 > > krb5_server = rhelidmsrv01.mydom.org > > krb5_kpasswd = rhelidmsrv01.mydom.org > > krb5_realm = mydom.org > > krb5_ccname_template = KEYRING:persistent:%U > > krb5_validate = true > > cache_credentials = true > > > > What could be the problem? > > > > Best regards, > > C. L. Martinez > > -- > > _______________________________________________ > > FreeIPA-users mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedorahosted.org/archives/list/[email protected] > > Do not reply to spam, report it: > > https://pagure.io/fedora-infrastructure/new_issue > -- _______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
