-
Bug
-
Resolution: Done
-
Normal
-
None
-
4.10
-
Quality / Stability / Reliability
-
False
-
-
1
-
None
-
None
-
None
-
None
-
None
-
None
-
None
-
None
-
None
-
None
-
None
-
None
-
None
Description of problem:
The oauth/cluster object configuration not respected, even after setting non-secure ldap URL, users are getting logged in with secure LDAP
Version-Release number of selected component (if applicable):
4.10
How reproducible:
100%
Steps to Reproduce:
1. Create a ConfigMap containing the IdM certificate to trust:
~~~
oc create configmap ca-config-map -n openshift-config --from-file=ca.crt
~~~
2. Configure the oauth/cluster object with configuration like below:
~~~
- name: ldapidp
mappingMethod: claim
type: LDAP
ldap:
attributes:
id:
- dn
email:
- mail
name:
- cn
preferredUsername:
- uid
bindDN: "uid=admin,cn=users,cn=accounts,dc=ocp4,dc=example,dc=com"
bindPassword:
name: ldap-secret
ca:
name: ca-config-map
insecure: false
url: "ldap://idm.ocp4.example.com:389/cn=users,cn=accounts,dc=ocp4,dc=example,dc=com?uid"
oc apply -f ldap-cr.yml
~~~
3. Login with the ldap user
~~~
oc login -u openshift-user -p openshift-user
Login successful.
You don't have any projects. You can try to create a new project, by running oc new-project <projectname>
~~~
Actual results:
The user logged in using secure LDAP.
Expected results:
The LDAP login should fail as the LDAP url setup in oauth/cluster is defined with port 389 which is not being connected
Additional info:
Based on the oauth/cluster object configuration anyone looking at will think that it is configured to connect via non-secure port, but this is not correct. It is using secure port 636 to query LDAP and this is creating confusion. This type of configuration should be invalidated at first place if the customer is setting `insecure: false` and using non-secure ldap url.