[Samba] Expiry of entries in netsamlogon_cache.tdb

[Orlando Richards]

On 11/06/14 21:21, Volker Lendecke wrote:

Hi Volker,

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:
>>    https://bugzilla.samba.org/show_bug.cgi?id=8641
>> 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 
minimal.




-- 
             --
    Dr Orlando Richards
   Information Services
IT Infrastructure Division
        Unix Section
     Tel: 0131 650 4994
   skype: orlando.richards

The University of Edinburgh is a charitable body, registered in 
Scotland, with registration number SC005336.