https://github.com/lldap/lldap logo
Powered by
PopeRigby - I'm having a lot of trouble getting...
# troubleshooting
p
I'm having a lot of trouble getting ownCloud Infinite Scale working. This is my OCIS config:
Copy code
env
OCIS_LDAP_URI="ldap://localhost:3890"
OCIS_LDAP_INSECURE="true"
OCIS_LDAP_BIND_DN="uid=ocis,ou=people,dc=haddock,dc=cc"
OCIS_LDAP_BIND_PASSWORD="REDACTED"
IDP_LDAP_LOGIN_ATTRIBUTE="uid"
IDP_LDAP_UUID_ATTRIBUTE="entryuuid"
LDAP_LOGIN_ATTRIBUTES="uid"
OCIS_LDAP_GROUP_BASE_DN="ou=groups,dc=haddock,dc=cc"
OCIS_LDAP_GROUP_FILTER="(objectclass=groupOfUniqueNames)"
OCIS_LDAP_GROUP_OBJECTCLASS="groupOfUniqueNames"
OCIS_LDAP_GROUP_SCHEMA_GROUPNAME="uid"
OCIS_LDAP_GROUP_SCHEMA_ID="uid"
OCIS_LDAP_USER_OBJECTCLASS="inetOrgPerson"
OCIS_LDAP_USER_FILTER="(objectclass=inetOrgPerson)"
OCIS_LDAP_USER_SCHEMA_ID="entryuuid"
OCIS_LDAP_USER_ENABLED_ATTRIBUTE="uid"
GRAPH_LDAP_SERVER_WRITE_ENABLED="false"
GRAPH_LDAP_REFINT_ENABLED="false"
This is the output in my logs when attempting to login: https://gist.github.com/poperigby/451f9e1bd40ea724494294b70c65674b
t
Login fails?
p
t
It looks like you're trying to log in as "cassidy" and it finds a user named cassidy
But then it looks for a group named cassidy
p
I get this OCIS error: 
{"level":"error","service":"proxy","error":"failed to get userinfo: 401 Unauthorized: {}\n","authenticator":"oidc","path":"/ocs/v1.php/cloud/user","time":"2024-09-22T19:02:05-07:00","message":"failed to authenticate the request"}
t
And finds none
p
Hmm, well it shouldn't be doing that 🤔
I just have my users as part of 
lldap_users
.
And I have the 
ocis
user as part of 
lldap_strict_readonly
.
Is it because the group filter is 
"(objectclass=groupOfUniqueNames)"
? Will that be a unique group for each user?
t
If I'm reading correctly the bind worked fine
Very funny PFP btw
Bc of line 21 and because it continued with the search for your user
p
I have no idea why it's not letting me login then 😕 .
Thanks lol
t
Line 43 is sus
Looks related to OCIS_LDAP_GROUP_SCHEMA_MEMBER
if fact that may be what you want to set instead of GROUP_FILTER
or at least in addition to it
Actually nvm it looks like "member" is a field of groups containing the members so should be working
But line 42 it's on user
And seems to find nothing
The under 48 get_groups_list it does find a group that you're a member of
p
Yeah, the group it returns looks right. If the bind worked, why am I being denied?
t
Well the bind is just a login with the oidc user so you can query the database
Then ocis looks for a user with your name and finds one
p
Could it be because of inetOrgPerson? What even is that?
t
I think line 38 is a query for groups that contain you, and get_user_list and get_group_list are both internal functions (I assume LLDAP calls them for all queries because it doesn't actually implement a full LDAP database underneath, and possibly since the query sent by ocis doesn't limit the group search to ou=groups which might clue LLDAP that it should only call the get_groups_list function
so as expected it finds no users that match your group query
which BTW is member=
which words on groups, but not people so it makes sense because people don't have the member field
then it does find a group containing you (line 58)
inetOrgPerson is a type of object in an LDAP database
an LDAP database contains different types of objects with different attributes e.g. a person could have a name, and email, etc
while a group could have a name and list of members
p
Ah, I see.
t
with an LDAP client you can see all that info e.g.
ldapsearch -H ldap://localhost:54308 -D 'cn=authelia,ou=people,dc=example,dc=com' -w password -b 'dc=example,dc=com'
there authelia is the account I'm using to bind
Copy code
dn: uid=admin,ou=people,dc=example,dc=com
objectclass: inetOrgPerson
objectclass: posixAccount
objectclass: mailAccount
objectclass: person
uid: admin
cn: Administrator
createtimestamp: 2024-09-22T03:01:04.742305307+00:00
entryuuid: 260b776f-c433-308e-8ec5-3cd88e62c789
that's one of the objects it returned and you can see all the fields
you can also see that it implements four objectclasses which can, I think, have overlapping fields
so person could alias inetOrgPerson
Copy code
# lldap_strict_readonly, groups, example.com
dn: cn=lldap_strict_readonly,ou=groups,dc=example,dc=com
objectclass: groupOfUniqueNames
uid: lldap_strict_readonly
cn: lldap_strict_readonly
member: uid=authelia,ou=people,dc=example,dc=com
uniquemember: uid=authelia,ou=people,dc=example,dc=com
entryuuid: baa2dc4c-fd65-3d64-997a-123dabc8c98d
there is another object returned (this time a group object) and you can see that authelia is a member
from your log it looks like multiple logins were attempted and 11-55 is a single login
strangely it looks like everything worked
it returned your user for the can you find this user query
and it returned ldap_users for the what groups is this user in query
p
So is it an OCIS bug or something or did I misconfigure something?
t
you might want to make sure you configured all the necessary variables in OCIS: https://owncloud.dev/ocis/identity-provider/ldap-active-directory/#configuration-example
I notice the disabled_user setting isn't in your config, but by default it's enabled
so if it looked for some "is this user enabled" field in the inetOrgPerson returned for you and it found nothing, it might deny you access
p
Mmm, yeah good idea.
t
to groups in their case
and looks like a few other fields not in your config
p
I set it to 
none
and it's still not working 😐
I don't know, should I ask the OCIS devs?
t
Is the logging info any different? for OCIS or LLDAP?
I'm guessing LLDAP should look much the same
also before that I'd try getting yours as close to the LLDAP example config for OCIS as possible
and see if it works
This page has all the config settings as a reference or in case something from the LLDAP config is out of date: https://doc.owncloud.com/ocis/next/deployment/services/s-list/users.html
also how is OCIS?
p
I don't think so but here's the updated log: https://gist.github.com/poperigby/21fddd8c088f0b7a264bc3018c393c90
t
I've been considering running it since forever ago, but last I checked it was still in alpha
looks about the same
p
Well I'm trying to get this working before actually using it lol, but it seems really cool. They recently added a POSIX backend so the files are stored normally instead of in binary blobs.
t
that's AMAZING!
I've been looking for something that if the server crashes I can take out the hard drive and still see the files
without lots of extra work
p
Yeah, this makes it better than Seafile in my opinion. Also, the OIDC/LDAP support is very nice.
t
yep and seafile is difficult to scale
p
I compared them and mine is pretty much identical except for non-LDAP related options.
I've heard the mobile apps are also kinda garbage and they don't take security that seriously.
t
plus I'm not keen on exposing a C webapp to the internet
"failed to get userinfo" makes me think it's definitely looking for some field of inetOrgPerson that LLDAP isn't giving it
n
Agree with @themooer1 , the LDAP query looks good, it got the user and group. Is there a debug/verbose logs mode in OwnCloud ?
x
let say i had tinkering with ocis before and worked that time
Copy code
version: "3.8"
services:
  app:
   image: owncloud/ocis:latest
   entrypoint:
      - /bin/sh
   command: ["-c", "ocis init || true; ocis server"]
   volumes:
     - ocis-config:/etc/ocis
     - ocis-data:/var/lib/ocis
   ports:
     - 9200:9200
   environment:
     OCIS_LOG_LEVEL: debug
     OCIS_INSECURE: true
     OCIS_ADMIN_USER_ID: "dedyms"  #https://github.com/owncloud/ocis/issues/3808
     PROXY_HTTP_ADDR: 0.0.0.0:9200
     OCIS_URL: https://ocis.ddyms.space
     AUTH_BASIC_AUTH_PROVIDER: ldap
     LDAP_URI: ldap://192.168.0.2:3890
     LDAP_INSECURE: true
     LDAP_BIND_DN: "cn=readonly,ou=people,dc=example,dc=com"
     LDAP_BIND_PASSWORD: ldapreadonly
     LDAP_LOGIN_ATTRIBUTES: "uid"
     LDAP_USER_BASE_DN: "ou=people,dc=example,dc=com"
     LDAP_GROUP_BASE_DN: "ou=groups,dc=example,dc=com"
     LDAP_USER_FILTER: "(&(objectClass=person)(memberOf=cn=lldap_ocis,ou=groups,dc=example,dc=com))"
     LDAP_GROUP_FILTER: "(cn=lldap_ocis,ou=groups,dc=example,dc=com)"
     IDP_LDAP_URI: ldap://192.168.0.2:3890
     IDP_LDAP_LOGIN_ATTRIBUTE: "uid"
     IDP_LDAP_UUID_ATTRIBUTE: "uuid"
     GRAPH_IDENTITY_BACKEND: ldap
     GRAPH_LDAP_SERVER_WRITE_ENABLED: false
#     PROXY_ENABLE_BASIC_AUTH: true
     OCIS_RUN_SERVICES: app-registry,app-provider,audit,auth-basic,auth-machine,frontend,gateway,graph,groups,idp,nats,notifications,ocdav,ocs,proxy,search,settings,sharing,storage-system,storage-publiclink,storage-shares,storage-users,store,thumbnails,users,web,webdav
     LDAP_USER_SCHEMA_ID: uuid
     LDAP_GROUP_SCHEMA_ID: uuid


volumes:
  ocis-config:
  ocis-data:
p
@xaverius666 I updated my config to be inline with yours, but it's still not working. Made a post with the updated info: https://central.owncloud.org/t/cant-get-ocis-working-with-lldap/50697
Oh, and I posted the verbose OCIS logs in there
Why is it referring to the builtin libregraph IDM?
n
It's trying to log in as "uid=reva,ou=sysusers,o=libregraph-idm", why?
p
I have no clue. It shouldn't be.
n
{"level":"debug","service":"users","pkg":"rgrpc","traceid":"2cd8bc8d70de43b99eea59b94d9fee77","backend":"ldap","basedn":"ou=users,o=libregraph-idm","filter":"(&(objectclass=inetOrgPerson)(uid=cassidy)(!(ownCloudUserEnabled=FALSE)))","scope":2,"time":"2024-09-23T15:42:32-07:00","line":"github.com/cs3org/reva/v2@v2.19.7/pkg/utils/ldap/identity.go:217","message":"LDAP Search"} {"level":"debug","service":"users","pkg":"rgrpc","traceid":"2cd8bc8d70de43b99eea59b94d9fee77","backend":"ldap","error":"LDAP Result Code 64 \"Naming Violation\": Not a subtree of the base tree","userfilter":"(&(objectclass=inetOrgPerson)(uid=cassidy)(!(ownCloudUserEnabled=FALSE)))","time":"2024-09-23T15:42:32-07:00","line":"github.com/cs3org/reva/v2@v2.19.7/pkg/utils/ldap/identity.go:220","message":"Error looking up user by filter"} {"level":"debug","service":"users","pkg":"rgrpc","traceid":"2cd8bc8d70de43b99eea59b94d9fee77","error":"error: not found: ","time":"2024-09-23T15:42:32-07:00","line":"github.com/cs3org/reva/v2@v2.19.7/pkg/user/manager/ldap/ldap.go:140","message":"GetUserByClaim"}
p
It definitely shouldn't be doing that 😕. I'm not sure why it's not working if @xaverius666's version is working. I'm also using OIDC, but I wouldn't think that would be a problem. Authelia is replacing the builtin identity provider and LLDAP is replacing the builtin identity manager.
t
That user is one of three created by the IDM service https://doc.owncloud.com/ocis/next/deployment/services/s-list/idm.html
It seems you're not running IDM but reva is expecting that user to exist when querying your LDAP
Are there any docs on what reva needs with LDAP and how to give out credentials it needs to access LDAP?
Does it think it's using the internal IDM LDAP because your LDAP server is running on localhost?
Are you running this whole setup in docker compose?
p
No on NixOS. I guess it needs those three users for the service users to communicate with the IDM? That's never mentioned in the docs as far as I can tell.
t
It says IDM creates those three users. Not required that they exist, but you probably need to have other users for those services to access the LDAP
p
Well maybe only the builtin IDM creates them?
n
The interesting thing is that above you can see the request to LLDAP and "authentication succeeded"
Do you need the reva plugin? Is it something you can disable?
Wait, no, I must have hallucinated it
t
The request for Cassidy or the one for reva? Even if Cassidy looks like it succeeded, line 56 looks like it starts a new session containing only the bad request which fails due to a naming violation which I guess is lldap's way of saying I don't pretend to have that ou
Oh haha
n
(surprise! I'm not actually a person, just an LLM!)
I'm on my phone, reading json logs is... interesting
There is an "authentication succeeded", but it's not after an LDAP query (from what I can tell)
Can you configure the base dn/bind dn for reva?
t
Lol same
p
I have no clue. The docs are kinda garbage.
x
had a bit of free time and tried again that old config, resulting 500 error, ocis said
Copy code
app-1  | {"level":"error","service":"idp","error":"ldap identifier backend logon connect error: LDAP Result Code 64 \"Naming Violation\": Not a subtree of the base tree","time":"2024-09-25T04:24:42Z","line":"github.com/owncloud/ocis/v2/ocis-pkg/log/logrus_wrapper.go:50","message":"identifier failed to logon with backend"}
when it used to be work, man...
p
🥲
2 Views
PreviousNext
Powered by