Announcement Announcement Module
Collapse
No announcement yet.
ServiceUnavailableException ONLY on SSL 636, not 389 Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • ServiceUnavailableException ONLY on SSL 636, not 389

    All is well when I try using 389 on the "insecure" server, but when I switch my config over to the secure server I get ServiceUnavailableException. I am bining under an "application" ldap username, and sending a standard username and password in an ldap:

    Code:
    AndFilter filter = new AndFilter();
            filter.and( new EqualsFilter( "objectclass", "person" ) ).and( new EqualsFilter( "sAMAccountName", username ) );
            boolean answer = false;
            answer = ldapTemplate.authenticate( DistinguishedName.EMPTY_PATH, filter.toString(), password );
    This is an AD server. Ok, the dumb question... I have done nothing with any certificates, keystores, etc. Is this the problem? Do I need a certificate only for the inital bind if I DON'T have an "application" username in ldap to bind with before calling authenticate?

    Thanks!


    context stuff:

    Code:
    	<bean id="contextSource" class="org.springframework.ldap.core.support.LdapContextSource">
    		<!--<property name="url" value="ldap://ldapauth.ldap.company.org:389" />-->
    		<property name="url" value="ldap://secureserver.ldap.company .orgl:636" />
    		<property name="base" value="OU=Departments,OU=SystemUsers,DC=myinfo1,DC=myinfo2,DC=local" />
    		<property name="userDn" value="CN=LDAP_MYAPPUSER,OU=Service Accounts,OU=SystemUsers,DC=myinfo1,DC=mynifo2,DC=local" />
     		<property name="password" value="MyPass" />
    	</bean>
    	<bean id="ldapTemplate" class="org.springframework.ldap.core.LdapTemplate">
    		<constructor-arg ref="contextSource" />
    	</bean>
    	<bean id="ldapDao" class="org.stjude.cris.dao.LdapDao">
    		<property name="ldapTemplate" ref="ldapTemplate" />
    	</bean>

  • #2
    I'm afraid I don't quite understand your question. Either way, a full stack trace would be helpful to help me point you in the right direction.

    Comment


    • #3
      Cannot reproduce now

      which I suppose it good news. I am not certain, but in retyping the ldap url, I think I might have started with a 'ldap' insead of a 'ldaps' even though using port 636. With a corrected ldap url, connections were made properly and the authenticate method did its job.

      Comment

      Working...
      X