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.
Pages: 1 [2]
16
Installation and Upgrades / Re: grant AD users access to the web admin GUI
« on: May 29, 2018, 09:38:29 pm »
Having the same problem and have not found a resolution yet.
17
Directory and Authentication / Re: Loading Roaming Profiles from Local Server, not over VPN?
« on: May 29, 2018, 01:36:46 pm »
A follow up for later thread-readers.
I added a new host entry to each of the two servers by editing
/usr/share/zentyal/stubs/samba/smb.conf.mas
and adding the line
netbios aliases = fs
However, I still have a problem. If I add fs a hostname alias to the DNS server on both boxes, then they sychronise across the two sites, and it's pot luck which IP address I get when resolving fs / fs.DOMAIN.COM
My workaround is to add
192.168.x.y fs fs.domain.com
to the \windows\system32\drivers\etc\hosts file on each and every machine on the network, where it's hard coded to point to the local server for that LAN.
My idea solution would be for the local PDC / BDC to give out its local IP address as fs, but I can't see a way of adding a DNS record into SAMBA that doesn't replicate to the other site.
I added a new host entry to each of the two servers by editing
/usr/share/zentyal/stubs/samba/smb.conf.mas
and adding the line
netbios aliases = fs
However, I still have a problem. If I add fs a hostname alias to the DNS server on both boxes, then they sychronise across the two sites, and it's pot luck which IP address I get when resolving fs / fs.DOMAIN.COM
My workaround is to add
192.168.x.y fs fs.domain.com
to the \windows\system32\drivers\etc\hosts file on each and every machine on the network, where it's hard coded to point to the local server for that LAN.
My idea solution would be for the local PDC / BDC to give out its local IP address as fs, but I can't see a way of adding a DNS record into SAMBA that doesn't replicate to the other site.
18
Directory and Authentication / Loading Roaming Profiles from Local Server, not over VPN?
« on: May 28, 2018, 12:38:03 pm »
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?
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?
19
Directory and Authentication / Zentyal 5.0 - Local usernames on PDC now prefixed with DOMAIN
« on: January 22, 2018, 04:24:43 pm »
Environment
Zentyal 5.0.10
Ubtuntu 16.04
zentyal-samba 5.0.10
Summary
Since upgrading to Zentyal 5.0, AD usernames are prefixed with the DOMAIN on the PDC
Problem
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 (https://lists.samba.org/archive/samba/2013-April/172804.html). Using
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
Ubtuntu 16.04
zentyal-samba 5.0.10
Summary
Since upgrading to Zentyal 5.0, AD usernames are prefixed with the DOMAIN on the PDC
Problem
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 (https://lists.samba.org/archive/samba/2013-April/172804.html). Using
Code: [Select]
winbind use default domain = yesno 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
20
Other modules / Using DHCP on Internet/WAN port causes Gateway and VPN problems
« on: January 22, 2018, 08:49:11 am »
Environment
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).
Summary
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 127.0.0.1
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
At some indeterminate time after rebooting, this error will stop happening and the server will start.
Questions
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).
Summary
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 127.0.0.1
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't be configured, no IP address found for interface eth0 at VPN server bridge couldn't be configured, no IP address found for interface eth0 at /usr/share/perl5/EBox/Module/Service.pm line 964At some indeterminate time after rebooting, this error will stop happening and the server will start.
Questions
- 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?
21
Installation and Upgrades / Re: Error after updating Zentyal core to 4.2.9
« on: August 29, 2017, 10:25:52 am »
Hello,
Same problem
open("/usr/share/zentyal/psgi/zentyal.psgi"): No such file or directory [/build/buildd/uwsgi-1.9.17.1/plugins/psgi/psgi_loader.c line 276]
This was my fix
So it appears the bug is that the Core 4.2.9 package does not include the /psgi/zenyal.psgi file
I've created a bug report https://tracker.zentyal.org/issues/5288
Same problem
open("/usr/share/zentyal/psgi/zentyal.psgi"): No such file or directory [/build/buildd/uwsgi-1.9.17.1/plugins/psgi/psgi_loader.c line 276]
This was my fix
Code: [Select]
sudo su
mkdir /usr/share/zentyal/psgi
cd /usr/share/zentyal/psgi
wget https://raw.githubusercontent.com/zentyal/zentyal/4.2/main/core/src/psgi/zentyal.psgi
/etc/init.d/zentyal webadmin restart
exitSo it appears the bug is that the Core 4.2.9 package does not include the /psgi/zenyal.psgi file
I've created a bug report https://tracker.zentyal.org/issues/5288
22
Other modules / Re: Firewall - First INPUT rule is ACCEPT?
« on: March 22, 2016, 12:46:23 am »
Ignore that message. I've realised the ACCEPT is only on the "lo"cal interface, which is completely reasonable.
I just need to jump back in and find why my iptables aren't working the way I am expecting to them to.
I just need to jump back in and find why my iptables aren't working the way I am expecting to them to.
23
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 [2]