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]
1
Other modules / Zentyal CA - CRL / OCSP
« on: April 20, 2023, 10:58:15 am »
The Zentyal (7.0) Certificate Authority allows for revocation of certificates.
However - it seems that the CA is not configured to provide certificate revocation information.
I noticed this when using curl to query a web server which uses a Zentyal CA provided certificate (of course with the Zentyal root CA provided to curl using --cacert).
Looking at the certificates no CRL endpoints are included, nor any reference to OCSP.
(Inspect for example the certificate of github.com and such information is included)
>> Is it correct that Zentyal CA does not provide certificate revocation information?
--> If so - has anyone succeeded in adding this functionality and how?
--> If not so - what is/are the endpoint(s) for CRL and/or OCSP - and how can I include this information in the Zentyal CA generated certificates?
However - it seems that the CA is not configured to provide certificate revocation information.
I noticed this when using curl to query a web server which uses a Zentyal CA provided certificate (of course with the Zentyal root CA provided to curl using --cacert).
Looking at the certificates no CRL endpoints are included, nor any reference to OCSP.
(Inspect for example the certificate of github.com and such information is included)
>> Is it correct that Zentyal CA does not provide certificate revocation information?
--> If so - has anyone succeeded in adding this functionality and how?
--> If not so - what is/are the endpoint(s) for CRL and/or OCSP - and how can I include this information in the Zentyal CA generated certificates?
2
Directory and Authentication / Share name with leading dot in name shows without dot (but only works with dot)
« on: December 13, 2022, 07:08:12 pm »
I am trying to set up a hidden share.
Followed these instructions for a stub to detect a dot in the name of the share and set browseable to no for that share.
Result is that users without access to the share do not see the share showing up.
So far so good.
However - for users with access rights the share shows up (in windows explorer) without the leading dot in the share name.
".Backup" shows up as "Backup" - it does not work/open when clicked/navigated in windows explorer.
Manually navigating to \\ZENTYALSERVER\.Backup (with leading dot) does work and shows the share contents.
Any tips for making Samba show/apply the leading dot in the Share name?
Followed these instructions for a stub to detect a dot in the name of the share and set browseable to no for that share.
Result is that users without access to the share do not see the share showing up.
So far so good.
However - for users with access rights the share shows up (in windows explorer) without the leading dot in the share name.
".Backup" shows up as "Backup" - it does not work/open when clicked/navigated in windows explorer.
Manually navigating to \\ZENTYALSERVER\.Backup (with leading dot) does work and shows the share contents.
Any tips for making Samba show/apply the leading dot in the Share name?
3
Other modules / zentyal.loggerd.service
« on: November 15, 2018, 09:42:13 am »
Looking into freezes of my Zentyal 5.1.1 server I run into repeated occurrences of the below in /var/logs/syslog
Any suggestions on what may cause this behavior (and how to fix it
) are most appreciated!
Code: [Select]
Nov 15 09:29:41 my-server systemd[1]: zentyal.loggerd.service: Main process exited, code=exited, status=9/n/a
Nov 15 09:29:41 my-server systemd[1]: zentyal.loggerd.service: Unit entered failed state.
Nov 15 09:29:41 my-server systemd[1]: zentyal.loggerd.service: Failed with result 'exit-code'.
Nov 15 09:29:42 my-server systemd[1]: zentyal.loggerd.service: Service hold-off time over, scheduling restart.
Nov 15 09:29:42 my-server systemd[1]: Stopped Zentyal logger daemon.
Nov 15 09:29:42 my-server systemd[1]: Started Zentyal logger daemon.Any suggestions on what may cause this behavior (and how to fix it
) are most appreciated!4
Directory and Authentication / [SOLVED] Zentyal 5 - CA - LDAPS SSL Certificate
« on: March 12, 2018, 12:08:21 pm »
Hi,
LDAPS is working but the certificate used does not seem to be issued by the CA (which is working fine for other services/servers) ... With LDAPS I am getting messages that the certificate is not valid.
Two questions:
1. Can I replace the certificate myself, and how can I make it persistent?
2. Is it possible to have LDAPS listed as a service in the Certification Authority under Services Certificates?
Thanks!
RAB
LDAPS is working but the certificate used does not seem to be issued by the CA (which is working fine for other services/servers) ... With LDAPS I am getting messages that the certificate is not valid.
Two questions:
1. Can I replace the certificate myself, and how can I make it persistent?
2. Is it possible to have LDAPS listed as a service in the Certification Authority under Services Certificates?
Thanks!
RAB
5
Installation and Upgrades / firewall blocking machines defined in network object ("foreign" subnet)
« on: April 25, 2017, 05:38:23 pm »
(behavior on Zentyal 5.0.7)
Whilst manually migrating from Zentyal 3.4 to Zentyal 5.0 I ran into the following which may or may not be expected behavior ... it was hard to isolate an may be of benefit to others.
Kept both Zentyal machines alive on different subnets, each being a DHCP server on their own subnet.
Old subnet will be used for servers, new subnet will be used for clients.
The subnets are routed via an external router for now, later they will both interface directly to the Zentyal 5.0 machine.
Transferred the server LDAP authentication to the Zentyal 5.0 machine in the new subnet.
This was working.
Then at some point the server LDAP authentication broke. It appeared that the servers with a fixed/reserved IP address (old subnet) could no longer reach the new Zentyal machine (no LDAP, no ping, no traceroute). When disabling the firewall on the new Zentyal 5.0 machine all was working as expected.
It took a while to figure out the problem, the cause was in the definition of a network Object on the new Zentyal 5.0 machine containing the servers in the subnet of the old Zentyal 3.4 machine.
I created a network Object "Servers" to be used in the future for fixed/reserved DHCP IP addresses.
The Names and IP/MAC addresses were identical to the "Servers" Object defined in the old Zentyal 3.4 machine as I plan to keep my servers in that old subnet.
In the Zentyal 5.0 machine no network interface was assigned to this subnet (yet), however the subnet was as stated above routed via an external router.
The network Object was NOT in use anywhere (not for fixed/reserved DHCP addresses) on the Zentyal 5.0 machine. It just was defined.
Interestingly enough, once the network object was created, the server machines (same reserved/fixed IP/MAC DHCP addresses as in the new "Servers" network object) from the old subnet could no longer contact the new Zentyal 5.0 machine.
The cients still in the old subnet (regular DHCP clients) had no issue in contacting the new Zentyal 5.0 machine.
Once I deleted the network object "Servers" on the new machine all was working again ...
It seems that he firewall definition / ip tables are generated using the network object whist nothing is being done with the network object (yet).
Note:
* Adding a firewall rule to the internal network to accept any service originating form the "Servers" network object did not seem to take any effect.
Whilst manually migrating from Zentyal 3.4 to Zentyal 5.0 I ran into the following which may or may not be expected behavior ... it was hard to isolate an may be of benefit to others.
Kept both Zentyal machines alive on different subnets, each being a DHCP server on their own subnet.
Old subnet will be used for servers, new subnet will be used for clients.
The subnets are routed via an external router for now, later they will both interface directly to the Zentyal 5.0 machine.
Transferred the server LDAP authentication to the Zentyal 5.0 machine in the new subnet.
This was working.
Then at some point the server LDAP authentication broke. It appeared that the servers with a fixed/reserved IP address (old subnet) could no longer reach the new Zentyal machine (no LDAP, no ping, no traceroute). When disabling the firewall on the new Zentyal 5.0 machine all was working as expected.
It took a while to figure out the problem, the cause was in the definition of a network Object on the new Zentyal 5.0 machine containing the servers in the subnet of the old Zentyal 3.4 machine.
I created a network Object "Servers" to be used in the future for fixed/reserved DHCP IP addresses.
The Names and IP/MAC addresses were identical to the "Servers" Object defined in the old Zentyal 3.4 machine as I plan to keep my servers in that old subnet.
In the Zentyal 5.0 machine no network interface was assigned to this subnet (yet), however the subnet was as stated above routed via an external router.
The network Object was NOT in use anywhere (not for fixed/reserved DHCP addresses) on the Zentyal 5.0 machine. It just was defined.
Interestingly enough, once the network object was created, the server machines (same reserved/fixed IP/MAC DHCP addresses as in the new "Servers" network object) from the old subnet could no longer contact the new Zentyal 5.0 machine.
The cients still in the old subnet (regular DHCP clients) had no issue in contacting the new Zentyal 5.0 machine.
Once I deleted the network object "Servers" on the new machine all was working again ...
It seems that he firewall definition / ip tables are generated using the network object whist nothing is being done with the network object (yet).
Note:
* Adding a firewall rule to the internal network to accept any service originating form the "Servers" network object did not seem to take any effect.
6
Installation and Upgrades / [SOLVED] Zentyal 3.3.4, Jabber 3.3 - Jabber fails to start - won't bind to LDAP
« on: February 11, 2014, 09:41:42 pm »
I seem to hit this bug
https://bugs.launchpad.net/ubuntu/+source/ejabberd/+bug/1241632
I can not find a way to start jabber (despite the webadmin interface sayin that the module started correctly, the module status says "stopped". "/etc/init.d/zentyal jabber status" shows "stopped". a commandline restart takes forever to no avail.
The credentials in /etc/ejabberd/ejabberd.cgf match the ones provided in the webinterface. External ldap explorer works fine with the same credentials.
Any help would be appreciated!
From /var/log/ejabberd/ejabberd.log.1 (this is repeated many many many times):
=INFO REPORT==== 2014-02-11 20:28:42 ===
I(<0.291.0>:eldap:983) : LDAP connection on 127.0.0.1:390
=INFO REPORT==== 2014-02-11 20:28:42 ===
I(<0.281.0>:eldap:983) : LDAP connection on 127.0.0.1:390
=INFO REPORT==== 2014-02-11 20:28:42 ===
I(<0.373.0>:eldap:983) : LDAP connection on 127.0.0.1:390
=INFO REPORT==== 2014-02-11 20:28:42 ===
I(<0.347.0>:eldap:983) : LDAP connection on 127.0.0.1:390
=WARNING REPORT==== 2014-02-11 20:28:42 ===
W(<0.347.0>:eldap:931) : LDAP bind failed on 127.0.0.1:390
Reason: invalidCredentials
=WARNING REPORT==== 2014-02-11 20:28:42 ===
W(<0.373.0>:eldap:931) : LDAP bind failed on 127.0.0.1:390
Reason: invalidCredentials
=WARNING REPORT==== 2014-02-11 20:28:42 ===
W(<0.281.0>:eldap:931) : LDAP bind failed on 127.0.0.1:390
Reason: invalidCredentials
=WARNING REPORT==== 2014-02-11 20:28:42 ===
W(<0.291.0>:eldap:931) : LDAP bind failed on 127.0.0.1:390
Reason: invalidCredentials
https://bugs.launchpad.net/ubuntu/+source/ejabberd/+bug/1241632
I can not find a way to start jabber (despite the webadmin interface sayin that the module started correctly, the module status says "stopped". "/etc/init.d/zentyal jabber status" shows "stopped". a commandline restart takes forever to no avail.
The credentials in /etc/ejabberd/ejabberd.cgf match the ones provided in the webinterface. External ldap explorer works fine with the same credentials.
Any help would be appreciated!
From /var/log/ejabberd/ejabberd.log.1 (this is repeated many many many times):
=INFO REPORT==== 2014-02-11 20:28:42 ===
I(<0.291.0>:eldap:983) : LDAP connection on 127.0.0.1:390
=INFO REPORT==== 2014-02-11 20:28:42 ===
I(<0.281.0>:eldap:983) : LDAP connection on 127.0.0.1:390
=INFO REPORT==== 2014-02-11 20:28:42 ===
I(<0.373.0>:eldap:983) : LDAP connection on 127.0.0.1:390
=INFO REPORT==== 2014-02-11 20:28:42 ===
I(<0.347.0>:eldap:983) : LDAP connection on 127.0.0.1:390
=WARNING REPORT==== 2014-02-11 20:28:42 ===
W(<0.347.0>:eldap:931) : LDAP bind failed on 127.0.0.1:390
Reason: invalidCredentials
=WARNING REPORT==== 2014-02-11 20:28:42 ===
W(<0.373.0>:eldap:931) : LDAP bind failed on 127.0.0.1:390
Reason: invalidCredentials
=WARNING REPORT==== 2014-02-11 20:28:42 ===
W(<0.281.0>:eldap:931) : LDAP bind failed on 127.0.0.1:390
Reason: invalidCredentials
=WARNING REPORT==== 2014-02-11 20:28:42 ===
W(<0.291.0>:eldap:931) : LDAP bind failed on 127.0.0.1:390
Reason: invalidCredentials
7
Installation and Upgrades / ebox 1.4 --> fresh Zentyal 2.2: Windows clients create new profile at logon
« on: June 05, 2012, 03:09:24 pm »
I am working on an upgrading our server from ebox 1.4.9 to Zentyal 2.2.
The latter is a fresh install on new hardware. The number of users, groups etc is fairly limited so I decided to manually configure the new server rather than importing users and groups etc. The domain name and server ip address remains the same after the upgrade.
Now if I log on as a user that is already existing on my Windows client (Win7Pro), the Windows client machine creates a new user profile. This is not what I want, I want to upgrade without disturbing any of the clients.
I have Google-ed my way around and searched the forum but cannot find any resolution.
What should I do to make sure that the users keep on using their existing client profiles? Maybe migrate some user key/id from ebox to the new Zentyal server or edit the windows client registry to mach some new id?
Thanks in advance for any useful hints!
RAB
The latter is a fresh install on new hardware. The number of users, groups etc is fairly limited so I decided to manually configure the new server rather than importing users and groups etc. The domain name and server ip address remains the same after the upgrade.
Now if I log on as a user that is already existing on my Windows client (Win7Pro), the Windows client machine creates a new user profile. This is not what I want, I want to upgrade without disturbing any of the clients.
I have Google-ed my way around and searched the forum but cannot find any resolution.
What should I do to make sure that the users keep on using their existing client profiles? Maybe migrate some user key/id from ebox to the new Zentyal server or edit the windows client registry to mach some new id?
Thanks in advance for any useful hints!
RAB
Pages: [1]