Hello, I want to use my existing Samba4 LDAP for Owncloud without any schema changes (don’t add Owncloud schema), but can’t get it to work.
Is there any example config available that works? Thank you.
Edit:
Auth looks like it’s ok, because a wrong password shows it’s wrong. But immediately got a message “you will be logout for security reason” and in the debug message, there is a “could not get user by claim username with value my_username : error authenticating user”
Can you share a bit more about your configuration? Especially the LDAP related settings you have done? Otherwise it will be hard to guess what’s going wrong.
To get it working with an external LDAP server you need to get the Attribute mappings for users and groups defined correctly. These are basically the LDAP_USER_SCHEMA_* and LDAP_GROUP_SCHEMA_* related env var described here:
The main difficulty will probably be to select a good attribute for the unique user id (LDAP_USER_SCHEMA_ID) and the unique group id (LDAP_GROUP_SCHEMA_ID). Those need to be unique identifiers that stay the same for the whole lifetime of a user. I don’t know the default schema of the samba 4 LDAP server but I guess it will maintain some unique identifier per user and group.
Hello,
thank you for your answer. I also found this site on the weekend and it helped a bit. Here is my LDAP config:
LDAP_URI=ldap://ldapserver.example.com:389
LDAP_INSECURE=true
LDAP_BIND_DN=cn=readonly,cn=users,dc=example,dc=com
LDAP_BIND_PASSWORD=test
LDAP_GROUP_BASE_DN=ou=groups,dc=example,dc=com
LDAP_GROUP_FILTER=
LDAP_GROUP_OBJECTCLASS=group
LDAP_GROUP_SCHEMA_ID=objectGUID
LDAP_GROUP_SCHEMA_ID_IS_OCTETSTRING=true
LDAP_USER_BASE_DN=ou=users,ou=accounts,dc=example,dc=com
LDAP_USER_FILTER=
LDAP_USER_OBJECTCLASS=user
LDAP_USER_SCHEMA_ID=objectGUID
LDAP_USER_SCHEMA_ID_IS_OCTETSTRING=true
LDAP_USER_SCHEMA_USERNAME=sAMAccountName
LDAP_LOGIN_ATTRIBUTES=sAMAccountName
IDP_LDAP_LOGIN_ATTRIBUTE=sAMAccountName
IDP_LDAP_UUID_ATTRIBUTE=objectGUID
IDP_LDAP_UUID_ATTRIBUTE_TYPE=text
GRAPH_LDAP_SERVER_WRITE_ENABLED=false
GRAPH_LDAP_REFINT_ENABLED=false
OCIS_ADMIN_USER_ID=myadminusername
Sambas LDAP is basically Active Directory and my feeling is, that there is something wrong in my *_SCHEMA_* configuration and maybe with OCIS_ADMIN_USER_ID. Also I don’t understand GRAPH_LDAP_REFINT_ENABLED correctly.
Can you set the log level to debug (OCIS_LOG_LEVEL=debug) and share the full log of a failed login attempt?
OCIS_ADMIN_USER_ID needs to be set to the ID ( objectGUID attribute in your case) of the user that you want to give admin privileges in oCIS. (This is basically needed for bootstrapping purposes, to have at least one admin user. After that, this user can give admin privileged to other users by assigning them the “admin” role.
GRAPH_LDAP_REFINT_ENABLED is still pretty new (it’s not available in the 2.0 release) and is only relevant for managing (as in create/edit/delete) users via the ocis web interface (which won’t work with and external LDAP server not using the owncloud specific schema.)
Using another attribute than objectGUID and set both *-OCTETSTRING to false let me login. I always felt that the content of objectGUID is garbage in the OCIS logs. This config let me login:
LDAP_URI=ldap://ldapserver.example.com:389
LDAP_INSECURE=true
LDAP_BIND_DN=cn=readonly,cn=users,dc=example,dc=com
LDAP_BIND_PASSWORD=test
LDAP_GROUP_BASE_DN=ou=groups,dc=example,dc=com
LDAP_GROUP_FILTER=
LDAP_GROUP_OBJECTCLASS=group
LDAP_GROUP_SCHEMA_ID=cn
LDAP_GROUP_SCHEMA_ID_IS_OCTETSTRING=false
LDAP_USER_BASE_DN=ou=users,ou=accounts,dc=example,dc=com
LDAP_USER_FILTER=
LDAP_USER_OBJECTCLASS=user
LDAP_USER_SCHEMA_ID=sAMAccountName
LDAP_USER_SCHEMA_ID_IS_OCTETSTRING=false
LDAP_USER_SCHEMA_USERNAME=sAMAccountName
LDAP_LOGIN_ATTRIBUTES=sAMAccountName
IDP_LDAP_LOGIN_ATTRIBUTE=sAMAccountName
IDP_LDAP_UUID_ATTRIBUTE=sAMAccountName
IDP_LDAP_UUID_ATTRIBUTE_TYPE=text
GRAPH_LDAP_SERVER_WRITE_ENABLED=false
GRAPH_LDAP_REFINT_ENABLED=false
OCIS_ADMIN_USER_ID=myadminusername
But it looks like “homefolder” for my user won’t be created or can’t be accessed. I can browse to my preferences, browse to admin page, see all other LDAP users and so on, but can’t upload any files or create folders. It’s just a rotating circle, no menu entries.
In debug logs there are some red colored logs:
xattr.get /var/lib/ocis/storage/metadata/spaces/f1/bdd61a-da7c-49fc-8203-0558109d1b4f/nodes/f1/bd/d6/1a/-da7c-49fc-8203-0558109d1b4f user.ocis.quota: no data available
xattr.get /var/lib/ocis/storage/metadata/spaces/f1/bdd61a-da7c-49fc-8203-0558109d1b4f/nodes/f1/bd/d6/1a/-da7c-49fc-8203-0558109d1b4f user.ocis.treesize: no data available
xattr.get /var/lib/ocis/storage/metadata/spaces/f1/bdd61a-da7c-49fc-8203-0558109d1b4f/nodes/f1/bd/d6/1a/-da7c-49fc-8203-0558109d1b4f user.ocis.quota: no data available
Set this variables doesn’t help:
OCIS_SPACES_MAX_QUOTA=0
FRONTEND_MAX_QUOTA=0
STORAGE_USERS_OCIS_MAX_QUOTA=0
Same happens when login with another user from my LDAP. Trying OCIS with local admin and demo users works.
I use owncloud/ocis:latest docker image because owncloud/ocis:2 always shows wrong configuration with my LDAP config.
There is indeed a bug in our graph service regarding the handling of binary encoded UUID attributes (like objectGUID). I just opened an issue for that (LDAP backend for graph API doesn't handle binary UUID correctly · Issue #5815 · owncloud/ocis · GitHub).
Using the cn attribute as the ID can be a bit problematic. As we require the ID to be constant over the whole lifetime of a user. If you’d rename the user when using cn as the ID attribute, it would be no longer able to access its files. Also IIRC our storage backend has a certain restriction on the minimum length that the uid must have.
Thanks for explain it und opening the issue!
I’m aware about renaming the user. I’ve tried this to narrow down to find any cause and also to have some success.
The problem should be fixed in ocis 3.0.0-rc3. A configuration that worked for us with AD and Samba4 is basically this: LDAP - Active Directory | ownCloud
Thanks, but unfortunately still doesn’t work with objectGUID. First a redirect message, then a message “Logged out, You were automatically logged out for security reasons.”
In the logs I see content of objectGUID ByteValues, which is the same like in my Samba4 AD.
Is the example snippet really working? When adding OCIS_ prefix to all LDAP_ env variables, for example OCIS_LDAP_URI instead of LDAP_URI, I can’t login at all.
Btw, I use owncloud/ocis:3.0.0-rc.3 image.
I would need to see the logs to undestand what’s going on. Can you please upload logs (either here, or in a new github issue), with GRAPH_LOG_LEVEL=debug, IDP_LOG_LEVEL=debug, PROXY_LOG_LEVEL=debug and USERS_LOG_LEVEL=debug?
Sorry, I got sick.
When using OCIS_ prefix in LDAP settings, I get 500 in login page and this log message:
2023-06-25T06:16:05Z ERR identifier failed to logon with backend error="ldap identifier backend logon connect error: LDAP Result Code 49 \"Invalid Crede
ntials\": 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1" line=github.com/owncloud/ocis/v2/ocis-pkg/log/logrus_
wrapper.go:50 service=idp
When using LDAP_xxx without OCIS_ prefix, it looks like login is ok, but shows “authentication failed” in the login page and the log file prints:
2023-06-25T05:31:54Z DBG identifier failed to update user data in logon request error="ldap identifier backend get user error: LDAP Result Code 201 \"Fi
lter Compile Error\": ldap: error reading rune at position 32" line=github.com/owncloud/ocis/v2/ocis-pkg/log/logrus_wrapper.go:50 service=idp
(...)
2023-06-25T05:31:55Z ERR IdentifierIdentityManager: fetch failed to get user from userID error="ldap identifier backend get user error: LDAP Result Code
201 \"Filter Compile Error\": ldap: error reading rune at position 32" line=github.com/owncloud/ocis/v2/ocis-pkg/log/logrus_wrapper.go:50 service=idp
What is the difference between OCIS_ prefix in LDAP_xxx lines and no OCIS_ prefix? Also the example shows in most lines exclamation marks, but not all. In Docker env file, exclamation marks are not needed if it’s in key=value syntax AFAIK.
I use just LDAP_xxx and not OCIS_LDAP_xxx because of this example:
You see for yourself, there is no OCIS_LDAP_xxx, but LDAP_xxx, but OCIS_LDAP_xxx in your link to the AD/Samba example. I think my docker-compose should be first in 100% correct syntax.
Thanks.
After holiday season I’ve tried it again with ocis 4.0.1. Your example can’t work. At least OCIS_LDAP_BIND_PASSWORD must be set to LDAP_BIND_PASSWORD.
Great, now I can login with any user in my Samba AD/LDAP. But OCIS_ADMIN_USER_ID doesn’t do anything. The user in Samba AD, that I want to use as ocis admin, don’t see any admin menus in ocis.
When I start from scratch (delete ocis.yaml and data folder, remove and start docker container), I always see in the logs that a local admin user will be generated with his password. Also in ocis.yaml admin_user_id always changes and doesn’t match a converted ObjectGUID.
How to proceed? Thanks
Btw, there is a password change option in ocis web-ui, but never works of course, because my ldap is read-only for ocis. Should be then disabled.
Oh. Sorry. That issue will be fixed with 4.0.2 (to be released soon). We deprecated some LDAP related variables in 4.0 and for some reason LDAP_BIND_PASSWORD was left out (Config pitfalls after v4 upgrade · Issue #7176 · owncloud/ocis · GitHub)
Can you please upload the logs with OCIS_LOG_LEVEL set to debug of a login of that user?
That locally generated admin user is basically irrelevant for your use case. Are you sure you’ve set OCIS_EXCLUDE_RUN_SERVICES=idm in you config? In that case no user should be created at all.
The admin_user_id in ocis.yaml is generated by ocis init, that’s why you need to replace it (or override using OCIS_ADMIN_USER_ID to match the external user that you want to make admin.
But as said for further debugging I’d need you complete config and logs with debug level.
OCIS_LDAP_SERVER_WRITE_ENABLED=false should do the trick.
It will be created or better: the log file told me this. Here is my complete ENV without confidential data:
TZ=Europe/Berlin
OCIS_LDAP_URI=ldap://ldap.example.com:389
OCIS_LDAP_INSECURE=true
OCIS_LDAP_BIND_DN=cn=<admin_of_ldap>,cn=users,dc=example,dc=com
LDAP_BIND_PASSWORD=<admin_password>
OCIS_LDAP_DISABLE_USER_MECHANISM=none
OCIS_LDAP_GROUP_BASE_DN=ou=groups,dc=example,dc=com
OCIS_LDAP_GROUP_OBJECTCLASS=group
OCIS_LDAP_GROUP_SCHEMA_ID=objectGUID
OCIS_LDAP_GROUP_SCHEMA_ID_IS_OCTETSTRING=true
OCIS_LDAP_GROUP_SCHEMA_GROUPNAME=cn
OCIS_LDAP_USER_BASE_DN=ou=accounts,dc=example,dc=com
OCIS_LDAP_USER_OBJECTCLASS=user
OCIS_LDAP_USER_SCHEMA_ID=objectGUID
OCIS_LDAP_USER_SCHEMA_ID_IS_OCTETSTRING=true
OCIS_LDAP_USER_SCHEMA_USERNAME=sAMAccountName
OCIS_LDAP_LOGIN_ATTRIBUTES=sAMAccountName
IDP_LDAP_LOGIN_ATTRIBUTE=sAMAccountName
IDP_LDAP_UUID_ATTRIBUTE=objectGUID
IDP_LDAP_UUID_ATTRIBUTE_TYPE=binary
GRAPH_LDAP_SERVER_WRITE_ENABLED=false
OCIS_EXCLUDE_RUN_SERVICES=idm
OCIS_ADMIN_USER_ID=<content_of_objectGUID>
OCIS_URL=https://owncloud.example.com
PROXY_TLS=false
OCIS_INSECURE=false
PROXY_ENABLE_BASIC_AUTH=true
FRONTEND_ENABLE_FAVORITES=false
FRONTEND_ENABLE_RESHARING=false
FRONTEND_ENABLE_PROJECT_SPACES=false
OCIS_SHARING_PUBLIC_WRITEABLE_SHARE_MUST_HAVE_PASSWORD=true
WEB_OPTION_DISABLE_FEEDBACK_LINK=true
STORAGE_USERS_OCIS_MAX_QUOTA=10000000000
With debug enabled, the very first lines are:
=========================================
generated OCIS Config
=========================================
configpath : /etc/ocis/ocis.yaml
user : admin
password : blablabla
{"level":"info","service":"storage-publiclink","time":"2023-10-04T09:44:32.901415127Z","line":"github.com/owncloud/ocis/v2/ocis-pkg/registry/register.go:17","message":"registering external service com.owncloud.api.storage-publiclink-d71e7d5e-17d4-425d-ac32-e2cc15554512@127.0.0.1:9178"}
(...)
Why is an admin user created with my env file? Do you have also tested it against v4.0.1?
Is it possible to redact confidential data in debug logs? Spreading my public domain or usernames isn’t what I want to see in a public forum. I see for myself, that some informations are just base64 encoded and it’s hard to go through and change everything. Do you have a special log line in mind which tells me that this user became admin in ocis?
Maybe the cause is that a local admin user is created and ocis doesn’t care about content of OCIS_ADMIN_USER_ID anymore?
Ok, this might probably just be a missunderstanding. The above lines don’t result in the user actually being created. These lines are produced by the call to ocis init. ocis init creates a initial config file that is mostly suitable for a basic stand-alone configuration. Because of that that config file will contain a generated admin password and user-id. In you set (external LDAP/AD server and OCIS_EXCLUDE_RUN_SERVICES=idm) the admin user will not be created.
And as you set OCIS_ADMIN_USER_ID in the enviroment, ocis will prefer that value over the one that is set in the configuration.
Ok. Fair enough. Currently there is not automatic way to redact that from the log AFAIK. Also some of the info would be quite handy to actually understand what the problem is.
First it would be good to find out if the value you set for OCIS_ADMIN_USER_ID actually matches the UUID that ocis decodes for that user (maybe there’s a but in that area). There should be a couple of log lines from the users service for a GetUserByClaim request. On my test-system I get this:
{"level":"debug","service":"users","pkg":"rgrpc","traceid":"00000000000000000000000000000000","method":"/cs3.identity.user.v1beta1.UserAPI/GetUserByClaim","time":"2023-10-04T12:49:34Z","line":"/owncloud/ocis/vendor/github.com/cs3org/reva/v2/internal/grpc/int
erceptors/auth/auth.go:122","message":"skipping auth"}
{"level":"debug","service":"users","pkg":"rgrpc","traceid":"00000000000000000000000000000000","claim":"username","value":"Administrator","time":"2023-10-04T12:49:34Z","line":"/owncloud/ocis/vendor/github.com/cs3org/reva/v2/pkg/user/manager/ldap/ldap.go:137","message":"GetUserByClaim"}
{"level":"debug","service":"users","pkg":"rgrpc","traceid":"00000000000000000000000000000000","backend":"ldap","basedn":"dc=owncloud,dc=test","filter":"(&(objectclass=user)(sAMAccountName=Administrator))","scope":2,"time":"2023-10-04T12:49:34Z","line":"/owncloud/ocis/vendor/github.com/cs3org/reva/v2/pkg/utils/ldap/identity.go:217","message":"LDAP Search"}
{"level":"debug","service":"users","pkg":"rgrpc","traceid":"00000000000000000000000000000000","entry":{"DN":"CN=Administrator,CN=Users,DC=owncloud,DC=test","Attributes":[{"Name":"objectGUID","Values":["\u0003\ufffd\t\ufffdO\u0026\ufffdD\ufffd\ufffd\u000f\ufffdY\ufffd\u0000\u0015"],"ByteValues":["A4QJpk8mikSMmg/HWdIAFQ=="]},{"Name":"sAMAccountName","Values":["Administrator"],"ByteValues":["QWRtaW5pc3RyYXRvcg=="]}]},"time":"2023-10-04T12:49:34Z","line":"/owncloud/ocis/vendor/github.com/cs3org/reva/v2/pkg/user/manager/ldap/ldap.go:144","message":"entries"}
There you can see the objectGUID (once base64 encode and once in some golang escaped form). I the above case the base64 value is A4QJpk8mikSMmg/HWdIAFQ==. A couple of log lines below that, there should be a message from the service auth-machine:
{"level":"info","service":"auth-machine","pkg":"rgrpc","traceid":"00000000000000000000000000000000","time":"2023-10-04T12:49:34Z","line":"/owncloud/ocis/vendor/github.com/cs3org/reva/v2/internal/grpc/services/authprovider/authprovider.go:141","message":"user idp:\"https://localhost:9200\" opaque_id:\"038409a6-4f26-8a44-8c9a-0fc759d20015\" type:USER_TYPE_PRIMARY authenticated"}
The value logged after opaque_id is the uuid string that ocis decoded for the objectGUID attribute. Does that value equal the string that you set for OCIS_ADMIN_USER_ID?
Yes. This is the original objectGUID part. I have also displayName and mail in this json response:
{
"Name": "objectGUID",
"Values": [
"\ufffdy\u001f\u0018\n\ufffdfL\ufffd\ufffdȯ\ufffd\r\ufffdT"
],
"ByteValues": [
"43kfGArKZkytj8ivmQ3nVA=="
]
},
This is the auth-machine json (only renamed my fqdn):
{
"level": "info",
"service": "auth-machine",
"pkg": "rgrpc",
"traceid": "00000000000000000000000000000000",
"time": "2023-10-04T16:28:09.242241065Z",
"line": "github.com/cs3org/reva/v2@v2.16.0/internal/grpc/services/authprovider/authprovider.go:141",
"message": "user idp:\"https://owncloud.example.com\" opaque_id:\"e3791f18-0aca-664c-ad8f-c8af990de754\" type:USER_TYPE_PRIMARY authenticated"
}
Looks like my log lines matches your log lines.
I’ve searched for errors that looks like an account error (changed the id’s because I don’t know if it contains personal content):
{
"level": "debug",
"service": "proxy",
"claims": "marshaling error: json: unsupported type: map[interface {}]interface {}",
"user": {
"id": {
"idp": "https://owncloud.example.com",
"opaque_id": "...-...-...-...-...",
"type": 1
},
"username": "administrator",
"mail": "administrator@example.com",
"display_name": "My Administrator",
"groups": [
"...-...-...-...-..."
],
"opaque": {
"map": {
"roles": {
"decoder": "json",
"value": "..."
}
}
},
"uid_number": 99,
"gid_number": 99
},
"time": "2023-10-04T16:28:09.435296315Z",
"line": "github.com/owncloud/ocis/v2/services/proxy/pkg/middleware/account_resolver.go:163",
"message": "associated claims with user"
}
Does the opaque_id value above equal the OCIS_ADMIN_USER_ID you’ve set in your config?
What does is the exact value of value there? (FYI It does not contain any personal data)
Yeah, finally it works!
I set OCIS_ADMIN_USER_ID what I found in this example:
OCIS_ADMIN_USER_ID="<objectGUID-value-of-the-default-admin-user>"
I thought value of objectGUID was meant that I read from my LDAP browser, because it says “objectGUID value”. But anyway, some days ago I have also tested converting objectGUID with help from this site:
… but used “Standard” format, because it looks the best (with dash). Yesterday I used your example values to compare your config, but doesn’t think much about it was in hex format. Today I saw the difference.
Thank you very much! Maybe this example config should be more clear, that the value must be converted to GUID hex format first.
Happy to hear it finally works. I’ll check how we can improve the example and documentation there to make that more explicit.
Regarding the Hex vs. Standard Format. I just now learned that the byte-order in which Microsoft returns the binary GUID value is different from what the UUID standard (RFC4122) defines (cause, why not?). Unfortunately the golang module we’re using for decoding the UUID does not deal with that. That’s why you get a different uuid displayed by the above GUID Converter.