Authelia+LLDAP how to get password hash via lldap?

[kuolemaaa]

Hi, please excuse my inexperience with ldap and similar stuff.
I am using lldap with Authelia for first factor authentication (that is user plus password).
The only thing I manage to understand is that the password hash is stored in the sqlite file of lldap.

But from what I understand, in case of login, authelia verifies the given username and password with those provided by lldap using ldap protocol, is that correct?

How to get the password hash using ldap protocol and tools like ldapsearch?
Using ldapsearch -H "ldap://<ip>:<port>" -D "cn=admin,ou=people,dc=example,dc=local" -w <admin_password> -b uid=admin,ou=people,dc=example,dc=local I get the following information, without any kind of hash:

# extended LDIF
#
# LDAPv3
# base <uid=admin,ou=people,dc=example,dc=local> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# admin, people, example.local
dn: uid=admin,ou=people,dc=example,dc=local
objectclass: inetOrgPerson
objectclass: posixAccount
objectclass: mailAccount
objectclass: person
uid: admin
cn: Administrator
createtimestamp: 2024-02-04T21:38:44.413079573+00:00
entryuuid: a64c7627-b113-30ca-b461-8c6bc3b57623

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

I would also like to know what kind of hashing, encryption, and general process a given password undergoes in case of default parameter both in authelia and lldap with "custom" as implementation backend in authelia.

Thanks

[nitnelave]

Hi!

You're partly correct: Authelia indeed checks the user's password using the LDAP protocol to talk to LLDAP. However, it doesn't get the password hash. Instead, it sends the credentials to LLDAP (an LDAP Bind operation), basically it tries to log in as the user, and checks that it's successful. The verification is done inside of LLDAP.

A derivation of the password is indeed stored in the DB, but it's not a hash. It's the information needed for a zero-knowledge proof that the user has the same password as when they last changed it. See https://github.com/lldap/lldap/blob/main/docs%2Farchitecture.md for more details.

This is not configurable. Note that from the web interface, the password is never actually sent to the server. That increases the security in case someone listens to your web traffic.

The password "hash" is not exposed through any interface. It wouldn't make sense without the private server key, and the specific OPAQUE implementation (not the latest implementation there is, sadly).

[kuolemaaa]

Sorry for being dense. I'm having a bit of hard time understanding the first paragraph.
I placed wireshark on authelia's container interface and from what I can see Authelia logs in via LDAP into LLDAP as admin using its password, asks for user-to-be-authenticated's details such as email, displayname and then
sends user-to-be-authenticated username (that is the distinguished name in LDAP lingo if i understand it correctly) and its password via LDAP to LLDAP. I think that last one is the attempt to do the "LDAP Bind opearation" you mentioned.

At this point I guess that LLDAP will do its "OPAQUE magical comparison" having received clear password and having that password_blob stored in the database then it will respond to Authelia valid or invalid credential pair. And I am not sure of this last sentence since I see only a bunch of bytes.

I opened this discussion because I wanted to code my own registration page for my, let's say, ecosystem backed by authelia and ldap with custom logic and invite system. But now I think I have to study how this OPAQUE thing works and maybe study LLDAP code

[nitnelave]

You shouldn't need to have a look at OPAQUE. Just consider that LLDAP is the source of truth that can tell you whether a user/password pair is valid or not.

Your analysis of the login flow by Authelia is correct. The minimal version of that flow is just the last part, logging in as the user.

If you're building a service, I recommend that you implement LDAP as a source of truth for logins, and if you want to play nicely with authelia you can add support for trusted headers (you'll get SSO).

[kuolemaaa]

Ok but what about the registration of a new user + password if I want to code this kind of page myself with my custom logics ?
It seems that the only way to submit a password to lldap is through the lldap_set_password binary, the lldap-cli that uses lldap_set_password under the hood and the single page app of lldap server.
The only thing that is trivial is the POST requests to http://lldap-server/auth/opaque/register/start and finish but I dont know anything about the data exchanged there.

[nitnelave]

You can create a new user through LDAP, and set the password there. Or you can send a password modification request through LDAP for an existing user (password modify extended request I think?)

The advantage is that it'll be immediately compatible with FreeIPA, openLdap and others

[kuolemaaa]

Are you talking about this RFC 3062: LDAP Password Modify Extended Operation ? Or is there some other thing?

[nitnelave]

That's the one!