samba - Jan 2019 - Users created in last few years cannot login after 4.7 -> 4.8 + winbind

It appears there is still misunderstanding about my situation/setup. Sorry, I 
know this is strange.

I have an LDAP server for my Linux infrastructure that is totally seperate
from the corporate AD Windows domain.  At one point my LDAP did have
the samba schema installed with my its own SID's and smbpasswd's in it.
My web app for users to change their Linux password would on the backend
set their 'userPassword' and 'sambaNTPassword' via separate
calls
to keep them in sync.

But when the edict to do single sign on to the coporate AD happened I stopped 
using any of the samba schema in my LDAP server.  And I set each user's 
'userPassword' field to something like '{SASL}per2' to use
passthru on the
LDAP authentication end.  And I configured samba to use corporate AD
with the username map

Corporate is definitely NOT going to let me copy 'sambaNTPassword' from
them
or let me setup my own domain to trust.  The later would probably not
work anyway due to the mismatch with names/uids.

So with 4.7.x using the 'username map' with 'domain = ads' was
working
just fine with me.

The random nature of this is what is most confusing.  Mounting always
works for old account 'per2'.  But I can have mounting work for one
the new accounts, simply doing a 'systemctl restart smb' and then
mounting
does not work for the new account or unmounting, waiting 10 minutes changing
nothing and then trying to mount again.

In addition I think I run into the secondary group problem referenced in the 
thread I mentioned a few months ago.  The share I was setting was using
"valid
users = +sysadm" and per2, aea32 and nmr27 are all in that group (but not 
their primary group).

With

[posters]
     path = /home/posters
     valid users = +sysadm
     writable = yes
     create mask = 664
     force create mode = 664
     directory mask = 2775
     force directory mode = 2775

And the permissions on /home/posters being

drwxrws--- 5 root sysadm 4096 Jan  7 11:13 /webdata/posters

only user 'per2' can mount the share ('per2' can also write)

When I changed it to

     path = /home/posters
     valid users = aea32 nmr27 +sysadm

and made the directory world readable I was then sometimes able
to mount this share as aea32 and nmr27, sometimes not. When I
could I could not write to the directory till I made it owned
by the user who mounted.


I have been using

        idmap config *:backend = tdb
        idmap config *:range = 100-999
        idmap config PARTNERS:backend = ad
        idmap config PARTNERS:schema_mode = rfc2307
        idmap config PARTNERS:range = 1000-9999999
        idmap config PARTNERS:unix_primary_group = yes

so all 3 accounts are covered in the 1000-9999999 range.

Failure will have a message like:

   winbindd case, sid_to_uid for S-1-5-21-8915387-943144406-1916815836-949594 
failed

which is the SID of in the corporate AD of the user I was trying.

[root:/var/log/samba]# wbinfo 
--sid-to-name=S-1-5-21-8915387-943144406-1916815836-949594
PARTNERS\nmr27 1

The above wbinfo always seems to work, so I don't know why it randomly
fails with the sid_to_uid error on mount requests


On Fri, 4 Jan 2019 4:20pm, Rowland Penny wrote:
> On Fri, 4 Jan 2019 15:14:06 -0500 (EST)
> Paul Raines <raines at nmr.mgh.harvard.edu> wrote:
>
>> On Fri, 4 Jan 2019 4:57am, Rowland Penny wrote:
>>
>>> On Thu, 3 Jan 2019 17:46:51 -0500 (EST)
>>> Paul Raines via samba <samba at lists.samba.org> wrote:
>>>
>>>> TLDR: after upgrading our CentOS 7.5 servers using Samba 4.7.x
with
>>>> security = ads and no winbind to CentOS 7.6 with Samba 4.8.x
with
>>>> security = ads + winbind all users accounts created in the last
few
>>>> years can no longer login.
>>>>
>>>> Explaining this requires a fairly long back story
>>>>
>>>> Our corporate is primarily a Windows shop while our own
research
>>>> department primarly uses Linux.  For over a decade we used our
own
>>>> account/group/file namespace in our Linux infrastructure
totally
>>>> separate from corporate.
>>>>
>>>> A couple years ago for new security hardening purposes
corporate
>>>> has dictated all logins need to be based off their AD server so
>>>> they can manage/monitor/enforce password changes, access, etc.
>>>
>>> So go back to them, point out it isn't working and they need to
>>> extend AD by adding the IDMU ldif and create your users and groups
>>> in AD with the correct ID's ;-)
>>
>> This is not an option for me.  Corporate is not going to change
>> anything on AD for me.  And this would create the opposite problem
>> were my users with resources on the corporate instrastructure will
>> have things break if the IDs are changed.
>>
>>>
>>>>
>>>> The issue was we had petabytes of data using our accounts which
had
>>>> in most cases both different names and underlying user ids. For
>>>> example, my Linux username is raines with ID 5829
>>>
>>> I take it this ID is the Unix users ID found in /etc/passwd
>>>
>>
>> My LDAP server, but yes
>
> This is the first mention of LDAP
>>
>>>> and my corparte/AD username is per2 with ID 2040470.
>>>
>>> And this is the users AD RID
>>
>> uidNumber you get when searching account on AD via LDAP
>
> So, your users are stored in LDAP, I take it from 'uidNumber' that
the
> samba schema is installed.
>
>>
>>>
>>>>  And groups have no relation
>>>> whatsoever. Simply reconfiguring our Linux servers to do
straight
>>>> LDAP or winbind/nss to corporate AD was not possible without a
>>>> wholesale painful re-ID-ing of files and breakage of lots of
apps
>>>> that hard code usernames in settings.
>>>
>>> It wouldn't have been a problem if AD had been extended
properly.
>>>
>>
>> I really don't see how that was realistically possible.  ANd I am
>> positive the managers would not allow the UIDs in the range
>> 5000-10000 I had use for my users.  I have a handful of users from
>> the early 2000s with UIDs in the 100-5000 range (predates me -- this
>> is before distros started enforcing user creation >500). It most
>> likely conflicts with system accounts they had created.
>>
>>>> raines = MYDOMAIN\per2
>>>> aea32 = MYDOMAIN\aea32
>>>
>>> That's one way of doing it, it isn't how I would have done
it.
>>>
>>
>> Except for "extending AD" as above is there another way.
>>
>> All I want and need from corporate AD is password authentication.  I
>> don't want or need anything else, including user or group ids. I
>> want Samba to get everything else (user id, group ids, shell,
>> homedir, ...) from the local NIS backend (i.e. my LDAP server)
>
> Basically extending AD with IDMU means that NIS is put into AD.
>
>>
>>>>
>>>> and then have in smb.conf
>>>>
>>>>  	workgroup = MYDOMAIN
>>>>          security = ads
>>>>          passdb backend = tdbsam
>>>>          realm = MYDOMAIN.ORG
>>>>
>>>>          dedicated keytab file = /etc/krb5.keytab
>>>>          kerberos method = secrets and keytab
>>>>          preferred master = no
>>>>          encrypt passwords = yes
>>>>
>>>>          socket options = TCP_NODELAY IPTOS_LOWDELAY
>>>> SO_RCVBUF=65536 SO_SNDBUF=65536 SO_KEEPALIVE
>>>>
>>>>          idmap config *:backend = tdb
>>>>          idmap config *:range = 100-999999
>>>
>>> That is a foolish range, it interferes with the local system users.
>>> The '*' domain is for the Well Known Sids and anything
outside the
>>> 'MYDOMAIN' domain.
>>
>> Again, I am not using WINBIND for actual NIS in the system.  It
>> will not be in /etc/nsswitch.conf, pam, etc.  I never used it before
>> in Samba 4.7.x or before.  I am only running it because it is now
>> required to use security=ads for authentication.  I DO want any
>> login on the samba server of any system account to always fail.
>>
>>>
>>>>          idmap config MYDOMAIN:backend = ad
>>>>          idmap config MYDOMAIN:schema_mode = rfc2307
>>>>          idmap config MYDOMAIN:range = 1000000-9999999
>>>
>>> Sorry, but this is wrong for your Samba version, see here:
>>>
>>>
https://wiki.samba.org/index.php/Setting_up_Samba_as_a_Domain_Member
>>>
>>> and here:
>>>
>>> https://wiki.samba.org/index.php/Idmap_config_ad
>>>
>>> The range must reflect the uidNumber & gidNumber attributes in
AD.
>>>
>>
>> I have tried using the nss backend and the results are random.
>> Sometimes it works.  Sometimes it doesn't.  It still always works
>> for my "old" account.  Just not for new accounts.
>
> What I was trying to point out was, 'idmap config' in smb.conf
changed
> at 4.6.0, yours is for pre 4.6.0
> Not that it matters, because you are using 'security = ADS', the
> machine must be joined to AD and all authentication will be coming from
> AD, your ldap server will be ignored.
>
>>
>> Do you have any configuration suggestion?
>>
>
> You could try this, use 'security = user' and run your server as a
> standalone pulling your info from your ldap server.
>
>> Is there a way to have winbind not fail a login just because it
>> cannot map a SID to GID? Is there a way for me to force
>> a mapping for S-1-5-21-8915387-943144406-1916815836-513?
>> I tried wbinfo --set-gid-mapping but just got WBC_ERR_NOT_IMPLEMENTED
>
> This isn't implemented for 'ADS' because it isn't required,
you
> normally just give Domain Users a gidNumber.
>
>>
>> I guess for now I will continue to run Samba 4.7.x as long as I can
>> still get it to run
>
> 4.7.x is still supported by Samba and will be until 4.10.0 comes out
> (approx beginning of March)
>
> Rowland
>
>
>

On Tue, 8 Jan 2019 16:25:55 -0500 (EST)
Paul Raines <raines at nmr.mgh.harvard.edu> wrote:
> 
> It appears there is still misunderstanding about my situation/setup.
> Sorry, I know this is strange.
> 
> I have an LDAP server for my Linux infrastructure that is totally
> seperate from the corporate AD Windows domain.  At one point my LDAP
> did have the samba schema installed with my its own SID's and
> smbpasswd's in it. My web app for users to change their Linux
> password would on the backend set their 'userPassword' and
> 'sambaNTPassword' via separate calls to keep them in sync.
> 
> But when the edict to do single sign on to the coporate AD happened I
> stopped using any of the samba schema in my LDAP server.  And I set
> each user's 'userPassword' field to something like
'{SASL}per2' to
> use passthru on the LDAP authentication end.  And I configured samba
> to use corporate AD with the username map
> 
> Corporate is definitely NOT going to let me copy 'sambaNTPassword'
> from them or let me setup my own domain to trust.  The later would
> probably not work anyway due to the mismatch with names/uids.
> 
You are either going to have to do one of two things, stick with 4.7.x
(which isn't a good thing in the long term), or explain to
'corporate'
that it is going to cost them a lot of money to fix this.

Your setup would best be described as a lash up

I do not think there is an easy way to fix your problem, except for
using your AD. It would have been a lot easier if you hadn't done
something stupid like having your users in your ldap and AD with
different names. I know Samba is capable of being bent to do some
strange things, but you are trying to bend it too far.

You will not like this, but you are going to have to work with it.
There have been numerous changes since 4.7.0 and it is very unlikely
that whatever has broken your setup will be reversed.

Rowland

I think that is fair to say about my old accounts where names and IDs
do not match.  But the crazy thing is it is those accounts which work fine
and it is the new accounts where I did make the names and IDs match where
things do not work!

I am still confused about the supplemental groups thing.  Are you saying
Samba will not support a mode where 'security = ads' for authentication
against AD but there are groups defined "locally" (and not in AD) that
can be used in smb.conf for things like 'valid users' and 'force
group'?

Does using 'security = ads' actually REQUIRE that winbind also be used
in NIS (nsswitch.conf/pam) now?

I have tried 'security = domain' as the smb.conf man page mostly
describes
this as what I want but using this always results in

Checking NTLMSSP password for MYDOMAIN\user failed: NT_STATUS_LOGON_FAILURE

for any user login without winbind running.  When I run winbind, winbind
hangs and can only be killed by a kill -9 signal. Even 'wbinfo
--own-domain'
just hangs forever.  Runing winbind in the foreground with -d 10 it seems
to be constantly trying to connect to the DC and failing with

Connecting to 172.18.1.18 at port 445
fcntl_lock 25 6 0 1 0
fcntl_lock: fcntl lock gave errno 11 (Resource temporarily unavailable)
fcntl_lock: lock failed at offset 0 count 1 op 6 type 0 (Resource temporarily 
unavailable)



On Tue, 8 Jan 2019 5:19pm, Rowland Penny wrote:
> On Tue, 8 Jan 2019 16:25:55 -0500 (EST)
> Paul Raines <raines at nmr.mgh.harvard.edu> wrote:
>
>>
>> It appears there is still misunderstanding about my situation/setup.
>> Sorry, I know this is strange.
>>
>> I have an LDAP server for my Linux infrastructure that is totally
>> seperate from the corporate AD Windows domain.  At one point my LDAP
>> did have the samba schema installed with my its own SID's and
>> smbpasswd's in it. My web app for users to change their Linux
>> password would on the backend set their 'userPassword' and
>> 'sambaNTPassword' via separate calls to keep them in sync.
>>
>> But when the edict to do single sign on to the coporate AD happened I
>> stopped using any of the samba schema in my LDAP server.  And I set
>> each user's 'userPassword' field to something like
'{SASL}per2' to
>> use passthru on the LDAP authentication end.  And I configured samba
>> to use corporate AD with the username map
>>
>> Corporate is definitely NOT going to let me copy
'sambaNTPassword'
>> from them or let me setup my own domain to trust.  The later would
>> probably not work anyway due to the mismatch with names/uids.
>>
>
> You are either going to have to do one of two things, stick with 4.7.x
> (which isn't a good thing in the long term), or explain to
'corporate'
> that it is going to cost them a lot of money to fix this.
>
> Your setup would best be described as a lash up
>
> I do not think there is an easy way to fix your problem, except for
> using your AD. It would have been a lot easier if you hadn't done
> something stupid like having your users in your ldap and AD with
> different names. I know Samba is capable of being bent to do some
> strange things, but you are trying to bend it too far.
>
> You will not like this, but you are going to have to work with it.
> There have been numerous changes since 4.7.0 and it is very unlikely
> that whatever has broken your setup will be reversed.
>
> Rowland
>
>
>