[Samba] Authentication with trusted credentials

[Yakov Revyakin]

So,
Point #1:
Samba DC before trust. Linux member joined domain. SSH authentication works
for a domain user. Checked with ad and rid backends. getent / id returns
correct UID:GID.

Point #2:
Samba DC after making trust with external AD. With the same Linux PC SSH
authentication and session still works with the trusting domain user in the
same right manner.
Trusted authentication works but it is routed according to the default
backend. SSH session is created.

# trusting user - authentication successful

Kerberos: TGS-REQ test01 at SVITLA3.ROOM from ipv4:10.0.0.12:50510 for
UC-SM18$@SVITLA3.ROOM
Kerberos: TGS-REQ authtime: 2020-07-17T16:47:35 starttime:
2020-07-17T16:47:35 endtime: 2020-07-18T02:47:35 renew till: unset

# trusted user - cross-realm authentication successful

Kerberos: TGS-REQ jake at APEX.CORP from ipv4:10.0.0.12:52437 for
UC-SM18$@SVITLA3.ROOM
Kerberos: Client not found in database: no such entry found in hdb
Kerberos: cross-realm APEX.CORP -> SVITLA3.ROOM

Kerberos: TGS-REQ authtime: 2020-07-17T18:07:28 starttime:
2020-07-17T18:07:28 endtime: 2020-07-18T04:07:28 renew till: unset


# uid|gid according with backend range
d at uc-sm18:~$ id test01 at SVITLA3
uid=20000(SVITLA3\test01) gid=20000(SVITLA3\domain users)
groups=20000(SVITLA3\domain users),3001(BUILTIN\users)
d at uc-sm18:~$ getent passwd test01 at SVITLA3.ROOM
SVITLA3\test01:*:20000:20000:test01:/home/SVITLA3/test01:/bin/bash

# uid|gid according to the default backend!!!
d at uc-sm18:~$ id APEX\\jake
uid=3000(APEX\jake) gid=3004(APEX\domain users) groups=3004(APEX\domain
users)
d at uc-sm18:~$ getent passwd  APEX\\jake
APEX\jake:*:3000:3004:jake:/home/APEX/jake:/bin/bash

# Linux client - smb.conf extraction
  idmap config * : backend = tdb
  idmap config * : range = 3000-7999

   idmap config SVITLA3:backend = rid
  idmap config SVITLA3:range = 20000-29999

   idmap config APEX:backend = rid
  idmap config APEX:range = 10000-19999

  template shell = /bin/bash

If I set APEX:backend = ad I get ssh authentication failed with Permission
Denied error. Probably authentication process can't extract uid|gid and
failed. In case of rid there are no such strong restrictions I think.

By the way, enabling/disabling of GSSAPI and UseDNS properties in
sshd_config don't influence behaviour.

What do you think about the correctness of trusted authentication setup? It
would be nice if there is a way to control uid|gid for trusted accounts. We
can see that we can exclude backend definition for trusted accounts and it
will still work. It looks like what I am looking for but what about
incorrect uid|gid?

Could you advise me what is the simplest way to check access to a file
share under trusted domain control with this Linux and trusted credentials?


On Fri, 17 Jul 2020 at 07:56, Yakov Revyakin <yrevyakin at gmail.com> wrote:

> Rowland,
> I only tried sssd looking for the cause of the problem.
> I use samba, winbind.
>
>
>
>
> On Fri, 17 Jul 2020 at 00:19, Rowland penny via samba <
> samba at lists.samba.org> wrote:
>
>> On 16/07/2020 22:13, Yakov Revyakin wrote:
>> > Thank you! I have food for tomorrow. Now I only want to voice some of
>> > my considerations.
>> >
>> > Imagine that a domain had no trusts. At this time a PC became a member
>> > of this domain.
>> > After some time DC made trust with another domain. In this case
>> > existing members don't consider any extra configuration like adding
>> > knowledge about new realm, DNS, etc. Existing configuration already
>> > provides means of login and session for a user of a trusted domain.
>> >
>> > In my case Linux PC was informed about trusting DNS before joining
>> > the domain. After setting DNS but before joining the domain I could
>> > authenticate users from both trusting and trusted domains with kinit
>> > without any modifications in krb5.conf. And it is what I was waiting
>> for.
>> >
>> > So, the PC already has a means to authenticate users from both
>> > domains.  How to enable that means?
>> >
>> Are you using sssd ?
>>
>> If you are, then ask on the sssd-users mailing list, because it is sssd
>> that will be doing the authentication, not Samba. We do not produce
>> sssd, so know little about it.
>>
>> If you are not using sssd, then we can look into your problem.
>>
>> Rowland
>>
>>
>>
>>
>> --
>> To unsubscribe from this list go to the following URL and read the
>> instructions:  https://lists.samba.org/mailman/options/samba
>>
>