yahoo-eng-team team mailing list archive

[MikeyB <michael@xxxxxxxxxxxxxxx>]

Public bug reported:

Environment:
Centos 7 using the OpenStack Mitaka release

RPMS from:
http://mirror.centos.org/centos/7/cloud/$basearch/openstack-mitaka/

openstack-keystone-9.2.0-1.el7.noarch

—————

I have a multidomain configuration with multiple AD backends in
keystone.

For one of the AD configurations I've configured a custom tls_cacertfile
as follows:

«
[identity]
driver = ldap

[assignment]
driver = ldap

[ldap]
url                      = ldap://dc1.domain1.ca ldap://dc1.domain1.ca
use_tls                  = true
…
»

For the other:

«
[identity]
driver = ldap

[assignment]
driver = ldap

[ldap]
url                      = ldap://dc1.domain2.ca ldap://dc2.domain2.ca
query_scope              = sub
use_tls                  = true
tls_cacertfile           = /etc/keystone/domains/domain2-caroot.pem
…
»

What I've observed is when logging in to domain2 I will get very
inconsistent behaviour:

* sometimes fails: "Unable to retrieve authorized projects."
* sometimes fails: "An error occurred authenticating. Please try again later."
* sometimes fails: "Unable to authenticate to any available projects."
* sometimes fails: "Invalid credentials."
* sometimes succeeds

Example traceback from keystone log:
«
2016-11-25 09:54:06.699 27879 INFO keystone.common.wsgi [req-c145506b-69fc-4fc2-9bad-76d77a79e3ca - - - - -] POST http://os-controller.lab.netdirect.ca:5000/v3/auth/tokens
2016-11-25 09:54:07.147 27879 ERROR keystone.common.wsgi [req-c145506b-69fc-4fc2-9bad-76d77a79e3ca - - - - -] {'info': "TLS error -8179:Peer's Certificate issuer is not recognized.", 'desc': 'Connect error'}
2016-11-25 09:54:07.147 27879 ERROR keystone.common.wsgi Traceback (most recent call last):
…
2016-11-25 09:54:07.147 27879 ERROR keystone.common.wsgi   File "/usr/lib/python2.7/site-packages/ldappool/__init__.py", line 224, in _create_connector
2016-11-25 09:54:07.147 27879 ERROR keystone.common.wsgi     raise BackendError(str(exc), backend=conn)
2016-11-25 09:54:07.147 27879 ERROR keystone.common.wsgi BackendError: {'info': "TLS error -8179:Peer's Certificate issuer is not recognized.", 'desc': 'Connect error'}
»

I've also tried putting a merged tls_cacertfile containing the system
default ca roots and the domain2-specific ca root. That felt like it
improved but did not fix the problem.

The workaround is putting the merged cacertfile into BOTH domain
configurations, which should not be necessary. After doing so I haven't
had any trouble.

** Affects: keystone
     Importance: Undecided
         Status: New

** Description changed:

+ Environment:
+ Centos 7 using the OpenStack Mitaka release
+ 
+ RPMS from:
+ http://mirror.centos.org/centos/7/cloud/$basearch/openstack-mitaka/
+ 
+ openstack-keystone-9.2.0-1.el7.noarch
+ 
+ —————
+ 
  I have a multidomain configuration with multiple AD backends in
  keystone.
  
  For one of the AD configurations I've configured a custom tls_cacertfile
  as follows:
  
  «
  [identity]
  driver = ldap
  
  [assignment]
  driver = ldap
  
  [ldap]
  url                      = ldap://dc1.domain1.ca ldap://dc1.domain1.ca
  use_tls                  = true
  …
  »
  
  For the other:
  
  «
  [identity]
  driver = ldap
  
  [assignment]
  driver = ldap
  
  [ldap]
  url                      = ldap://dc1.domain2.ca ldap://dc2.domain2.ca
  query_scope              = sub
  use_tls                  = true
  tls_cacertfile           = /etc/keystone/domains/domain2-caroot.pem
  …
  »
  
  What I've observed is when logging in to domain2 I will get very
  inconsistent behaviour:
  
  * sometimes fails: "Unable to retrieve authorized projects."
  * sometimes fails: "An error occurred authenticating. Please try again later."
  * sometimes fails: "Unable to authenticate to any available projects."
  * sometimes fails: "Invalid credentials."
  * sometimes succeeds
  
  Example traceback from keystone log:
  «
  2016-11-25 09:54:06.699 27879 INFO keystone.common.wsgi [req-c145506b-69fc-4fc2-9bad-76d77a79e3ca - - - - -] POST http://os-controller.lab.netdirect.ca:5000/v3/auth/tokens
  2016-11-25 09:54:07.147 27879 ERROR keystone.common.wsgi [req-c145506b-69fc-4fc2-9bad-76d77a79e3ca - - - - -] {'info': "TLS error -8179:Peer's Certificate issuer is not recognized.", 'desc': 'Connect error'}
  2016-11-25 09:54:07.147 27879 ERROR keystone.common.wsgi Traceback (most recent call last):
  …
  2016-11-25 09:54:07.147 27879 ERROR keystone.common.wsgi   File "/usr/lib/python2.7/site-packages/ldappool/__init__.py", line 224, in _create_connector
  2016-11-25 09:54:07.147 27879 ERROR keystone.common.wsgi     raise BackendError(str(exc), backend=conn)
  2016-11-25 09:54:07.147 27879 ERROR keystone.common.wsgi BackendError: {'info': "TLS error -8179:Peer's Certificate issuer is not recognized.", 'desc': 'Connect error'}
  »
  
  I've also tried putting a merged tls_cacertfile containing the system
  default ca roots and the domain2-specific ca root. That felt like it
  improved but did not fix the problem.
  
  The workaround is putting the merged cacertfile into BOTH domain
  configurations, which should not be necessary. After doing so I haven't
  had any trouble.

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1644862

Title:
  domain ldap tls_cacertfile "forgotten" in multidomain configuration

Status in OpenStack Identity (keystone):
  New

Bug description:
  Environment:
  Centos 7 using the OpenStack Mitaka release

  RPMS from:
  http://mirror.centos.org/centos/7/cloud/$basearch/openstack-mitaka/

  openstack-keystone-9.2.0-1.el7.noarch

  —————

  I have a multidomain configuration with multiple AD backends in
  keystone.

  For one of the AD configurations I've configured a custom
  tls_cacertfile as follows:

  «
  [identity]
  driver = ldap

  [assignment]
  driver = ldap

  [ldap]
  url                      = ldap://dc1.domain1.ca ldap://dc1.domain1.ca
  use_tls                  = true
  …
  »

  For the other:

  «
  [identity]
  driver = ldap

  [assignment]
  driver = ldap

  [ldap]
  url                      = ldap://dc1.domain2.ca ldap://dc2.domain2.ca
  query_scope              = sub
  use_tls                  = true
  tls_cacertfile           = /etc/keystone/domains/domain2-caroot.pem
  …
  »

  What I've observed is when logging in to domain2 I will get very
  inconsistent behaviour:

  * sometimes fails: "Unable to retrieve authorized projects."
  * sometimes fails: "An error occurred authenticating. Please try again later."
  * sometimes fails: "Unable to authenticate to any available projects."
  * sometimes fails: "Invalid credentials."
  * sometimes succeeds

  Example traceback from keystone log:
  «
  2016-11-25 09:54:06.699 27879 INFO keystone.common.wsgi [req-c145506b-69fc-4fc2-9bad-76d77a79e3ca - - - - -] POST http://os-controller.lab.netdirect.ca:5000/v3/auth/tokens
  2016-11-25 09:54:07.147 27879 ERROR keystone.common.wsgi [req-c145506b-69fc-4fc2-9bad-76d77a79e3ca - - - - -] {'info': "TLS error -8179:Peer's Certificate issuer is not recognized.", 'desc': 'Connect error'}
  2016-11-25 09:54:07.147 27879 ERROR keystone.common.wsgi Traceback (most recent call last):
  …
  2016-11-25 09:54:07.147 27879 ERROR keystone.common.wsgi   File "/usr/lib/python2.7/site-packages/ldappool/__init__.py", line 224, in _create_connector
  2016-11-25 09:54:07.147 27879 ERROR keystone.common.wsgi     raise BackendError(str(exc), backend=conn)
  2016-11-25 09:54:07.147 27879 ERROR keystone.common.wsgi BackendError: {'info': "TLS error -8179:Peer's Certificate issuer is not recognized.", 'desc': 'Connect error'}
  »

  I've also tried putting a merged tls_cacertfile containing the system
  default ca roots and the domain2-specific ca root. That felt like it
  improved but did not fix the problem.

  The workaround is putting the merged cacertfile into BOTH domain
  configurations, which should not be necessary. After doing so I
  haven't had any trouble.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1644862/+subscriptions