5

If I execute

sudo getent shadow

I see password hashes for all the local users who have them. For most of the LDAP accounts I only see * in the password field. However, for a few LDAP users, I see password hashes. I have verified that they don't have local accounts (i.e. no entry in /etc/passwd but getent passwd username returns a line).

In fact, logged in as myself, my user entry is one of the ones with an *.

There is a single LDAP server running OpenLDAP with a single group of accounts (one branch in the tree).

The LDAP-client servers are running nscd and libnss-ldap.

This is a portion of /etc/nsswitch.conf on the LDAP-client servers:

passwd:         files ldap
group:          files ldap
shadow:         files ldap

LDAP is used to authenticate the user for login to the LDAP-client server in this case and at some point the authentication mechanism, PAM in this case, must check a hash of the password provided by the user at login against the stored hash which is contained in the LDAP database.

Each user's LDAP account stores their password hash and has the objectClasses of posixAccount and shadowAccount (among other values and settings).

Only system accounts have local entries in /etc/password and /etc/shadow. User accounts are all on LDAP (and only there). All users in LDAP have userPassword entries.

What might cause this or how can I run down the cause of it? Why doesn't getent shadow return password hashes for all LDAP users?

Dennis Williamson
  • 6,620
  • 1
  • 34
  • 38
  • 2
    Wouldn't that depend on what's happening on the LDAP server? – Gilles 'SO- stop being evil' Dec 12 '16 at 23:35
  • 1
    @gilles: Of course, but that's kind of a vague question. Presume that all the LDAP users can successfully log into the server that the `getent` command is run from. – Dennis Williamson Dec 12 '16 at 23:38
  • Uh, I may be missing something because I'm not familiar with LDAP. What does the user being able to log in have to do with the LDAP server exposing a password hash? – Gilles 'SO- stop being evil' Dec 12 '16 at 23:43
  • @Gilles: LDAP is used to authenticate the user for login in this case and at some point the authentication mechanism, PAM in this case, must check a hash of the password provided by the user at login against the stored hash which is contained in the LDAP database. – Dennis Williamson Dec 12 '16 at 23:54
  • Is it related to the LDAP users who have authenticated to this server (i.e. have these password hashes been cached locally, and that's what `getent shadow` is seeing)? – roaima Dec 12 '16 at 23:57
  • @DennisWilliamson Yes, but that doesn't mean that the server should send the hash to the client. Nor that the client should send the password to the server, for that matter. Ideally the client sends a proof of possession of the password to the server. [LDAP supports all three methods](http://tldp.org/HOWTO/LDAP-HOWTO/authentication.html); I don't know how it's typically configured or how the configuration is set. – Gilles 'SO- stop being evil' Dec 12 '16 at 23:57
  • @thrig: The results are as expected and identical for each type (`getent` result as described in the question) of user. – Dennis Williamson Dec 12 '16 at 23:57
  • @Gilles: But I expect all the users in this case to be authenticated using the same method, regardless of which it is. I believe the article you linked is referring to authenticating to the LDAP server in order to determine how much access is granted to retrieve information that is stored there, rather than using the LDAP server as a database storing authentication information for accessing a Linux server (as an alternati\ve to `/etc/shadow`). – Dennis Williamson Dec 13 '16 at 00:03
  • @thrig: In particular, each user's LDAP account stores their password hash and has the objectClasses of posixAccount and shadowAccount (among other values and settings). – Dennis Williamson Dec 13 '16 at 00:05
  • You expect... but the point of this question would be to verify this expectation. Could there be different user pools? different LDAP servers? – Gilles 'SO- stop being evil' Dec 13 '16 at 00:08
  • @Gilles: No, I administer the system and there is only one of each. – Dennis Williamson Dec 13 '16 at 00:10
  • Hmm, so probably not an ACL issue. Were systems moved into LDAP support (thus no passwords in LDAP for those users) or has LDAP been there from the get-go? – thrig Dec 13 '16 at 00:49
  • @thrig Only system accounts have local entries in `/etc/password` and `/etc/shadow`. User accounts are all on LDAP (and only there). All users in LDAP have `userPassword` entries. Otherwise I'm not sure what you're asking. – Dennis Williamson Dec 13 '16 at 01:00
  • I believe that @roaima’s speculation is right — when a user logs in with an LDAP account, the local system caches the password hash. Have you tried (1) doing `sudo getentshadow`, (2) logging in (locally) with one of the users who has a `*` in the passwd field, and then (3) doing `sudo getentshadow` again? – G-Man Says 'Reinstate Monica' Dec 13 '16 at 07:07
  • What caching subsystem, if any, are you using to connect to the LDAP server? for example, I use `sssd` to communicate with Windows Active Directory. – roaima Dec 13 '16 at 10:17
  • @G-Man: Yes, I happen to be one that has a `*` in my password hash field. – Dennis Williamson Dec 13 '16 at 16:40
  • 1
    @roaima: I;m using `nscd` and `libnss-ldap`. The LDAP server is OpenLDAP. – Dennis Williamson Dec 13 '16 at 16:48
  • Wait, what?  You’re saying that, even after you login locally with your LDAP account, *your account* is listed with an `*` in the password field?  That would seem (?) to rule out caching as a factor.  I suggest that you [edit] your question to include that information.  In fact, all of this supplementary information that you’ve been posting as comments should be edited into the question. – G-Man Says 'Reinstate Monica' Dec 13 '16 at 20:41
  • @G-Man: I added information from comments to my question. – Dennis Williamson Dec 13 '16 at 22:24

0 Answers0