[Samba] Expiry of entries in netsamlogon_cache.tdb
orlando.richards at ed.ac.uk
Thu Jun 12 08:14:32 MDT 2014
On 11/06/14 21:21, Volker Lendecke wrote:
Thanks for the response.
> On Wed, Jun 11, 2014 at 10:38:01AM +0100, orlando.richards at ed.ac.uk wrote:
>> I think we're suffering from bug 8641 at the moment:
>> where the netsamlogon_cache.tdb entries are not expiring.
>> We use AD groups for our (redhat) server auth, and also use
>> server-side group auth for NFS (with the --manage-gids flag). So if
>> a user is not in a group on the server, they're denied access to
>> files as per group permissions. However, winbind is using
>> netsamlogon_cache.tdb to cache group memberships for a SID - and
>> this does not seem to get refreshed when users are accessing via
>> NFS. I'm not clear on under what circumstances it *is* refreshed -
>> but I guess that access via NFS is not one of them.
> You're right, we never delete stuff from the
> netsamlogon_cache.tdb. We only update it with fresh
> information, once we get hold of it via a successful login
> of an AD-authenticated user. wbinfo -a and a kerberized SMB
> login will do it.
Hmm - it *seems* to work okay for me to just issue an "id johndoe"
command, and the correct user and group information is presented back at
me - even if johndoe has never before been seen on my Linux/Samba
server. This is querying the MS Active Directory.
>> To work around the issue, I can edit the netsamlogon_cache.tdb
>> manually with tdbtool, delete the entry for the user's SID, and it
>> now refreshes. Obviously this is not optimal though!
> The problem here is -- this refresh is unreliable at best.
> In most trusted domain scenarios it does not work at all.
> That's the reason why we never expire the netsamlogon_cache:
> There is no way for us to refresh that information in any
> other way than via a successful login by an AD user. Yes, in
> some scenarios it does work, but in just as many scenarios
> it will fail in subtle ways.
What kind of failures would I see? As above - it *seems* to be working
okay, but I may just be blind to the errors! I guess my fix of removing
entries from the tdb (a more precise version of just deleting the tdb
and restarting winbind - but the same presumably applies there) does
rely on it being able to be repopulated afterwards (as prompted by my
"id johndoe" example above). Similarly, the initial population from a
clean install would be the same - unless a user actually authenticates
directly against the server, should their group information be
considered tainted? If so - in what ways?
> The only way to make this reliable is to kerberize the NFS
> service and make the NFS clients member of AD, retrieving
> tickets including a PAC. There are patches around somewhere
> that do this for Ganesha. I haven't looked at the kernel NFS
> services at all yet.
>> Is there a way of forcing an expiry on netsamlogon_cache.tdb cache
>> entries, or flushing the database? More usefully - is there a
>> setting somewhere which will set automatic expiry of entries as per
>> the winbind/idmap cache timeouts?
> Well, tdbtool is certainly the interim tool. We could
> provide a special net tool with some syntactic sugar, but
> that would not do much else. I'm a bit reluctant to expire
> this automatically, and if, then with a really long timeout
> such as a month or so.
I guess, other than pruning dead wood, there wouldn't be much advantage
in doing that (from the point of view of my problem). If someone is
added to or removed from a group, they'll want to see that take effect
"soon". The difference between "a month later" and "never" is probably
Dr Orlando Richards
IT Infrastructure Division
Tel: 0131 650 4994
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
More information about the samba