Bug 8459 - wbinfo -i GECOS field often does not contain any info
Summary: wbinfo -i GECOS field often does not contain any info
Status: RESOLVED DUPLICATE of bug 10440
Alias: None
Product: Samba 3.5
Classification: Unclassified
Component: Winbind (show other bugs)
Version: 3.5.11
Hardware: x86 Linux
: P5 normal
Target Milestone: ---
Assignee: Michael Adam
QA Contact: Samba QA Contact
Depends on:
Reported: 2011-09-15 10:17 UTC by Birger Wathne
Modified: 2015-03-12 11:19 UTC (History)
5 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Birger Wathne 2011-09-15 10:17:13 UTC
I have set up a Fedora 15 workstation with winbind against our domain(s).

Using wbinfo -i I sometimes see GECOS information and sometimes not. For some users I almost never get any info (as in I have yet to actually see any GECOS info from wbinfo -i, but once in a while the users have ther GECOS name in the Gnome login panel, so it must have happened...). For other users I seem to consistently get the info.

I have tried stopping winbindd, removing winbinddb_cache.tdb and restarting. Stopped nscd (configured to not cache users and groups) as well as sssd without any changes in behaviour. Same problems.

I see the problem both with users using the default domain (wbinfo -i user) and when querying a different domain (wbinfo -i 'DOMAIN\user')

Logging in with AD users works fine. the only problem is the inconsistent naming of users in the logon dialog.
Comment 1 Dustin C. Hatch 2012-10-04 15:49:45 UTC
I've noticed this problem as well. I have several machines running 3.5.6 (Debian Stable) and one running 3.5.15 (Gentoo stable), and all of them show no GECOS data for one particular user. On one machine, there is a second user without GECOS data, but it is there for that user on all other machines.

The interesting thing is that `wbinfo -i` does not show GECOS data, and neither does `getpwuid` from `pwd.h`, but `getent passwd` does.
Comment 2 Alex Cline 2013-02-15 15:22:19 UTC
I'm also seeing this problem on about a dozen machines running fully patched version of CentOS 6.3 and 5.9.

# wbinfo -V
Version 3.5.10-125.el6
# wbinfo -i cline
# wbinfo -i code-daemon
code-daemon:*:31426:30513:Code Daemon:/home/code-daemon:/bin/bash

# wbinfo -V
Version 3.6.6-0.129.el5
# wbinfo -i cline
# wbinfo -i code-daemon
code-daemon:*:31426:30513:Code Daemon:/home/code-daemon:/bin/bash

Only a handful of accounts don't show GECOS data, but those that don't don't have it on any system.  As far as I can tell there aren't any meaningful differences between accounts that do and do not show GECOS data.  The 'name' attribute is populated for all accounts in AD which I understand is supposed to populate the GECOS field.
Comment 3 Tim 2013-12-30 03:49:46 UTC
I'm seeing it too in 3.6.3 on Ubuntu 12.04.

And there's some differences with above: it happens only with logged in user. i.e. if user ever logged in before, and have a entry in the netsamlogon_cache.tdb, 'wbinfo -i' against the user always return empty.

To solve it temporarily:
  1. remove both netsamlogon_cache.tdb and winbindd_cache.tdb.
  2. restart winbindd
  3. 'wbinfo -i' against any user would return correct GECOS info

To reproduce the issue:
  1. after a PAM session login, thru ligthdm  or 'wbinfo --pam-logon=user%pass'
  2. wait for a while! (looks like not an instant impact, expiration?)
  3. 'wbinfo -i' against logged in user returns EMPTY GECOS field

I'm not quite sure the definition of netsamlogon_cache.tdb, and what service/functions are accessing/updating it. but if i emptied it, 'offline logon' would fail. 

attempted to look into source code, and find the comment of "try netsamlogon cache first" inside query_user. not quite sure the logic yet, reading more.
Comment 4 Tim 2013-12-30 09:51:25 UTC
Add an entry comparison from tdbdump (have replaced user id with 'samaccountname', and name)

before netsamlogon_cache.tdb is changed:
key(49) = "U/S-1-5-21-1085031214-1284227242-725345543-390888"                                             
data(133) = "\00\00\00\00\10@\96#\EE;\C1R\00\00\00\00\08samaccountname\08Luo, Tim\FF\FF\FF\FF\FF\FF/S-1-5-21-1085031214-1284227242-725345543-390888,S-1-5-21-1085031214-1284227242-725345543-513"                          

after logon lightdm or wbinfo --pam-logon:
key(49) = "U/S-1-5-21-1085031214-1284227242-725345543-390888"                                             
data(125) = "\00\00\00\00\8B^\96#%=\C1R\00\00\00\00\08samaccountname\FF\FF\FF\FF\FF\FF\FF/S-1-5-21-1085031214-1284227242-725345543-390888,S-1-5-21-1085031214-1284227242-725345543-513"

The GECOS field was somehow wiped out.
Comment 5 devurandom 2015-03-12 10:34:25 UTC
Has anyone found a fix for this, yet?

I see something similar on two machines:
Debian GNU/Linux 8.0 (jessie) with libnss-winbind_2:4.1.17+dfsg-1
Ubuntu 14.04.2 LTS with libnss-winbind_2:4.1.6+dfsg-1ubuntu2.14.04.7

Here the username is replicated in the gecos field.
Comment 6 Michael Adam 2015-03-12 10:45:47 UTC
Thanks for confirming with recent versions of samba.
I don't think it has been fixed.

Tim's analysis of comments #3 and #4 seems very good!
I would have guessed involvement of netsamlogon_cache, too.

We might want to look at the information that is available
at the various code paths that fill the netsamlogon-cache
and try to get them consistent, or merge in previously
existing  gecos field settings if current logon info does
not provide one.. Not sure yet.
Comment 7 Guenther Deschner 2015-03-12 11:06:13 UTC
Michael, this has been addressed in the meantime by using netlogon samlogon interactive.
Comment 8 Guenther Deschner 2015-03-12 11:07:32 UTC
https://bugzilla.samba.org/show_bug.cgi?id=10440 that is.
Comment 9 Michael Adam 2015-03-12 11:12:32 UTC
aha, thanks for the info, Günther, but it seems the patches have not made it into 4.1 (yet?). Since the patches are in master since a while, this means it should be fixed in 4.2.0.
Comment 10 Michael Adam 2015-03-12 11:13:21 UTC

*** This bug has been marked as a duplicate of bug 10440 ***
Comment 11 Michael Adam 2015-03-12 11:13:46 UTC
marking this a duplicate, because patches are on the newer bug..
Comment 12 Guenther Deschner 2015-03-12 11:19:49 UTC
Yes, that is correct. Recent RedHat releases ship samba 4.1.x releases with this (monstrous) backported patchset though.