Dario Lesca
2019-Sep-01 22:44 UTC
[Samba] Problem to access from Win to Win after classicupdate to Samba DC 4.10.7
I have do a classicupdate from a NT4 style domain to Samba DC 4.10.7
BIND_DLZ without (apparently) problem
All seem work fine, access to PC work, join or re-join a PC to domain
work, access from a Linux samba member server to Win7 PC work, access
from Win7 to samba member server work.
But I cannot access from a PC with win7 to another PC with win7.
If I try to access from win7-0 to win7-1 via "\\win7-1\" I get a error
message of Insufficient Right to access.
Another strange thing that happens is that I don't see any PC browsing
the net
If I try to access via IP of win-7-1 (es: \\10.1.1.1\) I see and can
access to shared folder, but I do not have the right access to
read/write into it.
The name of PC to which I connect it is into DNS an it's resolve
correctly the IP.
I have try to remove this PC from domain and rejoin it, but none is
change.
When I join to domain (or if I run "ipconfig /registerdns" on joined
PC) I get this error[1] into syslog (is the name ending with
"$" correct ?)
If I run RSAT tools on a Win7 I can see and modify all object of the
domain (user, group, computer, ecc)
This problem occurs with all PC: all can access to two new samba member
server, but they cannot access to other windows
Before classicupdate these problems did not occur and all worked fine.
This[2] is the smb.conf of AD-DC:
Some one have some suggest how to debug this issue?
If I missing some information, let me know.
Many thanks.
Dario
[1] ---- [error log]
set 01 22:36:56 s-addc.studiomosca.net named[639]: samba_dlz: starting
transaction on zone studiomosca.net
set 01 22:36:56 s-addc.studiomosca.net named[639]: client @0x7fce39095d90
192.168.1.243#54874: update 'studiomosca.net/IN' denied
set 01 22:36:56 s-addc.studiomosca.net named[639]: samba_dlz: cancelling
transaction on zone studiomosca.net
set 01 22:36:56 s-addc.studiomosca.net named[639]: samba_dlz: starting
transaction on zone studiomosca.net
set 01 22:36:56 s-addc.studiomosca.net named[639]: samba_dlz: disallowing update
of signer=WIN7-1\$\@STUDIOMOSCA.NET name=WIN7-1.studiomosca.net type>
set 01 22:36:56 s-addc.studiomosca.net named[639]: client @0x7fce39095d90
192.168.1.243#57567/key WIN7-1\$\@STUDIOMOSCA.NET: updating zone
'studiomos>
set 01 22:36:56 s-addc.studiomosca.net named[639]: samba_dlz: cancelling
transaction on zone studiomosca.net
[2] ----[smb.conf]
Server role: ROLE_ACTIVE_DIRECTORY_DC
# Global parameters
[global]
passdb backend = samba_dsdb
realm = STUDIOMOSCA.NET
server role = active directory domain controller
server services = s3fs, rpc, nbt, wrepl, ldap, cldap, kdc, drepl,
winbindd, ntp_signd, kcc, dnsupdate
template homedir = /home/%U
template shell = /bin/bash
workgroup = STUDIO_MOSCA
rpc_server:tcpip = no
rpc_daemon:spoolssd = embedded
rpc_server:spoolss = embedded
rpc_server:winreg = embedded
rpc_server:ntsvcs = embedded
rpc_server:eventlog = embedded
rpc_server:srvsvc = embedded
rpc_server:svcctl = embedded
rpc_server:default = external
winbindd:use external pipes = true
idmap_ldb:use rfc2307 = yes
idmap config * : backend = tdb
map archive = No
vfs objects = dfs_samba4 acl_xattr
[sysvol]
path = /var/lib/samba/sysvol
read only = No
[netlogon]
path = /var/lib/samba/sysvol/studiomosca.net/scripts
read only = No
--
Dario Lesca
(inviato dal mio Linux Fedora 30 Workstation)
Rowland penny
2019-Sep-02 07:26 UTC
[Samba] Problem to access from Win to Win after classicupdate to Samba DC 4.10.7
On 01/09/2019 23:44, Dario Lesca via samba wrote:> I have do a classicupdate from a NT4 style domain to Samba DC 4.10.7 > BIND_DLZ without (apparently) problem > > All seem work fine, access to PC work, join or re-join a PC to domain > work, access from a Linux samba member server to Win7 PC work, access > from Win7 to samba member server work. > > But I cannot access from a PC with win7 to another PC with win7. > > If I try to access from win7-0 to win7-1 via "\\win7-1\" I get a error > message of Insufficient Right to access. > > Another strange thing that happens is that I don't see any PC browsing > the net > > If I try to access via IP of win-7-1 (es: \\10.1.1.1\) I see and can > access to shared folder, but I do not have the right access to > read/write into it. > > The name of PC to which I connect it is into DNS an it's resolve > correctly the IP. > > I have try to remove this PC from domain and rejoin it, but none is > change. > > When I join to domain (or if I run "ipconfig /registerdns" on joined > PC) I get this error[1] into syslog (is the name ending with > "$" correct ?) > > If I run RSAT tools on a Win7 I can see and modify all object of the > domain (user, group, computer, ecc) > > This problem occurs with all PC: all can access to two new samba member > server, but they cannot access to other windows > > Before classicupdate these problems did not occur and all worked fine. > > This[2] is the smb.conf of AD-DC: > > Some one have some suggest how to debug this issue? > If I missing some information, let me know. > > Many thanks. > Dario > > > [1] ---- [error log] > set 01 22:36:56 s-addc.studiomosca.net named[639]: samba_dlz: starting transaction on zone studiomosca.net > set 01 22:36:56 s-addc.studiomosca.net named[639]: client @0x7fce39095d90 192.168.1.243#54874: update 'studiomosca.net/IN' denied > set 01 22:36:56 s-addc.studiomosca.net named[639]: samba_dlz: cancelling transaction on zone studiomosca.net > set 01 22:36:56 s-addc.studiomosca.net named[639]: samba_dlz: starting transaction on zone studiomosca.net > set 01 22:36:56 s-addc.studiomosca.net named[639]: samba_dlz: disallowing update of signer=WIN7-1\$\@STUDIOMOSCA.NET name=WIN7-1.studiomosca.net type> > set 01 22:36:56 s-addc.studiomosca.net named[639]: client @0x7fce39095d90 192.168.1.243#57567/key WIN7-1\$\@STUDIOMOSCA.NET: updating zone 'studiomos> > set 01 22:36:56 s-addc.studiomosca.net named[639]: samba_dlz: cancelling transaction on zone studiomosca.netThat is showing that a client isn't being allowed to update a record.> > [2] ----[smb.conf] > Server role: ROLE_ACTIVE_DIRECTORY_DC > > # Global parameters > [global] > passdb backend = samba_dsdb > realm = STUDIOMOSCA.NET > server role = active directory domain controller > server services = s3fs, rpc, nbt, wrepl, ldap, cldap, kdc, drepl, winbindd, ntp_signd, kcc, dnsupdate > template homedir = /home/%U > template shell = /bin/bash > workgroup = STUDIO_MOSCA > rpc_server:tcpip = no > rpc_daemon:spoolssd = embedded > rpc_server:spoolss = embedded > rpc_server:winreg = embedded > rpc_server:ntsvcs = embedded > rpc_server:eventlog = embedded > rpc_server:srvsvc = embedded > rpc_server:svcctl = embedded > rpc_server:default = external > winbindd:use external pipes = true > idmap_ldb:use rfc2307 = yes > idmap config * : backend = tdb > map archive = No > vfs objects = dfs_samba4 acl_xattr > [sysvol] > path = /var/lib/samba/sysvol > read only = No > [netlogon] > path = /var/lib/samba/sysvol/studiomosca.net/scripts > read only = No > >Please do not post the output of 'testparm'? (which the above appears to be) or the output of 'samba-tool testparm', just post the output of 'cat /etc/samba/smb.conf'. They are all different, but the 'cat' is the only true record. Try checking that apparmor isn't getting in the way (if it is installed). Check if a firewall is blocking a port. Rowland
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)
Reasonably Related Threads
- Problem to access from Win to Win after classicupdate to Samba DC 4.10.7
- Problem to access from Win to Win after classicupdate to Samba DC 4.10.7
- Problem to access from Win to Win after classicupdate to Samba DC 4.10.7
- Ovirt Hosted-Engine VM iptables
- connection state tracking with DNS [was Primary DNS...]