L
LLDAP•2mo ago
Kuaqe

Kuaqe - Hey, am setting up the LLDAP docker con...

Hey, am setting up the LLDAP docker container standalone (before integration), and im having trouble with logging in as admin - Invalid username or password - the /data folder is persistent - both the config.toml file and users.db file are there and populated, but changing the toml doesnt seem to help - server has been restarted several times - usernames used: "admin" "lldap_admin" neither has worked - password has been the same one set using LLDAP_LDAP_USER_PASS var each time i think the environment vars arent being read properly(?)
docker_compose:
lldap:
container_name: lldap
image: lldap/lldap:stable
restart: unless-stopped
networks:
- frigate
# expose:
# - 17170 web ui port
# - 3890 LDAP
# - 6360 LDAPS
volumes:
- ./lldap_data:/data
environment:
- "UID=1000"
- "GID=1000"
- "TZ=Asia/Singapore"
- "LLDAP_JWT_SECRET=blabla"
- "LLDAP_KEY_SEED=blabla"
- "LLDAP_LDAP_USER_PASS=PASSWORD"
- "LLDAP_LDAP_BASE_DN=dc=domain,dc=example"
- "LLDAP_SMTP_OPTIONS__ENABLE_PASSWORD_RESET=true"
- "LLDAP_SMTP_OPTIONS__SERVER=send.ahasend.com"
- "LLDAP_SMTP_OPTIONS__PORT=587"
- "LLDAP_SMTP_OPTIONS__SMTP_ENCRYPTION=STARTTLS"
- "LLDAP_SMTP_OPTIONS__USER=UmnS4SpWbE" # The SMTP user, usually your email address
- "LLDAP_SMTP_OPTIONS__PASSWORD=SMTPPASS" # The SMTP password
- "LLDAP_SMTP_OPTIONS__FROM=Kuaqe's Mail Slaves <[email protected]>"
labels:
#traefik labels
networks:
frigate:
external: true
docker_compose:
lldap:
container_name: lldap
image: lldap/lldap:stable
restart: unless-stopped
networks:
- frigate
# expose:
# - 17170 web ui port
# - 3890 LDAP
# - 6360 LDAPS
volumes:
- ./lldap_data:/data
environment:
- "UID=1000"
- "GID=1000"
- "TZ=Asia/Singapore"
- "LLDAP_JWT_SECRET=blabla"
- "LLDAP_KEY_SEED=blabla"
- "LLDAP_LDAP_USER_PASS=PASSWORD"
- "LLDAP_LDAP_BASE_DN=dc=domain,dc=example"
- "LLDAP_SMTP_OPTIONS__ENABLE_PASSWORD_RESET=true"
- "LLDAP_SMTP_OPTIONS__SERVER=send.ahasend.com"
- "LLDAP_SMTP_OPTIONS__PORT=587"
- "LLDAP_SMTP_OPTIONS__SMTP_ENCRYPTION=STARTTLS"
- "LLDAP_SMTP_OPTIONS__USER=UmnS4SpWbE" # The SMTP user, usually your email address
- "LLDAP_SMTP_OPTIONS__PASSWORD=SMTPPASS" # The SMTP password
- "LLDAP_SMTP_OPTIONS__FROM=Kuaqe's Mail Slaves <[email protected]>"
labels:
#traefik labels
networks:
frigate:
external: true
some values changed for privacy
Solution:
Stupid question, stupider solution sigh Persisting the /data folder means the admin does not get a password if you start the docker container without the LLDAP_LDAP_USER_PASS ENV variable (which a lot of ppl might do, since its not listed in the sample docker compose) so i had to delete the users.db and recreate it for the admin login to work...
Jump to solution
23 Replies
Solution
Kuaqe
Kuaqe•2mo ago
Stupid question, stupider solution sigh Persisting the /data folder means the admin does not get a password if you start the docker container without the LLDAP_LDAP_USER_PASS ENV variable (which a lot of ppl might do, since its not listed in the sample docker compose) so i had to delete the users.db and recreate it for the admin login to work Please add this to the I can't log in! section or add the ENV variable to the docker compose example. Thanks!
nitnelave
nitnelave•2mo ago
Thanks! That's indeed something to add to "I can't log in", I thought it was already there!
Kuaqe
KuaqeOP•5w ago
about this ^ hope this gets into the next "big" merge, bc i was thinking its too small to pr
nitnelave
nitnelave•5w ago
You can definitely PR it if you want! That would be a very welcome PR. No such thing as a too small PR I just haven't found the time yet
Kuaqe
KuaqeOP•5w ago
sure! no worries, just making sure it doesnt happen to anyone else
nitnelave
nitnelave•5w ago
So, I had a look at your PR, and it got me thinking Documentation is nice, but it's never enough. The behavior of the admin password is actually documented in at least 2 places, that you apparently haven't found (I'm not blaming you, if anything it's the documentation's fault) How can we change the system so the situation is impossible, or at least easy and obvious to fix? Right now the admin is created with the default "password" password (no need to delete the DB) What if we refuse to create the admin when no password is set? That would be a hard error, obvious in the logs, with details on how to set the password (similarly, we could refuse to start with the default JWT secret)
Kuaqe
KuaqeOP•5w ago
Hi! So I did find the admin password's behavior based on what was given in the default lldap_config.toml template and a bit of my own thinking. However, I do agree that doing things this way is better, i.e forcing the container (in docker's case) into a restart loop and highlighting the lack of a good jwt secret and/or admin password in docker logs Off the top of my head, I think there are two approaches from what I've seen from other the services i've deployed 1. If the admin user is default -> set up the admin user on the first login to the web interface (initially insecure, but user friendly) 2. Do something similar to the above, but across all platforms. If the .toml file passes certain tests such as: - Admin password is atleast 8 characters long, has mix of upper/lower, special characters etc - JWT secret is atleast 32 characters long and satisfy the above conditions, moreover, it should NOT match those in a lightweight dictionary (to avoid predictable secrets) ...(likewise for other necessary parameters) ...then flip a boolean in the program/database (this config is "verified" so these tests dont have to be done again on reboot. also save the hash of the config file every time the config file changes (hash differs) -> run internal tests again I might be over engineering this part, but I think something like this would be sufficient. After all, it is the deployer's responsibility to make sure they do a decent job at the end of the day.
nitnelave
nitnelave•5w ago
I might want to do a half-assed job and let people shoot themselves in the foot after giving them proper directions. 1 needs UI work, and frankly I don't want to do that if I can avoid it 😄 As for the admin password restrictions, if they don't put a strong password that's on them. For the JWT secret, I might require 32 characters but moreover I'll print a command line to generate it, and I can even produce a sample secret for them (using rust randomness) But I'm not going to do a dictionary attack check
Kuaqe
KuaqeOP•5w ago
Fair enough, I hate doing UI too. Understand the admin password part too, so then it can just be a hard error if the password is "password" like you mentioned about the jwt secret part, do you think its better to have something like LLDAP_JWT_SECRET_AUTO=true/false LLDAP_JWT_SECRET_LENGTH= xx #above 32 chars LLDAP_JWT_SECRET=only used if the first var is false #still needs to be 32 chars and/or their .toml counterparts in the config?
nitnelave
nitnelave•5w ago
So, I toyed with that idea, generating it automatically The problem is where to store it? Unless... I could store it in the DB But I don't like secrets in the DB: if it leaks, you give the keys to the realm
Kuaqe
KuaqeOP•5w ago
hmmm
nitnelave
nitnelave•5w ago
I could write it next to the config, but some people like a read-only folder I could error in that case, asking them to deal with the JWT themselves
Kuaqe
KuaqeOP•5w ago
yeah perhaps print out the jwt in the error log and just tell them to copy it over or something I think considering all possible scenarios such as this one might hamper the ease of setup aspect that lldap has going on Considering most people use lldap in smaller scale environments, I dont think most of us are too restrictive on file permissions (from what I've seen) You might want to confirm this first, though
nitnelave
nitnelave•5w ago
There has been requests for stateless/HA from many people Some of them use helm charts or kube even in their home labs And that's usually friendlier with read-only folders Especially paired with PG to avoid the SQLite DB
Kuaqe
KuaqeOP•5w ago
I see
nitnelave
nitnelave•5w ago
If it was a case of "the only way to make it painless for everyone is to make it painful for them", why not But I think we have a pretty good alternative, no?
Kuaqe
KuaqeOP•5w ago
then I guess this is the most neutral route make it a touch more painful (in the form of errors) but significantly reduce the pain on most
nitnelave
nitnelave•5w ago
I like that all the tutorials are still valid We just have to add the password in the docker example, as in your PR
Kuaqe
KuaqeOP•5w ago
yep, thats a start for sure congrats on the project so far, and good luck!
nitnelave
nitnelave•5w ago
Thanks! Can you create an issue to keep track of all that? I'll try to do it soon but I don't know when
Kuaqe
KuaqeOP•5w ago
sure, will do sometime tomorrow
nitnelave
nitnelave•5w ago
I'll have another look at the PR, but I think we'll want to rethink it after implementing the changes we talked about
Kuaqe
KuaqeOP•5w ago
got it
Want results from more Discord servers?
Add your server