samba - Oct 2019 - AD domain member cannot authenticate user in remote forest unless smbclient uses "localhost"

On Tue, Oct 29, 2019 at 11:43 AM Rowland penny via samba <
samba at lists.samba.org> wrote:
> A) You do not need 'realmd', 'sssd' etc
>
Understood. Using realmd is a convenience, as it automates some
housekeeping, but I'm happy to take it out of the picture for the purposes
of this test, if that's important.
> B) Your smb.conf is incorrectly set up.
>
I'm not surprised. I read the docs and used "testparm", but
I'm not a samba
expert, and I know there are lots of ways to write a valid, but silly,
smb.conf.  What, other than the id mapping config, should I change?

Here's the config again (with a more appropriate id mapping config), for
reference:

[global]
kerberos method = system keytab
logging = systemd
realm = TC83.LOCAL
security = ADS
template homedir = /home/%U@%D
template shell = /bin/bash
winbind offline logon = Yes
winbind refresh tickets = Yes
workgroup = TC83
idmap config * : backend = autorid
idmap config * : range = 1000000-19999999

[test]
path = /srv/test
valid users = "@tc83.local\domain users" "@tc84.local\domain
users"

> > Does anyone know whether winbind is expected to be able to handle
> > authenticating users in other trusted forests, and if so, why it might
> only
> > be able to do so when ntlmssp is used (vs. gse_krb5)?
> >
> >
> Trusted domains are supposed to work, but not sure about across forests ?
>
Is there a better place for me to ask this question?

n

On 29/10/2019 15:59, Nathaniel W. Turner via samba
wrote:
> On Tue, Oct 29, 2019 at 11:43 AM Rowland penny via samba <
> samba at lists.samba.org> wrote:
>
>> A) You do not need 'realmd', 'sssd' etc
>>
> Understood. Using realmd is a convenience, as it automates some
> housekeeping, but I'm happy to take it out of the picture for the
purposes
> of this test, if that's important.
I personally have never needed 'realmd', YMMV
>
>> B) Your smb.conf is incorrectly set up.
>>
> I'm not surprised. I read the docs and used "testparm", but
I'm not a samba
> expert, and I know there are lots of ways to write a valid, but silly,
> smb.conf.  What, other than the id mapping config, should I change?
>
> Here's the config again (with a more appropriate id mapping config),
for
> reference:
>
> [global]
> kerberos method = system keytab
I would alter the line above, to 'secrets and
keytab'
> logging = systemd
> realm = TC83.LOCAL
> security = ADS
> template homedir = /home/%U@%D
> template shell = /bin/bash
> winbind offline logon = Yes
> winbind refresh tickets = Yes
> workgroup = TC83
> idmap config * : backend = autorid
> idmap config * : range = 1000000-19999999
>
> [test]
> path = /srv/test
> valid users = "@tc83.local\domain users" "@tc84.local\domain
users"
I wouldn't use 'valid users', I would set the permissions from
Windows,
but to do this you will need to add this to smb.conf:

username map = /etc/samba/user.map

And create '/etc/samba/user.map' with this content:

!root = TC83\Administrator

Finally your share is unwriteable, to make it writeable, add 'read only 
= no'

Apart from that, your smb.conf is basically OK, though you may want to 
add these lines lines:

 ??? vfs objects = acl_xattr
 ??? map acl inherit = Yes

Rowland

Thanks for the suggestions. What you suggest makes sense for getting shares
exported in a way that works for typical use cases. As far as I can tell,
other than the "kerberos method" setting, none of these should impact
how a
user is authenticated, just what they can do once they are.

Is there anyone on this list who is familiar with cross-forest operation,
and knows why authentication works when NTLMSSP is chosen, but not
otherwise (i.e. when Kerberos is used)?

n

Thanks for the suggestions. What you propose makes sense for getting shares
exported in a way that works for typical use cases. As far as I can tell,
other than the "kerberos method" setting, none of these should impact
how a
user is authenticated, just what they can do once they are.

Is there anyone on this list who is familiar with cross-forest operation,
and knows why authentication works when NTLMSSP is chosen, but not
otherwise (i.e. when Kerberos is used)?