sssd-users August 2019

sssd-users@lists.fedorahosted.org

25 participants
26 discussions

adcli behavior change with RHEL 7.7
by Erinn Looney-Triggs 13 Aug '19

13 Aug '19

Previously when using adcli to join a RHEL <7.7 system to the AD principles came out in this format: EXAMPLE$(a)AD.DOMAIN.COM Now when doing a join with adcli we are getting principles in this format: example$(a)AD.DOMAIN.COM Is this still a legal NETBIOS name? I mean I know it can work, it is just a string from kerbs perspective, but I was under the impression that the AD was pretty specific about what it expected the host principle to be. I am still digging into this, but so far this has broken some of our kerb code and it appears to have broken adcli update as well because it is looking for the uppercase principle while only the lower case principle is available in the keytab. Thanks, -Erinn

3 5

override_gid not applying to trusted/parent AD domains when joined via child
by Josh Snyder 08 Aug '19

08 Aug '19

Hi All, I'm working in a proof of concept for a customer where I've been asked to join the child domain of a Microsoft Active Directory domain, child.example.com. Users will primarily exist in the parent, example.com, but some users will also exist in the child. The application requires that all users have a specific primary GID, 1100, which is defined in /etc/group and I'm attempting to apply via override_gid. User authentication via either the child or parent is successful, however, the override_gid is only applied to users of the child, @child.example.com and NOT for users of the parent, @example.com. I saw what looked to be a similar post to this list from Sep 2018. It was suggested this may be a bug. I didn't see a follow-up/resolution to that thread. Is this issue being tracked or has it been resolved? Below is my sssd.conf: [root@linux2 sssd]# cat sssd.conf [sssd] domains = child.example.com config_file_version = 2 services = nss, pam default_domain_suffix = EXAMPLE.COM [domain/child.example.com] ad_domain = child.example.com krb5_realm = CHILD.EXAMPLE.COM realmd_tags = manages-system joined-with-samba cache_credentials = True id_provider = ad krb5_store_password_if_offline = True default_shell = /bin/bash ldap_id_mapping = True use_fully_qualified_names = True fallback_homedir = /home/%u@%d access_provider = ad ad_access_filter = FOREST:example.com: (memberOf:1.2.840.113556.1.4.1941:=CN=LinuxUsers,ou=Groups,dc=child,dc=example,dc=com) auth_provider = ad chpass_provider = ad ldap_schema = ad override_gid = 1100 CentOS Version: [root@linux2 sssd]# cat /etc/redhat-release CentOS Linux release 7.5.1804 (Core) SSSD Component Versions: [root@linux2 sssd]# rpm -qa |grep sssd sssd-common-pac-1.16.2-13.el7_6.8.x86_64 sssd-ldap-1.16.2-13.el7_6.8.x86_64 python-sssdconfig-1.16.2-13.el7_6.8.noarch sssd-client-1.16.2-13.el7_6.8.x86_64 sssd-krb5-common-1.16.2-13.el7_6.8.x86_64 sssd-ipa-1.16.2-13.el7_6.8.x86_64 sssd-krb5-1.16.2-13.el7_6.8.x86_64 sssd-dbus-1.16.2-13.el7_6.8.x86_64 sssd-proxy-1.16.2-13.el7_6.8.x86_64 sssd-tools-1.16.2-13.el7_6.8.x86_64 sssd-common-1.16.2-13.el7_6.8.x86_64 sssd-ad-1.16.2-13.el7_6.8.x86_64 sssd-1.16.2-13.el7_6.8.x86_64 Thanks, -Josh

3 3

[AD] User discovery/enumeration issue due to domain settings
by Christian Lamparter 06 Aug '19

06 Aug '19

Hello Folks, I'm currently setting up sssd (Debian 1.16.3) on Debian Buster 10.0 and I ran into a problem that I was able to trace down to the domain permission/security settings that placed the users into a special OU that machine accounts can't read. First a bit of background: Currently, there's a way to use winbind + friends in order to join and auth users on the domain. But due to limitations (unreliable no home directories, gid/uid mapping issues, etc.), I want to give sssd a try and I tested this with both of the current Debian sssd version 1.16.3 and 2.2.0-4 (from unstable / sid / rolling release). I successfully used the "realm" utility to discover and setup the sssd.conf === # realm discover -v DOMAIN (named changed) * Resolving: _ldap._tcp.domain * Performing LDAP DSE lookup on: 1x.y.z.1 * Performing LDAP DSE lookup on: 1z.a.b.c * Performing LDAP DSE lookup on: 1d.e.f.g * Successfully discovered: domain domain type: kerberos realm-name: DOMAIN domain-name: domain configured: no server-software: active-directory client-software: sssd required-package: sssd-tools required-package: sssd required-package: libnss-sss required-package: libpam-sss required-package: adcli required-package: samba-common-bin # realm join -v -U me@DOMAIN domain * Resolving: _ldap._tcp.domain * Performing LDAP DSE lookup on: 1x.y.z.1 * Performing LDAP DSE lookup on: 1z.a.b.c * Performing LDAP DSE lookup on: 1d.e.f.g * Successfully discovered: domain Password for me@DOMAIN: ******* * Unconditionally checking packages * Resolving required packages [...] * Generated 120 character computer password * Using keytab: FILE:/etc/krb5.keytab * Found computer account for COMPUTER * Set computer password * Retrieved kvno '14' for computer account in directory: ... * Modifying computer account: userAccountControl * Modifying computer account: operatingSystemVersion, operatingSystemServicePack * Modifying computer account: userPrincipalName * Cleared old entries from keytab: FILE:/etc/krb5.keytab * Discovered which keytab salt to use * Added the entries to the keytab: ... * /usr/sbin/update-rc.d sssd enable * /usr/sbin/service sssd restart * Successfully enrolled machine in realm === /etc/sssd/sssd.conf [sssd] domains = domain config_file_version = 2 services = nss, pam, ifp # added ifp [domain/domain] ad_domain = domain krb5_realm = DOMAIN realmd_tags = manages-system joined-with-adcli cache_credentials = True id_provider = ad krb5_store_password_if_offline = True default_shell = /bin/bash ldap_id_mapping = True use_fully_qualified_names = True fallback_homedir = /home/%u@%d access_provider = ad === klist shows a valid ticket and everything seemed to be working. But when I was trying to login (yes, I made sure that my time is synced and I made sure /etc/nssswitch.conf was correct) with my "me@domain" login it never worked. I tried also id me@domain and sssctl (had to add ifp, seems like realm doesn't add) but it wasn't working for my login. After trying a lot of different combinations with different id, auth_providers and ldap I discovered that the AD Server is setup in such a way (probably due to DSVGO) that the Domain-PC Accounts are not allowed to read from the OU where all the staff users are placed. And indeed, when I copied the exact search query from the sssd_domain log with debug-level 7 and instructed ldapsearch to use GSSAPI with the Domain-PC ticket I always got a "not found". However, when I used simple bind with "me@domain" + password auth I got the request worked. So, I wonder if it is possible to extend sssd in such a way that id lookups could be performed with the provided either a provided user secret instead of the machine secret? Regards, Christian

2 4

socket activated services and "implicit" sssd.conf?
by Andreas Hasenack 05 Aug '19

05 Aug '19

Hi there, I'm trying to update the sssd package in ubuntu to 2.2.0, and while the upstream tests pass, and our integration tests pass too, I get this warning (error?) with the socket services right after installation: (https://pastebin.ubuntu.com/p/ZzW8BG2fpm/) root@eoan-sssd2:~# systemctl status sssd-autofs.service ● sssd-autofs.service - SSSD AutoFS Service responder Loaded: loaded (/lib/systemd/system/sssd-autofs.service; indirect; vendor preset: enabled) Active: inactive (dead) Docs: man:sssd.conf(5) root@eoan-sssd2:~# systemctl status sssd-nss.socket ● sssd-nss.socket - SSSD NSS Service responder socket Loaded: loaded (/lib/systemd/system/sssd-nss.socket; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Thu 2019-08-01 12:49:07 UTC; 16min ago Docs: man:sssd.conf(5) Listen: /var/lib/sss/pipes/nss (Stream) Aug 01 12:49:07 eoan-sssd2 systemd[1]: Starting SSSD NSS Service responder socket. Aug 01 12:49:07 eoan-sssd2 sssd_check_socket_activated_responders[3012]: (Thu Aug 1 12:49:07:354960 2019) [sssd] [check_socket_activated_responder] (0x0020): ini_config_file_open() failed [2][No such file or directory] Aug 01 12:49:07 eoan-sssd2 sssd_check_socket_activated_responders[3012]: (Thu Aug 1 12:49:07:355071 2019) [sssd] [main] (0x0010): Misconfiguration found for the nss responder. Aug 01 12:49:07 eoan-sssd2 sssd_check_socket_activated_responders[3012]: The nss responder has been configured to be socket-activated but it's still mentioned in the services' line in /etc/sssd/sssd.conf. Aug 01 12:49:07 eoan-sssd2 sssd_check_socket_activated_responders[3012]: Please, consider either adjusting your services' line in /etc/sssd/sssd.conf or disabling the nss's socket by calling: Aug 01 12:49:07 eoan-sssd2 sssd_check_socket_activated_responders[3012]: "systemctl disable sssd-nss.socket" Aug 01 12:49:07 eoan-sssd2 systemd[1]: sssd-nss.socket: Control process exited, code=exited, status=2/INVALIDARGUMENT Aug 01 12:49:07 eoan-sssd2 systemd[1]: sssd-nss.socket: Failed with result 'exit-code'. Aug 01 12:49:07 eoan-sssd2 systemd[1]: Failed to listen on SSSD NSS Service responder socket. There is no /etc/sssd/sssd.conf file present, so I think it assumes some defaults. What are these? After install I get these services running: 1871 ? Ss 0:00 /usr/sbin/sssd -i --logger=files 1872 ? S 0:00 \_ /usr/libexec/sssd/sssd_be --domain implicit_files --uid 0 --gid 0 --logger=files 1873 ? S 0:00 \_ /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --logger=files So here is my assumption: there is an implicit sssd.conf configuration that is taken in since there is no actual sssd.conf file, and that just starts sssd_nss, and at the *same* *time* we are trying to use socket activation, which then says "why are you starting the socket listener, since you are already starting nss?" I'm guessing only debian-based systems see this, because we start the services right after installation, and don't have a default sssd.conf file shipped with the package.

3 3

Re: FAILED with error NT_STATUS_LOGON_FAILURE
by J. Dalton Humpf 02 Aug '19

02 Aug '19

I would like to know versions, exact configs, and list of all installed software or something I have been trying to fix this for months -- [image: Image may contain: Dalton Humpf, smiling, beard and closeup] *J. Dalton Humpf* / Director of Computer Science Laboratories JHumpf(a)hamilton.edu / (315)859-4452 *Hamilton College* https://cs.hamilton.edu 198 College Hill Road, Clinton, NY 13323

1 0

Re: Could not convert objectSID ... to a UNIX ID
by Gordon Messmer 01 Aug '19

01 Aug '19

On Tuesday, July 30, 2019 22:35 PDT, Sumit Bose <sbose(a)redhat.com> wrote: > > the version of SSSD you are using should automatically pick a new range > if the RID is too large. Can you send your sssd.conf for a start to > better understand your setup and see what might preventing SSSD from > picking a new range? The configuration file is generated by "realm join". Are there any specific patterns you'd like to see from the logs that might provide more information? [sssd] domains = business.com config_file_version = 2 services = nss, pam [domain/business.com] debug = 6 ad_domain = business.com krb5_realm = BUSINESS.COM realmd_tags = manages-system joined-with-samba cache_credentials = False id_provider = ad krb5_store_password_if_offline = True default_shell = /bin/bash ldap_id_mapping = True use_fully_qualified_names = False fallback_homedir = /home/business/%u access_provider = ad

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users August 2019