samba - Aug 2020 - pam+winbind and maintaining domain membership: keytab vs tickets

Hello. I am trying to clarify in my mind how winbind, pam and kerberos all
work. I am hoping to get some knowledge to help debug and ensure our samba
server keeps it's domain membership in the most robust way possible.

Background: We are using a samba server to serve a filesystem to windows
users. A group policy on the machines will automatically mount the
filesystem. Samba and all the windows machines are expected to always be
members of the same AD domin.

Situation:
Not having used kerberos before I was getting tickets and keytabs confused.
I start to think that in the current setup tickets are perhaps an
unnecessary complication. All that is really needed is a way to ensure the
samba server stays in the domain indefinitely and rejoins on reboot.

Currently we join the domain when we provision a server with the `net ads
join -U domainadmin`. After the domain join running `net ads keytab list`
will list keytabs with NETBIOS_NAME at OUR.DOMAIN as the principal. It seems
to work without running kinit or creating a ticket-granting-ticket.

So I think that having `winbind refresh tickets` in smb.conf is
unnecessary, and I can safely change `kerberos methos` to just `keytab`

Questions:
Is the keytab created when the `net ads join` command is run?
Is there a way to test the keytab is working? (other than restarting the
server)
Would this break if we had multiple servers configured with the same
NETBIOS_NAME?
Everything seems to work even if I stop the nmb daemon. I think this is
because we use the ip and not the netbios name in our mount scripts and
configuration. Is this correct?

I tried to find out all I could with google and reading the docs, but I am
still not sure I understand everything and would greatly appreciate some
clarity.

Thanks Much,
 - Isaac

On 06/08/2020 18:18, Isaac Stone via samba wrote:
> Hello. I am trying to clarify in my mind how winbind, pam and kerberos all
> work. I am hoping to get some knowledge to help debug and ensure our samba
> server keeps it's domain membership in the most robust way possible.
>
> Background: We are using a samba server to serve a filesystem to windows
> users. A group policy on the machines will automatically mount the
> filesystem. Samba and all the windows machines are expected to always be
> members of the same AD domin.
>
> Situation:
> Not having used kerberos before I was getting tickets and keytabs confused.
You need a keytab to get a ticket, but the keytab might not be the one 
in /etc , there is another keytab in memory.
> I start to think that in the current setup tickets are perhaps an
> unnecessary complication.
Only if you want things to stop working ;-)
>   All that is really needed is a way to ensure the
> samba server stays in the domain indefinitely and rejoins on reboot.
Once joined it should stay in the domain and it reconnects on reboot, 
not rejoin.
>
> Currently we join the domain when we provision a server with the `net ads
> join -U domainadmin`. After the domain join running `net ads keytab list`
> will list keytabs with NETBIOS_NAME at OUR.DOMAIN as the principal. It
seems
> to work without running kinit or creating a ticket-granting-ticket.
>
> So I think that having `winbind refresh tickets` in smb.conf is
> unnecessary, and I can safely change `kerberos methos` to just `keytab`
Only if you want your kerberos tickets to expire ;-)
>
> Questions:
> Is the keytab created when the `net ads join` command is run?
Yes provided there are these lines in smb.conf:

 ??? dedicated keytab file = /etc/krb5.keytab
 ??? kerberos method = secrets and keytab
> Is there a way to test the keytab is working? (other than restarting the
> server)
Try to get a ticket for something in the keytab
> Would this break if we had multiple servers configured with the same
> NETBIOS_NAME?
The only time you can use the same NETBIOS_NAME on multiple Samba 
machines is when you are running a CTDB cluster. Just don't add the 
'netbios name' line to smb.conf and Samba will set it for
you.
> Everything seems to work even if I stop the nmb daemon.
You only need to run 'nmbd' if you require network browsing and this 
requires SMBv1, which is being turned off everywhere.
> I think this is
> because we use the ip and not the netbios name in our mount scripts and
> configuration. Is this correct?
I don't know if you noticed, but AD relies on dns, so you should be able 
to the short hostname instead of the ip.

Rowland

Thanks for your quick replies

Yes, we are using a ctdb setup, and having the same netbios name was
something I understood as necessary there. Thanks for confirming

To clarify, currently we are not fetching any kerberos tickets for any
reason on the samba server. We are not using `kinit` explicitly anywhere
and everything seems to be working. In a previous setup we were calling it
because I thought it was necessary for winbind, thinking somehow winbind
used kerberos tickets to keep the server joined to the domain. I think I
was mistaken and just wanted to get confirmation. I am not exactly sure
what I would be using a kerberos ticket for?

What is the "secrets" kerberos method in "secrets and
keytab"? is it the
username/password combo from the initial join?

On Thu, Aug 6, 2020 at 10:47 AM Rowland penny via samba <
samba at lists.samba.org> wrote:
> On 06/08/2020 18:18, Isaac Stone via samba wrote:
> > Hello. I am trying to clarify in my mind how winbind, pam and kerberos
> all
> > work. I am hoping to get some knowledge to help debug and ensure our
> samba
> > server keeps it's domain membership in the most robust way
possible.
> >
> > Background: We are using a samba server to serve a filesystem to
windows
> > users. A group policy on the machines will automatically mount the
> > filesystem. Samba and all the windows machines are expected to always
be
> > members of the same AD domin.
> >
> > Situation:
> > Not having used kerberos before I was getting tickets and keytabs
> confused.
> You need a keytab to get a ticket, but the keytab might not be the one
> in /etc , there is another keytab in memory.
> > I start to think that in the current setup tickets are perhaps an
> > unnecessary complication.
> Only if you want things to stop working ;-)
> >   All that is really needed is a way to ensure the
> > samba server stays in the domain indefinitely and rejoins on reboot.
> Once joined it should stay in the domain and it reconnects on reboot,
> not rejoin.
> >
> > Currently we join the domain when we provision a server with the `net
ads
> > join -U domainadmin`. After the domain join running `net ads keytab
list`
> > will list keytabs with NETBIOS_NAME at OUR.DOMAIN as the principal. It
> seems
> > to work without running kinit or creating a ticket-granting-ticket.
> >
> > So I think that having `winbind refresh tickets` in smb.conf is
> > unnecessary, and I can safely change `kerberos methos` to just
`keytab`
> Only if you want your kerberos tickets to expire ;-)
> >
> > Questions:
> > Is the keytab created when the `net ads join` command is run?
> Yes provided there are these lines in smb.conf:
>
>      dedicated keytab file = /etc/krb5.keytab
>      kerberos method = secrets and keytab
> > Is there a way to test the keytab is working? (other than restarting
the
> > server)
> Try to get a ticket for something in the keytab
> > Would this break if we had multiple servers configured with the same
> > NETBIOS_NAME?
> The only time you can use the same NETBIOS_NAME on multiple Samba
> machines is when you are running a CTDB cluster. Just don't add the
> 'netbios name' line to smb.conf and Samba will set it for you.
> > Everything seems to work even if I stop the nmb daemon.
> You only need to run 'nmbd' if you require network browsing and
this
> requires SMBv1, which is being turned off everywhere.
> > I think this is
> > because we use the ip and not the netbios name in our mount scripts
and
> > configuration. Is this correct?
> I don't know if you noticed, but AD relies on dns, so you should be
able
> to the short hostname instead of the ip.
>
> Rowland
>
>
>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba
>
>