Spring应用程序:连接到AD代理-OpenLDAP,使dnPrettyNormal接受user@domain.com格式?
我尝试在SpringMVC应用程序中验证用户。我的域内有一个Active Directory服务器,但我的web服务器在域外,因此我不得不建立一个OpenLDAP代理服务器 首先,我已成功尝试在我的域内建立连接,因此应用程序工作正常,并进行身份验证。一切都很好。。。但是 在阅读了数百个网站(由于新的cn=conf配置-而不是slap.conf,这是我很难了解的,因为大多数网站都描述了不推荐的配置)和论坛之后,我终于用ldap后端配置了代理服务器,使其像代理一样工作。并非没有任何问题-它在调用ldapsearch后挂起,但仍然返回结果 问题是,用于我的OpenLDAP配置的ldapsearch不接受带有user@domain.com符号只能接受。。。日志文件显示: 11月13日14:24:52 ip-10-0-0-121 slapd[19149]:conn=1001 op=0 do_bind 11月13日14:24:52 ip-10-0-0-121 slapd[19149]:>>>dnPrettyNormal: 11月13日14:24:52 ip-10-0-0-121 slapd[19149]:conn=1001 op=0 do_bind:无效dn(user@domain.com) 11月13日14:24:52 ip-10-0-0-121 slapd[19149]:发送ldap结果:conn=1001 op=0 p=3 因此>>dnPrettyNormal:是不可接受的,但它是从我的spring应用程序生成的 我认为有两种解决方法:Spring应用程序:连接到AD代理-OpenLDAP,使dnPrettyNormal接受user@domain.com格式?,spring,configuration,active-directory,ldap,openldap,Spring,Configuration,Active Directory,Ldap,Openldap,我尝试在SpringMVC应用程序中验证用户。我的域内有一个Active Directory服务器,但我的web服务器在域外,因此我不得不建立一个OpenLDAP代理服务器 首先,我已成功尝试在我的域内建立连接,因此应用程序工作正常,并进行身份验证。一切都很好。。。但是 在阅读了数百个网站(由于新的cn=conf配置-而不是slap.conf,这是我很难了解的,因为大多数网站都描述了不推荐的配置)和论坛之后,我终于用ldap后端配置了代理服务器,使其像代理一样工作。并非没有任何问题-它在调用ld
<authentication-manager>
<authentication-provider ref="ldapActiveDirectoryAuthProvider" />
</authentication-manager>
<beans:bean id="ldapActiveDirectoryAuthProvider"
class="org.springframework.security.ldap.authentication.ad.ActiveDirectoryLdapAuthenticationProvider">
<beans:constructor-arg value="domain.com" />
<beans:constructor-arg value="ldap://xx.xx.xx.xx:389/" /> <!--fake IP-->
<beans:property name="authoritiesMapper" ref="grantedAuthoritiesMapper" />
<beans:property name="useAuthenticationRequestCredentials"
value="true" />
<beans:property name="convertSubErrorCodesToExceptions"
value="true" />
</beans:bean>
<beans:bean id="grantedAuthoritiesMapper"
class="com.xxx.ActiveDirectoryGrantedAuthoritiesMapper" />
你能告诉我如何解决我的问题吗
解决方案/更新: 我已成功设置了连接。现在我使用的是LdapAuthenticationProvider 而不是ActiveDirectoryLdapAuthenticationProvider
<authentication-manager>
<authentication-provider ref='ldapProvider' />
</authentication-manager>
<!-- This bean points at the embedded directory server created by the ldap-server
element above -->
<beans:bean id="contextSource"
class="org.springframework.security.ldap.DefaultSpringSecurityContextSource">
<beans:constructor-arg value="ldap://xx.xx.xx.xx:389/dc=domain,dc=com" />
<beans:property name="baseEnvironmentProperties">
<beans:map>
<beans:entry key="java.naming.referral" value="ignore" />
</beans:map>
</beans:property>
<beans:property name="userDn"
value="CN=user,OU=group,dc=domain,dc=com" />
<beans:property name="password" value="secret" />
</beans:bean>
<beans:bean id="ldapProvider"
class="org.springframework.security.ldap.authentication.LdapAuthenticationProvider">
<beans:constructor-arg>
<beans:bean
class="org.springframework.security.ldap.authentication.BindAuthenticator">
<beans:constructor-arg ref="contextSource" />
<beans:property name="userSearch">
<beans:bean id="userSearch"
class="org.springframework.security.ldap.search.FilterBasedLdapUserSearch">
<beans:constructor-arg index="0" value="" />
<beans:constructor-arg index="1"
value="(sAMAccountName={0})" />
<beans:constructor-arg index="2" ref="contextSource" />
<beans:property name="searchSubtree" value="true" />
</beans:bean>
</beans:property>
</beans:bean>
</beans:constructor-arg>
<beans:constructor-arg>
<beans:bean
class="org.springframework.security.ldap.userdetails.DefaultLdapAuthoritiesPopulator">
<beans:constructor-arg ref="contextSource" />
<beans:constructor-arg value="" />
<beans:property name="searchSubtree" value="true" />
<beans:property name="rolePrefix" value="ROLE_" />
<beans:property name="convertToUpperCase" value="true" />
<beans:property name="ignorePartialResultException"
value="true" />
</beans:bean>
</beans:constructor-arg>
字符串user@domain.com
不是有效的可分辨名称。A是以逗号分隔的相对可分辨名称(RDN)序列,每个RDN都是一个attributeType attributeValue断言,其形式为type=value
,其中type
是属性类型(OID或OID的别名,如mail
)<代码>邮件=user@domain.com,dc=domain,dc=com是有效的可分辨名称。请更正配置中的DN以使用有效字符串。问题与“@
”字符无关。是的,我知道。。。但我不知道如何强制Spring将真正的DN发送到OpenLDAP而不是user@domain.com哪个广告真的接受。不过还是要谢谢你:)