Login prompt never presented with ldap login and ldapi set with a name.

[rsevero]

I have a ldap login configuration that has worked with several Ubuntu versions.

Unfortunately it doesn't work with 16.10.

If I left my ldapi setting using a name as I used to, the login prompt never appears. If I change the ldapi setting to the IP of the authentication server, the login works perfectly.

The authentication server name resolution works fine on 16.10 (after login) and on previous version even during login.

It seems to me my problem is related to some ordering issue.

ProblemType: Bug
DistroRelease: Ubuntu 16.10
Package: libpam-ldap 184-8.7ubuntu1
ProcVersionSignature: Ubuntu 4.8.0-44.47-generic 4.8.17
Uname: Linux 4.8.0-44-generic x86_64
ApportVersion: 2.20.3-0ubuntu8.2
Architecture: amd64
Date: Tue Mar 28 14:33:27 2017
InstallationDate: Installed on 2017-03-27 (1 days ago)
InstallationMedia: Xubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.2)
SourcePackage: libpam-ldap
UpgradeStatus: No upgrade log present (probably fresh install)

[Joshua Powers (powersj)]

Thank you for taking the time to file a bug report.

Would it be possible for you to give an example configuration to help us
reproduce this issue? Trying to get enough information to at least
reproduce this and then we can start to determine a fix.

Are there any logs as well that you could provide? syslog for example. It
does sound like dns resolution is not working as it has in the past, but
understanding the current ordering on boot and what is depending on what
would help assist us with this issue.

Since there is not enough information in your report to begin triage or to
differentiate between a local configuration problem and a bug in Ubuntu, I
am marking this bug as "Incomplete". We would be grateful if you would:
provide a more complete description of the problem, explain why you
believe this is a bug in Ubuntu rather than a problem specific to your
system, and then change the bug status back to "New".

For local configuration issues, you can find assistance here:
http://www.ubuntu.com/support/community

[rsevero (rodrigo-fabricadeideias)]

"Would it be possible for you to give an example configuration to help us
reproduce this issue?"

https://help.ubuntu.com/community/LDAPClientAuthentication

"Are there any logs as well that you could provide?"

Added as an attachement.

"understanding the current ordering on boot and what is depending on what
would help assist us with this issue."

I completely agree with you.

The best I could think was the photo of a halted boot.

Any other suggestions?

"provide a more complete description of the problem"

What details do you want? How can I get them?

"explain why you believe this is a bug in Ubuntu rather than a problem specific to your
system"

I believe this is a bug in Ubuntu 16.10 and not a problem on my specific system because I have been using this exact same configuration on 60+ Ubuntu stations since Ubuntu 14.04 at least without a glitch and now with 16.10 it suddenly stopped working.

[Nish Aravamudan (nacc)]

For what it's worth, the same version of libpam-ldap has been present in Ubuntu since (at least) 15.04. So I don't think the bug is in libpam-ldap.

When the login service fails, did you obtain the logs for it to see why it failed?

More than likely this is a systemd change, but it's unclear yet.

[Nish Aravamudan (nacc)]

Almost certainly the issue is that login.service is not waiting for networking before starting, when ldap is configured.

In the screenshot, I see "Failed to start Login Service" and then later "Started to raise network interfaces".

[Nish Aravamudan (nacc)]

Finally, is this reproducible with 17.04? Note that 16.10 goes eol in about 3 months so there is some non-zero cost to trying to fix it there, if it's already fixed in 16.10.

[Nish Aravamudan (nacc)]

If you are dropped to an emergency shell on failure to boot, does name resolution period work?

[rsevero (rodrigo-fabricadeideias)]

I also believe that this issue is related to systemd. I filed this issue on libpam-ldap because I don't know exactly which systemd service might be wrong and so don't know exactly what package exactly should be changed.

"When the login service fails, did you obtain the logs for it to see why it failed?"

On the previously attached log the boot starting at Mar 28 14:09:29 is a failed boot, i.e., one where the system halts during boot without ever presenting the login prompt.

I can't identify an exact reason for the failure. But I bet that it's related to the fact that the Login service starts together with the Network service making the Login service start without a functional Network connection as you said.

"Finally, is this reproducible with 17.04?"

I'm installing 17.04 in a test station right now. I will report when I finish the tests on it.

"If you are dropped to an emergency shell on failure to boot, does name resolution period work?"

I never managed to do that. I would like to try it. How could I do it?

[rsevero (rodrigo-fabricadeideias)]

I have just tested 17.04. The issue remains unchanged. It's not fixed.

[Nish Aravamudan (nacc)]

Thank you for the prompt testing. I'm marking a few potential src packages where the actual issue might lie.

[dino99 (9d9)]

This is an unsupported release now. Please think to install the next LTS 'Bionic 18.04'

http://cdimage.ubuntu.com/ubuntu-next/daily-live/current/
https://www.omgubuntu.co.uk/2018/02/ubuntu-18-04-minimal-install-option

[rsevero (rodrigo-fabricadeideias)]

Hummm, apparently Canonical is using the let's-wait-until-the-Ubuntu-version-mentioned-in-the-bug-report-gets-EOL-so-we-can-close-the-bug-without-fixing-anything" method for closing bug reports...

After confirming this bug for 2 current releases I give up. Let the bug remain and let's keep this bug report closed pretending someone at Canonical would give a damn if it were reported for a current release.

Thanks for your time, attention and help.

[Gunnar Hjalmarsson (gunnarhj)]

Re-opening. This issue is apparently not version specific.

[Andreas Hasenack (ahasenack)]

I'm taking a look.

[Andreas Hasenack (ahasenack)]

ldapi:/// is a unix socket connection, it shouldn't have a "name" or IP component. It can optionally take a path component, but usually should just be left blank.

Could you please attach your /etc/ldap.conf and /etc/ldap/ldap.conf?

Is your ldap server on localhost, or remote on another machine (in which case ldapi:/// makes no sense).

In the meantime I'll start with two scenarios:
a) ldapi and slapd server on localhost
b) ldap and slapd server on another machine

I'm going to use 17.10, since 17.04 and 16.10 are end of life and I'm having difficulties with creating a VM for them with MAAS (which is my test environment).

[Andreas Hasenack (ahasenack)]

The ldapi:/// worked just fine, as did ldap:// with an IP or a name. And I don't have an entry in /etc/hosts for the ldap server, I'm really using DNS. Reboot works just fine, login prompt, and I can login at the console (and via ssh) with an ldap user.

I'm sorry but I will need the files I requested in comment #16.

Here are mine:

ubuntu@04-57:~$ cat /etc/ldap.conf | grep -vE "^(#|$)"
base dc=example,dc=com
uri ldap://xenial-slapd-server.lxd
ldap_version 3
pam_password exop

ubuntu@04-57:~$ cat /etc/ldap/ldap.conf | grep -vE "^(#|$)"
URI ldap://xenial-slapd.server.lxd
BASE dc=example,dc=com
TLS_CACERT /etc/ssl/certs/ca-certificates.crt

I used these ldif files to minimally populate the ldap server:

ubuntu@04-57:~$ cat base.ldif usergroup.ldif
dn: ou=People,dc=example,dc=com
ou: People
objectClass: organizationalUnit

dn: ou=Group,dc=example,dc=com
ou: Group
objectClass: organizationalUnit
dn: uid=testuser1,ou=People,dc=example,dc=com
uid: testuser1
objectClass: inetOrgPerson
objectClass: posixAccount
cn: testuser1
sn: testuser1
givenName: testuser1
mail: <email address hidden>
userPassword: testuser1secret
uidNumber: 10001
gidNumber: 10001
loginShell: /bin/bash
homeDirectory: /home/testuser1

dn: cn=testuser1,ou=Group,dc=example,dc=com
cn: testuser1
objectClass: posixGroup
gidNumber: 10001
memberUid: testuser1

dn: cn=ldapusers,ou=Group,dc=example,dc=com
cn: ldapusers
objectClass: posixGroup
gidNumber: 10100
memberUid: testuser1

[Andreas Hasenack (ahasenack)]

I'll try to get 17.04 up somewhere and test that as well.

[Dan Streetman (ddstreet)]

please reopen if this is still an issue