2

I'm trying to configure LDAP using GDM3 (3.28.0) in Ubuntu 18.04.

But i can just log in terminal with ldap users. In the GUI I can't log in (famous GDM loop login).

I configure pam to create the home folder: 

vim /etc/pam.d/common-session
session required     pam_mkhomedir.so       umask=077 skel=/etc/skel

But, it wasn't sufficient!

I installed lightdm, and in this GUI, I can login!

Any suggestion?

Thanks!

pid_wolf
  • 111
  • 1
  • 7

2 Answers2

9

I resolved the problem by installing the nscd service.

pid_wolf
  • 111
  • 1
  • 7
  • Do you understand why this fixes the problem? I've confirmed it fixed the same issue for me, but I still don't understand what was wrong. – spaceghost Jul 12 '18 at 08:50
  • I do not know why. In Ubuntu 16.04, I had the same problem with Adobe Reader. Without nscd, the application didn't start. When initiating occurred segmentation fault. – pid_wolf Jul 13 '18 at 12:13
  • a reboot is also necessary. Lightdm works out-of-the-box, but not GDM yet. Let's hope that Ubuntu will help to improve GDM within LDAP context – M-Jack Aug 01 '18 at 11:43
  • Your "fix" is perfect, the reason why it works is not clear to me too. The interesting part is that without nscd my system freezes and takes all TTYs with it, though the kernel at least still responds to MagicSysReqs like CTRL-ALT-PRINT-B. I can only assume Gnome wants to connect to nscd and never times out trying to do so .. – Daniel creo Haslinger Aug 30 '18 at 10:13
3

Sounds likely to be the same problem I had with NIS, where I couldn't log in for a day or so after booting. To get to the bottom of it, I had to:

  • strace -f gdm
  • find that its gdm-session-worker child is getting a FileNotFound error back from dbus-daemon
  • find with strace that dbus-daemon is just getting it from another UNIX domain socket
  • use sudo ss -anp to find that's from systemd-logind
  • strace -s1000 that to find that, just after it's looked at the yp binding file but before it's doing sendmsg with FileNotFound, it's getting:

socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = -1 EAFNOSUPPORT (Address family not supported by protocol)

... think "huh, how on earth can that be failing?" and try a Google for "logind nis". Apparently, it's not secure to look up user groups, or whatever logind is doing here, over the network, at least not without some separate locked-down daemon. You might think it would have been deemed important enough to deserve a sensible error message, but that could, I suppose, have been the fault of nscd or nss-nis or something else. From there, it was plain sailing to:

https://wiki.archlinux.org/index.php/NIS#Attention_on_Systemd_V235_since_10/2017_(and_V239_since_06/2018)

... thence to adapt their answer:

sudo mkdir /etc/systemd/system/systemd-logind.service.d/
sudo tee /etc/systemd/system/systemd-logind.service.d/open_network_interface.conf <<EOF
[Service]
RestrictAddressFamilies=AF_UNIX AF_NETLINK AF_INET AF_INET6
IPAddressAllow=any
EOF
sudo systemctl daemon-reload
sudo systemctl restart systemd-logind

The warning on that wiki about IPAddressAllow=any not overriding the default seems not to apply, for me, today, on Debian Buster. Simply doing a daemon-reload, you'd think, but no. nscd is listed as the solution there too, but we have that installed and I tried logging in on a different VT immediately before and staying logged in - no dice. Presumably it can sometimes work, after a day or whatever.

Martin Dorey
  • 2,944
  • 2
  • 24
  • 16