sssd-users April 2018

sssd-users@lists.fedorahosted.org

18 participants
19 discussions

sudo rules do not get ALL run-as-user
by Dominik George 23 Apr '18

23 Apr '18

[ Not subscribed, please Cc in replies. ] Hi, we are usign sssd 1.15.0 on Debian stretch, for everything including sudo. The following LDAP entry… dn: cn=%supraadmin,ou=SUDOers,dc=teckids,dc=org objectClass: top objectClass: sudoRole cn: %supraadmin description: Allow everything for supraadmins sudoUser: %supraadmin sudoCommand: ALL sudoHost: ALL …keeps rendering as this insudo… User nik may run the following commands on ticdesk: (root) ALL …even if I add sudoRunAsUser: ALL explicitly. I already tried wiping the sss cache, with no success. Any hints on why this happens: Cheers, Nik -- Dominik George (1. Vorstandsvorsitzender, pädagogischer Leiter) Teckids e.V. - Erkunden, Entdecken, Erfinden. https://www.teckids.org/

2 3

does sssd support using a Microsoft read-only Domain Controller (RODC)?
by James Ralston 19 Apr '18

19 Apr '18

Has anyone figured out how to make sssd utilize a Microsoft read-only Domain Controller (RODC)? The host we want to join to AD is already behind the RODC. So, we are trying to "join" the host to the RODC by pre-creating a computer account object in AD (via a RWDC), then exporting a Kerberos keytab file to install on the client host. On the client host, in the /etc/krb5.conf file, we have overridden the "kdc" setting for our domain, pointing it to the RODC. In /etc/sssd/sssd.conf, we have set "ad_server" for our domain, pointing it to the RODC. Using the exported keytab file, we can run "kinit -k" successfully. But no matter how we create the computer account object, or how we export the Kerberos keytab, sssd cannot use the resulting keytab file to authenticate to the RODC: when sssd sends the AS-REQ, the RODC always replies with KRB5KDC_ERR_PREAUTH_FAILED. I'm beginning to suspect that sssd just doesn't work with RODCs: if "kinit -k" can successfully authenticate and acquire a service principal using the keytab file we exported to the client from the RWDC, then why can't sssd successfully use it? Can anyone confirm that you have sssd successfully speaking to a Microsoft RODC? If so, did you join the client host to a RWDC and then move it behind the RODC? Or did you pre-create the machine account on the RWDC and export the Kerberos keytab to the client? If the latter, do you have the exact net/admod/ktpass commands you used to pre-create the computer account and export the keytab in a way that is compatible with sssd? Thanks in advance for any pointers or advice!

3 5

Existing UID ranges
by John Hearns 19 Apr '18

19 Apr '18

Hello all. I am currently working on a new project to configure sssd authentication, for Ubuntu clients. And hello to Lachlan Musicman - did not expect to see you here! I think this question must be asked many times. So forgive me. We have an existing set of Unix usernames/uids which are pushed out onto the client workstations vi a configuration management system. Ie there are local /etc/passwd files which are updated when new users joint he company. the uid range is 1000 to 3000 If we start to use sssd with AD authentication and the AD RID mapping, then different UIDs will be reported. We do not wish to use the Posix attributes - the whole point is to reduce the manual steps needed when new accounts are created. So my questions are: a) is there any way to map AD RID style UIDs to existing UIDs (I have tried to search for this) b) other orgnisations have faced this. Is the only answer a script to chown each users files if they are transitioned over to AD? Also a question about pam_mkhomedir I have used this successfully in the past, on a BeeGFS filesystem where all the clients have read/write access. If the workstation is an NFS client, then creating a new home directory for a user should not be possible, given that root squash is configured on the NFS share. Is there a smart way to get pam_mkhomedir to work on an NFS client system? Or perhaps the user needs to log into the NFS server system one time only (assuming logins are encouraged directly to servers like that anyway) Thanks for any thoughts and insights. John Hearns

3 3

Automatic parameter update in /etc/sssd/sssd.conf
by TomK 17 Apr '18

17 Apr '18

Hey All, Is there a way to add or modify parameters in sssd.conf without having to grep, sed or awk things to get the same thing done? I know Ansible / Salt are one way but wondering if there are any IPA / SSSD specific commands to do the same. -- Cheers, Tom K. ------------------------------------------------------------------------------------- Living on earth is expensive, but it includes a free trip around the sun.

2 1

unexpected owner for credentials
by Charles Hedrick 11 Apr '18

11 Apr '18

I’m trying to support an odd configuration. We have an IPA system, which is used in the normal way for systems run by staff. But we have hundreds of systems run by faculty and grad students. I’d like to encourage them to integrate with our system. However their usernames and UIDs don’t typically match ours. I don’t think there’s much I can do about usernames. But I’d at least like to survive differing UIDs. Kerberos and even NFS V4 don’t care about UIDs. So I set up sssd pointing to IPA, with access_provider = deny (meaning only people accepted by pam_unix can login), and nsswitch.conf having “files sss." If a user logins in with the Kerberos password they’re logged in correctly, but they can’t access their own Kerberos credentials. Their logged in UID is the one in /etc/passwd, because login correctly obeys nsswitch. But their Kerberos credentials are for the UID in IPA. I can change id_provider to proxy/files. But then the sss nsswitch map doesn’t work. I need to get groups from IPA in order to interpret groups on our Netapp. I’d like to get users from IPA when there isn’t an entry in /etc/passwd, so that ls -l on the Netapp can interpret user names. So what I’d like is that when sssd creates Kerberos credentials, it uses the same user that login is going to use, i.e. that it obeys nsswitch. Is this a reasonable expectation? Going further, I’d like a way to do username mapping that will work with both sssd and Kerberos. One approach would be to pay attention to the username map in /etc/krb5.conf or idmapd.conf, since I’d have to put the mapping in both (I think).

3 7

Config for joining AD forest and Kerberos cross-domain authentication
by Bastian Rosner 11 Apr '18

11 Apr '18

Hi, we are looking for a detailed configuration example to join an AD forest with working Kerberos authentication. Our AD infrastructure consists of a single forest with multiple (sub-)domains in two-way trust. No FreeIPA, just Windows 2012 AD servers and SSSD clients using version 1.11 and 1.15 on Debian. We can successfully join with sssd-ad using the "net ads join" command and users from the same domain can authenticate using a Kerberos ticket or password. Also mounting CIFS shares via pam-mount works fine in the same domain. Unfortunately, users from other domains can't use their Kerberos ticket, only password works. These users are specifying their domain on login. Surprisingly, once logged in after authenticating with a password, foreign-domain users are able to issue a Kerberos ticket with kinit if they specify username@FQDN (with capital letters). Also lookup up group membership of users from another domain works fine, so presumably the LDAP part is working correctly. This is our current config, are we missing something in order to get Kerberos cross-domain authentication working? $ cat /etc/sssd/sssd.conf [sssd] domains = sub1.example.com services = nss, pam, pac config_file_version = 2 [nss] filter_groups = root filter_users = root [pam] [domain/sub1.example.com] id_provider = ad auth_provider = ad chpass_provider = ad access_provider = ad cache_credentials = true ldap_referrals = false ldap_force_upper_case_realm = true ad_gpo_access_control = disabled override_homedir = /home/%u default_shell = /bin/bash Thanks and kind regards, Bastian

4 8

Re: AD sudo rules have no values for attributes?
by Max DiOrio 05 Apr '18

05 Apr '18

I fixed it. Here’s more from the sssd_domain log. A single line revealed the issue. When storing the DevTest rule it said a value is provided more than once. When I looked at the entry in AD, the attribute sudoUser had the same group entered twice. Once as %GS-Technology, once as %gs-technology. I’m guessing someone was thinking that the group lookup was case sensitive and entered it both ways to rule that out. Ends up breaking the storing of the rules and it seems if one rule fails to be stored, they all are. Not necessarily the best thing to do maybe? (Thu Apr 5 13:30:44 2018) [sssd[be[internal.ieeeglobalspec.com]]] [sysdb_store_custom] (0x0020): Failed to store custom entry: Attribute or value exists(20)[attribute 'sudoUser': value #5 on 'name=DevTest,cn=sudorules,cn=custom,cn=internal.ieeeglobalspec.com,cn=sysdb' provided more than once] Thanks! Max

2 2

AD sudo rules have no values for attributes?
by Max DiOrio 05 Apr '18

05 Apr '18

I've got a few dozen servers using SSSD to authenticate and retrieve SUDO rules stored in AD and GPO. Everything works perfectly except for a new RHEL 6.8 server I brought up. sssd version 1.13.3 on both the working 6.8 and non-working 6.8 server. I literally copied the nsswitch, sssd.conf and pam.d configs between the two just to make sure I didn't typo anything. It authenticates fine and I can ssh into it, id account, do genet on the users and groups without a problem. But sudo fails. Looking at debug logs, I see it retrieving the 3 sudo rules we have stored in AD, however it's complaining that there are no sub-attributes in the rules when there clearly are. I'm guessing this is the source of my issues, but I have no idea why it's not working only on this one server. Any thoughts? Thanks! (Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] (Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]] [sdap_parse_entry] (0x1000): OriginalDN: [CN=fullaccess,OU=sudoers,DC=internal,DC=ieeeglobalspec,DC=com]. (Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectClass] (Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] (Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [uSNChanged] (Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [sudoCommand] (Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [sudoUser] (Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [sudoHost] (Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]] [sdap_process_result] (0x2000): Trace: sh[0xd42dc0], connected[1], ops[0xd677a0], ldap[0xd42800] (Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] (Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]] [sdap_parse_entry] (0x1000): OriginalDN: [CN=DevTest,OU=sudoers,DC=internal,DC=ieeeglobalspec,DC=com]. (Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectClass] (Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] (Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [uSNChanged] (Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [sudoRunAsUser] (Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [sudoCommand] (Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [sudoUser] (Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [sudoHost] .... (Thu Apr 5 09:45:34 2018) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=a-mdiorio)(sudoUser=a-mdiorio)(sudoUser=#1002201106)(sudoUser=%Allowed\20RODC\20Password$ Thu Apr 5 09:45:34 2018) [sssd[sudo]] [sudosrv_get_rules] (0x2000): About to get sudo rules from cache (Thu Apr 5 09:45:34 2018) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(name=defaults)))] (Thu Apr 5 09:45:34 2018) [sssd[sudo]] [sudosrv_get_sudorules_from_cache] (0x0400): Returning 0 rules for [<default options>@ internal.ieeeglobalspec.com] (Thu Apr 5 09:45:34 2018) [sssd[sudo]] [sss_parse_name_for_domains] (0x0200): name 'a-mdiorio' matched without domain, user is a-mdiorio (Thu Apr 5 09:45:34 2018) [sssd[sudo]] [sss_parse_name_for_domains] (0x0200): name 'a-mdiorio' matched without domain, user is a-mdiorio (Thu Apr 5 09:45:34 2018) [sssd[sudo]] [sudosrv_cmd_parse_query_done] (0x0200): Requesting rules for [a-mdiorio] from [<ALL>] (Thu Apr 5 09:45:34 2018) [sssd[sudo]] [sss_ncache_check_str] (0x2000): Checking negative cache for [NCE/USER/internal.ieeeglobalspec.com/a-mdiorio] (Thu Apr 5 09:45:34 2018) [sssd[sudo]] [sudosrv_get_user] (0x0200): Requesting info about [a-mdiorio(a)internal.ieeeglobalspec.com] (Thu Apr 5 09:45:34 2018) [sssd[sudo]] [sudosrv_get_user] (0x0400): Returning info for user [a-mdiorio(a)internal.ieeeglobalspec.com] (Thu Apr 5 09:45:34 2018) [sssd[sudo]] [sudosrv_get_rules] (0x0400): Retrieving rules for [a-mdiorio] from [internal.ieeeglobalspec.com] (Thu Apr 5 09:45:34 2018) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=a-mdiorio)(sudoUser=a-mdiorio)(sudoUser=#1002201106)(sudoUser=%Allowed\20RODC\20Password$ (Thu Apr 5 09:45:34 2018) [sssd[sudo]] [sudosrv_get_rules] (0x2000): About to get sudo rules from cache (Thu Apr 5 09:45:34 2018) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=a-mdiorio)(sudoUser=a-mdiorio)(sudoUser=#1002201106)(sudoUser=%Allowed\20RODC\20Password\20Replication\$ (Thu Apr 5 09:45:34 2018) [sssd[sudo]] [sudosrv_get_sudorules_from_cache] (0x0400): Returning 0 rules for [a-mdiorio(a)internal.ieeeglobalspec.com]

1 0

sssd 1.16.1 wont start, Centos 7.4
by Lachlan Musicman 04 Apr '18

04 Apr '18

Using the newly minted SSSD 1.16.1 from COPR, the sssd service doesn't restart. ( https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-16/) The journalctl -xe shows: -- Unit sssd.service has begun starting up. Mar 29 09:05:55 linuxclient1.unixdev.company.com sssd[1477]: Starting up Mar 29 09:05:55 linuxclient1.unixdev.company.com systemd[1]: sssd.service: main process exited, code=exited, status=3/NOTIMPLEMENTED Mar 29 09:05:55 linuxclient1.unixdev.company.com systemd[1]: Failed to start System Security Services Daemon. -- Subject: Unit sssd.service has failed -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel The /var/log/sssd/sssd.log shows (Thu Mar 29 09:03:44 2018) [sssd] [server_setup] (0x0400): CONFDB: /var/lib/sss/db/config.ldb (Thu Mar 29 09:03:44 2018) [sssd] [_snotify_create] (0x0400): Added a watch for /etc/resolv.conf with inotify flags 0x8D88 internal flags 0x1 using function resolv_conf_inotify_cb after delay 1.0 (Thu Mar 29 09:03:44 2018) [sssd] [sss_names_init_from_args] (0x0100): Using re [(((?P<domain>[^\\]+)\\(?P<name>.+$))|((?P<name>[^@]+)@(?P<domain>.+$))|(^(?P<name>[^@\\]+)$))]. (Thu Mar 29 09:03:44 2018) [sssd] [sss_fqnames_init] (0x0100): Using fq format [%1$s]. (Thu Mar 29 09:03:44 2018) [sssd] [sysdb_domain_init_internal] (0x0200): DB File for unixdev.company.com: /var/lib/sss/db/cache_unixdev.company.com.ldb (Thu Mar 29 09:03:44 2018) [sssd] [sysdb_domain_init_internal] (0x0200): Timestamp file for unixdev.company.com: /var/lib/sss/db/timestamps_unixdev.company.com.ldb (Thu Mar 29 09:03:44 2018) [sssd] [ldb] (0x0400): asq: Unable to register control with rootdse! (Thu Mar 29 09:03:44 2018) [sssd] [sbus_new_server] (0x0020): dbus_server_listen failed! (name=org.freedesktop.DBus.Error.AccessDenied, message=Failed to bind socket "/var/lib/sss/pipes/private/sbus-monitor": Permission denied) (Thu Mar 29 09:05:55 2018) [sssd] [server_setup] (0x0400): CONFDB: /var/lib/sss/db/config.ldb (Thu Mar 29 09:05:55 2018) [sssd] [_snotify_create] (0x0400): Added a watch for /etc/resolv.conf with inotify flags 0x8D88 internal flags 0x1 using function resolv_conf_inotify_cb after delay 1.0 (Thu Mar 29 09:05:55 2018) [sssd] [sss_names_init_from_args] (0x0100): Using re [(((?P<domain>[^\\]+)\\(?P<name>.+$))|((?P<name>[^@]+)@(?P<domain>.+$))|(^(?P<name>[^@\\]+)$))]. (Thu Mar 29 09:05:55 2018) [sssd] [sss_fqnames_init] (0x0100): Using fq format [%1$s]. (Thu Mar 29 09:05:55 2018) [sssd] [sysdb_domain_init_internal] (0x0200): DB File for unixdev.company.com: /var/lib/sss/db/cache_unixdev.company.com.ldb (Thu Mar 29 09:05:55 2018) [sssd] [sysdb_domain_init_internal] (0x0200): Timestamp file for unixdev.company.com: /var/lib/sss/db/timestamps_unixdev.company.com.ldb (Thu Mar 29 09:05:55 2018) [sssd] [ldb] (0x0400): asq: Unable to register control with rootdse! (Thu Mar 29 09:05:55 2018) [sssd] [sbus_new_server] (0x0020): dbus_server_listen failed! (name=org.freedesktop.DBus.Error.AccessDenied, message=Failed to bind socket "/var/lib/sss/pipes/private/sbus-monitor": Permission denied) /var/lib/sss/pipes/private shows drwxr-x---. 2 sssd root 4096 Mar 29 08:50 . drwxr-xr-x. 3 sssd sssd 71 Mar 29 03:01 .. srw------- 1 root root 0 Mar 19 09:21 pam lrwxrwxrwx 1 root root 62 Mar 19 09:20 sbus-dp_unixdev.company.com -> /var/lib/sss/pipes/private/sbus-dp_unixdev.company.com.758 srw------- 1 root root 0 Sep 18 2017 sbus-dp_unixdev.company.com.732 srw------- 1 root root 0 Dec 28 09:47 sbus-dp_unixdev.company.com.746 It looks like there's some clean up that's not happening? I don't actually know what sbus_dp files do, but the top result (pointing to .758) doesn't exist... How do I fix this? Cheers L. ------ "The antidote to apocalypticism is *apocalyptic civics*. Apocalyptic civics is the insistence that we cannot ignore the truth, nor should we panic about it. It is a shared consciousness that our institutions have failed and our ecosystem is collapsing, yet we are still here — and we are creative agents who can shape our destinies. Apocalyptic civics is the conviction that the only way out is through, and the only way through is together. " *Greg Bloom* @greggish https://twitter.com/greggish/status/873177525903609857

3 7

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users April 2018