Passwd fails in SSSD 2.4.2
by Paweł Szafer
Hi again,
Last week I had to change my sssd.conf to ldap_sasl_mech=GSSAPI.
SSSD is 2.4.2 on Arch Linux.
Don't know if it is related but now I can't change password with this
machine (last time it was working in February).
Anyway passwd is asking me for current password and after typing it + Enter
it returning with message: Password changed.
Error which are most important (I think) is: authentication service cannot
retrieve user authentication to the client (bold below in Polish).
What I see in logs:
pam_sss:
(2021-05-11 14:40:28): [pam] [pam_initgr_check_timeout] (0x2000): User
[test] found in PAM cache.
(2021-05-11 14:40:28): [pam] [pam_dp_send_req] (0x0100): Sending request
with the following data:
(2021-05-11 14:40:28): [pam] [pam_print_data] (0x0100): command:
SSS_PAM_CHAUTHTOK
(2021-05-11 14:40:28): [pam] [pam_print_data] (0x0100): domain: realm.domain
(2021-05-11 14:40:28): [pam] [pam_print_data] (0x0100): user:
test(a)realm.domain
(2021-05-11 14:40:28): [pam] [pam_print_data] (0x0100): service: passwd
(2021-05-11 14:40:28): [pam] [pam_print_data] (0x0100): tty: not set
(2021-05-11 14:40:28): [pam] [pam_print_data] (0x0100): ruser: not set
(2021-05-11 14:40:28): [pam] [pam_print_data] (0x0100): rhost: not set
(2021-05-11 14:40:28): [pam] [pam_print_data] (0x0100): authtok type: 1
(Password)
(2021-05-11 14:40:28): [pam] [pam_print_data] (0x0100): newauthtok type: 0
(No authentication token available)
(2021-05-11 14:40:28): [pam] [pam_print_data] (0x0100): priv: 0
(2021-05-11 14:40:28): [pam] [pam_print_data] (0x0100): cli_pid: 955753
(2021-05-11 14:40:28): [pam] [pam_print_data] (0x0100): logon name: test
(2021-05-11 14:40:28): [pam] [pam_print_data] (0x0100): flags: 4
(2021-05-11 14:40:28): [pam] [pam_dom_forwarder] (0x0100): pam_dp_send_req
returned 0
(2021-05-11 14:40:28): [pam] [sbus_dispatch] (0x4000): Dispatching.
(2021-05-11 14:40:28): [pam] [pam_dp_send_req_done] (0x0200): received: [15
(Usługa uwierzytelniania nie może uzyskać uwierzytelnienia
użytkownika)][realm.domain]
(2021-05-11 14:40:28): [pam] [ldb] (0x10000): Added timed event
"ldb_kv_callback": 0x56049f493ce0
*(2021-05-11 14:40:28): [pam] [pam_reply] (0x4000): pam_reply initially
called with result [15]: Usługa uwierzytelniania nie może uzyskać
uwierzytelnienia użytkownika. this result might be changed during
processing*
(2021-05-11 14:40:28): [pam] [filter_responses] (0x0100):
[pam_response_filter] not available, not fatal.
(2021-05-11 14:40:28): [pam] [pam_reply] (0x0200): blen: 35
*(2021-05-11 14:40:28): [pam] [pam_reply] (0x0200): Returning [15]: Usługa
uwierzytelniania nie może uzyskać uwierzytelnienia użytkownika to the
client*
(2021-05-11 14:40:28): [pam] [client_recv] (0x0200): Client disconnected!
(2021-05-11 14:40:28): [pam] [client_close_fn] (0x2000): Terminated client
[0x56049f489150][19]
(2021-05-11 14:40:33): [pam] [pam_initgr_cache_remove] (0x2000): [test]
removed from PAM initgroup cache
krb5 logs
(2021-05-11 14:40:28): [krb5_child[955777]] [main] (0x0400): krb5_child
started.
(2021-05-11 14:40:28): [krb5_child[955777]] [unpack_buffer] (0x1000): total
buffer size: [173]
(2021-05-11 14:40:28): [krb5_child[955777]] [unpack_buffer] (0x0100): cmd
[247 (password change checks)] uid [1175201116] gid [1175200513] validate
[true] enterprise principal [false] offline [false] UPN [test(a)REALM.DOMAIN]
(2021-05-11 14:40:28): [krb5_child[955777]] [unpack_buffer] (0x0100):
ccname: [FILE:/tmp/krb5cc_1175201116_XXXXXX] old_ccname:
[FILE:/tmp/krb5cc_1175201116_GlkSJ1] keytab: [/etc/krb5.keytab]
(2021-05-11 14:40:28): [krb5_child[955777]] [check_use_fast] (0x0100): Not
using FAST.
(2021-05-11 14:40:28): [krb5_child[955777]] [switch_creds] (0x0200): Switch
user to [1175201116][1175200513].
(2021-05-11 14:40:28): [krb5_child[955777]] [switch_creds] (0x0200): Switch
user to [0][0].
(2021-05-11 14:40:28): [krb5_child[955777]] [k5c_check_old_ccache]
(0x4000): Ccache_file is [FILE:/tmp/krb5cc_1175201116_GlkSJ1] and is
active and TGT is valid.
(2021-05-11 14:40:28): [krb5_child[955777]] [privileged_krb5_setup]
(0x0080): Cannot open the PAC responder socket
(2021-05-11 14:40:28): [krb5_child[955777]] [become_user] (0x0200): Trying
to become user [1175201116][1175200513].
(2021-05-11 14:40:28): [krb5_child[955777]] [main] (0x2000): Running as
[1175201116][1175200513].
(2021-05-11 14:40:28): [krb5_child[955777]] [sss_child_set_krb5_tracing]
(0x0100): krb5 tracing is not available
(2021-05-11 14:40:28): [krb5_child[955777]] [set_lifetime_options]
(0x0100): No specific renewable lifetime requested.
(2021-05-11 14:40:28): [krb5_child[955777]] [set_lifetime_options]
(0x0100): No specific lifetime requested.
(2021-05-11 14:40:28): [krb5_child[955777]] [set_canonicalize_option]
(0x0100): Canonicalization is set to [true]
(2021-05-11 14:40:28): [krb5_child[955777]] [main] (0x0400): Will perform
password change checks
(2021-05-11 14:40:28): [krb5_child[955777]] [changepw_child] (0x1000):
Password change operation
(2021-05-11 14:40:28): [krb5_child[955777]] [changepw_child] (0x0400):
Attempting kinit for realm [REALM.DOMAIN]
(2021-05-11 14:40:28): [krb5_child[955777]] [sss_krb5_responder] (0x4000):
Got question [password].
(2021-05-11 14:40:28): [krb5_child[955777]] [changepw_child] (0x2000):
chpass is not using OTP
(2021-05-11 14:40:28): [krb5_child[955777]] [changepw_child] (0x1000):
Initial authentication for change password operation successful.
(2021-05-11 14:40:28): [krb5_child[955777]] [k5c_send_data] (0x0200):
Received error code 0
(2021-05-11 14:40:28): [krb5_child[955777]] [pack_response_packet]
(0x2000): response packet size: [4]
(2021-05-11 14:40:28): [krb5_child[955777]] [k5c_send_data] (0x4000):
Response sent.
(2021-05-11 14:40:28): [krb5_child[955777]] [main] (0x0400): krb5_child
completed successfully
(2021-05-11 14:40:28): [krb5_child[955786]] [main] (0x0400): krb5_child
started.
(2021-05-11 14:40:28): [krb5_child[955786]] [unpack_buffer] (0x1000): total
buffer size: [181]
(2021-05-11 14:40:28): [krb5_child[955786]] [unpack_buffer] (0x0100): cmd
[246 (password change)] uid [1175201116] gid [1175200513] validate [true]
enterprise principal [false] offline [false] UPN [test(a)REALM.DOMAIN]
(2021-05-11 14:40:28): [krb5_child[955786]] [unpack_buffer] (0x0100):
ccname: [FILE:/tmp/krb5cc_1175201116_XXXXXX] old_ccname:
[FILE:/tmp/krb5cc_1175201116_GlkSJ1] keytab: [/etc/krb5.keytab]
(2021-05-11 14:40:28): [krb5_child[955786]] [check_use_fast] (0x0100): Not
using FAST.
(2021-05-11 14:40:28): [krb5_child[955786]] [switch_creds] (0x0200): Switch
user to [1175201116][1175200513].
(2021-05-11 14:40:28): [krb5_child[955786]] [switch_creds] (0x0200): Switch
user to [0][0].
(2021-05-11 14:40:28): [krb5_child[955786]] [k5c_check_old_ccache]
(0x4000): Ccache_file is [FILE:/tmp/krb5cc_1175201116_GlkSJ1] and is
active and TGT is valid.
(2021-05-11 14:40:28): [krb5_child[955786]] [privileged_krb5_setup]
(0x0080): Cannot open the PAC responder socket
(2021-05-11 14:40:28): [krb5_child[955786]] [become_user] (0x0200): Trying
to become user [1175201116][1175200513].
(2021-05-11 14:40:28): [krb5_child[955786]] [main] (0x2000): Running as
[1175201116][1175200513].
(2021-05-11 14:40:28): [krb5_child[955786]] [sss_child_set_krb5_tracing]
(0x0100): krb5 tracing is not available
(2021-05-11 14:40:28): [krb5_child[955786]] [set_lifetime_options]
(0x0100): No specific renewable lifetime requested.
(2021-05-11 14:40:28): [krb5_child[955786]] [set_lifetime_options]
(0x0100): No specific lifetime requested.
(2021-05-11 14:40:28): [krb5_child[955786]] [set_canonicalize_option]
(0x0100): Canonicalization is set to [true]
(2021-05-11 14:40:28): [krb5_child[955786]] [main] (0x0400): Will perform
password change
(2021-05-11 14:40:28): [krb5_child[955786]] [changepw_child] (0x1000):
Password change operation
(2021-05-11 14:40:28): [krb5_child[955786]] [changepw_child] (0x0400):
Attempting kinit for realm [REALM.DOMAIN]
(2021-05-11 14:40:28): [krb5_child[955786]] [sss_krb5_responder] (0x4000):
Got question [password].
(2021-05-11 14:40:28): [krb5_child[955786]] [changepw_child] (0x2000):
chpass is not using OTP
(2021-05-11 14:40:28): [krb5_child[955786]] [changepw_child] (0x0020):
Failed to fetch new password [2] No such file or directory.
(2021-05-11 14:40:28): [krb5_child[955786]] [k5c_send_data] (0x0200):
Received error code 1432158219
(2021-05-11 14:40:28): [krb5_child[955786]] [pack_response_packet]
(0x2000): response packet size: [4]
(2021-05-11 14:40:28): [krb5_child[955786]] [k5c_send_data] (0x4000):
Response sent.
(2021-05-11 14:40:28): [krb5_child[955786]] [main] (0x0400): krb5_child
completed successfully
Thanks in advance for your help!
-----
Best regards,
Pawel
2 years, 11 months
Announcing SSSD 2.5.0
by Pavel Březina
# SSSD 2.5.0
The SSSD team is proud to announce the release of version 2.5.0 of the
System Security Services Daemon. The tarball can be downloaded from:
https://github.com/SSSD/sssd/releases/tag/2.5.0
See the full release notes at:
https://sssd.io/release-notes/sssd-2.5.0.html
RPM packages will be made available for Fedora shortly.
## Feedback
Please provide comments, bugs and other feedback via the sssd-devel
or sssd-users mailing lists:
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
## Highlights
### General information
* `secrets` support is deprecated and will be removed in one of the next
versions of SSSD.
* `local-provider` is deprecated and will be removed in one of the next
versions of SSSD.
* SSSD's implementation of `libwbclient` was removed as incompatible
with modern version of Samba.
* This release deprecates `pcre1` support. This support will be removed
completely in following releases.
* A home directory from a dedicated user override, either local or
centrally managed by IPA, will have a higher precedence than the
`override_homedir` option.
* `debug-to-files`, `debug-to-stderr` command line and undocumented
`debug_to_files` config options were removed.
### New features
* Added support for automatic renewal of renewable TGTs that are stored
in KCM ccache. This can be enabled by setting `tgt_renewal = true`. See
the sssd-kcm man page for more details. This feature requires MIT
Kerberos krb5-1.19-0.beta2.3 or higher.
* Backround sudo periodic tasks (smart and full refresh) periods are now
extended by a random offset to spread the load on the server in
environments with many clients. The random offset can be changed with
`ldap_sudo_random_offset`.
* Completing a sudo full refresh now postpones the smart refresh by
`ldap_sudo_smart_refresh_interval` value. This ensure that the smart
refresh is not run too soon after a successful full refresh.
* If `debug_backtrace_enabled` is set to `true` then on any error all
prior debug messages (to some limit) are printed even if `debug_level`
is set to low value (for details see `man sssd.conf`:
`debug_backtrace_enabled` description).
* Besides trusted domains known by the forest root, trusted domains
known by the local domain are used as well.
* New configuration option `offline_timeout_random_offset` to control
random factor in backend probing interval when SSSD is in offline mode.
### Important fixes
* `ad_gpo_implicit_deny` is now respected even if there are no
applicable GPOs present
* During the IPA subdomains request a failure in reading a single
specific configuration option is not considered fatal and the request
will continue
* unknown IPA id-range types are not considered as an error
* SSSD spec file `%postun` no longer tries to restart services that can
not be restarted directly to stop produce systemd warnings
### Configuration changes
* Added `tgt_renewal`, `tgt_renewal_inherit`, and `krb5_*` KCM options
to enable, and tune behavior of new KCM renewal feature.
* Added `ldap_sudo_random_offset` (default to `30`) to add a random
offset to backround sudo periodic tasks (smart and full refresh).
* Introduced new option 'debug_backtrace_enabled' to control debug
backtrace.
* Added `offline_timeout_random_offset` configuration option to control
maximum size of random offset added to offline timeout SSSD backend
probing interval.
* Long time deprecated and undocumented `debug_to_files` option was removed.
2 years, 11 months
RHEL 8.3 KDC has no support for encryption type
by Jeremy Monnet
Hello,
We upgraded today a RHEL 7.9 to RHEL8.3. We encounter now that error
KDC has no support for encryption type
which prevents authentication. The server has been remove and rejoin
to the Active Directory with realm join -U user@DOMAIN. The object has
been created in the AD (2012R2 in case it would be relevant) with
SPNs:
host/HOSTNAME
host/fqdn
RestrictedKrbHost/HOSTNAME
RestrictedKrbHost/fqdn
sssd_domain.log contains
(2021-05-05 21:06:55): [be[bcrs.fr]] [sasl_bind_send] (0x0100):
Executing sasl bind mech: GSS-SPNEGO, user: HOSTNAME$
(2021-05-05 21:06:55): [be[bcrs.fr]] [ad_sasl_log] (0x4000): SASL:
GSSAPI client step 1
(2021-05-05 21:06:55): [be[bcrs.fr]] [ad_sasl_log] (0x4000): SASL:
GSSAPI client step 1
(2021-05-05 21:06:55): [be[bcrs.fr]] [ad_sasl_log] (0x0040): SASL:
GSSAPI Error: Unspecified GSS failure. Minor code may provide more
information (KDC has no support for encryption type)
(2021-05-05 21:06:55): [be[bcrs.fr]] [sasl_bind_send] (0x0020):
ldap_sasl_bind failed (-2)[Local error]
(2021-05-05 21:06:55): [be[bcrs.fr]] [sasl_bind_send] (0x0080):
Extended failure message: [SASL(-1): generic failure: GSSAPI Error:
Unspecified GSS failure. Minor code may provide more information (KDC
has no support for encryption type)]
(2021-05-05 21:06:55): [be[bcrs.fr]] [child_sig_handler] (0x1000):
Waiting for child [2234].
(2021-05-05 21:06:55): [be[bcrs.fr]] [child_sig_handler] (0x0100):
child [2234] finished successfully.
(2021-05-05 21:06:55): [be[bcrs.fr]] [sdap_cli_connect_recv] (0x0040):
Unable to establish connection [1432158227]: Authentication Failed
(2021-05-05 21:06:55): [be[bcrs.fr]] [_be_fo_set_port_status]
(0x8000): Setting status: PORT_NOT_WORKING. Called from:
src/providers/ldap/sdap_async_connection.c: sdap_cli_connect_recv:
2095
We have tried numerous things with kinit for example :
[root@hostname sssd]# klist -ke
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
2 HOSTNAME$@DOMAIN (aes128-cts-hmac-sha1-96)
2 HOSTNAME$@DOMAIN (aes256-cts-hmac-sha1-96)
2 host/HOSTNAME@DOMAIN (aes128-cts-hmac-sha1-96)
2 host/HOSTNAME@DOMAIN (aes256-cts-hmac-sha1-96)
2 host/fqdn@DOMAIN (aes128-cts-hmac-sha1-96)
2 host/fqdn@DOMAIN (aes256-cts-hmac-sha1-96)
2 RestrictedKrbHost/HOSTNAME@DOMAIN (aes128-cts-hmac-sha1-96)
2 RestrictedKrbHost/HOSTNAME@DOMAIN (aes256-cts-hmac-sha1-96)
2 RestrictedKrbHost/fqdn@DOMAIN (aes128-cts-hmac-sha1-96)
2 RestrictedKrbHost/fqdn@DOMAIN (aes256-cts-hmac-sha1-96)
[root@hostname sssd]# kinit -V -k
Using new cache: persistent:0:krb_ccache_PECiZeh
Using principal: host/fqdn@DOMAIN
kinit: Client 'host/fqdn@domain' not found in Kerberos database while
getting initial credentials
[root@hostname sssd]# kinit -V -k HOSTNAME$
Using new cache: persistent:0:krb_ccache_cFLtQ1H
Using principal: HOSTNAME$@DOMAIN
kinit: Keytab contains no suitable keys for HOSTNAME$@DOMAIN while
getting initial credentials
We have added
krb5_validate = False
in sssd.conf and
[libdefaults]
allow_weak_crypto = true
default_tgs_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
default_tkt_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
permitted_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
in krb5.conf
and set msDS-SupportedEncTypes to 31 (which means "all" if I
understand correctly) on the AD object.
With no success.
I do not know what to do now :-)
Thanks for your help
Jeremy
2 years, 11 months
System error 4 is reported in the secur log after provisioning new ldap/kerberos servers
by Fahad Sayed
Hello,
We upgraded our LDAP/Kerberos servers to CentOS7. As a test we pointed a VM
(that is configured to authenticate with ldap/kerberos) to new
ldap/kerberos servers. However, we get system error 4 in /var/log/secur.
Under the troubleshooting section of the site, we're asked to join this
mailing list to figure out what is going on.
Also, we tried to point back to the existing ldap/kerberos servers on our
test VM, we still get the system error 4. The new ldap/kerberos servers are
identical to the old ones. Please, advice us on how we can proceed with
troubleshooting this issue. Thank you.
-F
2 years, 11 months
Can't login to AD in SSSD 2.4.2 / Arch Linux
by Paweł Szafer
Hello,
Today morning I had a bad surprise. Suddenly I cannot login anymore to my
PC.
My OS is Arch based, with SSSD 2.4.2, updated yesterday (it was working
after update, last login occurred around 7pm 05.05.2021, today 7am
06.05.2021 cannot login anymore)
Maybe you have any idea what's wrong.
What I see in sssd logs:
2021-05-06 9:49:26): [be[domain.name]] [sasl_bind_send] (0x0100):
Executing sasl bind mech: GSS-SPNEGO, user: PCNAME$
(2021-05-06 9:49:26): [be[domain.name]] [ad_sasl_log] (0x0040): SASL: No
worthy mechs found
(2021-05-06 9:49:26): [be[domain.name]] [sasl_bind_send] (0x0020):
ldap_sasl_interactive_bind_s failed (-6)[Unknown authentication method]
(2021-05-06 9:49:26): [be[domain.name]] [sasl_bind_send] (0x0080):
Extended failure message: [SASL(-4): no mechanism available: No worthy
mechs found]
(2021-05-06 9:49:26): [be[domain.name]] [sdap_cli_connect_recv] (0x0040):
Unable to establish connection [1432158227]: Authentication Failed
(2021-05-06 9:49:26): [be[domain.name]] [fo_set_port_status] (0x0100):
Marking port 389 of server 'dc1.domain.name' as 'not working'
I tried to rejoin domain with
krb5.conf
allow_weak_crypto = true
permitted_enctypes = aes rc4
then with commands:
KRB5_TRACE=/dev/stdout kinit -V aduser(a)AD.EXAMPLE.COM.
kinit Administrator
net ads join -k
klist -ke
Keytab looks like that:
10 06.05.2021 09:49:09 restrictedkrbhost/pcname.domain.name(a)DOMAIN.NAME
(aes256-cts-hmac-sha1-96)
10 06.05.2021 09:49:09 restrictedkrbhost/PCNAME(a)DOMAIN.NAME
(aes256-cts-hmac-sha1-96)
10 06.05.2021 09:49:09 restrictedkrbhost/pcname.domain.name(a)DOMAIN.NAME
(aes128-cts-hmac-sha1-96)
10 06.05.2021 09:49:09 restrictedkrbhost/PCNAME(a)DOMAIN.NAME
(aes128-cts-hmac-sha1-96)
10 06.05.2021 09:49:09 restrictedkrbhost/pcname.domain.name(a)DOMAIN.NAME
(DEPRECATED:arcfour-hmac)
10 06.05.2021 09:49:09 restrictedkrbhost/PCNAME(a)DOMAIN.NAME
(DEPRECATED:arcfour-hmac)
10 06.05.2021 09:49:10 host/pcname.domain.name(a)DOMAIN.NAME
(aes256-cts-hmac-sha1-96)
10 06.05.2021 09:49:10 host/PCNAME(a)DOMAIN.NAME (aes256-cts-hmac-sha1-96)
10 06.05.2021 09:49:10 host/pcname.domain.name(a)DOMAIN.NAME
(aes128-cts-hmac-sha1-96)
10 06.05.2021 09:49:10 host/PCNAME(a)DOMAIN.NAME (aes128-cts-hmac-sha1-96)
10 06.05.2021 09:49:10 host/pcname.domain.name(a)DOMAIN.NAME
(DEPRECATED:arcfour-hmac)
10 06.05.2021 09:49:10 host/PCNAME(a)DOMAIN.NAME (DEPRECATED:arcfour-hmac)
10 06.05.2021 09:49:10 PCNAME$(a)DOMAIN.NAME (aes256-cts-hmac-sha1-96)
10 06.05.2021 09:49:10 PCNAME$(a)DOMAIN.NAME (aes128-cts-hmac-sha1-96)
10 06.05.2021 09:49:10 PCNAME$(a)DOMAIN.NAME (DEPRECATED:arcfour-hmac)
Both kinit and ldapsearch are working properly.
Thanks for help!
-----
Pawel
2 years, 11 months
How to lower case home dirs in sssd with AD as a backend?
by Spike White
sssd experts,
With an AD backend, by default the AD provider sets case_sensitive ==
False. This has the desired action of lower-casing user names. (and group
names). But not home directories.
How can we similarly lower case home directories? Our AD admins have an
edict to camel-case their home directory and user name entries in AD.
(Apparently, some high-level manager wishes to see user names in camel
case.)
In our old commercial AD integration product, it had a setting:
lowercase-homedirs = true
and then it took whatever it found in AD and merely lower cased it.
To sort of work around this problem when doing a sssd migration, we have
set:
[nss]
override_homedirs = /home/%u
This works. But effectively, this is throwing out whatever is in AD and
replacing it with /home/<lower case user name>
This only works because all our home dirs. are under /home. What about
other companies that need to lower-case their home dirs., but they’re not
always under /home? How would you lower-case home dirs. in sssd?
Spike
2 years, 11 months
sssd: new project website
by Pavel Březina
I am proud to announce that the new project website is online at:
https://sssd.io
We've worked hard the last couple of months to update our current
documentation and bring better user experience.
What's new:
* All content is now up to date with latest SSSD version
* New contribution guide so new contributors (both internal and
external) can quickly pick up on SSSD specifics
* New user-facing content
We will keep adding new content in the following months. You can also
contribute to the documentation by submitting pull requests to this
repository:
https://github.com/SSSD/sssd.io
We will try hard to keep to documentation up to date to make it more
useful for the community.
2 years, 11 months
