Starting SSSD without root
by Tero Saarni
Hi,
I'm trying to run SSSD inside docker container without root user. The
container is executed in OpenShift cluster which does not allow running as root
inside container.
SSSD requires root and checks for this specifically.
Is there any workaround for this?
I believe the limitation is implemented for security reasons, in order to have
most critical parts executed as root and have it drop privileges for other
parts but this now completely blocks using SSSD in the above environment.
--
Tero
1 week, 2 days
Password expiration in AD with SSSD
by Paweł Szafer
Hi,
I want to warn users when password expiration days are less than 14 days.
I have GPO Default domain policy with this number of days.
I have sssd.conf as:
[sssd]
domains = internal.domain.tld
config_file_version = 2
services = nss, pam
[domain/internal.domain.tld]
cache_credentials = True
debug_level = 6
id_provider = ad
auth_provider = ad
access_provider = ad
default_shell = /bin/bash
fallback_homedir = /home/%d/%u
ldap_id_mapping = True
ldap_schema = ad
enumerate = True
ad_site=internal1
ad_gpo_access_control = permissive
ad_gpo_ignore_unreadable = True
And pam.d as follow:
#%PAM-1.0
auth sufficient pam_sss.so forward_pass
auth required pam_unix.so try_first_pass nullok
auth optional pam_permit.so
auth required pam_env.so
#auth requisite pam_deny.so
account required pam_unix.so
account [default=bad success=ok user_unknown=ignore] pam_sss.so
account optional pam_permit.so
account required pam_time.so
password required pam_unix.so try_first_pass nullok sha512 shadow
password sufficient pam_sss.so
use_authok
password optional pam_permit.so
session required pam_mkhomedir.so
skel=/etc/skel/ umask=0022
session required pam_limits.so
session required pam_unix.so
session optional pam_sss.so
session optional pam_permit.so
User has password valid till 20.02.2020 and yet I don't have any warning.
I had to add ad_gpo_ignore_unreadable = True and ad_gpo_access_control =
permissive to my config because without it I end up with "System error"
during login and unsuccessful login.
In gpo_cache I see Machine gpo with lines:
[Registry Values]
MACHINE\Software\Microsoft\Windows
NT\CurrentVersion\Winlogon\PasswordExpiryWarning=4,14
Any idea how to turn on this warning?
Thanks for your help!
-----
Best regards,
Pawel
1 month, 1 week
[hs@schlittermann.de: sssd nss: issues with applications not using endpwent()]
by Heiko Schlittermann
Hi,
I sent this to sssd-devel already, but probably it was the wrong
channel, so I'm trying it here.
I'm using Dovecot with its "passwd" userdb, which effectivly uses NSS.
NSS services are provided by the files and by the sss "plugins".
The `doveadm user *` command enumerates the list of users. Repeating the
command doesn't enumerate the users provided by sssd again.
Analyzing this issue reveals:
Dovecot uses a long living process talking to NSS. For user
enumeration it uses
setpwent()
while (…) { getpwent(); }
and then misses the call to endpwent(). This bug is already confirmed by
the Dovecot developers.
I'm not sure about the semantics of setpwent()/endpwend(), especially
about calling sequences like
setpwent()
while (…) { getpwent(); }
setpwent()
while (…) { getpwent(); }
According to setpwent(3) it should rewind to the beginning. Calling
endpwent() seems to be for curtesy only (to have resources freed)
I suggest calling a preventive endpwent() before using setpwent() again
in nss_cmd.c.
Attached you'll find my patch. I'd be happy about review and integration into
upstream.
Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de ---------------------------- internet & unix support -
Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
gnupg encrypted messages are welcome --------------- key ID: F69376CE -
1 month, 1 week
Re: SSSD-AD Password auth at 2.3 level (CentOS 8)?
by Justin Stephenson
Hi,
You are right, the question is why does a second ldap child get forked
- the /var/log/sssd/domain_$domain.log should give some clues. As a
guess you may need to set `ad_enabled_domains = domain.bu.edu' in
sssd.conf to disable auto discovery of trusted domains. If this
doesn't help please send me the sanitized domain log directly and I
can take a look.
-Justin
On Tue, Feb 23, 2021 at 2:21 PM Conwell, Nik <nik(a)bu.edu> wrote:
>
> Hi all, can anyone offer some insight into how password authentication works with sssd-ad on the 2.3 version (CentOS 8)? It doesn’t seem to working as it was under the 1.16. Details below.
>
>
>
> We’ve been running SSSD 1.16 on CentOS7 for a while without issue. But on CentOS 8 at the 2.3 levels we are having issues with AD password auth. Authenticating in with KRB5 works just fine, we’re able to realm join, get the keytabs, etc., that all seems reasonable.
>
>
>
> The issue with the password auth not working seems to be related to SSSD not being able to get a service ticket for the host/myhost.bu.edu@DOMAIN possibly making an unauthenticated call instead of previously using the krb5tgt in the /var/lib/sss/db ccache?
>
>
>
> Cranking up debug I see ldap_child working fine when getting our initial TGT:
>
>
>
> (2021-02-23 11:31:29): [ldap_child[1485202]] [main] (0x0400): ldap_child started.
>
> (2021-02-23 11:31:29): [ldap_child[1485202]] [main] (0x2000): context initialized
>
> (2021-02-23 11:31:29): [ldap_child[1485202]] [unpack_buffer] (0x1000): total buffer size: 41
>
> (2021-02-23 11:31:29): [ldap_child[1485202]] [unpack_buffer] (0x1000): realm_str size: 9
>
> (2021-02-23 11:31:29): [ldap_child[1485202]] [unpack_buffer] (0x1000): got realm_str: [DOMAIN.BU.EDU]
>
> (2021-02-23 11:31:29): [ldap_child[1485202]] [unpack_buffer] (0x1000): princ_str size: 8
>
> (2021-02-23 11:31:29): [ldap_child[1485202]] [unpack_buffer] (0x1000): got princ_str: [server]$
>
> (2021-02-23 11:31:29): [ldap_child[1485202]] [unpack_buffer] (0x1000): keytab_name size: 0
>
> (2021-02-23 11:31:29): [ldap_child[1485202]] [unpack_buffer] (0x1000): lifetime: 86400
>
> (2021-02-23 11:31:29): [ldap_child[1485202]] [unpack_buffer] (0x0200): Will run as [0][0].
>
> […]
>
> (2021-02-23 11:31:29): [ldap_child[1485202]] [main] (0x2000): getting TGT sync
>
> (2021-02-23 11:31:29): [ldap_child[1485202]] [ldap_child_get_tgt_sync] (0x2000): got realm_name: [DOMAIN.BU.EDU]
>
> (2021-02-23 11:31:29): [ldap_child[1485202]] [ldap_child_get_tgt_sync] (0x0100): Principal name is: [server]$(a)DOMAIN.BU.EDU]
>
> (2021-02-23 11:31:29): [ldap_child[1485202]] [ldap_child_get_tgt_sync] (0x0100): Using keytab [MEMORY:/etc/krb5.keytab]
>
> (2021-02-23 11:31:29): [ldap_child[1485202]] [sss_child_krb5_trace_cb] (0x4000): [1485202] 1614097889.649498: Getting initial credentials for [server]$(a)DOMAIN.BU.EDU
>
> (2021-02-23 11:31:29): [ldap_child[1485202]] [sss_child_krb5_trace_cb] (0x4000): [1485202] 1614097889.649499: Looked up etypes in keytab: aes128-cts, aes256-cts
>
> (2021-02-23 11:31:29): [ldap_child[1485202]] [sss_child_krb5_trace_cb] (0x4000): [1485202] 1614097889.649501: Sending unauthenticated request
>
> […]
>
> (2021-02-23 11:31:29): [ldap_child[1485202]] [sss_child_krb5_trace_cb] (0x4000): [1485202] 1614097889.649507: Response was from master KDC
>
> (2021-02-23 11:31:29): [ldap_child[1485202]] [sss_child_krb5_trace_cb] (0x4000): [1485202] 1614097889.649508: Received error from KDC: -1765328359/Additional pre-authentication required
>
> (2021-02-23 11:31:29): [ldap_child[1485202]] [sss_child_krb5_trace_cb] (0x4000): [1485202] 1614097889.649511: Preauthenticating using KDC method data
>
> (2021-02-23 11:31:29): [ldap_child[1485202]] [sss_child_krb5_trace_cb] (0x4000): [1485202] 1614097889.649512: Processing preauth types: PA-PK-AS-REQ (16), PA-PK-AS-REP_OLD (15), PA-ETYPE-INFO2 (19), PA-ENC-TIMESTAMP (2)
>
> […]
>
> (2021-02-23 11:31:29): [ldap_child[1485202]] [sss_child_krb5_trace_cb] (0x4000): [1485202] 1614097889.649525: Response was from master KDC
>
> […]
>
> (2021-02-23 11:31:29): [ldap_child[1485202]] [ldap_child_get_tgt_sync] (0x2000): credentials initialized
>
> (2021-02-23 11:31:29): [ldap_child[1485202]] [ldap_child_get_tgt_sync] (0x2000): keytab ccname: [FILE:/var/lib/sss/db/ccache_DOMAIN.BU.EDU_j0b5Vd]
>
> (2021-02-23 11:31:29): [ldap_child[1485202]] [sss_child_krb5_trace_cb] (0x4000): [1485202] 1614097889.649532: Initializing FILE:/var/lib/sss/db/ccache_DOMAIN.BU.EDU_j0b5Vd with default princ server$(a)DOMAIN.BU.EDU
>
> […]
>
> (2021-02-23 11:31:29): [ldap_child[1485202]] [ldap_child_get_tgt_sync] (0x2000): credentials stored
>
> (2021-02-23 11:31:29): [ldap_child[1485202]] [ldap_child_get_tgt_sync] (0x2000): Got KDC time offset
>
> (2021-02-23 11:31:29): [ldap_child[1485202]] [ldap_child_get_tgt_sync] (0x2000): Renaming [/var/lib/sss/db/ccache_DOMAIN.BU.EDU_j0b5Vd] to [/var/lib/sss/db/ccache_DOMAIN.BU.EDU]
>
> […]
>
> (2021-02-23 11:31:29): [ldap_child[1485202]] [pack_buffer] (0x1000): result [0] krberr [0] msgsize [37] msg [FILE:/var/lib/sss/db/ccache_DOMAIN.BU.EDU]
>
> (2021-02-23 11:31:29): [ldap_child[1485202]] [main] (0x0400): ldap_child completed successfully
>
>
>
> But then right after I see ldap_child being called to get a host ticket:
>
>
>
> (2021-02-23 11:31:29): [ldap_child[1485203]] [main] (0x0400): ldap_child started.
>
> (2021-02-23 11:31:29): [ldap_child[1485203]] [main] (0x2000): context initialized
>
> (2021-02-23 11:31:29): [ldap_child[1485203]] [unpack_buffer] (0x1000): total buffer size: 52
>
> (2021-02-23 11:31:29): [ldap_child[1485203]] [unpack_buffer] (0x1000): realm_str size: 9
>
> (2021-02-23 11:31:29): [ldap_child[1485203]] [unpack_buffer] (0x1000): got realm_str: DOMAIN.BU.EDU
>
> (2021-02-23 11:31:29): [ldap_child[1485203]] [unpack_buffer] (0x1000): princ_str size: 19
>
> (2021-02-23 11:31:29): [ldap_child[1485203]] [unpack_buffer] (0x1000): got princ_str: host/server.bu.edu
>
> (2021-02-23 11:31:29): [ldap_child[1485203]] [unpack_buffer] (0x1000): keytab_name size: 0
>
> (2021-02-23 11:31:29): [ldap_child[1485203]] [unpack_buffer] (0x1000): lifetime: 86400
>
> (2021-02-23 11:31:29): [ldap_child[1485203]] [unpack_buffer] (0x0200): Will run as [0][0].
>
> (2021-02-23 11:31:29): [ldap_child[1485203]] [privileged_krb5_setup] (0x2000): Kerberos context initialized
>
> (2021-02-23 11:31:29): [ldap_child[1485203]] [main] (0x2000): Kerberos context initialized
>
> (2021-02-23 11:31:29): [ldap_child[1485203]] [become_user] (0x0200): Trying to become user [0][0].
>
> (2021-02-23 11:31:29): [ldap_child[1485203]] [become_user] (0x0200): Already user [0].
>
> (2021-02-23 11:31:29): [ldap_child[1485203]] [main] (0x2000): Running as [0][0].
>
> (2021-02-23 11:31:29): [ldap_child[1485203]] [main] (0x2000): getting TGT sync
>
> (2021-02-23 11:31:29): [ldap_child[1485203]] [ldap_child_get_tgt_sync] (0x2000): got realm_name: [DOMAIN.BU.EDU]
>
> (2021-02-23 11:31:29): [ldap_child[1485203]] [ldap_child_get_tgt_sync] (0x0100): Principal name is: [host/server.bu.edu(a)DOMAIN.BU.EDU]
>
> (2021-02-23 11:31:29): [ldap_child[1485203]] [ldap_child_get_tgt_sync] (0x0100): Using keytab [MEMORY:/etc/krb5.keytab]
>
> (2021-02-23 11:31:29): [ldap_child[1485203]] [sss_child_krb5_trace_cb] (0x4000): [1485203] 1614097889.687429: Getting initial credentials for host/server.bu.edu(a)DOMAIN.BU.EDU
>
> (2021-02-23 11:31:29): [ldap_child[1485203]] [sss_child_krb5_trace_cb] (0x4000): [1485203] 1614097889.687430: Looked up etypes in keytab: aes128-cts, aes256-cts
>
> (2021-02-23 11:31:29): [ldap_child[1485203]] [sss_child_krb5_trace_cb] (0x4000): [1485203] 1614097889.687432: Sending unauthenticated request
>
> (2021-02-23 11:31:29): [ldap_child[1485203]] [sss_child_krb5_trace_cb] (0x4000): [1485203] 1614097889.687433: Sending request (213 bytes) to DOMAIN.BU.EDU
>
> (2021-02-23 11:31:29): [ldap_child[1485203]] [sss_child_krb5_trace_cb] (0x4000): [1485203] 1614097889.687434: Initiating TCP connection to stream [IP]:88
>
> (2021-02-23 11:31:29): [ldap_child[1485203]] [sss_child_krb5_trace_cb] (0x4000): [1485203] 1614097889.687435: Sending TCP request to stream [IP]:88
>
> (2021-02-23 11:31:29): [ldap_child[1485203]] [sss_child_krb5_trace_cb] (0x4000): [1485203] 1614097889.687436: Received answer (90 bytes) from stream [IP]:88
>
> (2021-02-23 11:31:29): [ldap_child[1485203]] [sss_child_krb5_trace_cb] (0x4000): [1485203] 1614097889.687437: Terminating TCP connection to stream [IP]:88
>
> (2021-02-23 11:31:29): [ldap_child[1485203]] [sss_child_krb5_trace_cb] (0x4000): [1485203] 1614097889.687438: Response was from master KDC
>
> (2021-02-23 11:31:29): [ldap_child[1485203]] [sss_child_krb5_trace_cb] (0x4000): [1485203] 1614097889.687439: Received error from KDC: -1765328378/Client not found in Kerberos database
>
> (2021-02-23 11:31:29): [ldap_child[1485203]] [ldap_child_get_tgt_sync] (0x0040): krb5_get_init_creds_keytab() failed: -1765328378
>
> (2021-02-23 11:31:29): [ldap_child[1485203]] [ldap_child_get_tgt_sync] (0x0010): Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]: Client 'host/server.bu.edu(a)DOMAIN.BU.EDU' not found in Kerberos database. Unable to create GSSAPI-encrypted LDAP connection.
>
> (2021-02-23 11:31:29): [ldap_child[1485203]] [unique_filename_destructor] (0x2000): Unlinking [/var/lib/sss/db/ccache_DOMAIN.BU.EDU_O03KMi]
>
> (2021-02-23 11:31:29): [ldap_child[1485203]] [main] (0x0020): ldap_child_get_tgt_sync failed.
>
>
>
>
>
> My /etc/krb5.keytab has a usable key:
>
>
>
> [root@server sssd]# kinit nik
>
> Password for nik(a)DOMAIN.BU.EDU:
>
> [root@server sssd]# klist
>
> Ticket cache: KCM:0
>
> Default principal: nik(a)DOMAIN.BU.EDU
>
>
>
> Valid starting Expires Service principal
>
> 02/23/2021 12:50:18 02/23/2021 22:50:18 krbtgt/DOMAIN.BU.EDU(a)DOMAIN.BU.EDU
>
> renew until 03/02/2021 12:50:15
>
> [root@server sssd]# klist -k
>
> Keytab name: FILE:/etc/krb5.keytab
>
> KVNO Principal
>
> ---- --------------------------------------------------------------------------
>
> 4 server$(a)DOMAIN.BU.EDU
>
> 4 server$(a)DOMAIN.BU.EDU
>
> 4 host/server(a)DOMAIN.BU.EDU
>
> 4 host/server(a)DOMAIN.BU.EDU
>
> 4 host/server.bu.edu(a)DOMAIN.BU.EDU
>
> 4 host/server.bu.edu(a)DOMAIN.BU.EDU
>
> 4 RestrictedKrbHost/server(a)DOMAIN.BU.EDU
>
> 4 RestrictedKrbHost/server(a)DOMAIN.BU.EDU
>
> 4 RestrictedKrbHost/server.bu.edu(a)DOMAIN.BU.EDU
>
> 4 RestrictedKrbHost/server.bu.edu(a)DOMAIN.BU.EDU
>
> [root@server sssd]# kvno 'host/server.bu.edu(a)DOMAIN.BU.EDU'
>
> host/server.bu.edu(a)DOMAIN.BU.EDU: kvno = 4
>
> [root@server sssd]# klist
>
> Ticket cache: KCM:0
>
> Default principal: nik(a)DOMAIN.BU.EDU
>
>
>
> Valid starting Expires Service principal
>
> 02/23/2021 12:50:18 02/23/2021 22:50:18 krbtgt/DOMAIN.BU.EDU(a)DOMAIN.BU.EDU
>
> renew until 03/02/2021 12:50:15
>
> 02/23/2021 12:50:37 02/23/2021 22:50:18 host/server.bu.edu(a)DOMAIN.BU.EDU
>
>
>
>
>
>
>
> When I KRB5_TRACE=/dev/stdout that kvno command then I see that the client uses the TGT to make an authenticated call to get the service ticket. But in SSSD when the ldap_client runs the second time to get the host/server.bu.edu service ticket it makes an unauthenticated call and doesn’t seem to be using the krb5tgt previously returned. Am I missing something about the use of the credential cache (/var/lib/sss/db/ccache_DOMAIN.BU.EDU) for this second call that’s causing things to break?
>
>
>
> I don’t have a good sense of how things should work, and comparing with the working 1.9 shows that there’s no use of the host/server.bu.edu(a)DOMAIN.BU.EDU service ticket at all for password based authentication.
>
>
>
> Does somebody who has this working at the 2.3 level have a good sense of how things should look normally so I can figure out where I’m going off the rails here?
>
>
>
> Thanks.
>
> -nik
>
>
>
>
>
> Nik Conwell | Manager, Systems Engineering
> Boston University Information Services & Technology
> nik(a)bu.edu | 617.353.8274 | bu.edu/tech
>
>
>
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> 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/sssd-users@lists.fedorahoste...
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
1 month, 2 weeks
SSSD-AD Password auth at 2.3 level (CentOS 8)?
by Conwell, Nik
Hi all, can anyone offer some insight into how password authentication works with sssd-ad on the 2.3 version (CentOS 8)? It doesn't seem to working as it was under the 1.16. Details below.
We've been running SSSD 1.16 on CentOS7 for a while without issue. But on CentOS 8 at the 2.3 levels we are having issues with AD password auth. Authenticating in with KRB5 works just fine, we're able to realm join, get the keytabs, etc., that all seems reasonable.
The issue with the password auth not working seems to be related to SSSD not being able to get a service ticket for the host/myhost.bu.edu@DOMAIN<mailto:host/myhost.bu.edu@DOMAIN> possibly making an unauthenticated call instead of previously using the krb5tgt in the /var/lib/sss/db ccache?
Cranking up debug I see ldap_child working fine when getting our initial TGT:
(2021-02-23 11:31:29): [ldap_child[1485202]] [main] (0x0400): ldap_child started.
(2021-02-23 11:31:29): [ldap_child[1485202]] [main] (0x2000): context initialized
(2021-02-23 11:31:29): [ldap_child[1485202]] [unpack_buffer] (0x1000): total buffer size: 41
(2021-02-23 11:31:29): [ldap_child[1485202]] [unpack_buffer] (0x1000): realm_str size: 9
(2021-02-23 11:31:29): [ldap_child[1485202]] [unpack_buffer] (0x1000): got realm_str: [DOMAIN.BU.EDU]
(2021-02-23 11:31:29): [ldap_child[1485202]] [unpack_buffer] (0x1000): princ_str size: 8
(2021-02-23 11:31:29): [ldap_child[1485202]] [unpack_buffer] (0x1000): got princ_str: [server]$
(2021-02-23 11:31:29): [ldap_child[1485202]] [unpack_buffer] (0x1000): keytab_name size: 0
(2021-02-23 11:31:29): [ldap_child[1485202]] [unpack_buffer] (0x1000): lifetime: 86400
(2021-02-23 11:31:29): [ldap_child[1485202]] [unpack_buffer] (0x0200): Will run as [0][0].
[...]
(2021-02-23 11:31:29): [ldap_child[1485202]] [main] (0x2000): getting TGT sync
(2021-02-23 11:31:29): [ldap_child[1485202]] [ldap_child_get_tgt_sync] (0x2000): got realm_name: [DOMAIN.BU.EDU]
(2021-02-23 11:31:29): [ldap_child[1485202]] [ldap_child_get_tgt_sync] (0x0100): Principal name is: [server]$(a)DOMAIN.BU.EDU]
(2021-02-23 11:31:29): [ldap_child[1485202]] [ldap_child_get_tgt_sync] (0x0100): Using keytab [MEMORY:/etc/krb5.keytab]
(2021-02-23 11:31:29): [ldap_child[1485202]] [sss_child_krb5_trace_cb] (0x4000): [1485202] 1614097889.649498: Getting initial credentials for [server]$(a)DOMAIN.BU.EDU
(2021-02-23 11:31:29): [ldap_child[1485202]] [sss_child_krb5_trace_cb] (0x4000): [1485202] 1614097889.649499: Looked up etypes in keytab: aes128-cts, aes256-cts
(2021-02-23 11:31:29): [ldap_child[1485202]] [sss_child_krb5_trace_cb] (0x4000): [1485202] 1614097889.649501: Sending unauthenticated request
[...]
(2021-02-23 11:31:29): [ldap_child[1485202]] [sss_child_krb5_trace_cb] (0x4000): [1485202] 1614097889.649507: Response was from master KDC
(2021-02-23 11:31:29): [ldap_child[1485202]] [sss_child_krb5_trace_cb] (0x4000): [1485202] 1614097889.649508: Received error from KDC: -1765328359/Additional pre-authentication required
(2021-02-23 11:31:29): [ldap_child[1485202]] [sss_child_krb5_trace_cb] (0x4000): [1485202] 1614097889.649511: Preauthenticating using KDC method data
(2021-02-23 11:31:29): [ldap_child[1485202]] [sss_child_krb5_trace_cb] (0x4000): [1485202] 1614097889.649512: Processing preauth types: PA-PK-AS-REQ (16), PA-PK-AS-REP_OLD (15), PA-ETYPE-INFO2 (19), PA-ENC-TIMESTAMP (2)
[...]
(2021-02-23 11:31:29): [ldap_child[1485202]] [sss_child_krb5_trace_cb] (0x4000): [1485202] 1614097889.649525: Response was from master KDC
[...]
(2021-02-23 11:31:29): [ldap_child[1485202]] [ldap_child_get_tgt_sync] (0x2000): credentials initialized
(2021-02-23 11:31:29): [ldap_child[1485202]] [ldap_child_get_tgt_sync] (0x2000): keytab ccname: [FILE:/var/lib/sss/db/ccache_DOMAIN.BU.EDU_j0b5Vd]
(2021-02-23 11:31:29): [ldap_child[1485202]] [sss_child_krb5_trace_cb] (0x4000): [1485202] 1614097889.649532: Initializing FILE:/var/lib/sss/db/ccache_DOMAIN.BU.EDU_j0b5Vd with default princ server$(a)DOMAIN.BU.EDU
[...]
(2021-02-23 11:31:29): [ldap_child[1485202]] [ldap_child_get_tgt_sync] (0x2000): credentials stored
(2021-02-23 11:31:29): [ldap_child[1485202]] [ldap_child_get_tgt_sync] (0x2000): Got KDC time offset
(2021-02-23 11:31:29): [ldap_child[1485202]] [ldap_child_get_tgt_sync] (0x2000): Renaming [/var/lib/sss/db/ccache_DOMAIN.BU.EDU_j0b5Vd] to [/var/lib/sss/db/ccache_DOMAIN.BU.EDU]
[...]
(2021-02-23 11:31:29): [ldap_child[1485202]] [pack_buffer] (0x1000): result [0] krberr [0] msgsize [37] msg [FILE:/var/lib/sss/db/ccache_DOMAIN.BU.EDU]
(2021-02-23 11:31:29): [ldap_child[1485202]] [main] (0x0400): ldap_child completed successfully
But then right after I see ldap_child being called to get a host ticket:
(2021-02-23 11:31:29): [ldap_child[1485203]] [main] (0x0400): ldap_child started.
(2021-02-23 11:31:29): [ldap_child[1485203]] [main] (0x2000): context initialized
(2021-02-23 11:31:29): [ldap_child[1485203]] [unpack_buffer] (0x1000): total buffer size: 52
(2021-02-23 11:31:29): [ldap_child[1485203]] [unpack_buffer] (0x1000): realm_str size: 9
(2021-02-23 11:31:29): [ldap_child[1485203]] [unpack_buffer] (0x1000): got realm_str: DOMAIN.BU.EDU
(2021-02-23 11:31:29): [ldap_child[1485203]] [unpack_buffer] (0x1000): princ_str size: 19
(2021-02-23 11:31:29): [ldap_child[1485203]] [unpack_buffer] (0x1000): got princ_str: host/server.bu.edu
(2021-02-23 11:31:29): [ldap_child[1485203]] [unpack_buffer] (0x1000): keytab_name size: 0
(2021-02-23 11:31:29): [ldap_child[1485203]] [unpack_buffer] (0x1000): lifetime: 86400
(2021-02-23 11:31:29): [ldap_child[1485203]] [unpack_buffer] (0x0200): Will run as [0][0].
(2021-02-23 11:31:29): [ldap_child[1485203]] [privileged_krb5_setup] (0x2000): Kerberos context initialized
(2021-02-23 11:31:29): [ldap_child[1485203]] [main] (0x2000): Kerberos context initialized
(2021-02-23 11:31:29): [ldap_child[1485203]] [become_user] (0x0200): Trying to become user [0][0].
(2021-02-23 11:31:29): [ldap_child[1485203]] [become_user] (0x0200): Already user [0].
(2021-02-23 11:31:29): [ldap_child[1485203]] [main] (0x2000): Running as [0][0].
(2021-02-23 11:31:29): [ldap_child[1485203]] [main] (0x2000): getting TGT sync
(2021-02-23 11:31:29): [ldap_child[1485203]] [ldap_child_get_tgt_sync] (0x2000): got realm_name: [DOMAIN.BU.EDU]
(2021-02-23 11:31:29): [ldap_child[1485203]] [ldap_child_get_tgt_sync] (0x0100): Principal name is: [host/server.bu.edu(a)DOMAIN.BU.EDU]
(2021-02-23 11:31:29): [ldap_child[1485203]] [ldap_child_get_tgt_sync] (0x0100): Using keytab [MEMORY:/etc/krb5.keytab]
(2021-02-23 11:31:29): [ldap_child[1485203]] [sss_child_krb5_trace_cb] (0x4000): [1485203] 1614097889.687429: Getting initial credentials for host/server.bu.edu(a)DOMAIN.BU.EDU
(2021-02-23 11:31:29): [ldap_child[1485203]] [sss_child_krb5_trace_cb] (0x4000): [1485203] 1614097889.687430: Looked up etypes in keytab: aes128-cts, aes256-cts
(2021-02-23 11:31:29): [ldap_child[1485203]] [sss_child_krb5_trace_cb] (0x4000): [1485203] 1614097889.687432: Sending unauthenticated request
(2021-02-23 11:31:29): [ldap_child[1485203]] [sss_child_krb5_trace_cb] (0x4000): [1485203] 1614097889.687433: Sending request (213 bytes) to DOMAIN.BU.EDU
(2021-02-23 11:31:29): [ldap_child[1485203]] [sss_child_krb5_trace_cb] (0x4000): [1485203] 1614097889.687434: Initiating TCP connection to stream [IP]:88
(2021-02-23 11:31:29): [ldap_child[1485203]] [sss_child_krb5_trace_cb] (0x4000): [1485203] 1614097889.687435: Sending TCP request to stream [IP]:88
(2021-02-23 11:31:29): [ldap_child[1485203]] [sss_child_krb5_trace_cb] (0x4000): [1485203] 1614097889.687436: Received answer (90 bytes) from stream [IP]:88
(2021-02-23 11:31:29): [ldap_child[1485203]] [sss_child_krb5_trace_cb] (0x4000): [1485203] 1614097889.687437: Terminating TCP connection to stream [IP]:88
(2021-02-23 11:31:29): [ldap_child[1485203]] [sss_child_krb5_trace_cb] (0x4000): [1485203] 1614097889.687438: Response was from master KDC
(2021-02-23 11:31:29): [ldap_child[1485203]] [sss_child_krb5_trace_cb] (0x4000): [1485203] 1614097889.687439: Received error from KDC: -1765328378/Client not found in Kerberos database
(2021-02-23 11:31:29): [ldap_child[1485203]] [ldap_child_get_tgt_sync] (0x0040): krb5_get_init_creds_keytab() failed: -1765328378
(2021-02-23 11:31:29): [ldap_child[1485203]] [ldap_child_get_tgt_sync] (0x0010): Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]: Client 'host/server.bu.edu(a)DOMAIN.BU.EDU' not found in Kerberos database. Unable to create GSSAPI-encrypted LDAP connection.
(2021-02-23 11:31:29): [ldap_child[1485203]] [unique_filename_destructor] (0x2000): Unlinking [/var/lib/sss/db/ccache_DOMAIN.BU.EDU_O03KMi]
(2021-02-23 11:31:29): [ldap_child[1485203]] [main] (0x0020): ldap_child_get_tgt_sync failed.
My /etc/krb5.keytab has a usable key:
[root@server sssd]# kinit nik
Password for nik(a)DOMAIN.BU.EDU:
[root@server sssd]# klist
Ticket cache: KCM:0
Default principal: nik(a)DOMAIN.BU.EDU
Valid starting Expires Service principal
02/23/2021 12:50:18 02/23/2021 22:50:18 krbtgt/DOMAIN.BU.EDU(a)DOMAIN.BU.EDU
renew until 03/02/2021 12:50:15
[root@server sssd]# klist -k
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
4 server$(a)DOMAIN.BU.EDU
4 server$(a)DOMAIN.BU.EDU
4 host/server(a)DOMAIN.BU.EDU
4 host/server(a)DOMAIN.BU.EDU
4 host/server.bu.edu(a)DOMAIN.BU.EDU
4 host/server.bu.edu(a)DOMAIN.BU.EDU
4 RestrictedKrbHost/server(a)DOMAIN.BU.EDU
4 RestrictedKrbHost/server(a)DOMAIN.BU.EDU
4 RestrictedKrbHost/server.bu.edu(a)DOMAIN.BU.EDU
4 RestrictedKrbHost/server.bu.edu(a)DOMAIN.BU.EDU
[root@server sssd]# kvno 'host/server.bu.edu(a)DOMAIN.BU.EDU'
host/server.bu.edu(a)DOMAIN.BU.EDU: kvno = 4
[root@server sssd]# klist
Ticket cache: KCM:0
Default principal: nik(a)DOMAIN.BU.EDU
Valid starting Expires Service principal
02/23/2021 12:50:18 02/23/2021 22:50:18 krbtgt/DOMAIN.BU.EDU(a)DOMAIN.BU.EDU
renew until 03/02/2021 12:50:15
02/23/2021 12:50:37 02/23/2021 22:50:18 host/server.bu.edu(a)DOMAIN.BU.EDU<mailto:host/niktest.bu.edu@AD.BU.EDU>
When I KRB5_TRACE=/dev/stdout that kvno command then I see that the client uses the TGT to make an authenticated call to get the service ticket. But in SSSD when the ldap_client runs the second time to get the host/server.bu.edu service ticket it makes an unauthenticated call and doesn't seem to be using the krb5tgt previously returned. Am I missing something about the use of the credential cache (/var/lib/sss/db/ccache_DOMAIN.BU.EDU) for this second call that's causing things to break?
I don't have a good sense of how things should work, and comparing with the working 1.9 shows that there's no use of the host/server.bu.edu(a)DOMAIN.BU.EDU<mailto:host/server.bu.edu@DOMAIN.BU.EDU> service ticket at all for password based authentication.
Does somebody who has this working at the 2.3 level have a good sense of how things should look normally so I can figure out where I'm going off the rails here?
Thanks.
-nik
Nik Conwell | Manager, Systems Engineering
Boston University Information Services & Technology
nik(a)bu.edu<mailto:nik@bu.edu> | 617.353.8274 | bu.edu/tech<http://www.bu.edu/tech>
1 month, 2 weeks
session unlock with smartcard stops working when updating shared library
by Winberg Adam
We're using a third party shared library for communication with our smartcards, using RHEL 8.3. SSSD uses p11 to communicate with the cards, this works fine.
But, when I update the third party lib file to a new version, I can no longer unlock my Gnome session with the smart card. Debug logs shows the following in p11_child.log:
(2021-02-22 7:55:07): [p11_child[3059726]] [main] (0x0010): --module_name, --token_name and --key_id must be given for authentication
(2021-02-22 7:55:07): [p11_child[3059726]] [main] (0x0020): p11_child failed!
And in sssd_pam.log:
(2021-02-22 7:55:07): [pam] [parse_p11_child_response] (0x1000): No certificate found.
(2021-02-22 7:55:07): [pam] [pam_forwarder_cert_cb] (0x0020): No certificate returned, authentication failed.
I can use the smartcard for other actions, like sudo and logging in to a new session, but not to unlock the existing session. It's like some session specific data no longer is available or no longer matches when the lib file has changed on disk.
This makes it really hard to update the lib file on our users computers, seeing as doing so will effectively lock them out of their sessions. Does anyone recognize this behaviour and is there anything I can do to avoid it?
Regards
Adam Winberg
1 month, 2 weeks
Bug: Trying to get hostent from a name-less server / Server without name and address found in list.
by Anthony Joseph Messina
After upgrading to sssd-2.4.1-1.fc33.x86_64, I began seeing the following in my sssd_be log:
Bug: Trying to get hostent from a name-less server
Server without name and address found in list.
These entries occur at the time a user logins into cyrus-imapd via saslauthd.
salsauthd uses the PAM backend, which uses SSSD. I increased the log-level and
see the following, but am not sure how to interpret it, or if this is really an
issue. There are no problems with the users logging into cyrus-imapd.
Any pointers are appreciated. Thanks.
Feb 16 10:17:52 sssd_be[724]: Marking port 0 of duplicate server 'ipa.example.com' as 'working'
Feb 16 10:17:52 sssd_be[724]: DP Request [PAM Preauth #18362]: Request handler finished [0]: Success
Feb 16 10:17:52 sssd_be[724]: DP Request [PAM Preauth #18362]: Receiving request data.
Feb 16 10:17:52 sssd_be[724]: DP Request [PAM Preauth #18362]: Request removed.
Feb 16 10:17:52 sssd_be[724]: Number of active DP request: 1
Feb 16 10:17:52 sssd_be[724]: sssd.dataprovider.pamHandler: Success
Feb 16 10:17:52 sssd_be[724]: Constructed uri 'ldap://ipa.example.com'
Feb 16 10:17:52 sssd_be[724]: Bug: Trying to get hostent from a name-less server
Feb 16 10:17:52 sssd_be[724]: Server without name and address found in list.
Feb 16 10:17:52 sssd_be[724]: All data has been sent!
--
Anthony - https://messinet.com
F9B6 560E 68EA 037D 8C3D D1C9 FF31 3BDB D9D8 99B6
1 month, 2 weeks
problem obtaining kerberos ticket with sssd
by mbalembo
Hello,
I have trouble obtaining a kerberos ticket when loggin with sssd.
in /var/log/sssd/krb5_child.log i get the line :
[[sssd[krb5_child[9521]]]] [unpack_buffer] (0x0100): cmd [241] uid
[10007] gid [10000] validate [false] enterprise principal [true] offline
[false] UPN [USER@MYDOMAIN]
My problem is i need to restart the service to switch this to "offline
[false]".
(Note that authentication works otherwise, it's just the kerberos ticket
that is missing).
Maybe I missed an option to set the update rate ?
Thanks,
Marc
1 month, 3 weeks
sdap_save_user Failed to save user?
by Lachlan Simpson
Hi,
I'm having trouble getting results with IPA and SSSD, so I'm starting from first principles.
Running on RHEL 8.3, I have an IPA server (idm) and a test client (idm-test), with one way trusts to the company AD - both their adtest.company.com and production ad.company.com
I can't get id or ssh working on idm-test, so I went back to the IPA server to see if I can get id resolution there. This is what I'm seeing in /var/log/sssd/sssd_test.linux.company.com.log:
(2021-02-15 10:43:17): [be[test.linux.company.com]] [sdap_save_user] (0x0020): Failed to save user [z3530577(a)ad.company.com]
Here are the longer details
ipaserver = FreeIPA 4.8.7, SSSD 2.3.0
domain = test.linux.company.com
trusts = adtest.company.com, ad.company.com
[root@idm ~]# sssctl domain-list
implicit_files
test.linux.company.com
adtest.company.com
ad.company.com
[root@idm ~]# sssctl domain-status adtest.company.com
Online status: Online
...
[root@idm ~]# sssctl domain-status ad.company.com
Online status: Online
...
chronyd is set up against ntp.company.com
[root@idm ~]# id z3530577(a)adtest.company.com
uid=13530577(z3530577(a)adtest.company.com) gid=5000(company(a)test.linux.company.com) groups=5000(company(a)test.linux.company.com)
[root@idm ~]# getent passwd z3530577(a)adtest.company.com
z3530577@adtest.company.com:*:13530577:5000:Rajkumar Theeban:/home/adtest.company.com/z3530577:/bin/bash
[root@idm ~]# id z3530577(a)ad.company.com
id: ‘z3530577(a)ad.company.xn--com-to0a: no such user
[root@idm ~]# id z3530577(a)ad.company.com
id: ‘z3530577(a)ad.company.xn--com-to0a: no such user
As you can see, the user in ad.company.com can't be found.
Here is the log file /var/log/sssd/sssd_test.linux.company.com.log with more context /var/log/sssd/sssd_test.linux.company.com.log
(2021-02-15 10:43:17): [be[test.linux.company.com]] [sss_domain_get_state] (0x1000): Domain ad.company.com is Active
(2021-02-15 10:43:17): [be[test.linux.company.com]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(|(userPrincipalName=z3530577(a)ad.company.com
)(mail=z3530577@ad.company.com)(userPrincipalName=z3530577\\@ad.company.com@AD.company.com))(objectclass=user)(sAMAccountName=*)(objectSID=*))][dc=ad,dc=unsw,dc=edu,dc=
au].
(2021-02-15 10:43:17): [be[test.linux.company.com]] [sdap_get_generic_ext_add_references] (0x1000): Additional References: ldap://ad.company.com/CN=Configuration,DC=a
d,DC=unsw,DC=edu,DC=au
(2021-02-15 10:43:17): [be[test.linux.company.com]] [generic_ext_search_handler] (0x4000): Ref: ldap://ad.company.com/CN=Configuration,DC=ad,DC=unsw,DC=edu,DC=au
(2021-02-15 10:43:17): [be[test.linux.company.com]] [sss_domain_get_state] (0x1000): Domain ad.company.com is Active
(2021-02-15 10:43:17): [be[test.linux.company.com]] [sdap_save_user] (0x0400): Processing user z3530577(a)ad.company.com
(2021-02-15 10:43:17): [be[test.linux.company.com]] [sdap_save_user] (0x1000): Mapping user [z3530577(a)ad.company.com] objectSID [S-1-5-21-1140405718-358989843-3445714
273-3730445] to unix ID
(2021-02-15 10:43:17): [be[test.linux.company.com]] [sdap_save_user] (0x0020): Failed to save user [z3530577(a)ad.company.com]
(2021-02-15 10:43:17): [be[test.linux.company.com]] [sysdb_search_user_by_upn] (0x0400): No entry with upn [z3530577(a)ad.company.com] found.
1 month, 3 weeks
