https://github.com/lldap/lldap logo
Powered by
Kuaqe - Hey, am setting up the LLDAP docker con...
# troubleshooting
k
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(?)
Copy code
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 <admin@domain.example>" 
    labels:
      #traefik labels
networks:
  frigate:
    external: true
some values changed for privacy
a
message has been deleted
k
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!
n
Thanks! That's indeed something to add to "I can't log in", I thought it was already there!
k
about this ^ hope this gets into the next "big" merge, bc i was thinking its too small to pr
n
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
k
sure! no worries, just making sure it doesnt happen to anyone else
n
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)
k
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.
n
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
k
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?
n
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
k
hmmm
n
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
k
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
n
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
k
I see
n
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?
k
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
n
I like that all the tutorials are still valid
We just have to add the password in the docker example, as in your PR
k
yep, thats a start for sure
congrats on the project so far, and good luck!
n
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
k
sure, will do sometime tomorrow
n
I'll have another look at the PR, but I think we'll want to rethink it after implementing the changes we talked about
k
got it
n
Just FYI, I just implemented that: now LLDAP won't start without an explicit JWT secret, and it won't create an admin without an explicit password
PreviousNext
Powered by