ServiceUnavailableException ONLY on SSL 636, not 389

[wstiles]

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?

Thanks!


context stuff:

	<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>

[rasky]

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.

[wstiles]

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.