LLDAP•2mo ago

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•2mo ago

nitnelave•2mo ago

Thanks! That's indeed something to add to "I can't log in", I thought it was already there!

KuaqeOP•2mo ago

about this ^ hope this gets into the next "big" merge, bc i was thinking its too small to pr

nitnelave•2mo 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

KuaqeOP•2mo ago

sure! no worries, just making sure it doesnt happen to anyone else

nitnelave•2mo 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)

KuaqeOP•2mo 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•2mo 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

KuaqeOP•2mo 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•2mo 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

KuaqeOP•2mo ago

hmmm

nitnelave•2mo 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

KuaqeOP•2mo 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•2mo 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

KuaqeOP•2mo ago

I see

nitnelave•2mo 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?

KuaqeOP•2mo 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•2mo 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

KuaqeOP•2mo ago

yep, thats a start for sure congrats on the project so far, and good luck!

nitnelave•2mo 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

KuaqeOP•2mo ago

sure, will do sometime tomorrow

nitnelave•2mo 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

KuaqeOP•2mo ago

got it

Gaming

Programming

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