The OpenLDAP that Kubesphere accesses does not take effect

[Nacho-A]

KS 3.3.0 OPENLDAP lastest It's not an LDAP problem,Other systems can log in as LDAP users Here is my configuration:

spec:
 authentication:
    jwtSecret: ''
    maximumClockSkew: 10s
    multipleLogin: true
    oauthOptions:
      accessTokenMaxAge: 1h
      accessTokenInactivityTimeout: 30m
      identityProviders:
      - name: LDAP
        type: LDAPIdentityProvider
        mappingMethod: auto
        provider:
          host: xxxxxx:389
          managerDN: 'cn=admin,dc=xxx,dc=com'
          managerPassword: xxx
          userSearchBase: 'dc=xxx,dc=com'
          loginAttribute: cn
          mailAttribute: Email

[Nacho-A]

完全一样的配置，把KS集群版本降级到3.2.1就可以了，希望尽快解决

[wansir]

There have been no changes since v3.2.1. The logs of ks-apiserver are useful, could you provide more information about this?

[Nacho-A]

[Nacho-A]

Right now I am using two KS3.3 clusters and the LDAP configuration is invalid Demoting one of the clusters to 3.2.1 takes effect The LDAP configuration has never changed

[whensuc]

me too

[wansir]

/assign @zhou1203 @wenxin-01

[Nacho-A]

Does anyone have a solution? It's urgent

[Nacho-A]

@zhou1203 @wenxin-01

[wenxinll]

I used the same configuration to succeed in ks3.2.1 and ks3.3.1, it is recommended to restart the server and try again. @a52074137

authentication:
    jwtSecret: ''
    maximumClockSkew: 10s
    multipleLogin: true
    oauthOptions:
      accessTokenInactivityTimeout: 30m
      accessTokenMaxAge: 1h
      identityProviders:
        - mappingMethod: auto
          name: LDAP
          provider:
            host: 'xxxxx:32028'
            loginAttribute: uid
            mailAttribute: mail
            managerDN: 'cn=admin,dc=test,dc=test'
            managerPassword: '123456'
            userSearchBase: 'ou=kubesphere,dc=test,dc=test'
          type: LDAPIdentityProvider

[Nacho-A]

Do you mean restart KS-Installer? It will restart automatically after each update. I have also manually restarted, but it is invalid. There are also several people in the community and wechat group who have the same situation as me, It's not just about what happened to me

[Nacho-A]

@wenxin-01 ks3.3.1? or ks 3.3.0

[wenxinll]

No, restart server. I tested and found that after modifying the configuration, ldap did not take effect. But after restarting the server, ldap took effect. No specific reason has been found for the time being, maybe you can try this method first.

[Nacho-A]

Restart the control node or restart the worker node together

[Nacho-A]

I restarted the workstation where KS-Installer is located, but it still doesn't work. I restarted the server on all the nodes, and it now works

[wenxinll]

Ok, you can be solved temporarily with this method, and I will continue to look for the specific reason. Thanks for the feedback.

[Nacho-A]

But now the mail property is not active，It is valid on the KS3.2.1 cluster

[Nacho-A]

@wenxin-01

[wenxinll]

It's ok in my test, you can change 'Email' to 'mail'. @a52074137

[Nacho-A]

I've tried both mail and Email, but I can't get the value

[Nacho-A]

Do we have to restart the server again

[Nacho-A]

The modification takes effect only after you restart the server. However, a new problem occurred, and Jenkins failed to start. I changed the name of LDAP configuration in Ks-install to LDAP-1, and the Jenkins component of the system failed to start, and the original configuration cannot be deleted or modified

[Nacho-A]

2022-09-09 08:19:04.419+0000 [id=29]	SEVERE	jenkins.InitReactorRunner$1#onTaskFailed: Failed ConfigurationAsCode.init

 java.lang.IllegalArgumentException: Each server configuration must have a unique setup. At least two configurations have the same server(s), root DN, User search base and User search filter.

 	at hudson.security.LDAPSecurityRealm.<init>(LDAPSecurityRealm.java:507)

 Caused: java.lang.reflect.InvocationTargetException

 	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

 	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)

 	at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)

 	at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)

 	at io.jenkins.plugins.casc.impl.configurators.DataBoundConfigurator.tryConstructor(DataBoundConfigurator.java:173)

 Caused: io.jenkins.plugins.casc.ConfiguratorException: ldap: Failed to construct instance of class hudson.security.LDAPSecurityRealm.

  Constructor: public hudson.security.LDAPSecurityRealm(java.util.List,boolean,hudson.security.LDAPSecurityRealm$CacheConfiguration,jenkins.model.IdStrategy,jenkins.model.IdStrategy).

  Arguments: [java.util.ArrayList, java.lang.Boolean, null, null, null].

  Expected Parameters: configurations java.util.List<jenkins.security.plugins.ldap.LDAPConfiguration>, disableMailAddressResolver boolean, cache hudson.security.LDAPSecurityRealm$CacheConfiguration, userIdStrategy jenkins.model.IdStrategy, groupIdStrategy jenkins.model.IdStrategy

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Any further update will cause the issue/pull request to no longer be considered stale. Thank you for your contributions.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Any further update will cause the issue/pull request to no longer be considered stale. Thank you for your contributions.

[stale[bot]]

This issue is being automatically closed due to inactivity.

[wansir]

/reopen

[ks-ci-bot]

@wansir: Reopened this issue.

In response to this:

/reopen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.