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
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 >
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 >> >
Point #1: is not correct. Why is Jake getting an ID from * Range and not APEX range. ? That need to be found first Run: net cache flush Restart samba. : systemctl restart smbd winbind nmbd (and/or sssd is you use that) wbinfo --all-domains -ug id jake getent passwd jake Any improvement?> if you have set: APEX:backend = adYes, and did you assign an UID/GID after you changed RID to AD backend? Greetz, Louis> -----Oorspronkelijk bericht----- > Van: samba [mailto:samba-bounces at lists.samba.org] Namens > Yakov Revyakin via samba > Verzonden: vrijdag 17 juli 2020 20:38 > Aan: Rowland penny > CC: sambalist > Onderwerp: Re: [Samba] Authentication with trusted credentials > > 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 > >> > > > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba > >