thr3ads.net - samba - [Samba] Problem to access from Win to Win after classicupdate to Samba DC 4.10.7 [Sep 2019]

If this information is useful, please help other people find it:
Share via:

Dario Lesca

2019-Sep-02 10:04 UTC

[Samba] Problem to access from Win to Win after classicupdate to Samba DC 4.10.7

Il giorno lun, 02/09/2019 alle 08.26 +0100, Rowland penny via samba ha
scritto:> > set 01 22:36:56 s-addc.studiomosca.net named[639]: samba_dlz:
> > cancelling transaction on zone studiomosca.net
> 
> That is showing that a client isn't being allowed to update a record.
Is it possible to cure it in some way?
> > [2] ----[smb.conf]
> > 
> Please do not post the output of 'testparm'
[root at s-addc samba]# cat /etc/samba/smb.conf
# Global parameters
[global]
        netbios name = S-ADDC
        realm = STUDIOMOSCA.NET
        server role = active directory domain controller
        server services = s3fs, rpc, nbt, wrepl, ldap, cldap, kdc, drepl,
winbindd, ntp_signd, kcc, dnsupdate
        workgroup = STUDIO_MOSCA
        idmap_ldb:use rfc2307 = yes
        template shell = /bin/bash
        template homedir = /home/%U

[sysvol]
        path = /var/lib/samba/sysvol
        read only = No

[netlogon]
        path = /var/lib/samba/sysvol/studiomosca.net/scripts
        read only = No

> Try checking that apparmor isn't getting in the way (if it is
> installed).
No apparmor but SElinux, and it's disable.
> Check if a firewall is blocking a port.
May be, the firewalld is enable and it's possible that must open some
other port...
This is the port witch I have open:

  182  firewall-cmd --permanent
--add-service={samba,samba-dc,dns,dhcp,kerberos,kpasswd,ldap,ldaps,ntp}
  183  firewall-cmd --permanent
--add-port={135/tcp,137-138/udp,139/tcp,3268-3269/tcp,49152-65535/tcp}
  184  firewall-cmd --reload

Then now the port open are that[1]

The system is a Fedora 30 Server with default samba out of the box.
Then yes, it's a krb5kdc (mit_kdc). I hope this is not a problem for
this ml, otherwise let me know where I can post my question.

I have look into mit_kdc.log and I have see this recurred lament, (that
I don't know what it means and whether it is important or not):

set 02 11:54:36 s-addc.studiomosca.net krb5kdc[6764](info): preauth
(encrypted_timestamp) verify failure: Preauthentication failed
set 02 11:54:36 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 at STUDIO_MOSCA, Preauthentication failed
set 02 11:54:36 s-addc.studiomosca.net krb5kdc[6764](info): closing down fd 20
set 02 11:54:36 s-addc.studiomosca.net krb5kdc[6764](info): preauth
(encrypted_timestamp) verify failure: Preauthentication failed
set 02 11:54:36 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 at STUDIO_MOSCA, Preauthentication failed
set 02 11:54:36 s-addc.studiomosca.net krb5kdc[6764](info): closing down fd 20

But for now, apart the win-to-win problem in the subject, all seem workfine. 

Thanks for help

[1] iptables-save
....
....
-A IN_public_allow -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW,UNTRACKED
-j ACCEPT
-A IN_public_allow -d 224.0.0.251/32 -p udp -m udp --dport 5353 -m conntrack
--ctstate NEW,UNTRACKED -j ACCEPT
-A IN_public_allow -p udp -m udp --dport 137 -m conntrack --ctstate
NEW,UNTRACKED -j ACCEPT
-A IN_public_allow -p udp -m udp --dport 138 -m conntrack --ctstate
NEW,UNTRACKED -j ACCEPT
-A IN_public_allow -p tcp -m tcp --dport 139 -m conntrack --ctstate
NEW,UNTRACKED -j ACCEPT
-A IN_public_allow -p tcp -m tcp --dport 445 -m conntrack --ctstate
NEW,UNTRACKED -j ACCEPT
-A IN_public_allow -p tcp -m tcp --dport 53 -m conntrack --ctstate NEW,UNTRACKED
-j ACCEPT
-A IN_public_allow -p udp -m udp --dport 53 -m conntrack --ctstate NEW,UNTRACKED
-j ACCEPT
-A IN_public_allow -p tcp -m tcp --dport 88 -m conntrack --ctstate NEW,UNTRACKED
-j ACCEPT
-A IN_public_allow -p udp -m udp --dport 88 -m conntrack --ctstate NEW,UNTRACKED
-j ACCEPT
-A IN_public_allow -p tcp -m tcp --dport 135 -m conntrack --ctstate
NEW,UNTRACKED -j ACCEPT
-A IN_public_allow -p udp -m udp --dport 137 -m conntrack --ctstate
NEW,UNTRACKED -j ACCEPT
-A IN_public_allow -p udp -m udp --dport 138 -m conntrack --ctstate
NEW,UNTRACKED -j ACCEPT
-A IN_public_allow -p tcp -m tcp --dport 139 -m conntrack --ctstate
NEW,UNTRACKED -j ACCEPT
-A IN_public_allow -p tcp -m tcp --dport 389 -m conntrack --ctstate
NEW,UNTRACKED -j ACCEPT
-A IN_public_allow -p udp -m udp --dport 389 -m conntrack --ctstate
NEW,UNTRACKED -j ACCEPT
-A IN_public_allow -p tcp -m tcp --dport 445 -m conntrack --ctstate
NEW,UNTRACKED -j ACCEPT
-A IN_public_allow -p tcp -m tcp --dport 464 -m conntrack --ctstate
NEW,UNTRACKED -j ACCEPT
-A IN_public_allow -p udp -m udp --dport 464 -m conntrack --ctstate
NEW,UNTRACKED -j ACCEPT
-A IN_public_allow -p tcp -m tcp --dport 636 -m conntrack --ctstate
NEW,UNTRACKED -j ACCEPT
-A IN_public_allow -p tcp -m tcp --dport 49152:65535 -m conntrack --ctstate
NEW,UNTRACKED -j ACCEPT
-A IN_public_allow -p tcp -m tcp --dport 3268 -m conntrack --ctstate
NEW,UNTRACKED -j ACCEPT
-A IN_public_allow -p tcp -m tcp --dport 3269 -m conntrack --ctstate
NEW,UNTRACKED -j ACCEPT
-A IN_public_allow -p tcp -m tcp --dport 53 -m conntrack --ctstate NEW,UNTRACKED
-j ACCEPT
-A IN_public_allow -p udp -m udp --dport 53 -m conntrack --ctstate NEW,UNTRACKED
-j ACCEPT
-A IN_public_allow -p udp -m udp --dport 67 -m conntrack --ctstate NEW,UNTRACKED
-j ACCEPT
-A IN_public_allow -p tcp -m tcp --dport 88 -m conntrack --ctstate NEW,UNTRACKED
-j ACCEPT
-A IN_public_allow -p udp -m udp --dport 88 -m conntrack --ctstate NEW,UNTRACKED
-j ACCEPT
-A IN_public_allow -p tcp -m tcp --dport 464 -m conntrack --ctstate
NEW,UNTRACKED -j ACCEPT
-A IN_public_allow -p udp -m udp --dport 464 -m conntrack --ctstate
NEW,UNTRACKED -j ACCEPT
-A IN_public_allow -p tcp -m tcp --dport 389 -m conntrack --ctstate
NEW,UNTRACKED -j ACCEPT
-A IN_public_allow -p tcp -m tcp --dport 636 -m conntrack --ctstate
NEW,UNTRACKED -j ACCEPT
-A IN_public_allow -p udp -m udp --dport 123 -m conntrack --ctstate
NEW,UNTRACKED -j ACCEPT
-A IN_public_allow -p tcp -m tcp --dport 873 -m conntrack --ctstate
NEW,UNTRACKED -j ACCEPT
-A IN_public_allow -p udp -m udp --dport 873 -m conntrack --ctstate
NEW,UNTRACKED -j ACCEPT
-A IN_public_allow -p tcp -m tcp --dport 135 -m conntrack --ctstate
NEW,UNTRACKED -j ACCEPT
-A IN_public_allow -p udp -m udp --dport 137:138 -m conntrack --ctstate
NEW,UNTRACKED -j ACCEPT
-A IN_public_allow -p tcp -m tcp --dport 139 -m conntrack --ctstate
NEW,UNTRACKED -j ACCEPT
-A IN_public_allow -p tcp -m tcp --dport 3268:3269 -m conntrack --ctstate
NEW,UNTRACKED -j ACCEPT
-A IN_public_allow -p tcp -m tcp --dport 49152:65535 -m conntrack --ctstate
NEW,UNTRACKED -j ACCEPT

-- 
Dario Lesca
(inviato dal mio Linux Fedora 30 Workstation)

Rowland penny

2019-Sep-02 10:24 UTC

head link

[Samba] Problem to access from Win to Win after classicupdate to Samba DC 4.10.7

On 02/09/2019 11:04, Dario Lesca via samba wrote:> Il giorno lun, 02/09/2019 alle 08.26 +0100, Rowland penny via samba ha
> scritto:
> Is it possible to cure it in some way?
>
>>> [2] ----[smb.conf]
>>>
>> Please do not post the output of 'testparm'
> [root at s-addc samba]# cat /etc/samba/smb.conf
> # Global parameters
> [global]
>          netbios name = S-ADDC
>          realm = STUDIOMOSCA.NET
>          server role = active directory domain controller
>          server services = s3fs, rpc, nbt, wrepl, ldap, cldap, kdc, drepl,
winbindd, ntp_signd, kcc, dnsupdate
>          workgroup = STUDIO_MOSCA
>          idmap_ldb:use rfc2307 = yes
>          template shell = /bin/bash
>          template homedir = /home/%U
>
> [sysvol]
>          path = /var/lib/samba/sysvol
>          read only = No
>
> [netlogon]
>          path = /var/lib/samba/sysvol/studiomosca.net/scripts
>          read only = No
>
>
> May be, the firewalld is enable and it's possible that must open some
> other port...
> This is the port witch I have open:
>
>    182  firewall-cmd --permanent
--add-service={samba,samba-dc,dns,dhcp,kerberos,kpasswd,ldap,ldaps,ntp}
>    183  firewall-cmd --permanent
--add-port={135/tcp,137-138/udp,139/tcp,3268-3269/tcp,49152-65535/tcp}
>    184  firewall-cmd --reload
>
> Then now the port open are that[1]The ports seem okay, but try turning the firewall off, if it starts 
working, then you know where to look ;-)>
> The system is a Fedora 30 Server with default samba out of the box.
> Then yes, it's a krb5kdc (mit_kdc). I hope this is not a problem for
> this ml, otherwise let me know where I can post my question.
Well, it isn't a problem for this mailing list, but it could be a 
problem for you. Using MIT with a Samba AD DC is still experimental, you 
should not run it in production. There are numerous things that do not 
work, or give problems and you might have found another one.

>
> I have look into mit_kdc.log and I have see this recurred lament, (that
> I don't know what it means and whether it is important or not):
>
> set 02 11:54:36 s-addc.studiomosca.net krb5kdc[6764](info): preauth
(encrypted_timestamp) verify failure: Preauthentication failed
> set 02 11:54:36 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 at STUDIO_MOSCA, Preauthentication failed
> set 02 11:54:36 s-addc.studiomosca.net krb5kdc[6764](info): closing down fd
20
> set 02 11:54:36 s-addc.studiomosca.net krb5kdc[6764](info): preauth
(encrypted_timestamp) verify failure: Preauthentication failed
> set 02 11:54:36 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 at STUDIO_MOSCA, Preauthentication failed
> set 02 11:54:36 s-addc.studiomosca.net krb5kdc[6764](info): closing down fd
20
>
> But for now, apart the win-to-win problem in the subject, all seem
workfine.
>
> Thanks for help
>Kerberos problems due to using MIT ?????

Rowland

Dario Lesca

2019-Sep-03 09:38 UTC

head link

[Samba] Problem to access from Win to Win after classicupdate to Samba DC 4.10.7

Il giorno lun, 02/09/2019 alle 11.24 +0100, Rowland penny via samba ha
scritto:> Kerberos problems due to using MIT ?????
Ok, thank Rowland, I have move my problem on Fedora Devel ML.
https://lists.fedoraproject.org/archives/list/devel at
lists.fedoraproject.org/thread/LW3XIRWLZ5E3C2P263H4OVO3I6UQPNTQ/

The question now is. Fedora/Redhat Samba DC-MIT have a future? 
And I think this answer should not be given by samba team: samba team
has chosen Heimdal KDC


Thanks.


-- 
Dario Lesca
(inviato dal mio Linux Fedora 30 Workstation)

Maybe Matching Threads

Search for more apparently analagous threads

samba - Sep 2019 - Problem to access from Win to Win after classicupdate to Samba DC 4.10.7

[Samba] Problem to access from Win to Win after classicupdate to Samba DC 4.10.7

[Samba] Problem to access from Win to Win after classicupdate to Samba DC 4.10.7

[Samba] Problem to access from Win to Win after classicupdate to Samba DC 4.10.7

Maybe Matching Threads