[GH-ISSUE #631] TOTP Support

kerem commented

2026-02-27 08:16:00 +03:00

Owner

Originally created by @andreax79 on GitHub (Aug 2, 2023).
Original GitHub issue: https://github.com/lldap/lldap/issues/631

Hi, is TOTP supported?
In the code i found:

            Column::TotpSecret => ColumnType::String(Some(64)),
            Column::MfaType => ColumnType::String(Some(64))

but i think they are not used.

Originally created by @andreax79 on GitHub (Aug 2, 2023). Original GitHub issue: https://github.com/lldap/lldap/issues/631 Hi, is TOTP supported? In the code i found: ```rust Column::TotpSecret => ColumnType::String(Some(64)), Column::MfaType => ColumnType::String(Some(64)) ``` but i think they are not used.

kerem added the

labels

2026-02-27 08:16:00 +03:00

kerem commented

2026-02-27 08:16:01 +03:00

Author

Owner

@nitnelave commented on GitHub (Aug 2, 2023):

It's not currently supported, no, but as you have seen, it was taken into account when designing.

@nitnelave commented on GitHub (Aug 2, 2023): It's not currently supported, no, but as you have seen, it was taken into account when designing.

kerem commented

2026-02-27 08:16:01 +03:00

Author

Owner

@andreax79 commented on GitHub (Aug 2, 2023):

It would be a great feature.
Probably more fields are required fot TOTP:

MfaType => TOTP, ...
Algorithm (SHA1, SHA256, SHA512)
Number of digits (e.g. 6 or 8 digits)
Period (e.g. 30 seconds)

@andreax79 commented on GitHub (Aug 2, 2023): It would be a great feature. Probably more fields are required fot TOTP: - MfaType => TOTP, ... - Algorithm (SHA1, SHA256, SHA512) - Number of digits (e.g. 6 or 8 digits) - Period (e.g. 30 seconds)

kerem commented

2026-02-27 08:16:01 +03:00

Author

Owner

@nitnelave commented on GitHub (Aug 2, 2023):

This would only be for logging in to LLDAP, right? Not using LLDAP as a storage for secrets for other TOTP logins.

In that case, we'd probably hardcode most of these parameters with safe defaults to simplify the implementation.

Note that I don't have any intent on implementing that right now, but contributions are welcome.

@nitnelave commented on GitHub (Aug 2, 2023): This would only be for logging in to LLDAP, right? Not using LLDAP as a storage for secrets for other TOTP logins. In that case, we'd probably hardcode most of these parameters with safe defaults to simplify the implementation. Note that I don't have any intent on implementing that right now, but contributions are welcome.

kerem commented

2026-02-27 08:16:01 +03:00

Author

Owner

@andreax79 commented on GitHub (Aug 2, 2023):

I'm thinking about something similar to slapo-otp,
where TOTOP is used in conjunction with the LDAP password for two-factor authentication.

@andreax79 commented on GitHub (Aug 2, 2023): I'm thinking about something similar to [slapo-otp](https://www.openldap.org/software/man.cgi?query=slapo-otp), where TOTOP is used in conjunction with the LDAP password for two-factor authentication.

kerem commented

2026-02-27 08:16:01 +03:00

Author

Owner

@nitnelave commented on GitHub (Aug 2, 2023):

Oh, I see what you mean: you want to provide a default, centralized TOTP for use in many applications. That's quite different from what I had in mind (TOTP limited to logging in to LLDAP in the web front-end).

Something that comes to mind, though: How do you provide the TOTP to LLDAP to validate? Especially through the LDAP interface. Most services do not implement that, and probably will not. How do you imagine the user experience?

@nitnelave commented on GitHub (Aug 2, 2023): Oh, I see what you mean: you want to provide a default, centralized TOTP for use in many applications. That's quite different from what I had in mind (TOTP limited to logging in to LLDAP in the web front-end). Something that comes to mind, though: How do you provide the TOTP to LLDAP to validate? Especially through the LDAP interface. Most services do not implement that, and probably will not. How do you imagine the user experience?

kerem commented

2026-02-27 08:16:01 +03:00

Author

Owner

@andreax79 commented on GitHub (Aug 2, 2023):

Some years ago I created something similar for authenticating OpenVPN using password + TOTP.
The users enter as password: password + separator (space) + TOTP
The separtor was optional because the TOTP lengh is know, but our users always insert a space between the password and the TOTP :)
The autentication was done with a python script performing the autentication (with the password) on LDAP and the TOTP check with a local db.

@andreax79 commented on GitHub (Aug 2, 2023): Some years ago I created something similar for authenticating OpenVPN using password + TOTP. The users enter as password: password + separator (space) + TOTP The separtor was optional because the TOTP lengh is know, but our users always insert a space between the password and the TOTP :) The autentication was done with a python script performing the autentication (with the password) on LDAP and the TOTP check with a local db.

kerem commented

2026-02-27 08:16:01 +03:00

Author

Owner

@nitnelave commented on GitHub (Aug 2, 2023):

Although it would technically work, it would be a hard flow to explain to users: there is no dedicated TOTP field, it doesn't play very well with password managers and so on. I feel that the use case is a bit too niche for LLDAP.

@nitnelave commented on GitHub (Aug 2, 2023): Although it would technically work, it would be a hard flow to explain to users: there is no dedicated TOTP field, it doesn't play very well with password managers and so on. I feel that the use case is a bit too niche for LLDAP.

kerem commented

2026-02-27 08:16:01 +03:00

Author

Owner

@tonygermano commented on GitHub (Nov 2, 2023):

This is exactly the feature I came here looking for. It is supported by at least Duo, Jumpcloud, and Okta. All 3 of them have the option when using LDAP+TOTP to append the TOTP code to the end of the password, separated by a comma.

https://jumpcloud.com/support/configure-mfa-for-ldap
https://help.okta.com/oie/en-us/content/topics/directory/ldap-interface-mfa.htm
https://duo.com/docs/ldap

@tonygermano commented on GitHub (Nov 2, 2023): This is exactly the feature I came here looking for. It is supported by at least Duo, Jumpcloud, and Okta. All 3 of them have the option when using LDAP+TOTP to append the TOTP code to the end of the password, separated by a comma. https://jumpcloud.com/support/configure-mfa-for-ldap https://help.okta.com/oie/en-us/content/topics/directory/ldap-interface-mfa.htm https://duo.com/docs/ldap

kerem commented

2026-02-27 08:16:02 +03:00

Author

Owner

@nitnelave commented on GitHub (Nov 29, 2023):

Reopening as it might actually be interesting, and it seems to be half standard (duo, okta, ...)

Still not planned anytime soon though.

It's possible to set up e.g. duo as an LDAP proxy that adds MFA, that's the recommended workaround for now.

@nitnelave commented on GitHub (Nov 29, 2023): Reopening as it might actually be interesting, and it seems to be half standard (duo, okta, ...) Still not planned anytime soon though. It's possible to set up e.g. duo as an LDAP proxy that adds MFA, that's the recommended workaround for now.

kerem commented

2026-02-27 08:16:02 +03:00

Author

Owner

@paulo-roger commented on GitHub (Sep 10, 2024):

Hi, I am a bit confused.

I have some users that I imported into lldap and som of them have TOTP enabled. So lldap will only take care of their passwords and each service is still responsible for their own TOTP implementation?

@paulo-roger commented on GitHub (Sep 10, 2024): Hi, I am a bit confused. I have some users that I imported into lldap and som of them have TOTP enabled. So lldap will only take care of their passwords and each service is still responsible for their own TOTP implementation?

kerem commented

2026-02-27 08:16:02 +03:00

Author

Owner

@nitnelave commented on GitHub (Sep 11, 2024):

That's the current state of things, yes. This issue contains a proposal to support the syntax "password 123456" for a 6-digit TOTP validated by LLDAP. There are already some allowances made in the DB to support TOTP, but it's not implemented yet.

Moreover, we'd have to think about various features:

backup keys
admin reset of 2FA for other users
probably some other UX that I can't think of right now.

Speaking of UX, the UI work to support that is non-trivial, including generating the QR code to scan with the phone.

@nitnelave commented on GitHub (Sep 11, 2024): That's the current state of things, yes. This issue contains a proposal to support the syntax "password 123456" for a 6-digit TOTP validated by LLDAP. There are already some allowances made in the DB to support TOTP, but it's not implemented yet. Moreover, we'd have to think about various features: - backup keys - admin reset of 2FA for other users - probably some other UX that I can't think of right now. Speaking of UX, the UI work to support that is non-trivial, including generating the QR code to scan with the phone.

kerem commented

2026-02-27 08:16:02 +03:00

Author

Owner

@paulo-roger commented on GitHub (Sep 13, 2024):

Hi!

Thank you so much for the clarification and for all the amazing work you’ve done with LLDAP! I’m still relatively new to LDAP, so I was a bit confused about how TOTP fits into the setup, but your explanation really helped.

Honestly, I don’t have any complaints — I actually like the way things work currently and appreciate the flexibility it offers. No worries from me at all!

Thanks again for your help and for making such a great tool!

@paulo-roger commented on GitHub (Sep 13, 2024): Hi! Thank you so much for the clarification and for all the amazing work you’ve done with LLDAP! I’m still relatively new to LDAP, so I was a bit confused about how TOTP fits into the setup, but your explanation really helped. Honestly, I don’t have any complaints — I actually like the way things work currently and appreciate the flexibility it offers. No worries from me at all! Thanks again for your help and for making such a great tool!

kerem commented

2026-02-27 08:16:02 +03:00

Author

Owner

@tonygermano commented on GitHub (Sep 13, 2024):

That's the current state of things, yes. This issue contains a proposal to support the syntax "password 123456" for a 6-digit TOTP validated by LLDAP. There are already some allowances made in the DB to support TOTP, but it's not implemented yet.

Moreover, we'd have to think about various features:

backup keys

admin reset of 2FA for other users

probably some other UX that I can't think of right now.

Speaking of UX, the UI work to support that is non-trivial, including generating the QR code to scan with the phone.

I've configured this in trial environments for both JumpCloud and Okta now. They were pretty similar.

On the admin side they allow the user to define MFA policies that can apply to specific groups (including an All Users group) and exclude certain users from those groups. For instance, if you have a service which needs to bind with an admin account in order to look up the other users, you want to be able to exclude the bind account from the MFA requirements.

Additionally, different policies can be applied whether the user is authenticating over LDAP or logging into the user side of the web portal. So, while you may require MFA to authenticate with LDAP, if the admin removes the last MFA enrolled device, the user can still complete a new enrollment through the portal (following a similar process as a forced password reset.) You could use the same secret for all of that user's devices, but then if you need to reset it because a device was lost, all devices will need to be set up again.

I'm not a rust programmer, but I would think you could use a library to generate the QR code. A QR code is basically just an encoded string. In this case, a specially formed uri that contains the key that a user would manually type into the authenticator app on a device without a camera.

@tonygermano commented on GitHub (Sep 13, 2024): > That's the current state of things, yes. This issue contains a proposal to support the syntax "password 123456" for a 6-digit TOTP validated by LLDAP. There are already some allowances made in the DB to support TOTP, but it's not implemented yet. > > Moreover, we'd have to think about various features: > > * backup keys > * admin reset of 2FA for other users > * probably some other UX that I can't think of right now. > > Speaking of UX, the UI work to support that is non-trivial, including generating the QR code to scan with the phone. I've configured this in trial environments for both JumpCloud and Okta now. They were pretty similar. On the admin side they allow the user to define MFA policies that can apply to specific groups (including an All Users group) and exclude certain users from those groups. For instance, if you have a service which needs to bind with an admin account in order to look up the other users, you want to be able to exclude the bind account from the MFA requirements. Additionally, different policies can be applied whether the user is authenticating over LDAP or logging into the user side of the web portal. So, while you may require MFA to authenticate with LDAP, if the admin removes the last MFA enrolled device, the user can still complete a new enrollment through the portal (following a similar process as a forced password reset.) You could use the same secret for all of that user's devices, but then if you need to reset it because a device was lost, all devices will need to be set up again. I'm not a rust programmer, but I would think you could use a [library](https://docs.rs/qrcode-generator/latest/qrcode_generator/) to generate the QR code. A QR code is basically just an encoded string. In this case, a [specially formed uri](https://github.com/google/google-authenticator/wiki/Key-Uri-Format) that contains the key that a user would manually type into the authenticator app on a device without a camera.

kerem commented

2026-02-27 08:16:02 +03:00

Author

Owner

@nitnelave commented on GitHub (Sep 13, 2024):

Sure, I don't expect the QR code to be an unsurmountable obstacle, it's just something else to think about :)

@nitnelave commented on GitHub (Sep 13, 2024): Sure, I don't expect the QR code to be an unsurmountable obstacle, it's just something else to think about :)

Rows
Columns

[GH-ISSUE #631] TOTP Support #229