Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - nickpiggott

Pages: [1]
After a very difficult upgrade from 6.2 to 7.0, I was facing a problem where Bind and Samba were not properly connected, so DNS updates between them failed (and ultimated disrupted replication between DCs because they DNS zones became incorrectly populated). Restarting the dns module and/or the samba module failed with errors.

I noted several things I need to check and fix, so I'll list them here to help anyone who comes down with the same problems.

A lot of the problems are because the user "bind" cannot access the "dns.keytab", but this is silently failing. You just see "TKEY is unacceptable" errors or "Update: REFUSED" errors.

Check the reference to the dns.key tab shown in /etc/bind/named.conf.options. It should be pointing to /var/lib/samba/private/dns.keytab
Check the access rights to the /var/lib/samba/private folder. It must be readable by "bind" (or "named") - you may have to
Code: [Select]
chmod o=rx /var/lib/samba/privateCheck that the /var/lib/samba/private/dns.keytab file is set to group "bind" (or "named") and with permissions r-x. Permissions for other users should be --- (not allowed access)

If that doesn't fix your problem, you can recreate the DNS update user, but you must follow all these steps

If there is a /var/lib/samba/private/dns.keytab file, delete it
use samba-tool to to delete any existing DNS update user -
Code: [Select]
sudo samba-tool user delete dns-{domain controller name}follow this guide to recreate the user and keytab -
add the newly created user to the DnsAdmins group -
Code: [Select]
sudo samba-tool group addmembers "DnsAdmins" dns-{domain controller name}as above, check that dns.keytab is readable by the bind user

Finally, if you're seeing errors relating to "nsupdate -l -t10 {filename}" check that you
  • Have disabled IPv6 on the machine OR
  • Have enabled bind to respond on IPv6. You'll need to copy /usr/share/zentyal/stubs/dns/bind9.mas to /etc/zentyal/stubs/bind9.mas and then edit that file to remove the "-4" from the OPTIONS line
(this last issue is because nsupdate -l tries to contact locahost, which if IPv6 is enabled, tries :::53, not

Then you can check that things are working with
Code: [Select]
sudo samba_dnsupdate --verboseand
Code: [Select]
sudo nsupdate -lthen type "help" and "quit" to make sure it's connected

I hope this saves someone a day or so trying to work out why the DNS module is throwing errors in Zentyal.

I started to see this error in the Web Admin console when trying to access any of the Domain menu options.

The error was reported in /var/log/zental/zental.log as

Code: [Select] EBox::Ldap::safeConnect - FATAL: Could not connect to samba LDAP server: connect: Permission denied at FATAL: Could not connect to samba LDAP server: connect: Permission denied at /usr/share/perl5/EBox/ line 219

After a great deal of debugging, I found this solution.

  • Zentyal makes its LDAP connection through a pipe at /var/lib/samba/private/ldapi_priv/ldapi
  • The modules run as user ebox
  • ldapi_priv is group "ebox"
  • ldapi_priv/ldapi is a pipe, so read/writeable by all
  • /var/lib/samba has permissions allowing any user to access
  • in my situation, /var/lib/samba/private was owned root:root and only accessible by root
  • therefore it seemed that user ebox could not access the ldapi pipe (defined in /usr/share/perl5/EBox/
I changed the permissions of the private folder
Code: [Select]
sudo chgrp ebox private
sudo chown g=rwx private

That fixed my problem

Recent upgrade from 6.2.7 to 7.0 on Ubutnu

After upgrading I noticed that my iptables were blank and I had no routing through the server. Looking at the log, I could see that the firewall module was trying to manipulate iptables by referencing /sbin/iptables.

There wasn't an /sbin/iptables on my installation - its /usr/sbin/iptables

I "fixed" the problem by creating a symbolic link from /sbin/iptables to /usr/sbin/iptables and restarted the firewall. iptables then populated correctly and traffic flowed through the server.

Running Zentyal 6.2, Samba Active Directory enabled.

In smb.conf, these values are set
Code: [Select]
workgroup = mydomain  (in lower case)
realm =

From the Linux command line on the server running Zentyal,

Code: [Select]
MYDOMAIN\myuser@dc:\home\myuser$ mail
Subject: Test Email
Test Email

The mail is rejected by GMail with this error

Code: [Select]
: host[] said: 553-5.1.7 The sender address <MYDOMAIN\> is not a valid 553 5.1.7 RFC-5321 address.
If I send an email myself, I see TWO mailboxes in /var/mail

Code: [Select]

When I open mail to read mail, it says there is no mail for MYDOMAIN\myuser
If I cat the file of mydomain\myuser I can see the email

Looking in /var/log/mail.log I can see
Code: [Select]
postfix/pickup[29633]: 0532F1403E4: uid=1000 from=<MYDOMAIN\myuser>

So it seems that post fix is doing two things:
  • Not removing the MYDOMAIN part of my username from the outbound "from address"

  • Changing the reply back to all lowercase (including the mydomain section)

Any thoughts what I can do to resolve this?

I'm running Zentyal 5.1 with Samba 4.6.7 on Ubuntu 16.04.6 LTS

I have users and groups populated in Active Directory. I can use the Zentyal GUI to add a user to the "Domain Admins" group.

However querying the Domain Admin groups shows it as being empty:
Code: [Select]
> getent group
DOMAIN\domain admins:x:2512:
> wbinfo --group-info="Domain Admins"
DOMAIN\domain admins:x:2512:

Using samba-tool provides the correct answer:
Code: [Select]
> sudo samba-tool group listmembers "Domain Admins"
ldb_wrap open of secrets.ldb

My uid is 1000 (a legacy ID). The administrator uid is 2500. The zental-mail-dc2 uid is 3000031.

My smb.conf is autogenerated by Zentyal. There are no apparent errors in /var/log/samba/samba.log. I'm using only winbind (sssd is not installed on this box).

What can I do to correct this? It's stopping important functionality (like adding "Domain Admins" to the sudoers file) from working.

I am running Zentyal 5.1, providing an Active Directory service. I can successfully join machines to the domain, and I have a number of users in the domain. They all have uidNumber and gidNumber entries in their LDAP records, and these are correctly mapped to the user ID and group IDs when the user logs into any of the Domain Controllers.

The server smb.conf contains
Code: [Select]
    idmap_ldb:use rfc2307 = yes

    winbind enum users = yes
    winbind enum groups = yes
    template shell = /bin/bash
    template homedir = /home/%U

Problem: The user and group IDs that are allocated to users and groups are different when the user logs into a (non Domain Controller) machine joined to the domain.

Can anyone advise what I need to install and configure for the idmapping on the client machine to correctly use the uidNumber and gidNumber in the Active Directory?

I've followed a number of guides for enabling SSO with AD, and the official Samba guidance for idmap config ad. I can't find much documentation on how to use the idmap_ldb configuration on the client machine.


I'm using Zentyal 5.1, configured to provide an Active Directory.

That requires that I have a DNS server authoritative for my domain ( running on the Zentyal server. This is populated with the required DNS records for the domain controller (

The true authoritative DNS server for the domain is hosted externally. All new DNS records for the domain are added to this external DNS server. For example, the A record for is hosted externally.

When I query DNS for locally, the request is passed to the DNS server running on Zentyal. The believes that it is the authoritative DNS server for the domain, and because there is no A record configured for on that DNS server, it returns an NX (not found) result.

Is there a way I can configure Zentyal / Samba / bind to forward requests for that zone to the specific external Authoritative nameserver for


I'm hoping this is a common enough problem for people to have a few ideas about solving it.

I have users provisioned with Windows Roaming Profiles, and based on two sites linked with a (slow) VPN link. There is a PDC on one site, and a BDC on the other site, both running Zentyal 5.1. I use unison to keep the filesystems of the two machines continuously synchronised.

The profilePath item for the user in LDAP depends on which server I have created them - if I create the user on the PDC, it says \\pdc\profiles\username, if I create them on the BDC it says \\bdc\profiles\username

The problem comes when a user is working on the "other" LAN (e.g. someone who's profile was created on the BDC comes and works on the LAN with the PDC - which is linked to the other LAN using a slow VPN). Because their profile says \\bdc\profiles\username, it loads their Windows profile very very slowly (hours to login) over the VPN from the BDC, rather than loading it from the LAN on the PDC.

I've tried putting in local alias entries into the local DNS servers - FS pointing to the same ip address as the PDC on one lan, and pointing to the BDC on the other lan - and then manually editing the profilePath to point to \\fs\profiles\username - but Samba notices that it's an alias and refuses to load the profile. (I assume it's worried that a machine is spoofing the PDC / BDC)

Any thoughts on how I can put a workaround in for this problem?

Zentyal 5.0.10
Ubtuntu 16.04
zentyal-samba 5.0.10

Since upgrading to Zentyal 5.0, AD usernames are prefixed with the DOMAIN on the PDC

On Zentyal 4.2 usernames on the PDC were the username. e.g. tomjones
On upgrade to Zental 5.0.10, usernames on the PDC are now prefixed by the domain e..g DOMAIN\tomjones

This is a known issue with Samba =>4.0.5 ( Using

Code: [Select]
winbind use default domain = yes
no longer functions on the PDC. As an example of a problem this causes, you can no longer log into the the webadmin interface using DOMAIN\username (or username). Additionally, mail routing is failing, crontabs are no long associated with user accounts. It's no longer possible to get kerberos tickets as kinit (without username specified) fails because it looks for DOMAIN\username credentials, not username.

Is this something that could be adjusted in the Zentyal packaging of Samba? It's causing significant problems when transitioning from Samba <4.0.5 to =>4.0.05

Zentyal 5.0.10
Ubuntu 16.04.3 LTS
Zentyal server has networking (5.0.9), DNS (5.0.3) and OpenVPN (5.0.1) components enabled

eth0 is connected to a router provided by my ISP. The ISP recommends using DHCP to acquire IP address, gateway and DNS servers.
eth1 is connected to my LAN, configured to use a static address

I configure eth0 to use DHCP and marked as External(WAN).

The way that DHCP is handled creates unpredictable behaviour in other modules - gateway is configured late, and VPN cannot determine the IP addresses of the interface - for an indeterminate period of time after reboot.

Gateway Problems
At initial setup, prior to enabling zentyal-networking, dhclient acquires IP address, gateway and DNS servers and writes these into the IP routing tables (and /etc/resolv.conf for the DNS servers). I can access the internet.

Enabling zentyal-networking causes the pre/post scripts at /etc/dhcp/dhclient-enter|exit-scripts.d to be executed. These scripts remove the default gateway and DNS servers. This causes loss of access to the Internet, as there is no default gateway configured, and the only DNS server in /etc/resolve.conf is

In the User Interface, there is no default gateway shown on the Network>Gateways page.

At some "indeterminate" time later, the default gateway is re-configured and Internet access comes back. The gateway appears in Network>Gateways as dhcp-gw-eth0.

The DNS servers are not added to Zentyal. I have to manually add them to DNS>Forwarders

VPN Problems
I have a VPN server configured. If I set the server to listen on <All Ports>, it starts correctly. If I set the server to listen to eth0, it will fail to start, with an error

Code: [Select]
VPN server bridge couldn&#39;t be configured, no IP address found for interface eth0 at VPN server bridge couldn&#39;t be configured, no IP address found for interface eth0 at /usr/share/perl5/EBox/Module/ line 964
At some indeterminate time after rebooting, this error will stop happening and the server will start.

  • Does anyone else see this behaviour?
  • Is there anything I can do to make handling of gateways / interface addresses more reliable?
  • Should the DNS servers be automatically added to DNS>Forwarders?

Other modules / Firewall - First INPUT rule is ACCEPT?
« on: March 21, 2016, 07:39:58 pm »
I noticed my INPUT iptables has the first rule as ACCEPT. I'm not an iptables guru, but doesn't that mean that all INPUT packets are immediately accepted and all the rules that follow (preinput, idrop etc) are ignored and therefore pointless?

Code: [Select]
Chain INPUT (policy DROP)                                                                                                                                                                                                           
target     prot opt source               destination                                                                                                                                                                                 
ACCEPT     all  --  anywhere             anywhere                                                                                                                                                                                   
preinput   all  --  anywhere             anywhere                                                                                                                                                                                   
idrop      all  --  anywhere             anywhere             state INVALID                                                                                                                                                         
iaccept    all  --  anywhere             anywhere             state RELATED,ESTABLISHED                                                                                                                                             
inospoof   all  --  anywhere             anywhere                                                                                                                                                                                   
iexternalmodules  all  --  anywhere             anywhere                                                                                                                                                                             
iexternal  all  --  anywhere             anywhere                                                                                                                                                                                   
inoexternal  all  --  anywhere             anywhere                                                                                                                                                                                 
imodules   all  --  anywhere             anywhere                                                                                                                                                                                   
iglobal    all  --  anywhere             anywhere                                                                                                                                                                                   
iaccept    icmp !f  anywhere             anywhere             icmp echo-request state NEW                                                                                                                                           
iaccept    icmp !f  anywhere             anywhere             icmp echo-reply state NEW                                                                                                                                             
iaccept    icmp !f  anywhere             anywhere             icmp destination-unreachable state NEW                                                                                                                                 
iaccept    icmp !f  anywhere             anywhere             icmp source-quench state NEW                                                                                                                                           
iaccept    icmp !f  anywhere             anywhere             icmp time-exceeded state NEW                                                                                                                                           
iaccept    icmp !f  anywhere             anywhere             icmp parameter-problem state NEW                                                                                                                                       
idrop      all  --  anywhere             anywhere                     

Pages: [1]