[GH-ISSUE #1168] [FEATURE REQUEST] Store NTLM hashes for basic Samba integration #417

Closed
opened 2026-02-27 08:17:11 +03:00 by kerem · 5 comments
Owner

Originally created by @mitchins on GitHub (May 9, 2025).
Original GitHub issue: https://github.com/lldap/lldap/issues/1168

Motivation
I run LLDAP with multiple Samba instances in a home network. Need a way to keep passwords in sync between both systems without manual management.

Describe the solution you'd like
When passwords are set in LLDAP, automatically calculate and store NTLM hashes (sambaNTPassword attribute). This would allow me to periodically sync these hashes to my Samba servers for users in the samba group.

Describe alternatives you've considered
Currently maintaining separate password databases or manually running smbpasswd after password changes, which is error-prone and frustrating for users.

Additional context
This would be a minimal change that doesn't require full Samba schema support but still enables basic integration for home setups.

Originally created by @mitchins on GitHub (May 9, 2025). Original GitHub issue: https://github.com/lldap/lldap/issues/1168 **Motivation** I run LLDAP with multiple Samba instances in a home network. Need a way to keep passwords in sync between both systems without manual management. **Describe the solution you'd like** When passwords are set in LLDAP, automatically calculate and store NTLM hashes (sambaNTPassword attribute). This would allow me to periodically sync these hashes to my Samba servers for users in the samba group. **Describe alternatives you've considered** Currently maintaining separate password databases or manually running smbpasswd after password changes, which is error-prone and frustrating for users. **Additional context** This would be a minimal change that doesn't require full Samba schema support but still enables basic integration for home setups.
kerem 2026-02-27 08:17:11 +03:00
Author
Owner

@nitnelave commented on GitHub (May 9, 2025):

Sadly this is both technically impossible and not something I want to do for this project. The passwords are set and stored from the web frontend using a zero knowledge proof, meaning that the server never receives the clear text or even hashed password. And this is not something that I want to change.

However, I do believe that it's possible to use Samba with sssd, where it would ask LLDAP to validate a password (using LLDAP as the single source of truth for the password)

<!-- gh-comment-id:2865921041 --> @nitnelave commented on GitHub (May 9, 2025): Sadly this is both technically impossible and not something I want to do for this project. The passwords are set and stored from the web frontend using a zero knowledge proof, meaning that the server never receives the clear text or even hashed password. And this is not something that I want to change. However, I do believe that it's possible to use Samba with sssd, where it would ask LLDAP to validate a password (using LLDAP as the single source of truth for the password)
Author
Owner

@mitchins commented on GitHub (May 9, 2025):

Thanks for the good write up.

I’ve been exploring just any way to make the two work and will investigate
what you suggested via SSSD. lldap on the whole is much simpler then
openLDAP and does everything else I need besides samba.

I managed to get Linux bound and samba to query that but macOS and windows
fail authentication without a SambaDB entry.

On Fri, 9 May 2025 at 19:53, nitnelave @.***> wrote:

nitnelave left a comment (lldap/lldap#1168)
https://github.com/lldap/lldap/issues/1168#issuecomment-2865921041

Sadly this is both technically impossible and not something I want to do
for this project. The passwords are set and stored from the web frontend
using a zero knowledge proof, meaning that the server never receives the
clear text or even hashed password. And this is not something that I want
to change.

However, I do believe that it's possible to use Samba with sssd, where it
would ask LLDAP to validate a password (using LLDAP as the single source of
truth for the password)


Reply to this email directly, view it on GitHub
https://github.com/lldap/lldap/issues/1168#issuecomment-2865921041, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAHYB4X2YIGHZXQJH3KQPCL25R3J7AVCNFSM6AAAAAB4X6EFLOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQNRVHEZDCMBUGE
.
You are receiving this because you authored the thread.Message ID:
@.***>

<!-- gh-comment-id:2866326934 --> @mitchins commented on GitHub (May 9, 2025): Thanks for the good write up. I’ve been exploring just any way to make the two work and will investigate what you suggested via SSSD. lldap on the whole is much simpler then openLDAP and does everything else I need besides samba. I managed to get Linux bound and samba to query that but macOS and windows fail authentication without a SambaDB entry. On Fri, 9 May 2025 at 19:53, nitnelave ***@***.***> wrote: > *nitnelave* left a comment (lldap/lldap#1168) > <https://github.com/lldap/lldap/issues/1168#issuecomment-2865921041> > > Sadly this is both technically impossible and not something I want to do > for this project. The passwords are set and stored from the web frontend > using a zero knowledge proof, meaning that the server never receives the > clear text or even hashed password. And this is not something that I want > to change. > > However, I do believe that it's possible to use Samba with sssd, where it > would ask LLDAP to validate a password (using LLDAP as the single source of > truth for the password) > > — > Reply to this email directly, view it on GitHub > <https://github.com/lldap/lldap/issues/1168#issuecomment-2865921041>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAHYB4X2YIGHZXQJH3KQPCL25R3J7AVCNFSM6AAAAAB4X6EFLOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQNRVHEZDCMBUGE> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >
Author
Owner

@languagegame commented on GitHub (May 18, 2025):

I also would like to use Samba file shares with LLDAP.

I found a related Github repository called AzureAD-LDAP-wrapper that might have some logic that could work for LLDAP for samba authentication. AzureAD-LDAP-wrapper addresses a different use case for authenticating a samba file server to Entra ID, but some of that logic could apply here as well.

Here is how AzureAD-LDAP-wrapper solved this:

  1. Add the Samba schema to the LDAP database for an NT4-style domain.
  2. Before a user can access a Samba file share, make the user bind / authenticate to the LDAP database. If the bind is succesful, the LDAP server generates a hash of the password and populates it in "sambaNTPassword". It also updates the "sambaPwdLastSet" attribute with the current date time. For LLDAP, this could be accomplished by forcing the user to login to LLDAP web frontend and the client would send the password hash to the server. This can be secured by only allowing this over HTTPS with secure SSL/TLS encryption.
  3. Now that these attributes are populated, a user can authenticate to a Samba file server configured for NT4 style authentication. This is a very old protocol, but it still seems to work with Windows 11 and MacOS Sequoia. It also avoids having to setup a full active directory, as it doesn't require things like a DNS server and Kerberos. It also doesn't require the user to join his or her computer to the Domain.
  4. Only the admin and user can pull the values of the "sambaNTPassword" and "sambaPwdLastSet" attributes from the LDAP server. All other users only see an empty value.

While the NT4 hash methodology for "sambaNTPassword" is no longer cryptographically safe, LLDAP could force the Samba server to use LDAPS, which runs over SSL/TLS encryption. This would allow the user to share the NT4 password hash to the Samba server over a secure link.

Here is an example Samba file server configuration that uses the ldapsam password backend.

workgroup = EXAMPLE
passdb backend = ldapsam:ldaps://example.com:636
ldap admin dn = uid=admin,ou=people,dc=example,dc=com
ldap suffix = dc=example,dc=com
ldap ssl = off
server role = classic backup domain controller
ldap passwd sync = yes
ldap delete dn = no
security = user
idmap config * : backend = tdb
idmap config * : range = 1000000-1999999
admin users = @admin,@administrators
<!-- gh-comment-id:2888753827 --> @languagegame commented on GitHub (May 18, 2025): I also would like to use Samba file shares with LLDAP. I found a related Github repository called [AzureAD-LDAP-wrapper ](https://github.com/ahaenggli/AzureAD-LDAP-wrapper/) that might have some logic that could work for LLDAP for samba authentication. AzureAD-LDAP-wrapper addresses a different use case for authenticating a samba file server to Entra ID, but some of that logic could apply here as well. Here is how AzureAD-LDAP-wrapper solved this: 1. Add the Samba schema to the LDAP database for an NT4-style domain. 2. Before a user can access a Samba file share, make the user bind / authenticate to the LDAP database. If the bind is succesful, the LDAP server generates a hash of the password and populates it in "sambaNTPassword". It also updates the "sambaPwdLastSet" attribute with the current date time. For LLDAP, this could be accomplished by forcing the user to login to LLDAP web frontend and the client would send the password hash to the server. This can be secured by only allowing this over HTTPS with secure SSL/TLS encryption. 3. Now that these attributes are populated, a user can authenticate to a Samba file server configured for NT4 style authentication. This is a very old protocol, but it still seems to work with Windows 11 and MacOS Sequoia. It also avoids having to setup a full active directory, as it doesn't require things like a DNS server and Kerberos. It also doesn't require the user to join his or her computer to the Domain. 4. Only the admin and user can pull the values of the "sambaNTPassword" and "sambaPwdLastSet" attributes from the LDAP server. All other users only see an empty value. While the NT4 hash methodology for "sambaNTPassword" is no longer cryptographically safe, LLDAP could force the Samba server to use LDAPS, which runs over SSL/TLS encryption. This would allow the user to share the NT4 password hash to the Samba server over a secure link. Here is an example Samba file server configuration that uses the ldapsam password backend. ``` workgroup = EXAMPLE passdb backend = ldapsam:ldaps://example.com:636 ldap admin dn = uid=admin,ou=people,dc=example,dc=com ldap suffix = dc=example,dc=com ldap ssl = off server role = classic backup domain controller ldap passwd sync = yes ldap delete dn = no security = user idmap config * : backend = tdb idmap config * : range = 1000000-1999999 admin users = @admin,@administrators ```
Author
Owner

@nitnelave commented on GitHub (May 18, 2025):

I do not want, and often cannot, store password hashes.
When a user connects to the web frontend, the server doesn't receive the password but only a zero knowledge proof that they have the correct password.

<!-- gh-comment-id:2888787517 --> @nitnelave commented on GitHub (May 18, 2025): I do not want, and often cannot, store password hashes. When a user connects to the web frontend, the server doesn't receive the password but only a zero knowledge proof that they have the correct password.
Author
Owner

@markus-seidl commented on GitHub (May 28, 2025):

@mitchins

I would be interested in your process, as I'm currently searching for a new auth stack.

<!-- gh-comment-id:2914947013 --> @markus-seidl commented on GitHub (May 28, 2025): @mitchins I would be interested in your process, as I'm currently searching for a new auth stack.
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#417
No description provided.