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?
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
CentOS 5 is not supported for more than a year
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.
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 
(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 (Authentication Failed)
I am wondering why is SSSD trying now, all of sudden, to obtain a TGT using wrong principal?
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.
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.
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:
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:
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?