Issues with NS8 Samba Active Directory and Go based Authentication Providers (Authelia)

Feature
,
1

Hello all. Not sure how to put a tag on this, or I’d fill it in Active Directory. Also waffling on between bug and feature, it kind of falls between.

I have a working Samba Active Directory domain setup on my NS8 installation with Mail and Webtop. I can direct connect to the Samba AD with LDAP browsers and other apps, like Calibre-Web, without much issue (see below about slowness). I ran into two issues with Authelia, but I now have a working configuration.

As an aside, I didn’t want to deal with the TLS issues I knew would happen, so I put skip_verify=true in Authelia’s options out of the gate.

The first issue was timeout related - I’m not sure why, but the responses on NS8 seem slow? A timeout of 5s is not long enough (the default for Authelia) and will result in a 200 error for context deadline exceeded. Setting to 10s cleared that, but I do wish Go had a bit more detailed logs (I had set to debug, and that was all it was giving me). These delays show up in other applications as well (such as with LDAPBrowser), and I don’t know why that would be - the NS8 server is a modified ASUSTOR all flash device with 2.5G bonded links (disabling the eMMC module and running Rocky from one of the NVMe drives). There should be no hardware issue attributing to this, and other suites (such as LLDAP or Authentik) do not have these problems (I was trying to use LLDAP and Authentik’s LDAP outpost before deciding to use NS8 for this).

The second issue was TLS related, despite my attempt to circumvent this with the skip_verify above. I received:

LDAP Result Code 200 \"Network Error\": tls: failed to parse certificate from server: x509: negative serial number" provider=user stack="github.com/authelia/authelia/v4/internal/commands/root.go:118

And this was much easier to troubleshoot. This is called out specifically in Go’s documentation with respect to version 1.23 which hit full release in August of last year. To get around this, you need to add an environment variable to Authelia’s docker, something akin to:

GODEBUG=x509negativeserial=1

YMMV for how you need to enter this, I am using Podman on a Centos 10 Stream system for my Authelia setup. While I am specifically talking about Authelia here, this will be true for any Go based LDAP provider system after v1.23.

I am pointing it out here rather than with Authelia’s devteam because it is not an issue with Go from my POV, but an issue of the TLS setup with NS8. Why does the Samba AD only have this self-signed setup? Why can’t it use a LE cert? I’ve done that before with using certbot on Windows 2016 installs in front of the ADDC, for example. You lose out on some AD specific stuff, but if the purpose of your AD is just to be a user provider to an application like Authelia (and for NS8 Mail) and not for the computers/file sharing aspects I think this would be a good option to have. NS8’s implementation will certainly be easier and lighter than running a Windows Server VM just for AD user functionality.

2

@stephdl was the exposition of Active directory outside the cluster implemented.

Hello @armouredking is authelia with which you are attempting to connect your NS8 Active directory hosted on an NS8 system or not.

IF yes, is it hosted within the same cluster. if yes, could be another issue.

if the authelia system is running on a different server system, I am unsure if exposing Active directory outside the cluster has already been implemented, we have to wait for confirmation from Dev team

3

Yes, the Authelia server is on a different system (as noted, that is running on a Centos 10 Stream system; the NS8 server was done on a RL9.5 system). It is listed as not only available, but required in the docs. I also tested this using Calibre-Web’s LDAP setup (located on the same server as the Authelia Podman container), and the same slow access occurs there.

Per the docs, OpenLDAP is not available, SAMBA is. And I’m not sure how SAMBA would work if it weren’t accessible externally, seeing as that is needed for registering computers if you were going with a full AD build (not necessary for my environment).

Morever, it is possible to access the Samba AD server (as noted above) using an LDAP Browser to the IP address defined during the node build (the external share IP per setup). Not only can it be viewed, but it can be edited with a samba administration user - I tested this by uploading jpegPhotos and pulling them remotely - the data is uploaded and can be viewed. It’s just incredibly slow from a transaction point of view. LDAPBrowser throws an expected warning for a self signed cert, and that is likely why that particular application is much slower than the others (as noted, increasing timeout to 10s is enough for Authelia), but it’s much slower to access than alternative solutions on the same hardware (tested with LLDAP and Authentik’s LDAP provider outpost).

Honestly, probably just going to drop attempting to get this to work, particularly because the viewer feedback is just a slow page which results in multiple attempts to F5 to get a visual response while the slow call is occurring.

4

maybe we should go back to the route, what are you trying to achieve exactly

i see you mentioned Authentik, on a differen server. NS8 also has an authentik App, which can authentik with Ldap or AD locally.

Shouldn’t AD and Ldap to external servers be handled via a VPN, instead of directly, unless the servers are all locally virtualised.