0

A user on our Opensuse 12.1 server was trying to mount an NFS directory and came to me saying that he had no username. His user configuration is identical to every other user on the system, so I suspected that LDAP was failing entirely, but it turns out to not be the case. He can, in fact, log in as his LDAP user on other systems and they successfully detect his name (i.e. whoami does not fail). Running whoami on every user on the server returns (non-truncated output):

$ for i in $(ldapsearch -LLL -x -H ldap://localhost uid | grep "^uid" | cut -d' ' -f 2); do [[ $(su $i -c whoami) == "$i" ]] || echo $i; done
whoami: cannot find name for user ID 1497
hisusername

Likewise, if I run groups on him on the LDAP server:

$ groups hisusername
hisusername : users faculty
$ su hisusername
[hisusername@server root]$ groups
users groups: cannot find name for group ID 1000
1000

This completely baffles me. I restarted slapd as well, and that unfortunately didn't fix anything.

The server is running sssd for name caching, but the problem persists after

systemctl stop sssd
rm -rf /var/lib/sss/db/**
systemctl restart sssd

Meaning that name caching is probably(?) not the issue

LDAP entries for working user account:

# hisusername-temp, people, linuxlab.<domain>.<tld>
dn: uid=hisusername-temp,ou=people,dc=linuxlab,dc=<domain>,dc=<tld>
cn: hisusername-temp
gidNumber: 100
homeDirectory: /home/hisusername-temp
loginShell: /usr/local/bin/redirsh
objectClass: top
objectClass: posixAccount
objectClass: inetOrgPerson
sn: hisusername-temp
uid: hisusername-temp
uidNumber: 1540

The faulty account: 

# hisusername, people, linuxlab.<domain>.<tld>
dn: uid=hisusername,ou=people,dc=linuxlab,dc=<domain>,dc=<tld>
cn: His Name
gidNumber: 100
homeDirectory: /home/hisusername
loginShell: /usr/local/bin/redirsh
objectClass: top
objectClass: posixAccount
objectClass: inetOrgPerson
sn: hisusername
uid: hisusername
uidNumber: 1497
Richard Quackenbush
  • 11
  • 7
  • Perhaps the failing server has some name caching daemon like `nscd` or `sssd` running, which for some reason now needs to be restarted and/or cache files pruned? – Janne Pikkarainen May 02 '18 at 16:57
  • @JannePikkarainen sssd is running, updated the post – Richard Quackenbush May 02 '18 at 17:07
  • What is the ldap branch where are you storing users? have you take a look inside it? – Daniel PC May 03 '18 at 08:12
  • @DanielPC I'm not sure what you mean by that, since I'm not super comfortable with LDAP. The entries were all autogenerated by YaST2, and they are apparently rfc2307bis complaint according to the ldap.conf-client file. I updated the post with the user account. Additionally, the faulty account is a member of all of the correct groups. – Richard Quackenbush May 03 '18 at 13:38
  • @RichardQuackenbush if these groups are created on ldap, your server is not able to translate them locally. Try create them : If you have root privileges add the group into /etc/group and try again. – Daniel PC May 03 '18 at 14:39
  • @DanielPC That's definitely not the issue. The groups of the affected user are the same as the groups of some others I just tested (users built from the same script with the same setting over a long period of time). Likewise, this entire configuration is multiple years old, and only recently this user entry has had this issue despite the user account being created several months ago. The groups are not in /etc/group since (I assume) sssd is handling it, and the affected user account works fine over NFS mounted home directory on one of our client workstations. – Richard Quackenbush May 03 '18 at 16:48

0 Answers0