sssd-users August 2018

sssd-users@lists.fedorahosted.org

22 participants
26 discussions

SSSD cache security
by q8ztvkkd＠posteo.de 09 Aug '18

09 Aug '18

Hello! We are deploying SSSD for authentication with an LDAP backend, and we are getting pushback from our Security colleagues about using SSSD to cache user credentials.. I would like to have some documentation to show them how this cache is kept secure...where can I find information to support this? Thanks! K.

4 3

Re: sssd 1.9.6
by Lukas Slebodnik 07 Aug '18

07 Aug '18

On (31/07/18 18:34), Laack, Andrea P wrote: >I downloaded sssd 1.9.6 for centos 5 from https://copr-be.cloud.fedoraproject.org/results/sgallagh/sssd-1.9-rhel5/epe…. >Unfortunately the contents of krb5-1.12.2-14.fc21/ are not there. I have downloaded krb5-workstation, libs, and devel for krb-1.12.2-14 from other places, but the list of dependencies are daunting. Is there anyplace I can get the original contents of this directory? > krb5-1.12.2 is not there because it failed to build and epel-5 buildroots were removed from copr. So it is not possible to build it there anymore https://copr.fedorainfracloud.org/coprs/sgallagh/sssd-1.9-rhel5/builds/ CentOS 5 is not supported for more than a year https://www.centosblog.com/centos-eol-dates/ If you use some enterprise version then I would not recommend to use unsupported version of sssd from copr. I can imagine that you probably need to use el5 due to other old applications. But in such situation you might want to have it in container and bind-mount directory /var/lib/sss/pipes from host(container) which has newer version of sssd. You just need to have installed sssd-client in el5 container. Protocol between sssd-client (libss_nss.so and pam_sss.so) is backward compatible so basic functionality should work. LS

1 0

id: cannot find name for group ID
by Mario Rossi 07 Aug '18

07 Aug '18

Hi All! I am running into an issue where groups cannot be resolved upon login. All servers on CentOS 6 work fine, so this is isolated to newer sssd version on CentOS 7. [user@snoopy ~]$ id uid=100001012(user) *gid=1001* *groups=1001*,10(wheel),1102 [user@snoopy ~]$ getent -s sss passwd user user:*:100001012:1001:User Name:/home/user:/bin/bash However, a quick lookup against the group: [user@snoopy ~]$ *getent -s sss group security* security:*:1001:user Subsequent id lookup works: [user@snoopy ~]$ id uid=100001012(user) *gid=1001(security) **groups=1001(security)*,10(wheel),1102 Sudo also complains about the user, even after above command succeeds [user@snoopy ~]$*sudo su -* *sudo: unknown uid 100001012: who are you?* A few seconds later sudo is no longer confused: [user@snoopy ~]$*sudo su -* *LDAP OnePassword for **user**:* root@snoopy[~]# SSSD config: [sssd] config_file_version = 2 sbus_timeout = 30 services = nss, pam, sudo, ssh # BOUNCE DEV domains = LOCAL, HOSTOPIA, DOMAIN1, DOMAIN2, DOMAIN3 [nss] filter_users = adm,apache,avahi,bin,daemon,dbus,ecryptfs,ftp,git,games,gopher,haldaemon,halt,hfallback,hdeploy,influxdb,ldap,lp,mail,mailnull,named,news,nfsnobody,nobody,nscd,nslcd,ntp,operator,oprofile,osse c,postfix,puppet,puppet-dashboard,pulse,pulse-access,radiusd,root,rpc,rpcuser,rtkit,saslauth,sfallback,shutdown,slocate,smmsp,sshd,sync,tcpdump,tss,uucp,vcsa filter_groups = adm,apache,audio,bin,cdrom,cgred,daemon,dbus,dialout,dip,disk,ecryptfs,floppy,fuse,git,hfallback,hdeploy,influxdb,kmem,ldap,lock,lp,mail,mailnull,man,mem,nfsnobody,nobody,nscd,ntp,ossec,oprof ile,postdrop,postfix,puppet,puppet-dashboard,pulse,pulse-access,root,rpc,rpcuser,rtkit,saslauth,sfallback,slocate,smmsp,sshd,sys,tape,tcpdump,tss,tty,users,utempter,utmp,vcsa,video [pam] debug_level = 0 reconnection_retries = 3 offline_credentials_expiration = 2 offline_failed_login_attempts = 3 offline_failed_login_delay = 5 pam_verbosity = 1 pam_pwd_expiration_warning = 21 pam_account_expired_message = Your LDAP password has expired, please use selfservice portal to change your LDAP password. [sudo] debug_level = 0 [ssh] # debug_level = 0 [domain/LOCAL] description = LOCAL Users domain id_provider = local enumerate = true min_id = 500 max_id = 999 default_shell = /bin/bash base_directory = /home create_homedir = false remove_homedir = true homedir_umask = 077 skel_dir = /etc/skel mail_dir = /var/spool/mail All domains have the following options set: ######### SECTION: HOSTOPIA [domain/HOSTOPIA] min_id = 499 debug_level = 0 cache_credentials = True entry_cache_timeout = 864000 auth_provider = ldap id_provider = ldap access_provider = ldap chpass_provider = none sudo_provider = ldap selinux_provider = none autofs_provider = none hostid_provider = none ldap_use_tokengroups = false # https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-… #ignore_group_members=True lookup_family_order = ipv4_only # LDAP Search ldap_search_base = dc=hostopia,dc=com ldap_group_search_base = ou=groups,o=Hostopia,dc=hostopia,dc=com?subtree?(|(cn=almighties)(cn=security)(cn=systems)(cn=bounce-development)(cn=development-wholesale)(cn=development-retail)(cn=abuse)) ldap_user_search_base = ou=users,o=hostopia,dc=hostopia,dc=com?subtree?(|(description=cn=bounce-development,ou=groups,o=Hostopia,dc=hostopia,dc=com)(description=cn=almighties,ou=groups,o=Hostopia,dc=hostopia ,dc=com)(description=cn=security,ou=groups,o=Hostopia,dc=hostopia,dc=com)) # LDAP Custom Schema ldap_group_member = hMemberDN ldap_user_member_of = description # ldap_schema can be set to "rfc2307", which stores group member names in the # "memberuid" attribute, or to "rfc2307bis", which stores group member DNs in # the "member" attribute. If you do not know this value, ask your LDAP # administrator. ldap_schema = rfc2307bis ldap_network_timeout = 3 ldap_id_use_start_tls = False ldap_tls_reqcert = never ldap_tls_cacertdir = /etc/openldap/cacerts # Ldap Servers ldap_uri = ldaps://SERVER1, ldaps://SERVER2, ldaps://SERVER3 ldap_backup_uri = ldaps://1.1.1.1 ldap_default_authtok_type = obfuscated_password ldap_default_bind_dn = **** ldap_default_authtok = ****** ldap_user_ssh_public_key = sshPublicKey ldap_pwd_policy = none ldap_account_expire_policy = shadow ldap_user_shadow_expire = shadowExpire # shadowExpire: days since Jan 1, 1970 that account is disabled: $ echo $(($(date --utc --date "$1" +%s)/86400)) ldap_chpass_update_last_change = false ldap_access_order = filter, expire ldap_access_filter = (&(objectClass=posixAccount)(uidNumber=*)(hAccountInitialSetup=1)(|(description=cn=bounce-development,ou=groups,o=Hostopia,dc=hostopia,dc=com)(description=cn=almighties,ou=groups,o=Hosto pia,dc=hostopia,dc=com)(description=cn=security,ou=groups,o=Hostopia,dc=hostopia,dc=com))) # SUDO ldap_sudo_search_base = ou=sudoers,o=Hostopia,dc=hostopia,dc=com ldap_sudo_full_refresh_interval = 86400 ldap_sudo_smart_refresh_interval = 3600 #entry_cache_sudo_timeout = 5400 ##### END DOMAIN SECTION #####

2 4

sssd connecting to two AD domains
by Ondrej Valousek 07 Aug '18

07 Aug '18

Hi all, I have a machine joined to AD domain "mydomain.com" and there is also domain "mydomain2.com". The two are connected with full two way trust. SSSD can happily recognize users from "mydomain.com", but fails with users from "mydomain2.com" - sssd complains that: (Mon Jul 30 08:26:38 2018) [sssd[be[adesto]]] [get_port_status] (0x1000): Port status of port 389 for server 'server.mydomain2.com' is 'not working' (Mon Jul 30 08:26:38 2018) [sssd[be[adesto]]] [get_port_status] (0x0080): SSSD is unable to complete the full connection request, this internal status does not necessarily indicate network port issues. But I can connect to that server with ldapsearch just fine (using a TGT obtained with kinit -k hostname$). Earlier in the logs I spotted that SSSD is trying to obtain TGT with a wrong principal "host/hostname@REALM" instead of "hostname$@REALM": (Mon Jul 30 08:32:34 2018) [sssd[be[adesto]]] [sdap_get_tgt_recv] (0x0400): Child responded: 14 [Client 'host/hostname(a)mydomain.COM' not found in Kerberos database], expired on [0] (Mon Jul 30 08:32:34 2018) [sssd[be[adesto]]] [sdap_kinit_done] (0x0100): Could not get TGT: 14 [Bad address] (Mon Jul 30 08:32:34 2018) [sssd[be[adesto]]] [sdap_cli_kinit_done] (0x0400): Cannot get a TGT: ret [1432158226](Authentication Failed) I am wondering why is SSSD trying now, all of sudden, to obtain a TGT using wrong principal? Using RHEL-7. 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.

3 7

06 Aug '18

Hey, I'm wondering if SSSD might not be updating some of the logon attributes in AD. We recently were directed to use updated DCs and some attributes no longer seem to be getting updated; for example, logonCount and lastLogon. In some cases, the attribute is non-existant. I'm leaning towards it being a DC issue since it was gettting updated with the previous controllers but wanted to see if anyone was aware of any reason SSSD could be at issue. thanks =G=

2 2

SSSD attempts Dyndns updates for loopback address [SEC=UNOFFICIAL]
by Kosseck, Adam MR 06 Aug '18

06 Aug '18

UNOFFICIAL A number of DHCP linux workstation hosts in our environment were not updating DNS. Logs in SSSD showed that the Dynamic DNS child was failing with status 256. Further investigation into the logs (with debug turned up past 5) showed that the issue seems to be that SSSD is attempting to update both host and PTR DNS records on the Windows DNS servers for the loopback address (127.0.0.1). Dyndns Config in /etc/sssd/conf.d/<file>.conf is: [domain/example.com] Ad_hostname = host.fqdn Dyndns_update = true Dyndns_update_ptr = true Dyndns_ttl = 3600 Dyndns_iface = <adapter name> have the following in their hosts file: # /etc/hosts 127.0.0.1 localhost 127.0.0.1 host.fqdn host 198.168.x.x host.fqdn host Tested workstations are running SSSD 1.16.1 on Ubuntu 18.04.1 LTS. Removing the second 127.0.0.1 line and reloading SSSD resolved the issue. I understand that having 127.0.0.1 against the FQDN is unusual, but this "feature" is unfortunately required by a vendor product we are using. Is it possible for SSSD dyndns logic to be updated so that it ignores loopback IPs?

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users August 2018