Announcement Announcement Module
No announcement yet.
ServiceUnavailableException ONLY on SSL 636, not 389 Page Title Module
Move Remove Collapse
Conversation Detail Module
  • 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:

    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?


    context stuff:

    	<bean id="contextSource" class="">
    		<!--<property name="url" value="ldap://" />-->
    		<property name="url" value="ldap:// .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 id="ldapTemplate" class="org.springframework.ldap.core.LdapTemplate">
    		<constructor-arg ref="contextSource" />
    	<bean id="ldapDao" class="org.stjude.cris.dao.LdapDao">
    		<property name="ldapTemplate" ref="ldapTemplate" />

  • #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.


    • #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.