Feature Request: LDAP Integration about davis HOT 21 CLOSED

Hi @IronTooch
This should rather be done at the sabre/dav level.
An attempt was made some time ago, but I don't think anybody tried to finish this work: sabre-io/dav#838

from davis.

See also sabre-io/Baikal#321 on Baikal (which is also using sabre/dav)

from davis.

Oh, for sure, integrating at the Sabre level is certainly better. But since they don't seem inclined to integrate it, it might be able to be scaffolded at this layer instead with an integration that makes regular users from an LDAP source. That being said, if you want to close this for the same reason the Baikal team closed theirs, I understand.

from davis.

I'm fine with leaving it open if someone feels like trying — I'll gladly review a PR.

Unfortunately I myself have little time and no interest in LDAP as I don't use it on a day-to-day basis.

from davis.

Oh, just realized this may be helpful here too:
https://github.com/Excision-Mail/ansible-baikal/blob/main/files/baikal-0.9.1-ldap-auth-and-smtp.patch

from davis.

Hi @IronTooch
I could give it a go, since the patch provided by @reven is quite close to what an actual implementation might look like and I have some free time to work on Davis.

Would you be able to test it with a real LDAP server (I don't have any at hand) if I create a branch for that ?

from davis.

Sure can, I have a LDAP server available.

from davis.

Great, will keep you updated really soon !

from davis.

See #61 — if you can test it and tell me if everything is nominal, that would be awesome @IronTooch !

from davis.

Okay, so does not work at the moment, but I'm kind of at a loss on how to troubleshoot. @tchapi , can you tell me where the relevant logs would be?

I can say the most likely reason why is because the given variables don't seem to have any way of setting the Bind user for LDAP, so there's no way to authenticate to search / enumerate the directory. I tried digging into the pull req, but I couldn't figure out where that would go. src/Services/LDAPAuth.php has an LDAP Open call that seems to ask for a user name, but I'm not sure where it's set. My understanding of Bind is that you have to auth to the server first, before seeing if the user in question is any good. I did try to just connect to the admin interface as a valid user in my directory, and that was unsuccessful (Username not found).

Here is the relevant data from an authenticated LDAP directory search:

test_user, virtual-groups, ldap.tucc.io
dn: cn=test_user,ou=virtual-groups,dc=ldap,dc=tucc,dc=io
goauthentik.io/ldap/superuser: false
cn: test_user
uid: 72c328974474361eb03f4a83568203fb1dbd722561e7e8968befbc4f8077fa69
sAMAccountName: test_user
gidNumber: 2009
objectClass: group
objectClass: groupOfUniqueNames
objectClass: goauthentik.io/ldap/group
objectClass: goauthentik.io/ldap/virtual-group
member: cn=test_user,ou=users,dc=ldap,dc=tucc,dc=io

from davis.

Also relevant Screenshot from Admin Interface

from davis.

Hi @IronTooch

Thanks for your test. I think you are trying to connect to the admin interface with your LDAP user, which is not possible (There is only one "admin dashboard" user, it's admin by default and it's configured in the env vars.

What you want to try is to connect to http://yourserver.org/dav with your credentials and see how it works. If it's successful, you will be able to browse your DAV objects in the browser. If not, you will see an XML error page

Tell me how it goes
Thanks

from davis.

Ah, I see! You're absolutely right, initially I was trying to connect too the admin interface. When I try to browse to the dav, unfortunately, still having no luck, but it's a different error:

<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
<s:sabredav-version>4.3.1</s:sabredav-version>
<s:exception>Error</s:exception>
<s:message>Call to undefined function App\Services\ldap_connect()</s:message>
</d:error>

I appreciate your patience too!

from davis.

Ok, this error seems to indicate that your PHP version was not compiled with LDAP. So you need to either reinstall it correctly, or add the module. I cannot really help you here since it really depends on your platform ... but you should be able to find a tutorial for that. Ex. if you're on Debian: apt-get install php-ldap

from davis.

Okay, so now I'm getting the HTTP login screen, but the authentication is not operational:

I.e., when I type a user I know to be correct, it just re-presents me the login screen repeatedly, as opposed to allowing the user through.

Nothing of note in the following log locations:
/var/log/syslog
/var/log/nginx/mysite.error.log
/var/log/php7.4-fpm.log

Output of php -m

[PHP Modules]
calendar
Core
ctype
curl
date
dom
exif
FFI
fileinfo
filter
ftp
gettext
hash
iconv
intl
json
ldap
libxml
mbstring
mysqli
mysqlnd
openssl
pcntl
pcre
PDO
pdo_mysql
Phar
posix
readline
Reflection
session
shmop
SimpleXML
sockets
sodium
SPL
standard
sysvmsg
sysvsem
sysvshm
tokenizer
xml
xmlreader
xmlwriter
xsl
Zend OPcache
zip
zlib

[Zend Modules]
Zend OPcache

from davis.

Ok thanks. Several thoughts:

• you may find more logs in var/log/* in the Symfony installation, maybe something worth it in there
• any log on the LDAP side, by any chance (like "password is not good" or "user does not exist" for instance) ?
• have you tried with a [email protected] type of login instead of just user ?

from davis.

Re: I tried to run a standard openldap container locally (with https://hub.docker.com/r/bitnami/openldap/) with the default configuration, and I can login with admin / adminpassword.

The configuration I used on Davis is:

LDAP_AUTH_URL="ldap://localhost:1389"
LDAP_DN_PATTERN="cn=%u,dc=example,dc=org"
LDAP_MAIL_ATTRIBUTE="mail"
LDAP_AUTH_USER_AUTOCREATE=true

It's the first time I work with LDAP so I don't really know if it's good but apart from a problem with ldap_read() (stating that it cannot find such object, which is likely a configuration problem on the LDAP side), I could login without problem.

I've added a try/catch and my setup with the default openldap container works (I can login with admin, and it autocreates the user)

from davis.

Okay, a working pattern definitely helped. I didn't include the port on the LDAP connection (assumed it would default to 389), and my DN pattern was off. I'm now able to log in, though some things render oddly at the moment (see screenshot).

This was my (working) config:

LDAP_AUTH_URL="ldap://10.1.40.5:389"
LDAP_DN_PATTERN="cn=%u,ou=users,dc=ldap,dc=tucc,dc=io"
LDAP_MAIL_ATTRIBUTE="mail"
LDAP_AUTH_USER_AUTOCREATE=true

That being said, I am able to see the new user in the Admin interface, so it looks good from my side.

I'm going to spin up a client instance to test, but on first shake, it looks like this works.

from davis.

Great ! This is fantastic.

On the screenshot, the only thing I see that is not rendered correctly is the Symfony debug bar at the bottom of the page — which is normal (the page is rendered via a subtly different way than normal pages) and not really a concern (it's only displayed when the app is in dev mode): this will not happen in production mode.

from davis.

So, would the end goal of all of this be to ultimately get "LDAP" as an option for the drop-down in the "WebDAV Authentication Type" drop-down menu under "System Settings"?

from davis.

Hmmm ... what dropdown are you talking about ? 🤔

from davis.