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.


Messages - RAB

Pages: [1] 2 3
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?

2
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?

3
Other modules / Re: zentyal.loggerd.service
« on: January 07, 2019, 04:54:09 pm »
upgraded to 5.1.3 and completely stripped the server from GUI (LXDE and X) - behavior still occurs roughly anywhere from once an hour to one minute in between occurrences.

4
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

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!


5
OK - solved

Changed the content of:

/var/lib/samba/private/tls/cert.pem to contain the content of the *-cert.crt file in the key-certificate package form the zentyal CA
/var/lib/samba/private/tls/key.pem to contain the content of the *-private-key.pem file in the key-certificatepackage form the zentyal CA
/var/lib/samba/private/tls/ca.pem to empty (no content). The file somehow needs to exist otherwise the start of the zentyal samba service fails.

Edited
/usr/share/zentyal/stubs/samba/smb.conf.mas to include at the end:

tls enabled  = yes
tls keyfile  = tls/key.pem
tls certfile = tls/cert.pem
tls cafile   =


Restart the zentyal samba service:

sudo zs samba stop
sudo zs samba stop


NOTE: Despite the empty setting for tls cafile in smb.config.mas, the start of the zentyal samba service fails if no tls/ca.pem file exists. Having an empty tls/ca.pem resolved this for me.

6
Ok - figured it out for the most part.

Just cannot find where Zentyal configures the samba certificates (the settings below from a plain samba config):


tls enabled  = yes
tls keyfile  = tls/myKey.pem
tls certfile = tls/myCert.pem
tls cafile   = tls/myIntermediate .pem  # if not required, set empty


The certificates used (default setup) for LDAPS on port 636 is the one found in
/var/lib/samba/private/tls

per https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html this is the default location and tls is enabled per default.

7
This: https://wiki.samba.org/index.php/Configuring_LDAP_over_SSL_(LDAPS)_on_a_Samba_AD_DC

Suggests that the certificates in
/var/lib/samba/private/tls
would only e used for LDAP.

Correct?

8
This post:
https://forum.zentyal.org/index.php/topic,32039.0.html

suggests that the certificates are located here on the Zentyal server:
/var/lib/samba/private/tls


Is this correct?
Can I just replace these by a certificate generated by the Zentyal CA or will this generate issues with the existing AD functionality?

The LDAP conf file also contains a reference to a certificate.
/etc/ldap/ldap.conf


What is the role of this certificate? Does it require changing as well? Should it rather point to a certificate in
/var/lib/samba/private/tls
?

9
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


10
Never mind, the module list is just one layer deeper.

Just use an arbitrary module name that does not exist and on the unknown modulename the zs command will still display which modules are available.

for example:

# sudo zs myfakemodule restart

11
Hi,

Could you also provide a list of the module names available in Zentyal 5 ?

I did put some effort into it but could not find an up-to-date list.

In particular I am looking for the module name of the zentyal web interface which froze on me (apache is up).

Thanks!
RAB

12
(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.

Pages: [1] 2 3