samba - Feb 2022 - using aliases for samba servers in an AD

18.02.2022 15:25, Michael Tokarev via samba wrote:
> 18.02.2022 14:45, Christian Naumer via samba wrote:
>> Hi,
>> last time I did this using just CNAMEs worked with Windows as a client.
For us it just was smbclient that didn't work. However, adding cifs/tsrv as
>> SPN for that computer should fix it (it did for us)
> 
> I were debugging other prob with win connection and thought I'd
> give smbclient a try, but faced its own unique issue :)
> 
> Yes, Christian, adding cifs/tsrv SPN for that host helped, smbclient
> can now connect with -k to a CNAME - actually to ANY CNAME for that
> host.? Thank you for the hint!
> 
> However, I become curious - which SPN I actually need to add, for the
> main name or the CNAME, for complete name.domain or just he name part..
> And I and _removed_ that SPN which I just added, entirely...
> 
> And the thing.. continues working!? I can't force it to fail anymore
> once cifs/tsrv SPN were added and removed.? So I'm really confused
> now what's going on behind the scenes.. :)
Ok. Answering to my own post.

The SPNs are cached in the local krb5 cache. And one have to add ALL
alternative names as cifs/ SPNs for the host in question (besides its
own name) for smbclient to actually work.

Eg, if you use alias (CNAME) "fs" when accessing this server, you have
to have servicePrincipalName: CIFS/FS in the AD. If you use
"fs.tls.msk.ru",
you have to have CIFS/FS.tls.msk.ru. Etc.  For any names this server is
being accessed as you have to add CIFS/name SPN to the AD. Even
"localhost".

I dunno why smbclient does not complain about server's own name (tsrv
in our case).

Thanks,

/mjt

On Fri, 2022-02-18 at 15:52 +0300, Michael Tokarev via samba
wrote:
> 18.02.2022 15:25, Michael Tokarev via samba wrote:
> > 18.02.2022 14:45, Christian Naumer via samba wrote:
> > > Hi,
> > > last time I did this using just CNAMEs worked with Windows as a
> > > client. For us it just was smbclient that didn't work.
However,
> > > adding cifs/tsrv as 
> > > SPN for that computer should fix it (it did for us)
> > 
> > I were debugging other prob with win connection and thought I'd
> > give smbclient a try, but faced its own unique issue :)
> > 
> > Yes, Christian, adding cifs/tsrv SPN for that host helped,
> > smbclient
> > can now connect with -k to a CNAME - actually to ANY CNAME for that
> > host.  Thank you for the hint!
> > 
> > However, I become curious - which SPN I actually need to add, for
> > the
> > main name or the CNAME, for complete name.domain or just he name
> > part..
> > And I and _removed_ that SPN which I just added, entirely...
> > 
> > And the thing.. continues working!  I can't force it to fail
> > anymore
> > once cifs/tsrv SPN were added and removed.  So I'm really confused
> > now what's going on behind the scenes.. :)
> 
> Ok. Answering to my own post.
> 
> The SPNs are cached in the local krb5 cache. And one have to add ALL
> alternative names as cifs/ SPNs for the host in question (besides its
> own name) for smbclient to actually work.
> 
> Eg, if you use alias (CNAME) "fs" when accessing this server, you
> have
> to have servicePrincipalName: CIFS/FS in the AD. If you use
> "fs.tls.msk.ru",
> you have to have CIFS/FS.tls.msk.ru. Etc.  For any names this server
> is
> being accessed as you have to add CIFS/name SPN to the AD. Even
> "localhost".
> 
> I dunno why smbclient does not complain about server's own name (tsrv
> in our case).
Because this is one alias that does work with AD, the SPN 'HOST/fqdn'
is an alias for a long list of others, among which is 'CIFS/fqdn'. I
haven't tried it, but adding 'HOST/$CNAME' SPN to the computers
object
that the CNAME points to, will probably work.

Rowland