The currently logged in admin can't be deleted, admin itself can

At least in LLDAP

Have a simple solution to the disabled users #750 feature request, and it should work with your version of LLDAP as well, as long as you don't mind a group doing the functionality. https://github.com/Aelieth/lldap-with-kerberos/commit/8c0e037899a44ca6bc51f8e69a6ba90708966282

It's a simple fix, but I'd like to think more about UX: should disabled users be returned when you search for users? What's the error you get? How do they display? Having just the user be part of the disabled group will lead to confusion, I think, it's not clear enough unless you're a regular LLDAP maintainer/admin. I want LLDAP to be simple with very little to learn, more like set-and-forget. I expect casual admins will forget about that group

💯 Agreed, it's why I didn't put the rest of it in the same commit, just did that one commit for the base of it. The rest of it is different on KLLDAP due to how much it's changed. UX perspective, yes, they should be visually different - muted (and mine has an extra X next to their name to differentiate) I bet you can tell who is disabled there! Totally agree with your design principal of set-and-forget. https://cdn.discordapp.com/attachments/975815392175980585/1495809954899296347/image.png?ex=69e79914&is=69e64794&hm=05ce98a012e50bf1161165d6236c74eefa67d4366426334714e440d59c57ef6f&

Also, I ended up doing OU's the right way... created a system_settings table in the schema. Needed it for both the OU's and POSIX settings.

@here is anyone interested in a paid mission implementing TOTP 2FA in LLDAP? I have a potential client asking for a quote for implementation of https://github.com/lldap/lldap/issues/631 in view of CPCSC compliance. I'm looking for people with experience in Rust and OSS contributions, bonus if you have worked on non-trivial parts of LLDAP. I'll be consulting and reviewing the code, but I won't have that much time, so I need well thought-out and implemented solutions with good UX (and in particular, no half-baked AI slop). I'm not against AI use, but I'll judge the code as if a human wrote it and I expect the contributor to be able to stand proudly next to the PR. Of course, I don't expect the code to be perfect on the first try, but as long as an honest attempt was made we can work with that. Anyone interested?

> I want LLDAP to be simple with very little to learn, more like set-and-forget. I expect casual admins will forget about that group Just wanted to say I'm very much a casual admin and I really appreciate LLDAP for being set and forget. Thanks for considering that angle!

Got proper LDAP standardized search support going in my KLLDAP version. The code isn't pretty yet, but got the major bugs out and everything connecting, organizing, and recognized properly. Cleaning the code is next, and then implementing all the other functions for items like password changes, deletions, additions, and supported modifications (limited). After I finish this portion, I will take a look at the TOTP support if no one else has started it yet. https://cdn.discordapp.com/attachments/975815392175980585/1497658692877811903/image.png?ex=69ee52d9&is=69ed0159&hm=39e99fcbb64eb728815a17403d40878e89765af3f547d59d56c77d4d5a231f87&

Any updates on this? Can I somehow help you?

@Aelieth When you get started on the TOTP, please send me a couple of messages outlining your immediate work, so I can give early feedback. I saw a couple of points that won't pass review in your plan, but as it's nothing major I let it pass for the rough plan. I just want to save you some work going forward 😉

He seems to be AWOL. Maybe you can check his unmerged work? He's @broeng on GH, and I think you want his "plugin-support-4" branch on his fork. I have no idea what it looks like, though

Sorry, been a bit busy, but I'm still here, though not as actively checking the discord channel here, so I've missed some notifications, I see. You're welcome to DM me directly, I should see that. I'll try to have a look at rebasing it friday, then maybe we can have a look at it @Kumpelinus ?

Sure, sounds good 👍

Got some way with the rebase today, but there's been quite a bit of refactoring changes, so it's going to take a bit. I'll try to find a couple of hours a day next week to continue with it.

https://blog.janestreet.com/strace-ui-bonsai-term-and-the-tui-renaissance/ I think the future of LLDAP is to rewrite the web frontend in Ocaml, to capture the broad contributor base at the intersection of Rust and Ocaml who like to do web dev /s

sigh reminds me that Elm is really cool, but it's just so incredibly stale that it's not fun to start learning.

@nitnelave For multifactor / 2fa, would you prefer it on or off by default for the config? The options are true, false, or always - matching the existing enums. false - LLDAP functions as is, nothing visually changed, users cannot enroll themselves into MFA and admins cannot force them to enroll. true - users may choose to enroll their accounts into MFA, admins may reset their MFA if needed always - users must enroll their accounts into MFA after first login to LLDAP, users cannot auth via ldap or graph until their account has been setup with MFA. Admins may place users into the lldap_mfa_disabled to circumvent the forced MFA process and allow password only (typically on service accounts and etc, a group audit-able which is required by law)

My thought on true / false is to keep it false by default so that existing LLDAP deployments are not affected by throwing MFA into the mix on upgrade all of a sudden with a true option by default.

As someone running this, I'd prefer to keep it false, so that I don't have to deal with this on a routine upgrade.

Maybe with a message on the web UI for admins where the MFA management would be to tell them about the feature and how to enable it

It's to be in the README.md / faq.md as it's a configuration environment variable. There is no other section of LLDAP UI that does such admin guidance for features, so followed that structure. It's very straight-forward and easy to implement. In the lldap_config.docker_template.toml MFA policy (TOTP). false = disabled (default); true = enabled (opt-in, only users who have enrolled); "always" = require MFA for all users. Env: LLDAP_ENABLE_MFA enable_mfa = false Updating documentation info at the moment while doing further bug-testing. *Editing this to update the variable name chosen, enable makes more sense as it's not always required.

Implementing a 5 TOTP retry attempt per 30 seconds. If someone gets their TOTP wrong 5 times within 30 seconds they must wait until the next window to try again and shown an error accordingly. This is to satisfy NIST SHALL / RFC §7.3, limiting the amount of tries per window based on current two-factor implementation. This is best-effort implementation to meet any advanced guidelines for those using TOTP to satisfy standards. Seem reasonable? However, I cannot satisfy NIST 800-63B which is consecutive failure ceilings, which limits the total amount of logins attempt failures (max 100). This will be documented and up to the admin, just as current password attempts are documented to the admin to handle through something like a reverse proxy or fail2ban. Enabling / disable / locking user accounts and advanced logging are out of scope of the implementation.

Just a question, none of this will be required right?

I have authelia in front of my LDAPP instance. Authelia is my login lol

None of it is required, by default it's false (off)

Okay cool

LDAP just acts as normal!

Makes sense for people who aren't putting something else in front of it

I just have it as a sub path so... Lol