Hi, have you created an issue on the github repo for this issue? I'm having the exact some problem but I don't want to create duplicate issues. 😅

Here's a brand new thread for you! Please keep the discussion for this problem in this thread.

Do you mean the admin not being able to change another user's password? Try logging out and back in, KevS' problem was that permissions were not propagated

No, this issue concerns password writeback/self-reset through authentik.

That seems like a different problem: you're getting an "unwilling to perform" error

Yes, where can I find them?

I'm not familiar with unraid. In LLDAP, you can enable verbose logs by either changing the config (setting

verbose: true

) or through environment variables

LLDAP_VERBOSE=true

. Then the logs go to the standard output

Okay, one moment!

small note: you can switch to lldap/lldap:latest (same image, but more "official")

gotcha

I don't think these are the correct logs: did you get the "unwilling to perform" error after enabling verbose logs? I see 2 successful user listings, and that's it

Here's a fresh one https://pastebin.com/WzDbAeNx

I'm not sure authentik supports the right LDAP methods: it expects the password to be stored in a field in the LDAP server, it seems?

I am honestly not sure, LDAP is very new to me

Hmm, looking at their code, they do use an extended password modify request, but I don't see it in the LLDAP logs. However, the python error doesn't seem related to LDAP at all

the last log I sent is all I have unfortunately

It's a bit hard for me to debug, since I don't see the logs of the error: the logs you sent me don't contain any error on the LLDAP side

Yeah, that's undersatndable

My pleasure 🙂

Hello, I am back, this time with a better log file!

Hmm, that's what I was afraid of. Authentik uses a normal modify operation instead of an extended password modify operation

Welp, time for me to shoot in a feature request then 😅

Sure! Also, note that the logs you sent me contain the new password in clear

They are allowed to know that the new password is

bbb

Huh, then maybe I'm not reading their code right

Would you like to have the stack trace that goes with above log?

Oh, I see the issue: they first try to modify the password the AD way, which uses a modify operation with the unicodePwd field, and then if they get an AttributeError they try the extended operation. However, lldap doesn't return an AttributeError but an UnwillingToPerformError since we don't support the modify operation at all, so it completely fails

Gotcha, thank you 🙏