samba - Oct 2016 - winbindd losing track of RFC2307 UIDs

On Wed, 5 Oct 2016 16:12:41 -0400 (EDT)
Rob via samba <samba at lists.samba.org> wrote:
> On Tue, 4 Oct 2016, Rowland Penny wrote:
> 
> > This is very strange, have you tried running 'net cache flush'
on
> > the domain member ?
> >
> > Have you compared the users AD objects ?
> 
> Running 'net cache flush' on the member does fix things, albeit
only
> for a while:
> 
> # wbinfo -i auser
> auser:*:2020:10000:User Name:/home/auser:/bin/bash
> # net cache flush
> # wbinfo -i auser
> auser:*:10028:10000:User Name:/home/auser:/bin/bash
> [...wait a few hours...]
> # wbinfo -i auser
> auser:*:2020:10000:User Name:/home/auser:/bin/bash
> 
> Using ldbsearch on sam.ldb on the DC, I compared the attributes of 
> problematic users and normal users... I couldn't find anything 
> obvious distinguishing them.
> 
> Also, on the member:
> 
> # net idmap dump
> dumping id mapping from /usr/local/samba/var/locks/winbindd_idmap.tdb
> [...]
> UID 2020 S-1-5-21-2701825980-1665447529-2160704981-1177
> 
> (where S-*-1177 is the SID for auser)
> 
> But I'd think winbindd would prefer the mapping in AD, given smb.conf 
> having our domain listed explicitly and 2xxx only as a
> default/fallback. Or maybe I misunderstand how the idmaps work...
> does the order in smb.conf matter at all?
> 
> _Rob
> 
> 
OK, this is basically how the winbind 'ad' works:

Domain Users is checked for a gidNumber attribute and if found
winbind continues, if not found, the '*' range will be used.

Once pass this point, any user that has a uidNumber attribute that
contains a number inside the 'idmap config DOMAIN' range will be
displayed by 'getent passwd username'

once a user is displayed in this way, it should always be displayed in
this way, it shouldn't get an ID from the '*' range.

Could the '...wait a few hours...' be about 10 hours ??

Try adding these lines to smb.conf:

    dedicated keytab file = /etc/krb5.keytab
    kerberos method = secrets and keytab
    winbind refresh tickets = Yes

Leave the domain and rejoin, this should create the /etc/krb5.keytab 

Rowland

I'm having the same "problem" with my member/fileserver.

I leave and join domain, and when i re-join, the system aways ask me 2
times for the administrator password... can this be a problem?

root at fs2:~# net join ads -Uadministrator

Enter administrator's password:

Failed to join domain: failed to find DC for domain ads

ADS join did not work, falling back to RPC...

Enter administrator's password:

Using short domain name -- DOMAIN

Joined 'FS2' to realm 'domain.local'




2016-10-05 17:36 GMT-03:00 Rowland Penny via samba <samba at
lists.samba.org>:
> On Wed, 5 Oct 2016 16:12:41 -0400 (EDT)
> Rob via samba <samba at lists.samba.org> wrote:
>
> > On Tue, 4 Oct 2016, Rowland Penny wrote:
> >
> > > This is very strange, have you tried running 'net cache
flush' on
> > > the domain member ?
> > >
> > > Have you compared the users AD objects ?
> >
> > Running 'net cache flush' on the member does fix things,
albeit only
> > for a while:
> >
> > # wbinfo -i auser
> > auser:*:2020:10000:User Name:/home/auser:/bin/bash
> > # net cache flush
> > # wbinfo -i auser
> > auser:*:10028:10000:User Name:/home/auser:/bin/bash
> > [...wait a few hours...]
> > # wbinfo -i auser
> > auser:*:2020:10000:User Name:/home/auser:/bin/bash
> >
> > Using ldbsearch on sam.ldb on the DC, I compared the attributes of
> > problematic users and normal users... I couldn't find anything
> > obvious distinguishing them.
> >
> > Also, on the member:
> >
> > # net idmap dump
> > dumping id mapping from /usr/local/samba/var/locks/winbindd_idmap.tdb
> > [...]
> > UID 2020 S-1-5-21-2701825980-1665447529-2160704981-1177
> >
> > (where S-*-1177 is the SID for auser)
> >
> > But I'd think winbindd would prefer the mapping in AD, given
smb.conf
> > having our domain listed explicitly and 2xxx only as a
> > default/fallback. Or maybe I misunderstand how the idmaps work...
> > does the order in smb.conf matter at all?
> >
> > _Rob
> >
> >
>
> OK, this is basically how the winbind 'ad' works:
>
> Domain Users is checked for a gidNumber attribute and if found
> winbind continues, if not found, the '*' range will be used.
>
> Once pass this point, any user that has a uidNumber attribute that
> contains a number inside the 'idmap config DOMAIN' range will be
> displayed by 'getent passwd username'
>
> once a user is displayed in this way, it should always be displayed in
> this way, it shouldn't get an ID from the '*' range.
>
> Could the '...wait a few hours...' be about 10 hours ??
>
> Try adding these lines to smb.conf:
>
>     dedicated keytab file = /etc/krb5.keytab
>     kerberos method = secrets and keytab
>     winbind refresh tickets = Yes
>
> Leave the domain and rejoin, this should create the /etc/krb5.keytab
>
> Rowland
>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba
>


-- 

-------------------------------------------
Edson Tadeu Almeida Silveira
http://sites.google.com/site/edsontadeu/
-------------------------------------------

On Wed, 5 Oct 2016, Rowland Penny wrote:
> Could the '...wait a few hours...' be about 10 hours ??
I'll let you know... in about 10 hours!
> Try adding these lines to smb.conf:
>
>    dedicated keytab file = /etc/krb5.keytab
>    kerberos method = secrets and keytab
>    winbind refresh tickets = Yes
>
> Leave the domain and rejoin, this should create the /etc/krb5.keytab
Will try that the next time the system is idle.

Thanks,
-Rob

On Thu, 6 Oct 2016, Rob wrote:
> On Wed, 5 Oct 2016, Rowland Penny wrote:
>
>> Could the '...wait a few hours...' be about 10 hours ??
>
> I'll let you know... in about 10 hours!
Turns out it's far less than 10 hours in some cases.  In fact, I've been
able to more-or-less reproduce it on demand!

The member server in question provides SMB file service as well as SSH 
login.  If a particular user logs in via SSH (using a keypair rather than 
password, if that matters) and does some SVN operations, then logs out and 
does some file system operations (not explicitly on the SMB shares, but 
Wireshark shows Windows is making queries on them anyway), the UID resets 
to 2xxx within a few seconds.

Other users (17 of 20) don't have this problem and subsequent lookups or 
SSH sessions for other users work fine (so it's not that winbindd has 
somehow lost contact with the DC).

I recognize I need to isolate exactly what parts of this scenario cause 
the problem... will report back.  Meanwhile, I have a 15,000 line -d10 log 
file from winbindd while this happens, but it's interspersed with 
unrelated lookup traffic.  I'll try to make a more compact log.  Is there 
anything specific I should look for in the log?
>> Try adding these lines to smb.conf:
>>
>>    dedicated keytab file = /etc/krb5.keytab
>>    kerberos method = secrets and keytab
>>    winbind refresh tickets = Yes
>> 
>> Leave the domain and rejoin, this should create the /etc/krb5.keytab
It turns out smb.conf already has both "kerberos method = secrets and 
keytab" and "winbind refresh tickets = yes", but not the
"dedicated keytab
file" line.  (The system does have an /etc/krb5.keytab that appears to 
have been created when it joined the domain.)

Still, I can try re-joining the domain if that may help.

_Rob