sssd-users March 2016

sssd-users@lists.fedorahosted.org

24 participants
19 discussions

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

full_name_format and supplemental groups
by Orion Poplawski 25 Oct '16

25 Oct '16

Running IPA with an AD trust. Users are in AD. Trying to use full_name_format = %1$s to strip the domain from user names. This appears to break supplemental groups in strange ways. On the IPA server: Without full_name_format: # id orion(a)ad.nwra.com uid=470202603(orion(a)ad.nwra.com) gid=470202603(orion(a)ad.nwra.com) groups=470202603(orion(a)ad.nwra.com),470200513(domain users(a)ad.nwra.com),470204703(pirep rd users(a)ad.nwra.com),470204714(wireless access@ad.nwra.com),470204715(nwra-users@ad.nwra.com),470204701(boulder@ad.nwra.com),470207608(heimdall users(a)ad.nwra.com),470200512(domain admins(a)ad.nwra.com),470207124(andreas admins(a)ad.nwra.com) With: # id orion(a)ad.nwra.com uid=470202603(orion) gid=470202603(orion) groups=470202603(orion) If I add: default_domain_suffix = ad.nwra.com # id orion uid=470202603(orion) gid=470202603(orion) groups=470202603(orion),470200512(domain admins),470207608(heimdall users),470204714(wireless access),470204715(nwra-users),470204701(boulder),470204703(pirep rd users),470207124(andreas admins),470200513(domain users) Which I guess makes some sense as you'd need to add the domain suffix back on to find the groups. But this appears to completely break IPA clients (with full_name_format = %1$s and default_domain_suffix = ad.nwra.com): # id orion(a)ad.nwra.com id: orion(a)ad.nwra.com: no such user # id orion id: orion: no such user >From looking at the server logs, it looks like only the IPA domain is searched If I reset the server back to normal (drop full_name_format and default_domain_suffix): # id orion uid=470202603(orion) gid=470202603(orion) groups=470202603(orion) I don't get any supplemental groups. I see sssd errors like: (Mon Mar 30 15:20:52 2015) [sssd[be[nwra.com]]] [sysdb_mod_group_member] (0x0400): Error: 2 (No such file or directory) (Mon Mar 30 15:20:52 2015) [sssd[be[nwra.com]]] [sysdb_update_members_ex] (0x0020): Could not add member [orion] to group [name=domain admins,cn=groups,cn=nwra.com,cn=sysdb]. Skipping. Is t trying "cn=groups,cn=nwra.com,cn=sysdb" instead of "cn=groups,cn=ad.nwra.com,cn=sysdb" -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion(a)nwra.com Boulder, CO 80301 http://www.nwra.com

3 7

netlink messages on Infiniband causing sssd to exit
by Ryan Novosielski 19 Aug '16

19 Aug '16

Over time, I’ve been having seemingly random sssd quits that I’ve not been able to figure out. Today, I finally traced it to fluctuations on my Infiniband fabric: sssd.log (Tue Nov 3 13:17:59 2015) [sssd] [message_type] (0x0200): netlink Message type: 16 (Tue Nov 3 13:17:59 2015) [sssd] [link_msg_handler] (0x1000): netlink link message: iface idx 4 (ib0) flags 0x1003 (broadcast,multicast,up) (Tue Nov 3 13:17:59 2015) [sssd] [message_type] (0x0200): netlink Message type: 16 (Tue Nov 3 13:17:59 2015) [sssd] [link_msg_handler] (0x1000): netlink link message: iface idx 4 (ib0) flags 0x11043 (broadcast,multicast,up,running,lower) This exactly corresponds to the time in /var/log/messages for the unexplained shutdown: 2015-11-03T13:17:59-05:00 node75 sssd[pam]: Shutting down 2015-11-03T13:17:59-05:00 node75 sssd[be[default]]: Shutting down 2015-11-03T13:17:59-05:00 node75 sssd[nss]: Shutting down Here is sssd_default.log for good measure: (Tue Nov 3 13:17:59 2015) [sssd[be[default]]] [sbus_remove_watch] (0x2000): 0x1414770/0x14133d0 (Tue Nov 3 13:17:59 2015) [sssd[be[default]]] [sbus_remove_watch] (0x2000): 0x1414770/0x13fef90 (Tue Nov 3 13:17:59 2015) [sssd[be[default]]] [be_ptask_destructor] (0x0400): Terminating periodic task [Cleanup of default] (Tue Nov 3 13:17:59 2015) [sssd[be[default]]] [sdap_handle_release] (0x2000): Trace: sh[0x14bd850], connected[1], ops[(nil)], ldap[0x1424260], destructor_lock[0], release_memory[0] (Tue Nov 3 13:17:59 2015) [sssd[be[default]]] [remove_connection_callback] (0x4000): Successfully removed connection callback. (Tue Nov 3 13:17:59 2015) [sssd[be[default]]] [sbus_remove_watch] (0x2000): 0x1415970/0x1416430 (Tue Nov 3 13:17:59 2015) [sssd[be[default]]] [remove_socket_symlink] (0x4000): The symlink points to [/var/lib/sss/pipes/private/sbus-dp_default.18702] (Tue Nov 3 13:17:59 2015) [sssd[be[default]]] [remove_socket_symlink] (0x4000): The path including our pid is [/var/lib/sss/pipes/private/sbus-dp_default.18702] (Tue Nov 3 13:17:59 2015) [sssd[be[default]]] [remove_socket_symlink] (0x4000): Removed the symlink (Tue Nov 3 13:17:59 2015) [sssd[be[default]]] [be_client_destructor] (0x0400): Removed PAM client (Tue Nov 3 13:17:59 2015) [sssd[be[default]]] [be_client_destructor] (0x0400): Removed NSS client I can duplicate this by manually taking down the Infiniband link: [root@node24 ~]# service sssd status sssd (pid 9132) is running... [root@node24 ~]# ifdown ib0 [root@node24 ~]# service sssd status sssd dead but pid file exists I have also noticed that sssd will not start on boot. As I know that Infiniband tends to flutter a little bit before the link comes up, I’m thinking this is probably the same cause. Can anyone explain this behavior and tell me what I might do to prevent it? -- ____ *Note: UMDNJ is now Rutgers-Biomedical and Health Sciences* || \\UTGERS |---------------------*O*--------------------- ||_// Biomedical | Ryan Novosielski - Senior Technologist || \\ and Health | novosirj(a)rutgers.edu - 973/972.0922 (2x0922) || \\ Sciences | OIRT/High Perf & Res Comp - MSB C630, Newark `'

5 7

Caching of automount maps
by Jason L Tibbitts III 30 Mar '16

30 Mar '16

I'm trying to better understand how sssd caches automount maps. I've had everything working for quite some time; autofs will get the maps (which are stored in ldap) from sssd when the system boots and in general there are no issues. However, there are a couple of problems I've been having: * Autofs is mostly nonfunctional When a system boots without the network. * Even with a network, autofs sometimes simply fails to start with: automount[917]: setautomntent: lookup(sss): setautomntent: No such file or directory --- With no network, autofs starts but the only thing which operates is the /net map because that's in /etc/auto.master. The rest of the maps simply aren't there, and if the network returns, autofs doesn't notice (which I know is an issue with autofs). I thought that sssd would be able to cache the master map entries which come from ldap when the network is offline, but that doesn't seem to be the case. I know that it couldn't actually mount anything, but if it at had access to a cached version the map, it would at least start properly. --- The startup failure is rather difficult to reproduce. My guess is that autofs is simply coming up before sssd is ready to provide the master map, but I haven't been able to confirm that. I also haven't been able to see how much of autofs is actually functioning in that case (because people keep rebooting their desktops before I can examine one in detail). --- By skipping ldap and storing the entire master map in /etc/auto.master, everything seems to work better. At least, the first problem goes away entirely, and I haven't yet been able to reproduce the second problem. With a local auto.master and no network, autofs starts up OK but automount -m shows no data at all for the maps. This also surprises me because I figured they'd be cached. As soon as the network returns the maps appear. Is this the normal behavior? Am I expecting sssd to cache things it isn't supposed to be caching? - J<

3 6

stale config used when restarting sssd 1.13.0-40
by Chadwick Banning 29 Mar '16

29 Mar '16

I am joining a machine to a domain via Realmd and then filling out the SSSD config with a few more directives such as setting dyndns_update = false. Every once in a while, I'm finding that SSSD is using the old configuration even after restarting the service or starting it interactively. Sanitized config: [root@host]# cat /etc/sssd/sssd.conf [domain/<domain.com>] access_provider = simple ad_domain = <domain.com> ad_hostname = <host.domain.com> cache_credentials = true debug_level = 6 default_shell = /bin/bash dyndns_update = false fallback_homedir = /home/%u id_provider = ad krb5_realm = <DOMAIN.COM> krb5_store_password_if_offline = true ldap_id_mapping = true realmd_tags = manages-system joined-with-adcli simple_allow_groups = <group> use_fully_qualified_names = false [sssd] config_file_version = 2 domains = <domain.com> services = nss,pam If I restart the service, all logs are blank under /var/log/sssd/* so it is not picking up the debug level in the config and I also have trouble logging in. If I start the service interactively: [root@host]# sssd -d 6 -i ...snip... (Fri Mar 18 14:23:58 2016) [sssd[be[<domain.com>]]] [ad_failover_init] (0x0100): No primary servers defined, using service discovery (Fri Mar 18 14:23:58 2016) [sssd[be[<domain.com>]]] [fo_add_srv_server] (0x0400): Adding new SRV server to service 'AD_GC' using 'tcp'. (Fri Mar 18 14:23:58 2016) [sssd[be[<domain.com>]]] [fo_add_srv_server] (0x0400): Adding new SRV server to service 'AD' using 'tcp'. (Fri Mar 18 14:23:58 2016) [sssd[be[<domain.com>]]] [_ad_servers_init] (0x0100): Added service discovery for AD (Fri Mar 18 14:23:58 2016) [sssd[be[<domain.com>]]] [dp_get_options] (0x0400): Option dyndns_update is TRUE (Fri Mar 18 14:23:58 2016) [sssd[be[<domain.com>]]] [dp_get_options] (0x0400): Option dyndns_refresh_interval has value 86400 (Fri Mar 18 14:23:58 2016) [sssd[be[<domain.com>]]] [dp_get_options] (0x0400): Option dyndns_iface has no value (Fri Mar 18 14:23:58 2016) [sssd[be[<domain.com>]]] [dp_get_options] (0x0400): Option dyndns_ttl has value 3600 (Fri Mar 18 14:23:58 2016) [sssd[be[<domain.com>]]] [dp_get_options] (0x0400): Option dyndns_update_ptr is TRUE (Fri Mar 18 14:23:58 2016) [sssd[be[<domain.com>]]] [dp_get_options] (0x0400): Option dyndns_force_tcp is FALSE (Fri Mar 18 14:23:58 2016) [sssd[be[<domain.com>]]] [dp_get_options] (0x0400): Option dyndns_auth has value gss-tsig (Fri Mar 18 14:23:58 2016) [sssd[be[<domain.com>]]] [dp_get_options] (0x0400): Option dyndns_server has no value ...snip... It clearly sees dyndns_update as TRUE even though its set to false in the config. It remains stuck in this state until i remove /var/lib/sss/db/config.ldb and restart the service, after which everything is fine. Is there any way for me to dig into why the config.ldb file would not be refreshed after config changes and service restart?

3 8

accessing ldap through sssd
by Cyril Scetbon 29 Mar '16

29 Mar '16

Hi Guys, I've made some tests and I have a few questions regarding sssd. We were using pam_ldap and at first I thought that sssd could work with pam_ldap but I didn't find a way to make it work. If I enable the debug mode in the pam section, I don't see anything. As sssd can query for the ldap password + do the caching, it may be the reason why they can't work together. I've been able to make it work by putting my ldap configuration in the domain section and I've verified that if the ldap server becomes unavailable then sssd uses the password version it has cached [sssd[be[default]]] [sdap_pam_auth_done] (0x0100): Password successfully cached for mouser However, when the ldap server is available, I see that every time I try to log in, it does a ldap request instead of reusing the value it has cached : [sssd[be[default]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(uid=myuser)(objectclass=posixAccount))][dc=fti,dc=net] As entry_cache_timeout is set to 600 per default, I would expect sssd to only query the ldap every 600 seconds and use the cached value otherwise. What am I missing ? I see sssd tries to access many attributes for my user and that some of them are missing. Can it be the reason it doesn't reuse the cache except if the ldap is offline ? Thank you -- Cyril

5 26

sssd-ad login failures after certain period
by Christoph Kaunzner 29 Mar '16

29 Mar '16

4 6

sssd responders fail regularly on busy servers
by Patrick Coleman 24 Mar '16

24 Mar '16

Hi, We run sssd to bind a number of machines to LDAP for auth. On a subset of these machines, we have software that makes several thousand IPv6 route changes per second. Recently, we found that on these hosts the sssd_nss responder process fails several times a day[1], and will not recover until sssd is restarted. strace[2] of the main sssd process indicates that sssd is receiving many, many netlink messages - so many, in fact, that sssd cannot process them fast enough and is receiving ENOBUFS from recvmsg(2). The messages that are received seem to get forwarded[3] to the sssd responders over the unix socket and flood them until they fail. From what I can see, the netlink code in src/monitor/monitor_netlink.c:setup_netlink() subscribes to netlink notifications with the aim of detecting things like wifi network changes. This isn't something we'd find useful on our servers and seems to have performance implications - is there any easy way of turning off this functionality in sssd that I've missed? We see this issue running sssd 1.11.7. Cheers, Patrick 1. The failures look something like this. I have replaced our sss domain with "ourdomain" /var/log/sssd/sssd_nss.log (Tue Mar 22 02:58:01 2016) [sssd[nss]] [accept_fd_handler] (0x0100): Client connected! (Tue Mar 22 02:58:01 2016) [sssd[nss]] [nss_cmd_initgroups] (0x0100): Requesting info for [systemuser] from [<ALL>] (Tue Mar 22 02:58:01 2016) [sssd[nss]] [nss_cmd_initgroups_search] (0x0100): Requesting info for [systemuser@ourdomain] (Tue Mar 22 02:59:04 2016) [sssd[nss]] [nss_cmd_initgroups_dp_callback] (0x0040): Unable to get information from Data Provider Error: 3, 5, (null) Will try to return what we have in cache (Tue Mar 22 02:59:14 2016) [sssd[nss]] [server_setup] (0x0080): CONFDB: /var/lib/sss/db/config.ldb (Tue Mar 22 02:59:14 2016) [sssd[nss]] [monitor_common_send_id] (0x0100): Sending ID: (nss,1) (Tue Mar 22 02:59:14 2016) [sssd[nss]] [check_file] (0x0020): lstat for [/var/lib/sss/pipes/private/sbus-dp_ourdomain] failed: [2][No such file or directory]. (Tue Mar 22 02:59:14 2016) [sssd[nss]] [sbus_client_init] (0x0020): check_file failed for [/var/lib/sss/pipes/private/sbus-dp_ourdomain]. (Tue Mar 22 02:59:14 2016) [sssd[nss]] [sss_dp_init] (0x0010): Failed to connect to monitor services. (Tue Mar 22 02:59:14 2016) [sssd[nss]] [sss_process_init] (0x0010): fatal error setting up backend connector (Tue Mar 22 02:59:14 2016) [sssd[nss]] [server_setup] (0x0080): CONFDB: /var/lib/sss/db/config.ldb (Tue Mar 22 02:59:14 2016) [sssd[nss]] [monitor_common_send_id] (0x0100): Sending ID: (nss,1) (Tue Mar 22 02:59:14 2016) [sssd[nss]] [check_file] (0x0020): lstat for [/var/lib/sss/pipes/private/sbus-dp_ourdomain] failed: [2][No such file or directory]. (Tue Mar 22 02:59:14 2016) [sssd[nss]] [sbus_client_init] (0x0020): check_file failed for [/var/lib/sss/pipes/private/sbus-dp_ourdomain]. (Tue Mar 22 02:59:14 2016) [sssd[nss]] [sss_dp_init] (0x0010): Failed to connect to monitor services. (Tue Mar 22 02:59:14 2016) [sssd[nss]] [sss_process_init] (0x0010): fatal error setting up backend connector (Tue Mar 22 02:59:14 2016) [sssd[nss]] [server_setup] (0x0080): CONFDB: /var/lib/sss/db/config.ldb (Tue Mar 22 02:59:14 2016) [sssd[nss]] [monitor_common_send_id] (0x0100): Sending ID: (nss,1) (Tue Mar 22 02:59:14 2016) [sssd[nss]] [check_file] (0x0020): lstat for [/var/lib/sss/pipes/private/sbus-dp_ourdomain] failed: [2][No such file or directory]. (Tue Mar 22 02:59:14 2016) [sssd[nss]] [sbus_client_init] (0x0020): check_file failed for [/var/lib/sss/pipes/private/sbus-dp_ourdomain]. (Tue Mar 22 02:59:14 2016) [sssd[nss]] [sss_dp_init] (0x0010): Failed to connect to monitor services. (Tue Mar 22 02:59:14 2016) [sssd[nss]] [sss_process_init] (0x0010): fatal error setting up backend connector (no further messages until service restarts) 2. strace sssd -i sendmsg(12, {msg_name(0)=NULL, msg_iov(2)=[{"l\1\0\1\0\0\0\0M\10\0\0e\0\0\0\1\1o\0\35\0\0\0/org/fre"..., 120}, {"", 0}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 120 gettimeofday({1458663090, 595705}, NULL) = 0 epoll_wait(5, {{EPOLLIN, {u32=150507384, u64=150507384}}}, 1, 1563) = 1 recvmsg(12, {msg_name(0)=NULL, msg_iov(1)=[{"l\2\1\1\0\0\0\0M\10\0\0\10\0\0\0\5\1u\0M\10\0\0\0\2\1\1\0\0\0\0"..., 2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 24 gettimeofday({1458663090, 595978}, NULL) = 0 recvmsg(12, 0xffcdcac0, MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable) gettimeofday({1458663090, 596110}, NULL) = 0 gettimeofday({1458663090, 596151}, NULL) = 0 epoll_wait(5, {{EPOLLIN|EPOLLERR, {u32=150512424, u64=150512424}}}, 1, 1563) = 1 recvmsg(11, 0xffcdcb3c, 0) = -1 ENOBUFS (No buffer space available) gettimeofday({1458663090, 596330}, NULL) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2819, ...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2819, ...}) = 0 write(2, "(Tue Mar 22 09:11:30 2016) [sssd"..., 65(Tue Mar 22 09:11:30 2016) [sssd] [netlink_fd_handler] (0x0020): ) = 65 write(2, "Error while reading from netlink"..., 36Error while reading from netlink fd ) = 36 gettimeofday({1458663090, 596538}, NULL) = 0 epoll_wait(5, {{EPOLLIN, {u32=150512424, u64=150512424}}}, 1, 1563) = 1 recvmsg(11, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000400}, msg_iov(1)=[{"\224\0\0\0\31\0\0\0\0\0\0\0\0\0\0\0\n\200\0\0\1\0\0\1\0\2\0\0\10\0\17\0"..., 4096}], msg_controllen=24, {cmsg_len=24, cmsg_level=SOL_SOCKET, cmsg_type=SCM_CREDENTIALS{pid=0, uid=0, gid=0}}, msg_flags=0}, 0) = 148 gettimeofday({1458663090, 596679}, NULL) = 0 sendmsg(12, {msg_name(0)=NULL, msg_iov(2)=[{"l\1\0\1\0\0\0\0N\10\0\0e\0\0\0\1\1o\0\35\0\0\0/org/fre"..., 120}, {"", 0}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 120 gettimeofday({1458663090, 596777}, NULL) = 0 3. /var/log/sssd/sssd.log (Wed Mar 23 06:59:07 2016) [sssd] [message_type] (0x0200): netlink Message type: 24 (Wed Mar 23 06:59:07 2016) [sssd] [route_msg_debug_print] (0x1000): route idx 209591 flags 0X200 family 10 addr fd0a:9b09:1f7:0:218:aff:fe34:3d08/128 (Wed Mar 23 06:59:07 2016) [sssd] [network_status_change_cb] (0x2000): A networking status change detected signaling providers to reset offline status (Wed Mar 23 06:59:07 2016) [sssd] [service_signal] (0x0020): Could not signal service [ourdomain]. (Wed Mar 23 06:59:07 2016) [sssd] [message_type] (0x0200): netlink Message type: 24 (Wed Mar 23 06:59:07 2016) [sssd] [route_msg_debug_print] (0x1000): route idx 209591 flags 0X200 family 10 addr fd0a:9b09:1f7:0:218:aff:fe33:3b66/128 (Wed Mar 23 06:59:07 2016) [sssd] [network_status_change_cb] (0x2000): A networking status change detected signaling providers to reset offline status (Wed Mar 23 06:59:07 2016) [sssd] [service_signal] (0x0020): Could not signal service [ourdomain]. (Wed Mar 23 06:59:07 2016) [sssd] [message_type] (0x0200): netlink Message type: 24 $ grep network_status_change_cb sssd.log | grep '06:59:12' | wc -l 1245

3 4

sssd responders fail regularly on busy servers
by Patrick Coleman 23 Mar '16

23 Mar '16

1 0

Re: sssd-ad login failures after certain period (Striker Leggette)
by Christoph Kaunzner 23 Mar '16

23 Mar '16

Hi Striker, yes, I used this method (restart, clear db) so far to resolve the problem. Thanks for the info about id_provider, will adjust the config. I will report again once I have a debug log when this issues happens. Thanks, Christoph On 03/21/2016 12:49 PM, Striker Legette wrote: > Hi, > > If it works right after joining, then I wouldn't expect anything in your > config. would be wrong. 'debug_level = 7' in your [domain] section will > tell more. Does the following command clear the issue for some time? > > # service sssd stop ; rm -rf /var/lib/sss/db/* ; service sssd start > > Also, you have some duplicates in your config. Since 'auth_provider' > and 'chpass_provider' is the same as 'id_provider', you do not actually > need to specify them. > > Striker

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users March 2016