Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1836630
Summary: | samba DC: Remote Desktop cannot access from win10 to another win10 with user's domain | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Dario Lesca <d.lesca> |
Component: | samba | Assignee: | Guenther Deschner <gdeschner> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | urgent | Docs Contact: | |
Priority: | unspecified | ||
Version: | 32 | CC: | abokovoy, anoopcs, asn, gdeschner, iboukris, iboukris, jarrpa, jstephen, lmohanty, madam, rharwood, sbose, ssorce, steve |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | samba-4.13.0-13.fc33 samba-4.12.8-1.fc32 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2020-10-28 02:01:56 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Dario Lesca
2020-05-17 14:06:13 UTC
Hi Dario, would you be able to try a test krb5 package, to see if it works for you (from upstream PR #1116)? (In reply to Isaac Boukris from comment #1) > Hi Dario, would you be able to try a test krb5 package, to see if it works > for you (from upstream PR #1116)? I have start my test environment, update my Fedora 32 addc then I have try to access to win10a with domain user administrator ... * from Fedora Linux addc server, with xfreerdp : WORK * from Windows win10b with Remote Desktop : NOT WORK (authenticate panel request) Now these are the packages installed: [root@addc1 ~]# rpm -qa|grep -E '(samba|krb5)'|sort krb5-libs-1.18.2-22.fc32.x86_64 krb5-server-1.18.2-22.fc32.x86_64 krb5-workstation-1.18.2-22.fc32.x86_64 python3-samba-4.12.6-0.fc32.x86_64 python3-samba-dc-4.12.6-0.fc32.x86_64 samba-4.12.6-0.fc32.x86_64 samba-client-4.12.6-0.fc32.x86_64 samba-client-libs-4.12.6-0.fc32.x86_64 samba-common-4.12.6-0.fc32.noarch samba-common-libs-4.12.6-0.fc32.x86_64 samba-common-tools-4.12.6-0.fc32.x86_64 samba-dc-4.12.6-0.fc32.x86_64 samba-dc-bind-dlz-4.12.6-0.fc32.x86_64 samba-dc-libs-4.12.6-0.fc32.x86_64 samba-dc-provision-4.12.6-0.fc32.noarch samba-libs-4.12.6-0.fc32.x86_64 samba-winbind-4.12.6-0.fc32.x86_64 samba-winbind-clients-4.12.6-0.fc32.x86_64 samba-winbind-modules-4.12.6-0.fc32.x86_64 The problem still exist Let me know if I can test something Thanks Dario Dario, we'll build a new package for testing that includes additional fixes. They are not yet in Fedora, so your current result is expected. Stay tuned. Dario, please use $ dnf copr enable abbra/samba-test and update samba/krb5 packages from there. Remember, these are experimental packages, they might cause failures too, so if these are VMs, it would make sense to back them up first. (In reply to Alexander Bokovoy from comment #4) > > and update samba/krb5 packages from there. Remember, these are experimental > packages, they might cause failures too, so if these are VMs, it would make > sense to back them up first. Yeah, especially the samba change is risky, i'm looking into a better fix, but it could still work. I have stop addc server, take a snapshot, start and update: Upgrading: krb5-libs x86_64 1.18.2-23.fc32 copr:copr.fedorainfracloud.org:abbra:samba-test 758 k krb5-server x86_64 1.18.2-23.fc32 copr:copr.fedorainfracloud.org:abbra:samba-test 312 k krb5-workstation x86_64 1.18.2-23.fc32 copr:copr.fedorainfracloud.org:abbra:samba-test 507 k libkadm5 x86_64 1.18.2-23.fc32 copr:copr.fedorainfracloud.org:abbra:samba-test 86 k libsmbclient x86_64 2:4.12.6-1.fc32 copr:copr.fedorainfracloud.org:abbra:samba-test 76 k libwbclient x86_64 2:4.12.6-1.fc32 copr:copr.fedorainfracloud.org:abbra:samba-test 47 k python3-samba x86_64 2:4.12.6-1.fc32 copr:copr.fedorainfracloud.org:abbra:samba-test 3.1 M python3-samba-dc x86_64 2:4.12.6-1.fc32 copr:copr.fedorainfracloud.org:abbra:samba-test 357 k samba x86_64 2:4.12.6-1.fc32 copr:copr.fedorainfracloud.org:abbra:samba-test 795 k samba-client x86_64 2:4.12.6-1.fc32 copr:copr.fedorainfracloud.org:abbra:samba-test 642 k samba-client-libs x86_64 2:4.12.6-1.fc32 copr:copr.fedorainfracloud.org:abbra:samba-test 5.5 M samba-common noarch 2:4.12.6-1.fc32 copr:copr.fedorainfracloud.org:abbra:samba-test 141 k samba-common-libs x86_64 2:4.12.6-1.fc32 copr:copr.fedorainfracloud.org:abbra:samba-test 101 k samba-common-tools x86_64 2:4.12.6-1.fc32 copr:copr.fedorainfracloud.org:abbra:samba-test 423 k samba-dc x86_64 2:4.12.6-1.fc32 copr:copr.fedorainfracloud.org:abbra:samba-test 474 k samba-dc-bind-dlz x86_64 2:4.12.6-1.fc32 copr:copr.fedorainfracloud.org:abbra:samba-test 45 k samba-dc-libs x86_64 2:4.12.6-1.fc32 copr:copr.fedorainfracloud.org:abbra:samba-test 560 k samba-dc-provision noarch 2:4.12.6-1.fc32 copr:copr.fedorainfracloud.org:abbra:samba-test 379 k samba-libs x86_64 2:4.12.6-1.fc32 copr:copr.fedorainfracloud.org:abbra:samba-test 97 k samba-winbind x86_64 2:4.12.6-1.fc32 copr:copr.fedorainfracloud.org:abbra:samba-test 505 k samba-winbind-clients x86_64 2:4.12.6-1.fc32 copr:copr.fedorainfracloud.org:abbra:samba-test 79 k samba-winbind-modules x86_64 2:4.12.6-1.fc32 copr:copr.fedorainfracloud.org:abbra:samba-test 53 k Then I have reboot and test: Seem to work! I have log into win10b with domain fedora.loc user "administrator" If I try from win10b connect to win10a with remote desktop app using user "administrator" do NOT work. if I use the user "administrator" WORK! If I memorize the password when I login with "administrator" and try to connect with user "administrator" WORK I do not know if this behaviour is the same of a Microsoft ADDC or not ... let me know. But .... If I try to access from centos8 (storage domain member server) to centos8 (it self) with this samba version: [root@centos8 ~]# rpm -q samba samba-4.11.2-13.el8.x86_64 or access from centos8 to addc1 I get this error: [root@centos8 ~]# smbclient -L centos8.fedora.loc -Uadministrator Enter administrator's password: gse_get_client_auth_token: gss_init_sec_context failed with [Unspecified GSS failure. Minor code may provide more information: Matching credential not found](2529639053) gensec_spnego_client_negTokenInit_step: gse_krb5: creating NEG_TOKEN_INIT for cifs/centos8.fedora.loc failed (next[(null)]): NT_STATUS_LOGON_FAILURE session setup failed: NT_STATUS_LOGON_FAILURE [root@centos8 ~]# smbclient -L addc1.fedora.loc -Uadministrator Enter administrator's password: gse_get_client_auth_token: gss_init_sec_context failed with [Unspecified GSS failure. Minor code may provide more information: Matching credential not found](2529639053) gensec_spnego_client_negTokenInit_step: gse_krb5: creating NEG_TOKEN_INIT for cifs/addc1.fedora.loc failed (next[(null)]): NT_STATUS_LOGON_FAILURE session setup failed: NT_STATUS_LOGON_FAILURE Also from win10b I cannot access to \\centos8\ Then I have revert the addc1 snapshot to previous version and retray centos8 cannot access with another error (not the same) I have try to rejoin centos8 to domain with ... [root@centos8 ~]# net ads join -U administrator Retry to access from centos8 to centos8 and addc1 and..... IT WORK! ... also from win10a/b IT WORK I have also retry from win10b to access to win10a with R.D. and ... not work as I expect. Then I have rerun "dnf copr enable abbra/samba-test", update samba/krb5, reboot and retray all: centos8 cannot access with same previus error (see follow debug 9)[1] BUT, if I use only user "administrator" (without @fedora.loc) IT WORK try R.D. from win10b to win10a: IT WORK ... but I must retype administrator password as previous test. try \\centos8 from win10b and IT WORK. in conclusion seem the patch WORK, with some other things to be clarified let me know if you want some other test. Many Thanks Dario [1] access centos8 to centos8 [root@centos8 ~]# smbclient -L centos8.fedora.loc -Uadministrator -d9 INFO: Current debug levels: all: 9 tdb: 9 printdrivers: 9 lanman: 9 smb: 9 rpc_parse: 9 rpc_srv: 9 rpc_cli: 9 passdb: 9 sam: 9 auth: 9 winbind: 9 vfs: 9 idmap: 9 quota: 9 acls: 9 locking: 9 msdfs: 9 dmapi: 9 registry: 9 scavenger: 9 dns: 9 ldb: 9 tevent: 9 auth_audit: 9 auth_json_audit: 9 kerberos: 9 drs_repl: 9 smb2: 9 smb2_credits: 9 dsdb_audit: 9 dsdb_json_audit: 9 dsdb_password_audit: 9 dsdb_password_json_audit: 9 dsdb_transaction_audit: 9 dsdb_transaction_json_audit: 9 dsdb_group_audit: 9 dsdb_group_json_audit: 9 lp_load_ex: refreshing parameters Initialising global parameters rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384) INFO: Current debug levels: all: 9 tdb: 9 printdrivers: 9 lanman: 9 smb: 9 rpc_parse: 9 rpc_srv: 9 rpc_cli: 9 passdb: 9 sam: 9 auth: 9 winbind: 9 vfs: 9 idmap: 9 quota: 9 acls: 9 locking: 9 msdfs: 9 dmapi: 9 registry: 9 scavenger: 9 dns: 9 ldb: 9 tevent: 9 auth_audit: 9 auth_json_audit: 9 kerberos: 9 drs_repl: 9 smb2: 9 smb2_credits: 9 dsdb_audit: 9 dsdb_json_audit: 9 dsdb_password_audit: 9 dsdb_password_json_audit: 9 dsdb_transaction_audit: 9 dsdb_transaction_json_audit: 9 dsdb_group_audit: 9 dsdb_group_json_audit: 9 Processing section "[global]" doing parameter workgroup = FEDORA doing parameter realm = FEDORA.LOC doing parameter security = ADS doing parameter idmap config * : backend = tdb doing parameter idmap config * : range = 10000-99999 doing parameter idmap config FEDORA:schema_mode = rfc2307 doing parameter idmap config FEDORA:range = 1000000-3000000 doing parameter idmap config FEDORA:backend = rid doing parameter template homedir = /u/samba/home/%U doing parameter template shell = /bin/bash doing parameter kerberos method = secrets only doing parameter winbind use default domain = true doing parameter winbind offline logon = true doing parameter passdb backend = tdbsam doing parameter printing = cups doing parameter printcap name = cups doing parameter load printers = yes doing parameter cups options = raw doing parameter rpc_server:spoolss = external doing parameter rpc_daemon:spoolssd = fork doing parameter winbind enum users = yes doing parameter winbind enum groups = yes doing parameter vfs objects = acl_xattr doing parameter map acl inherit = yes doing parameter store dos attributes = yes doing parameter acl allow execute always = True pm_process() returned Yes lp_servicenumber: couldn't find homes Registering messaging pointer for type 2 - private_data=(nil) Registering messaging pointer for type 9 - private_data=(nil) Registered MSG_REQ_POOL_USAGE Registering messaging pointer for type 11 - private_data=(nil) Registering messaging pointer for type 12 - private_data=(nil) Registered MSG_REQ_DMALLOC_MARK and LOG_CHANGED Registering messaging pointer for type 1 - private_data=(nil) Registering messaging pointer for type 5 - private_data=(nil) Registering messaging pointer for type 51 - private_data=(nil) lp_load_ex: refreshing parameters Freeing parametrics: Initialising global parameters rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384) INFO: Current debug levels: all: 9 tdb: 9 printdrivers: 9 lanman: 9 smb: 9 rpc_parse: 9 rpc_srv: 9 rpc_cli: 9 passdb: 9 sam: 9 auth: 9 winbind: 9 vfs: 9 idmap: 9 quota: 9 acls: 9 locking: 9 msdfs: 9 dmapi: 9 registry: 9 scavenger: 9 dns: 9 ldb: 9 tevent: 9 auth_audit: 9 auth_json_audit: 9 kerberos: 9 drs_repl: 9 smb2: 9 smb2_credits: 9 dsdb_audit: 9 dsdb_json_audit: 9 dsdb_password_audit: 9 dsdb_password_json_audit: 9 dsdb_transaction_audit: 9 dsdb_transaction_json_audit: 9 dsdb_group_audit: 9 dsdb_group_json_audit: 9 Processing section "[global]" doing parameter workgroup = FEDORA doing parameter realm = FEDORA.LOC doing parameter security = ADS doing parameter idmap config * : backend = tdb doing parameter idmap config * : range = 10000-99999 doing parameter idmap config FEDORA:schema_mode = rfc2307 doing parameter idmap config FEDORA:range = 1000000-3000000 doing parameter idmap config FEDORA:backend = rid doing parameter template homedir = /u/samba/home/%U doing parameter template shell = /bin/bash doing parameter kerberos method = secrets only doing parameter winbind use default domain = true doing parameter winbind offline logon = true doing parameter passdb backend = tdbsam doing parameter printing = cups doing parameter printcap name = cups doing parameter load printers = yes doing parameter cups options = raw doing parameter rpc_server:spoolss = external doing parameter rpc_daemon:spoolssd = fork doing parameter winbind enum users = yes doing parameter winbind enum groups = yes doing parameter vfs objects = acl_xattr doing parameter map acl inherit = yes doing parameter store dos attributes = yes doing parameter acl allow execute always = True pm_process() returned Yes lp_servicenumber: couldn't find homes added interface ens3 ip=192.168.122.11 bcast=192.168.122.255 netmask=255.255.255.0 Netbios name list:- my_netbios_names[0]="CENTOS8" Client started (version 4.11.2). Opening cache file at /var/lib/samba/lock/gencache.tdb sitename_fetch: Returning sitename for realm 'FEDORA.LOC': "Default-First-Site-Name" name centos8.fedora.loc#20 found. Connecting to 192.168.122.11 at port 445 Socket options: SO_KEEPALIVE = 0 SO_REUSEADDR = 0 SO_BROADCAST = 0 TCP_NODELAY = 1 TCP_KEEPCNT = 9 TCP_KEEPIDLE = 7200 TCP_KEEPINTVL = 75 IPTOS_LOWDELAY = 0 IPTOS_THROUGHPUT = 0 SO_REUSEPORT = 0 SO_SNDBUF = 2626560 SO_RCVBUF = 1061296 SO_SNDLOWAT = 1 SO_RCVLOWAT = 1 SO_SNDTIMEO = 0 SO_RCVTIMEO = 0 TCP_QUICKACK = 1 TCP_DEFER_ACCEPT = 0 session request ok negotiated dialect[SMB3_11] against server[centos8.fedora.loc] Enter administrator's password: cli_session_creds_prepare_krb5: Doing kinit for administrator to access centos8.fedora.loc cli_session_setup_spnego_send: Connect to centos8.fedora.loc as Administrator using SPNEGO GENSEC backend 'gssapi_spnego' registered GENSEC backend 'gssapi_krb5' registered GENSEC backend 'gssapi_krb5_sasl' registered GENSEC backend 'spnego' registered GENSEC backend 'schannel' registered GENSEC backend 'naclrpc_as_system' registered GENSEC backend 'sasl-EXTERNAL' registered GENSEC backend 'ntlmssp' registered GENSEC backend 'ntlmssp_resume_ccache' registered GENSEC backend 'http_basic' registered GENSEC backend 'http_ntlm' registered GENSEC backend 'http_negotiate' registered Starting GENSEC mechanism spnego Starting GENSEC submechanism gse_krb5 gse_get_client_auth_token: gss_init_sec_context failed with [Unspecified GSS failure. Minor code may provide more information: Matching credential not found](2529639053) gensec_update_done: gse_krb5[0x55c780359970]: NT_STATUS_LOGON_FAILURE gensec_spnego_client_negTokenInit_step: gse_krb5: creating NEG_TOKEN_INIT for cifs/centos8.fedora.loc failed (next[(null)]): NT_STATUS_LOGON_FAILURE gensec_update_done: spnego[0x55c78034d900]: NT_STATUS_LOGON_FAILURE SPNEGO login failed: The attempted logon is invalid. This is either due to a bad username or authentication information. session setup failed: NT_STATUS_LOGON_FAILURE (In reply to Dario Lesca from comment #6) > > Then I have reboot and test: > > Seem to work! > > I have log into win10b with domain fedora.loc user "administrator" > > If I try from win10b connect to win10a with remote desktop app using user > "administrator" do NOT work. Alexander is adding a new samba version to the repo, so please try again in ~20 minutes. If it still doesn't work, please collect the mit_kdc.log file as well (and packet capture if possible, you can email me). > if I use the user "administrator" WORK! > > If I memorize the password when I login with "administrator" and > try to connect with user "administrator" WORK > > I do not know if this behaviour is the same of a Microsoft ADDC or not ... > let me know. > > But .... > > If I try to access from centos8 (storage domain member server) to centos8 > (it self) with this samba version: > [root@centos8 ~]# rpm -q samba > samba-4.11.2-13.el8.x86_64 > > or access from centos8 to addc1 I get this error: > > [root@centos8 ~]# smbclient -L centos8.fedora.loc -Uadministrator > Enter administrator's password: > gse_get_client_auth_token: gss_init_sec_context failed with [Unspecified GSS > failure. Minor code may provide more information: Matching credential not > found](2529639053) > gensec_spnego_client_negTokenInit_step: gse_krb5: creating NEG_TOKEN_INIT > for cifs/centos8.fedora.loc failed (next[(null)]): NT_STATUS_LOGON_FAILURE > session setup failed: NT_STATUS_LOGON_FAILURE > > [root@centos8 ~]# smbclient -L addc1.fedora.loc -Uadministrator > Enter administrator's password: > gse_get_client_auth_token: gss_init_sec_context failed with [Unspecified GSS > failure. Minor code may provide more information: Matching credential not > found](2529639053) > gensec_spnego_client_negTokenInit_step: gse_krb5: creating NEG_TOKEN_INIT > for cifs/addc1.fedora.loc failed (next[(null)]): NT_STATUS_LOGON_FAILURE > session setup failed: NT_STATUS_LOGON_FAILURE > > Also from win10b I cannot access to \\centos8\ I can't reproduce it, so hopefully the new samba package would solve it, otherwise as above, please collect the mit_kdc.log file as well (and packet capture if possible), and also prefix the smbclient command with KRB5_TRACE=/dev/stderr to get more debug info. > Then I have revert the addc1 snapshot to previous version and retray > > centos8 cannot access with another error (not the same) > > I have try to rejoin centos8 to domain with ... > > [root@centos8 ~]# net ads join -U administrator > > Retry to access from centos8 to centos8 and addc1 and..... IT WORK! ... also > from win10a/b IT WORK When you go back to a snapshot you may need to rejoin since the machine account might have changed. Upgrading: libsmbclient x86_64 2:4.12.6-2.fc32 copr:copr.fedorainfracloud.org:abbra:samba-test 76 k libwbclient x86_64 2:4.12.6-2.fc32 copr:copr.fedorainfracloud.org:abbra:samba-test 46 k linux-firmware noarch 20200918-112.fc32 updates 99 M linux-firmware-whence noarch 20200918-112.fc32 updates 36 k mesa-libEGL x86_64 20.1.8-1.fc32 updates 126 k mesa-libGL x86_64 20.1.8-1.fc32 updates 184 k mesa-libgbm x86_64 20.1.8-1.fc32 updates 46 k mesa-libglapi x86_64 20.1.8-1.fc32 updates 58 k python3-samba x86_64 2:4.12.6-2.fc32 copr:copr.fedorainfracloud.org:abbra:samba-test 3.1 M python3-samba-dc x86_64 2:4.12.6-2.fc32 copr:copr.fedorainfracloud.org:abbra:samba-test 357 k samba x86_64 2:4.12.6-2.fc32 copr:copr.fedorainfracloud.org:abbra:samba-test 795 k samba-client x86_64 2:4.12.6-2.fc32 copr:copr.fedorainfracloud.org:abbra:samba-test 642 k samba-client-libs x86_64 2:4.12.6-2.fc32 copr:copr.fedorainfracloud.org:abbra:samba-test 5.5 M samba-common noarch 2:4.12.6-2.fc32 copr:copr.fedorainfracloud.org:abbra:samba-test 141 k samba-common-libs x86_64 2:4.12.6-2.fc32 copr:copr.fedorainfracloud.org:abbra:samba-test 100 k samba-common-tools x86_64 2:4.12.6-2.fc32 copr:copr.fedorainfracloud.org:abbra:samba-test 423 k samba-dc x86_64 2:4.12.6-2.fc32 copr:copr.fedorainfracloud.org:abbra:samba-test 474 k samba-dc-bind-dlz x86_64 2:4.12.6-2.fc32 copr:copr.fedorainfracloud.org:abbra:samba-test 45 k samba-dc-libs x86_64 2:4.12.6-2.fc32 copr:copr.fedorainfracloud.org:abbra:samba-test 561 k samba-dc-provision noarch 2:4.12.6-2.fc32 copr:copr.fedorainfracloud.org:abbra:samba-test 379 k samba-libs x86_64 2:4.12.6-2.fc32 copr:copr.fedorainfracloud.org:abbra:samba-test 97 k samba-winbind x86_64 2:4.12.6-2.fc32 copr:copr.fedorainfracloud.org:abbra:samba-test 506 k samba-winbind-clients x86_64 2:4.12.6-2.fc32 copr:copr.fedorainfracloud.org:abbra:samba-test 79 k samba-winbind-modules x86_64 2:4.12.6-2.fc32 copr:copr.fedorainfracloud.org:abbra:samba-test 53 k After upgrade and reboot I have do these tests: With Remote Desktop from win10b to win10a - with user domain "administrator" (a win10b user's), get a password request and: NOT WORK if I do not type doamin name - with "administrator", get a password request then IT WORK - with user "ospite" (a normal user and not a win10b user's), get a password request then IT WORK - with user "ospite", get a password request then IT WORK I get always password request, before to connect, and if I use a local account (administrator), I must type also domain. See follow mit_kdc.log, take when I connect with user "ospite" (after I grant on woin10a R.D. access). When I try to connect to win10a the password is requested but on addc1 server, none is log into file before password request, all this log are show after password request. I have try to tcpdump the network traffic, and also with this monitor, none is show previous password request. I do not know if this is a normal Windows bheaviour or not.... but it work after type correct password! All other test from or to centos8 or addc1 from centos8 or win10* IT WORK and the previous error it doesn't happen anymore. Let me know if I do some other tests Many Thanks to all. [root@addc1 samba]# cat /tmp/mit_kdc.log set 21 20:33:10 addc1.fedora.loc krb5kdc[741](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: ospite@FEDORA for krbtgt/FEDORA@FEDORA, Additional pre-authentication required set 21 20:33:10 addc1.fedora.loc krb5kdc[741](info): closing down fd 19 set 21 20:33:10 addc1.fedora.loc krb5kdc[741](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 1600713190, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)}, ospite@FEDORA for krbtgt/FEDORA@FEDORA set 21 20:33:10 addc1.fedora.loc krb5kdc[741](info): closing down fd 19 set 21 20:33:10 addc1.fedora.loc krb5kdc[741](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 1600713190, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)}, ospite for WIN10A$@FEDORA.LOC set 21 20:33:10 addc1.fedora.loc krb5kdc[741](info): closing down fd 19 set 21 20:33:11 addc1.fedora.loc krb5kdc[741](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 1600713190, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)}, ospite for WIN10A$@FEDORA.LOC set 21 20:33:11 addc1.fedora.loc krb5kdc[741](info): closing down fd 19 set 21 20:33:14 addc1.fedora.loc krb5kdc[741](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.103: NEEDED_PREAUTH: ospite for krbtgt/FEDORA.LOC, Additional pre-authentication required set 21 20:33:14 addc1.fedora.loc krb5kdc[741](info): closing down fd 19 set 21 20:33:14 addc1.fedora.loc krb5kdc[741](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.103: ISSUE: authtime 1600713194, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)}, ospite for krbtgt/FEDORA.LOC set 21 20:33:15 addc1.fedora.loc krb5kdc[741](info): closing down fd 19 set 21 20:33:15 addc1.fedora.loc krb5kdc[741](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.103: ISSUE: authtime 1600713194, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)}, ospite for WIN10A$@FEDORA.LOC set 21 20:33:15 addc1.fedora.loc krb5kdc[741](info): closing down fd 19 (In reply to Dario Lesca from comment #8) > > After upgrade and reboot I have do these tests: > > With Remote Desktop from win10b to win10a > - with user domain "administrator" (a win10b user's), get a password > request and: NOT WORK if I do not type doamin name > - with "administrator", get a password request then IT WORK > - with user "ospite" (a normal user and not a win10b user's), get a > password request then IT WORK > - with user "ospite", get a password request then IT WORK > > I get always password request, before to connect, and if I use a local > account (administrator), I must type also domain. Yeah it sounds like it tries the local account first, I guess it would the same with Windows DC. > See follow mit_kdc.log, take when I connect with user "ospite" (after I > grant on woin10a R.D. access). > When I try to connect to win10a the password is requested but on addc1 > server, none is log into file before password request, all this log are show > after password request. > I have try to tcpdump the network traffic, and also with this monitor, none > is show previous password request. > > I do not know if this is a normal Windows bheaviour or not.... but it work > after type correct password! > > All other test from or to centos8 or addc1 from centos8 or win10* IT WORK > and the previous error it doesn't happen anymore. That's good, thanks for all the tests. Is this likely to be pushed as an update soon? (This appears to have fixed the same issue for me.) Per out-of-band request, I've updated krb5: - f34: krb5-1.18.2-27.fc34 - f33: https://bodhi.fedoraproject.org/updates/FEDORA-2020-7ff48016a5 - f32: https://bodhi.fedoraproject.org/updates/FEDORA-2020-939681213a I believe samba plans to update tomorrow. New samba packages are being built right now. I'll update krb5 bodhi requests to include them together. FEDORA-2020-939681213a has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-939681213a FEDORA-2020-7ff48016a5 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-7ff48016a5 FEDORA-2020-7ff48016a5 has been pushed to the Fedora 33 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-7ff48016a5` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-7ff48016a5 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2020-939681213a has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-939681213a` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-939681213a See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2020-7ff48016a5 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-7ff48016a5 FEDORA-2020-7ff48016a5 has been pushed to the Fedora 33 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-7ff48016a5` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-7ff48016a5 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2020-7ff48016a5 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-2020-939681213a has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report. |