SSSD cache security
by q8ztvkkd＠posteo.de
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.
5 years, 8 months
Re: sssd 1.9.6
by Lukas Slebodnik
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/e....
>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
5 years, 8 months
id: cannot find name for group ID
by Mario Rossi
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-larg...
#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 #####
5 years, 8 months
sssd connecting to two AD domains
by Ondrej Valousek
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.
5 years, 8 months
login attributes not being updated
by Galen Johnson
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=
5 years, 8 months
SSSD attempts Dyndns updates for loopback address [SEC=UNOFFICIAL]
by Kosseck, Adam MR
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?
5 years, 8 months
