Bug 1748860

Dario,

in KDC logs I see this:

set 04 12:01:35 s-addc.studiomosca.net krb5kdc[6764](info): preauth (encrypted_timestamp) verify failure: Preauthentication failed
set 04 12:01:35 s-addc.studiomosca.net krb5kdc[6764](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), (-135), DEPRECATED:des-cbc-md5(3)}) 192.168.1.102: PREAUTH_FAILED: madrid$@STUDIO_MOSCA for krbtgt/STUDIO_MOSCA@STUDIO_MOSCA, Preauthentication failed
set 04 12:01:35 s-addc.studiomosca.net krb5kdc[6764](info): closing down fd 20

'Preauthentication failed' is a Kerberos for 'password is incorrect'. It looks like this particular machine is not having its machine account password the same as Samba AD DC thinks it should.

Could you please show output from 

kinit Administrator
net -s /dev/null ads search -S s-addc.studiomosca.net samaccountname=madrid\$

In the logs I see actual entry:

  dn: <GUID=47462bf2-948b-4678-a494-795f11653a83>;<SID=S-1-5-21-3718620208-793601445-2691216725-1007>;CN=MADRID,CN=Computers,DC=studiomosca,DC=net
  objectGUID: 47462bf2-948b-4678-a494-795f11653a83
  badPwdCount: 0
  badPasswordTime: 0
  lastLogon: 0
  primaryGroupID: 515
  objectSid: S-1-5-21-3718620208-793601445-2691216725-1007
  accountExpires: 9223372036854775807
  logonCount: 0
  sAMAccountName: MADRID$
  pwdLastSet: 130983518930000000
  displayName: MADRID$
  lastLogoff: 9223372036854775807
  logonHours:: ////////////////////////////
  userAccountControl: 4096
  objectClass: top
  objectClass: posixAccount
  objectClass: person
  objectClass: organizationalPerson
  objectClass: user
  objectClass: computer
  msDS-KeyVersionNumber: 2
  msDS-User-Account-Control-Computed: 0
  msDS-UserPasswordExpiryTimeComputed: 9223372036854775807
  # ntPwdHistory::: REDACTED SECRET ATTRIBUTE
  # unicodePwd::: REDACTED SECRET ATTRIBUTE

Note that Samba knows MADRID machine, not 'madrid' (lowcase). I think this is what fails for Kerberos as Kerberos principals are case-sensitive.

Since Kerberos authentication failed, NTLM variants were tried and failed as well:

[2019/09/04 11:50:55.550420,  4, pid=7320, effective(0, 0), real(0, 0)] ../../libcli/auth/ntlm_check.c:363(ntlm_password_check)
  ntlm_password_check: Checking NTLMv2 password with domain [STUDIO_MOSCA]
[2019/09/04 11:50:55.550468,  4, pid=7320, effective(0, 0), real(0, 0)] ../../libcli/auth/ntlm_check.c:377(ntlm_password_check)
  ntlm_password_check: Checking NTLMv2 password with uppercased version of domain [STUDIO_MOSCA]
[2019/09/04 11:50:55.550505,  4, pid=7320, effective(0, 0), real(0, 0)] ../../libcli/auth/ntlm_check.c:391(ntlm_password_check)
  ntlm_password_check: Checking NTLMv2 password without a domain
[2019/09/04 11:50:55.550541,  3, pid=7320, effective(0, 0), real(0, 0)] ../../libcli/auth/ntlm_check.c:403(ntlm_password_check)
  ntlm_password_check: NTLMv2 password check failed
[2019/09/04 11:50:55.550590,  3, pid=7320, effective(0, 0), real(0, 0)] ../../libcli/auth/ntlm_check.c:448(ntlm_password_check)
  ntlm_password_check: Lanman passwords NOT PERMITTED for user MADRID$
[2019/09/04 11:50:55.550618,  4, pid=7320, effective(0, 0), real(0, 0)] ../../libcli/auth/ntlm_check.c:485(ntlm_password_check)
  ntlm_password_check: Checking LMv2 password with domain STUDIO_MOSCA
[2019/09/04 11:50:55.550653,  4, pid=7320, effective(0, 0), real(0, 0)] ../../libcli/auth/ntlm_check.c:514(ntlm_password_check)
  ntlm_password_check: Checking LMv2 password with upper-cased version of domain STUDIO_MOSCA
[2019/09/04 11:50:55.550687,  4, pid=7320, effective(0, 0), real(0, 0)] ../../libcli/auth/ntlm_check.c:543(ntlm_password_check)
  ntlm_password_check: Checking LMv2 password without a domain
[2019/09/04 11:50:55.550721,  4, pid=7320, effective(0, 0), real(0, 0)] ../../libcli/auth/ntlm_check.c:574(ntlm_password_check)
  ntlm_password_check: Checking NT MD4 password in LM field
[2019/09/04 11:50:55.550748,  3, pid=7320, effective(0, 0), real(0, 0)] ../../libcli/auth/ntlm_check.c:595(ntlm_password_check)
  ntlm_password_check: LM password and LMv2 failed for user MADRID$, and NT MD4 password in LM field not permitted

Could you explain how did you join 'madrid' machine?

> Could you please show output from 
> 
> kinit Administrator
> net -s /dev/null ads search -S s-addc.studiomosca.net samaccountname=madrid\$

[root@s-addc samba]# kinit Administrator
Password for Administrator:
[root@s-addc samba]# net -s /dev/null ads search -S s-addc.studiomosca.net samaccountname=madrid\$
Got 1 replies

cn: MADRID
instanceType: 4
whenCreated: 20190827092712.0Z
whenChanged: 20190827092712.0Z
uSNCreated: 4018
name: MADRID
objectGUID: 47462bf2-948b-4678-a494-795f11653a83
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 0
lastLogon: 0
primaryGroupID: 515
objectSid: S-1-5-21-3718620208-793601445-2691216725-1007
accountExpires: 9223372036854775807
logonCount: 0
sAMAccountName: MADRID$
sAMAccountType: 805306369
objectCategory: CN=Computer,CN=Schema,CN=Configuration,DC=studiomosca,DC=net
isCriticalSystemObject: FALSE
pwdLastSet: 130983518930000000
displayName: MADRID$
lastLogoff: 9223372036854775807
userAccountControl: 4096
uidNumber: 833
objectClass: top
objectClass: posixAccount
objectClass: person
objectClass: organizationalPerson
objectClass: user
objectClass: computer
uSNChanged: 4021
distinguishedName: CN=MADRID,CN=Computers,DC=studiomosca,DC=net

(In reply to Alexander Bokovoy from comment #2)
> 
> Could you explain how did you join 'madrid' machine?

Machine MADRID is a Win7 PC joined many years ago to old samba NT4 PDC.

after the samba classicupdate I have not yet rejoin id to domain.

for now I have exited from domain the win7-1 PC to which all the others PC must connect with a local account

I have also creare a new virtual machine (win10-1) for test and join it to domain.

now if I from the win7-1 try to connect to win10-1 via "net use x: \\win10-1\pub pwd /user:user" I get the "system error 5 access deny."

Created attachment 1611482 [details]
pcap dump while I run on win7-1 "net use ..." to win10-1

(In reply to Alexander Bokovoy from fedora devel ML)
> I still need to see network traces that show breakage between Windows clients.

I have produce a pcap dump while I run on win7-1 "net use ..." towards win10-1

See attached file

For what it worth.
Even with a fresh samba installation on F30, a fresh windows installation and a new join to the domain the problem seems the same.

From another windows machine I can access the windows share using the IP address of the other one, but if I try to map the share using the machine name I get 
    System error 5 has occurred.
    Access is denied.
Same thing using file explorer: \\IPaddress\share works, \\hostname\share doesn't work.

But I suspect that there is something not properly configured...


Ciao! :-)

Dario,

unfortunately, this pcap dump only contains your attempt to acquire Kerberos ticket to cifs/win10-1... but no actual operations.

After getting a ticket to cifs/win10-1.. from KDC win7-1 doesn't even try to contact win10-1.

(In reply to Alessio from comment #6)
> For what it worth.
> Even with a fresh samba installation on F30, a fresh windows installation
> and a new join to the domain the problem seems the same.
> 
> From another windows machine I can access the windows share using the IP
> address of the other one, but if I try to map the share using the machine
> name I get 
>     System error 5 has occurred.
>     Access is denied.
> Same thing using file explorer: \\IPaddress\share works, \\hostname\share
> doesn't work.
> 
> But I suspect that there is something not properly configured...

Could you please provide logs and network dump? 'log level = 10' in smb.conf, restart everything, then record a network trace between Samba DC and two windows machines from the moment you login to Windows machine.

Dario's issue looks like really a machine account password being wrong between DC and win7-1.

(In reply to Alexander Bokovoy from comment #7)
> Dario,
> 
> unfortunately, this pcap dump only contains your attempt to acquire Kerberos
> ticket to cifs/win10-1... but no actual operations.
> 
> After getting a ticket to cifs/win10-1.. from KDC win7-1 doesn't even try to
> contact win10-1.

win7-1 now is not join to domain, it is a standalone workstation. win10-1 is joined to domain

I have run tcpdump on samba addc: "tcpdump -n -i ens3 -s 0 -w debug.samba-addc.pcap"

I must run it on win7-1 or win10-1?
or I must use some other params
ora I must do the test with another PC joined into domain?

(In reply to Alexander Bokovoy from comment #9)
> Dario's issue looks like really a machine account password being wrong
> between DC and win7-1.

It's possible to recovery this issue?

NOTE: Before run samba calssicupdate (it have worked well and ended without problem), I have must change administrator's ID (from 2005 to 500).
Now administrator's SID and password is not equal to old.
May this be the cause of my problem?

It might be but I'm not really sure about that -- this is not something I saw in the logs as you didn't use admin account.

Anyway, 

> win7-1 now is not join to domain, it is a standalone workstation. win10-1 is
> joined to domain
> 
> I have run tcpdump on samba addc: "tcpdump -n -i ens3 -s 0 -w
> debug.samba-addc.pcap"

You are probably better to limit what is captured to IP addresses of the machines involved ('host addc or host win10-1 or host win7-1' as a filter for tcpdump). Start tcpdump and then try to login to win7-1, then try to access resource on win10-1.

And provide Samba logs for the same period.

Created attachment 1611720 [details]
second debug pc-jolly (win7) and win10-1 (win10)

(In reply to Alexander Bokovoy from comment #12)
> ...Start tcpdump and then try to login to win7-1, then try to
> access resource on win10-1.
> 
> And provide Samba logs for the same period.

Done.

For this test I have used two PC joined to domain: pc-jolly and win10-1

[root@s-addc samba]# host 192.168.1.108
108.1.168.192.in-addr.arpa domain name pointer PC-JOLLY.studiomosca.net.
[root@s-addc samba]# host 192.168.1.165
165.1.168.192.in-addr.arpa domain name pointer win10-1.studiomosca.net.


I have enable this flag into smb.conf (via include smb-debug.conf)

[root@s-addc samba]# cat /etc/samba/smb-debug.conf 
# Global parameters
[global]
        ;debug level = 10
        ;debug pid = true
        ;debug timestamp = yes
        ;max log size = 0

        init logon delay = 1000
        log file = /var/log/samba/debug.%m.log
        log level = 10
        max log size = 500000
        timestamp logs = Yes
        debug class = Yes
        debug hires timestamp = Yes
        debug pid = Yes
        debug prefix timestamp = Yes
        debug uid = Yes
        ldap debug level = 0
        ldap debug threshold = 10
        passwd chat debug = Yes


restart samba (systemctr restart samba) and run tcpdump

sudo tcpdump -n -i ens3 -s 0 -w debug.samba-addc.pcap host pc-jolly or host win10-1

Then I connected to pc-jolly and win10-1 via rdesktop using same domain user (alberto)

On pc-jolly I have run "net use ... " to win10-1, and on win10-1 I have run "net use ..." to pc-jolly without success.

I have also try connect from PC-Jolly to win10-1 via \\win10-1\pub, in this case I have get a access denied and user & password request.

hope this help.

Does this log could be of interest?

If I run this command from an Ubuntu AD domain controller configured in a similar way as the Fedora one, I get a response:

root@adc1:~# wbinfo  -K administrator%xxxxxxxx --domain=MYDOMAIN -N winquattro
plaintext kerberos password authentication for [administrator%xxxxxxxx] succeeded (requesting cctype: FILE)
credentials were put in: FILE:/tmp/krb5cc_0
10.97.69.27	winquattro


The same command on Fedora lead to:

Could not lookup WINS by name winquattro


And in /var/log/samba/log.winbindd (loglevel in smb.conf is 10)

[2019/09/05 00:21:10.994462,  3, pid=2631, effective(0, 0), real(0, 0), class=winbind] ../../source3/winbindd/winbindd_wins_byname.c:56(winbindd_wins_byname_send)
  [ 2772]: wins_byname winquattro
[2019/09/05 00:21:10.994485, 10, pid=2631, effective(0, 0), real(0, 0)] ../../source3/libsmb/namequery.c:2136(resolve_wins_send)
  wins_server_tag_ips failed for tag *
[2019/09/05 00:21:10.994506,  3, pid=2631, effective(0, 0), real(0, 0)] ../../source3/libsmb/namequery.c:1834(name_resolve_bcast_send)
  name_resolve_bcast: Attempting broadcast lookup for name winquattro<0x20>
[2019/09/05 00:21:10.994606, 10, pid=2631, effective(0, 0), real(0, 0)] ../../source3/libsmb/unexpected.c:563(nb_packet_reader_connected)
  tstream_unix_connect failed: No such file or directory
[2019/09/05 00:21:10.994646, 10, pid=2631, effective(0, 0), real(0, 0)] ../../source3/libsmb/namequery.c:605(nb_trans_got_reader)
  nmbd not around

Created attachment 1611721 [details]
debug3=debug2+net-ads-search for some machine

I have add the output of these command:

[root@s-addc samba]# net -s /dev/null ads search -S s-addc.studiomosca.net samaccountname=pc-jolly\$ > debug.net-ads-search-pc-jolly.txt
[root@s-addc samba]# net -s /dev/null ads search -S s-addc.studiomosca.net samaccountname=win10-1\$ > debug.net-ads-search-win10-1.txt
[root@s-addc samba]# net -s /dev/null ads search -S s-addc.studiomosca.net samaccountname=s-dati\$ > debug.net-ads-search-s-dati.txt

Thanks.

Created attachment 1611722 [details]
mit kerberos log

if can help ...

(In reply to Alessio from comment #14)
> Does this log could be of interest?
> 
> Could not lookup WINS by name winquattro
> 

on samba DC also nmblookup not work for me:

[root@s-addc samba]# nmblookup pc-jolly
name_query failed to find name pc-jolly

If I run the same command on member server it work:

[root@s-dati ~]# nmblookup pc-jolly
192.168.1.108 pc-jolly<00>

via ps and strace I see on samba DC that nmbd is not running and on member server it's running.
Is this correct?

Where is not running the file /run/samba/nmbd/unexpected is missing:

[root@s-addc samba]# ll /run/samba/nmbd/unexpected
ls: cannot access '/run/samba/nmbd/unexpected': No such file or directory

[root@s-dati ~]# ll /run/samba/nmbd/unexpected
srwxrwxrwx. 1 root root 0 28 ago 17.06 /run/samba/nmbd/unexpected

Thanks. There are more issues, it seems. There is an issue: PC-JOLLY tries to perform S4U2Proxy for itself when alberto accesses it from win10-1 but it uses wrong principal (again, PC-JOLLY$ versus pc-jolly$) and that fails S4U2Proxy check:

set 04 23:44:49 s-addc.studiomosca.net krb5kdc[16492](info): AS_REQ (5 etypes {DEPRECATED:arcfour-hmac(23), (-133), (-128), DEPRECATED:arcfour-hmac-exp(24), (-135)}) 192.168.1.165: ISSUE: authtime 1567633489, etypes {rep=DEPRECATED:arcfour-hmac(23), tkt=DEPRECATED:arcfour-hmac(23), ses=DEPRECATED:arcfour-hmac(23)}, alberto for krbtgt/STUDIOMOSCA.NET
set 04 23:44:49 s-addc.studiomosca.net krb5kdc[16492](info): closing down fd 20
set 04 23:44:49 s-addc.studiomosca.net krb5kdc[16492](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), (-135)}) 192.168.1.165: ISSUE: authtime 1567633489, etypes {rep=DEPRECATED:arcfour-hmac(23), tkt=DEPRECATED:arcfour-hmac(23), ses=DEPRECATED:arcfour-hmac(23)}, alberto for cifs/pc-jolly.studiomosca.net
set 04 23:44:49 s-addc.studiomosca.net krb5kdc[16492](info): closing down fd 20
set 04 23:44:49 s-addc.studiomosca.net krb5kdc[16492](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), (-135)}) 192.168.1.108: ISSUE: authtime 1567613202, etypes {rep=DEPRECATED:arcfour-hmac(23), tkt=DEPRECATED:arcfour-hmac(23), ses=DEPRECATED:arcfour-hmac(23)}, PC-JOLLY$@STUDIOMOSCA.NET for pc-jolly$\@STUDIOMOSCA.NET
set 04 23:44:49 s-addc.studiomosca.net krb5kdc[16492](info): closing down fd 20
set 04 23:44:49 s-addc.studiomosca.net krb5kdc[16492](info): TGS_REQ 192.168.1.108: EVIDENCE_TICKET_MISMATCH: authtime 0, PC-JOLLY$@STUDIOMOSCA.NET for pc-jolly$\@STUDIOMOSCA.NET, 2nd tkt client <unknown>
set 04 23:44:49 s-addc.studiomosca.net krb5kdc[16492](info): closing down fd 20

Here is what PC-JOLLY sends:

Frame 1151: 1475 bytes on wire (11800 bits), 1475 bytes captured (11800 bits)
Ethernet II, Src: HewlettP_e9:9f:62 (80:c1:6e:e9:9f:62), Dst: RealtekU_d5:3c:a1 (52:54:00:d5:3c:a1)
Internet Protocol Version 4, Src: 192.168.1.108, Dst: 192.168.1.100
Transmission Control Protocol, Src Port: 61800, Dst Port: 88, Seq: 1, Ack: 1, Len: 1421
Kerberos
    Record Mark: 1417 bytes
        0... .... .... .... .... .... .... .... = Reserved: Not set
        .000 0000 0000 0000 0000 0101 1000 1001 = Record Length: 1417
    tgs-req
        pvno: 5
        msg-type: krb-tgs-req (12)
        padata: 1 item
            PA-DATA PA-TGS-REQ
                padata-type: kRB5-PADATA-TGS-REQ (1)
                    padata-value: 6e8204e3308204dfa003020105a10302010ea20703050000…
                        ap-req
                            pvno: 5
                            msg-type: krb-ap-req (14)
                            Padding: 0
                            ap-options: 00000000
                                0... .... = reserved: False
                                .0.. .... = use-session-key: False
                                ..0. .... = mutual-required: False
                            ticket
                                tkt-vno: 5
                                realm: STUDIOMOSCA.NET
                                sname
                                    name-type: kRB5-NT-SRV-INST (2)
                                    sname-string: 2 items
                                        SNameString: krbtgt
                                        SNameString: STUDIOMOSCA.NET
                                enc-part
                                    etype: eTYPE-ARCFOUR-HMAC-MD5 (23)
                                    kvno: 1
                                    cipher: 87300e42e00deb1f679b1e154a2f4b6adf09bee8916fc99e…
                            authenticator
                                etype: eTYPE-ARCFOUR-HMAC-MD5 (23)
                                cipher: ed69b6fc00f2e8683d277b2dbf78b098c0db9c9ef967d984…
        req-body
            Padding: 0
            kdc-options: 40810000 (forwardable, renewable, canonicalize)
            realm: STUDIOMOSCA.NET
            sname
                name-type: kRB5-NT-ENTERPRISE-PRINCIPAL (10)
                sname-string: 1 item
                    SNameString: pc-jolly$@STUDIOMOSCA.NET
            till: 2037-09-13 02:48:05 (UTC)
            nonce: 2062720916
            etype: 5 items
                ENCTYPE: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
                ENCTYPE: eTYPE-AES128-CTS-HMAC-SHA1-96 (17)
                ENCTYPE: eTYPE-ARCFOUR-HMAC-MD5 (23)
                ENCTYPE: eTYPE-ARCFOUR-HMAC-MD5-56 (24)
                ENCTYPE: eTYPE-ARCFOUR-HMAC-OLD-EXP (-135)

Here is Samba DC answer:

Frame 1153: 1471 bytes on wire (11768 bits), 1471 bytes captured (11768 bits)
Ethernet II, Src: RealtekU_d5:3c:a1 (52:54:00:d5:3c:a1), Dst: HewlettP_e9:9f:62 (80:c1:6e:e9:9f:62)
Internet Protocol Version 4, Src: 192.168.1.100, Dst: 192.168.1.108
Transmission Control Protocol, Src Port: 88, Dst Port: 61800, Seq: 1, Ack: 1422, Len: 1417
Kerberos
    Record Mark: 1413 bytes
        0... .... .... .... .... .... .... .... = Reserved: Not set
        .000 0000 0000 0000 0000 0101 1000 0101 = Record Length: 1413
    tgs-rep
        pvno: 5
        msg-type: krb-tgs-rep (13)
        crealm: STUDIOMOSCA.NET
        cname
            name-type: kRB5-NT-UNKNOWN (0)
            cname-string: 1 item
                CNameString: PC-JOLLY$
        ticket
            tkt-vno: 5
            realm: STUDIOMOSCA.NET
            sname
                name-type: kRB5-NT-ENTERPRISE-PRINCIPAL (10)
                sname-string: 1 item
                    SNameString: pc-jolly$@STUDIOMOSCA.NET
            enc-part
                etype: eTYPE-ARCFOUR-HMAC-MD5 (23)
                kvno: 5
                cipher: 594e2792503f5ecc250c85243b2bff79b7904b0ffbec8df5…
        enc-part
            etype: eTYPE-ARCFOUR-HMAC-MD5 (23)
            cipher: 39d5054c43fe3352aa79c6c7fbecf5d3d7b7174b3a9415bc…

Then it requests S4U2Proxy:

Frame 1161: 2577 bytes on wire (20616 bits), 2577 bytes captured (20616 bits)
Ethernet II, Src: HewlettP_e9:9f:62 (80:c1:6e:e9:9f:62), Dst: RealtekU_d5:3c:a1 (52:54:00:d5:3c:a1)
Internet Protocol Version 4, Src: 192.168.1.108, Dst: 192.168.1.100
Transmission Control Protocol, Src Port: 61801, Dst Port: 88, Seq: 1, Ack: 1, Len: 2523
Kerberos
    Record Mark: 2519 bytes
        0... .... .... .... .... .... .... .... = Reserved: Not set
        .000 0000 0000 0000 0000 1001 1101 0111 = Record Length: 2519
    tgs-req
        pvno: 5
        msg-type: krb-tgs-req (12)
        padata: 1 item
            PA-DATA PA-TGS-REQ
                padata-type: kRB5-PADATA-TGS-REQ (1)
                    padata-value: 6e8204e3308204dfa003020105a10302010ea20703050000…
                        ap-req
                            pvno: 5
                            msg-type: krb-ap-req (14)
                            Padding: 0
                            ap-options: 00000000
                                0... .... = reserved: False
                                .0.. .... = use-session-key: False
                                ..0. .... = mutual-required: False
                            ticket
                                tkt-vno: 5
                                realm: STUDIOMOSCA.NET
                                sname
                                    name-type: kRB5-NT-SRV-INST (2)
                                    sname-string: 2 items
                                        SNameString: krbtgt
                                        SNameString: STUDIOMOSCA.NET
                                enc-part
                                    etype: eTYPE-ARCFOUR-HMAC-MD5 (23)
                                    kvno: 1
                                    cipher: 87300e42e00deb1f679b1e154a2f4b6adf09bee8916fc99e…
                            authenticator
                                etype: eTYPE-ARCFOUR-HMAC-MD5 (23)
                                cipher: 30750834e368ab17711e19aace503b3019f3785f1907d8db…
        req-body
            Padding: 0
            kdc-options: 40830000 (forwardable, renewable, constrained-delegation, canonicalize)
            realm: STUDIOMOSCA.NET
            sname
                name-type: kRB5-NT-ENTERPRISE-PRINCIPAL (10)
                sname-string: 1 item
                    SNameString: pc-jolly$@STUDIOMOSCA.NET
            till: 2019-09-04 21:59:49 (UTC)
            nonce: 2063233733
            etype: 5 items
                ENCTYPE: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
                ENCTYPE: eTYPE-AES128-CTS-HMAC-SHA1-96 (17)
                ENCTYPE: eTYPE-ARCFOUR-HMAC-MD5 (23)
                ENCTYPE: eTYPE-ARCFOUR-HMAC-MD5-56 (24)
                ENCTYPE: eTYPE-ARCFOUR-HMAC-OLD-EXP (-135)
            additional-tickets: 1 item
                Ticket
                    tkt-vno: 5
                    realm: STUDIOMOSCA.NET
                    sname
                        name-type: kRB5-NT-ENTERPRISE-PRINCIPAL (10)
                        sname-string: 1 item
                            SNameString: pc-jolly$@STUDIOMOSCA.NET
                    enc-part
                        etype: eTYPE-ARCFOUR-HMAC-MD5 (23)
                        kvno: 5
                        cipher: 594e2792503f5ecc250c85243b2bff79b7904b0ffbec8df5…

and Samba DC rejects it:

Frame 1169: 235 bytes on wire (1880 bits), 235 bytes captured (1880 bits)
Ethernet II, Src: RealtekU_d5:3c:a1 (52:54:00:d5:3c:a1), Dst: HewlettP_e9:9f:62 (80:c1:6e:e9:9f:62)
Internet Protocol Version 4, Src: 192.168.1.100, Dst: 192.168.1.108
Transmission Control Protocol, Src Port: 88, Dst Port: 61801, Seq: 1, Ack: 2524, Len: 181
Kerberos
    Record Mark: 177 bytes
        0... .... .... .... .... .... .... .... = Reserved: Not set
        .000 0000 0000 0000 0000 0000 1011 0001 = Record Length: 177
    krb-error
        pvno: 5
        msg-type: krb-error (30)
        stime: 2019-09-04 21:44:49 (UTC)
        susec: 228030
        error-code: eRR-SERVER-NOMATCH (26)
        crealm: STUDIOMOSCA.NET
        cname
            name-type: kRB5-NT-UNKNOWN (0)
            cname-string: 1 item
                CNameString: PC-JOLLY$
        realm: STUDIOMOSCA.NET
        sname
            name-type: kRB5-NT-ENTERPRISE-PRINCIPAL (10)
            sname-string: 1 item
                SNameString: pc-jolly$@STUDIOMOSCA.NET
        e-text: EVIDENCE_TICKET_MISMATCH


Isaac, this works for embedded Heimdal build in Samba AD DC but fails for MIT. Looks like we lack something here? Can it be something from your recent work on S4U2Proxy?

In Heimdal version (source4/heimdal/kdc/krb5tgs.c) we only do check if validation requested or renewal of the ticket was requested:

tgs_build_reply():
...
    /*
     * Check flags
     */

    ret = kdc_check_flags(context, config,
                          client, cpn,
                          server, spn,
                          FALSE);
    if(ret)
        goto out;

    if((b->kdc_options.validate || b->kdc_options.renew) &&
       !krb5_principal_compare(context,
                               krbtgt->entry.principal,
                               server->entry.principal)){
        kdc_log(context, config, 0, "Inconsistent request.");
        ret = KRB5KDC_ERR_SERVER_NOMATCH;
        goto out;
    }

In MIT Kerberos, in process_tgs_req(), we only process it if the client asked for cname-in-addl-tgt options flag, as required by MS-SFU 3.1.5.2.1:

    if (isflagset(request->kdc_options, KDC_OPT_CNAME_IN_ADDL_TKT)) {
        /* Do constrained delegation protocol and authorization checks */
        errcode = kdc_process_s4u2proxy_req(kdc_active_realm,
                                            request,
                                            request->second_ticket[st_idx]->enc_part2,
                                            stkt_server,
                                            header_ticket->enc_part2->client,
                                            request->server,
                                            &status);
        if (errcode == KDC_ERR_POLICY || errcode == KDC_ERR_BADOPTION)
            au_state->violation = PROT_CONSTRAINT;
        else if (errcode)
            au_state->violation = LOCAL_POLICY;
        au_state->status = status;
        retval = kau_make_tkt_id(kdc_context, request->second_ticket[st_idx],
                                  &au_state->evid_tkt_id);
        if (retval) {
            errcode = retval;
            goto cleanup;
        }
        kau_s4u2proxy(kdc_context, errcode ? FALSE : TRUE, au_state);
        if (errcode)
            goto cleanup;

        setflag(c_flags, KRB5_KDB_FLAG_CONSTRAINED_DELEGATION);

        assert(krb5_is_tgs_principal(header_ticket->server));

        assert(client == NULL); /* assured by kdc_process_s4u2self_req() */
        client = stkt_server;
        stkt_server = NULL;
    } else if (request->kdc_options & KDC_OPT_ENC_TKT_IN_SKEY) {
        krb5_db_free_principal(kdc_context, stkt_server);
        stkt_server = NULL;
    } else
        assert(stkt_server == NULL);


I would say MIT Kerberos does it correctly because it is required by MS-SFU. However, it seems we actually fail here MS-KILE 3.1.5.7 in kdc_process_s4u2proxy_req() where we do 

    /* Ensure that evidence ticket server matches TGT client */
    if (!krb5_principal_compare(kdc_context,
                                server->princ, /* after canon */
                                server_princ)) {
        *status = "EVIDENCE_TICKET_MISMATCH";
        return KRB5KDC_ERR_SERVER_NOMATCH;
    }

MS-KILE 3.1.5.7 says:

Name comparisons, whether for users or domains, MUST NOT be case sensitive in KILE. KILE MUST use UTF-8 encoding of these names [RFC2279]. Normalization MUST NOT be performed and surrogates MUST NOT be supported. To match names, the GetWindowsSortKey algorithm ([MS-UCODEREF] section 3.1.5.2.4) with the following flags NORM_IGNORECASE, NORM_IGNOREKANATYPE, NORM_IGNORENONSPACE, and NORM_IGNOREWIDTH SHOULD be used then the CompareSortKey algorithm ([MS-UCODEREF] section 3.1.5.2.2) SHOULD be used to compare the names.Note that this applies only to names; passwords (and the transformation of a password to a key) are governed by the actual key generation specification ([RFC4120], [RFC4757], and [RFC3962]).

The krb5_principal_compare() in both Heimdal and MIT Kerberos does case-sensitive comparison. So, may be we should replace krb5_principal_compare() here with a call to 

 krb5_principal_compare_flags(kdc_context,
                              server->princ,
                              server_princ,
                              KRB5_PRINCIPAL_COMPARE_CASEFOLD)
?

Dario,

I've built a test version of krb5 to validate my idea. Could you please try

# dnf copr enable abbra/krb5-casefold 
# dnf update

?

Created attachment 1612078 [details]
Log after test copr abbra/krb5-casefold

First of all, thank you for taking the time to analyze the logs and understand what is happening.

Today for me was a hard day at work and I didn't have time to follow this tread, only now I could do the required test

I have install abbra/krb5-casefold copr files

[root@s-addc ~]# dnf copr enable abbra/krb5-casefold
....
Dipendenze risolte.
========================================================================================================================
 Package               Arch        Version                Repository                                               Size
========================================================================================================================
Upgrading:
 krb5-libs             x86_64      1.17-14.1.fc30         copr:copr.fedorainfracloud.org:abbra:krb5-casefold      747 k
 krb5-server           x86_64      1.17-14.1.fc30         copr:copr.fedorainfracloud.org:abbra:krb5-casefold      981 k
 krb5-workstation      x86_64      1.17-14.1.fc30         copr:copr.fedorainfracloud.org:abbra:krb5-casefold      834 k
 libkadm5              x86_64      1.17-14.1.fc30         copr:copr.fedorainfracloud.org:abbra:krb5-casefold       79 k

Riepilogo della transazione
========================================================================================================================
Aggiornati  4 pacchetti

Then I have restart the server, enable samba loggin and do the same previous test (see attach)
Unfortunately the problem still here, none is change.

Hope this help.

Instead, what do you think about nmblookup unresolve name problem?

We had a call with Isaac and he'll work on the patch upstream in krb5 to add a mechanism to compare and retrieve aliased entries for both S4U2Proxy and S4U2Self. 
This is along the needs he also had in https://github.com/krb5/krb5/pull/912

Your test actually shows that his fixes will be needed because two principals we have to compare below need to be compared after canonicalization:

set 05 22:06:38 s-addc.studiomosca.net krb5kdc[1068](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), (-135)}) 192.168.1.108: ISSUE: authtime 1567650936, etypes {rep=DEPRECATED:arcfour-hmac(23), tkt=DEPRECATED:arcfour-hmac(23), ses=DEPRECATED:arcfour-hmac(23)}, PC-JOLLY$@STUDIOMOSCA
.NET for pc-jolly$\@STUDIOMOSCA.NET
set 05 22:06:38 s-addc.studiomosca.net krb5kdc[1068](info): closing down fd 20
set 05 22:06:38 s-addc.studiomosca.net krb5kdc[1068](info): TGS_REQ 192.168.1.108: EVIDENCE_TICKET_MISMATCH: authtime 0, PC-JOLLY$@STUDIOMOSCA.NET for pc-jolly$\@STUDIOMOSCA.NET@STUDIOMOSCA.
NET, 2nd tkt client <unknown>

So, thanks for the test, it actually moves us into the right direction.

Regarding NBT, I think you are already using it -- at least network traces says that the clients are registering against WINS service on S-ADDC.

(In reply to Alexander Bokovoy from comment #23)
> Regarding NBT, I think you are already using it -- at least network traces
> says that the clients are registering against WINS service on S-ADDC.

what do you mean here? (sorry, but I'm not an expert samba devel)

If NBT = nmblookup or WINS; yes, I have enable it into smb.conf for test, but the nmblookup still don't do what it should be (netbios name resolver) on DC.
While it solves them on member servers.

Is also this depend from MitKrb5 ?
Or depend that nmbd is not running?
it's correct, or not, that it is not running?

Many thanks.

Let us first get MIT Kerberos fixed with regards to case-sensitivity of the Kerberos principals comparison in S4U2Proxy case. This affects any attemps to reuse user credentials by the workstation against any other workstation (which is what is done when they try to resolve other machines' resources).

Hi Dario, I'm working on S4U support and aliases and got some working tests, however it is still a long way ahead.
It would be great though if you'd be able to try out development packages once we'd have any.

(In reply to Isaac Boukris from comment #26)
> Hi Dario, I'm working on S4U support and aliases and got some working tests,
> however it is still a long way ahead.
> It would be great though if you'd be able to try out development packages
> once we'd have any.

Yes, i can, and I'm glad to help you to make samba-dc+mit-kbr5 a stable product.

Besides testing it in this existing real environment (making previous snapshots and following restore of virtual machines), if useful, I can setup a test environment with some machine (1 fedora ad-dc + 1 centos7 member server + 2 win10 workstation joined to domain)

Let me know.

If it helps, I'm available to test development packages as well.
Thanks

Hi,

I have built our current work in progress patches to make Samba AD DC working with MIT Kerberos in https://copr.fedorainfracloud.org/coprs/abbra/samba-nodes-test/. This build is for Fedora 31 and includes fixes for https://bugzilla.redhat.com/show_bug.cgi?id=1748860 and https://bugzilla.redhat.com/show_bug.cgi?id=1757071

Please test it by following these instructions on Fedora 31 host:

$ dnf copr enable abbra/samba-nodes-test 
$ dnf install samba-dc
..

Once tested and also accepted to Samba upstream, we can do backports to Fedora 30/31.

(In reply to Alexander Bokovoy from comment #29)
> Hi,
> 
> I have built our current work in progress patches to make Samba AD DC
> working with MIT Kerberos in
> https://copr.fedorainfracloud.org/coprs/abbra/samba-nodes-test/. This build
> is for Fedora 31 and includes fixes for
> https://bugzilla.redhat.com/show_bug.cgi?id=1748860 and
> https://bugzilla.redhat.com/show_bug.cgi?id=1757071
> 
> Please test it by following these instructions on Fedora 31 host:
> 
> $ dnf copr enable abbra/samba-nodes-test 
> $ dnf install samba-dc
> ..
> 
> Once tested and also accepted to Samba upstream, we can do backports to
> Fedora 30/31.

I have test this patch into a Fedora 31 environment used for resolve the deploy samba-dc problem, already resolved with previous patch
(https://bugzilla.redhat.com/show_bug.cgi?id=1757071)

On this scenario I have already add and enable abba's copr repo, then I have do a simple "dnf update" on addc1 and reboot all machine.

PC win10a share to all a c:\public folder

On PC win10b I have do "net use x: \\win10a\public /user:administrator"
and I get "System errore 5. Access Denied"

On PC centos8 same command work:

[root@centos8 ~]# smbclient -mSMB2 //win10a/public -Uadministrator -c ls
Enter MOSCA\administrator's password: 
  .                                   D        0  Mon Sep 30 18:33:48 2019
  ..                                  D        0  Mon Sep 30 18:33:48 2019

                28694783 blocks of size 4096. 24330219 blocks available

I must do some other test?

(In reply to Dario Lesca from comment #30)
> 
> On PC win10b I have do "net use x: \\win10a\public /user:administrator"
> and I get "System errore 5. Access Denied"

Same issue here.
But if I use the IP instead of the name, it works.
net use x: \\192.168.1.100\public /user:administrator

Note that the S4U alias issue isn't expected to be fixed yet, more patches are needed upstream MIT and samba for that.

(In reply to Alexander Bokovoy from comment #29)
> 
> Once tested and also accepted to Samba upstream, we can do backports to
> Fedora 30/31.

Is this patch released in time for fedora 31 release?

(In reply to Isaac Boukris from comment #32)
> Note that the S4U alias issue isn't expected to be fixed yet, more patches
> are needed upstream MIT and samba for that.

Ok, let us know.

(In reply to Isaac Boukris from comment #32)
> Note that the S4U alias issue isn't expected to be fixed yet, more patches
> are needed upstream MIT and samba for that.

hello Isaac, there are some news about this issue?

There are some ways I can help you?

Next Weeks I must setup a new AD-DC and I must to decide which version of samba to use.

In this domain, Win to Win access is not used.

If I use Fedora samba 4.11.x KDC without S4U support, when the patch S4U is released (4.12.x ?), can update samba without problem? 

Let me know
Thanks

Dario,

the work is still in progress upstream. If you need production use, please consider using Heimdal-built version. 
Most likely you'll also need to consider using other distribution for this particular deployment because Fedora 31 did change a system-wide crypto policy to tighten up use of weak crypto.

Next Samba version will have deprecation for weak crypto in both Heimdal and MIT Kerberos build variants but right now Heimdal version might not be fully compatible with Fedora crypto policies too.

Hi, 

Some news about this bug, are planning some news for MIT Kerberos into next 4.12.x samba release?

Thanks for info.

Hi sorry but no, there is still a lot of work to do in both MIT and samba for this.

Dario, meanwhile, could you please try with the current Rawhide packages with krb5 1.18 and samba ad built against it? 

There seems to be a bit of progress with recent krb5 upstream changes as shown in https://bugzilla.samba.org/show_bug.cgi?id=13516 comments by Isaac.

About the GPO issue, I'm interested to know if what I tested in upstream #13516, fails with current fedora. Or if anyone knows of concrete case that's currently failing, and whether if works with heimdal.

btw, we have #1598037 for the gpo issue.

(In reply to Alexander Bokovoy from comment #39)
> Dario, meanwhile, could you please try with the current Rawhide packages
> with krb5 1.18 and samba ad built against it? 
> 
> There seems to be a bit of progress with recent krb5 upstream changes as
> shown in https://bugzilla.samba.org/show_bug.cgi?id=13516 comments by Isaac.

Seem to work!

In a test environment, I have restore a f31 working samba MIT DC, update it to last version of f31 then update it to f32 (rawhide)

At this poin I have join win10a and win10b to domain, share a folder on win10a and access to it from win10b.

All work fine.

I have also try to install a new f32 server but the setup not work (yet).

Next days I do some other test:
a) restore a f31 samba MIT DC, update it to last version of f31, then join win10a and win10b to domain and try a "supposedly not working" win to win access.
Then update f31 to f32 and see if w2w work.
b) install a new f32 samba MIT DC, join win10a and win10b to domain and try w2w access.

I will let you know

Many thanks!
Dario

(In reply to Dario Lesca from comment #41)
> (In reply to Alexander Bokovoy from comment #39)
> > Dario, meanwhile, could you please try with the current Rawhide packages
> > with krb5 1.18 and samba ad built against it? 
> > 
> > There seems to be a bit of progress with recent krb5 upstream changes as
> > shown in https://bugzilla.samba.org/show_bug.cgi?id=13516 comments by Isaac.
> 
> Seem to work!
> 
> In a test environment, I have restore a f31 working samba MIT DC, update it
> to last version of f31 then update it to f32 (rawhide)
> 
> At this poin I have join win10a and win10b to domain, share a folder on
> win10a and access to it from win10b.
> 
> All work fine.

That's good news, although I'll admit I'm a bit confused, as I thought this was about S4U.

I guess this could have been fixed by the krb5 patch that Alexander mentioned (pac-first).

If it is pac-first fix, it should now also should be in Fedora 31 stable updates, via https://bodhi.fedoraproject.org/updates/FEDORA-2020-f5beaa44a6

Today I have try this:

Restore a f31 4 mount old with samba MIT DC working (samba-4.11.0 + krb5-libs-1.17-45)
join 2 new win PC (win10a and win10b) to domain
share on win10a a public folder (everyone full access) 
try access to win10a\public from centos8 member server: work.
try access to win10a\public from win10b NOT work


Take a VM snapshot of F31
Update all to last F31 packages (samba-4.11.6 + krb5-libs-1.17-46) and reboot all
try access to win10a\public from centos8 member server: work.
try access to win10a\public from win10b and magically ... WORK!

Then this problem is resolved with last Fedora 31 update ?

Thanks

Looks like it is. Thank you for confirming!

Closing as CURRENTRELEASE with https://bodhi.fedoraproject.org/updates/FEDORA-2020-f5beaa44a6

(In reply to Alexander Bokovoy from comment #39)
> Dario, meanwhile, could you please try with the current Rawhide packages
> with krb5 1.18 and samba ad built against it? 
> 
> There seems to be a bit of progress with recent krb5 upstream changes as
> shown in https://bugzilla.samba.org/show_bug.cgi?id=13516 comments by Isaac.

Only for close my needinfo request (see https://bugzilla.redhat.com/show_bug.cgi?id=1748860#c41)