[GH-ISSUE #371] Unable to log in after bootstrapping #144

Closed
opened 2026-02-27 08:15:30 +03:00 by kerem · 8 comments
Owner

Originally created by @ViViDboarder on GitHub (Nov 15, 2022).
Original GitHub issue: https://github.com/lldap/lldap/issues/371

I've been debugging this for a while and hitting a dead end. I can't tell if I'm just missing something or what.

I saw some other user had issues due to it loading the wrong file initially and creating the admin user, so I moved my admin user to environment variables. I've set the following:

LLDAP_VERBOSE=true
LLDAP_LDAP_USER_DN=my-admin
LLDAP_LDAP_USER_EMAIL=ian@example.com
LLDAP_LDAP_USER_PASS=hushnowthisisok

When I look in my logs I see that the config is understood when it prints out my configuration. I can also see it set up the rest of the server:

2022-11-15T19:58:51.984959595+00:00 INFO     set_up_server [ 119ms | 99.12% / 100.00% ]
2022-11-15T19:58:52.027698600+00:00 INFO     ┝━ i [info]: Starting LLDAP version 0.4.2-alpha
2022-11-15T19:58:52.215889241+00:00 DEBUG    ┝━ get_user_details [ 357µs | 0.30% ]
2022-11-15T19:58:52.215905281+00:00 DEBUG    │  ┝━ 🐛 [debug]:  | user_id: UserId("my-admin")
2022-11-15T19:58:52.215938746+00:00 DEBUG    │  ┝━ 🐛 [debug]:  | query: SELECT "user_id", "email", "display_name", "first_name", "last_name", "avatar", "creation_date", "uuid" FROM "users" WHERE "user_id" = ?
2022-11-15T19:58:52.216797362+00:00 DEBUG    │  ┕━ 🐛 [debug]:  | return: Ok(User { user_id: UserId("my-admin"), email: "ian@example.com", display_name: "Administrator", first_name: "", last_name: "", avatar: JpegPhoto([]), creation_date: 2022-11-15T19:58:45.747905475Z, uuid: Uuid("1235ec85-6e91-3c2b-b9dc-150dadf91e62") })
2022-11-15T19:58:52.217594782+00:00 DEBUG    ┝━ list_groups [ 188µs | 0.16% ]
2022-11-15T19:58:52.217606761+00:00 DEBUG    │  ┝━ 🐛 [debug]:  | filters: Some(DisplayName("lldap_password_manager"))
2022-11-15T19:58:52.217674711+00:00 DEBUG    │  ┝━ 🐛 [debug]:  | query: SELECT "groups"."group_id", "display_name", "creation_date", "uuid", "user_id" FROM "groups" LEFT JOIN "memberships" ON "groups"."group_id" = "memberships"."group_id" WHERE "groups"."display_name" = ? ORDER BY "display_name" ASC, "user_id" ASC
2022-11-15T19:58:52.217991984+00:00 DEBUG    │  ┕━ 🐛 [debug]:  | return: []
2022-11-15T19:58:52.218004288+00:00 WARN     ┝━ 🚧 [warn]: Could not find password_manager group, trying to create it
2022-11-15T19:58:52.218006277+00:00 DEBUG    ┝━ create_group [ 252µs | 0.21% ]
2022-11-15T19:58:52.218009302+00:00 DEBUG    │  ┝━ 🐛 [debug]:  | group_name: "lldap_password_manager"
2022-11-15T19:58:52.218036297+00:00 DEBUG    │  ┝━ 🐛 [debug]:  | query: INSERT INTO "groups" ("display_name", "creation_date", "uuid") VALUES (?, ?, ?)
2022-11-15T19:58:52.294651698+00:00 DEBUG    │  ┝━ 🐛 [debug]:  | query: SELECT "group_id" FROM "groups" WHERE "display_name" = ?
2022-11-15T19:58:52.294859812+00:00 DEBUG    │  ┕━ 🐛 [debug]:  | return: GroupId(1)
2022-11-15T19:58:52.294867671+00:00 DEBUG    ┝━ create_group [ 164µs | 0.14% ]
2022-11-15T19:58:52.294870994+00:00 DEBUG    │  ┝━ 🐛 [debug]:  | group_name: "lldap_strict_readonly"
2022-11-15T19:58:52.294892987+00:00 DEBUG    │  ┝━ 🐛 [debug]:  | query: INSERT INTO "groups" ("display_name", "creation_date", "uuid") VALUES (?, ?, ?)
2022-11-15T19:58:52.350618867+00:00 DEBUG    │  ┝━ 🐛 [debug]:  | query: SELECT "group_id" FROM "groups" WHERE "display_name" = ?
2022-11-15T19:58:52.350732280+00:00 DEBUG    │  ┕━ 🐛 [debug]:  | return: GroupId(2)
2022-11-15T19:58:52.351423618+00:00 INFO     ┝━ i [info]: Starting the LDAP server on port 3890
2022-11-15T19:58:52.564230375+00:00 DEBUG    ┝━ get_jwt_blacklist [ 84.2µs | 0.07% ]
2022-11-15T19:58:52.564247969+00:00 DEBUG    │  ┕━ 🐛 [debug]:  | query: SELECT "jwt_hash" FROM "jwt_storage"
2022-11-15T19:58:52.564712920+00:00 INFO     ┕━ i [info]: Starting the API/web server on port 17170
2022-11-15T19:58:52.564922411+00:00 INFO     i [info]: Starting 1 workers | log.target: "actix_server::builder" | log.module_path: "actix_server::builder" | log.file: "/__w/lldap/lldap/${GITHUB_WORKSPACE}/.cargo/registry/src/github.com-1ecc6299db9ec823/actix-server-2.0.0-beta.5/src/builder.rs" | log.line: 281
2022-11-15T19:58:52.567995397+00:00 INFO     i [info]: Starting "ldap" service on 0.0.0.0:3890 | log.target: "actix_server::builder" | log.module_path: "actix_server::builder" | log.file: "/__w/lldap/lldap/${GITHUB_WORKSPACE}/.cargo/registry/src/github.com-1ecc6299db9ec823/actix-server-2.0.0-beta.5/src/builder.rs" | log.line: 296
2022-11-15T19:58:52.568771363+00:00 INFO     i [info]: Starting "http" service on 0.0.0.0:17170 | log.target: "actix_server::builder" | log.module_path: "actix_server::builder" | log.file: "/__w/lldap/lldap/${GITHUB_WORKSPACE}/.cargo/registry/src/github.com-1ecc6299db9ec823/actix-server-2.0.0-beta.5/src/builder.rs" | log.line: 296
2022-11-15T19:58:52.569182142+00:00 INFO     i [info]: DB Cleanup Cron started

So it looks like it's created the user just fine. I can also verify this and the user shows up in the sqlite database.

When I try to log in, I get an error message saying the user or password is incorrect and the following in my logs:

2022-11-15T20:00:20.902291363+00:00 INFO     HTTP request [ 760µs | 7.89% / 100.00% ]
2022-11-15T20:00:20.902297744+00:00 INFO     ┝━ i [info]:  | uri: /auth/opaque/login/start
2022-11-15T20:00:20.902340590+00:00 DEBUG    ┝━ opaque_login_start [ 700µs | 1.08% / 92.11% ]
2022-11-15T20:00:20.902343268+00:00 DEBUG    │  ┕━ login_start [ 691µs | 82.79% / 91.03% ]
2022-11-15T20:00:20.902344754+00:00 DEBUG    │     ┕━ get_password_file_for_user [ 62.6µs | 8.24% ]
2022-11-15T20:00:20.903240696+00:00 INFO     ┕━ i [info]:  | status_code: 200

Any ideas how I can debug further?

Originally created by @ViViDboarder on GitHub (Nov 15, 2022). Original GitHub issue: https://github.com/lldap/lldap/issues/371 I've been debugging this for a while and hitting a dead end. I can't tell if I'm just missing something or what. I saw some other user had issues due to it loading the wrong file initially and creating the admin user, so I moved my admin user to environment variables. I've set the following: LLDAP_VERBOSE=true LLDAP_LDAP_USER_DN=my-admin LLDAP_LDAP_USER_EMAIL=ian@example.com LLDAP_LDAP_USER_PASS=hushnowthisisok When I look in my logs I see that the config is understood when it prints out my configuration. I can also see it set up the rest of the server: ``` 2022-11-15T19:58:51.984959595+00:00 INFO set_up_server [ 119ms | 99.12% / 100.00% ] 2022-11-15T19:58:52.027698600+00:00 INFO ┝━ i [info]: Starting LLDAP version 0.4.2-alpha 2022-11-15T19:58:52.215889241+00:00 DEBUG ┝━ get_user_details [ 357µs | 0.30% ] 2022-11-15T19:58:52.215905281+00:00 DEBUG │ ┝━ 🐛 [debug]: | user_id: UserId("my-admin") 2022-11-15T19:58:52.215938746+00:00 DEBUG │ ┝━ 🐛 [debug]: | query: SELECT "user_id", "email", "display_name", "first_name", "last_name", "avatar", "creation_date", "uuid" FROM "users" WHERE "user_id" = ? 2022-11-15T19:58:52.216797362+00:00 DEBUG │ ┕━ 🐛 [debug]: | return: Ok(User { user_id: UserId("my-admin"), email: "ian@example.com", display_name: "Administrator", first_name: "", last_name: "", avatar: JpegPhoto([]), creation_date: 2022-11-15T19:58:45.747905475Z, uuid: Uuid("1235ec85-6e91-3c2b-b9dc-150dadf91e62") }) 2022-11-15T19:58:52.217594782+00:00 DEBUG ┝━ list_groups [ 188µs | 0.16% ] 2022-11-15T19:58:52.217606761+00:00 DEBUG │ ┝━ 🐛 [debug]: | filters: Some(DisplayName("lldap_password_manager")) 2022-11-15T19:58:52.217674711+00:00 DEBUG │ ┝━ 🐛 [debug]: | query: SELECT "groups"."group_id", "display_name", "creation_date", "uuid", "user_id" FROM "groups" LEFT JOIN "memberships" ON "groups"."group_id" = "memberships"."group_id" WHERE "groups"."display_name" = ? ORDER BY "display_name" ASC, "user_id" ASC 2022-11-15T19:58:52.217991984+00:00 DEBUG │ ┕━ 🐛 [debug]: | return: [] 2022-11-15T19:58:52.218004288+00:00 WARN ┝━ 🚧 [warn]: Could not find password_manager group, trying to create it 2022-11-15T19:58:52.218006277+00:00 DEBUG ┝━ create_group [ 252µs | 0.21% ] 2022-11-15T19:58:52.218009302+00:00 DEBUG │ ┝━ 🐛 [debug]: | group_name: "lldap_password_manager" 2022-11-15T19:58:52.218036297+00:00 DEBUG │ ┝━ 🐛 [debug]: | query: INSERT INTO "groups" ("display_name", "creation_date", "uuid") VALUES (?, ?, ?) 2022-11-15T19:58:52.294651698+00:00 DEBUG │ ┝━ 🐛 [debug]: | query: SELECT "group_id" FROM "groups" WHERE "display_name" = ? 2022-11-15T19:58:52.294859812+00:00 DEBUG │ ┕━ 🐛 [debug]: | return: GroupId(1) 2022-11-15T19:58:52.294867671+00:00 DEBUG ┝━ create_group [ 164µs | 0.14% ] 2022-11-15T19:58:52.294870994+00:00 DEBUG │ ┝━ 🐛 [debug]: | group_name: "lldap_strict_readonly" 2022-11-15T19:58:52.294892987+00:00 DEBUG │ ┝━ 🐛 [debug]: | query: INSERT INTO "groups" ("display_name", "creation_date", "uuid") VALUES (?, ?, ?) 2022-11-15T19:58:52.350618867+00:00 DEBUG │ ┝━ 🐛 [debug]: | query: SELECT "group_id" FROM "groups" WHERE "display_name" = ? 2022-11-15T19:58:52.350732280+00:00 DEBUG │ ┕━ 🐛 [debug]: | return: GroupId(2) 2022-11-15T19:58:52.351423618+00:00 INFO ┝━ i [info]: Starting the LDAP server on port 3890 2022-11-15T19:58:52.564230375+00:00 DEBUG ┝━ get_jwt_blacklist [ 84.2µs | 0.07% ] 2022-11-15T19:58:52.564247969+00:00 DEBUG │ ┕━ 🐛 [debug]: | query: SELECT "jwt_hash" FROM "jwt_storage" 2022-11-15T19:58:52.564712920+00:00 INFO ┕━ i [info]: Starting the API/web server on port 17170 2022-11-15T19:58:52.564922411+00:00 INFO i [info]: Starting 1 workers | log.target: "actix_server::builder" | log.module_path: "actix_server::builder" | log.file: "/__w/lldap/lldap/${GITHUB_WORKSPACE}/.cargo/registry/src/github.com-1ecc6299db9ec823/actix-server-2.0.0-beta.5/src/builder.rs" | log.line: 281 2022-11-15T19:58:52.567995397+00:00 INFO i [info]: Starting "ldap" service on 0.0.0.0:3890 | log.target: "actix_server::builder" | log.module_path: "actix_server::builder" | log.file: "/__w/lldap/lldap/${GITHUB_WORKSPACE}/.cargo/registry/src/github.com-1ecc6299db9ec823/actix-server-2.0.0-beta.5/src/builder.rs" | log.line: 296 2022-11-15T19:58:52.568771363+00:00 INFO i [info]: Starting "http" service on 0.0.0.0:17170 | log.target: "actix_server::builder" | log.module_path: "actix_server::builder" | log.file: "/__w/lldap/lldap/${GITHUB_WORKSPACE}/.cargo/registry/src/github.com-1ecc6299db9ec823/actix-server-2.0.0-beta.5/src/builder.rs" | log.line: 296 2022-11-15T19:58:52.569182142+00:00 INFO i [info]: DB Cleanup Cron started ``` So it looks like it's created the user just fine. I can also verify this and the user shows up in the sqlite database. When I try to log in, I get an error message saying the user or password is incorrect and the following in my logs: ``` 2022-11-15T20:00:20.902291363+00:00 INFO HTTP request [ 760µs | 7.89% / 100.00% ] 2022-11-15T20:00:20.902297744+00:00 INFO ┝━ i [info]: | uri: /auth/opaque/login/start 2022-11-15T20:00:20.902340590+00:00 DEBUG ┝━ opaque_login_start [ 700µs | 1.08% / 92.11% ] 2022-11-15T20:00:20.902343268+00:00 DEBUG │ ┕━ login_start [ 691µs | 82.79% / 91.03% ] 2022-11-15T20:00:20.902344754+00:00 DEBUG │ ┕━ get_password_file_for_user [ 62.6µs | 8.24% ] 2022-11-15T20:00:20.903240696+00:00 INFO ┕━ i [info]: | status_code: 200 ``` Any ideas how I can debug further?
kerem closed this issue 2026-02-27 08:15:30 +03:00
Author
Owner

@nitnelave commented on GitHub (Nov 15, 2022):

The admin password is only used when creating the admin user for the first time. My guess is that you ran the server a first time with a (potentially default) password, the admin was created with this password, and then you changed it in the config: that doesn't change the admin password. If you haven't done anything else (creating users and so on), the simplest is to just delete the database and restart the server. That'll create the admin password with the right password.

<!-- gh-comment-id:1315818461 --> @nitnelave commented on GitHub (Nov 15, 2022): The admin password is only used when creating the admin user for the first time. My guess is that you ran the server a first time with a (potentially default) password, the admin was created with this password, and then you changed it in the config: that doesn't change the admin password. If you haven't done anything else (creating users and so on), the simplest is to just delete the database and restart the server. That'll create the admin password with the right password.
Author
Owner

@ViViDboarder commented on GitHub (Nov 15, 2022):

No. I've been deleting the whole data dir every time I've tried and verified that it creates the user with (I'm assuming) the password provided at user creation.

<!-- gh-comment-id:1315821626 --> @ViViDboarder commented on GitHub (Nov 15, 2022): No. I've been deleting the whole data dir every time I've tried and verified that it creates the user with (I'm assuming) the password provided at user creation.
Author
Owner

@ViViDboarder commented on GitHub (Nov 15, 2022):

Oh. Interesting... When I connect over ldap I see more logs:

2022-11-15T20:23:21.091619241+00:00 INFO     LDAP session [ 408µs | 17.71% / 100.00% ]
2022-11-15T20:23:21.092964549+00:00 INFO     ┕━ LDAP request [ 336µs | 35.12% / 82.29% ]
2022-11-15T20:23:21.092975741+00:00 DEBUG       ┝━ 🐛 [debug]:  | msg: LdapMsg { msgid: 1, op: BindRequest(LdapBindRequest { dn: "uid=thefij-admin,ou=people,dc=thefij,dc=rocks", cred: Simple("********") }), ctrl: [] }
2022-11-15T20:23:21.092978186+00:00 DEBUG       ┝━ do_bind [ 192µs | 3.42% / 47.17% ]
2022-11-15T20:23:21.092980128+00:00 DEBUG       │  ┝━ 🐛 [debug]: DN: uid=thefij-admin,ou=people,dc=thefij,dc=rocks
2022-11-15T20:23:21.092988681+00:00 DEBUG       │  ┕━ bind [ 178µs | 43.76% ]
2022-11-15T20:23:21.093160612+00:00 DEBUG       │     ┝━ 🐛 [debug]: User "thefij-admin" has no password
2022-11-15T20:23:21.093165955+00:00 ERROR       │     ┕━ 🚨 [error]:  | error: Authentication error: ` for user 'thefij-admin'`
2022-11-15T20:23:21.093177294+00:00 DEBUG       ┕━ 🐛 [debug]:  | response: BindResponse(LdapBindResponse { res: LdapResult { code: InvalidCredentials, matcheddn: "", message: "", referral: [] }, saslcreds: None })

So maybe the user has no password.

<!-- gh-comment-id:1315824404 --> @ViViDboarder commented on GitHub (Nov 15, 2022): Oh. Interesting... When I connect over ldap I see more logs: ``` 2022-11-15T20:23:21.091619241+00:00 INFO LDAP session [ 408µs | 17.71% / 100.00% ] 2022-11-15T20:23:21.092964549+00:00 INFO ┕━ LDAP request [ 336µs | 35.12% / 82.29% ] 2022-11-15T20:23:21.092975741+00:00 DEBUG ┝━ 🐛 [debug]: | msg: LdapMsg { msgid: 1, op: BindRequest(LdapBindRequest { dn: "uid=thefij-admin,ou=people,dc=thefij,dc=rocks", cred: Simple("********") }), ctrl: [] } 2022-11-15T20:23:21.092978186+00:00 DEBUG ┝━ do_bind [ 192µs | 3.42% / 47.17% ] 2022-11-15T20:23:21.092980128+00:00 DEBUG │ ┝━ 🐛 [debug]: DN: uid=thefij-admin,ou=people,dc=thefij,dc=rocks 2022-11-15T20:23:21.092988681+00:00 DEBUG │ ┕━ bind [ 178µs | 43.76% ] 2022-11-15T20:23:21.093160612+00:00 DEBUG │ ┝━ 🐛 [debug]: User "thefij-admin" has no password 2022-11-15T20:23:21.093165955+00:00 ERROR │ ┕━ 🚨 [error]: | error: Authentication error: ` for user 'thefij-admin'` 2022-11-15T20:23:21.093177294+00:00 DEBUG ┕━ 🐛 [debug]: | response: BindResponse(LdapBindResponse { res: LdapResult { code: InvalidCredentials, matcheddn: "", message: "", referral: [] }, saslcreds: None }) ``` So maybe the user has _no_ password.
Author
Owner

@ViViDboarder commented on GitHub (Nov 15, 2022):

When I query the database with sqlite, the password hash seems to be blank. The user even shows up if I query select * from users where password_hash is null;

<!-- gh-comment-id:1315826820 --> @ViViDboarder commented on GitHub (Nov 15, 2022): When I query the database with sqlite, the password hash seems to be blank. The user even shows up if I query `select * from users where password_hash is null;`
Author
Owner

@ViViDboarder commented on GitHub (Nov 15, 2022):

One strange thing I'm noticing on startup is that, after cleaning out the data dir and starting again the logs show:

[entrypoint] Copying the default config to /data/lldap_config.toml
[entrypoint] Edit this file to configure LLDAP.
> Setup permissions..
> Starting lldap..
Loading configuration from /lldap_config.toml
Configuration: Configuration {
... snip ...
}
DEPRECATED: smtp_options.tls_required field is deprecated, it never did anything. You can replace it with smtp_options.smtp_encryption.
> Setup permissions..
> Starting lldap..
Loading configuration from /lldap_config.toml
Configuration: Configuration {
... snip ...
}
DEPRECATED: smtp_options.tls_required field is deprecated, it never did anything. You can replace it with smtp_options.smtp_encryption.
2022-11-15T20:31:43.407407240+00:00 INFO     set_up_server [ 43.5ms | 96.54% / 100.00% ]
2022-11-15T20:31:43.408037643+00:00 INFO     ┝━ i [info]: Starting LLDAP version 0.4.2-alpha
...

So it looks like it starts twice?

Looking at main.rs for the sever, it seems to be creating the user, but failing to set the password, crashing, and then restarting, finding the user (not checking the password), then not-finding the groups (because it crashed at pass assigment) and creating them in the second go.

I'm not sure why there is no error or anything on stdout or stderr for what appears to be a crash.

<!-- gh-comment-id:1315833457 --> @ViViDboarder commented on GitHub (Nov 15, 2022): One strange thing I'm noticing on startup is that, after cleaning out the data dir and starting again the logs show: ``` [entrypoint] Copying the default config to /data/lldap_config.toml [entrypoint] Edit this file to configure LLDAP. > Setup permissions.. > Starting lldap.. Loading configuration from /lldap_config.toml Configuration: Configuration { ... snip ... } DEPRECATED: smtp_options.tls_required field is deprecated, it never did anything. You can replace it with smtp_options.smtp_encryption. > Setup permissions.. > Starting lldap.. Loading configuration from /lldap_config.toml Configuration: Configuration { ... snip ... } DEPRECATED: smtp_options.tls_required field is deprecated, it never did anything. You can replace it with smtp_options.smtp_encryption. 2022-11-15T20:31:43.407407240+00:00 INFO set_up_server [ 43.5ms | 96.54% / 100.00% ] 2022-11-15T20:31:43.408037643+00:00 INFO ┝━ i [info]: Starting LLDAP version 0.4.2-alpha ... ``` So it looks like it starts twice? Looking at `main.rs` for the sever, it seems to be creating the user, but failing to set the password, crashing, and then restarting, finding the user (not checking the password), then not-finding the groups (because it crashed at pass assigment) and creating them in the second go. I'm not sure why there is no error or anything on stdout or stderr for what appears to be a crash.
Author
Owner

@ViViDboarder commented on GitHub (Nov 15, 2022):

Though I'm not sure why I never see warn!("Could not get admin user, trying to create it: {:#}", e); shown anywhere in my logs either as it seems like it should be logged right before the creation.

<!-- gh-comment-id:1315835871 --> @ViViDboarder commented on GitHub (Nov 15, 2022): Though I'm not sure why I never see `warn!("Could not get admin user, trying to create it: {:#}", e);` shown anywhere in my logs either as it seems like it should be logged right before the creation.
Author
Owner

@ViViDboarder commented on GitHub (Nov 15, 2022):

Ok, figured it out! Looks like it was getting killed by my scheduler due to OOM. That explains the abrupt cutoff in my logs with no stack trace.

I figured it out by execing into the container, deleting the data, and running the entrypoint. There it ended with Killed. Only then, my scheduler showed an OOM event!

Increased the memory and it's good.

<!-- gh-comment-id:1315882001 --> @ViViDboarder commented on GitHub (Nov 15, 2022): Ok, figured it out! Looks like it was getting killed by my scheduler due to OOM. That explains the abrupt cutoff in my logs with no stack trace. I figured it out by `exec`ing into the container, deleting the data, and running the entrypoint. There it ended with `Killed`. Only then, my scheduler showed an OOM event! Increased the memory and it's good.
Author
Owner

@nitnelave commented on GitHub (Nov 15, 2022):

Ah, yes, the "password hashing" process is quite memory intensive (and CPU
intensive as well). It's intentional in order to make brute force attacks
impractical in case the server gets hacked and the DB leaks.

On Tue, 15 Nov 2022, 22:24 Ian, @.***> wrote:

Closed #371 https://github.com/nitnelave/lldap/issues/371 as completed.


Reply to this email directly, view it on GitHub
https://github.com/nitnelave/lldap/issues/371#event-7817671287, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGCPWII5U42ACG5MXFYN53WIP5SNANCNFSM6AAAAAASBKEF24
.
You are receiving this because you commented.Message ID:
@.***>

<!-- gh-comment-id:1315990756 --> @nitnelave commented on GitHub (Nov 15, 2022): Ah, yes, the "password hashing" process is quite memory intensive (and CPU intensive as well). It's intentional in order to make brute force attacks impractical in case the server gets hacked and the DB leaks. On Tue, 15 Nov 2022, 22:24 Ian, ***@***.***> wrote: > Closed #371 <https://github.com/nitnelave/lldap/issues/371> as completed. > > — > Reply to this email directly, view it on GitHub > <https://github.com/nitnelave/lldap/issues/371#event-7817671287>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAGCPWII5U42ACG5MXFYN53WIP5SNANCNFSM6AAAAAASBKEF24> > . > You are receiving this because you commented.Message ID: > ***@***.***> >
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/lldap-lldap#144
No description provided.