May 2017 - sssd-users - Fedora mailing-lists

sssd performance on large domains
by zfnoctis＠gmail.com 03 Feb '22

03 Feb '22

Hi, I'm wondering if there are any plans to improve sssd performance on large active directory domains (100k+ users, 40k+ groups), or if there are settings I am not aware of that can greatly improve performance, specifically for workstation use cases. Currently if I do not set "ignore_group_members = True" in sssd.conf, logins can take upwards of 6 minutes and "sssd_be" will max the CPU for up to 20 minutes after logon, which makes it a non-starter. The reason I want to allow group members to be seen is that I want certain domain groups to be able to perform elevated actions using polkit. If I ignore group members, polkit reports that the group is empty and so no one can elevate in the graphical environment. Ultimately this means that Linux workstations are at a severe disadvantage since they cannot be bound to the domain and have the normal set of access features users and IT expect from macOS or Windows. Distributions used: Ubuntu 16.04 (sssd 1.13.4-1ubuntu1.1), Ubuntu 16.10 (sssd 1.13.4-3) and Fedora 24 (sssd-1.13.4-3.fc24). All exhibit the same problems. I've also tried "ldap_group_nesting_level = 1" without seeing any noticeable improvement with respect to performance. Putting the database on /tmp isn't viable as these are workstations that will reboot semi-frequently, and I don't believe this is an I/O bound performance issue anyways. Thanks for your time.

6 29

Enumerate users from external group from AD trust
by Bolke de Bruin 29 Nov '19

29 Nov '19

Hello, I have sssd 1.13.00 working against FreeIPA 4.2 domain. This domain has a trust relationship with a active directory domain. One of the systems we are using requires to enumerate all users in groups by (unfortunate) design (Apache Ranger). This is done by using “getent group”. During this enumeration the full user list for a group that has a nested external member group* is not always returned so we thought to add “getent group mygroup” in order to get more details. Unfortunately this does not seem to work consistently: sometimes this gives information sometimes it does not: [root@master centos]# getent group ad_users ad_users:*:1950000004: [root@master centos]# id bolke(a)ad.local UID=1796201107(bolke(a)ad.local) GID=1796201107(bolke(a)ad.local) groepen=1796201107(bolke(a)ad.local),1796200513(domain users@ad.local),1796201108(test@ad.local) [root@master centos]# getent group ad_users ad_users:*:1950000004:bolke@ad.local <mailto:bolke@ad.local> If I clear the cache (sss_cache -E) the entry is gone again: [root@master centos]# getent group ad_users ad_users:*:1950000004: My question is how do I get sssd to enumerate *all users* in a group consistently? Thanks! Bolke * https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/trust-gro…

3 15

Does anyone use id_provider=local ?
by Jakub Hrozek 16 Oct '17

16 Oct '17

Hi, are there any SSSD users who actively use a configuration with: id_provider=local ? If so, what is your use-case? We're considering deprecating and eventually removing this provider upstream. The replacemant for id_provider=local would be id_provider=files: https://fedorahosted.org/sssd/wiki/DesignDocs/FilesProvider which is already under review and later extension of the SSSD's D-Bus interface to allow manipulating custom user attributes. My current plan for deprecating the local provider is to only build the provider and the tools around it if a configure-time flag is provided. This flag would be disabled by default. Then, if noone complains, eventually just remove the code.

3 5

Re: kerberos ticket not renewed in 15.2/master
by Lukas Slebodnik 20 Jul '17

20 Jul '17

On (22/05/17 06:51), Joakim Tjernlund wrote: >On Fri, 2017-05-19 at 16:59 +0200, Lukas Slebodnik wrote: >> On (19/05/17 14:41), Joakim Tjernlund wrote: >> > On Fri, 2017-05-19 at 16:34 +0200, Lukas Slebodnik wrote: >> > > On (19/05/17 14:07), Joakim Tjernlund wrote: >> > > > Will do over the week end >> > > > >> > > > > >> > > > > Please also provide an output of following command >> > > > > rpm -V sssd-common sssd-krb5-common >> > > > >> > > > That is a bit hard as this is Gentoo :) >> > > >> > > Ahh sorry; >> > > >> > > I cannot see 1.15.2 in portage. >> > > Which arguments did you pass to configure? >> > >> > Sending the ebuilds I use, made by myself as upstream is lagging behind. >> > >> >> Logging to journald is not enabled enabled. So I do not think >> you fwill find anything in journald :-) >> >> sssd is not compiled with non-privileged user therefore >> it should not cause problems. >> >> We will not be able to move it forward without >> *child log files. >> >> LS > >Hi again > >Got some *child logs now. Can you make something of these? >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [main] (0x0400): ldap_child started. >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [main] (0x2000): context initialized >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [unpack_buffer] (0x1000): total buffer size: 49 >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [unpack_buffer] (0x1000): realm_str size: 12 >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [unpack_buffer] (0x1000): got realm_str: INFINERA.COM >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [unpack_buffer] (0x1000): princ_str size: 13 >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [unpack_buffer] (0x1000): got princ_str: GENTOO-LABBB$ >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [unpack_buffer] (0x1000): keytab_name size: 0 >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [unpack_buffer] (0x1000): lifetime: 86400 >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [unpack_buffer] (0x0200): Will run as [0][0]. >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [privileged_krb5_setup] (0x2000): Kerberos context initialized >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [main] (0x2000): Kerberos context initialized >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [become_user] (0x0200): Trying to become user [0][0]. >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [become_user] (0x0200): Already user [0]. >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [main] (0x2000): Running as [0][0]. >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [main] (0x2000): getting TGT sync >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [ldap_child_get_tgt_sync] (0x2000): got realm_name: [INFINERA.COM] >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [ldap_child_get_tgt_sync] (0x0100): Principal name is: [GENTOO-LABBB$(a)INFINERA.COM] >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [ldap_child_get_tgt_sync] (0x0100): Using keytab [MEMORY:/etc/krb5.keytab] >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [ldap_child_get_tgt_sync] (0x0100): Will canonicalize principals >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.430433: Getting initial credentials for GENTOO-LABBB$(a)INFINERA.COM > >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.430585: Looked up etypes in keytab: des-cbc-crc, des, des-cbc-crc, aes128-cts, aes256-cts, rc4-hmac > >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.430660: Sending request (203 bytes) to INFINERA.COM > >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.430840: Resolving hostname se-dc01.infinera.com > >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.431709: Sending initial UDP request to dgram 10.210.34.21:88 > >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.432672: Received answer (266 bytes) from dgram 10.210.34.21:88 > >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.432741: Response was not from master KDC > >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.432786: Received error from KDC: -1765328359/Additional pre-authentication required > >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.432851: Processing preauth types: 16, 15, 19, 2 > >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.432880: Selected etype info: etype aes256-cts, salt "INFINERA.COMhostgentoo-labbb.infinera.com", params "" > >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.432923: Retrieving GENTOO-LABBB$(a)INFINERA.COM from MEMORY:/etc/krb5.keytab (vno 0, enctype aes256-cts) with result: 0/Success > >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.432960: AS key obtained for encrypted timestamp: aes256-cts/645C > >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.433059: Encrypted timestamp (for 1495435577.276052): plain 301AA011180F32303137303532323036343631375AA1050203043654, encrypted 08B7186DAB549BD6AC8DCC76C9E88A5FB59619A42672B848C1CF6605E2AB5EFB54D0EDD8B8FC3D9BC154519791BD77F8938FBADEB6C9F65C > >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.433087: Preauth module encrypted_timestamp (2) (real) returned: 0/Success > >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.433103: Produced preauth for next request: 2 > >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.433137: Sending request (283 bytes) to INFINERA.COM > >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.433172: Resolving hostname se-dc01.infinera.com > >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.433387: Sending initial UDP request to dgram 10.210.34.21:88 > >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.434554: Received answer (96 bytes) from dgram 10.210.34.21:88 > >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.434603: Response was not from master KDC > >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.434624: Received error from KDC: -1765328332/Response too big for UDP, retry with TCP > >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.434636: Request or response is too big for UDP; retrying with TCP > >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.434647: Sending request (283 bytes) to INFINERA.COM (tcp only) > >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.434665: Resolving hostname se-dc01.infinera.com > >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.434807: Initiating TCP connection to stream 10.210.34.21:88 > >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.435110: Sending TCP request to stream 10.210.34.21:88 > >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.436061: Received answer (1543 bytes) from stream 10.210.34.21:88 > >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.436086: Terminating TCP connection to stream 10.210.34.21:88 > >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.436130: Response was not from master KDC > >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.436166: Processing preauth types: 19 > >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.436180: Selected etype info: etype aes256-cts, salt "INFINERA.COMhostgentoo-labbb.infinera.com", params "" > >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.436191: Produced preauth for next request: (empty) > >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.436204: AS key determined by preauth: aes256-cts/645C > >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.436268: Decrypted AS reply; session key is: aes256-cts/00F2 > >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.436287: FAST negotiation: unavailable > >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [ldap_child_get_tgt_sync] (0x2000): credentials initialized >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [ldap_child_get_tgt_sync] (0x2000): keytab ccname: [FILE:/var/lib/sss/db/ccache_INFINERA.COM_wwO4jb] >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.436396: Initializing FILE:/var/lib/sss/db/ccache_INFINERA.COM_wwO4jb with default princ GENTOO-LABBB$(a)INFINERA.COM > >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [sss_child_krb5_trace_cb] (0x4000): [17650] 1495435574.436543: Storing GENTOO-LABBB$(a)INFINERA.COM -> krbtgt/INFINERA.COM(a)INFINERA.COM in FILE:/var/lib/sss/db/ccache_INFINERA.COM_wwO4jb > >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [ldap_child_get_tgt_sync] (0x2000): credentials stored >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [ldap_child_get_tgt_sync] (0x2000): Got KDC time offset The time is not synchronised between client and server. MIT krb5 can handle small offset. But I would highly recommends to keep time in sync. >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [ldap_child_get_tgt_sync] (0x2000): Renaming [/var/lib/sss/db/ccache_INFINERA.COM_wwO4jb] to [/var/lib/sss/db/ccache_INFINERA.COM] >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [unique_filename_destructor] (0x2000): Unlinking [/var/lib/sss/db/ccache_INFINERA.COM_wwO4jb] >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [unlink_dbg] (0x2000): File already removed: [/var/lib/sss/db/ccache_INFINERA.COM_wwO4jb] >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [prepare_response] (0x0400): Building response for result [0] >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [pack_buffer] (0x2000): response size: 60 >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [pack_buffer] (0x1000): result [0] krberr [0] msgsize [40] msg [FILE:/var/lib/sss/db/ccache_INFINERA.COM] >(Mon May 22 08:46:14 2017) [[sssd[ldap_child[17650]]]] [main] (0x0400): ldap_child completed successfully >(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [main] (0x0400): krb5_child started. >(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [unpack_buffer] (0x1000): total buffer size: [154] >(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [unpack_buffer] (0x0100): cmd [248] uid [1001] gid [100] validate [true] enterprise principal [false] offline [false] UPN [jocke(a)INFINERA.COM] >(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_1001] old_ccname: [FILE:/tmp/krb5cc_1001] keytab: [/etc/krb5.keytab] >(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [check_use_fast] (0x0100): Not using FAST. >(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [switch_creds] (0x0200): Switch user to [1001][100]. >(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. >(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [switch_creds] (0x0200): Switch user to [0][0]. >(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [k5c_check_old_ccache] (0x4000): Ccache_file is [FILE:/tmp/krb5cc_1001] and is active and TGT is valid. >(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [privileged_krb5_setup] (0x0080): Cannot open the PAC responder socket >(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [become_user] (0x0200): Trying to become user [1001][100]. >(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [main] (0x2000): Running as [1001][100]. >(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [k5c_setup] (0x2000): Running as [1001][100]. >(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [set_lifetime_options] (0x0100): Renewable lifetime is set to [7d] >(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [set_lifetime_options] (0x0100): Lifetime is set to [24h] >(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [set_canonicalize_option] (0x0100): Canonicalization is set to [true] >(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [main] (0x0400): Will perform ticket renewal >(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [renew_tgt_child] (0x1000): Renewing a ticket >(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [sss_child_krb5_trace_cb] (0x4000): [17652] 1495435574.515585: Retrieving jocke(a)INFINERA.COM -> krbtgt/INFINERA.COM(a)INFINERA.COM from FILE:/tmp/krb5cc_1001 with result: 0/Success >(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [sss_child_krb5_trace_cb] (0x4000): [17652] 1495435574.515616: Get cred via TGT krbtgt/INFINERA.COM(a)INFINERA.COM after requesting krbtgt/INFINERA.COM(a)INFINERA.COM (canonicalize off) >(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [sss_child_krb5_trace_cb] (0x4000): [17652] 1495435574.515681: Generated subkey for TGS request: aes256-cts/2D54 >(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [sss_child_krb5_trace_cb] (0x4000): [17652] 1495435574.515747: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts, des-cbc-crc, des, des-cbc-md4 >(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [sss_child_krb5_trace_cb] (0x4000): [17652] 1495435574.515862: Encoding request body and padata into FAST request >(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [sss_child_krb5_trace_cb] (0x4000): [17652] 1495435574.515973: Sending request (1901 bytes) to INFINERA.COM >(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [sss_child_krb5_trace_cb] (0x4000): [17652] 1495435574.516194: Resolving hostname se-dc01.infinera.com >(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [sss_child_krb5_trace_cb] (0x4000): [17652] 1495435574.516448: Initiating TCP connection to stream 10.210.34.21:88 >(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [sss_child_krb5_trace_cb] (0x4000): [17652] 1495435574.516778: Sending TCP request to stream 10.210.34.21:88 >(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [sss_child_krb5_trace_cb] (0x4000): [17652] 1495435574.517190: Received answer (123 bytes) from stream 10.210.34.21:88 >(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [sss_child_krb5_trace_cb] (0x4000): [17652] 1495435574.517203: Terminating TCP connection to stream 10.210.34.21:88 >(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [sss_child_krb5_trace_cb] (0x4000): [17652] 1495435574.517247: Response was not from master KDC >(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [sss_child_krb5_trace_cb] (0x4000): [17652] 1495435574.517270: Got cred; -1765328352/Ticket expired >(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [map_krb5_error] (0x0020): 1643: [-1765328352][Ticket expired] Renewing of a ticket failed because it is already expired. Maybe due to time shift between client and server(KDC) >(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [k5c_send_data] (0x0200): Received error code 1432158229 >(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [pack_response_packet] (0x2000): response packet size: [4] >(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [k5c_send_data] (0x4000): Response sent. >(Mon May 22 08:46:14 2017) [[sssd[krb5_child[17652]]]] [main] (0x0400): krb5_child completed successfully There were 5 more attempts to renew tickets within a second. 4 of them failed due to expired ticket. And the last one failed due to offline mode. Few seconds later (7) user was authenticated in offline mode. >(Mon May 22 08:46:21 2017) [[sssd[krb5_child[17694]]]] [main] (0x0400): krb5_child started. >(Mon May 22 08:46:21 2017) [[sssd[krb5_child[17694]]]] [unpack_buffer] (0x1000): total buffer size: [141] >(Mon May 22 08:46:21 2017) [[sssd[krb5_child[17694]]]] [unpack_buffer] (0x0100): cmd [241] uid [1001] gid [100] validate [true] enterprise principal [false] offline [true] UPN [jocke(a)INFINERA.COM] >(Mon May 22 08:46:21 2017) [[sssd[krb5_child[17694]]]] [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_1001] old_ccname: [FILE:/tmp/krb5cc_1001] keytab: [/etc/krb5.keytab] >(Mon May 22 08:46:21 2017) [[sssd[krb5_child[17694]]]] [check_use_fast] (0x0100): Not using FAST. >(Mon May 22 08:46:21 2017) [[sssd[krb5_child[17694]]]] [switch_creds] (0x0200): Switch user to [1001][100]. >(Mon May 22 08:46:21 2017) [[sssd[krb5_child[17694]]]] [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. >(Mon May 22 08:46:21 2017) [[sssd[krb5_child[17694]]]] [switch_creds] (0x0200): Switch user to [0][0]. >(Mon May 22 08:46:21 2017) [[sssd[krb5_child[17694]]]] [k5c_check_old_ccache] (0x4000): Ccache_file is [FILE:/tmp/krb5cc_1001] and is active and TGT is valid. >(Mon May 22 08:46:21 2017) [[sssd[krb5_child[17694]]]] [privileged_krb5_setup] (0x0080): Cannot open the PAC responder socket >(Mon May 22 08:46:21 2017) [[sssd[krb5_child[17694]]]] [become_user] (0x0200): Trying to become user [1001][100]. >(Mon May 22 08:46:21 2017) [[sssd[krb5_child[17694]]]] [main] (0x2000): Running as [1001][100]. >(Mon May 22 08:46:21 2017) [[sssd[krb5_child[17694]]]] [become_user] (0x0200): Trying to become user [1001][100]. >(Mon May 22 08:46:21 2017) [[sssd[krb5_child[17694]]]] [become_user] (0x0200): Already user [1001]. >(Mon May 22 08:46:21 2017) [[sssd[krb5_child[17694]]]] [k5c_setup] (0x2000): Running as [1001][100]. >(Mon May 22 08:46:21 2017) [[sssd[krb5_child[17694]]]] [set_lifetime_options] (0x0100): Renewable lifetime is set to [7d] >(Mon May 22 08:46:21 2017) [[sssd[krb5_child[17694]]]] [set_lifetime_options] (0x0100): Lifetime is set to [24h] >(Mon May 22 08:46:21 2017) [[sssd[krb5_child[17694]]]] [main] (0x0400): Will perform offline auth >(Mon May 22 08:46:21 2017) [[sssd[krb5_child[17694]]]] [create_empty_ccache] (0x1000): Existing ccache still valid, reusing >(Mon May 22 08:46:21 2017) [[sssd[krb5_child[17694]]]] [k5c_send_data] (0x0200): Received error code 0 >(Mon May 22 08:46:21 2017) [[sssd[krb5_child[17694]]]] [pack_response_packet] (0x2000): response packet size: [45] >(Mon May 22 08:46:21 2017) [[sssd[krb5_child[17694]]]] [k5c_send_data] (0x4000): Response sent. >(Mon May 22 08:46:21 2017) [[sssd[krb5_child[17694]]]] [main] (0x0400): krb5_child completed successfully LS

3 19

1.15.3/1.16 release timeframe?
by Lachlan Musicman 11 Jul '17

11 Jul '17

Hi all, I noticed a while ago that 1.15.3 was versioned in the repo but I've not seen anything released? I'm mostly looking on the COPR ( https://pagure.io/SSSD/sssd/c/012ee7c3fe24a5e75d9b0465268c1bb8187b8337?bran… ) This is purely selfish - I love all that you do, and I'm aware that there has been some fairly comprehensive infrastructural change. I'm just waiting on that one fix and have no roadmap visibility :) cheers L. ------ "Mission Statement: To provide hope and inspiration for collective action, to build collective power, to achieve collective transformation, rooted in grief and rage but pointed towards vision and dreams." - Patrisse Cullors, *Black Lives Matter founder*

5 14

Expected one user entry and got 2
by TomK 06 Jul '17

06 Jul '17

Hey All, We're receiving the following message on an older installation of SSSD and RHEL 6.7. SSSD version is sssd-1.12.4-47.el6_7.4.x86_64. I'm wondering under what conditions could "Expected one user entry and got 2" be thrown and if it's fixed in higher SSSD versions. -- Cheers, Tom K. ------------------------------------------------------------------------------------- Living on earth is expensive, but it includes a free trip around the sun.

3 7

Received error from KDC: -1765328378/Client not found in Kerberos database
by TomK 05 Jul '17

05 Jul '17

Hey All, We are connecting a set of servers directly with AD. The AD computer object is created for the host and is associated to a service account. This service account works well with other hosts on the same domain. Since this is a direct SSSD to AD setup, we are using adcli to establish a connection to AD. adcli populates a /etc/krb5.keytab file with a number of entries including: * Added the entries to the keytab: host/longhostname-host01.xyz.abc.com(a)COMPANY.COM: FILE:/etc/krb5.keytab and runs successfully, without errors, to completion. However when starting up sssd, we see the following in the log files: . . [[sssd[ldap_child[11774]]]] [main] (0x0400): ldap_child started. [[sssd[ldap_child[11774]]]] [main] (0x2000): context initialized [[sssd[ldap_child[11774]]]] [unpack_buffer] (0x1000): total buffer size: 71 [[sssd[ldap_child[11774]]]] [unpack_buffer] (0x1000): realm_str size: 12 [[sssd[ldap_child[11774]]]] [unpack_buffer] (0x1000): got realm_str: COMPANY.COM [[sssd[ldap_child[11774]]]] [unpack_buffer] (0x1000): princ_str size: 35 [[sssd[ldap_child[11774]]]] [unpack_buffer] (0x1000): got princ_str: host/longhostname-host01.xyz.abc.co [[sssd[ldap_child[11774]]]] [unpack_buffer] (0x1000): keytab_name size: 0 [[sssd[ldap_child[11774]]]] [unpack_buffer] (0x1000): lifetime: 86400 [[sssd[ldap_child[11774]]]] [unpack_buffer] (0x0200): Will run as [0][0]. [[sssd[ldap_child[11774]]]] [privileged_krb5_setup] (0x2000): Kerberos context initialized [[sssd[ldap_child[11774]]]] [main] (0x2000): Kerberos context initialized [[sssd[ldap_child[11774]]]] [become_user] (0x0200): Trying to become user [0][0]. [[sssd[ldap_child[11774]]]] [become_user] (0x0200): Already user [0]. [[sssd[ldap_child[11774]]]] [main] (0x2000): Running as [0][0]. [[sssd[ldap_child[11774]]]] [main] (0x2000): getting TGT sync got princ_str: host/longhostname-host01.xyz.abc.com(a)COMPANY.COM . . Principal name is: [host/longhostname-host01.xyz.abc.com(a)COMPANY.COM] . . followed by: [[sssd[ldap_child[11774]]]] [sss_child_krb5_trace_cb] (0x4000): [11774] 1492661662.219837: Looked up etypes in keytab: des-cbc-crc, des, des-cbc-crc, rc4-hmac, aes128-cts, aes256-cts [[sssd[ldap_child[11774]]]] [sss_child_krb5_trace_cb] (0x4000): [11774] 1492661662.219898: Sending request (224 bytes) to COMPANY.COM [[sssd[ldap_child[11774]]]] [sss_child_krb5_trace_cb] (0x4000): [11774] 1492661662.220151: Initiating TCP connection to stream 1.2.3.4:88 [[sssd[ldap_child[11774]]]] [sss_child_krb5_trace_cb] (0x4000): [11774] 1492661662.222555: Sending TCP request to stream 1.2.3.4:88 [[sssd[ldap_child[11774]]]] [sss_child_krb5_trace_cb] (0x4000): [11774] 1492661662.226128: Received answer from stream 1.2.3.4:88 [[sssd[ldap_child[11774]]]] [sss_child_krb5_trace_cb] (0x4000): [11774] 1492661662.226205: Response was from master KDC [[sssd[ldap_child[11774]]]] [sss_child_krb5_trace_cb] (0x4000): [11774] 1492661662.226238: Received error from KDC: -1765328378/Client not found in Kerberos database Verified that the krb5.keytab has the principal and it matches exactly. The OS is RHEL 6.7. Wondering if anyone ran into this and what could be some of the problems that could be causing this? Do we need something extra to be done on the AD side besides creating the computer object? We'd take it from there to dig further since I realize I can't provide all the details without first editing things out as I did above. -- Cheers, Tom K. ------------------------------------------------------------------------------------- Living on earth is expensive, but it includes a free trip around the sun.

5 14

p11_child fails to obtain certificate from yubikey
by tallinn1960＠yahoo.de 07 Jun '17

07 Jun '17

I am trying to setup a PKINIT/smartcard-based logon scheme using sssd 1.15.1 on Ubuntu 16.04. I am using the opensc-pkcs11 lib to access the smartcard. I have a working pam_krb5 based PKINIT smartcard logon to the KDC. The opensc pkcs11 lib and all relevant ca certificates are installed in the nss database. However, p11_child is not happy about the yubikey: ➜ ~ sudo /usr/local/libexec/sssd/p11_child -d 9 --nssdb=/etc/pki/nssdb --pre (Wed Apr 26 17:40:56:522588 2017) [[sssd[p11_child[2677]]]] [main] (0x0400): p11_child started. (Wed Apr 26 17:40:56:522763 2017) [[sssd[p11_child[2677]]]] [main] (0x2000): Running in [pre-auth] mode. (Wed Apr 26 17:40:56:522849 2017) [[sssd[p11_child[2677]]]] [main] (0x2000): Running with effective IDs: [0][0]. (Wed Apr 26 17:40:56:522931 2017) [[sssd[p11_child[2677]]]] [main] (0x2000): Running with real IDs [0][0]. (Wed Apr 26 17:40:56:655832 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000): Default Module List: (Wed Apr 26 17:40:56:655859 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000): common name: [NSS Internal PKCS #11 Module]. (Wed Apr 26 17:40:56:655864 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000): dll name: [(null)]. (Wed Apr 26 17:40:56:655869 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000): common name: [yubikey]. (Wed Apr 26 17:40:56:655873 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000): dll name: [/usr/lib/x86_64-linux-gnu/onepin-opensc-pkcs11.so]. (Wed Apr 26 17:40:56:655877 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000): Dead Module List: (Wed Apr 26 17:40:56:655883 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000): DB Module List: (Wed Apr 26 17:40:56:655888 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000): common name: [NSS Internal Module]. (Wed Apr 26 17:40:56:655892 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000): dll name: [(null)]. (Wed Apr 26 17:40:56:655917 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000): Description [NSS Internal Cryptographic Services Mozilla Foundation ] Manufacturer [Mozilla Foundation ] flags [1]. (Wed Apr 26 17:40:56:655924 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000): Description [NSS User Private Key and Certificate Services Mozilla Foundation ] Manufacturer [Mozilla Foundation ] flags [1]. (Wed Apr 26 17:40:56:655929 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000): Description [Yubico Yubikey 4 OTP+CCID 00 00 OpenSC (www.opensc-project.org) ] Manufacturer [OpenSC (www.opensc-project.org) ] flags [7]. (Wed Apr 26 17:40:56:655940 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000): Found [PIV_II (PIV Card Holder pin)] in slot [Yubico Yubikey 4 OTP+CCID 00 00][1] of module [2][/usr/lib/x86_64-linux-gnu/onepin-opensc-pkcs11.so]. (Wed Apr 26 17:40:56:655946 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000): Token is NOT friendly. (Wed Apr 26 17:40:56:655951 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000): Trying to switch to friendly to read certificate. (Wed Apr 26 17:40:56:655957 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000): Login required. (Wed Apr 26 17:40:56:655961 2017) [[sssd[p11_child[2677]]]] [do_work] (0x0020): Login required but no pin available, continue. (Wed Apr 26 17:40:56:656102 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000): found cert[PIV_II (PIV Card Holder pin):Certificate for PIV Authentication][CN=secadm,UID=4915377] (Wed Apr 26 17:40:56:656127 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000): Filtered certificates: (Wed Apr 26 17:40:56:656132 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000): No certificate found. It looks like the certificate on the key is PIN-protected. Shouldn't p11_child ask for a PIN? Giving p11_child the --pin flag has absolutely no effect. Any help is welcome. Thx

3 8

user id getting lost
by Thomas Beaudry 31 May '17

31 May '17

?Hi Guys, I am running into a problem recently where my username is getting lost, and being associated to a number. I disabled reverse DNS in the past based on a suggestion from another sssd user, which seemed to work for awhile. I set my debug levels to 10, so how can i start debugging this? Thomas

3 3

Samba 4.4, sssd, adcli; windows hosts cannot authenticate
by Steve Dainard 29 May '17

29 May '17

I'm running samba 4.4.4 on el7. I'm attempting to provide a share auth by Kerberos or for non-kerberos hosts auth by password on Linux or Windows (7) clients. We have uid/gid/group memberships in AD and typically configure Linux hosts with a kerberos/sssd/ldap configuration which uses attributes from AD, but are not joined to domain. I need to be able to automate the domain join with salt stack, so I'm stuck using adcli to join the machine as it has a plain-text password option, I then push sssd.conf, /etc/krb5.conf, and /etc/samba/smb.conf to the samba host. Thus far I've been able to browse shares from Linux, which authenticates with Kerberos OK. File/directory perms are respected, new files are created with proper uid, etc. No complaints on this side. When I attempt to connect from a domain joined Windows client I get prompted for credentials, and domain credentials do not work. It seems like the id of the user isn't passed through or looked up correctly after Kerberos auth, and the user is labelled as a guest user. Guest users are mapped to bad user in samba config. Here's a bit of logging when the Windows client tries to access a share: https://pastebin.com/pbEqj9ZR Configs; smb.conf: https://pastebin.com/XfeVTCDE sssd.conf: https://pastebin.com/Z57rRwBw krb5.conf: https://pastebin.com/JigdxgJ6 Some other interesting tidbits: DNS is served by el6/bind, not by AD, but the AD srv records exist and work properly for auto discovery and binding. The samba server does not have a PTR record, although this seems to be a requirement for KDC's not members. The domain is ad.localdomain.com, but hosts (including the samba server) have fqdn assigned by dhcp as <hostname>.dhcp.localdomain.com. Any help is appreciated, usually its the Linux client that ends up being a pain, this is the first time for me a Windows client is having issues authing. Thanks, Steve

2 1

SSSD list allowed users only
by Ali, Saqib 29 May '17

29 May '17

We are using SSSD for authentication using LDAP. And I filter the user access using *simple_allow_groups* as follows: access_provider = simple simple_allow_groups = Computer Admins Is it possible to get a list of ONLY allowed users using *getent*? There is an option enumeration, but this lists all users. I am only interested in the allowed users.

4 8

Re: [Samba] Samba 4.4, sssd, adcli; windows hosts cannot authenticate
by Steve Dainard 28 May '17

28 May '17

On Sun, May 28, 2017 at 1:38 AM, Rowland Penny via samba <samba(a)lists.samba.org> wrote: > On Sat, 27 May 2017 21:45:29 -0700 > Steve Dainard via samba <samba(a)lists.samba.org> wrote: > >> I'm running samba 4.4.4 on el7. I'm attempting to provide a share >> auth by Kerberos or for non-kerberos hosts auth by password on Linux >> or Windows (7) >> clients. >> >> We have uid/gid/group memberships in AD and typically configure >> Linux hosts with a kerberos/sssd/ldap configuration which uses >> attributes from AD, but are not joined to domain. > > You have 'security = ADS' in smb.conf and from 'man smb.conf' > > SECURITY = ADS > > In this mode, Samba will act as a domain member in an ADS realm. To > operate in this mode, the machine running Samba will need to have > Kerberos installed and configured and Samba will need to be joined > to the ADS realm using the net utility. > Right, the host is joined to the domain, via adcli, rather than net. > >> >> I need to be able to automate the domain join with salt stack, so I'm >> stuck using adcli to join the machine as it has a plain-text password >> option, I then push sssd.conf, /etc/krb5.conf, and /etc/samba/smb.conf >> to the samba host. > > Never heard of 'salt' until now and I don't really understand what it > brings to the party ? In context, makes sure people understand I've used adcli, rather than using the net command and must continue to do so, so that I can automate joining samba servers to the domain. > > From what you have posted the default realm is > 'AD.LOCALDOMAIN.COM' but your clients are in the dns domain > 'dhcp.localdomain.com', I am no kerberos expert, but this wouldn't work > with a Samba AD DC. Right, the server is configured as a member server, not a domain controller. Also this doesn't seem to be a 'kerberos' issue, as my Linux clients who auth via kerberos are able to properly authenticate on a protected share without password prompts, and I see a cifs kerberos ticket on my Linux client. The Linux clients also have fqdn's in the same domain as the samba server, not the ad domain. So it appears it might be Windows implementation that has an issue with clients having a different domain name than the servers. That doesn't explain user/password authentication not working on the Windows client, I'm definitely missing something on this side, I'm thinking NTLM may not work with encrypted passwords although I thought this didn't apply to newer versions of samba. This seems related https://social.technet.microsoft.com/Forums/en-US/8249ad4c-69aa-41ba-8863-8… I'll give it a run when I'm back in the office. > > It sounds like you could replace the salt machine with a Samba AD DC > and then you wouldn't have all the problems you are having, but I > understand that you want to use salt. The only problem I can see, you > have set up smb.conf to connect to an AD DC. Salt is only for configuration management, it doesn't matter too much in this context. As mentioned, I'm joining the samba server as a member of the domain, not using it as a domain controller, and using it as a DC is not an option. > > >> When I attempt to connect from a domain joined Windows client I get >> prompted for credentials, and domain credentials do not work. It seems >> like the id of the user isn't passed through or looked up correctly >> after Kerberos auth, and the user is labelled as a guest user. Guest >> users are mapped to bad user in samba config. Here's a bit of logging >> when the Windows client tries to access a >> share: https://pastebin.com/pbEqj9ZR > > Actually unknown users (i.e. Bad User) are mapped to the Unix user > 'nobody', they probably wouldn't be if you were using an AD DC with > the windows clients joined to the domain. Whichever user a bad user is being mapped to, I believe this is at the root of the problem with the Windows client. I think Kerberos is working for the initial auth/handshake, but somehow user id doesn't carry through to match actual permissions on the share. But that this does work for a Linux client machine/user is what is confounding. > > The other problem you have here is, sssd has nothing to do with Samba, > it is not Samba package, you may get better help from the sssd-users > mailing list, mainly because, if you are using sssd, it is this that > is doing your authentication. Yes, I've sent this mail to both lists. > > Rowland > > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba

1 0

[SSSD][AD][GPO] GPOs Found but Not Applied
by Ledford, Donald 22 May '17

22 May '17

Hello, We've got a RHEL 6.9 system in testing for AD integration. We have to use 6.x due to compatibility issues with software that will eventually be deployed to the system so moving to RHEL 7.3 isn't an option. Currently we're working on getting SSSD integrated with AD on this box. So far everything except GPO restrictions are working. Users can login via their AD credentials, their groups are enumerated, home directories are made automatically, etc. The only piece left is GPO based access restrictions. We'd really like to use AD GPOs to set who can and can't login via SSH. To this end we've made a new OU for the Linux server, placed it's AD object in the OU, and attached a GPO to the OU with a test user account in the "Deny log on through Remote Desktop Services" policy setting. So far this hasn't been working and the test account can always login through SSH. The SSSD system can see the GPOs attached to the OU all the way up to the domain root, but does not think any of the GPOs apply to it. We've got "ad_gpo_access_control = enforcing" set in sssd.conf but it doesn't seem to be doing anything. According to the logs SSSD is parsing all the GPO LDAP attributes then deciding none of the GPOs apply, without parsing the GPO INI files themselves. I have confirmed manually that the server's Kerberos credentials will return results via LDAP queries and can mount the domain SYSVOL share as well as read the GPO files in the share. So I'm not sure why SSSD won't apply the GPO settings. I've attached a sanitized sssd.conf file and selected parts of the sssd_ad.domain.com.log file to this post. Here's the relevant version info: RHEL 6.9 - Linux ad-lnx-test.ad.domain.com 2.6.32-696.1.1.el6.x86_64 #1 SMP Tue Mar 21 12:19:18 EDT 2017 x86_64 x86_64 x86_64 GNU/Linux yum info sssd: Name : sssd Arch : x86_64 Version : 1.13.3 Release : 56.el6 Size : 34 k Repo : installed From repo : rhel-6-server-rpms Any thoughts on why this isn't working are much appreciated. -- -Donald

4 11

Cluster VIP for LDAP hosts.
by TomK 20 May '17

20 May '17

Hey Guy's, Cluster VIP for LDAP hosts. Does SSSD support this now? Or should it still be a comma seperated list? Have a Windows AD DC cluster made up of 8 servers. Would be handy to use that (ie company-dom.com) instead of the individual hosts that make this up. In case the AD / DC team removes hosts from a cluster, we would not need to update anything on our end if we were using just the domain. -- Cheers, Tom K. ------------------------------------------------------------------------------------- Living on earth is expensive, but it includes a free trip around the sun.

2 2

Can all ldap controls be removed when using access_provider=ad
by Abhijit Tikekar 19 May '17

19 May '17

All, We use access_provider=ad along with ad_access_filter to control authentication based on specific group memberships. But we also have configured several low level ldap control as shown below: #ldap_id_mapping = true #ldap_use_tokengroups = False #ldap_sasl_mech = GSSAPI #ldap_uri = #ldap_sudo_search_base = ou #ldap_user_search_base = dc #ldap_user_object_class = user #ldap_group_search_base = ou= #ldap_group_object_class = group #ldap_user_home_directory = unixHomeDirectory #ldap_user_principal = userPrincipalName #ldap_access_order = filter, expire #ldap_account_expire_policy = ad # ldap_schema = ad I’ve seen several posts where it is suggested that when using “access_provider=ad”, these ldap configurations are no longer needed. I just want to get some clarification on this forum regarding how safe it is to remove all the items listed above and do we run a risk of any potential issues later? Here is a complete SSSD conf. [sssd] domains = services = nss, pam, sudo config_file_version = 2 debug_level = 0 [nss] [pam] [sudo] debug_level=0 [domain/] debug_level=0 ad_server = xxxxx id_provider = ad auth_provider = ad access_provider = ad sudo_provider = ad krb5_realm = #ldap_id_mapping = true #ldap_use_tokengroups = False #ldap_sasl_mech = GSSAPI #ldap_uri = ldap://xxxxxx #ldap_sudo_search_base = #ldap_user_search_base = #ldap_user_object_class = #ldap_group_search_base = #ldap_group_object_class = #ldap_user_home_directory = #ldap_user_principal = #ldap_access_order = filter, expire #ldap_account_expire_policy = ad #ldap_schema = ad ad_access_filter = cache_credentials = true override_homedir = /home/%d/%u default_shell = /bin/bash Thanks in advance for any inputs. ~ Abhi

2 1

kerberos ticket not renewed in 15.2/master
by Joakim Tjernlund 19 May '17

19 May '17

Sequence: login into MATE or Plasma suspend to ram wait until krbtgt expires wakeup computer unlock screen klist will show the old expired ticket. lock/unlock screen again(well after networking is up) klist still shows the old ticket. No SSO/NFS possible until manually doing a kinit to get a fresh ticket Anyone else see this? Jocke

4 15

sAMAccountName with gid in requests
by Sébastien QUESSON 19 May '17

19 May '17

Hi, on sssd 1.13.4-1ubuntu1.5: looking at sssd_domain.tls.log with debug level 9, I can see many wrong group requests. After flushing ssd cache and restarting: [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(gidNumber=10117)(objectClass=group)(sAMAccountName=*)(&(gidNumber=*)(!(gidNumber=0))))][DC=domain,DC=tld]. => it is valid, but few milliseconds later: [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(sAMAccountName=10107)(objectClass=group)(sAMAccountName=*)(&(gidNumber=*)(!(gidNumber=0))))][DC=domain,DC=tld] returns nothing, because sAMAccountName=10107 does not exists in sssd_nss.log, it generates many errors such [sssd[nss]] [nss_cmd_getpwnam_search] (0x0040): No results for getpwnam call [nss_cmd_getgrnam_search] (0x0040): No results for getgrnam call is it expected or a misconfiguration on my test environment? attached : sssd.conf

2 2

Users able to login but unable to sudo
by Abhijit Tikekar 18 May '17

18 May '17

Hi, On multiple machines where SSSD is being used, “sudo” has stopped working. Users can authenticate successfully based on their group memberships, but are unable to elevate privileges. [first.last@hostname ~]$ sudo su [sudo] password for first.last: Sorry, try again. [sudo] password for first.last: Here is the SSSD Configuration: [sssd] domains = X.Y.LOCAL services = nss, pam, sudo config_file_version = 2 debug_level = 0 [nss] [pam] [sudo] debug_level=10 [domain/x.y.local] debug_level=0 ad_server = AD.x.y.local id_provider = ad auth_provider = ad access_provider = ad sudo_provider = ad ldap_id_mapping = true ldap_use_tokengroups = False ldap_sasl_mech = GSSAPI krb5_realm = X.Y.LOCAL ldap_uri = ldap://AD.x.y.local ldap_sudo_search_base = ou= ldap_user_search_base = dc= ldap_user_object_class = user ldap_group_search_base = ou ldap_group_object_class = group ldap_user_home_directory = unixHomeDirectory ldap_user_principal = userPrincipalName ldap_access_order = filter, expire ldap_account_expire_policy = ad ldap_access_filter = cache_credentials = true override_homedir = /home/%d/%u default_shell = /bin/bash ldap_schema = ad Here is sssd_sudo.log with level set to 10 (Wed May 17 13:33:51 2017) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=first.last)(sudoUser=first.last)(sudoUser=#xxxxxxxxx)(sudoUser=%yyyyyyyy)(sudoUser=%zzzzzz)] (Wed May 17 13:33:51 2017) [sssd[sudo]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x24216e0 (Wed May 17 13:33:51 2017) [sssd[sudo]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x241d2f0 (Wed May 17 13:33:51 2017) [sssd[sudo]] [ldb] (0x4000): Running timer event 0x24216e0 "ltdb_callback" (Wed May 17 13:33:51 2017) [sssd[sudo]] [ldb] (0x4000): Destroying timer event 0x241d2f0 "ltdb_timeout" (Wed May 17 13:33:51 2017) [sssd[sudo]] [ldb] (0x4000): Ending timer event 0x24216e0 "ltdb_callback" (Wed May 17 13:33:51 2017) [sssd[sudo]] [sudosrv_get_rules] (0x2000): About to get sudo rules from cache (Wed May 17 13:33:51 2017) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(name=defaults)))] (Wed May 17 13:33:51 2017) [sssd[sudo]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x2421880 (Wed May 17 13:33:51 2017) [sssd[sudo]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x241bd70 (Wed May 17 13:33:51 2017) [sssd[sudo]] [ldb] (0x4000): Running timer event 0x2421880 "ltdb_callback" (Wed May 17 13:33:51 2017) [sssd[sudo]] [ldb] (0x4000): Destroying timer event 0x241bd70 "ltdb_timeout" (Wed May 17 13:33:51 2017) [sssd[sudo]] [ldb] (0x4000): Ending timer event 0x2421880 "ltdb_callback" (Wed May 17 13:33:51 2017) [sssd[sudo]] [sudosrv_get_sudorules_from_cache] (0x0400): Returning 0 rules for [<default options>@x.y.local] (Wed May 17 13:33:51 2017) [sssd[sudo]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x241dbe0][17] (Wed May 17 13:33:51 2017) [sssd[sudo]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x241dbe0][17] (Wed May 17 13:33:51 2017) [sssd[sudo]] [sudosrv_cmd] (0x2000): Using protocol version [1] (Wed May 17 13:33:51 2017) [sssd[sudo]] [sss_parse_name_for_domains] (0x0200): name 'first.last' matched without domain, user is first.last (Wed May 17 13:33:51 2017) [sssd[sudo]] [sss_parse_name_for_domains] (0x0200): name 'first.last' matched without domain, user is first.last (Wed May 17 13:33:51 2017) [sssd[sudo]] [sudosrv_cmd_parse_query_done] (0x0200): Requesting rules for [first.last] from [<ALL>] (Wed May 17 13:33:51 2017) [sssd[sudo]] [sss_ncache_check_str] (0x2000): Checking negative cache for [NCE/USER/x.y.local/first.last] (Wed May 17 13:33:51 2017) [sssd[sudo]] [sudosrv_get_user] (0x0200): Requesting info about [first.last(a)x.y.local] (Wed May 17 13:33:51 2017) [sssd[sudo]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x2411ce0 (Wed May 17 13:33:51 2017) [sssd[sudo]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x241bcf0 (Wed May 17 13:33:51 2017) [sssd[sudo]] [ldb] (0x4000): Running timer event 0x2411ce0 "ltdb_callback" (Wed May 17 13:33:51 2017) [sssd[sudo]] [ldb] (0x4000): Destroying timer event 0x241bcf0 "ltdb_timeout" (Wed May 17 13:33:51 2017) [sssd[sudo]] [ldb] (0x4000): Ending timer event 0x2411ce0 "ltdb_callback" (Wed May 17 13:33:51 2017) [sssd[sudo]] [sudosrv_get_user] (0x0400): Returning info for user [first.last(a)x.y.local] (Wed May 17 13:33:51 2017) [sssd[sudo]] [sudosrv_get_rules] (0x0400): Retrieving rules for [first.last] from [x.y.local] (Wed May 17 13:33:51 2017) [sssd[sudo]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x2416450 (Wed May 17 13:33:51 2017) [sssd[sudo]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x241a150 (Wed May 17 13:33:51 2017) [sssd[sudo]] [ldb] (0x4000): Running timer event 0x2416450 "ltdb_callback" (Wed May 17 13:33:51 2017) [sssd[sudo]] [ldb] (0x4000): Destroying timer event 0x241a150 "ltdb_timeout" (Wed May 17 13:33:51 2017) [sssd[sudo]] [ldb] (0x4000): Ending timer event 0x2416450 "ltdb_callback" (Wed May 17 13:33:51 2017) [sssd[sudo]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x2412df0 (Wed May 17 13:33:51 2017) [sssd[sudo]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x2421340 (Wed May 17 13:33:51 2017) [sssd[sudo]] [ldb] (0x4000): Running timer event 0x2412df0 "ltdb_callback" (Wed May 17 13:33:51 2017) [sssd[sudo]] [ldb] (0x4000): Destroying timer event 0x2421340 "ltdb_timeout" (Wed May 17 13:33:51 2017) [sssd[sudo]] [ldb] (0x4000): Ending timer event 0x2412df0 "ltdb_callback" (Wed May 17 13:33:51 2017) [sssd[sudo]] [sysdb_search_group_by_gid] (0x0400): No such entry Verified that correct %groupname entry exists under /etc/sudoers file. What else can be checked? Thanks, ~ abhi

2 4

Authenticating to RODC using SSSD
by Abhijit Tikekar 15 May '17

15 May '17

Hi, Has anyone had any success while setting up SSSD with RODC AD Server? We are setting this up on CentOS 6.8 machines but doesn't seem to work. Computer object is created and replicated to RODC. Verified that all configuration file parameters are identical to the ones mentioned in the link below. https://access.redhat.com/discussions/2838371 I assume we still have to join the server to RODC? Is the joining process still the same as we do for a Writable DC. When using "net ads join" I get the following error: Failed to join domain: Failed to set account flags for machine account (NT_STATUS_NOT_SUPPORTED) in the logs, we also get the following( Debug level set to 7) (Tue Feb 14 11:20:42 2017) [sssd[be[x.y.local]]] [sdap_set_sasl_options] (0x0100): Will look for testdmzlin(a)X.Y.LOCAL in default keytab (Tue Feb 14 11:20:42 2017) [sssd[be[x.y.local]]] [select_principal_from_keytab] (0x0200): trying to select the most appropriate principal from keytab (Tue Feb 14 11:20:42 2017) [sssd[be[x.y.local]]] [find_principal_in_keytab] (0x0400): No principal matching testdmzlin(a)X.Y.LOCAL found in keytab. (Tue Feb 14 11:20:42 2017) [sssd[be[x.y.local]]] [find_principal_in_keytab] (0x0400): No principal matching TESTDMZLIN$(a)X.Y.LOCAL found in keytab. (Tue Feb 14 11:20:42 2017) [sssd[be[x.y.local]]] [find_principal_in_keytab] (0x0400): No principal matching host/testdmzlin(a)X.Y.LOCAL found in keytab. (Tue Feb 14 11:20:42 2017) [sssd[be[x.y.local]]] [find_principal_in_keytab] (0x0400): No principal matching *$(a)X.Y.LOCAL found in keytab. (Tue Feb 14 11:20:42 2017) [sssd[be[x.y.local]]] [find_principal_in_keytab] (0x0400): No principal matching host/*(a)X.Y.LOCAL found in keytab. (Tue Feb 14 11:20:42 2017) [sssd[be[x.y.local]]] [find_principal_in_keytab] (0x0400): No principal matching host/*@(null) found in keytab. But if i try to query this RODC using "ldapsearch" it works. ldapsearch -H ldap://RODC_ServerName.x.y.local/ -Y GSSAPI -N -b "dc=x,dc=y,dc=local" "(&(objectClass=user)(sAMAccountName=firstname.lastname))" What else can I check to troubleshoot this issue? Thanks, ~ Abhi

3 12

Thank You!
by Orion Poplawski 08 May '17

08 May '17

IPA/SSSD developers - I'm writing to give everyone involved in the IPA and sssd projects a big "Thank You". I've been poking at IPA for a little over 4 years now, looking to migrate away from our 389ds LDAP configuration. There have been lots of hurdles to jump, bugs to fix, as well as a complete change of direction (from migrating users to moving to an AD trust). Along the way I have received a huge amount of assistance from a large group of incredibly helpful people, including (but not limited to) Jakub Hrozek, Lukas Slebodnik, Simo Sorce, Pavel Březina, Nalin Dahyabhai, Rob Crittenden. My apologies if I left anyone out. I have two machines left to convert to IPA and can hardly believe sometimes that I've finally arrived at this point. So, thanks again for everyone for their work on this incredibly complex and critical set of software. - Orion -- Orion Poplawski Technical Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion(a)nwra.com Boulder, CO 80301 http://www.nwra.com

1 0

SSSD & POSIX attrs in GC
by Ondrej Valousek 05 May '17

05 May '17

Hi all, Simple question: In case we not use ldap_id_mapping, does SSSD require posix attrs in GC or not? Thanks, Ondrej ----- The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications(a)s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18.

2 2

Fwd: SSS sudoers and Ubuntu 16.04
by Clayton Daley 04 May '17

04 May '17

Good Morning, We're doing some tests on Ubuntu 16.04 before upgrading and I'm having an issue with sss (ldap) sudoers. On 14.04, everything works: User clayton@<domain> may run the following commands on lin2: > (root) ALL > (root) NOPASSWD: /usr/bin/docker On 16.04, the user has no problem authenticating, but: User clayton@<domain> is not allowed to run sudo on lin3. This is the same AD server and we use deployment automation code so I know both systems are getting the same treatment. Here are the software versions: - ubuntu 14.04 vs 16.04 - sssd 1.11.8 vs 1.13.4 - sudo 1.8.9p5 vs. 1.8.19p2 << this is a manual upgrade of the 16.04 default in case a relevant bug was fixed - realm 0.15.0-1 vs. 0.16.2.-2 << these appear to be the only versions available through apt - adcli 0.7.5-1 vs. adcli 0.8.1-1 << same apt limitation Some additional notes and troubleshooting: - Our AD server has an SSL certificate for the domain. ldapsearch has been used to verify that it's functioning correctly. Based on logs, I'm not clear if realm/sssd ever even uses the LDAPS port. - "realm join" only works on Ubuntu 16.04 with either "dns_canonicalize_hostname = false" (in krb5.conf) or "--membership-software=samba". I've tested both of these options on Ubuntu 14.04 and neither affect sudoers (i.e. it works fine). - I've increased the debug_level and verified that sssd is loading both the user's groups and sudoRoles (visually verified contents) and that sssd is (correctly) resolving 2 rules that apply to the user when running sudo -l: [sudosrv_get_sudorules_from_cache] (0x0400): Returning 2 rules for [clayton@<domain>] Is there any more testing I should do at the sssd level or is this where sssd hands off the data and sudo picks it up? Is there a specific line that gives me more information on the handoff? P.S. I'm also interested in resolving my "realm join" issue on 16.04. I've done some digging on the (failing) adcli step of the failing realm join command. The kinit works fine, but it chokes on "SASL(-1): generic failure: GSSAPI Error: An invalid name was supplied (Success)". I've even tried to complete the process passwordless (i.e. https://fedoraproject. org/wiki/QA:Testcase_realmd_join_ccache) but I'm always prompted for a password. P.P.S. Is ldap_uri the right way to switch to LDAPS? Does it even work with the ad provider? Thanks, Clayton Daley

3 2

Looking for wiki page
by s.quesson＠alkante.com 04 May '17

04 May '17

Hi, please I searched in cached page, but I'm unable to access that documentation that seems important to me. Could you provide me an archive of this page? https://fedorahosted.org/sssd/wiki/DesignDocs/LocalGroupMembersForRFC2307 best regards,

3 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users May 2017