On to, 18 helmi 2021, Braden McGrath via FreeIPA-users wrote:
I have a 3-server (replicating) FreeIPA environment running on CentOS7. ipa --version shows: VERSION: 4.6.8, API_VERSION: 2.237 I have successfully "joined" two Ubuntu Server 20.04 LTS clients to the FreeIPA environment without issue. Let's call those Alpha and Beta. Alpha and Beta were installed using Ubuntu's freeipa packages; they show ipa --version: VERSION: 4.8.6, API_VERSION: 2.236Alpha and Beta work as expected, even though their client version is newer than the servers. I now have a 3rd Ubuntu Server 20.04 LTS VM ("Gamma") that I am trying to enroll/setup, and ipa-client-install returns success, but near the end of the install, 'getent' fails to pull info about the user account that was used during the install, and I can't login to this VM with an account from the FreeIPA database. I looked through the install log and didn't see anything obvious, but I've also only installed freeipa on 5 other systems at this point, so I don't really know what to look for. :) Key differences between Alpha/Beta and Gamma: Alpha/Beta are both VMs installed from a Ubuntu 20.04 LTS ISO; Gamma is an Ubuntu "cloud-image" VM (cloned from their image and then run through cloud-init for a hostname/etc) Alpha/Beta are using static IP addresses with manual DNS configuration; Gamma is using DHCP, but has a reservation (the IP won't change). DHCP is issuing the IPs of the 3 FreeIPA server VMs as DNS servers, and the DNS search domain is correct. Note that all 3 Ubuntu systems *are* still using Systemd-Resolve for DNS, which is then sending queries to the CentOS 7 Servers. Alpha and Beta are fine with this, so I don't think systemd-resolve is the problem. Any help would be greatly appreciated, because I'm not sure what to look at next (and I also don't understand why what should be a nearly identical install is not working). Rather than attaching the entirety of ipaclient-install.log, here is a github gist link with it. I've sanitized the domain, hostname, enroll username, and kerberos realm, but everything else has not been touched. https://gist.github.com/ZPrimed/1040499a744286690745a7d93bcd3d10
Check your /etc/nsswitch.conf, does it have 'sss' in 'passwd' and 'group' entries? I think Debian/Ubuntu platform code does not modify /etc/nsswitch.conf and expects that 'sss' is present. If I'd do 'apt-get install sssd' on Ubuntu 20.04, then an install script from one of installed packages modifies /etc/nsswitch.conf to include 'sss', this can be seen here: https://salsa.debian.org/sssd-team/sssd/-/blob/master/debian/libnss-sss.postinst Setting up libnss-sss:amd64 (2.2.3-3ubuntu0.3) ... First installation detected... Checking NSS setup... Adding an entry for automount. I'd guess your cloud image is incomplete and may be it didn't really run the post install scripts for many packages, not just libnss-sss. May be 'dpkg-reconfigure libnss-sss' would help? -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland _______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected] Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
