Fedora 32 MIT Kerberos and samba 4.12.2: Remote Desktop application cannot login from win to another win with domain users

Sun Jun 7 04:51:42 UTC 2020

On to, 04 kesä 2020, Dario Lesca via samba-technical wrote:
> I work on a test environment to test samba AD with MIT kerberos out of
> the box.
> 
> I have a AD-DC samba on Fedora 32 (addc1), a Centos 8 member server
> (centos8) and two PC windows 10 (win10a and win10b), fedora.loc is the
> AD REALM test domain name
> 
> All work fine, except to access from windows to windows with remote
> desktop. 
> 
> I work on win10b with user administrator at fedora.loc and if I try to
> access to win10a with remote desktop, not work.
> I get a password request and I cannot access with domain users, I can
> access only with win10a local user enabled.
> 
> This is what I get into /var/log/samba/mit_kdc.log:
> 
> mag 15 16:58:49 addc1.fedora.loc krb5kdc[821](info): AS_REQ (6 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), DEPRECATED:arcfour-hmac(23), DEPRECATED:arcfour-hmac-exp(24), UNSUPPORTED:(-135), UNSUPPORTED:des-cbc-md5(3)}) 192.168.122.102: NEEDED_PREAUTH: Administrator at FEDORA for krbtgt/FEDORA at FEDORA, Additional pre-authentication required
> mag 15 16:58:49 addc1.fedora.loc krb5kdc[821](info): closing down fd 19
> mag 15 16:58:49 addc1.fedora.loc krb5kdc[821](info): AS_REQ (6 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), DEPRECATED:arcfour-hmac(23), DEPRECATED:arcfour-hmac-exp(24), UNSUPPORTED:(-135), UNSUPPORTED:des-cbc-md5(3)}) 192.168.122.102: ISSUE: authtime 1589554729, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)}, Administrator at FEDORA for krbtgt/FEDORA at FEDORA
> mag 15 16:58:49 addc1.fedora.loc krb5kdc[821](info): closing down fd 19
> mag 15 16:58:49 addc1.fedora.loc krb5kdc[821](info): TGS_REQ (5 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), DEPRECATED:arcfour-hmac(23), DEPRECATED:arcfour-hmac-exp(24), UNSUPPORTED:(-135)}) 192.168.122.102: ISSUE: authtime 1589554729, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)}, Administrator at FEDORA.LOC for TERMSRV/win10a at FEDORA.LOC
> mag 15 16:58:49 addc1.fedora.loc krb5kdc[821](info): closing down fd 19
> mag 15 16:58:49 addc1.fedora.loc krb5kdc[821](info): TGS_REQ 192.168.122.102: 2ND_TKT_MISMATCH: authtime 1589554729, Administrator at FEDORA.LOC for TERMSRV/win10a at FEDORA.LOC, 2nd tkt client WIN10A$@FEDORA.LOC
> mag 15 16:58:49 addc1.fedora.loc krb5kdc[821](info): closing down fd 19
> 
> If I try to access via file manager to some shared folder on win10a
> (\\win10a\share\) all work fine.
> 
> Also if I try to access to win10a from Linux Fedora addc1 server with
> xfreerdp utility ( via ssh -XY addc1) all work fine and I can access
> without problem, this is the log session:
> 
> [lesca at addc1 ~]$ xfreerdp  /u:administrator at fedora.loc /v:win10a.fedora.loc
> [18:01:32:549] [2340:2341] [INFO][com.freerdp.core] - freerdp_connect:freerdp_set_last_error_ex resetting error state
> [18:01:32:549] [2340:2341] [INFO][com.freerdp.client.common.cmdline] - loading channelEx rdpdr
> [18:01:32:549] [2340:2341] [INFO][com.freerdp.client.common.cmdline] - loading channelEx rdpsnd
> [18:01:32:549] [2340:2341] [INFO][com.freerdp.client.common.cmdline] - loading channelEx cliprdr
> [18:01:35:857] [2340:2341] [INFO][com.freerdp.primitives] - primitives autodetect, using optimized
> [18:01:35:864] [2340:2341] [INFO][com.freerdp.core] - freerdp_tcp_is_hostname_resolvable:freerdp_set_last_error_ex resetting error state
> [18:01:35:867] [2340:2341] [INFO][com.freerdp.core] - freerdp_tcp_connect:freerdp_set_last_error_ex resetting error state
> [18:01:35:886] [2340:2341] [WARN][com.freerdp.crypto] - Certificate verification failure 'unable to get local issuer certificate (20)' at stack position 0
> [18:01:35:886] [2340:2341] [WARN][com.freerdp.crypto] - CN = win10a.fedora.loc
> Password: 
> [18:01:39:264] [2340:2341] [INFO][com.freerdp.gdi] - Local framebuffer format  PIXEL_FORMAT_BGRX32
> [18:01:39:265] [2340:2341] [INFO][com.freerdp.gdi] - Remote framebuffer format PIXEL_FORMAT_RGB16
> [18:01:40:343] [2340:2341] [INFO][com.winpr.clipboard] - initialized POSIX local file subsystem
> [18:01:41:829] [2340:2341] [INFO][com.freerdp.channels.rdpsnd.client] - Loaded fake backend for rdpsnd
> [18:02:12:906] [2340:2341] [INFO][com.freerdp.core] - rdp_set_error_info:freerdp_set_last_error_ex resetting error state
> [18:02:12:906] [2340:2347] [WARN][com.freerdp.channels.cliprdr.common] - [cliprdr_packet_format_list_new] called with invalid type 00000000
> 
> I have fill this RedHat bug:
> https://bugzilla.redhat.com/show_bug.cgi?id=1836630
> 
> I must fill also a bug on samba bugzilla?

As I said, it is a bug in MIT Kerberos, not Samba.
We discussed this with Isaac and we need to fix it MIT upstream. Sorry,
last two weeks were too busy for me.

> 
> Here some comment get on Fedora ML
> 
> > From Alexander Bokovoy
> > This is one of user-to-user authentication cases that aren't
> > implemented 
> > properly in MIT Kerberos and Samba AD for aliases (SPNs) of the
> > machine
> > account:
> > 
> >   19 mag 15 16:58:49 addc1.fedora.loc krb5kdc[821](info): TGS_REQ
> >   192.168.122.102: 2ND_TKT_MISMATCH: authtime 1589554729,
> >   Administrator at FEDORA.LOC for TERMSRV/win10a at FEDORA.LOC, 2nd tkt
> >   client WIN10A$@FEDORA.LOC
> >   mag 15 16:58:49 addc1.fedora.loc krb5kdc[821](info): closing down
> > fd
> > 
> > From Windows point of view TERMSRV/win10a is a service principal
> > name of
> > the WIN10A$ machine account, so they share the same key and are seen
> > at
> > the same principal for the check that is being done here. For MIT
> > Kerberos, it doesn't see them as aliases as it does explicit compare
> > of
> > the principals and requested service principal does not match the
> > principal in the evidence (2nd) ticket.
> 
> 
> > From Isaac Boukris:
> > From the code context of the '2ND_TKT_MISMATCH' error, it looks like
> > it is doing user-to-user authentication (KDC_OPT_ENC_TKT_IN_SKEY).
> > 
> > Sounds like we might need to invoke krb5_db_check_alias() from PR
> > 
> > #1014 here as well.
> 
> 
> Many thanks
> 
> -- 
> Dario Lesca
> (inviato dal mio Linux Fedora 32 Workstation)
> 
> 

-- 
/ Alexander Bokovoy