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.
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] dc1.domain1. ca ldap:// dc1.domain1. ca
url = ldap://
use_tls = true
…
»
For the other:
«
[identity]
driver = ldap
[assignment]
driver = ldap
[ldap] dc1.domain2. ca ldap:// dc2.domain2. ca domains/ domain2- caroot. pem
url = ldap://
query_scope = sub
use_tls = true
tls_cacertfile = /etc/keystone/
…
»
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: common. wsgi [req-c145506b- 69fc-4fc2- 9bad-76d77a79e3 ca - - - - -] POST http:// os-controller. lab.netdirect. ca:5000/ v3/auth/ tokens common. wsgi [req-c145506b- 69fc-4fc2- 9bad-76d77a79e3 ca - - - - -] {'info': "TLS error -8179:Peer's Certificate issuer is not recognized.", 'desc': 'Connect error'} common. wsgi Traceback (most recent call last): common. wsgi File "/usr/lib/ python2. 7/site- packages/ ldappool/ __init_ _.py", line 224, in _create_connector common. wsgi raise BackendError( str(exc) , backend=conn) common. wsgi BackendError: {'info': "TLS error -8179:Peer's Certificate issuer is not recognized.", 'desc': 'Connect error'}
«
2016-11-25 09:54:06.699 27879 INFO keystone.
2016-11-25 09:54:07.147 27879 ERROR keystone.
2016-11-25 09:54:07.147 27879 ERROR keystone.
…
2016-11-25 09:54:07.147 27879 ERROR keystone.
2016-11-25 09:54:07.147 27879 ERROR keystone.
2016-11-25 09:54:07.147 27879 ERROR keystone.
»
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.