hardypart - Can't log in after initial setup......
Can't log in after initial setup...
I would say everything looks fine in my config file:
1. Uncommented and set ldap_user_pass = "xxxxxxxxxxxx"
2. Uncommented ldap_user_dn = "admin"
But it's still not working. I restarted the container, deleted the users.db file, restartet again, but all I'm getting is "Invalid username or password" when trying to log in.
How could this be solved? I also tried to set these things with environment variables in the Portainer stack, but it's the same result.
As the users.db is being recreated after deleting it and restarting the container, I suppose it's not a permission issue on the data folder.
21 Replies
Hey! It's a bit hard to debug like this. Does the server correctly generate the server key when it starts? Is it persisted between restarts? Alternatively, are you using the server key seed?
For the rest, it would be very helpful to see the verbose logs (verbose true in the config)
Thanks for your reply! I was not sure what info you need, sorry for that.
Server key: How can I verify this? Should this be a new file in the data folder? This is what my data folder contains (resarted multiple times):
lldap_config.toml, private_key, users.db
Persistent: Yes, I pointed my data folder in my Portainer stack to the folder /home/Configs/lldap/data. Which seems to work, the files were created and after rebooting the container everything is the same like before the reboot.
Server key seed: Not using server seed, at least I didn't make any deliberate settings for that.
Log: I changed the verbosity to "true" and restarted the container. Where can I find the logs? There seems to be no log file in the data folder.
Yeah, that was the private key file I was talking about
The logs are on the standard output. If you're using docker, you can use
docker logs lldapHere's the log, does this help you narrow down the root cause?
It's a bit too noisy. Could you restart the container, try to log in, stop it, and give me the entire log? (Including the config at the beginning)
Sure, here you go:
That's an old LLDAP! Could you upgrade to stable?
Or v0.5 , equivalently
My stack is actually
image: nitnelave/lldap:stable
I changed it to
image: nitnelave/lldap:0.5
Which gave me this error:
failed to pull images of the stack: lldap Pulling lldap Error Error response from daemon: manifest for nitnelave/lldap:0.5 not found: manifest unknown: manifest unknown
With
image: nitnelave/lldap:latest
I can deploy it again, it also says LLDAP version 0.5.1-alpha on the login page, but I'm having the same issue with it.
BTW, I changed it back to latest, just like it was initially, and it says version 0.5 on the login page. No idea why the logs tell otherwise.
Ah, that's because you pulled the new image in the meantime 🙂
I think it's lldap:v0.5 if you want an explicit tag
And you can switch to lldap/lldap as well, instead of nitnelave
(same thing)
Did that, but nothing has changed... Still the same error.
Yeah, that's weird, I see the login request, so the failure must be client side
Can you walk me through what you're doing to log in?
Which page, what you enter and so on
I open the IP http://192.168.2.124:17170/
I enter admin as username
I enter the password that I specified in the config file. I tried it in an Incognito tab as well as on another machine. Everywhere the same result.
The only thing I can think of is that the password is genuinely wrong 😄
Did you try deleting the DB (assuming it's empty)?
I already tried to delete the users.db file and let it recreate by restarting the container, but I get the same result. I just did it again, just to be sure, and it's still the same.
I even copied the password from my config file to rule out any typos, but it's not working, no matter what I try. 😦
Hmm, what if you delete the DB and set the key_seed to a random string in the config?
You can also try logging in via LDAP :
ldapsearch -H ldap://localhost:3890 -D 'cn=admin,ou=people,dc=example,dc=com' -w password -x -b 'ou=people, dc=example,dc=com' '(objectclass=person)'
(maybe also check your environment, that you didn't set the password to a different value through an env variable ?)