Service crashes (unresponsive) when connection to LDAP fails

Hi all,

It seems that privacyIDEA service become unresponsive when the connection
to LDAP server in the ldapresolver fails.

How to reproduce:

  1. create a valid ldapresolver (test resolver successfully)
  2. block the connection between privacyidea server and ldap server (for
    example, by iptables, by stop slapd server, or by turning off the ldap
    server)
  3. retest the ldapresolver (user>ldapresolver>Test LDAP Resolver)

After step 3, the page will work on it for awhile. Wait for around 2-3
mins, then browse around, the portal is no longer responsive.

Have anyone run into the same issue before and/or be able to reproduce this?

Best regards,

Hi Cornelius,

Thank you for your response.
The connection is not LDAPS, simple LDAP. And I was also using the 2.16
privacyIDEA.
Were you able to reproduce this problem with any of your stack?On Wednesday, November 16, 2016 at 4:00:02 AM UTC-8, Cornelius Kölbel wrote:

Hi Quynh,

is your connection LDAPS?

There was is fix in the underlying ldap3 python module in version 2.0.7,
which might give us a hint here, that the connect_timeout was not honoured
in case of TLS.

http://ldap3.readthedocs.io/changelog.html

The test_connection and the normal code are using the connect_timeout.

When updating ldap3 please also update privacyIDEA. Since privacyIDEA <
2.16 will have problems with ldap3 >=2.0.7.

Kind regards
Cornelius

Am Mittwoch, 16. November 2016 00:58:14 UTC+1 schrieb Quynh .Nhat:

Hi all,

It seems that privacyIDEA service become unresponsive when the connection
to LDAP server in the ldapresolver fails.

How to reproduce:

  1. create a valid ldapresolver (test resolver successfully)
  2. block the connection between privacyidea server and ldap server (for
    example, by iptables, by stop slapd server, or by turning off the ldap
    server)
  3. retest the ldapresolver (user>ldapresolver>Test LDAP Resolver)

After step 3, the page will work on it for awhile. Wait for around 2-3
mins, then browse around, the portal is no longer responsive.

Have anyone run into the same issue before and/or be able to reproduce
this?

Best regards,

Hi Quynh,

is your connection LDAPS?

There was is fix in the underlying ldap3 python module in version 2.0.7,
which might give us a hint here, that the connect_timeout was not honoured
in case of TLS.

http://ldap3.readthedocs.io/changelog.html

The test_connection and the normal code are using the connect_timeout.

When updating ldap3 please also update privacyIDEA. Since privacyIDEA <
2.16 will have problems with ldap3 >=2.0.7.

Kind regards
CorneliusAm Mittwoch, 16. November 2016 00:58:14 UTC+1 schrieb Quynh .Nhat:

Hi all,

It seems that privacyIDEA service become unresponsive when the connection
to LDAP server in the ldapresolver fails.

How to reproduce:

  1. create a valid ldapresolver (test resolver successfully)
  2. block the connection between privacyidea server and ldap server (for
    example, by iptables, by stop slapd server, or by turning off the ldap
    server)
  3. retest the ldapresolver (user>ldapresolver>Test LDAP Resolver)

After step 3, the page will work on it for awhile. Wait for around 2-3
mins, then browse around, the portal is no longer responsive.

Have anyone run into the same issue before and/or be able to reproduce
this?

Best regards,

Hi Quynh,

great! THanks for your feedback.

Kind regards
CorneliusAm Donnerstag, den 17.11.2016, 13:13 -0800 schrieb Quynh .Nhat:

Hi Cornelius,

The fix seems to work well, and I dont experience indefinite hang
anymore when LDAP connection is down.

Thank you for your help!

Hello Quynh,

for a quick fix you can change the LDAPIdResolver.py, if this is OK
for
you.

Locate the method “get_serverpool”:

@classmethod 
def get_serverpool(cls, urilist, timeout): 
    """ 
    This create the serverpool for the ldap3 connection. 
    The URI from the LDAP resolver can contain a comma

separated

    :param urilist: The list of LDAP URIs, comma separated 
    :type urilist: basestring 
    :param timeout: The connection timeout 
    :type timeout: float 
    :return: Server Pool 
    :rtype: LDAP3 Server Pool Instance 
    """ 
    try: 
        strategy = ldap3.POOLING_STRATEGY_ROUND_ROBIN 
    except AttributeError: 
        # This is for ldap3 >= 2.0.7 
        strategy = ldap3.ROUND_ROBIN 
    server_pool = ldap3.ServerPool(None, strategy, active=2, 
                                   exhaust=30) 
    for uri in urilist.split(","): 
        uri = uri.strip() 
        host, port, ssl = cls.split_uri(uri) 
        server = ldap3.Server(host, port=port, 
                              use_ssl=ssl, 
                              connect_timeout=float(timeout)) 
        server_pool.add(server) 
        log.debug("Added {0!s}, {1!s}, {2!s} to server 

pool.".format(host, port, ssl))
return server_pool

Not the parameters to the call

    ldap3.ServerPool  

and set them to active=2 and exhaust=30.
active=2 means, it will try for 2 rounds to reach a server in the
server pool.

Kind regards
Cornelius

Am Donnerstag, den 17.11.2016, 01:10 -0800 schrieb Quynh .Nhat:

Also, I only use 1 LDAP server. It is not a pool.

Hi Cornelius,

Following are some settings information for the LDAP
connector.

  • Timeout: 30s
  • Limit: 500
  • seach base: OU=x,dc=y,dc=z

The installation is rpm, and we package it ourself.
Pip freeze output:
alembic==0.8.8
bcrypt==3.1.1
beautifulsoup4==4.5.1
cffi==1.9.1
click==6.6
configobj==5.0.6
cryptography==1.5.3
docutils==0.12
ecdsa==0.13
enum34==1.1.6
Flask==0.11.1
Flask-Migrate==2.0.1
Flask-Script==2.0.5
Flask-SQLAlchemy==2.1
funcparserlib==0.3.6
idna==2.1
ipaddress==1.0.17
itsdangerous==0.24
Jinja2==2.8
ldap3==2.1.0
lxml==3.6.4
Mako==1.0.6
MarkupSafe==0.23
netaddr==0.7.18
passlib==1.6.5
Pillow==3.4.2
privacyIDEA==2.16
privacyideaadm==2.15
psycopg2==2.6.2
pyasn1==0.1.9
pycparser==2.17
pycrypto==2.6.1
Pygments==2.1.3
PyGreSQL==5.0.2
PyJWT==1.4.2
PyKCS11==1.3.3
PyMySQL==0.7.9
pyOpenSSL==16.2.0
pyrad==2.0
pysqlite==2.8.3
python-editor==1.0.1
python-gnupg==0.3.9
pyusb==1.0.0
PyYAML==3.12
qrcode==5.3
requests==2.12.0
six==1.10.0
SQLAlchemy==1.1.4
sqlsoup==0.9.1
uWSGI==2.0.14
Werkzeug==0.11.11

I triggered the crash with the ‘Test LDAP Resolver’ button in
the

resolver setup page.
Some users have token assigned.

I have waited for like 10 mins, and the server still timeout
(504)

(even after the connection to LDAP is restored)
Restarted uwsgi fix the issue (our uwsgi config does not
recycle

the worker(s), and we plan to tune this in the future)


Please read the blog post about getting help
https://www.privacyidea.org/getting-help/.

For professional services and consultancy regarding two factor
authentication please visit
https://netknights.it/en/leistungen/one-time-services/

In an enterprise environment you should get a SERVICE LEVEL
AGREEMENT
which suites your needs for SECURITY, AVAILABILITY and
LIABILITY:
https://netknights.it/en/leistungen/service-level-agreements/

You received this message because you are subscribed to a topic
in
the Google Groups “privacyidea” group.
To unsubscribe from this topic, visit https://groups.google.com/d
/top
ic/privacyidea/aS_dG1uXpwo/unsubscribe.
To unsubscribe from this group and all its topics, send an email
to p
rivacyidea+...@googlegroups.com.
To post to this group, send email to priva...@googlegroups.com.
Visit this group at https://groups.google.com/group/privacyidea.
To view this discussion on the web visit https://groups.google.co
m/d/
msgid/privacyidea/ea6a79d6-b00b-4e5b-ac34-
9588c8e05491%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Cornelius Kölbel
@cornelinux
+49 151 2960 1417

NetKnights GmbH
http://www.netknights.it
Landgraf-Karl-Str. 19, 34131 Kassel, Germany
Tel: +49 561 3166797, Fax: +49 561 3166798

Amtsgericht Kassel, HRB 16405
Geschäftsführer: Cornelius Kölbel

signature.asc (819 Bytes)

Hi Cornelius,

The fix seems to work well, and I dont experience indefinite hang anymore
when LDAP connection is down.

Thank you for your help!On Thursday, November 17, 2016 at 5:40:53 AM UTC-8, Cornelius Kölbel wrote:

Hello Quynh,

for a quick fix you can change the LDAPIdResolver.py, if this is OK for
you.

Locate the method “get_serverpool”:

@classmethod 
def get_serverpool(cls, urilist, timeout): 
    """ 
    This create the serverpool for the ldap3 connection. 
    The URI from the LDAP resolver can contain a comma separated  

    :param urilist: The list of LDAP URIs, comma separated 
    :type urilist: basestring 
    :param timeout: The connection timeout 
    :type timeout: float 
    :return: Server Pool 
    :rtype: LDAP3 Server Pool Instance 
    """ 
    try: 
        strategy = ldap3.POOLING_STRATEGY_ROUND_ROBIN 
    except AttributeError: 
        # This is for ldap3 >= 2.0.7 
        strategy = ldap3.ROUND_ROBIN 
    server_pool = ldap3.ServerPool(None, strategy, active=2, 
                                   exhaust=30) 
    for uri in urilist.split(","): 
        uri = uri.strip() 
        host, port, ssl = cls.split_uri(uri) 
        server = ldap3.Server(host, port=port, 
                              use_ssl=ssl, 
                              connect_timeout=float(timeout)) 
        server_pool.add(server) 
        log.debug("Added {0!s}, {1!s}, {2!s} to server 

pool.".format(host, port, ssl))
return server_pool

Not the parameters to the call

    ldap3.ServerPool  

and set them to active=2 and exhaust=30.
active=2 means, it will try for 2 rounds to reach a server in the
server pool.

Kind regards
Cornelius

Am Donnerstag, den 17.11.2016, 01:10 -0800 schrieb Quynh .Nhat:

Also, I only use 1 LDAP server. It is not a pool.

Hi Cornelius,

Following are some settings information for the LDAP connector.

  • Timeout: 30s
  • Limit: 500
  • seach base: OU=x,dc=y,dc=z

The installation is rpm, and we package it ourself.
Pip freeze output:
alembic==0.8.8
bcrypt==3.1.1
beautifulsoup4==4.5.1
cffi==1.9.1
click==6.6
configobj==5.0.6
cryptography==1.5.3
docutils==0.12
ecdsa==0.13
enum34==1.1.6
Flask==0.11.1
Flask-Migrate==2.0.1
Flask-Script==2.0.5
Flask-SQLAlchemy==2.1
funcparserlib==0.3.6
idna==2.1
ipaddress==1.0.17
itsdangerous==0.24
Jinja2==2.8
ldap3==2.1.0
lxml==3.6.4
Mako==1.0.6
MarkupSafe==0.23
netaddr==0.7.18
passlib==1.6.5
Pillow==3.4.2
privacyIDEA==2.16
privacyideaadm==2.15
psycopg2==2.6.2
pyasn1==0.1.9
pycparser==2.17
pycrypto==2.6.1
Pygments==2.1.3
PyGreSQL==5.0.2
PyJWT==1.4.2
PyKCS11==1.3.3
PyMySQL==0.7.9
pyOpenSSL==16.2.0
pyrad==2.0
pysqlite==2.8.3
python-editor==1.0.1
python-gnupg==0.3.9
pyusb==1.0.0
PyYAML==3.12
qrcode==5.3
requests==2.12.0
six==1.10.0
SQLAlchemy==1.1.4
sqlsoup==0.9.1
uWSGI==2.0.14
Werkzeug==0.11.11

I triggered the crash with the ‘Test LDAP Resolver’ button in the
resolver setup page.
Some users have token assigned.

I have waited for like 10 mins, and the server still timeout (504)
(even after the connection to LDAP is restored)
Restarted uwsgi fix the issue (our uwsgi config does not recycle
the worker(s), and we plan to tune this in the future)


Please read the blog post about getting help
https://www.privacyidea.org/getting-help/.

For professional services and consultancy regarding two factor
authentication please visit
https://netknights.it/en/leistungen/one-time-services/

In an enterprise environment you should get a SERVICE LEVEL AGREEMENT
which suites your needs for SECURITY, AVAILABILITY and LIABILITY:
https://netknights.it/en/leistungen/service-level-agreements/

You received this message because you are subscribed to a topic in
the Google Groups “privacyidea” group.
To unsubscribe from this topic, visit https://groups.google.com/d/top
ic/privacyidea/aS_dG1uXpwo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to p
rivacyidea+...@googlegroups.com <javascript:>.
To post to this group, send email to priva...@googlegroups.com
<javascript:>.
Visit this group at https://groups.google.com/group/privacyidea.
To view this discussion on the web visit https://groups.google.com/d/
msgid/privacyidea/ea6a79d6-b00b-4e5b-ac34-
9588c8e05491%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Cornelius Kölbel
corneliu...@netknights.it <javascript:>
+49 151 2960 1417

NetKnights GmbH
http://www.netknights.it
Landgraf-Karl-Str. 19, 34131 Kassel, Germany
Tel: +49 561 3166797, Fax: +49 561 3166798

Amtsgericht Kassel, HRB 16405
Geschäftsführer: Cornelius Kölbel

Hi Cornelius,

Following are some settings information for the LDAP connector.

  • Timeout: 30s
  • Limit: 500
  • seach base: OU=x,dc=y,dc=z

The installation is rpm, and we package it ourself.
Pip freeze output:
alembic==0.8.8
bcrypt==3.1.1
beautifulsoup4==4.5.1
cffi==1.9.1
click==6.6
configobj==5.0.6
cryptography==1.5.3
docutils==0.12
ecdsa==0.13
enum34==1.1.6
Flask==0.11.1
Flask-Migrate==2.0.1
Flask-Script==2.0.5
Flask-SQLAlchemy==2.1
funcparserlib==0.3.6
idna==2.1
ipaddress==1.0.17
itsdangerous==0.24
Jinja2==2.8
ldap3==2.1.0
lxml==3.6.4
Mako==1.0.6
MarkupSafe==0.23
netaddr==0.7.18
passlib==1.6.5
Pillow==3.4.2
privacyIDEA==2.16
privacyideaadm==2.15
psycopg2==2.6.2
pyasn1==0.1.9
pycparser==2.17
pycrypto==2.6.1
Pygments==2.1.3
PyGreSQL==5.0.2
PyJWT==1.4.2
PyKCS11==1.3.3
PyMySQL==0.7.9
pyOpenSSL==16.2.0
pyrad==2.0
pysqlite==2.8.3
python-editor==1.0.1
python-gnupg==0.3.9
pyusb==1.0.0
PyYAML==3.12
qrcode==5.3
requests==2.12.0
six==1.10.0
SQLAlchemy==1.1.4
sqlsoup==0.9.1
uWSGI==2.0.14
Werkzeug==0.11.11

I triggered the crash with the ‘Test LDAP Resolver’ button in the resolver
setup page.
Some users have token assigned.

I have waited for like 10 mins, and the server still timeout (504) (even
after the connection to LDAP is restored)
Restarted uwsgi fix the issue (our uwsgi config does not recycle the
worker(s), and we plan to tune this in the future)

Hi Quynh,

no, not yet.
Can you please provide more information.

What is the install type?
pip, rpm, deb…

If pip, please run a

pip freeze

in your python virtualenv, so that I get all version numbers.

Are you running in apache or nginx? How many processes and threads have
you configured?
Please provide some settings information for the LDAP connector.

  • Timeout
  • Limit
  • seach base, is it top level DC or are you using an OU?

Did you already enroll tokens and assign to LDAP users? Or only testing
resolver?

Have you configured to use the resolver anywhere, yet?

Kind regards
CorneliusAm Mittwoch, den 16.11.2016, 14:49 -0800 schrieb Quynh .Nhat:

Hi Cornelius,

Thank you for your response.
The connection is not LDAPS, simple LDAP. And I was also using the
2.16 privacyIDEA.
Were you able to reproduce this problem with any of your stack?

Hi Quynh,

is your connection LDAPS?

There was is fix in the underlying ldap3 python module in version
2.0.7, which might give us a hint here, that the connect_timeout
was not honoured in case of TLS.

http://ldap3.readthedocs.io/changelog.html

The test_connection and the normal code are using the
connect_timeout.

When updating ldap3 please also update privacyIDEA. Since
privacyIDEA < 2.16 will have problems with ldap3 >=2.0.7.

Kind regards
Cornelius

Hi all,

It seems that privacyIDEA service become unresponsive when the
connection to LDAP server in the ldapresolver fails.

How to reproduce:

  1. create a valid ldapresolver (test resolver successfully)
  2. block the connection between privacyidea server and ldap
    server (for example, by iptables, by stop slapd server, or by
    turning off the ldap server)
  3. retest the ldapresolver (user>ldapresolver>Test LDAP Resolver)

After step 3, the page will work on it for awhile. Wait for
around 2-3 mins, then browse around, the portal is no longer
responsive.

Have anyone run into the same issue before and/or be able to
reproduce this?

Best regards,


Please read the blog post about getting help
https://www.privacyidea.org/getting-help/.

For professional services and consultancy regarding two factor
authentication please visit
https://netknights.it/en/leistungen/one-time-services/

In an enterprise environment you should get a SERVICE LEVEL AGREEMENT
which suites your needs for SECURITY, AVAILABILITY and LIABILITY:
https://netknights.it/en/leistungen/service-level-agreements/

You received this message because you are subscribed to a topic in
the Google Groups “privacyidea” group.
To unsubscribe from this topic, visit https://groups.google.com/d/top
ic/privacyidea/aS_dG1uXpwo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to p
rivacyidea+unsubscribe@googlegroups.com.
To post to this group, send email to privacyidea@googlegroups.com.
Visit this group at https://groups.google.com/group/privacyidea.
To view this discussion on the web visit https://groups.google.com/d/
msgid/privacyidea/bc0e4f31-4feb-4bad-9029-
49dfc85cfabf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Cornelius Kölbel
@cornelinux
+49 151 2960 1417

NetKnights GmbH
http://www.netknights.it
Landgraf-Karl-Str. 19, 34131 Kassel, Germany
Tel: +49 561 3166797, Fax: +49 561 3166798

Amtsgericht Kassel, HRB 16405
Geschäftsführer: Cornelius Kölbel

signature.asc (819 Bytes)

Hi Quynh,

there seems to be a bug within ldap3 regarding the timeout.
If by any chance you are running a virtualenv, please install ldap3
version 2.0.9

pip install ldap3==2.0.9

Kind regards
CorneliusAm Donnerstag, den 17.11.2016, 06:57 +0100 schrieb Cornelius Kölbel:

Hi Quynh,

no, not yet.
Can you please provide more information.

What is the install type?
pip, rpm, deb…

If pip, please run a

pip freeze

in your python virtualenv, so that I get all version numbers.

Are you running in apache or nginx? How many processes and threads
have
you configured?
Please provide some settings information for the LDAP connector.

  • Timeout
  • Limit
  • seach base, is it top level DC or are you using an OU?

Did you already enroll tokens and assign to LDAP users? Or only
testing
resolver?

Have you configured to use the resolver anywhere, yet?

Kind regards
Cornelius

Am Mittwoch, den 16.11.2016, 14:49 -0800 schrieb Quynh .Nhat:

Hi Cornelius,

Thank you for your response.
The connection is not LDAPS, simple LDAP. And I was also using the
2.16 privacyIDEA.
Were you able to reproduce this problem with any of your stack?

Hi Quynh,

is your connection LDAPS?

There was is fix in the underlying ldap3 python module in version
2.0.7, which might give us a hint here, that the connect_timeout
was not honoured in case of TLS.

http://ldap3.readthedocs.io/changelog.html

The test_connection and the normal code are using the
connect_timeout.

When updating ldap3 please also update privacyIDEA. Since
privacyIDEA < 2.16 will have problems with ldap3 >=2.0.7.

Kind regards
Cornelius

Hi all,

It seems that privacyIDEA service become unresponsive when the
connection to LDAP server in the ldapresolver fails.

How to reproduce:

  1. create a valid ldapresolver (test resolver successfully)
  2. block the connection between privacyidea server and ldap
    server (for example, by iptables, by stop slapd server, or by
    turning off the ldap server)
  3. retest the ldapresolver (user>ldapresolver>Test LDAP
    Resolver)

After step 3, the page will work on it for awhile. Wait for
around 2-3 mins, then browse around, the portal is no longer
responsive.

Have anyone run into the same issue before and/or be able to
reproduce this?

Best regards,


Please read the blog post about getting help
https://www.privacyidea.org/getting-help/.

For professional services and consultancy regarding two factor
authentication please visit
https://netknights.it/en/leistungen/one-time-services/

In an enterprise environment you should get a SERVICE LEVEL
AGREEMENT
which suites your needs for SECURITY, AVAILABILITY and LIABILITY:
https://netknights.it/en/leistungen/service-level-agreements/

You received this message because you are subscribed to a topic in
the Google Groups “privacyidea” group.
To unsubscribe from this topic, visit https://groups.google.com/d/t
op
ic/privacyidea/aS_dG1uXpwo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
p
rivacyidea+unsubscribe@googlegroups.com.
To post to this group, send email to privacyidea@googlegroups.com.
Visit this group at https://groups.google.com/group/privacyidea.
To view this discussion on the web visit https://groups.google.com/
d/
msgid/privacyidea/bc0e4f31-4feb-4bad-9029-
49dfc85cfabf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Cornelius Kölbel
@cornelinux
+49 151 2960 1417

NetKnights GmbH
http://www.netknights.it
Landgraf-Karl-Str. 19, 34131 Kassel, Germany
Tel: +49 561 3166797, Fax: +49 561 3166798

Amtsgericht Kassel, HRB 16405
Geschäftsführer: Cornelius Kölbel


Cornelius Kölbel
@cornelinux
+49 151 2960 1417

NetKnights GmbH
http://www.netknights.it
Landgraf-Karl-Str. 19, 34131 Kassel, Germany
Tel: +49 561 3166797, Fax: +49 561 3166798

Amtsgericht Kassel, HRB 16405
Geschäftsführer: Cornelius Kölbel

signature.asc (819 Bytes)

Hi Quynh,

ok, I can see this now. The effect does not seem with all requests.

The test request is pending and some API requests are also pending
after this. (like fetching the tokens)

I tested with a 2nd LDAP resolver, which worked find, even after the
first one was pending.

In fact after 5 minutes I get a 504 Gateway Timeout and all API
requests are working fine again.

Which version of ldap3 are you using?

Thanks a lot
CorneliusAm Mittwoch, den 16.11.2016, 14:49 -0800 schrieb Quynh .Nhat:

Hi Cornelius,

Thank you for your response.
The connection is not LDAPS, simple LDAP. And I was also using the
2.16 privacyIDEA.
Were you able to reproduce this problem with any of your stack?

Hi Quynh,

is your connection LDAPS?

There was is fix in the underlying ldap3 python module in version
2.0.7, which might give us a hint here, that the connect_timeout
was not honoured in case of TLS.

http://ldap3.readthedocs.io/changelog.html

The test_connection and the normal code are using the
connect_timeout.

When updating ldap3 please also update privacyIDEA. Since
privacyIDEA < 2.16 will have problems with ldap3 >=2.0.7.

Kind regards
Cornelius

Hi all,

It seems that privacyIDEA service become unresponsive when the
connection to LDAP server in the ldapresolver fails.

How to reproduce:

  1. create a valid ldapresolver (test resolver successfully)
  2. block the connection between privacyidea server and ldap
    server (for example, by iptables, by stop slapd server, or by
    turning off the ldap server)
  3. retest the ldapresolver (user>ldapresolver>Test LDAP Resolver)

After step 3, the page will work on it for awhile. Wait for
around 2-3 mins, then browse around, the portal is no longer
responsive.

Have anyone run into the same issue before and/or be able to
reproduce this?

Best regards,


Please read the blog post about getting help
https://www.privacyidea.org/getting-help/.

For professional services and consultancy regarding two factor
authentication please visit
https://netknights.it/en/leistungen/one-time-services/

In an enterprise environment you should get a SERVICE LEVEL AGREEMENT
which suites your needs for SECURITY, AVAILABILITY and LIABILITY:
https://netknights.it/en/leistungen/service-level-agreements/

You received this message because you are subscribed to a topic in
the Google Groups “privacyidea” group.
To unsubscribe from this topic, visit https://groups.google.com/d/top
ic/privacyidea/aS_dG1uXpwo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to p
rivacyidea+unsubscribe@googlegroups.com.
To post to this group, send email to privacyidea@googlegroups.com.
Visit this group at https://groups.google.com/group/privacyidea.
To view this discussion on the web visit https://groups.google.com/d/
msgid/privacyidea/bc0e4f31-4feb-4bad-9029-
49dfc85cfabf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Cornelius Kölbel
@cornelinux
+49 151 2960 1417

NetKnights GmbH
http://www.netknights.it
Landgraf-Karl-Str. 19, 34131 Kassel, Germany
Tel: +49 561 3166797, Fax: +49 561 3166798

Amtsgericht Kassel, HRB 16405
Geschäftsführer: Cornelius Kölbel

signature.asc (819 Bytes)

Also, I only use 1 LDAP server. It is not a pool.On Thursday, November 17, 2016 at 1:09:14 AM UTC-8, Quynh .Nhat wrote:

Hi Cornelius,

Following are some settings information for the LDAP connector.

  • Timeout: 30s
  • Limit: 500
  • seach base: OU=x,dc=y,dc=z

The installation is rpm, and we package it ourself.
Pip freeze output:
alembic==0.8.8
bcrypt==3.1.1
beautifulsoup4==4.5.1
cffi==1.9.1
click==6.6
configobj==5.0.6
cryptography==1.5.3
docutils==0.12
ecdsa==0.13
enum34==1.1.6
Flask==0.11.1
Flask-Migrate==2.0.1
Flask-Script==2.0.5
Flask-SQLAlchemy==2.1
funcparserlib==0.3.6
idna==2.1
ipaddress==1.0.17
itsdangerous==0.24
Jinja2==2.8
ldap3==2.1.0
lxml==3.6.4
Mako==1.0.6
MarkupSafe==0.23
netaddr==0.7.18
passlib==1.6.5
Pillow==3.4.2
privacyIDEA==2.16
privacyideaadm==2.15
psycopg2==2.6.2
pyasn1==0.1.9
pycparser==2.17
pycrypto==2.6.1
Pygments==2.1.3
PyGreSQL==5.0.2
PyJWT==1.4.2
PyKCS11==1.3.3
PyMySQL==0.7.9
pyOpenSSL==16.2.0
pyrad==2.0
pysqlite==2.8.3
python-editor==1.0.1
python-gnupg==0.3.9
pyusb==1.0.0
PyYAML==3.12
qrcode==5.3
requests==2.12.0
six==1.10.0
SQLAlchemy==1.1.4
sqlsoup==0.9.1
uWSGI==2.0.14
Werkzeug==0.11.11

I triggered the crash with the ‘Test LDAP Resolver’ button in the resolver
setup page.
Some users have token assigned.

I have waited for like 10 mins, and the server still timeout (504) (even
after the connection to LDAP is restored)
Restarted uwsgi fix the issue (our uwsgi config does not recycle the
worker(s), and we plan to tune this in the future)

Hello Quynh,

for a quick fix you can change the LDAPIdResolver.py, if this is OK for
you.

Locate the method “get_serverpool”:

@classmethod
def get_serverpool(cls, urilist, timeout):
    """
    This create the serverpool for the ldap3 connection.
    The URI from the LDAP resolver can contain a comma separated 

    :param urilist: The list of LDAP URIs, comma separated
    :type urilist: basestring
    :param timeout: The connection timeout
    :type timeout: float
    :return: Server Pool
    :rtype: LDAP3 Server Pool Instance
    """
    try:
        strategy = ldap3.POOLING_STRATEGY_ROUND_ROBIN
    except AttributeError:
        # This is for ldap3 >= 2.0.7
        strategy = ldap3.ROUND_ROBIN
    server_pool = ldap3.ServerPool(None, strategy, active=2,
                                   exhaust=30)
    for uri in urilist.split(","):
        uri = uri.strip()
        host, port, ssl = cls.split_uri(uri)
        server = ldap3.Server(host, port=port,
                              use_ssl=ssl,
                              connect_timeout=float(timeout))
        server_pool.add(server)
        log.debug("Added {0!s}, {1!s}, {2!s} to server

pool.".format(host, port, ssl))
return server_pool

Not the parameters to the call

ldap3.ServerPool 

and set them to active=2 and exhaust=30.
active=2 means, it will try for 2 rounds to reach a server in the
server pool.

Kind regards
CorneliusAm Donnerstag, den 17.11.2016, 01:10 -0800 schrieb Quynh .Nhat:

Also, I only use 1 LDAP server. It is not a pool.

Hi Cornelius,

Following are some settings information for the LDAP connector.

  • Timeout: 30s
  • Limit: 500
  • seach base: OU=x,dc=y,dc=z

The installation is rpm, and we package it ourself.
Pip freeze output:
alembic==0.8.8
bcrypt==3.1.1
beautifulsoup4==4.5.1
cffi==1.9.1
click==6.6
configobj==5.0.6
cryptography==1.5.3
docutils==0.12
ecdsa==0.13
enum34==1.1.6
Flask==0.11.1
Flask-Migrate==2.0.1
Flask-Script==2.0.5
Flask-SQLAlchemy==2.1
funcparserlib==0.3.6
idna==2.1
ipaddress==1.0.17
itsdangerous==0.24
Jinja2==2.8
ldap3==2.1.0
lxml==3.6.4
Mako==1.0.6
MarkupSafe==0.23
netaddr==0.7.18
passlib==1.6.5
Pillow==3.4.2
privacyIDEA==2.16
privacyideaadm==2.15
psycopg2==2.6.2
pyasn1==0.1.9
pycparser==2.17
pycrypto==2.6.1
Pygments==2.1.3
PyGreSQL==5.0.2
PyJWT==1.4.2
PyKCS11==1.3.3
PyMySQL==0.7.9
pyOpenSSL==16.2.0
pyrad==2.0
pysqlite==2.8.3
python-editor==1.0.1
python-gnupg==0.3.9
pyusb==1.0.0
PyYAML==3.12
qrcode==5.3
requests==2.12.0
six==1.10.0
SQLAlchemy==1.1.4
sqlsoup==0.9.1
uWSGI==2.0.14
Werkzeug==0.11.11

I triggered the crash with the ‘Test LDAP Resolver’ button in the
resolver setup page.
Some users have token assigned.

I have waited for like 10 mins, and the server still timeout (504)
(even after the connection to LDAP is restored)
Restarted uwsgi fix the issue (our uwsgi config does not recycle
the worker(s), and we plan to tune this in the future)


Please read the blog post about getting help
https://www.privacyidea.org/getting-help/.

For professional services and consultancy regarding two factor
authentication please visit
https://netknights.it/en/leistungen/one-time-services/

In an enterprise environment you should get a SERVICE LEVEL AGREEMENT
which suites your needs for SECURITY, AVAILABILITY and LIABILITY:
https://netknights.it/en/leistungen/service-level-agreements/

You received this message because you are subscribed to a topic in
the Google Groups “privacyidea” group.
To unsubscribe from this topic, visit https://groups.google.com/d/top
ic/privacyidea/aS_dG1uXpwo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to p
rivacyidea+unsubscribe@googlegroups.com.
To post to this group, send email to privacyidea@googlegroups.com.
Visit this group at https://groups.google.com/group/privacyidea.
To view this discussion on the web visit https://groups.google.com/d/
msgid/privacyidea/ea6a79d6-b00b-4e5b-ac34-
9588c8e05491%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Cornelius Kölbel
@cornelinux
+49 151 2960 1417

NetKnights GmbH
http://www.netknights.it
Landgraf-Karl-Str. 19, 34131 Kassel, Germany
Tel: +49 561 3166797, Fax: +49 561 3166798

Amtsgericht Kassel, HRB 16405
Geschäftsführer: Cornelius Kölbel

signature.asc (819 Bytes)