I'm calling a 3rd party 2FA API from within a password module in OpenLDAP. The 2FA API call sends an SMS push to a mobile device.

If the push does not return a result within 10 seconds, auth fails with what looks like a socket (tls_read) timeout[1]. What is going on there and can this timeout be increased if that's what this is?

60 seconds would be more user friendly but after some experimentation with ldap_set_option() I've not been able to affect the connection timeout -- if that's what it is.

Thanks

------------------- push timed out ------------------------------ 5ce4023e daemon: activity on 1 descriptor 5ce4023e daemon: activity on: 30r 5ce4023e daemon: read active on 30 5ce4023e daemon: epoll: listen=8 active_threads=0 tvp=zero 5ce4023e daemon: epoll: listen=9 active_threads=0 tvp=zero 5ce4023e daemon: epoll: listen=10 active_threads=0 tvp=zero 5ce4023e connection_get(30) 5ce4023e connection_get(30): got connid=1002 5ce4023e connection_read(30): checking for input on id=1002 ber_get_next tls_read: want=5, got=5 0000: 17 03 03 00 26 ....&

tls_read: want=38, got=38 0000: 00 00 00 00 00 00 00 04 22 93 b3 d6 32 6d 6b c2 ........"...2mk. 0010: 1c d2 4b 74 d9 87 8e c2 63 35 02 e4 5e 5f d6 76 ..Kt....c5..^_.v 0020: b5 b4 8b d2 04 14 ......

ldap_read: want=8, got=8 0000: 30 0c 02 01 05 60 07 02 0....`..

ldap_read: want=6, got=6 0000: 01 03 04 00 80 00 ......

ber_get_next: tag 0x30 len 12 contents: ber_dump: buf=0x7efc280008c0 ptr=0x7efc280008c0 end=0x7efc280008cc len=12 0000: 02 01 05 60 07 02 01 03 04 00 80 00 ...`........

5ce4023e op tag 0x60, time 1558446654 5ce4023e connection_input: conn=1002 deferring operation: binding ber_get_next tls_read: want=5 error=Resource temporarily unavailable ldap_read: want=8, got=0

5ce4023e daemon: activity on 1 descriptor 5ce4023e daemon: activity on: 5ce4023e daemon: epoll: listen=8 active_threads=0 tvp=zero 5ce4023e daemon: epoll: listen=9 active_threads=0 tvp=zero 5ce4023e daemon: epoll: listen=10 active_threads=0 tvp=zero

On 5/21/19 4:31 PM, Michael Ströder wrote:

On 5/21/19 4:12 PM, dee heffem wrote:

<snip>>> 60 seconds would be more user friendly but after some experimentation

...

with ldap_set_option() I've not been able to affect the connection timeout -- if that's what it is.

It seems after reloading my OpenLDAP test server this morning, the ldap_set_option() timeout adjustment has indeed changed. I had merely restarted slapd yesterday and for whatever reason the timeout was unaffected.

Is your overlay processing a single bind operation?

AFAIK the slapd worker thread is blocked for the whole processing time of a single bind operation. Thus I have some doubts that you want to implement an auth mechanism with such asynchronous characteristics in an overlay.

Yes. Also, I now see what you mean. Testing simultaneous auth sessions was the next TODO after increasing the timeout. Alas, as you mention, when two users attempt a bind (ldapsearch -D for instance) User #2 does not get a push request until User #1 has finished auth. Blasted thing.

Can lutil_passwd_add() be told to run in another thread or something? Perhaps this is just digging a hole deeper however.

Thanks

On 5/22/19 8:50 AM, Michael Ströder wrote: <snip>

Each request is processed by a slapd worker-thread. But this means that when setting

threads n

in your slapd.conf only max. n bind operations can wait for push message. The next one will block

I'm running OpenLDAP 2.4.42 (Ubuntu package) on the server which uses cn=config. zytrax shows the equivalent parameter being olcThreads which is 16 by default (I don't have the parameter set). Does this mean I should expect to get 16 "non-blocking" push requests running concurrently instead of only the one? Maybe I am misunderstanding - You mentioned earlier: "slapd worker thread is blocked for the whole processing time" so maybe this means the password overlay is not designed to run concurrently and this is all for naught?

Additionally, regarding the 10 second timeout in my original post, I've run more testing and it seems this timeout is limited to the Linux `su` command. Huh..perhaps I need to look into the PAM stack config or other client-side settings, not slapd. I'll have to try and hunt that down. Authenticating with a PHP application, or using an authenticated bind with ldapsearch doesn't timeout for nearly a minute.

BTW: Not sure about the capabilities of the 2FA service you're using. Such a service might serialize all your calls or have some other type of rate-limiting in place.

The vendor offers a "push test" utility which simply sends a user a push request to test the setup. I can indeed synchronously process pushes to two users at once (slapd out of the loop) so I don't believe the API is rate limiting at this point.

The source code for the utility is available and the same push call they use is the one I use in the password overlay. The only difference is I had to recompile the API library statically for use with slapd. I will have to look into the gcc flags and make sure I didn't mess something up there.

Thanks

On 5/24/19 12:58 PM, Michael Ströder wrote:

<snip>

No. It simply means that processing the LDAP operations is done synchronously in worker thread.

...

...

BTW: Not sure about the capabilities of the 2FA service you're using. Such a service might serialize all your calls or have some other type of rate-limiting in place.

The vendor offers a "push test" utility which simply sends a user a push request to test the setup. I can indeed synchronously process pushes to two users at once (slapd out of the loop)

Really in a single OS process?

Perhaps I misrepresented. This was done in two different terminal processes.

...

The source code for the utility is available and the same push call they use is the one I use in the password overlay. The only difference is I had to recompile the API library statically for use with slapd.

This library could also serialize calls into the library with a lock.

I was busy with a few other projects this week but just came back to this. I was going through some code and this caught my eye:

static ldap_pvt_thread_mutex_t my_mutex; ... ldap_pvt_thread_mutex_lock (...); ... ldap_pvt_thread_mutex_unlock (...);

in my password overlay. I used some of the contrib overlays to develop with and the radius.c overlay used this. I guessed it best to implement the same since I am also using an external API.

I don't have time today to experiment but this may be where the blocking is coming from. Would you know what the intention of ldap_pvt_thread_mutex_t is from the standpoint of the password overlay?

Thank you