Problems with Active Directory
Hello
I have been trying all day to connect my Homarr installation to my Active Directory.
I have tried many things, but I always get the message that the user cannot be found in LDAP.
Please find attached my config (Neutralized)
AUTH_LDAP_URI=ldap://xx.abc.en:389
AUTH_LDAP_BASE=DC=abc,DC=en
AUTH_LDAP_BIND_DN=CN=Administrator,CN=Users,DC=abc,DC=en
AUTH_LDAP_BIND_PASSWORD=password
AUTH_LDAP_USERNAME_ATTRIBUTE=sAMAccountName
AUTH_PROVIDER=credentials,ldap
AUTH_LDAP_GROUP_CLASS=CN=users,OU=groups,DC=abc,DC=en
AUTH_LDAP_ADMIN_GROUP=CN=admins,OU=groups,DC=abc,DC=en
AUTH_LDAP_OWNER_GROUP=CN=owners,OU=groups,DC=abc,DC=en
What am i doing wrong?
BR
SebastianSolution:Jump to solution
AUTH_PROVIDER="ldap"
AUTH_LDAP_URI="ldap://192.168.x.x:389"
AUTH_LDAP_BASE="DC=abc,DC=xyz"
AUTH_LDAP_BIND_DN="CN=Administrator,CN=Users,DC=abc,DC=xyz"
AUTH_LDAP_BIND_PASSWORD="password"...
195 Replies
Thank you for submitting a support request.
Depending on the volume of requests, our team should get in contact with you shortly.
โ ๏ธ Please include the following details in your post or we may reject your request without further comment: - Log (See https://homarr.dev/docs/community/faq#how-do-i-open-the-console--log) - Operating system (Unraid, TrueNAS, Ubuntu, ...) - Exact Homarr version (eg. 0.15.0, not latest) - Configuration (eg. docker-compose, screenshot or similar. Use ``your-text`` to format) - Other relevant information (eg. your devices, your browser, ...)
โ Frequently Asked Questions | Homarr documentation
Can I install Homarr on a Raspberry Pi?
Log: 2024-04-12T12:52:07.429403915Z ERROR User not found in LDAP
2024-04-12T12:52:07.429414493Z
2024-04-12T12:52:07.429416032Z at Object.authorize (.next/server/chunks/7534.js:94:34)
2024-04-12T12:52:07.429417740Z at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
2024-04-12T12:52:07.429419122Z at async Object.callback (node_modules/next-auth/core/routes/callback.js:362:14)
2024-04-12T12:52:07.429420642Z at async AuthHandler (node_modules/next-auth/core/index.js:302:28)
2024-04-12T12:52:07.429422252Z at async NextAuthApiHandler (node_modules/next-auth/next/index.js:22:19)
2024-04-12T12:52:07.429423558Z at async auth (.next/server/pages/api/auth/[...nextauth].js:129:12)
operating system debian
Frankly, ldap can be hard to correctly set up.
Just from what I can see, I'd say maybe you're missing quotation marks on the values?
Also depending on how you setup env variables, you might want to use ":" instead of equals for value assignement.
Hi
Normally i'm using portainer for the configuration, so this is the "Advanced mode" from portainer
Therefore i think it should be right
Ah ok so you shouldn't have problems with that at all then
exactly
the container start also perfectly and i can login via the "normal" credentials
only the ldap is not working
AUTH_LDAP_BIND_DN=CN=Administrator,CN=Users,DC=abc,DC=en
You should be providing a user here. Afaik you should have a "uid="?
I'm no expert so I'm not sure how the structure works, but that line should have a specific user, not just groups
Nvm that may just be specific to my setup. CN is just common name so it may very well work
Users being a group though should be OU, not CN. Again, may depend on your setup here.
Reading on the naming attribute, it's only available to change if you've set UID or CN for name equalities. So "sAMAccountName" doesn't seem like a correct value here
Also, all this is wrong, you just need to provide the name of the group, not the whole path
so just "users", "admins" and "owners"
Same for group_class, it's not a path
So here you mean only the username not the full bind
i refered to the example
๐ Single Sign On | Homarr documentation
Homarr supports multiple authentication options, namely credentials, ldap and oidc.
Administrator is a user, no group
Our AD doesn't use the uid, it uses the sAMAccountName for the name
I said nvm, because I thought you had to use "uid" instead of "cn" to address the username. But this is not actually standard and cn can be correct.
What might not be correct though is the pointing to the users group, as this might use "ou" instead of "cn".
This is where username_attribute comes into play though, in your case you might need to set it to "cn", not "sAMAccountName".
hi, sorry for the late response, many other topics to do
the distinguishedName of my users group is CN=Users,DC=xxx,DC=de
From Windows Server the uid is not set by default
the name used to differentiate users ist the sAMAccountName
these are my actual settings
AUTH_LDAP_URI=ldap://srv.abc.en:389
AUTH_LDAP_BASE=DC=abc,DC=en
AUTH_LDAP_BIND_DN=CN=Service Account,CN=Users,DC=abc,DC=en
AUTH_LDAP_BIND_PASSWORD=YouWantToKnowItXD
AUTH_LDAP_USERNAME_ATTRIBUTE=sAmAccountName
AUTH_PROVIDER=credentials,ldap
You're getting things mixed I think. Ldap is confusing as fuck so I don't blame you.
I'm not talking about windows server's UID, I'm saying that some ldap providers replaces the "CN" in the query by "UID". That is what "AUTH_LDAP_USERNAME_ATTRIBUTE" is for, in your case you have to set it to "cn"
Ok lets check
i've changed the env and it isn't wokring
do you know if there is a setting for a deeper logging level?
Have you changed this part ?
yes and modified to my needs
so ou is Gruppen instead of groups
Actually nvm it shouldn't matter for a simple login, just for admin role attribution
You also changed this one?
AUTH_LDAP_GROUP_CLASS=CN=users,OU=groups,DC=abc,DC=en
It should only have the name of the class, not a pathAUTH_LDAP_URI=ldap://srv.abc.en:389
AUTH_LDAP_BASE=DC=abc,DC=en
AUTH_LDAP_BIND_DN=CN=Service Account,CN=Users,DC=abc,DC=en
AUTH_LDAP_BIND_PASSWORD=YouWantToKnowItXD
AUTH_LDAP_USERNAME_ATTRIBUTE=cn
AUTH_PROVIDER=credentials,ldap
AUTH_LDAP_ADMIN_GROUP=CN=employees,OU=Gruppen,DC=abc,DC=en
AUTH_LDAP_OWNER_GROUP=CN=Administrators,OU=Gruppen,DC=abc,DC=en
Again, those are not paths. Only put the name of the group
AUTH_LDAP_URI=ldap://srv.abc.en:389
AUTH_LDAP_BASE=DC=abc,DC=en
AUTH_LDAP_BIND_DN=CN=Service Account,CN=Users,DC=abc,DC=en
AUTH_LDAP_BIND_PASSWORD=YouWantToKnowItXD
AUTH_LDAP_USERNAME_ATTRIBUTE=cn
AUTH_PROVIDER=credentials,ldap
AUTH_LDAP_GROUP_CLASS=memberOf
AUTH_LDAP_ADMIN_GROUP=employees
AUTH_LDAP_OWNER_GROUP=Administrators
like that
2024-04-22T12:16:49.186635962Z user raubucs is trying to log in using LDAP. Signing in...
2024-04-22T12:16:49.194683864Z
2024-04-22T12:16:49.194708837Z ERROR Invalid username or password
2024-04-22T12:16:49.194711509Z
I'm not sure how your system works, but I also feel like this one
AUTH_LDAP_BIND_DN=CN=Service Account,CN=Users,DC=abc,DC=en should use OU=Users, otherwise it seems like this should be it. many things after this point might be specific to your ldap provider and I wouldn't be able to knowthe distinguishedName of the Service Account I've copied directly from our AD Management tool
Not the service account...
CN=Users -> OU=Users
i can try it, but for every other service i'm using it worked with this
Yeah like I said, it's dependent on your ldap provider, it's just a guess
perhaps an microsoft ad server acts different do an lldap
The "sAMAccountName" may need to be given to the
AUTH_LDAP_GROUP_MEMBER_USER_ATTRIBUTE env variable
Or it could be set to "userPrincipalName" since we're in 2024, and sAMAccountName is for systems pre-windows 2000userPrincipalName ist not only the username, it is username@domain
SAMAccountName is only the username
Ok then set that to
AUTH_LDAP_GROUP_MEMBER_USER_ATTRIBUTEnope
invalid username or password
Last thing that seem to be possibly wrong because I know nothing of your ldap provider, are you sure AUTH_LDAP_GROUP_CLASS is correct?
Seems like it should be set to "user"
Also, it seems AUTH_LDAP_GROUP_MEMBER_ATTRIBUTE needs to be set to sAMAccountName, not AUTH_LDAP_GROUP_MEMBER_USER_ATTRIBUTE
Further research into our own code, All this doesn't even matter as they are only used to set groups, not login.
It seems one of the following is not correct:
AUTH_LDAP_BIND_DN
AUTH_LDAP_BIND_PASSWORD
AUTH_LDAP_URInow i have another error
There was really a typo inside the passwd
Good, that's progress
What's the error
2024-04-22T13:48:06.213339860Z ERROR User not found in LDAP
2024-04-22T13:48:06.213342892Z
2024-04-22T13:48:06.213344252Z at Object.authorize (.next/server/chunks/7534.js:94:34)
2024-04-22T13:48:06.213346518Z at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
2024-04-22T13:48:06.213348451Z at async Object.callback (node_modules/next-auth/core/routes/callback.js:362:14)
2024-04-22T13:48:06.213349999Z at async AuthHandler (node_modules/next-auth/core/index.js:302:28)
2024-04-22T13:48:06.213351906Z at async NextAuthApiHandler (node_modules/next-auth/next/index.js:22:19)
2024-04-22T13:48:06.213353446Z at async auth (.next/server/pages/api/auth/[...nextauth].js:129:12)
2024-04-22T13:48:06.213354800Z
Hmm, I do suspect for that one that there might need a change on our end
Basically, after logging in, it searches for users.
It does so with the filter
(uid="user").
In case of AD, the filter should be (sAMAccountName="user")
I'm guessing the env variable AUTH_LDAP_USERNAME_ATTRIBUTE should have been implemented here but was forgotten.so i have to wait for a next release?
I'll make a custom image for testing, when it works you'll be able to use until then.
or do you know where to change the uid variable
i'm able to log into the container to modify it temporarly
It's not a variable in the code, like I said, I'm guessing it wasn't implemented by mistake
kk
It was supposed to though as that env variable is linked nowhere
ok, then i will wait
Thanks for the support
i will mark this as answer for the question
No no wait
We don't know if that's the problem yet x)
Just writting things down for later:
AUTH_LDAP_USERNAME_ATTRIBUTE = sAMAccountName
env.AUTH_LDAP_USERNAME_FILTER_EXTRA_ARG = (sAMAccountType=805306368)
AUTH_LDAP_GROUP_CLASS = user
AUTH_LDAP_GROUP_MEMBER_ATTRIBUTE = memberOf
AUTH_LDAP_GROUP_MEMBER_USER_ATTRIBUTE = dn
Could you try the image
SeDemal/homarr:latest
And set the environment variables that I listed aboveonesec
ok testImg is running
I've also deleted the complete mapping stuff for the instance
2024-04-22T14:47:57.551355606Z user raubucs is trying to log in using LDAP. Signing in...
2024-04-22T14:47:57.561924233Z
2024-04-22T14:47:57.561942830Z ERROR Cannot read properties of undefined (reading 'dn')
2024-04-22T14:47:57.561945748Z
2024-04-22T14:47:57.561947329Z at Object.authorize (.next/server/chunks/7534.js:93:38)
2024-04-22T14:47:57.561949145Z at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
2024-04-22T14:47:57.561950701Z at async Object.callback (node_modules/next-auth/core/routes/callback.js:362:14)
2024-04-22T14:47:57.561952214Z at async AuthHandler (node_modules/next-auth/core/index.js:302:28)
2024-04-22T14:47:57.561953690Z at async NextAuthApiHandler (node_modules/next-auth/next/index.js:22:19)
2024-04-22T14:47:57.561955243Z at async auth (.next/server/pages/api/auth/[...nextauth].js:129:12)
2024-04-22T14:47:57.561956617Z
sry overread a parameter
Set AUTH_LDAP_GROUP_MEMBER_USER_ATTRIBUTE = uid
2024-04-22T14:50:59.419371125Z user raubucs is trying to log in using LDAP. Signing in...
2024-04-22T14:50:59.430699238Z
2024-04-22T14:50:59.430711284Z ERROR Cannot read properties of undefined (reading 'dn')
2024-04-22T14:50:59.430713627Z
2024-04-22T14:50:59.430714847Z at Object.authorize (.next/server/chunks/7534.js:93:38)
2024-04-22T14:50:59.430716557Z at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
2024-04-22T14:50:59.430718184Z at async Object.callback (node_modules/next-auth/core/routes/callback.js:362:14)
2024-04-22T14:50:59.430719503Z at async AuthHandler (node_modules/next-auth/core/index.js:302:28)
2024-04-22T14:50:59.430720784Z at async NextAuthApiHandler (node_modules/next-auth/next/index.js:22:19)
2024-04-22T14:50:59.430722204Z at async auth (.next/server/pages/api/auth/[...nextauth].js:129:12)
2024-04-22T14:50:59.430723764Z
Actual ENVs
AUTH_PROVIDER=credentials,ldap
AUTH_LDAP_URI=ldap://srv.abc.en:389
AUTH_LDAP_BASE=dc=abc,DC=en
AUTH_LDAP_BIND_DN=cn=Service Account,cn=Users,dc=abc,dc=en
AUTH_LDAP_BIND_PASSWORD=YouWantToKnow
AUTH_LDAP_USERNAME_ATTRIBUTE=sAMAccountName
AUTH_LDAP_USERNAME_FILTER_EXTRA_ARG=(sAMAccountType=805306368)
AUTH_LDAP_GROUP_CLASS=user
AUTH_LDAP_GROUP_MEMBER_ATTRIBUTE=memberOf
AUTH_LDAP_GROUP_MEMBER_USER_ATTRIBUTE=uid
Just to not leave you in the dark, it seems that when logging in the user, dn stays undefined, and it shouldn't be.
I'm adding some debugging points so we can know better
But i have to leave for today
i will be back online tomorrow
08:00 GMT+1
Alright, I'll make a new image with more logging points to give us info, pull latest again (and make sure you'll be on version 0.15.99999)
Upon logging it'll print out in the console Something of the sort:
Make sure you look at the one with
messageId: 2. I want to make sure you have an objectName there and attributes.Alright
Have a nice evening/day
Same to you
so, back to work
There is no extended logging
where do you pulished the image? ghcr?
Two 9s are missing
then it says, the image cannot be found
btw @Tag wrote 99999
Oh your right, the image above you still got 4x 9
Or pull latest again
Yeah I'm just adding a 9 every release x), might be easier to pull latest again if you can
https://github.com/SeDemal/homarr/releases/tag/v0.15.99999 there's actually 5 9's
but portainer didn't find the 99999 image
I've tried latest but it seems, that there nothing changed
this is the image available in ghcr.io
ghcr.io/sedemal/homarr:latest@sha256:fa5ce8f3707607104b7cb355a4a3de153c95653839ed6275935bef3a2c098d84
Turns out you may not have been on my v0.15.9999 actually, so there's still a chance the fix I did works
Just have to figure out why my package isn't updating
Alright finally did it.
Sedemal/homarr:v38
Did you have to try it 13 times? lmao
Nah just picked a random number, I did retry about 10 times but there's a re-run button that I learned about mid way through
Anyway about that image, I'm deeply confused because it doesn't link to any of my existing images in the packages, and I now know for sure that I couldn't have successfully published the first version. In any case, since that was supposedly not working, that means my fix might still work and we might not need any more debugging.
Hi
So the error message changed after i update to image version 91
2024-04-24T11:59:46.128178856Z user raubucs is trying to log in using LDAP. Signing in...
2024-04-24T11:59:46.139267212Z
2024-04-24T11:59:46.139291851Z ERROR User not found in LDAP
2024-04-24T11:59:46.139294961Z
2024-04-24T11:59:46.139296752Z at Object.authorize (.next/server/chunks/7534.js:94:34)
2024-04-24T11:59:46.139298698Z at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
2024-04-24T11:59:46.139300513Z at async Object.callback (node_modules/next-auth/core/routes/callback.js:362:14)
2024-04-24T11:59:46.139302590Z at async AuthHandler (node_modules/next-auth/core/index.js:302:28)
2024-04-24T11:59:46.139304184Z at async NextAuthApiHandler (node_modules/next-auth/next/index.js:22:19)
2024-04-24T11:59:46.139305542Z at async auth (.next/server/pages/api/auth/[...nextauth].js:129:12)
2024-04-24T11:59:46.139307093Z
but i don't get the error message format you've mentioned
I said v38
V91 is for someone else
oh
XD
Sry
no different error message
You should have a lot more text in the console
nope
as i wrote
no change in the console
I don't know what version you're on, but in version 38, every logging for ldap is different, so you can't have the exact same output.
Your sha doesn't look like the ones from the ghcr package list https://github.com/SeDemal/homarr/pkgs/container/homarr/207432814?tag=38
maybe try pulling it again
I've made a local instance to try the image and I can say for sure that the logging is different.
Even the first line says "Connecting to LDAP server..." instead of "Signing in..."
Then if the connection to the server succeeds, you should see the line "Connection established. Logging in User..."
Which is where you would normally get an error
Can confirm. Ive been trying to configure ldap authentication but cannot get past by the same exact error as @raubucs . The only difference now is that before errors i have message saying connection estabilished:
Connection established. Logging in User...
ERROR User not found in LDAP
at Object.authorize (.next/server/chunks/7534.js:96:34)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
at async Object.callback (node_modules/next-auth/core/routes/callback.js:362:14)
at async AuthHandler (node_modules/next-auth/core/index.js:302:28)
at async NextAuthApiHandler (node_modules/next-auth/next/index.js:22:19)
at async auth (.next/server/pages/api/auth/[...nextauth].js:129:12)
Your problem might be different as raubucs'. He's configuring Active directory through ldap, which is widely different.
Open a ticket if you can't make it work but if you have a standard ldap server, it is most likely a config error.
As i understand im trying the same as @raubucs - my mistake i didnt specify that but im trying also to authenticate through active directory ldap. I tried every step he mentioned and got the same result, use different image and so on, so i decided to reply this here. I didnt get extended output what the reason. But if you suggest i should open a new case thats not a problem.
Ah, if you're going with active directory, then you might be able to help, nvm
Interesting.
This means that the user does not exist on the set filter.
Nothing extra appears because nothing was found.
Would you happen to know exactly what filter you would apply for logging in users?
Here's our current template:
(&(${env.AUTH_LDAP_USERNAME_ATTRIBUTE}=${data.name})${env.AUTH_LDAP_USERNAME_FILTER_EXTRA_ARG})
in your case this would translate to this right now:
(&(sAMAccountName=${username})(sAMAccountType=805306368))
Where (sAMAccountType=805306368) designates users in active directoryI tried per instuction found here:
https://homarr.dev/docs/advanced/sso
To specify only required arguments, as if i understand right, it would allow any user in any group to authenticate. It resulted with the same error set.
๐ Single Sign On | Homarr documentation
Homarr supports multiple authentication options, namely credentials, ldap and oidc.
Did you set your variables to be like I said here?
last it tried was that below:
in ldap:// i used exact ip so i could elimiate enything dns related. made no difference
Replace LDAP_USERNAME_FILTER_EXTRA_ARGS with "(objectCategory=person)", and also try without it.
Alright, some cheatsheet says this should be the filter:
(objectCategory=person)(objectClass=user)(sAMAccountType=805306368)(!(userAccountControl:1.2.840.113556.1.4.803:=2))
put that in AUTH_LDAP_USERNAME_FILTER_EXTRA_ARGS. Try removing them one by one starting from the rightmost one.tried both. ended with the same result.
to get some insight extraded through ldap browser table of attributed for any user look like this (showing user homarr created to make bind to ldap):
i see object class as person not user type (maybe this will be important maybe not but domain is level 2008 r2 for compatibility reasons - maybe newer levels differ in some degree)
now trying filter from your second reply nevertheless
My mistake, they are both user and person class ๐ trying now...
You have 4 objectClass, user, top, person and organizationalPerson
You can try removing "(objectCategory=person)" since I don't see it in the list Found it in the screenshot, it looks like it's set to CN=Person. with a caps P though
Although it comes from microsoft directly, so this should be correct
They also recommend to use
(sAMAccountType=805306368) instead of (objectCategory=person)(objectClass=user)
Which is funny since it's all part of the filtertried whole filter, same error output, without "(objectCategory=person)" too. keeping trying
just tkinking, if i remove all except AUTH_LDAP_URI, AUTH_LDAP_BASE, AUTH_LDAP_BIND_DN and AUTH_LDAP_BIND_PASSWORD and got the same result isnt that mean that this is not filter related?
There's 3 steps:
- Homarr client gets access to ldap server using:
- AUTH_LDAP_BIND_DN
- AUTH_LDAP_BIND_PASSWORD
- AUTH_LDAP_URI
- Search for user using:
- previously authenticated homarr client
- AUTH_LDAP_BASE
- AUTH_LDAP_USERNAME_ATTRIBUTE=${user input in the login form}
- (optional) AUTH_LDAP_USERNAME_FILTER_EXTRA_ARG
- Retrieve groups for the user (which I won't go into details yet because we're not there
So if you set the 4 variables correctly, your client will always connect, but if your filter is not correct, then it will never return a user
So you'll always get the same error, which basically means "your filters or LDAP_BASE is incorrect"
but if i dont specify any filter whatsoever it should accept any user, am i right?
meanwhile im keeping trying different suggested configuration of what you wrote ๐
Not sure, I don't know if active directory forces you to be specific
But I think I might have found something
I think one of the search option's attribute is forcing uid, but active directory doesn't have that, so it's not returning the user since it's missing it
I would love to have an active directory to just try things out myself
Meanwhile i tested every combination i could whink of: leaving (sAMAccountType=805306368) alone too but thats not producing anything different
What's the easiest way I could make myself an active directory test environment?
if you have a esxi or other hypervisor, or even virtualpc or qemu you could download and install wink2k22 eval and make local ad, configuration is trivial. meanwhile im whinking where i have mine test domain stashed to make available to you somehow
I don't want you to do that if there's any sensitive info linked to it though. I'll try a virtual machine with windows enterprise but that will take me a little time to get running
im talking about test domain dont worry, i will wait patiently, homarr is worth it ๐ meanwhile if i find anything i will post here ๐ thank you for the effort
https://learn.microsoft.com/en-us/microsoft-365/enterprise/modern-desktop-deployment-and-management-lab?view=o365-worldwide
didnt used that but for testing purposes its woth the shot
Windows and Office 365 deployment lab kit - Microsoft 365 Enterprise
Learn about where to access the Windows and Office deployment lab kit.
Ok, I got news, it's not gonna work yet, but you need to set "AUTH_LDAP_SEARCH_SCOPE" to "sub"
Solution
AUTH_PROVIDER="ldap"
AUTH_LDAP_URI="ldap://192.168.x.x:389"
AUTH_LDAP_BASE="DC=abc,DC=xyz"
AUTH_LDAP_BIND_DN="CN=Administrator,CN=Users,DC=abc,DC=xyz"
AUTH_LDAP_BIND_PASSWORD="password"
AUTH_LDAP_USERNAME_ATTRIBUTE="sAMAccountName"
AUTH_LDAP_SEARCH_SCOPE="sub"
AUTH_LDAP_GROUP_CLASS="group"
AUTH_LDAP_OWNER_GROUP="Administrators"
AUTH_LDAP_ADMIN_GROUP={Any group you want to have admin privileges, otherwise keep empty}
sedemal/homarr:40
Should be in dev shortly, most likely in homarr v0.15.3 and later too.
To note: users need to have an email attached to the user.
If you really don't want to link a user to an email, you can use the following env variable that I just added:
AUTH_LDAP_USER_MAIL_ATTRIBUTE="userPrincipalName"
userPrincipalName is in email address format for some reason, so it fits.
Ghcr.io/sedemal/homarr:39
Available in about 5 minutes
@raubucs @nefratus Please try it as soon as you can
2024-04-30T06:44:03.447904646Z user raubucs is trying to log in using LDAP. Connecting to LDAP server...
2024-04-30T06:44:03.455465367Z Connection established. Searching User...
2024-04-30T06:44:03.458425663Z
2024-04-30T06:44:03.458440275Z ERROR User not found in LDAP
2024-04-30T06:44:03.458442671Z
2024-04-30T06:44:03.458444163Z at Object.authorize (.next/server/chunks/7534.js:97:34)
2024-04-30T06:44:03.458446112Z at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
2024-04-30T06:44:03.458447626Z at async Object.callback (node_modules/next-auth/core/routes/callback.js:362:14)
2024-04-30T06:44:03.458449122Z at async AuthHandler (node_modules/next-auth/core/index.js:302:28)
2024-04-30T06:44:03.458450438Z at async NextAuthApiHandler (node_modules/next-auth/next/index.js:22:19)
2024-04-30T06:44:03.458451965Z at async auth (.next/server/pages/api/auth/[...nextauth].js:129:12)
2024-04-30T06:44:03.458453324Z
You removed any environment variable I didn't write up there right?
(the ones pertaining to ldap)
sry, there was a env to much
now it works
๐
If your users have a registered email, remember to change AUTH_LDAP_USER_MAIL_ATTRIBUTE to "mail"
Superb work ๐ will try this now too
Interesting behavior ist, that it only works for "Administrators"
On my end definitely something changed. Downloaded new image, remvoed all env variables targeting ldap and added new ones by yours suggestion. output now look like this:
Starting production server...
Listening on port 7575 url: http://f30b92c9a745:7575
user ljasinski is trying to log in using LDAP. Connecting to LDAP server...
Connection established. Searching User...
User found. Logging in...
ERROR Invalid username or password
env looks like this:
AUTH_LDAP_ADMIN_GROUP homarr-admin AUTH_LDAP_BASE DC=wodociagi,DC=torun AUTH_LDAP_BIND_DN CN=homarr,OU=Uslugi,DC=wodociagi,DC=torun AUTH_LDAP_BIND_PASSWORD B@z1n9a AUTH_LDAP_GROUP_CLASS group AUTH_LDAP_SEARCH_SCOPE sub AUTH_LDAP_URI ldap://192.168.1.30:389 AUTH_LDAP_USER_MAIL_ATTRIBUTE mail AUTH_LDAP_USERNAME_ATTRIBUTE sAMAccountName AUTH_PROVIDER ldap homarr-admin is security group with 2 members - me and friend sitting next to me (output from ldap browser of security group): and output from mine account (cropped some timetables etc):
AUTH_LDAP_ADMIN_GROUP homarr-admin AUTH_LDAP_BASE DC=wodociagi,DC=torun AUTH_LDAP_BIND_DN CN=homarr,OU=Uslugi,DC=wodociagi,DC=torun AUTH_LDAP_BIND_PASSWORD B@z1n9a AUTH_LDAP_GROUP_CLASS group AUTH_LDAP_SEARCH_SCOPE sub AUTH_LDAP_URI ldap://192.168.1.30:389 AUTH_LDAP_USER_MAIL_ATTRIBUTE mail AUTH_LDAP_USERNAME_ATTRIBUTE sAMAccountName AUTH_PROVIDER ldap homarr-admin is security group with 2 members - me and friend sitting next to me (output from ldap browser of security group): and output from mine account (cropped some timetables etc):
I've added these env and now i'm able to log as my account
but my testaccount is log's into another account
it looks like its binding ok, looking for user and finding it properly but for some reason cannot link group to accounts. ill try @raubucs method now
this is my current ENV
AUTH_PROVIDER=credentials,ldap
AUTH_LDAP_URI=ldap://abc.xyz.de:389
AUTH_LDAP_BASE=dc=xyz,DC=de
AUTH_LDAP_BIND_DN=cn=Administrator,cn=Users,dc=hg-innovation,dc=de
AUTH_LDAP_BIND_PASSWORD=XXXXX
AUTH_LDAP_USERNAME_ATTRIBUTE=sAMAccountName
AUTH_LDAP_SEARCH_SCOPE=sub
AUTH_LDAP_GROUP_CLASS=group
AUTH_LDAP_OWNER_GROUP=Administrators
AUTH_LDAP_ADMIN_GROUP=employees
Your users have to be part of the group employees too.
Win+r -> ldp.exe, connection -> connect..., connection-> bind..., Browse->Search
bind: DN=abc,DN=xyz, filter: (objectClass=group), attributes: *
Edit that message without the password
Also, error seems pretty straightforward, wrong password?
thats dummy password its ok ๐
Ok
They are part of the employees to
strange thing is that my ttest user is logged in as another local user
passwords triple checked.
Actually ldap might be shitting itself because of the accents, can you try with a test user?
Can you show me what the output of what I sent is?
Basically, ldap will use the returned "distinguishedName" to log in since it contains the whole path, but that DN uses the cn instead of the sAMAccountName, so it uses all the accents as you can see in your screenshots. I don't know if that has an effect on things. I know punctuation doesn't cause troubles, but more than that no idea
output of your command in my environment generated 20 second and i think its like 2 billion lines ๐
Wtf
Try again with the filter (&(objectClass=group)(dn={insert user distinguishedName here}))
But that's not gonna help you just yet, you can't even log in your users, that's for retrieving groups which is the step after
That was for raubucs, not you
Unless you fixed the loggin issue?
no problem. just for clarity, output might look like this because my network is pretty large and old so many groups many users etc
nope tried combination with userprincipalname etc and canot get past it. if you wish we can pasue and you can focus on helping @raubucs . i can wait
Have you tried with a test user that doesn't have accents anywhere in its data?
This is the membership of my testuser
That's not what I asked
there i'm getting error messages
At what point? Have you connected properly first? Have you bound the right user then?
Binding is not working
Domain is in ldap DN format
DC=abc,DC=xyz
***Searching...
ldap_search_s(ld, "DC=xyz,DC=de", 0, "(objectClass=group)", attrList, 0, &msg)
Getting 0 entries
Let me boot up my test env...
I'm testing the filter inside my functioning nextcloud
and here i can find groups
Now it works
somehting was wrong with the filter....
Filter is like this
(&(objectClass=group)(member={insert user distinguishedName here}))
Dn: CN=employees,OU=Gruppen,DC=xyz,DC=de
cn: employees;
distinguishedName: CN=employees,OU=Gruppen,DC=xyz,DC=de;
dSCorePropagationData: 0x0 = ( );
groupType: 0x80000002 = ( ACCOUNT_GROUP | SECURITY_ENABLED );
instanceType: 0x4 = ( WRITE );
member (9): users;
name: employees;
objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=xyz,DC=de;
objectClass (2): top; group;
objectGUID: 726ad41c-18dd-4a97-a7bb-b18780481ce3;
objectSid: S-1-5-21-2470423731-2906607440-1235520191-1112;
sAMAccountName: employees;
sAMAccountType: 268435456 = ( GROUP_OBJECT );
uSNChanged: 63982;
uSNCreated: 13119;
whenChanged: 22.04.2024 10:18:31 Mitteleuropรคische Somm;
whenCreated: 20.02.2024 14:25:45 Mitteleuropรคische Somm;
I had it wrong before
-----------
***Searching...
ldap_search_s(ld, "DC=xyz,DC=de", 1, "(&(objectClass=group)(member="ttest"))", attrList, 0, &msg)
Getting 0 entries:
-----------
Did you put the full DN of distinguishedName or did you just actually put "ttest"
I've put ttest
and the full DN CN=Testus Testian,CN=Users,DC=xyz,DC=de inside there
Member needs to be equal to the full DN, not just the name
this should be then the dn, or?
Yes
So your filter should be (&(objectClass=group)(member=CN=Testus Testian,CN=Users,DC=xyz,DC=de))
(and don't forget to change the DC)
Not working
Then either you didn't input the right dn, or your user is not part of any groups
What filter did you use to get that then?
Base-DN was DC=xyz,DC=de
with this filter i've got the whole list of groups
Yeah, of course that's going to return a group if you query any group. You need to specify the member
You can try to replace attribute with "member" and check if your user is in the list
nope
not working
Interesting fact is, that i have to select Area -> Substructure
All other areas are not working
Yeah, that's the scope, which has to be set to sub
It's set in one of your env variables too
And it's "subtree"
with objectclass=member it is not working
Yeah that's normal
I told you to change the attribute
Not the filter
sry
i have to read more precisely
Don't beat yourself up too much on that, you have to translate on top of interpreting things which makes it harder
So
Base-DN: DC=xyz,DC=de
Filter:(objectClass=group)
And for attribute?
member
Filter you might want to change to (&(objectClass=group)(distinguishedName=CN=employees,OU=Gruppen,DC=xyz,DC=de))
It filters to only show members of the employees group, instead of showing every member of every group
ok
now i'm getting the members of the employees group
And is your user part of it?
yes
Ok now set Filter to
(&(objectClass=group)(member=cn=Testus Testian,cn=Users,dc=ABC,dc=de)) <- change the first DC
and set Attributes to cn
Keeping the same base.Okay, i needed to attend to other things but i did as you asked, created new user without any polish gibberish in the middle, username testownia, added it to homarr-admin group and at least got sucessful ldap logon. so i will add second one, see if it will log the same and the third with special characters to see whats what. anyway, progress ๐
I sure hope it's fixable if that's the issue
yep, confirmed. added second user, testownia2 but this time i added my name, ลukasz in the profile. didnt get through
I tried too, could have done it sooner actually. It is indeed not working
That ought to explain it
Cn is supposed to be "testล"
Weirdest part is, the sAMAccountName is still correct
Thanks microsoft...
i got to it deeper from my side, edited account that was not working to the point it started, after renaming whole account on the list in ad snap in, which in turn changes the "name" and "cn" fields on ldap, account stated working, after editing again to include some special polish letters, its stopped again. pictures below ๐
this works
this not
Yeah, I tried on my side, the login is not the problem as it accepts special characters
It seems the search function is the problem, or rather what windows sends as the dn
Dn -> distinguishedName in this case
from curiosity side, i added special chars in other fields and it got through no problem
Loging in using the sAMAccountName works, so if I can make things work I'll just make another env variable. But at this point it's starting to be a little much and it's hard enough to use ldap so I'd rather find another solution
only those 2 fields are affecting things
Oh, I might know hold on
Ok nvm
Here's how it works for us:
1. Connect admin
2. Search ldap database for the user and get back it's dn, mail, and prefered username attribute
3. Connect said user using it's dn and provided password to validate user authentication
4. Get the user's groups to compare for admin and owner
5. Logged in
Problem is that in step 2, we get the wrong dn
Problem 2 is that I don't know if it's us interpreting the value wrong or active directory sending it wrong.
For both situation, the weird part is that the dn is wrong, but the sAMAccountName is correct.
I'll try reconstructing the dn with the correct value to see if it logs in properly
tried that, it is getting through ok. what im wondering right now is why ad itself when creating account ask for specific account name and fetch it to new ldap account to samaccount name but not in dn
That worked like a charm.
I'll try to see if I can rewrite it so we get the correct dn
yeah but i edited it through active directory snap in and verified it in ldap browser, then log in. the thing is if i edit it to the point when dn is set correctly it affect the username too. but as i said i edited it through windows active directory snap in. maybe it edits 2 points at the same time. but at the other hand, active directory snap in is the place where all active directory admins do those things so...
those 2 screens i send earlier. there are two differences. one is that one works other not. other difference is 2 changes in ldap which were done by editing one field on ad
The problem isn't logging in, it's the dn value that active directory sends upon search that's wrong
I tried hard coding the special characters and it worked, so that's not the issue here
okay i will say this. altrough i got 20 years experience in managing networks i dont know anything about programming, so im writing my thoughts and knowing that you know better what we are talking about ๐
Lmfao I found the solution and it's the worst thing I've ever seen
decodeURIComponent(ldapUser.dn.replaceAll("\\","%"))
So, the idea is to go from UTF-8 to string, so to do that, you replace the backslashes with % and handle it like a web URI.
I'm sure there's a better way but I just found this along the way and it's working
Welp, turns out that's the most common answer, so I guess that's how I should do it.
decodeURIComponent(ldapUser.dn.replaceAll(/(?<!\\)(\\)(?=[0-9a-fA-F]{2})/g, '%'))
I'll make a new image for you to try out
@nefratus Try out v40, should work with any types of accents.
It's actually good to catch up on this early on, this could have happened even with any non English language actually.I will try it in the evening - theres national holiday today in poland and will be wherever wife tell me to be probably whole day ๐ will report back asap
๐
just done quick testing. i logged my main domain account without troubles, the account that during testing was not modified whatsoever and every time was unable to log in. everything from my perspective looks like its working like a charm. as its late here now i will postpone further testing till tomoorow but i suppose that this issue is resolved now. if enything regarding this issue will show itself tommorow i will post here but i highly doubt it. Im very happy that you could make this work cause i think that if i tell everyone in my work that they need to change they names to simpler ones, well, they may not be very happy xD congratulations and thank you ๐ wonderfull work ๐
Take your time testing. Glad to see it's holding up for now.
There might be very rare edge cases, but I doubt it'll happen given the environment of ldap. If it does though, that one person in a million can change their username x)
Like I said earlier, it's a good thing we catch this now. Any foreign alphabet would have caused this very issue, and I'm actually surprised that didn't happen before.
Also, very glad to hear that homarr is being used in a professional setting. It feels very validating ^^
While I have you testing things out, could you try to set 2 different non native groups for admin and owner?
This would help knowing if raubucs' problem is truly from our end or if we need to look into config more.
I personally had no problems with it using the config I gave but if you have any observations while doing it it could help
Ok. I think its tested thoroughly as i could. I sucesfully logged 4 different users from specially created homarr admin group (every account has some polish letters in them) and encountered no problems whatsoever. Created another grup for owners and they logged without trubles - again with some polish letters in them. In panel they show as expected as admins and owner/admins respectively. Althrough everytihing is working fine i remain available if you need some testing further - working homarr with ldap will be tested here with my department before i will push it to production.
Wanted to thank you again for such swift reaction with outstanding results ๐ You know, this is third company (i mean every min 300 employees, one multinational) i deployed homarr in production. in times when you got like 20 panels to operate just as office employee everyone quickly cannot imagine working without it and love this right away and by extend your admin for getting you this tool ๐ I tested several panels and nothing in my opinion even compares to it. im just hoping that my boss will keep his promise and compensate you through donations ๐
if u need anything im available.
This is wonderful to hear. @raubucs you can try and update to v40, although I doubt it'll help but at least it's 1 version we're sure that grouping works as intended.
And thanks a lot for at least thinking of donating ^^
hello
sorry for the late reply
i've tested the v40 and now it works fine
Welp, not sure what change from v39 for you but glad it worked.
No issues whatsoever then?
no and i've found out what was the problem with my test user
my test user ttest had the same mail address inside the AD
and then homarr thought the ttest is the same user as my local-root user with the same mail address
Oh yeah, we log in using the email. That's why it's a necessary field
We might update the login to include the whole user object instead
Problem is, that in our AD not all users have a mail adress
I've managed to use the userPrincipalName for that, because the MS AD automatically creates there a user@domain address
Yeah that's why I suggested using AUTH_LDAP_USER_MAIL_ATTRIBUTE="userPrincipalName"
That "email" is made using the username
And automatically made by ad
Lol we said the same thing
I personnally think you should make all your users use an email, but that's an acceptable workaround since we don't actually need a valid email.
Only caveat is that you won't be able to make use of libravatar/gravatar for custom Avatar icons, but since it's a professional environment, it doesn't matter much.
I'll mark the env variable list I gave as the answer. I think we've had enough messages for this one ticket so if you have a new issue, please make a new ticket.
It'll make it easier if someone goes through the same problem.
for sure
thanks a lot for the work and help
No problem, as I told nefratus, all this was bound to happen and need fixing at one point. This also gives us a more solid base for homarr v1.