Hi Christopher,
Is there anything else that you might suggest or observe? Are there any flags in the 1.11 branch (similar to "server.dedup.in_process_enabled") that might (need to) be set?
No
Is there any more information that I might be able to supply to assist?
What we do not understand and cannot explain is this "passdb_backend=unknown". It is like for some request instances there is a null pointer for the server … and typing this and seeing the logs, I note:
Could you please forward the null pointer exceptions. This is very important.
Dec 16 13:34:43 hostpack-nauthilus-01 nauthilus[71980]: time=2025-12-16T13:34:43.796Z level=DEBUG msg="LDAP free/busy state #1 is free" instance=nauthilus pool=auth debug_module=ldappool function=github.com/croessner/nauthilus/server/backend/ldappool.(*ldapPoolImpl).u> Dec 16 13:34:43 hostpack-nauthilus-01 nauthilus[71980]: time=2025-12-16T13:34:43.796Z level=DEBUG msg="LDAP free/busy state #2 is free" instance=nauthilus pool=auth debug_module=ldappool function=github.com/croessner/nauthilus/server/backend/ldappool.(*ldapPoolImpl).u> Dec 16 13:34:43 hostpack-nauthilus-01 nauthilus[71980]: time=2025-12-16T13:34:43.796Z level=DEBUG msg="LDAP free/busy state #3 is busy or closed" instance=nauthilus pool=auth debug_module=ldappool function=github.com/croessner/nauthilus/server/backend/ldappool.(*ldapP> Dec 16 13:34:43 hostpack-nauthilus-01 nauthilus[71980]: time=2025-12-16T13:34:43.796Z level=DEBUG msg="LDAP free/busy state #4 is busy or closed" instance=nauthilus pool=auth debug_module=ldappool function=github.com/croessner/nauthilus/server/backend/ldappool.(*ldapP> Dec 16 13:34:43 hostpack-nauthilus-01 nauthilus[71980]: time=2025-12-16T13:34:43.796Z level=DEBUG msg="LDAP free/busy state #5 is busy or closed" instance=nauthilus pool=auth debug_module=ldappool function=github.com/croessner/nauthilus/server/backend/ldappool.(*ldapP> Dec 16 13:34:43 hostpack-nauthilus-01 nauthilus[71980]: time=2025-12-16T13:34:43.796Z level=DEBUG msg="LDAP free/busy state #6 is busy or closed" instance=nauthilus pool=auth debug_module=ldappool function=github.com/croessner/nauthilus/server/backend/ldappool.(*ldapP> Dec 16 13:34:43 hostpack-nauthilus-01 nauthilus[71980]: time=2025-12-16T13:34:43.796Z level=DEBUG msg="LDAP free/busy state #7 is busy or closed" instance=nauthilus pool=auth debug_module=ldappool function=github.com/croessner/nauthilus/server/backend/ldappool.(*ldapP> Dec 16 13:34:43 hostpack-nauthilus-01 nauthilus[71980]: time=2025-12-16T13:34:43.796Z level=DEBUG msg="LDAP free/busy state #8 is busy or closed" instance=nauthilus pool=auth debug_module=ldappool function=github.com/croessner/nauthilus/server/backend/ldappool.(*ldapP> Dec 16 13:34:43 hostpack-nauthilus-01 nauthilus[71980]: time=2025-12-16T13:34:43.796Z level=DEBUG msg="State open connections" instance=nauthilus pool=auth needClosing=0 openConnections=2 idlePoolSize=2 debug_module=ldappool function=github.com/croessner/nauthilus/ser>
Could these "busy or closed" LDAP instances #3-#8 be causing the "unknown" backend?
I don’t think so, but of course I will investigate this.
What I see from the logs is that LDAP is telling you that it did not find the user: UserFound:false
Do you see LDAP-filter logs? If so, can you manually check if that filter works?
Kind regards
Christian
Rößner-Network-Solutions Zertifizierter ITSiBe / CISO Marburger Str. 70a, 36304 Alsfeld Mobil: +49 171 9905345 USt-IdNr.: DE225643613, https://roessner.website PGP fingerprint: 658D 1342 B762 F484 2DDF 1E88 38A5 4346 D727 94E5
Hi,
I found an issue with the LDAP pool management and have fixed it.
As a small workaround:
Could you set the *_pool_size and *_idle_pool_size parameters to higher values? Set the idde-params to the same values as the non-idle ones.
If it gets better, my fix might be correct. Still waiting for the crash dump. I would like to see, if it addresses to „closing idle connection“.
I am testing the code changes today and if no further errors occur will release a hot fix tomorrow. The code is already committed in main, if you want to give it a try.
Kind regards
Christian
Could these "busy or closed" LDAP instances #3-#8 be causing the "unknown" backend?
I don’t think so, but of course I will investigate this.
What I see from the logs is that LDAP is telling you that it did not find the user: UserFound:false
Do you see LDAP-filter logs? If so, can you manually check if that filter works?
Kind regards
Christian
Rößner-Network-Solutions Zertifizierter ITSiBe / CISO Marburger Str. 70a, 36304 Alsfeld Mobil: +49 171 9905345 USt-IdNr.: DE225643613, https://roessner.website PGP fingerprint: 658D 1342 B762 F484 2DDF 1E88 38A5 4346 D727 94E5 _______________________________________________ Nauthilus-users mailing list -- nauthilus-users@lists.nauthilus.org To unsubscribe send an email to nauthilus-users-leave@lists.nauthilus.org
Rößner-Network-Solutions Zertifizierter ITSiBe / CISO Marburger Str. 70a, 36304 Alsfeld Mobil: +49 171 9905345 USt-IdNr.: DE225643613, https://roessner.website PGP fingerprint: 658D 1342 B762 F484 2DDF 1E88 38A5 4346 D727 94E5
Hello Christian,
So, based on this feedback I have tried configuring the following:
ldap: config: server_uri: … number_of_workers: 8 lookup_pool_size: 4 lookup_idle_pool_size: 4 auth_pool_size: 4 auth_idle_pool_size: 4
This seems to, indeed, help, but not for long. After restarting Nauthilus and watching the logs with a low volume of traffic, for the first few minutes everything seems to be working as expected. Then, at some point, I start to get LDAP lookup failures and then these continue. At this point I stop new traffic to the server and suspend the test. I have done this a few times.
I do not directly have the resources to build a new release myself (mainly the time to setup a build server and figure out what I need). I hope my last mail is still of some value. I will try to take a look at the last commits and review the diff.
Thanks for all your assistance and what I do hope will become a very useful tool for us in the area of Authentication and Authorization, the possibilities are exciting.
Regards,
Chris
From: Christian Rößner via Nauthilus-users nauthilus-users@lists.nauthilus.org Sent: Wednesday, December 17, 2025 12:01 To: Christopher Moules Christopher.Moules@post.lu Cc: Main list for Nauthilus users nauthilus-users@lists.nauthilus.org Subject: [Nauthilus-users] Re: Why do I get "passdb_backend=unknown" for a subset of requests
ATTENTION: Ce mail provient de l'extérieur de Post. Ne cliquez pas sur les liens ou n'ouvrez pas les pièces jointes à moins de connaitre l'expéditeur et d'être sûr que le contenu est inoffensif. En cas de doute sur son origine ou si vous pensez qu'il est suspect, nous vous prions de rapporter cet évènement par email à cybersos@post.lu.
Hi,
I found an issue with the LDAP pool management and have fixed it.
As a small workaround:
Could you set the *_pool_size and *_idle_pool_size parameters to higher values? Set the idde-params to the same values as the non-idle ones.
If it gets better, my fix might be correct. Still waiting for the crash dump. I would like to see, if it addresses to „closing idle connection“.
I am testing the code changes today and if no further errors occur will release a hot fix tomorrow. The code is already committed in main, if you want to give it a try.
Kind regards
Christian
Could these "busy or closed" LDAP instances #3-#8 be causing the "unknown" backend?
I don’t think so, but of course I will investigate this.
What I see from the logs is that LDAP is telling you that it did not find the user: UserFound:false
Do you see LDAP-filter logs? If so, can you manually check if that filter works?
Kind regards
Christian
Rößner-Network-Solutions Zertifizierter ITSiBe / CISO Marburger Str. 70a, 36304 Alsfeld Mobil: +49 171 9905345 USt-IdNr.: DE225643613, https://roessner.websitehttps://roessner.website/ PGP fingerprint: 658D 1342 B762 F484 2DDF 1E88 38A5 4346 D727 94E5
Nauthilus-users mailing list -- nauthilus-users@lists.nauthilus.orgmailto:nauthilus-users@lists.nauthilus.org To unsubscribe send an email to nauthilus-users-leave@lists.nauthilus.orgmailto:nauthilus-users-leave@lists.nauthilus.org
Rößner-Network-Solutions Zertifizierter ITSiBe / CISO Marburger Str. 70a, 36304 Alsfeld Mobil: +49 171 9905345 USt-IdNr.: DE225643613, https://roessner.websitehttps://roessner.website/ PGP fingerprint: 658D 1342 B762 F484 2DDF 1E88 38A5 4346 D727 94E5
Hello Again,
I have just observed something that might be of value.
The service is working fine, until we hit the case "Login Fail - User not exist" - (at this point the LDAP filter is logged). After this happens, I start to get many login failures where there is no "filter=" logged and existing users have 'UserFound:false' logged. Multiple Nauthilus restarts with Redis flushes have shown this same behaviour and it is with different non-existing users.
In all cases I am seeing 'msg="Connection #1 is free, using it"'. It could be that the user lookup failure is somehow blocking the LDAP connection, causing future lookups to fail.
I am not pushing enough traffic at the server to see if 'Connection #2' or more do not have this issue. As soon as I see the problems, I am cutting the traffic to the server.
I had had a very quick look at the commit messages you made and saw that things were mainly related to LDAP pool exhaustion. Given the above, this does not look to be that case. I had just reconfigured my 'nauthilus.yml', in the light of this, to have the following:
ldap: config: server_uri: ... number_of_workers: 16 lookup_pool_size: 8 lookup_idle_pool_size: 8 auth_pool_size: 8 auth_idle_pool_size: 8
When we started, I had not modified any of these settings from 'default'. I had reduced the numbers in the hope that this may help with the issue.
Regards,
Chris
From: Christopher Moules via Nauthilus-users nauthilus-users@lists.nauthilus.org Sent: 17 December 2025 15:07 To: Christopher Moules Christopher.Moules@post.lu Cc: Main list for Nauthilus users nauthilus-users@lists.nauthilus.org Subject: [Nauthilus-users] Re: Why do I get "passdb_backend=unknown" for a subset of requests
ATTENTION: Ce mail provient de l'extérieur de Post. Ne cliquez pas sur les liens ou n'ouvrez pas les pièces jointes à moins de connaitre l'expéditeur et d'être sûr que le contenu est inoffensif. En cas de doute sur son origine ou si vous pensez qu'il est suspect, nous vous prions de rapporter cet évènement par email à cybersos@post.lumailto:cybersos@post.lu.
Hello Christian,
So, based on this feedback I have tried configuring the following:
ldap: config: server_uri: ... number_of_workers: 8 lookup_pool_size: 4 lookup_idle_pool_size: 4 auth_pool_size: 4 auth_idle_pool_size: 4
This seems to, indeed, help, but not for long. After restarting Nauthilus and watching the logs with a low volume of traffic, for the first few minutes everything seems to be working as expected. Then, at some point, I start to get LDAP lookup failures and then these continue. At this point I stop new traffic to the server and suspend the test. I have done this a few times.
I do not directly have the resources to build a new release myself (mainly the time to setup a build server and figure out what I need). I hope my last mail is still of some value. I will try to take a look at the last commits and review the diff.
Thanks for all your assistance and what I do hope will become a very useful tool for us in the area of Authentication and Authorization, the possibilities are exciting.
Regards,
Chris
From: Christian Rößner via Nauthilus-users <nauthilus-users@lists.nauthilus.orgmailto:nauthilus-users@lists.nauthilus.org> Sent: Wednesday, December 17, 2025 12:01 To: Christopher Moules <Christopher.Moules@post.lumailto:Christopher.Moules@post.lu> Cc: Main list for Nauthilus users <nauthilus-users@lists.nauthilus.orgmailto:nauthilus-users@lists.nauthilus.org> Subject: [Nauthilus-users] Re: Why do I get "passdb_backend=unknown" for a subset of requests
ATTENTION: Ce mail provient de l'extérieur de Post. Ne cliquez pas sur les liens ou n'ouvrez pas les pièces jointes à moins de connaitre l'expéditeur et d'être sûr que le contenu est inoffensif. En cas de doute sur son origine ou si vous pensez qu'il est suspect, nous vous prions de rapporter cet évènement par email à cybersos@post.lumailto:cybersos@post.lu.
Hi,
I found an issue with the LDAP pool management and have fixed it.
As a small workaround:
Could you set the *_pool_size and *_idle_pool_size parameters to higher values? Set the idde-params to the same values as the non-idle ones.
If it gets better, my fix might be correct. Still waiting for the crash dump. I would like to see, if it addresses to "closing idle connection".
I am testing the code changes today and if no further errors occur will release a hot fix tomorrow. The code is already committed in main, if you want to give it a try.
Kind regards
Christian
Could these "busy or closed" LDAP instances #3-#8 be causing the "unknown" backend?
I don't think so, but of course I will investigate this.
What I see from the logs is that LDAP is telling you that it did not find the user: UserFound:false
Do you see LDAP-filter logs? If so, can you manually check if that filter works?
Kind regards
Christian
Rößner-Network-Solutions Zertifizierter ITSiBe / CISO Marburger Str. 70a, 36304 Alsfeld Mobil: +49 171 9905345 USt-IdNr.: DE225643613, https://roessner.websitehttps://roessner.website/ PGP fingerprint: 658D 1342 B762 F484 2DDF 1E88 38A5 4346 D727 94E5
Nauthilus-users mailing list -- nauthilus-users@lists.nauthilus.orgmailto:nauthilus-users@lists.nauthilus.org To unsubscribe send an email to nauthilus-users-leave@lists.nauthilus.orgmailto:nauthilus-users-leave@lists.nauthilus.org
Rößner-Network-Solutions Zertifizierter ITSiBe / CISO Marburger Str. 70a, 36304 Alsfeld Mobil: +49 171 9905345 USt-IdNr.: DE225643613, https://roessner.websitehttps://roessner.website/ PGP fingerprint: 658D 1342 B762 F484 2DDF 1E88 38A5 4346 D727 94E5
Hi,
thank you very much for your feedback. I think I might have found the issue now. Your response shows a major problem with a cache in front of LDAP filters. Unfortunately the macros have not been expanded before the given filter was used as a cache key. A user request with a failed login could cause cache poisoning.
I try to fix this asap.
Kind regards
Christian
On 17 Dec 2025, at 15:37, Christopher Moules wrote:
Hello Again,
I have just observed something that might be of value.
The service is working fine, until we hit the case "Login Fail - User not exist" - (at this point the LDAP filter is logged). After this happens, I start to get many login failures where there is no "filter=" logged and existing users have 'UserFound:false' logged. Multiple Nauthilus restarts with Redis flushes have shown this same behaviour and it is with different non-existing users.
In all cases I am seeing 'msg="Connection #1 is free, using it"'. It could be that the user lookup failure is somehow blocking the LDAP connection, causing future lookups to fail.
I am not pushing enough traffic at the server to see if 'Connection #2' or more do not have this issue. As soon as I see the problems, I am cutting the traffic to the server.
I had had a very quick look at the commit messages you made and saw that things were mainly related to LDAP pool exhaustion. Given the above, this does not look to be that case. I had just reconfigured my 'nauthilus.yml', in the light of this, to have the following:
ldap: config: server_uri: ... number_of_workers: 16 lookup_pool_size: 8 lookup_idle_pool_size: 8 auth_pool_size: 8 auth_idle_pool_size: 8
When we started, I had not modified any of these settings from 'default'. I had reduced the numbers in the hope that this may help with the issue.
Regards,
Chris
From: Christopher Moules via Nauthilus-users nauthilus-users@lists.nauthilus.org Sent: 17 December 2025 15:07 To: Christopher Moules Christopher.Moules@post.lu Cc: Main list for Nauthilus users nauthilus-users@lists.nauthilus.org Subject: [Nauthilus-users] Re: Why do I get "passdb_backend=unknown" for a subset of requests
ATTENTION: Ce mail provient de l'extérieur de Post. Ne cliquez pas sur les liens ou n'ouvrez pas les pièces jointes à moins de connaitre l'expéditeur et d'être sûr que le contenu est inoffensif. En cas de doute sur son origine ou si vous pensez qu'il est suspect, nous vous prions de rapporter cet évènement par email à cybersos@post.lumailto:cybersos@post.lu .
Hello Christian,
So, based on this feedback I have tried configuring the following:
ldap: config: server_uri: ... number_of_workers: 8 lookup_pool_size: 4 lookup_idle_pool_size: 4 auth_pool_size: 4 auth_idle_pool_size: 4
This seems to, indeed, help, but not for long. After restarting Nauthilus and watching the logs with a low volume of traffic, for the first few minutes everything seems to be working as expected. Then, at some point, I start to get LDAP lookup failures and then these continue. At this point I stop new traffic to the server and suspend the test. I have done this a few times.
I do not directly have the resources to build a new release myself (mainly the time to setup a build server and figure out what I need). I hope my last mail is still of some value. I will try to take a look at the last commits and review the diff.
Thanks for all your assistance and what I do hope will become a very useful tool for us in the area of Authentication and Authorization, the possibilities are exciting.
Regards,
Chris
From: Christian Rößner via Nauthilus-users <nauthilus-users@lists.nauthilus.orgmailto:nauthilus-users@lists.nauthilus.org> Sent: Wednesday, December 17, 2025 12:01 To: Christopher Moules <Christopher.Moules@post.lumailto:Christopher.Moules@post.lu> Cc: Main list for Nauthilus users <nauthilus-users@lists.nauthilus.orgmailto:nauthilus-users@lists.nauthilus.org> Subject: [Nauthilus-users] Re: Why do I get "passdb_backend=unknown" for a subset of requests
ATTENTION: Ce mail provient de l'extérieur de Post. Ne cliquez pas sur les liens ou n'ouvrez pas les pièces jointes à moins de connaitre l'expéditeur et d'être sûr que le contenu est inoffensif. En cas de doute sur son origine ou si vous pensez qu'il est suspect, nous vous prions de rapporter cet évènement par email à cybersos@post.lumailto:cybersos@post.lu .
Hi,
I found an issue with the LDAP pool management and have fixed it.
As a small workaround:
Could you set the *_pool_size and *_idle_pool_size parameters to higher values? Set the idde-params to the same values as the non-idle ones.
If it gets better, my fix might be correct. Still waiting for the crash dump. I would like to see, if it addresses to "closing idle connection".
I am testing the code changes today and if no further errors occur will release a hot fix tomorrow. The code is already committed in main, if you want to give it a try.
Kind regards
Christian
Could these "busy or closed" LDAP instances #3-#8 be causing the "unknown" backend?
I don't think so, but of course I will investigate this.
What I see from the logs is that LDAP is telling you that it did not find the user: UserFound:false
Do you see LDAP-filter logs? If so, can you manually check if that filter works?
Kind regards
Christian
Rößner-Network-Solutions Zertifizierter ITSiBe / CISO Marburger Str. 70a, 36304 Alsfeld Mobil: +49 171 9905345 USt-IdNr.: DE225643613, https://roessner.websitehttps://roessner.website/ PGP fingerprint: 658D 1342 B762 F484 2DDF 1E88 38A5 4346 D727 94E5
Nauthilus-users mailing list -- nauthilus-users@lists.nauthilus.orgmailto:nauthilus-users@lists.nauthilus.org To unsubscribe send an email to nauthilus-users-leave@lists.nauthilus.orgmailto:nauthilus-users-leave@lists.nauthilus.org
Rößner-Network-Solutions Zertifizierter ITSiBe / CISO Marburger Str. 70a, 36304 Alsfeld Mobil: +49 171 9905345 USt-IdNr.: DE225643613, https://roessner.websitehttps://roessner.website/ PGP fingerprint: 658D 1342 B762 F484 2DDF 1E88 38A5 4346 D727 94E5
Rößner-Network-Solutions Zertifizierter ITSiBe / CISO Marburger Str. 70a, 36304 Alsfeld Mobil: +49 171 9905345 USt-IdNr.: DE225643613, https://roessner.website PGP fingerprint: 658D 1342 B762 F484 2DDF 1E88 38A5 4346 D727 94E5
Hello Christian,
That is good news! (at least the finding/identification of a bug). It has taken me a little while to understand the details of what was being logged and to see the differences in the requests, but apparently time well spent.
I was just about to report that I just installed the 1.11.5 release and that this made no difference to our use case.
I had started looking through the source code and found references to "Singleflight" in processLookupSearchRequest(). As some of the recent commit entries were all to do with removing Singleflight, I was trying to understand this code and figure out if this was the 'problem'. Given your response, I will take another look and see if I understand the issue.
Thanks again for your hard work on this.
Regards,
Chris
From: Christian Rößner christian@roessner.email Sent: 17 December 2025 16:58 To: Christopher Moules Christopher.Moules@post.lu Cc: Main list for Nauthilus users nauthilus-users@lists.nauthilus.org Subject: Re: [Nauthilus-users] Why do I get "passdb_backend=unknown" for a subset of requests
ATTENTION: Ce mail provient de l'extérieur de Post. Ne cliquez pas sur les liens ou n'ouvrez pas les pièces jointes à moins de connaitre l'expéditeur et d'être sûr que le contenu est inoffensif. En cas de doute sur son origine ou si vous pensez qu'il est suspect, nous vous prions de rapporter cet évènement par email à cybersos@post.lumailto:cybersos@post.lu.
Hi,
thank you very much for your feedback. I think I might have found the issue now. Your response shows a major problem with a cache in front of LDAP filters. Unfortunately the macros have not been expanded before the given filter was used as a cache key. A user request with a failed login could cause cache poisoning.
I try to fix this asap.
Kind regards
Christian
On 17 Dec 2025, at 15:37, Christopher Moules wrote: Hello Again,
I have just observed something that might be of value.
The service is working fine, until we hit the case "Login Fail - User not exist" - (at this point the LDAP filter is logged). After this happens, I start to get many login failures where there is no "filter=" logged and existing users have 'UserFound:false' logged. Multiple Nauthilus restarts with Redis flushes have shown this same behaviour and it is with different non-existing users.
In all cases I am seeing 'msg="Connection #1 is free, using it"'. It could be that the user lookup failure is somehow blocking the LDAP connection, causing future lookups to fail.
I am not pushing enough traffic at the server to see if 'Connection #2' or more do not have this issue. As soon as I see the problems, I am cutting the traffic to the server.
I had had a very quick look at the commit messages you made and saw that things were mainly related to LDAP pool exhaustion. Given the above, this does not look to be that case. I had just reconfigured my 'nauthilus.yml', in the light of this, to have the following:
ldap: config: server_uri: ... number_of_workers: 16 lookup_pool_size: 8 lookup_idle_pool_size: 8 auth_pool_size: 8 auth_idle_pool_size: 8
When we started, I had not modified any of these settings from 'default'. I had reduced the numbers in the hope that this may help with the issue.
Regards,
Chris
From: Christopher Moules via Nauthilus-users <nauthilus-users@lists.nauthilus.orgmailto:nauthilus-users@lists.nauthilus.org> Sent: 17 December 2025 15:07 To: Christopher Moules <Christopher.Moules@post.lumailto:Christopher.Moules@post.lu> Cc: Main list for Nauthilus users <nauthilus-users@lists.nauthilus.orgmailto:nauthilus-users@lists.nauthilus.org> Subject: [Nauthilus-users] Re: Why do I get "passdb_backend=unknown" for a subset of requests
ATTENTION: Ce mail provient de l'extérieur de Post. Ne cliquez pas sur les liens ou n'ouvrez pas les pièces jointes à moins de connaitre l'expéditeur et d'être sûr que le contenu est inoffensif. En cas de doute sur son origine ou si vous pensez qu'il est suspect, nous vous prions de rapporter cet évènement par email à cybersos@post.lumailto:cybersos@post.lu.
Hello Christian,
So, based on this feedback I have tried configuring the following:
ldap: config: server_uri: ... number_of_workers: 8 lookup_pool_size: 4 lookup_idle_pool_size: 4 auth_pool_size: 4 auth_idle_pool_size: 4
This seems to, indeed, help, but not for long. After restarting Nauthilus and watching the logs with a low volume of traffic, for the first few minutes everything seems to be working as expected. Then, at some point, I start to get LDAP lookup failures and then these continue. At this point I stop new traffic to the server and suspend the test. I have done this a few times.
I do not directly have the resources to build a new release myself (mainly the time to setup a build server and figure out what I need). I hope my last mail is still of some value. I will try to take a look at the last commits and review the diff.
Thanks for all your assistance and what I do hope will become a very useful tool for us in the area of Authentication and Authorization, the possibilities are exciting.
Regards,
Chris
From: Christian Rößner via Nauthilus-users <nauthilus-users@lists.nauthilus.orgmailto:nauthilus-users@lists.nauthilus.org> Sent: Wednesday, December 17, 2025 12:01 To: Christopher Moules <Christopher.Moules@post.lumailto:Christopher.Moules@post.lu> Cc: Main list for Nauthilus users <nauthilus-users@lists.nauthilus.orgmailto:nauthilus-users@lists.nauthilus.org> Subject: [Nauthilus-users] Re: Why do I get "passdb_backend=unknown" for a subset of requests
ATTENTION: Ce mail provient de l'extérieur de Post. Ne cliquez pas sur les liens ou n'ouvrez pas les pièces jointes à moins de connaitre l'expéditeur et d'être sûr que le contenu est inoffensif. En cas de doute sur son origine ou si vous pensez qu'il est suspect, nous vous prions de rapporter cet évènement par email à cybersos@post.lumailto:cybersos@post.lu.
Hi,
I found an issue with the LDAP pool management and have fixed it.
As a small workaround:
Could you set the *_pool_size and *_idle_pool_size parameters to higher values? Set the idde-params to the same values as the non-idle ones.
If it gets better, my fix might be correct. Still waiting for the crash dump. I would like to see, if it addresses to "closing idle connection".
I am testing the code changes today and if no further errors occur will release a hot fix tomorrow. The code is already committed in main, if you want to give it a try.
Kind regards
Christian
Could these "busy or closed" LDAP instances #3-#8 be causing the "unknown" backend?
I don't think so, but of course I will investigate this.
What I see from the logs is that LDAP is telling you that it did not find the user: UserFound:false
Do you see LDAP-filter logs? If so, can you manually check if that filter works?
Kind regards
Christian
Rößner-Network-Solutions Zertifizierter ITSiBe / CISO Marburger Str. 70a, 36304 Alsfeld Mobil: +49 171 9905345 USt-IdNr.: DE225643613, https://roessner.websitehttps://roessner.website/ PGP fingerprint: 658D 1342 B762 F484 2DDF 1E88 38A5 4346 D727 94E5
Nauthilus-users mailing list -- nauthilus-users@lists.nauthilus.orgmailto:nauthilus-users@lists.nauthilus.org To unsubscribe send an email to nauthilus-users-leave@lists.nauthilus.orgmailto:nauthilus-users-leave@lists.nauthilus.org
Rößner-Network-Solutions Zertifizierter ITSiBe / CISO Marburger Str. 70a, 36304 Alsfeld Mobil: +49 171 9905345 USt-IdNr.: DE225643613, https://roessner.websitehttps://roessner.website/ PGP fingerprint: 658D 1342 B762 F484 2DDF 1E88 38A5 4346 D727 94E5
Rößner-Network-Solutions Zertifizierter ITSiBe / CISO Marburger Str. 70a, 36304 Alsfeld Mobil: +49 171 9905345 USt-IdNr.: DE225643613, https://roessner.websitehttps://roessner.website/ PGP fingerprint: 658D 1342 B762 F484 2DDF 1E88 38A5 4346 D727 94E5
Hi,
On 17 Dec 2025, at 17:08, Christopher Moules wrote:
Hello Christian,
That is good news! (at least the finding/identification of a bug). It has taken me a little while to understand the details of what was being logged and to see the differences in the requests, but apparently time well spent.
I was just about to report that I just installed the 1.11.5 release and that this made no difference to our use case.
I had started looking through the source code and found references to "Singleflight" in processLookupSearchRequest(). As some of the recent commit entries were all to do with removing Singleflight, I was trying to understand this code and figure out if this was the 'problem'. Given your response, I will take another look and see if I understand the issue.
Thanks again for your hard work on this.
No! I thank you very much for your help making it better :-)
I just pushed a fix into main. I think that could address the problem.
Kind regards
Christian
Regards,
Chris
From: Christian Rößner christian@roessner.email Sent: 17 December 2025 16:58 To: Christopher Moules Christopher.Moules@post.lu Cc: Main list for Nauthilus users nauthilus-users@lists.nauthilus.org Subject: Re: [Nauthilus-users] Why do I get "passdb_backend=unknown" for a subset of requests
ATTENTION: Ce mail provient de l'extérieur de Post. Ne cliquez pas sur les liens ou n'ouvrez pas les pièces jointes à moins de connaitre l'expéditeur et d'être sûr que le contenu est inoffensif. En cas de doute sur son origine ou si vous pensez qu'il est suspect, nous vous prions de rapporter cet évènement par email à cybersos@post.lumailto:cybersos@post.lu .
Hi,
thank you very much for your feedback. I think I might have found the issue now. Your response shows a major problem with a cache in front of LDAP filters. Unfortunately the macros have not been expanded before the given filter was used as a cache key. A user request with a failed login could cause cache poisoning.
I try to fix this asap.
Kind regards
Christian
On 17 Dec 2025, at 15:37, Christopher Moules wrote: Hello Again,
I have just observed something that might be of value.
The service is working fine, until we hit the case "Login Fail - User not exist" - (at this point the LDAP filter is logged). After this happens, I start to get many login failures where there is no "filter=" logged and existing users have 'UserFound:false' logged. Multiple Nauthilus restarts with Redis flushes have shown this same behaviour and it is with different non-existing users.
In all cases I am seeing 'msg="Connection #1 is free, using it"'. It could be that the user lookup failure is somehow blocking the LDAP connection, causing future lookups to fail.
I am not pushing enough traffic at the server to see if 'Connection #2' or more do not have this issue. As soon as I see the problems, I am cutting the traffic to the server.
I had had a very quick look at the commit messages you made and saw that things were mainly related to LDAP pool exhaustion. Given the above, this does not look to be that case. I had just reconfigured my 'nauthilus.yml', in the light of this, to have the following:
ldap: config: server_uri: ... number_of_workers: 16 lookup_pool_size: 8 lookup_idle_pool_size: 8 auth_pool_size: 8 auth_idle_pool_size: 8
When we started, I had not modified any of these settings from 'default'. I had reduced the numbers in the hope that this may help with the issue.
Regards,
Chris
From: Christopher Moules via Nauthilus-users <nauthilus-users@lists.nauthilus.orgmailto:nauthilus-users@lists.nauthilus.org> Sent: 17 December 2025 15:07 To: Christopher Moules <Christopher.Moules@post.lumailto:Christopher.Moules@post.lu> Cc: Main list for Nauthilus users <nauthilus-users@lists.nauthilus.orgmailto:nauthilus-users@lists.nauthilus.org> Subject: [Nauthilus-users] Re: Why do I get "passdb_backend=unknown" for a subset of requests
ATTENTION: Ce mail provient de l'extérieur de Post. Ne cliquez pas sur les liens ou n'ouvrez pas les pièces jointes à moins de connaitre l'expéditeur et d'être sûr que le contenu est inoffensif. En cas de doute sur son origine ou si vous pensez qu'il est suspect, nous vous prions de rapporter cet évènement par email à cybersos@post.lumailto:cybersos@post.lu .
Hello Christian,
So, based on this feedback I have tried configuring the following:
ldap: config: server_uri: ... number_of_workers: 8 lookup_pool_size: 4 lookup_idle_pool_size: 4 auth_pool_size: 4 auth_idle_pool_size: 4
This seems to, indeed, help, but not for long. After restarting Nauthilus and watching the logs with a low volume of traffic, for the first few minutes everything seems to be working as expected. Then, at some point, I start to get LDAP lookup failures and then these continue. At this point I stop new traffic to the server and suspend the test. I have done this a few times.
I do not directly have the resources to build a new release myself (mainly the time to setup a build server and figure out what I need). I hope my last mail is still of some value. I will try to take a look at the last commits and review the diff.
Thanks for all your assistance and what I do hope will become a very useful tool for us in the area of Authentication and Authorization, the possibilities are exciting.
Regards,
Chris
From: Christian Rößner via Nauthilus-users <nauthilus-users@lists.nauthilus.orgmailto:nauthilus-users@lists.nauthilus.org> Sent: Wednesday, December 17, 2025 12:01 To: Christopher Moules <Christopher.Moules@post.lumailto:Christopher.Moules@post.lu> Cc: Main list for Nauthilus users <nauthilus-users@lists.nauthilus.orgmailto:nauthilus-users@lists.nauthilus.org> Subject: [Nauthilus-users] Re: Why do I get "passdb_backend=unknown" for a subset of requests
ATTENTION: Ce mail provient de l'extérieur de Post. Ne cliquez pas sur les liens ou n'ouvrez pas les pièces jointes à moins de connaitre l'expéditeur et d'être sûr que le contenu est inoffensif. En cas de doute sur son origine ou si vous pensez qu'il est suspect, nous vous prions de rapporter cet évènement par email à cybersos@post.lumailto:cybersos@post.lu .
Hi,
I found an issue with the LDAP pool management and have fixed it.
As a small workaround:
Could you set the *_pool_size and *_idle_pool_size parameters to higher values? Set the idde-params to the same values as the non-idle ones.
If it gets better, my fix might be correct. Still waiting for the crash dump. I would like to see, if it addresses to "closing idle connection".
I am testing the code changes today and if no further errors occur will release a hot fix tomorrow. The code is already committed in main, if you want to give it a try.
Kind regards
Christian
Could these "busy or closed" LDAP instances #3-#8 be causing the "unknown" backend?
I don't think so, but of course I will investigate this.
What I see from the logs is that LDAP is telling you that it did not find the user: UserFound:false
Do you see LDAP-filter logs? If so, can you manually check if that filter works?
Kind regards
Christian
Rößner-Network-Solutions Zertifizierter ITSiBe / CISO Marburger Str. 70a, 36304 Alsfeld Mobil: +49 171 9905345 USt-IdNr.: DE225643613, https://roessner.websitehttps://roessner.website/ PGP fingerprint: 658D 1342 B762 F484 2DDF 1E88 38A5 4346 D727 94E5
Nauthilus-users mailing list -- nauthilus-users@lists.nauthilus.orgmailto:nauthilus-users@lists.nauthilus.org To unsubscribe send an email to nauthilus-users-leave@lists.nauthilus.orgmailto:nauthilus-users-leave@lists.nauthilus.org
Rößner-Network-Solutions Zertifizierter ITSiBe / CISO Marburger Str. 70a, 36304 Alsfeld Mobil: +49 171 9905345 USt-IdNr.: DE225643613, https://roessner.websitehttps://roessner.website/ PGP fingerprint: 658D 1342 B762 F484 2DDF 1E88 38A5 4346 D727 94E5
Rößner-Network-Solutions Zertifizierter ITSiBe / CISO Marburger Str. 70a, 36304 Alsfeld Mobil: +49 171 9905345 USt-IdNr.: DE225643613, https://roessner.websitehttps://roessner.website/ PGP fingerprint: 658D 1342 B762 F484 2DDF 1E88 38A5 4346 D727 94E5
Rößner-Network-Solutions Zertifizierter ITSiBe / CISO Marburger Str. 70a, 36304 Alsfeld Mobil: +49 171 9905345 USt-IdNr.: DE225643613, https://roessner.website PGP fingerprint: 658D 1342 B762 F484 2DDF 1E88 38A5 4346 D727 94E5
Morning Christian,
I have just deployed the fresh 1.11.6 package from github. I am happy to report that I am not seeing the same failures as before. The issue does look to have been resolved. Thanks!
It may be that we do not run production on this now until the new year. We are in a technical freeze period (the initial go-live with nauthilus was just before this).
I will see if I start experimenting with other components of nauthilus (brute-force detection / lua scripting) and see how we can use this tool to good effect with our services.
Regards,
Chris Moules
-----Original Message----- From: Christian Rößner christian@roessner.email Sent: 17 December 2025 17:34 To: Christopher Moules Christopher.Moules@post.lu Cc: Main list for Nauthilus users nauthilus-users@lists.nauthilus.org Subject: Re: [Nauthilus-users] Why do I get "passdb_backend=unknown" for a subset of requests
ATTENTION: Ce mail provient de l'extérieur de Post. Ne cliquez pas sur les liens ou n'ouvrez pas les pièces jointes à moins de connaitre l'expéditeur et d'être sûr que le contenu est inoffensif. En cas de doute sur son origine ou si vous pensez qu'il est suspect, nous vous prions de rapporter cet évènement par email à cybersos@post.lu.
Hi,
On 17 Dec 2025, at 17:08, Christopher Moules wrote:
Hello Christian,
That is good news! (at least the finding/identification of a bug). It has taken me a little while to understand the details of what was being logged and to see the differences in the requests, but apparently time well spent.
I was just about to report that I just installed the 1.11.5 release and that this made no difference to our use case.
I had started looking through the source code and found references to "Singleflight" in processLookupSearchRequest(). As some of the recent commit entries were all to do with removing Singleflight, I was trying to understand this code and figure out if this was the 'problem'. Given your response, I will take another look and see if I understand the issue.
Thanks again for your hard work on this.
No! I thank you very much for your help making it better :-)
I just pushed a fix into main. I think that could address the problem.
Kind regards
Christian
Regards,
Chris
From: Christian Rößner christian@roessner.email Sent: 17 December 2025 16:58 To: Christopher Moules Christopher.Moules@post.lu Cc: Main list for Nauthilus users nauthilus-users@lists.nauthilus.org Subject: Re: [Nauthilus-users] Why do I get "passdb_backend=unknown" for a subset of requests
ATTENTION: Ce mail provient de l'extérieur de Post. Ne cliquez pas sur les liens ou n'ouvrez pas les pièces jointes à moins de connaitre l'expéditeur et d'être sûr que le contenu est inoffensif. En cas de doute sur son origine ou si vous pensez qu'il est suspect, nous vous prions de rapporter cet évènement par email à cybersos@post.lumailto:cybersos@post.lu .
Hi,
thank you very much for your feedback. I think I might have found the issue now. Your response shows a major problem with a cache in front of LDAP filters. Unfortunately the macros have not been expanded before the given filter was used as a cache key. A user request with a failed login could cause cache poisoning.
I try to fix this asap.
Kind regards
Christian
On 17 Dec 2025, at 15:37, Christopher Moules wrote: Hello Again,
I have just observed something that might be of value.
The service is working fine, until we hit the case "Login Fail - User not exist" - (at this point the LDAP filter is logged). After this happens, I start to get many login failures where there is no "filter=" logged and existing users have 'UserFound:false' logged. Multiple Nauthilus restarts with Redis flushes have shown this same behaviour and it is with different non-existing users.
In all cases I am seeing 'msg="Connection #1 is free, using it"'. It could be that the user lookup failure is somehow blocking the LDAP connection, causing future lookups to fail.
I am not pushing enough traffic at the server to see if 'Connection #2' or more do not have this issue. As soon as I see the problems, I am cutting the traffic to the server.
I had had a very quick look at the commit messages you made and saw that things were mainly related to LDAP pool exhaustion. Given the above, this does not look to be that case. I had just reconfigured my 'nauthilus.yml', in the light of this, to have the following:
ldap: config: server_uri: ... number_of_workers: 16 lookup_pool_size: 8 lookup_idle_pool_size: 8 auth_pool_size: 8 auth_idle_pool_size: 8
When we started, I had not modified any of these settings from 'default'. I had reduced the numbers in the hope that this may help with the issue.
Regards,
Chris
From: Christopher Moules via Nauthilus-users <nauthilus-users@lists.nauthilus.orgmailto:nauthilus-users@lists.nauthilus.org> Sent: 17 December 2025 15:07 To: Christopher Moules <Christopher.Moules@post.lumailto:Christopher.Moules@post.lu> Cc: Main list for Nauthilus users <nauthilus-users@lists.nauthilus.orgmailto:nauthilus-users@lists.nauthilus.org> Subject: [Nauthilus-users] Re: Why do I get "passdb_backend=unknown" for a subset of requests
ATTENTION: Ce mail provient de l'extérieur de Post. Ne cliquez pas sur les liens ou n'ouvrez pas les pièces jointes à moins de connaitre l'expéditeur et d'être sûr que le contenu est inoffensif. En cas de doute sur son origine ou si vous pensez qu'il est suspect, nous vous prions de rapporter cet évènement par email à cybersos@post.lumailto:cybersos@post.lu .
Hello Christian,
So, based on this feedback I have tried configuring the following:
ldap: config: server_uri: ... number_of_workers: 8 lookup_pool_size: 4 lookup_idle_pool_size: 4 auth_pool_size: 4 auth_idle_pool_size: 4
This seems to, indeed, help, but not for long. After restarting Nauthilus and watching the logs with a low volume of traffic, for the first few minutes everything seems to be working as expected. Then, at some point, I start to get LDAP lookup failures and then these continue. At this point I stop new traffic to the server and suspend the test. I have done this a few times.
I do not directly have the resources to build a new release myself (mainly the time to setup a build server and figure out what I need). I hope my last mail is still of some value. I will try to take a look at the last commits and review the diff.
Thanks for all your assistance and what I do hope will become a very useful tool for us in the area of Authentication and Authorization, the possibilities are exciting.
Regards,
Chris
From: Christian Rößner via Nauthilus-users <nauthilus-users@lists.nauthilus.orgmailto:nauthilus-users@lists.nauthilus.org> Sent: Wednesday, December 17, 2025 12:01 To: Christopher Moules <Christopher.Moules@post.lumailto:Christopher.Moules@post.lu> Cc: Main list for Nauthilus users <nauthilus-users@lists.nauthilus.orgmailto:nauthilus-users@lists.nauthilus.org> Subject: [Nauthilus-users] Re: Why do I get "passdb_backend=unknown" for a subset of requests
ATTENTION: Ce mail provient de l'extérieur de Post. Ne cliquez pas sur les liens ou n'ouvrez pas les pièces jointes à moins de connaitre l'expéditeur et d'être sûr que le contenu est inoffensif. En cas de doute sur son origine ou si vous pensez qu'il est suspect, nous vous prions de rapporter cet évènement par email à cybersos@post.lumailto:cybersos@post.lu .
Hi,
I found an issue with the LDAP pool management and have fixed it.
As a small workaround:
Could you set the *_pool_size and *_idle_pool_size parameters to higher values? Set the idde-params to the same values as the non-idle ones.
If it gets better, my fix might be correct. Still waiting for the crash dump. I would like to see, if it addresses to "closing idle connection".
I am testing the code changes today and if no further errors occur will release a hot fix tomorrow. The code is already committed in main, if you want to give it a try.
Kind regards
Christian
Could these "busy or closed" LDAP instances #3-#8 be causing the "unknown" backend?
I don't think so, but of course I will investigate this.
What I see from the logs is that LDAP is telling you that it did not find the user: UserFound:false
Do you see LDAP-filter logs? If so, can you manually check if that filter works?
Kind regards
Christian
Rößner-Network-Solutions Zertifizierter ITSiBe / CISO Marburger Str. 70a, 36304 Alsfeld Mobil: +49 171 9905345 USt-IdNr.: DE225643613, https://roessner.website/https://roessner.website/ PGP fingerprint: 658D 1342 B762 F484 2DDF 1E88 38A5 4346 D727 94E5
Nauthilus-users mailing list -- nauthilus-users@lists.nauthilus.orgmailto:nauthilus-users@lists.nauthilus.org To unsubscribe send an email to nauthilus-users-leave@lists.nauthilus.orgmailto:nauthilus-users-leave@lists.nauthilus.org
Rößner-Network-Solutions Zertifizierter ITSiBe / CISO Marburger Str. 70a, 36304 Alsfeld Mobil: +49 171 9905345 USt-IdNr.: DE225643613, https://roessner.website/https://roessner.website/ PGP fingerprint: 658D 1342 B762 F484 2DDF 1E88 38A5 4346 D727 94E5
Rößner-Network-Solutions Zertifizierter ITSiBe / CISO Marburger Str. 70a, 36304 Alsfeld Mobil: +49 171 9905345 USt-IdNr.: DE225643613, https://roessner.website/https://roessner.website/ PGP fingerprint: 658D 1342 B762 F484 2DDF 1E88 38A5 4346 D727 94E5
Rößner-Network-Solutions Zertifizierter ITSiBe / CISO Marburger Str. 70a, 36304 Alsfeld Mobil: +49 171 9905345 USt-IdNr.: DE225643613, https://roessner.website/ PGP fingerprint: 658D 1342 B762 F484 2DDF 1E88 38A5 4346 D727 94E5
Hi,
On 18 Dec 2025, at 9:13, Christopher Moules wrote:
Morning Christian,
I have just deployed the fresh 1.11.6 package from github. I am happy to report that I am not seeing the same failures as before. The issue does look to have been resolved. Thanks!
Good to hear it’s fixed. And thanks for reporting :-)
It may be that we do not run production on this now until the new year. We are in a technical freeze period (the initial go-live with nauthilus was just before this).
I will see if I start experimenting with other components of nauthilus (brute-force detection / lua scripting) and see how we can use this tool to good effect with our services.
I am looking forward hearing from your experiences…
Regards
Christian
Regards,
Chris Moules
-----Original Message----- From: Christian Rößner christian@roessner.email Sent: 17 December 2025 17:34 To: Christopher Moules Christopher.Moules@post.lu Cc: Main list for Nauthilus users nauthilus-users@lists.nauthilus.org Subject: Re: [Nauthilus-users] Why do I get "passdb_backend=unknown" for a subset of requests
ATTENTION: Ce mail provient de l'extérieur de Post. Ne cliquez pas sur les liens ou n'ouvrez pas les pièces jointes à moins de connaitre l'expéditeur et d'être sûr que le contenu est inoffensif. En cas de doute sur son origine ou si vous pensez qu'il est suspect, nous vous prions de rapporter cet évènement par email à cybersos@post.lu.
Hi,
On 17 Dec 2025, at 17:08, Christopher Moules wrote:
Hello Christian,
That is good news! (at least the finding/identification of a bug). It has taken me a little while to understand the details of what was being logged and to see the differences in the requests, but apparently time well spent.
I was just about to report that I just installed the 1.11.5 release and that this made no difference to our use case.
I had started looking through the source code and found references to "Singleflight" in processLookupSearchRequest(). As some of the recent commit entries were all to do with removing Singleflight, I was trying to understand this code and figure out if this was the 'problem'. Given your response, I will take another look and see if I understand the issue.
Thanks again for your hard work on this.
No! I thank you very much for your help making it better :-)
I just pushed a fix into main. I think that could address the problem.
Kind regards
Christian
Regards,
Chris
From: Christian Rößner christian@roessner.email Sent: 17 December 2025 16:58 To: Christopher Moules Christopher.Moules@post.lu Cc: Main list for Nauthilus users nauthilus-users@lists.nauthilus.org Subject: Re: [Nauthilus-users] Why do I get "passdb_backend=unknown" for a subset of requests
ATTENTION: Ce mail provient de l'extérieur de Post. Ne cliquez pas sur les liens ou n'ouvrez pas les pièces jointes à moins de connaitre l'expéditeur et d'être sûr que le contenu est inoffensif. En cas de doute sur son origine ou si vous pensez qu'il est suspect, nous vous prions de rapporter cet évènement par email à cybersos@post.lumailto:cybersos@post.lu .
Hi,
thank you very much for your feedback. I think I might have found the issue now. Your response shows a major problem with a cache in front of LDAP filters. Unfortunately the macros have not been expanded before the given filter was used as a cache key. A user request with a failed login could cause cache poisoning.
I try to fix this asap.
Kind regards
Christian
On 17 Dec 2025, at 15:37, Christopher Moules wrote: Hello Again,
I have just observed something that might be of value.
The service is working fine, until we hit the case "Login Fail - User not exist" - (at this point the LDAP filter is logged). After this happens, I start to get many login failures where there is no "filter=" logged and existing users have 'UserFound:false' logged. Multiple Nauthilus restarts with Redis flushes have shown this same behaviour and it is with different non-existing users.
In all cases I am seeing 'msg="Connection #1 is free, using it"'. It could be that the user lookup failure is somehow blocking the LDAP connection, causing future lookups to fail.
I am not pushing enough traffic at the server to see if 'Connection #2' or more do not have this issue. As soon as I see the problems, I am cutting the traffic to the server.
I had had a very quick look at the commit messages you made and saw that things were mainly related to LDAP pool exhaustion. Given the above, this does not look to be that case. I had just reconfigured my 'nauthilus.yml', in the light of this, to have the following:
ldap: config: server_uri: ... number_of_workers: 16 lookup_pool_size: 8 lookup_idle_pool_size: 8 auth_pool_size: 8 auth_idle_pool_size: 8
When we started, I had not modified any of these settings from 'default'. I had reduced the numbers in the hope that this may help with the issue.
Regards,
Chris
From: Christopher Moules via Nauthilus-users <nauthilus-users@lists.nauthilus.orgmailto:nauthilus-users@lists.nauthilus.org> Sent: 17 December 2025 15:07 To: Christopher Moules <Christopher.Moules@post.lumailto:Christopher.Moules@post.lu> Cc: Main list for Nauthilus users <nauthilus-users@lists.nauthilus.orgmailto:nauthilus-users@lists.nauthilus.org> Subject: [Nauthilus-users] Re: Why do I get "passdb_backend=unknown" for a subset of requests
ATTENTION: Ce mail provient de l'extérieur de Post. Ne cliquez pas sur les liens ou n'ouvrez pas les pièces jointes à moins de connaitre l'expéditeur et d'être sûr que le contenu est inoffensif. En cas de doute sur son origine ou si vous pensez qu'il est suspect, nous vous prions de rapporter cet évènement par email à cybersos@post.lumailto:cybersos@post.lu .
Hello Christian,
So, based on this feedback I have tried configuring the following:
ldap: config: server_uri: ... number_of_workers: 8 lookup_pool_size: 4 lookup_idle_pool_size: 4 auth_pool_size: 4 auth_idle_pool_size: 4
This seems to, indeed, help, but not for long. After restarting Nauthilus and watching the logs with a low volume of traffic, for the first few minutes everything seems to be working as expected. Then, at some point, I start to get LDAP lookup failures and then these continue. At this point I stop new traffic to the server and suspend the test. I have done this a few times.
I do not directly have the resources to build a new release myself (mainly the time to setup a build server and figure out what I need). I hope my last mail is still of some value. I will try to take a look at the last commits and review the diff.
Thanks for all your assistance and what I do hope will become a very useful tool for us in the area of Authentication and Authorization, the possibilities are exciting.
Regards,
Chris
From: Christian Rößner via Nauthilus-users <nauthilus-users@lists.nauthilus.orgmailto:nauthilus-users@lists.nauthilus.org> Sent: Wednesday, December 17, 2025 12:01 To: Christopher Moules <Christopher.Moules@post.lumailto:Christopher.Moules@post.lu> Cc: Main list for Nauthilus users <nauthilus-users@lists.nauthilus.orgmailto:nauthilus-users@lists.nauthilus.org> Subject: [Nauthilus-users] Re: Why do I get "passdb_backend=unknown" for a subset of requests
ATTENTION: Ce mail provient de l'extérieur de Post. Ne cliquez pas sur les liens ou n'ouvrez pas les pièces jointes à moins de connaitre l'expéditeur et d'être sûr que le contenu est inoffensif. En cas de doute sur son origine ou si vous pensez qu'il est suspect, nous vous prions de rapporter cet évènement par email à cybersos@post.lumailto:cybersos@post.lu .
Hi,
I found an issue with the LDAP pool management and have fixed it.
As a small workaround:
Could you set the *_pool_size and *_idle_pool_size parameters to higher values? Set the idde-params to the same values as the non-idle ones.
If it gets better, my fix might be correct. Still waiting for the crash dump. I would like to see, if it addresses to "closing idle connection".
I am testing the code changes today and if no further errors occur will release a hot fix tomorrow. The code is already committed in main, if you want to give it a try.
Kind regards
Christian
Could these "busy or closed" LDAP instances #3-#8 be causing the "unknown" backend?
I don't think so, but of course I will investigate this.
What I see from the logs is that LDAP is telling you that it did not find the user: UserFound:false
Do you see LDAP-filter logs? If so, can you manually check if that filter works?
Kind regards
Christian
Rößner-Network-Solutions Zertifizierter ITSiBe / CISO Marburger Str. 70a, 36304 Alsfeld Mobil: +49 171 9905345 USt-IdNr.: DE225643613, https://roessner.website/https://roessner.website/ PGP fingerprint: 658D 1342 B762 F484 2DDF 1E88 38A5 4346 D727 94E5
Nauthilus-users mailing list -- nauthilus-users@lists.nauthilus.orgmailto:nauthilus-users@lists.nauthilus.org To unsubscribe send an email to nauthilus-users-leave@lists.nauthilus.orgmailto:nauthilus-users-leave@lists.nauthilus.org
Rößner-Network-Solutions Zertifizierter ITSiBe / CISO Marburger Str. 70a, 36304 Alsfeld Mobil: +49 171 9905345 USt-IdNr.: DE225643613, https://roessner.website/https://roessner.website/ PGP fingerprint: 658D 1342 B762 F484 2DDF 1E88 38A5 4346 D727 94E5
Rößner-Network-Solutions Zertifizierter ITSiBe / CISO Marburger Str. 70a, 36304 Alsfeld Mobil: +49 171 9905345 USt-IdNr.: DE225643613, https://roessner.website/https://roessner.website/ PGP fingerprint: 658D 1342 B762 F484 2DDF 1E88 38A5 4346 D727 94E5
Rößner-Network-Solutions Zertifizierter ITSiBe / CISO Marburger Str. 70a, 36304 Alsfeld Mobil: +49 171 9905345 USt-IdNr.: DE225643613, https://roessner.website/ PGP fingerprint: 658D 1342 B762 F484 2DDF 1E88 38A5 4346 D727 94E5
Rößner-Network-Solutions Zertifizierter ITSiBe / CISO Marburger Str. 70a, 36304 Alsfeld Mobil: +49 171 9905345 USt-IdNr.: DE225643613, https://roessner.website PGP fingerprint: 658D 1342 B762 F484 2DDF 1E88 38A5 4346 D727 94E5
Hello Christian,
Could you please forward the null pointer exceptions. This is very important.
As I tried to imply, this was speculation. I do not have anything "black and white" that shows null pointers. Having read more about the LDAP configuration, what I saw here is probably the LDAP pools (search/auth) and the "idle_pool_size" (2x LDAP connections) and the others are then connected on-demand. I had wondered if the "LDAP free/busy state #3 is busy or closed" was informing me that the connection was non-functional and if a thread used this connection that it would fail. Now I think I understand this better, and these are "just" currently unused LDAP connection instances.
What I see from the logs is that LDAP is telling you that it did not find the user: UserFound:false Do you see LDAP-filter logs? If so, can you manually check if that filter works?
I thought that I had stated, and shown with logs, if I perform a "?mode=no-auth" for the same user that is failing, the user is found via the LDAP search. (see my first message and the logs supplied). Simply said, "yes, the filter works". The LDAP filter is identical to that in our legacy codebase.
I would need to do some correlation with the LDAP server and the logs, but I believe that Nauthilus is not performing a LDAP search against the LDAP server when I am seeing "passdb_backend=unknown" and "Backend='unknown'" in the Nauthilus logs.
While composing this answer, I have been trying to see more in the logs. I think that I have a few clues. I have looked at the following cases:
Login Success
Login Failure (incorrect - our problem case)
Login Failure (correct - user does not exist)
Login Failure (correct - password false)
Comparing a "success" to a "failure" (incorrect) and "failure" (correct) I am seeing some key differences.
The most significant to me, is that for all the correct use cases, I can see the LDAP filter in the LDAP debug. However, in the "failure" (incorrect) case, the LDAP debug line with the filter is missing. Some log extracts (journald - heavily edited) re-arranged to read top-down.
Login Success: level=NOTICE msg="Processing incoming request" level=DEBUG msg="Connection #1 is free, using it" … pool=lookup level=DEBUG … filter="redacted" debug_module=ldap level=DEBUG msg="Connection #1 is free, using it" … pool=auth level=DEBUG … passdb=ldap result="Authenticated='true' UserFound='true' BackendName='__meta_default__' level=NOTICE msg="Authentication request was successful" … mode=auth backend_name=__meta_default__ protocol=pop3 … auth_method=plain username=redacted passdb_backend=ldap … cache to redis and succeed.
Login Fail - user not exist: level=NOTICE msg="Processing incoming request" level=DEBUG msg="Connection #1 is free, using it" … pool=lookup level=DEBUG … filter="redacted" debug_module=ldap level=DEBUG … passdb=ldap username=redacted passdb_result="{Authenticated:false UserFound:false level=NOTICE msg="Authentication request has failed" … mode=auth backend_name=N/A protocol=imap … auth_method=plain username=redacted passdb_backend=unknown
Login Fail - wrong PWD: level=NOTICE msg="Processing incoming request" level=DEBUG msg="Connection #1 is free, using it" … pool=lookup level=DEBUG … filter="redacted" debug_module=ldap level=DEBUG msg="Connection #1 is free, using it" … pool=auth level=DEBUG … passdb=ldap result="Authenticated='false' UserFound='true' BackendName='__meta_default__' level=NOTICE msg="Authentication request has failed" … mode=auth backend_name=__meta_default__ protocol=imap … auth_method=plain username=redacted passdb_backend=ldap
Login Fail - Our problem use case: level=NOTICE msg="Processing incoming request" level=DEBUG msg="Connection #1 is free, using it" … pool=lookup <NOTE> Here missing 'level=DEBUG … filter="redacted" debug_module=ldap'</NOTE> level=DEBUG … passdb=ldap username=redacted passdb_result="{Authenticated:false UserFound:false level=NOTICE msg="Authentication request has failed" … mode=auth backend_name=N/A protocol=imap … auth_method=plain username=redacted passdb_backend=unknown
So, if I see correctly, in a subset of cases, we are seeing that the LDAP module is possibly(?) not querying the LDAP server, not getting any results and failing the request. The lack of "BackendName='__meta_default__'" may or may not be a clue? However where a LDAP query returns no result (unknown user), this is also the case. I have a feeling that this might have a link with "connection stability" or "persistence" with our legacy LDAP servers. It could well be that newer LDAP servers have better connection handling code and that you do not see this as you have "more functional" LDAP servers. That said, I do not see directly any errors on the LDAP server side. I mention this as a possibility as this would not be a use-case that you have tested against.
Given the above observation, I will, when I have time and energy, try to look at the source code to the LDAP module and identify what might be happening between 'Connection #1 is free, using it' and 'filter="redacted"'. Any further insights from your side are naturally welcome.
Seasons Greetings,
Chris
From: Christian Rößner christian@roessner.email Sent: Wednesday, December 17, 2025 08:22 To: Christopher Moules Christopher.Moules@post.lu; Main list for Nauthilus users nauthilus-users@lists.nauthilus.org Subject: Re: [Nauthilus-users] Why do I get "passdb_backend=unknown" for a subset of requests
ATTENTION: Ce mail provient de l'extérieur de Post. Ne cliquez pas sur les liens ou n'ouvrez pas les pièces jointes à moins de connaitre l'expéditeur et d'être sûr que le contenu est inoffensif. En cas de doute sur son origine ou si vous pensez qu'il est suspect, nous vous prions de rapporter cet évènement par email à cybersos@post.lu.
Hi Christopher,
Is there anything else that you might suggest or observe? Are there any flags in the 1.11 branch (similar to "server.dedup.in_process_enabled") that might (need to) be set?
No
Is there any more information that I might be able to supply to assist?
What we do not understand and cannot explain is this "passdb_backend=unknown". It is like for some request instances there is a null pointer for the server … and typing this and seeing the logs, I note:
Could you please forward the null pointer exceptions. This is very important.
Dec 16 13:34:43 hostpack-nauthilus-01 nauthilus[71980]: time=2025-12-16T13:34:43.796Z level=DEBUG msg="LDAP free/busy state #1 is free" instance=nauthilus pool=auth debug_module=ldappool function=github.com/croessner/nauthilus/server/backend/ldappool.(*ldapPoolImpl).u> Dec 16 13:34:43 hostpack-nauthilus-01 nauthilus[71980]: time=2025-12-16T13:34:43.796Z level=DEBUG msg="LDAP free/busy state #2 is free" instance=nauthilus pool=auth debug_module=ldappool function=github.com/croessner/nauthilus/server/backend/ldappool.(*ldapPoolImpl).u> Dec 16 13:34:43 hostpack-nauthilus-01 nauthilus[71980]: time=2025-12-16T13:34:43.796Z level=DEBUG msg="LDAP free/busy state #3 is busy or closed" instance=nauthilus pool=auth debug_module=ldappool function=github.com/croessner/nauthilus/server/backend/ldappool.(*ldapP> Dec 16 13:34:43 hostpack-nauthilus-01 nauthilus[71980]: time=2025-12-16T13:34:43.796Z level=DEBUG msg="LDAP free/busy state #4 is busy or closed" instance=nauthilus pool=auth debug_module=ldappool function=github.com/croessner/nauthilus/server/backend/ldappool.(*ldapP> Dec 16 13:34:43 hostpack-nauthilus-01 nauthilus[71980]: time=2025-12-16T13:34:43.796Z level=DEBUG msg="LDAP free/busy state #5 is busy or closed" instance=nauthilus pool=auth debug_module=ldappool function=github.com/croessner/nauthilus/server/backend/ldappool.(*ldapP> Dec 16 13:34:43 hostpack-nauthilus-01 nauthilus[71980]: time=2025-12-16T13:34:43.796Z level=DEBUG msg="LDAP free/busy state #6 is busy or closed" instance=nauthilus pool=auth debug_module=ldappool function=github.com/croessner/nauthilus/server/backend/ldappool.(*ldapP> Dec 16 13:34:43 hostpack-nauthilus-01 nauthilus[71980]: time=2025-12-16T13:34:43.796Z level=DEBUG msg="LDAP free/busy state #7 is busy or closed" instance=nauthilus pool=auth debug_module=ldappool function=github.com/croessner/nauthilus/server/backend/ldappool.(*ldapP> Dec 16 13:34:43 hostpack-nauthilus-01 nauthilus[71980]: time=2025-12-16T13:34:43.796Z level=DEBUG msg="LDAP free/busy state #8 is busy or closed" instance=nauthilus pool=auth debug_module=ldappool function=github.com/croessner/nauthilus/server/backend/ldappool.(*ldapP> Dec 16 13:34:43 hostpack-nauthilus-01 nauthilus[71980]: time=2025-12-16T13:34:43.796Z level=DEBUG msg="State open connections" instance=nauthilus pool=auth needClosing=0 openConnections=2 idlePoolSize=2 debug_module=ldappool function=github.com/croessner/nauthilus/ser>
Could these "busy or closed" LDAP instances #3-#8 be causing the "unknown" backend?
I don’t think so, but of course I will investigate this.
What I see from the logs is that LDAP is telling you that it did not find the user: UserFound:false
Do you see LDAP-filter logs? If so, can you manually check if that filter works?
Kind regards
Christian
Rößner-Network-Solutions Zertifizierter ITSiBe / CISO Marburger Str. 70a, 36304 Alsfeld Mobil: +49 171 9905345 USt-IdNr.: DE225643613, https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Froessner.w...https://roessner.website/ PGP fingerprint: 658D 1342 B762 F484 2DDF 1E88 38A5 4346 D727 94E5
participants (2)
-
Christian Rößner -
Christopher Moules