LDAP health check failed 难道没有人遇到这样的问题吗?!!

Spring Boot集成报错及解决办法
博客提到遇到报错但不影响启动的问题,网上类似问题是Spring Boot集成Elasticsearch报错Health check failed,解决办法是在配置文件中增加配置关闭安全检查,最终问题得到解决。
2020-11-18 16:22:37.614  WARN 40736 --- [on(4)-127.0.0.1] o.s.b.actuate.ldap.LdapHealthIndicator   : LDAP health check failed

java.lang.NullPointerException: null
	at java.util.Hashtable.put(Hashtable.java:459) ~[na:1.8.0_40]
	at org.springframework.ldap.core.support.SimpleDirContextAuthenticationStrategy.setupEnvironment(SimpleDirContextAuthenticationStrategy.java:42) ~[spring-ldap-core-2.3.2.RELEASE.jar:2.3.2.RELEASE]
	at org.springframework.ldap.core.support.AbstractContextSource.setupAuthenticatedEnvironment(AbstractContextSource.java:194) ~[spring-ldap-core-2.3.2.RELEASE.jar:2.3.2.RELEASE]
	at org.springframework.ldap.core.support.AbstractContextSource.getAuthenticatedEnv(AbstractContextSource.java:582) ~[spring-ldap-core-2.3.2.RELEASE.jar:2.3.2.RELEASE]
	at org.springframework.ldap.core.support.AbstractContextSource.doGetContext(AbstractContextSource.java:134) ~[spring-ldap-core-2.3.2.RELEASE.jar:2.3.2.RELEASE]
	at org.springframework.ldap.core.support.AbstractContextSource.getReadOnlyContext(AbstractContextSource.java:158) ~[spring-ldap-core-2.3.2.RELEASE.jar:2.3.2.RELEASE]
	at org.springframework.ldap.core.LdapTemplate.executeReadOnly(LdapTemplate.java:802) ~[spring-ldap-core-2.3.2.RELEASE.jar:2.3.2.RELEASE]
	at org.springframework.boot.actuate.ldap.LdapHealthIndicator.doHealthCheck(LdapHealthIndicator.java:50) ~[spring-boot-actuator-2.1.1.RELEASE.jar:2.1.1.RELEASE]
	at org.springframework.boot.actuate.health.AbstractHealthIndicator.health(AbstractHealthIndicator.java:84) ~[spring-boot-actuator-2.1.1.RELEASE.jar:2.1.1.RELEASE]
	at org.springframework.boot.actuate.health.CompositeHealthIndicator.health(CompositeHealthIndicator.java:98) [spring-boot-actuator-2.1.1.RELEASE.jar:2.1.1.RELEASE]
	at org.springframework.boot.actuate.health.HealthEndpoint.health(HealthEndpoint.java:50) [spring-boot-actuator-2.1.1.RELEASE.jar:2.1.1.RELEASE]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0_40]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:1.8.0_40]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_40]
	at java.lang.reflect.Method.invoke(Method.java:497) ~[na:1.8.0_40]
	at org.springframework.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:246) [spring-core-5.1.3.RELEASE.jar:5.1.3.RELEASE]
	at org.springframework.boot.actuate.endpoint.invoke.reflect.ReflectiveOperationInvoker.invoke(ReflectiveOperationInvoker.java:76) [spring-boot-actuator-2.1.1.RELEASE.jar:2.1.1.RELEASE]
	at org.springframework.boot.actuate.endpoint.annotation.AbstractDiscoveredOperation.invoke(AbstractDiscoveredOperation.java:61) [spring-boot-actuator-2.1.1.RELEASE.jar:2.1.1.RELEASE]
	at org.springframework.boot.actuate.endpoint.jmx.EndpointMBean.invoke(EndpointMBean.java:126) [spring-boot-actuator-2.1.1.RELEASE.jar:2.1.1.RELEASE]
	at org.springframework.boot.actuate.endpoint.jmx.EndpointMBean.invoke(EndpointMBean.java:99) [spring-boot-actuator-2.1.1.RELEASE.jar:2.1.1.RELEASE]
	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) [na:1.8.0_40]
	at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801) [na:1.8.0_40]
	at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1466) [na:1.8.0_40]
	at javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:76) [na:1.8.0_40]
	at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1307) [na:1.8.0_40]
	at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1399) [na:1.8.0_40]
	at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:828) [na:1.8.0_40]
	at sun.reflect.GeneratedMethodAccessor100.invoke(Unknown Source) ~[na:na]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_40]
	at java.lang.reflect.Method.invoke(Method.java:497) ~[na:1.8.0_40]
	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:323) [na:1.8.0_40]
	at sun.rmi.transport.Transport$1.run(Transport.java:200) [na:1.8.0_40]
	at sun.rmi.transport.Transport$1.run(Transport.java:197) [na:1.8.0_40]
	at java.security.AccessController.doPrivileged(Native Method) [na:1.8.0_40]
	at sun.rmi.transport.Transport.serviceCall(Transport.java:196) [na:1.8.0_40]
	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568) [na:1.8.0_40]
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826) [na:1.8.0_40]
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$254(TCPTransport.java:683) [na:1.8.0_40]
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$$Lambda$5/1266146250.run(Unknown Source) [na:1.8.0_40]
	at java.security.AccessController.doPrivileged(Native Method) [na:1.8.0_40]
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682) [na:1.8.0_40]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_40]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_40]
	at java.lang.Thread.run(Thread.java:745) [na:1.8.0_40]

上面就是错误日志,报错但是不影响启动,非常烦恼。

网上搜到类似的问题是 springBoot集成Elasticsearch 报错 Health check failed

解决方法也是类似,在配置文件中增加一个配置把安全检查关调!

management:
  health:
    ldap:
      enabled: false

或者说是

management.health.ldap.enabled=false

先记到这 问题是解决了 

在 Django 中,通过 LDAP 认证创建用户与通过 Admin 界面手动创建用户的方式在本质上是不同的,尽管最终都会在 Django 的用户模型中生成一个用户记录。 ### 通过 LDAP 创建用户 当使用 `django-auth-ldap` 模块进行 LDAP 认证时,用户信息是从 LDAP 服务器中读取的,并根据配置的规则映射到 Django 的用户模型中。具体过程如下: - 用户通过登录界面输入用户名和密码。 - Django 使用 `django-auth-ldap` 模块将凭证提交到 LDAP 服务器进行验证。 - 如果验证成功,则根据 LDAP 中的用户信息在 Django 数据库中创建或更新一个用户记录。 - 这些用户通常被称为“外部用户”,因为它们的源数据来自 LDAP 服务器,而不是 Django 的本地数据库。 - 用户的权限和组信息也可以通过 LDAP 同步到 Django 中,具体取决于配置 [^2]。 ### 通过 Admin 创建用户 Django Admin 界面允许管理员手动创建用户。这种方式是完全基于 Django 的本地数据库的,与外部认证系统无关。具体特点包括: - 用户信息直接存储在 Django 的数据库中。 - 用户密码由 Django 管理,并使用 Django 提供的密码哈希机制进行加密。 - 用户的权限、组和超级用户状态可以直接在 Admin 界面中设置。 - 这些用户是“本地用户”,与 LDAP 无关。 ### 一致性比较 尽管两种方式最终都会在 `auth_user` 表中生成一条记录,但它们在以下方面存在显著差异: | 特性 | LDAP 创建用户 | Admin 创建用户 | |------|----------------|----------------| | 用户来源 | LDAP 服务器 | Django 数据库 | | 密码管理 | 由 LDAP 服务器管理 | 由 Django 管理 | | 权限同步 | 可通过配置同步 LDAP 组权限 | 手动在 Admin 中设置 | | 用户生命周期 | 取决于 LDAP 认证 | 由 Django 控制 | | 超级用户权限 | 需要特殊配置才能授予 | 可直接在 Admin 中设置 | 因此,虽然两者最终都会在 Django 中生成一个用户对象,但它们的来源、管理方式以及权限机制存在本质区别。 ### 相关代码示例 以下是一个典型的 `django-auth-ldap` 配置示例,用于从 LDAP 创建用户: ```python import ldap from django_auth_ldap.config import LDAPSearch, GroupOfNamesType AUTHENTICATION_BACKENDS = ( 'django_auth_ldap.backend.LDAPBackend', 'django.contrib.auth.backends.ModelBackend', ) AUTH_LDAP_SERVER_URI = "ldap://eric_ldap.oschina.com" AUTH_LDAP_BIND_DN = "cn=admin,dc=example,dc=com" AUTH_LDAP_BIND_PASSWORD = "your_ldap_password" AUTH_LDAP_USER_SEARCH = LDAPSearch( "ou=users,dc=example,dc=com", ldap.SCOPE_SUBTREE, "(uid=%(user)s)" ) AUTH_LDAP_GROUP_SEARCH = LDAPSearch( "ou=groups,dc=example,dc=com", ldap.SCOPE_SUBTREE, "(objectClass=groupOfNames)" ) AUTH_LDAP_GROUP_TYPE = GroupOfNamesType() AUTH_LDAP_USER_ATTR_MAP = { "first_name": "givenName", "last_name": "sn", "email": "mail" } AUTH_LDAP_PROFILE_ATTR_MAP = { "employee_number": "employeeNumber" } AUTH_LDAP_DEFAULT_SEPERMISSIONS = True ``` ###
评论 2
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

天天

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值