Well, with what we’ve figured out so far, that would be the OpenLDAP account provider on NS8. Authentik does a periodic read-only sync from that. That, I think, is probably the simplest way to use it, and that’s consistent with how I’ve set up LemonLDAP::NG in my NS7 module for that. But, of course, the downside is that everything needs to be manually configured to use the SSO solution.
1 Like
I would like to test by adding a external provider in NS8 pointing to the internal LDAP server within Authentik.
Within Authentik see:
Application → Providers → Create → LDAP Provider
What would be the host IP and the correct port number when trying to create an extrnal account provider on NS8?
Authentik says use port 389 on the docker host IP
but I think that will not work and maybe they really mean container and port, but is what port and how to handle many LDAP provider bound to applications in Authentik??
I have not completely enabled Ldap server on Authentik, i think there are some parametersi need to define, for the port and many other details to get Ldap on Authentik towork.
you can try though
I think so too, especially how a Authentik container is designed to work and how ports and network is being handled, especially since 1 Authentik instance can act with may auth mechanisms for many application on a 1 on 1 relationship.
I completely lack the skills for diving into those docker related topics, and I appreciate your (team) efforts!
A little bit of further testing: Not surprisingly (since the LDAP users show up in Authentik) I’m able to log into Authentik (at auth.mydomain) using one of those users. Good to know.
1 Like
I can confirm.
OK, we can install Authentik, get a cert for it, log in, and configure it to sync with at least the OpenLDAP server on NS8. Users from NS8’s OpenLDAP server can log in to Authentik. Well and good.
The next obvious step is to configure other NS8 apps to authenticate via Authentik, and fortunately Authentik has documentation for lots of them. Let’s start with Roundcube:
…and we have a problem. The scope mapping is easy enough, as is the application; both of those are configured in the Authentik UI. But then you need to set several configuration options for Roundcube, you need to add an authentication mechanism to Dovecot, and you need to set several configuration options for that. There’s no mechanism exposed in NS8 to do any of those things. Kind of a problem, that is.
Exactly, and there we hit a design issue of either NS8 or the modules, or even both. Hence my interest to see if we can relieve NS8 from the task of account management completely and leave it to something else. The possibility of external provider with domain shows it is taken into consideration. But does the rest of the design/modules do too?
As regards roundcube options, it seems possible to use an own settings.php:
For customizing dovecot:
2 Likes
The dokuwiki module is an great example. It offers authentication methods for 'Internal (Dokuwiki itself) and external (One of the LDAP instances on the cluster itself). Now for a real external, external, source other then those defined on NS8 directly. So basically an option (and parameters) for 1 or 2 external authentication methods.
Nextcloud: The instructions here (using OpenID Connect) work:
…but they don’t log you into the same account as if you’d logged into Nextcloud with username/password. If user fred logs in using the Nextcloud login page, he gets a different account (different files) than if user fred logs in via Authentik. This is true whether or not the “use unique user ID” is checked in the Nextcloud OIDC settings–you get the same account when logging in through Authentik regardless of whether that box is checked, but it’s a different box than if you log in through Nextcloud directly. Not good at all.
Don’t forget the behaviour of the built in NC admin of NethServer 7. It is ONLY differentiated by the password from the NethServer 7 built in NS admin (somewhat coupled with root). Or, as both users use the username “admin”, the difference must be in what’s before or accompanying the username, be this the AD or LDAP auth.
This is intended as a hint for troubleshooting…
If the logs show eg a prepended part to the username (akin to an AD login like Domain\Username (or whatever), this means a different user (and thus different profile / permissions and folders), even if the username part is exactly the same…
I think you’re seeing this phenomen already…
My 2 cents
Andy
1 Like
Shouldn’t that possibility be disabled when using Authentik as auth mechanism?
And could it be related to this warning in the Authentik docs?:
" Nextcloud will use the UUID as username. However, mapping the subject mode to authentik usernames is not recommended due to their mutable nature. This can lead to security issues such as user impersonation. If you still wish to map the subject mode to an username, disable username changing in authentik and set this to Based on the User's username ."
It probably should. But in a case where the Nextcloud data will have been migrated from NS7 (which is the situation I’ll be dealing with, and thus in which I’m most interested), I’m 99.9% sure you’re going to see the same problem–users will be able to log in, but their data will be gone.
I expect what I’m seeing is the same thing I was seeing when using LLNG with Nextcloud on NS7: the way Nethserver sets up Nextcloud’s LDAP authentication results in accounts based on a UUID, rather than based on a username (which also, incidentally, meant that CalDAV/CardDAV URLs were extraordinarily messy). Logging in via LLNG gave a username rather than the UUID, and therefore a different account.
1 Like
Exactly my thoughts. The messy UUID…
I wonder what solutions we might have with messy UUID, different admin and or users of NC with NS ldap user.
Q, has anyone tried the authetik with AD instead of. LDAP
I’d seen that, but kind of glanced over it, but a closer look suggested trying different options. I’d had it set to subject mode “based on the User’s UUID”, but tried all the other options. Each of them created a different account; none of them connected with the account used/created when I just logged in through the Nextcloud interface. Here’s what I ended up with in my data directory:
[root@ns8 data]# ls
74b3296d-72fc-4418-b6e7-d8f681187d22 appdata_ocyd4hwrnkva
942854a133ecc168e9d84bd3c57de4107b7fd230a07d36af225fcd763502eb9e cc94ae7a-c11e-4e08-8b7e-b88d0b5b3a48
94fe6d40389257ea9d58404c2c52c51a5170f54bb85faf594e9ab48fc531e99a e7eb0faf936450e4fca49d67041bd7864ddd9c8582a9c92d8ad4ba8e8483c014
95042fc412af1903f343e1e41dce6d177ae321373ccda65db7a3eae5995e384e files_external
a1548bc9ff2768b334be34aa289c8356f483209ba4219d6f63ff2e4b73dec27c index.html
admin nextcloud.log
[root@ns8 data]#
cc94ae7a-c11e-4e08-8b7e-b88d0b5b3a48 is the one that was created when I logged in as user fred through Nextcloud itself. 74b3296d-72fc-4418-b6e7-d8f681187d22 was created when I logged in via Authentik using the UUID. The other long hex strings were based on ID, username, Email, UPN, or hashed ID.
I’d also note that the LDAP sync still seems flaky. And I’m seeing events in the Authentik log that look like:
{
"pk": "a6cffeb7-7153-45ad-a9ae-5dcd70acc24b",
"user": {},
"action": "configuration_error",
"app": "authentik.sources.ldap.sync.base",
"context": {
"source": {
"pk": "9ef1d25d196f42eba256378b95390d62",
"app": "authentik_sources_ldap",
"name": "ns8",
"model_name": "ldapsource"
},
"mapping": {
"pk": "00fafe2f03f5495991d8f06d7ba714f6",
"app": "authentik_sources_ldap",
"name": "authentik default LDAP Mapping: DN to User Path",
"model_name": "ldappropertymapping"
},
"message": "Failed to evaluate property-mapping: 'authentik default LDAP Mapping: DN to User Path'"
},
"created": "2024-03-28T19:35:20.010Z",
"expires": "2025-03-28T19:35:20.006Z",
"brand": {
"pk": "a155ea208c0c48bbb599d96f9ec4392c",
"app": "authentik_brands",
"name": "Brand fallback",
"model_name": "brand"
}
}
and
{
"pk": "de78d506-b414-4ef3-b646-443717738131",
"user": {},
"action": "system_task_exception",
"app": "authentik.events.system_tasks",
"context": {
"message": "Task notification_transport encountered an error: Traceback (most recent call last):\n File \"/ak-root/venv/lib/python3.12/site-packages/celery/app/trace.py\", line 477, in trace_task\n R = retval = fun(*args, **kwargs)\n ^^^^^^^^^^^^^^^^^^^^\n File \"/ak-root/venv/lib/python3.12/site-packages/celery/app/trace.py\", line 760, in __protected_call__\n return self.run(*args, **kwargs)\n ^^^^^^^^^^^^^^^^^^^^^^^^^\n File \"/ak-root/venv/lib/python3.12/site-packages/celery/app/autoretry.py\", line 60, in run\n ret = task.retry(exc=exc, **retry_kwargs)\n ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n File \"/ak-root/venv/lib/python3.12/site-packages/celery/app/task.py\", line 736, in retry\n raise_with_context(exc)\n File \"/ak-root/venv/lib/python3.12/site-packages/celery/app/autoretry.py\", line 38, in run\n return task._orig_run(*args, **kwargs)\n ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n File \"/authentik/events/tasks.py\", line 126, in notification_transport\n raise exc\n File \"/authentik/events/tasks.py\", line 122, in notification_transport\n transport.send(notification)\n File \"/authentik/events/models.py\", line 346, in send\n return self.send_email(notification)\n ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n File \"/authentik/events/models.py\", line 494, in send_email\n raise NotificationTransportError(exc) from exc\nauthentik.events.models.NotificationTransportError: [Errno 111] Connection refused"
},
"created": "2024-03-28T19:35:28.488Z",
"expires": "2025-03-28T19:35:28.484Z",
"brand": {
"pk": "a155ea208c0c48bbb599d96f9ec4392c",
"app": "authentik_brands",
"name": "Brand fallback",
"model_name": "brand"
}
}
I recognise the “celery” entries. Did not pay attention to it yet.