[SSSD-users] Re: System Error (4) for passwd users
On Wed, Jan 24, 2018 at 06:06:38PM +0100, Franky Van Liedekerke wrote: > Op Woensdag, 24-01-2018 om 17:44 schreef Jakub Hrozek: > > On Wed, Jan 24, 2018 at 05:25:26PM +0100, Franky Van Liedekerke wrote: > > > Op Woensdag, 24-01-2018 om 16:45 schreef Jakub Hrozek: > > > > On Wed, Jan 24, 2018 at 10:10:11AM -0500, Geoff Goehle wrote: > > > > > Sorry about the line breaks. Adding "enable_files_domain = false" to > > > > > the [sssd] section fixed the issue. Just out of curiosity, could I > > > > > ask what that does? Its not in the man page. > > > > > > > > SSSD has a feature which mirrors the local /etc/passwd and /etc/group > > > > files for faster lookups of local users without having to enable nscd > > > > which is tricky to operate together with sssd, especially if you run > > > > sssd for a remote domain, too: > > > > https://fedoraproject.org/wiki/Changes/SSSDCacheForLocalUsers > > > > But I'm surprised that Debian would enable this feature without changing > > > > the nsswitch.conf order like Fedora did. They probably should disable > > > > the files domain by default.. > > > > > > > > The files domain is currently identity-only and no authentication is > > > > performed. That, together with the duplicate users and the files domain > > > > running by default has been causing the failures for you.. > > > > > > On a side-note: I just tested this enable_files_domain and it seems using > > > it results in the next domain still being queried for local users > > > (verified by sifting through the ldap server logs). Using an explicit > > > domain with id_provider=files apparently works differently (that domain > > > answers and the next one is not queried), which is not very transparent. > > > Is this expected? > > > > What was the order of the explicit domains? Note the implicit domain is > > always prepended before any other domain.. > > The order in case of an explicit domain is first the files-based one, then > ldap. So the order is (or should be) identical in both cases. > Then I don't know without logs, sorry. ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
[SSSD-users] Re: System Error (4) for passwd users
Op Woensdag, 24-01-2018 om 17:44 schreef Jakub Hrozek: > On Wed, Jan 24, 2018 at 05:25:26PM +0100, Franky Van Liedekerke wrote: > > Op Woensdag, 24-01-2018 om 16:45 schreef Jakub Hrozek: > > > On Wed, Jan 24, 2018 at 10:10:11AM -0500, Geoff Goehle wrote: > > > > Sorry about the line breaks. Adding "enable_files_domain = false" to > > > > the [sssd] section fixed the issue. Just out of curiosity, could I ask > > > > what that does? Its not in the man page. > > > > > > SSSD has a feature which mirrors the local /etc/passwd and /etc/group > > > files for faster lookups of local users without having to enable nscd > > > which is tricky to operate together with sssd, especially if you run > > > sssd for a remote domain, too: > > > https://fedoraproject.org/wiki/Changes/SSSDCacheForLocalUsers > > > But I'm surprised that Debian would enable this feature without changing > > > the nsswitch.conf order like Fedora did. They probably should disable > > > the files domain by default.. > > > > > > The files domain is currently identity-only and no authentication is > > > performed. That, together with the duplicate users and the files domain > > > running by default has been causing the failures for you.. > > > > On a side-note: I just tested this enable_files_domain and it seems using > > it results in the next domain still being queried for local users (verified > > by sifting through the ldap server logs). Using an explicit domain with > > id_provider=files apparently works differently (that domain answers and the > > next one is not queried), which is not very transparent. > > Is this expected? > > What was the order of the explicit domains? Note the implicit domain is > always prepended before any other domain.. The order in case of an explicit domain is first the files-based one, then ldap. So the order is (or should be) identical in both cases. Franky ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
[SSSD-users] Re: System Error (4) for passwd users
On Wed, Jan 24, 2018 at 05:25:26PM +0100, Franky Van Liedekerke wrote: > Op Woensdag, 24-01-2018 om 16:45 schreef Jakub Hrozek: > > On Wed, Jan 24, 2018 at 10:10:11AM -0500, Geoff Goehle wrote: > > > Sorry about the line breaks. Adding "enable_files_domain = false" to the > > > [sssd] section fixed the issue. Just out of curiosity, could I ask what > > > that does? Its not in the man page. > > > > SSSD has a feature which mirrors the local /etc/passwd and /etc/group > > files for faster lookups of local users without having to enable nscd > > which is tricky to operate together with sssd, especially if you run > > sssd for a remote domain, too: > > https://fedoraproject.org/wiki/Changes/SSSDCacheForLocalUsers > > But I'm surprised that Debian would enable this feature without changing > > the nsswitch.conf order like Fedora did. They probably should disable > > the files domain by default.. > > > > The files domain is currently identity-only and no authentication is > > performed. That, together with the duplicate users and the files domain > > running by default has been causing the failures for you.. > > On a side-note: I just tested this enable_files_domain and it seems using it > results in the next domain still being queried for local users (verified by > sifting through the ldap server logs). Using an explicit domain with > id_provider=files apparently works differently (that domain answers and the > next one is not queried), which is not very transparent. > Is this expected? What was the order of the explicit domains? Note the implicit domain is always prepended before any other domain.. ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
[SSSD-users] Re: System Error (4) for passwd users
On Wed, Jan 24, 2018 at 10:10:11AM -0500, Geoff Goehle wrote: > Sorry about the line breaks. Adding "enable_files_domain = false" to the > [sssd] section fixed the issue. Just out of curiosity, could I ask what that > does? Its not in the man page. SSSD has a feature which mirrors the local /etc/passwd and /etc/group files for faster lookups of local users without having to enable nscd which is tricky to operate together with sssd, especially if you run sssd for a remote domain, too: https://fedoraproject.org/wiki/Changes/SSSDCacheForLocalUsers But I'm surprised that Debian would enable this feature without changing the nsswitch.conf order like Fedora did. They probably should disable the files domain by default.. The files domain is currently identity-only and no authentication is performed. That, together with the duplicate users and the files domain running by default has been causing the failures for you.. ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
[SSSD-users] Re: System Error (4) for passwd users
Sorry about the line breaks. Adding "enable_files_domain = false" to the [sssd] section fixed the issue. Just out of curiosity, could I ask what that does? Its not in the man page. Thanks so much for the help. Geoff. On Wed, 2018-01-24 at 15:46 +0100, Jakub Hrozek wrote: > I'm sorry, but the line wraps in your mail are missing, at least that's > how the mail got rendered for me..so I'm having trougle reading the > logs.. > > Nonetheless, does it help if you add enable_files_domain = false into > the [sssd] section? > > On Wed, Jan 24, 2018 at 08:58:11AM -0500, Geoff Goehle wrote: > > Thanks for the response. I was on #sssd and someone said that duplicate > > usernames like we have is a no go, so I was planning on just removing local > > accounts and deal with the fallout. However, > > I'm > > happy to look for a different fix. > > Geoff. > > - We are using the implicit files provider > > - The sssd.conf file is > > [domain/place.edu]id_provider = adaccess_provider = ad > > ldap_idmap_range_min = 20ldap_idmap_range_max = > > 200020ldap_idmap_range_size = 80ldap_pwd_policy = none > > sudo_provider = none > > debug_level = 8 > > [sssd]services = nss, pamconfig_file_version = 2domains = place.edu > > [nss]override_shell=/bin/bashoverride_homedir=/home/%ufilter_users = > > filter_groups = > > [pam]___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
[SSSD-users] Re: System Error (4) for passwd users
I'm sorry, but the line wraps in your mail are missing, at least that's how the mail got rendered for me..so I'm having trougle reading the logs.. Nonetheless, does it help if you add enable_files_domain = false into the [sssd] section? On Wed, Jan 24, 2018 at 08:58:11AM -0500, Geoff Goehle wrote: > Thanks for the response. I was on #sssd and someone said that duplicate > usernames like we have is a no go, so I was planning on just removing local > accounts and deal with the fallout. However, I'm > happy to look for a different fix. > Geoff. > - We are using the implicit files provider > - The sssd.conf file is > [domain/place.edu]id_provider = adaccess_provider = ad > ldap_idmap_range_min = 20ldap_idmap_range_max = > 200020ldap_idmap_range_size = 80ldap_pwd_policy = none > sudo_provider = none > debug_level = 8 > [sssd]services = nss, pamconfig_file_version = 2domains = place.edu > [nss]override_shell=/bin/bashoverride_homedir=/home/%ufilter_users = > filter_groups = > [pam] > - The domain log file is. (There is a failed login attempt in this range of > entries, but it doesn't show up anywhere.) > (Wed Jan 24 08:53:43 2018) [sssd[be[place.edu]]] [child_sig_handler] > (0x1000): Waiting for child [19947].(Wed Jan 24 08:53:43 2018) > [sssd[be[place.edu]]] [child_sig_handler] (0x0020): child [19947] > failed with status [2].(Wed Jan 24 08:53:43 2018) [sssd[be[place.edu]]] > [nsupdate_child_handler] (0x0040): Dynamic DNS child failed with status > [512](Wed Jan 24 08:53:43 2018) [sssd[be[place.edu]]] > [be_nsupdate_done] (0x0040): nsupdate child execution failed [1432158239]: > Dynamic DNS update failed(Wed Jan 24 08:53:43 2018) [sssd[be[place.edu]]] > [sbus_server_init_new_connection] (0x0200): > Entering.(Wed Jan 24 08:53:43 2018) [sssd[be[place.edu]]] > [sbus_server_init_new_connection] (0x0200): Adding connection > 0x55a3326eac70.(Wed Jan 24 08:53:43 2018) [sssd[be[place.edu]]] > [sbus_init_connection] (0x0400): Adding connection 0x55a3326eac70(Wed Jan 24 > 08:53:43 2018) [sssd[be[place.edu]]] [sbus_add_watch] (0x2000): > 0x55a3326d8260/0x55a3326ede90 (19), -/W (disabled)(Wed Jan > 24 08:53:43 2018) [sssd[be[place.edu]]] [sbus_server_init_new_connection] > (0x0200): Got a connection(Wed Jan 24 08:53:43 2018) [sssd[be[place.edu]]] > [dp_client_init] (0x0100): Set-up Backend ID > timeout [0x55a3326e7070](Wed Jan 24 08:53:43 2018) [sssd[be[place.edu]]] > [sbus_opath_hash_add_iface] (0x0400): Registering interface > org.freedesktop.sssd.DataProvider.Client with path > /org/freedesktop/sssd/dataprovider(Wed Jan 24 08:53:43 2018) > [sssd[be[place.edu]]] [sbus_conn_register_path] (0x0400): Registering object > path /org/freedesktop/sssd/dataprovider with D-Bus > connection(Wed Jan 24 08:53:43 2018) [sssd[be[place.edu]]] > [sbus_opath_hash_add_iface] (0x0400): Registering interface > org.freedesktop.DBus.Properties with path > /org/freedesktop/sssd/dataprovider(Wed > Jan 24 08:53:43 2018) [sssd[be[place.edu]]] [sbus_opath_hash_add_iface] > (0x0400): Registering interface org.freedesktop.DBus.Introspectable with path > /org/freedesktop/sssd/dataprovider(Wed Jan 24 > 08:53:43 2018) [sssd[be[place.edu]]] [sbus_opath_hash_add_iface] (0x0400): > Registering interface org.freedesktop.sssd.dataprovider with path > /org/freedesktop/sssd/dataprovider(Wed Jan 24 08:53:43 > 2018) [sssd[be[place.edu]]] [sbus_opath_hash_add_iface] (0x0400): Registering > interface org.freedesktop.sssd.DataProvider.Backend with path > /org/freedesktop/sssd/dataprovider(Wed Jan 24 08:53:43 2018) > [sssd[be[place.edu]]] [sbus_opath_hash_add_iface] (0x0400): Registering > interface org.freedesktop.sssd.DataProvider.Failover with path > /org/freedesktop/sssd/dataprovider(Wed Jan 24 08:53:43 2018) > [sssd[be[place.edu]]] [sbus_server_init_new_connection] (0x0200): > Entering.(Wed Jan 24 08:53:43 2018) [sssd[be[place.edu]]] > [sbus_server_init_new_connection] (0x0200): Adding connection > 0x55a3326e8800.(Wed Jan 24 08:53:43 2018) [sssd[be[place.edu]]] > [sbus_init_connection] (0x0400): Adding connection 0x55a3326e8800(Wed Jan 24 > 08:53:43 2018) [sssd[be[place.edu]]] [sbus_add_watch] > (0x2000): 0x55a3326d8de0/0x55a3326d9630 (20), -/W (disabled)(Wed Jan 24 > 08:53:43 2018) [sssd[be[place.edu]]] [sbus_server_init_new_connection] > (0x0200): Got a connection(Wed Jan 24 08:53:43 2018) > [sssd[be[place.edu]]] [dp_client_init] (0x0100): Set-up Backend ID timeout > [0x55a3326f3510](Wed Jan 24 08:53:43 2018) [sssd[be[place.edu]]] > [sbus_opath_hash_add_iface] (0x0400): Registering interface > org.freedesktop.sssd.DataProvider.Client with path > /org/freedesktop/sssd/dataprovider(Wed Jan 24 08:53:43 2018) > [sssd[be[place.edu]]] [sbus_conn_register_path] (0x0400): Registering object > path > /org/freedesktop/sssd/dataprovider with D-Bus connection(Wed Jan 24 08:53:43 > 2018) [sssd[be[place.edu]]] [sbus_opath_hash_add_iface] (0x0400): Registering > interface org.freedesktop.DBus.Properties >
[SSSD-users] Re: System Error (4) for passwd users
Thanks for the response. I was on #sssd and someone said that duplicate usernames like we have is a no go, so I was planning on just removing local accounts and deal with the fallout. However, I'm happy to look for a different fix. Geoff. - We are using the implicit files provider - The sssd.conf file is [domain/place.edu]id_provider = adaccess_provider = ad ldap_idmap_range_min = 20ldap_idmap_range_max = 200020ldap_idmap_range_size = 80ldap_pwd_policy = none sudo_provider = none debug_level = 8 [sssd]services = nss, pamconfig_file_version = 2domains = place.edu [nss]override_shell=/bin/bashoverride_homedir=/home/%ufilter_users = filter_groups = [pam] - The domain log file is. (There is a failed login attempt in this range of entries, but it doesn't show up anywhere.) (Wed Jan 24 08:53:43 2018) [sssd[be[place.edu]]] [child_sig_handler] (0x1000): Waiting for child [19947].(Wed Jan 24 08:53:43 2018) [sssd[be[place.edu]]] [child_sig_handler] (0x0020): child [19947] failed with status [2].(Wed Jan 24 08:53:43 2018) [sssd[be[place.edu]]] [nsupdate_child_handler] (0x0040): Dynamic DNS child failed with status [512](Wed Jan 24 08:53:43 2018) [sssd[be[place.edu]]] [be_nsupdate_done] (0x0040): nsupdate child execution failed [1432158239]: Dynamic DNS update failed(Wed Jan 24 08:53:43 2018) [sssd[be[place.edu]]] [sbus_server_init_new_connection] (0x0200): Entering.(Wed Jan 24 08:53:43 2018) [sssd[be[place.edu]]] [sbus_server_init_new_connection] (0x0200): Adding connection 0x55a3326eac70.(Wed Jan 24 08:53:43 2018) [sssd[be[place.edu]]] [sbus_init_connection] (0x0400): Adding connection 0x55a3326eac70(Wed Jan 24 08:53:43 2018) [sssd[be[place.edu]]] [sbus_add_watch] (0x2000): 0x55a3326d8260/0x55a3326ede90 (19), -/W (disabled)(Wed Jan 24 08:53:43 2018) [sssd[be[place.edu]]] [sbus_server_init_new_connection] (0x0200): Got a connection(Wed Jan 24 08:53:43 2018) [sssd[be[place.edu]]] [dp_client_init] (0x0100): Set-up Backend ID timeout [0x55a3326e7070](Wed Jan 24 08:53:43 2018) [sssd[be[place.edu]]] [sbus_opath_hash_add_iface] (0x0400): Registering interface org.freedesktop.sssd.DataProvider.Client with path /org/freedesktop/sssd/dataprovider(Wed Jan 24 08:53:43 2018) [sssd[be[place.edu]]] [sbus_conn_register_path] (0x0400): Registering object path /org/freedesktop/sssd/dataprovider with D-Bus connection(Wed Jan 24 08:53:43 2018) [sssd[be[place.edu]]] [sbus_opath_hash_add_iface] (0x0400): Registering interface org.freedesktop.DBus.Properties with path /org/freedesktop/sssd/dataprovider(Wed Jan 24 08:53:43 2018) [sssd[be[place.edu]]] [sbus_opath_hash_add_iface] (0x0400): Registering interface org.freedesktop.DBus.Introspectable with path /org/freedesktop/sssd/dataprovider(Wed Jan 24 08:53:43 2018) [sssd[be[place.edu]]] [sbus_opath_hash_add_iface] (0x0400): Registering interface org.freedesktop.sssd.dataprovider with path /org/freedesktop/sssd/dataprovider(Wed Jan 24 08:53:43 2018) [sssd[be[place.edu]]] [sbus_opath_hash_add_iface] (0x0400): Registering interface org.freedesktop.sssd.DataProvider.Backend with path /org/freedesktop/sssd/dataprovider(Wed Jan 24 08:53:43 2018) [sssd[be[place.edu]]] [sbus_opath_hash_add_iface] (0x0400): Registering interface org.freedesktop.sssd.DataProvider.Failover with path /org/freedesktop/sssd/dataprovider(Wed Jan 24 08:53:43 2018) [sssd[be[place.edu]]] [sbus_server_init_new_connection] (0x0200): Entering.(Wed Jan 24 08:53:43 2018) [sssd[be[place.edu]]] [sbus_server_init_new_connection] (0x0200): Adding connection 0x55a3326e8800.(Wed Jan 24 08:53:43 2018) [sssd[be[place.edu]]] [sbus_init_connection] (0x0400): Adding connection 0x55a3326e8800(Wed Jan 24 08:53:43 2018) [sssd[be[place.edu]]] [sbus_add_watch] (0x2000): 0x55a3326d8de0/0x55a3326d9630 (20), -/W (disabled)(Wed Jan 24 08:53:43 2018) [sssd[be[place.edu]]] [sbus_server_init_new_connection] (0x0200): Got a connection(Wed Jan 24 08:53:43 2018) [sssd[be[place.edu]]] [dp_client_init] (0x0100): Set-up Backend ID timeout [0x55a3326f3510](Wed Jan 24 08:53:43 2018) [sssd[be[place.edu]]] [sbus_opath_hash_add_iface] (0x0400): Registering interface org.freedesktop.sssd.DataProvider.Client with path /org/freedesktop/sssd/dataprovider(Wed Jan 24 08:53:43 2018) [sssd[be[place.edu]]] [sbus_conn_register_path] (0x0400): Registering object path /org/freedesktop/sssd/dataprovider with D-Bus connection(Wed Jan 24 08:53:43 2018) [sssd[be[place.edu]]] [sbus_opath_hash_add_iface] (0x0400): Registering interface org.freedesktop.DBus.Properties with path /org/freedesktop/sssd/dataprovider(Wed Jan 24 08:53:43 2018) [sssd[be[place.edu]]] [sbus_opath_hash_add_iface] (0x0400): Registering interface org.freedesktop.DBus.Introspectable with path /org/freedesktop/sssd/dataprovider(Wed Jan 24 08:53:43 2018) [sssd[be[place.edu]]] [sbus_opath_hash_add_iface] (0x0400): Registering interface org.freedesktop.sssd.dataprovider with path /org/freedesktop/sssd/dataprovider(Wed Jan 24 08:53:43 2018)
[SSSD-users] Re: System Error (4) for passwd users
On Tue, Jan 23, 2018 at 07:44:04PM -0500, goe...@gmail.com wrote: > Hi, > > The troubleshooting guide in the docs said to email the list if the System > Error (4) shows up, so I figured I bring this issue up. I'm running sssd > version 1.16.0 on Debian testing and recently encountered a new behavior. > We set up sssd with active directory based authentication on an already > established system. For various reasons there are still local passwd > users, some of whom also have ad accounts. What used to happen is that the > pam/nsswitch stack was set up so that those users would end up with their > passwd id. If they had an ad account they could log in with either their > shadow password or their ad password. Right after we upgraded from > 1.16.0-1 to 1.16.0-2 any local user generated a System Error (4) in the > logs and and local users with ad accounts could no longer use their ad > passwords (although they could still use their local passwords). There > isn't a lot of information in the logs. Can you also paste your full configuration and the sssd domain log(s) ? Does sssd on Debian use the implicit files provider (ps would show a sssd_be process running with --name implicit_files) ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
