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

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.. :)

Thanks!

/mjt
> Regards
> 
> Christian
> 
> Am 18.02.22 um 12:25 schrieb Michael Tokarev via samba:
>> Hello!
>>
>> We observed that after setting up a samba AD, we can't connect to -
>> at least - linux samba servers with kerberos auth using alternative
>> names.
>>
>> We always had CNAMEs for role names in DNS, and those CNAMEs work
>> right now too, after AD setup.
>>
>> In particular, there's a server named "tsrv" (with A
record), and
>> a CNAME "fs" pointing to it (stands for File Server).
>>
>> DNS resolution works, - either short name or long name (with
.tls.msk.ru
>> domain) can be used.
>>
>> But samba does not work:
>>
>> $ smbclient //tsrv/mjt -U mjt -k
>> gensec_spnego_client_negTokenInit_step: gse_krb5: creating
NEG_TOKEN_INIT for cifs/fs failed (next[(null)]): NT_STATUS_INVALID_PARAMETER
>> session setup failed: NT_STATUS_INVALID_PARAMETER
>>
>> $ smbclient //tsrv/mjt -U mjt -k
>> Try "help" to get a list of possible commands.
>> smb: \>
>>
>> $ smbclient //fs.tls.msk.ru/mjt -U mjt -k
>> gensec_spnego_client_negTokenInit_step: gse_krb5: creating
NEG_TOKEN_INIT for cifs/fs.tls.msk.ru failed (next[(null)]):
NT_STATUS_INVALID_PARAMETER
>> session setup failed: NT_STATUS_INVALID_PARAMETER
>>
>> $ smbclient //tsrv.tls.msk.ru/mjt -U mjt -k
>> Try "help" to get a list of possible commands.
>> smb: \>
>>
>> both names resolves:
>>
>> $ dnsget fs
>> fs.tls.msk.ru. CNAME tsrv.tls.msk.ru.
>> tsrv.tls.msk.ru. A 192.168.177.2
>>
>> What's wrong with using CNAMEs?
>>
>> Thanks,
>>
>> /mjt
>>
>

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