glauth ldap backend
-
Im looking to leverage glauth for a simple LDAP backend. I have configured this independently in several of the apps but I was hoping to be able to sync this ldap server with cloudron and just sync the apps with the cloudron server users (ldap). However Im getting the following error and I was wondering if there is an easy way to support non paged ldap results.
Nov 09 14:26:02 box:tasks update 10: {"percent":100,"result":null,"error":{"stack":"BoxError: missing paged control\n at SearchPager.<anonymous> (/home/yellowtent/box/src/externalldap.js:122:48)\n at SearchPager.emit (node:events:526:28)\n at SearchPager.emit (/home/yellowtent/box/node_modules/ldapjs/lib/corked_emitter.js:44:33)\n at SearchPager._onEnd (/home/yellowtent/box/node_modules/ldapjs/lib/client/search_pager.js:103:12)\n at EventEmitter.emit (node:events:526:28)\n at sendResult (/home/yellowtent/box/node_modules/ldapjs/lib/client/client.js:1194:22)\n at messageCallback (/home/yellowtent/box/node_modules/ldapjs/lib/client/client.js:1222:16)\n at Parser.onMessage (/home/yellowtent/box/node_modules/ldapjs/lib/client/client.js:888:14)\n at Parser.emit (node:events:526:28)\n at Parser.write (/home/yellowtent/box/node_modules/ldapjs/lib/messages/parser.js:107:8)","name":"BoxError","reason":"External Error","details":{},"message":"missing paged control","nestedError":{"stack":"PagedError: missing paged control\n at SearchPager._onEnd (/home/yellowtent/box/node_modules/ldapjs/lib/client/search_pager.js:93:17)\n at EventEmitter.emit (node:events:526:28)\n at sendResult (/home/yellowtent/box/node_modules/ldapjs/lib/client/client.js:1194:22)\n at messageCallback (/home/yellowtent/box/node_modules/ldapjs/lib/client/client.js:1222:16)\n at Parser.onMessage (/home/yellowtent/box/node_modules/ldapjs/lib/client/client.js:888:14)\n at Parser.emit (node:events:526:28)\n at Parser.write (/home/yellowtent/box/node_modules/ldapjs/lib/messages/parser.js:107:8)\n at Socket.onData (/home/yellowtent/box/node_modules/ldapjs/lib/client/client.js:875:22)\n at Socket.emit (node:events:526:28)\n at addChunk (node:internal/streams/readable:315:12)","name":"PagedError","message":"missing paged control"}}} missing paged control at SearchPager.<anonymous> (/home/yellowtent/box/src/externalldap.js:122:48) at SearchPager.emit (node:events:526:28) at SearchPager.emit (/home/yellowtent/box/node_modules/ldapjs/lib/corked_emitter.js:44:33) at SearchPager._onEnd (/home/yellowtent/box/node_modules/ldapjs/lib/client/search_pager.js:103:12) at EventEmitter.emit (node:events:526:28) at sendResult (/home/yellowtent/box/node_modules/ldapjs/lib/client/client.js:1194:22) at messageCallback (/home/yellowtent/box/node_modules/ldapjs/lib/client/client.js:1222:16) at Parser.onMessage (/home/yellowtent/box/node_modules/ldapjs/lib/client/client.js:888:14) at Parser.emit (node:events:526:28) at Parser.write (/home/yellowtent/box/node_modules/ldapjs/lib/messages/parser.js:107:8) -
Yeah, we haven't tested it against glauth. Looks like it may not support pagination from my reading of the logs. Maybe you can open a feature request to support this because without testing it's hard to tell what issues one might face.
-
@girish because I have such a low user count currently, I think I should be OK with my pagination workaround.
However, Im having a bit of a time trying to get the LDAP authentication to succeed. It works for the user I specify as the BindDN/username portion of the Connect to External Directory when this user is in the form of user@domain.tld. The search succeeds and returns the user account for testing authentication but the subsequent bind to validate authentication fails as I cannot specify user@domain.tld but instead it attempts to authenticate as just user.
On the glauth side it fails as its looking for the the BindDN to contain the BaseDN string. Is the BaseDN field in the LDAP authentication getting applied because it appears it is not when looking at
/home/yellowtent/box/src/externalldap.js.Is there anyway to append the BaseDn to the BindDn in these cases?
-
@prusaman what is the dn of user's in glauth? The externalldap logic first tries to locate a user with the filter
username=<username>. Then, it will authenticate using the dn from the previous search.The baseDN is only used for searching and not for auth.
-
wget https://raw.githubusercontent.com/glauth/glauth/e7195ed983715383bd5df1dc521f8c17d34d6a50/v2/sample-simple.cfg -O /tmp/ldap.cfgthe releases section has precompiled bins here https://github.com/glauth/glauth/releases/
if using docker
docker run -d --name glauth -p 389:3893 -v /tmp/ldap.cfg:/app/config/config.cfg glauth/glauth-pluginsinside cloudron
Provider: other Server URL: ldap://127.0.0.1:389 BseDN: dc=glauth,dc=com Filter: (objectClass=posixAccount) Username Field: uid Bind DN: serviceuser,dc=glauth,dc=com | cn=serviceuser,ou=svcaccts,dc=glauth,dc=com # either work Bind Password: mysecretsave and synchronize
user accounts load into users section correctly. Logging into the accounts produces the following error in glauth:
15:52:23.394913 findUser ▶ WARN 00c "level"=2 "msg"="BindDN not part of our BaseDN" "basedn"="dc=glauth,dc=com" "binddn"="johndoe"pcap:
15:52:23.394496 IP localhost.60316 > localhost.ldap: Flags [P.], seq 1:28, ack 1, win 512, options [nop,nop,TS val 293 1810893 ecr 2931810893], length 27 0x0000: 4500 004f 6b42 4000 4006 d164 7f00 0001 E..OkB@.@..d.... 0x0010: 7f00 0001 eb9c 0185 6c39 a418 9a16 2259 ........l9...."Y 0x0020: 8018 0200 fe43 0000 0101 080a aebf e24d .....C.........M 0x0030: aebf e24d 3019 0201 0160 1402 0103 0407 ...M0....`...... 0x0040: 6a6f 686e 646f 6580 0664 6f67 6f6f 64 johndoe..dogoodldapsearch -LLL -H ldap://localhost:389 -D serviceuser,dc=glauth,dc=com -w mysecret -x -bdc=glauth,dc=com
succeedsldapsearch -LLL -H ldap://localhost:389 -D serviceuser -w mysecret -x -bdc=glauth,dc=com
ldap_bind: Invalid credentials (49)ldapsearch -LLL -H ldap://localhost:3893 -D johndoe,dc=glauth,dc=com -w dogood -x -bdc=glauth,dc=com '(objectClass=posixAccount)'
succeeds if I add[[users.capabilities]] action = "search" object = "*"but I still get
ldapsearch -LLL -H ldap://localhost:389 -D johndoe -w dogood -x -bdc=glauth,dc=com '(objectClass=posixAccount)'
ldap_bind: Invalid credentials (49)What Im looking at is potentially adding an External Directory Provider that simply appends "dc=glauth,dc=com" to the result of the search prior to the bind.
ie: johndoe@dc=glauth,dc=com or johndoe@glauth.com rather than just johndoe
-
@prusaman not 100% sure I get the issue. But it seems like the user bind from Cloudron to your glauth instance fails. Generally what our (in this case client side) implementation does is to search for a user record, after a potential admin bind if needed. Then once a user record is found, we take the
dnof that record (which was delivered from your server in the previous search call) and just use it as bind identifier. So maybe you can reconfigure your glauth instance to return adnin the user record which matches what your bind call expects? -
@nebulon yeah this exactly. I can use the DN instead of the UID but the problem then became the tolower() function on the cloudron side would fail. Currently I patched glauth to stop checking for bindDN being part of the baseDN but I dont think its the ideal long term solution. Im not sure what portion of your user base is using glauth and imagine its probably fairly small but it would be a big quality of life improvement for me.
Cheers for the assistance
-
@nebulon anything changed recently related to this? I patched glauth and authentication was working for the last few days. I rebooted the system to update OS packages and now auth is no longer working. Nothing else has changed. Just trying to limit variables and preserve the limited hair I have remaining.
Cheers
-
