LDAP over SSL for Solaris 9 / Solaris 10

I have successfully configured Solaris-10 clients to use Windows 2003 R2 Active Directory for LDAP authentication over SSL. However, my production environment is still running on Solaris-9. I am able to make Kerberos and ldapsearch working on Solaris-9, but I am still NOT able to use PuTTY to make authentication with AD.
I reviewed all my steps that I configured on Solaris-10, but somewhat I could not make it work on Solaris-9. If anybody sucessfully deployed on Solaris-9, please advices! Any helps greatly appreciated.
Here are what I got so far on Solaris-9
=======================================================
KERBEROS
=======================================================
#getent passwd aduser
aduser:1000:1000:aduser:/export/home/aduser:/bin/sh
#kinit [email protected]
Password for [email protected]:
#klist
Ticket cache: /tmp/krb5cc_0
Default principal: [email protected]
Valid starting Expires Service principal
Fri Jan 04 17:22:34 2008 Sat Jan 05 03:22:34 2008 krbtgt/[email protected]
renew until Fri Jan 11 17:22:34 2008
=======================================================
LDAPSEARCH / SSL
=======================================================
#ldapsearch -v -h sundc1.consoto.com -p 636 -Z -P /var/ldap/cert8.db -D cn=administrator,cn=users,dc=consoto,dc=com -w - -b "dc=consoto,dc=com" -v -s base "objectclass=*"
Enter bind password:
ldapsearch: started Fri Jan 4 17:23:52 2008
LDAP Library Information -
Highest supported protocol version: 3
LDAP API revision: 2005
API vendor name: Sun Microsystems Inc.
Vendor-specific version: 5.08
LDAP API Extensions:
SERVER_SIDE_SORT (revision 1)
VIRTUAL_LIST_VIEW (revision 1)
PERSISTENT_SEARCH (revision 1)
PROXY_AUTHORIZATION (revision 1)
X_LDERRNO (revision 1)
X_MEMCACHE (revision 1)
X_IO_FUNCTIONS (revision 1)
X_EXTIO_FUNCTIONS (revision 1)
X_DNS_FUNCTIONS (revision 1)
X_MEMALLOC_FUNCTIONS (revision 1)
X_THREAD_FUNCTIONS (revision 1)
X_EXTHREAD_FUNCTIONS (revision 1)
X_GETLANGVALUES (revision 1)
X_CLIENT_SIDE_SORT (revision 1)
X_URL_FUNCTIONS (revision 1)
X_FILTER_FUNCTIONS (revision 1)
ldap_init( sundc1.consoto.com, 636 )
ldaptool_getcertpath -- /var/ldap/cert8.db
ldaptool_getkeypath -- .
ldaptool_getdonglefilename -- (null)
filter pattern: objectclass=*
returning: ALL
filter is: (objectclass=*)
version: 1
dn: dc=consoto,dc=com
objectClass: top
objectClass: domain
objectClass: domainDNS
distinguishedName: DC=consoto,DC=com
instanceType: 5
whenCreated: 20071220204021.0Z
whenChanged: 20071226231851.0Z
subRefs: DC=ForestDnsZones,DC=consoto,DC=com
subRefs: DC=DomainDnsZones,DC=consoto,DC=com
subRefs: CN=Configuration,DC=consoto,DC=com
uSNCreated: 4098
uSNChanged: 16663
name: consoto
objectGUID:: bM0hWw8HKEOYCFN3yQ==
creationTime: 128426572605937500
forceLogoff: -9223372036854775808
lockoutDuration: -18000000000
lockOutObservationWindow: -18000000000
lockoutThreshold: 0
maxPwdAge: -37108517437440
minPwdAge: -864000000000
minPwdLength: 7
modifiedCountAtLastProm: 0
nextRid: 1003
pwdProperties: 1
pwdHistoryLength: 24
objectSid:: AQQAAAAAAAUAAYA4LaLGUspxVHsMP
serverState: 1
uASCompat: 1
modifiedCount: 129
auditingPolicy:: AAE=
nTMixedDomain: 0
rIDManagerReference: CN=RID Manager$,CN=System,DC=consoto,DC=com
fSMORoleOwner: CN=NTDS Settings,CN=SUNDC1,CN=Servers,CN=Default-First-Site-Nam e,CN=Sites,CN=Configuration,DC=consoto,DC=com
systemFlags: -1946157056
wellKnownObjects: B:32:6227F0AF1FC2410D8E3BB10615BB5B0F:CN=NTDS Quotas,DC=sunl
ab,DC=com
wellKnownObjects: B:32:F4BE92A4C777485E878E9421D53087DB:CN=Microsoft,CN=Progra
m Data,DC=consoto,DC=com
wellKnownObjects: B:32:09460C08AE1E4A4EA0F64AEE7DAA1E5A:CN=Program Data,DC=sun
lab,DC=com
wellKnownObjects: B:32:22B70C67D56E4EFB91E9300FCA3DC1AA:CN=ForeignSecurityPrin
cipals,DC=consoto,DC=com
wellKnownObjects: B:32:18E2EA80684F11D2B9AA00C04F79F805:CN=Deleted Objects,DC=
consoto,DC=com
wellKnownObjects: B:32:2FBAC1870ADE11D297C400C04FD8D5CD:CN=Infrastructure,DC=s
unlab,DC=com
wellKnownObjects: B:32:AB8153B7768811D1ADED00C04FD8D5CD:CN=LostAndFound,DC=sun
lab,DC=com
wellKnownObjects: B:32:AB1D30F3768811D1ADED00C04FD8D5CD:CN=System,DC=consoto,DC
=com
wellKnownObjects: B:32:A361B2FFFFD211D1AA4B00C04FD7D83A:OU=Domain Controllers,
DC=consoto,DC=com
wellKnownObjects: B:32:AA312825768811D1ADED00C04FD8D5CD:CN=Computers,DC=consoto
,DC=com
wellKnownObjects: B:32:A9D1CA15768811D1ADED00C04FD8D5CD:CN=Users,DC=consoto,DC=
com
objectCategory: CN=Domain-DNS,CN=Schema,CN=Configuration,DC=consoto,DC=com
isCriticalSystemObject: TRUE
gPLink: [LDAP://CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=Syste
m,DC=consoto,DC=com;0]
masteredBy: CN=NTDS Settings,CN=SUNDC1,CN=Servers,CN=Default-First-Site-Name,C
N=Sites,CN=Configuration,DC=consoto,DC=com
ms-DS-MachineAccountQuota: 10
msDS-Behavior-Version: 2
msDS-PerUserTrustQuota: 1
msDS-AllUsersTrustQuota: 1000
msDS-PerUserTrustTombstonesQuota: 10
msDs-masteredBy: CN=NTDS Settings,CN=SUNDC1,CN=Servers,CN=Default-First-Site-N
ame,CN=Sites,CN=Configuration,DC=consoto,DC=com
dc: consoto
1 matches
I am thinking about pam.conf file or ldapclient's configuration file, any suggestion?

I have now sat down and looked at your suggestion and I am pretty certain we can't implement it ... :( I was hoping it was just going to be configuration files that were copied (maybe a naive hope, but there you go!) This system is going to be deployed as a live service for a government agency so I do not think we can, in all good conscience, have binaries from two different OS releases residing on the same server as it will make the system nigh-on non-patchable.
Let's hope Sun have somethig constructive to say about our issue which, I am slowly beginning to think, is related to the password.
If I su to the test AD user we have whilst logged in as a root user (which does not, of course, prompt for a password) it all works nicely - home directory, shell, the id command gives all that is expected of uid and gid. Now, should I be in a as a non-root user and try the same I get prompted for a password and it all fails - despite me providing what should be the correct password.
If I do a getent for the user the returned data has a blank for the password field (as opposed to the usual x).
I think that somewhere, somehow, in the transmission of data that the password is getting a level of encryption that the AD is not setup to unravel. The packets are all encrypted through ldap (we are using tls simple) but what of the password within the packet? Does anything encrypt that first, and if so, does AD know how to decrypt it?

Similar Messages

LC + ActiveDirectory + LDAP over SSL = doesn't work

Hi,
I installed Active Directory Certificate Services. Now I want setup LDAP over SSL. Unfortunatelly it doesn't work. I pressed "Test" and always get "Invalid username or invalid password" (
German: "Ungültiger Benutzername oder ungültiges Kennwort"). I'm pretty sure username and password are fine (it worked before I installed Active Directory Certificate Services and used LDAP without SSL).
On server.log, I got this:
2011-11-12 00:51:28,202 INFO [com.adobe.idp.um.businesslogic.synch.LdapHelper] Following stacktrace is generated due to the Test LDAP Server Configuration action
javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1]
        at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3041)
        at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2987)
        at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2789)
        at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2703)
        at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:293)
        at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:175)
        at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:193)
        at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:136)
        at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:66)
        at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667)
        at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288)
        at javax.naming.InitialContext.init(InitialContext.java:223)
        at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:134)
        at com.adobe.idp.um.businesslogic.synch.LdapHelper.createContext(LdapHelper.java:663)
        at com.adobe.idp.um.businesslogic.synch.LdapHelper.testServerConfig(LdapHelper.java:682)
        at com.adobe.idp.um.ui.config.ConfigDirectoryEditAction.testServerSettings_onClick(ConfigDirectoryEditAction.java:215)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at com.cc.framework.adapter.struts.ActionUtil.handleFormAction(Unknown Source)
        at com.cc.framework.adapter.struts.FWAction.handleFormAction(Unknown Source)
        at com.cc.framework.adapter.struts.ActionUtil.execute(Unknown Source)
        at com.cc.framework.adapter.struts.FWAction.execute(Unknown Source)
        at com.cc.framework.adapter.struts.FWAction.execute(Unknown Source)
        at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431)
        at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236)
        at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
        at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at com.adobe.framework.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:173)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at com.adobe.idp.um.auth.filter.AuthenticationFilter.doFilter(AuthenticationFilter.java:154)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at com.adobe.idp.um.auth.filter.PortalSSOFilter.doFilter(PortalSSOFilter.java:91)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at com.adobe.idp.um.auth.filter.CSRFFilter.doFilter(CSRFFilter.java:41)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
        at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
        at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
        at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
        at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
        at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:543)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
        at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580)
        at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
        at java.lang.Thread.run(Thread.java:619)
Do you have some Idea?
cu Floh

I have not done it for Netscape yet but I have done it for Novell and JNDI.. Here is the settings for Novell
// Dynamically set JSSE as a security provider
Security.addProvider(new com.sun.net.ssl.internal.ssl.Provider());
// Dynamically set the property that JSSE uses to identify
// the keystore that holds trusted root certificates
System.setProperty("javax.net.ssl.trustStore", m_connectionData.getLocal("KeyStore").toString());
ssf = new LDAPJSSESecureSocketFactory();
// Set the socket factory as the default for all future connections
LDAPConnection.setSocketFactory(ssf);

LDAP over SSL

A hosted service wants to authenticate against our AD. They recommend using LDAPS.
What is best practice? Install a public certificate on a DC.
For instance on DC1.contoso.com. Then would I open up 443 on the firewall to that DC and allow from that IP? How would that affect other local LAN clients authenticating to that DC?

A hosted service wants to authenticate against our AD. They recommend using LDAPS.
What is best practice? Install a public certificate on a DC.
For instance on DC1.contoso.com. Then would I open up 443 on the firewall to that DC and allow from that IP? How would that affect other local LAN clients authenticating to that DC?
If its hosted services & if its supports ADAM/AD LDS, then its much safe to use them instead of RWDC or RODC. Enabling LDAP over SSL enhances the security of the information how information is transmitted when client tries to contact DC for the information(authentication/authorization).
Normally w/o LDAPs being configured in the environment, when client queries a DC in the domain, the information is transmitted in the plain text which ca be read by the hacker using tools available for free. The reason is simple the information on transit
is not encrypted, but enabling LDAP over SSL prevent the unencrypted queries & provide more security.
You can't simple implement LDAP over SSP, but it needs PKI infrastructure, planning & designing which is comprehensively listed into the document URL posted by Justin. You can also use ldap over SSL using AD LDS.
http://blogs.technet.com/b/pki/archive/2011/06/02/implementing-ldaps-ldap-over-ssl.aspx
Awinish Vishwakarma - MVP
My Blog: awinish.wordpress.com
Disclaimer This posting is provided AS-IS with no warranties/guarantees and confers no rights.

Trying to determine if LDAP over SSL is working using LDP.exe

Hi,
I just wanted to confirm that LDAP over SSL is working properly on our domain controller. When I connect using LDP.exe on my Windows 7 computer, I get the following output:
ld = ldap_sslinit("dc1.domain.com", 636, 1);
Error 0 = ldap_set_option(hLdap, LDAP_OPT_PROTOCOL_VERSION, 3);
Error 0 = ldap_connect(hLdap, NULL);
Error 0 = ldap_get_option(hLdap,LDAP_OPT_SSL,(void*)&lv);
Host supports SSL, SSL cipher strength = 128 bits
Established connection to dc1.domain.com.
Retrieving base DSA information...
Getting 1 entries:
Dn: (RootDSE)
<unnecessary details>
It looks like it is working, but I wasn't sure if the Error 0's mean there is some sort of problem.
Also, when I run a Simple bind with my credentials, I get the following output:
res = ldap_simple_bind_s(ld, 'myuseraccount-at-domaindotcom', <unavailable>); // v.3
Authenticated as: 'DOMAIN\myuseraccount'.
Finally, when I run a Bind as currently logged on user (with Encrypt traffic after bind checked), I get the following output:
53 = ldap_set_option(ld, LDAP_OPT_ENCRYPT, 1)
res = ldap_bind_s(ld, NULL, &NtAuthIdentity, NEGOTIATE (1158)); // v.3
{NtAuthIdentity: User='NULL'; Pwd=<unavailable>; domain = 'NULL'}
Authenticated as: 'DOMAIN\myuseraccount'.
I followed all the instructions found in Microsoft article KB-321051 to get LDAP over SSL working with a valid 3rd party certificate on one of our Windows 2008 R2 domain controllers. However, when I test Active Directory Authentication on our
WatchGuard Management Server after importing the CA certificate, the test fails. In order to use Active Directory Authentication, LDAPS (LDAP over SSL) must be enabled in the Active Directory domain and I am not 100% sure that it is enabled properly.
Any advice or additional insight would be greatly appreciated.
Thanks!

Some ideas:
DNS Name: KB-321051 says that you need the DNS name in either Subject CN or Subject Alternative Name. Which one did you use? Windows clients are fine with an empty CN and only the SAN populated (there the "either or" statement in the article)
but third-party tools often look for the DNS name in the Subject CN.
Even if the WatchGuard Server runs on Windows it might use its own certificate checking logic.
DC certificate(s): Does the DC have more than this certificate? If yes I'd run a network trace to check which one the machine is actually sending in the SSL handshake.
Chaining issues at your LDAP client / the WatchGuard Management Server:
Very often such issues are related to the fact that the certificate chain is not validated properly. Some typical issues:
It is not clear whether the client uses the Windows certificate store (even if it runs on a Windows server).
Tools / systems / PKI clients can only deal with a single root CA, not with a hierarchy.
You need to import both Root and intermediate CAs as the client cannot fetch the intermediates from AIA URLs.
The client cannot access CRL URLs because of firewalls rules or missing access (e.g.: A CRL URL in AD is used but the client does not have an AD user in whose context it would try to fetch the CRL).
The client has issues with blanks or special characters in CDP or AIA URLs.
Having a quick look at
WatchGuard documentation it seems to me that they are using their own certificate stores you need to import CA certificates to. And they only mention a "Root CA" so if your PKI has two levels you might need to import both CAs to the so-called Root store.
Elke

Ldap over ssl in windows 2008 r2

hi
i wanted to configure ldap over ssl and i have created security template along with apropriate persmission however when i want to add it my domain 2008 R2 computer it gives me error.
""the permision on the certificate template do not allow the current user to enrol for this type of certificate""
""you do not have perssmion to view this type of certificate""
kindly advise me.
greenman

On Sun, 23 Feb 2014 08:23:40 +0000, GreeMann wrote:
I believe my main problem is that I can not issue any template I have tried other template but I get the same permission error I have tried different account I get the same permission error, is there any way that we can change the default template permission.?
You have not followed the instructions I gave. As I've said in previous
posts, the way you've got this template configured is never going to work
as it is configured to build the subject information from AD and one of the
attributes being included in the Subject Alternative Name is the DNS. Since
you're using a user account to request the certificate when it attempts to
build the subject alternative name it is trying to add the user's DNS name.
A user account does not have a DNS name.
I would suggest that you delete any custom templates you've already created
and start over again. As per one of my previous posts:
http://technet.microsoft.com/en-us/library/ff625722%28v=ws.10%29.aspx
Follow the instructions in the Using the Certificate Enrollment wizard with
an enterprise CA section.
If you don't follow the instructions I've given you, I can't help you.
Paul Adare - FIM CM MVP
Of all the things I've lost, I miss my mind the most.

Failed to use LDAP over SSL MUTUAL AUTHENTICATION with some Directory enable SSL.

In iPlanet Web Server, Enterprise Edition Administration's guide, chapter 5: secure your web server - Using SSL and TLS protocol specifying that the Administrator server camn communicate LDAP over SSL with some Directory enable SSL.
Is there any way to configure iplanet Administration server to talk ldap/ssl in mutual authentication mode with some directory?

Hi,
Sorry, I could not understand what your are trying to do with iWS.
Could you please berifly explain your question. So that I can help you.
Regards,
Dakshin.
Developer Technical Support
Sun Microsystems
http://www.sun.com/developers/support.

Apex3 on XE over SSL for internet users

Folks,
I've been thrown in the deep end - I've created an Intranet in Apex3 on XE and now I need to make it available to outside parties over the internet. Due to the nature of the content it really should be only be available over SSL.
I have seen by other posts that suggest running Apache as a proxy for XE/Apex is the way to go and found what I thought was the answer on Apache's site (http://httpd.apache.org/docs/2.2/ssl/ssl_howto.html) as well as defaulting Apache to an Apex site (APEX charts and reverse proxy (Houston we have a problem!!)
However I don't seem to be able to marry up these settings (not being an Apache guru) into one solution for Apache defaulting to an Apex app (for intranet users) AND the same app but running under SSL for internet users !
Any assistance would be greatly appreciated !!

Wayne,
This is discussed on the XE forum over here:
How to Enable SSL in Oracle XE
Joel

Trying to connect to an AD LDAP over SSL via OPEN_SSL

Hello,
We are getting the error below when we attempt to run this code. Any ideas? Does this point to an incorrectly configured wallet and/or certificate?
DECLARE
BEGIN
l_session := DBMS_LDAP.init ( hostname => l_ldap_host_in, portnum => l_ldap_port_in );
l_retval := DBMS_LDAP.OPEN_SSL(l_session, owallet_loc, owallet_pwd, 2); -- Over SSL
l_retval := DBMS_LDAP.simple_bind_s ( ld => l_session, dn => l_ldap_dn_in, passwd => l_ldap_password_in );
l_retval := DBMS_LDAP.unbind_s(l_session);
END;
Error report:
ORA-31202: DBMS_LDAP: LDAP client/server error: UnKnown Error Encountered
ORA-06512: at "SYS.DBMS_SYS_ERROR", line 86
ORA-06512: at "SYS.DBMS_LDAP", line 1457
ORA-06512: at "SYS.DBMS_LDAP", line 1234
ORA-06512: at line 21
31202. 00000 - "DBMS_LDAP: LDAP client/server error: %s"
*Cause: There is a problem either on the LDAP server or on the client.
*Action: Please report this error to the LDAP server administrator or
your Database administrator.
Any help will be greatly appreciated! Thank you,
Alex.

We had never tried this before. I'm the Programmer trying to make the code work. I found this other thread Google'ing https://kr.forums.oracle.com/forums/thread.jspa?threadID=494022&start=15&tstart=0 and asked our Network Admin and our DBA to follow steps 1 and 2 and provide location to the wallet and password when they were done, which they did.
Now I'm testing the code and getting that error. I was about to report it to them, but I thought I should try and help by providing a possible fix, or maybe the code is the problem?
Alex.
Edited by: alarzabal on Dec 7, 2011 6:24 PM

LDAP over SSL in Weblogic 6.1 Certificate probs

Hi,
I'm trying to set up an outgoing SSL connection from a J2EE app to an LDAP server
(Netpoint) using JNDI. The code I use looks like this:
// Set up the environment for creating the initial context
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,
"com.sun.jndi.ldap.LdapCtxFactory");
env.put(Context.PROVIDER_URL, "ldap://url:636");
// Specify SSL
env.put(Context.SECURITY_PROTOCOL, "ssl");
// Authenticate as S. User and password
env.put(Context.SECURITY_AUTHENTICATION, "simple");
env.put(Context.SECURITY_PRINCIPAL, "uid=userid,ou=ApplicationAccess,dc=domain,dc=domain");
env.put(Context.SECURITY_CREDENTIALS, "password");
// Create the initial context
DirContext ctx = new InitialDirContext(env);
The LDAP server is already configured with a root certificate in PEM format(Base64
encoded ASCII). How do I setup weblogic so that my J2EE application accepts this
certificate??? I have understood that I have to generate a key and add this to
my truststore but I don't know exactly how to do this. Any help is greatly appreciated!

Hi,
I'm trying to set up an outgoing SSL connection from a J2EE app to an LDAP server
(Netpoint) using JNDI. The code I use looks like this:
// Set up the environment for creating the initial context
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,
"com.sun.jndi.ldap.LdapCtxFactory");
env.put(Context.PROVIDER_URL, "ldap://url:636");
// Specify SSL
env.put(Context.SECURITY_PROTOCOL, "ssl");
// Authenticate as S. User and password
env.put(Context.SECURITY_AUTHENTICATION, "simple");
env.put(Context.SECURITY_PRINCIPAL, "uid=userid,ou=ApplicationAccess,dc=domain,dc=domain");
env.put(Context.SECURITY_CREDENTIALS, "password");
// Create the initial context
DirContext ctx = new InitialDirContext(env);
The LDAP server is already configured with a root certificate in PEM format(Base64
encoded ASCII). How do I setup weblogic so that my J2EE application accepts this
certificate??? I have understood that I have to generate a key and add this to
my truststore but I don't know exactly how to do this. Any help is greatly appreciated!

LDAP over SSL gives an error when testing connection in RPD

Hello all,
I got something strange. When I configure OBIEE to use an LDAP server (ADSI) it just works fine.
Now when I change the port number and check SSL and I check the connection again it says:
[53016] The IBM LDAP SSL (Secure Socket Layer) client library initialization failed: Reason: Bad keyfile password
But now when I log on to OBIEE with an AD user it just works...
Anyone with the same problem/issue?

On Sun, 23 Feb 2014 08:23:40 +0000, GreeMann wrote:
I believe my main problem is that I can not issue any template I have tried other template but I get the same permission error I have tried different account I get the same permission error, is there any way that we can change the default template permission.?
You have not followed the instructions I gave. As I've said in previous
posts, the way you've got this template configured is never going to work
as it is configured to build the subject information from AD and one of the
attributes being included in the Subject Alternative Name is the DNS. Since
you're using a user account to request the certificate when it attempts to
build the subject alternative name it is trying to add the user's DNS name.
A user account does not have a DNS name.
I would suggest that you delete any custom templates you've already created
and start over again. As per one of my previous posts:
http://technet.microsoft.com/en-us/library/ff625722%28v=ws.10%29.aspx
Follow the instructions in the Using the Certificate Enrollment wizard with
an enterprise CA section.
If you don't follow the instructions I've given you, I can't help you.
Paul Adare - FIM CM MVP
Of all the things I've lost, I miss my mind the most.

Solution: Active Directory over LDAP over SSL

Hey all
I have the solution and i will describe how i solved it.
- Install windows 2000 server
- install service pack 2
- install high encription pack from windows
http://www.microsoft.com/windows2000/downloads/recommended/encryption/
- install active directory
also install a dns server, if there isn't one.
- install a Certificate Authority
a stand alone, that requires Active Directory
- install JDK 1.4
- goto http://localhost/certsrv
choose: "Retrieve the CA certificate or certificate revocation list"
then choose: "Download CA certificate"
save this file to the hard disk
- use keytool to import this file in the cacerts file
keytool -import -alias foo -storetype jks -keystore cacerts -file yourca.cer
the cacerts file must be in C:\j2sdk1.4.0_01\jre\lib\security or something
- then run the followin code for a connection
import java.util.*;
import javax.naming.*;
import javax.naming.directory.*;
import java.io.*;
import java.net.*;
public class HBUserAdmin {
public HBUserAdmin() {}
private Hashtable env;
private void _initialize() {
env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
env.put(Context.PROVIDER_URL, "ldap://your.server.com:636");
env.put(Context.SECURITY_AUTHENTICATION, "simple");
env.put(Context.SECURITY_PRINCIPAL, "CN=Administrator,CN=Users,DC=jellie,DC=com");
env.put(Context.SECURITY_CREDENTIALS, "youknowit");
env.put(Context.REFERRAL, "ignore");
env.put(Context.SECURITY_PROTOCOL, "ssl");
//THE LOCATION OF THE CACERTS MUST BE SPECIFIED
System.setProperty("javax.net.ssl.keyStore", "D:\\j2sdk1.4.0_01\\jre\\lib\\security\\cacerts");
System.setProperty("javax.net.ssl.trustStore", "D:\\j2sdk1.4.0_01\\jre\\lib\\security\\cacerts");
System.setProperty("javax.net.ssl.trustStoreType", "jks");
public void bindAs(String principal, String credentials, String baseDN) {
env.put(Context.PROVIDER_URL, baseDN);
env.put(Context.SECURITY_PRINCIPAL, principal);
env.put(Context.SECURITY_CREDENTIALS, credentials);
DirContext ctx = null;
try {
ctx = new InitialDirContext(env);
System.out.println("bind Successful...");
ctx.close();
} catch(AuthenticationException aex) {
System.out.println("Invalid userid or password... Please try again");
} catch (Exception ex) {
ex.printStackTrace();
public static void main(String[] args) {
System.out.println("Starting to execute");
HBUserAdmin testUser = new HBUserAdmin();
System.out.println("Binding...");
testUser.bindAs("CN=Administrator,CN=Users,DC=jellie,DC=com", "youknowit", "ldap://your.server.com:636");
I hope this will help all of you
questions?....mail
Jellie
[email protected]

System.setProperty("javax.net.ssl.keyStore", "D:\\j2sdk1.4.0_01\\jre\\lib\\security\\cacerts");
System.setProperty("javax.net.ssl.trustStore", "D:\\j2sdk1.4.0_01\\jre\\lib\\security\\cacerts");
Do not forget to alter these values.
IT MUST BE POINTING TO THE FILE YOU HAVE IMPORTED THE CERTIFICATE TO.
good luck

SOLVED: How To Use LDAP over SSL (no certs) from java program

Trying to connect to OID from Java program (using Grocery Store demo as a test). Want to use SSL with no server certificate. OID is configured, and ldapsearch -U 1 works.
Tried using URL with ldaps, or adding SECURITY_PROTOCOL,"ssl". In both case the error is 'simple bind failed'.
Samples on OTN say this should be possible, but then only have code for the non-ssl connection.
Posting from others with this same question don't seem to have been answered.
Message was edited by:
user590350
I have found that using ConnectionUtil.getSSLDirCtx() from Oracle will make a no-authentication SSL connection. An example in the sample code would be useful.

Even with Java APIs, There is a way to talk through SSL without bothering about certificates. It's just that you will have to write some code and make some changes in settings.
Read following to get further information on the same.
http://kiranthakkar.blogspot.com/2007/04/dummny-certificate-authentication.html
I don't know or I won't comment whether it's the right approach or not but it's definitely a work around.
Thanking You
Kiran Thakkar

LDAP over SSL - Works with AD Username but not with full logon @

Hello
I have 2 Cisco ASA 5505 and have configured SSL over LDAP to connect via a Active Directory server.
Everything works fine apart that lets say I have a user called [email protected] - When I am using Anyconnect or Cisco VPN Client and try that it does not work at all.
If I try abc without the @zzz.com then it works and authenticates to the AD and gets DHCP and user is fine.
The only question is since I think I have seen this documented somewhere - is that correct or can I use the @ full AD UPN ??
I am trying to make our users do a single SSO and have every other application using the full UPN.
Thanks

Hello
I have 2 Cisco ASA 5505 and have configured SSL over LDAP to connect via a Active Directory server.
Everything works fine apart that lets say I have a user called [email protected] - When I am using Anyconnect or Cisco VPN Client and try that it does not work at all.
If I try abc without the @zzz.com then it works and authenticates to the AD and gets DHCP and user is fine.
The only question is since I think I have seen this documented somewhere - is that correct or can I use the @ full AD UPN ??
I am trying to make our users do a single SSO and have every other application using the full UPN.
Thanks

Support ssl for ldap

Hi,
I am working on connecting to ldap over ssl through java application.
I have few questions :
We are using jdk1.3 version, as per sun's documentation,
LDAP client requirement section says that :
Once the JSSE has been installed and configured, you need to ensure that the client trusts the LDAP server that you'll be using. You must install the server's certificate (or its CA's certificate) in your JRE's database of trusted certificates. Here is an example.
# cd JAVA_HOME/lib/security
# keytool -import -file server_cert.cer -keystore jssecacerts
a) I donot find jssecacerts in my jre directory, I only have cacerts file, how exactly can I generate jssecacerts file ?
b) server_cert.cer - should this be the same server certificate used in setting up the LDAP server ?
I am new to this and haven't worked on this before. Any help on this is highly appreciated.
Thanks in advance.

Yeah, all you need to do is :
At this directory
# cd JAVA_HOME/lib/security
from the command line execute the keytool command as follows.
# keytool -import -file server_cert.cer -keystore jssecacerts
where server_cert.cer is the certificate u installed at the LDAP server.
jssecacerts gets created automatically after this succeeds.
Thanks,

Connecting to a remote OpenLDAP server over SSL.

I've been trying for several weeks now to get a remote OpenLDAP server up and running; configured in such a way that it only allows SSL and requires certificate validation.
I've created a CA with a self-signed certificate.
I used that CA to create a server and client certificate.
The server certificate is in /etc/ssl/certs, has a link by the name of its hash.0 pointing to it; permissions are all correct and /etc/ssl/slapd.conf point to it and the CA certificate.
The client certificate is on my MacBook Pro in /etc/ssl/certs along with the CA certificate; each of which also has its hash linked to it. /etc/ssl/ldap.conf is set up properly, the permissions are correct, and the following test command ran as my user produces a successful result:
ldapsearch -v -x -H ldaps://ldap.foo.org -b "dc=foo,dc=org" -d -1
Now the problem part. I open Directory Utility; go to Services with Advanced Settings enabled. After unlocking it, I click the LDAPv3 and the pencil icon.
I hit New... in the window that pops up and use ldap.foo.org as servername, SSL box ticked. I hit Continue, and behold; nothing happens.
It is to say; Directory Utility hangs for a while; after which it goes back to the box I clicked Continue in without any error or warning popping up; but obviously hasn't advanced.
The server logs indicate my Mac had actually connected; received the server certificate; but didn't send a client certificate at which point the TLS connection got aborted for some reason and the session ended.
My Mac Console shows something even more bizare, though:
11/09/08 23:09:22 com.apple.DirectoryServices[97123] Assertion failed: (ld != NULL), function ldapsearchext, file search.c, line 76.
My suspicion is that Directory Utility can't verify the server certificate and aborts the TLS connection. I expect it also uses /etc/openldap/ldap.conf? How can I diagnose the root of this problem?
Thanks a lot for your assistance; I just can't figure this out and any hint or pointer would be greatly appreciated. It now just looks like OSX does not support a secure LDAP over SSL configuration.
Though it currently isn't set up to be that way, I'd like to have my client also provide a certificate (CN=lhunath.foo.org) and have the server validate that. For now I've got the server set to:
TLSVerifyClient never
(And of course, the client:)
TLS_REQCERT demand
Message was edited by: lhunath

By the way; about the assertion error I get in Console; here's the relevant source of ldap.c. Looks like ld is not set; probably something going wrong before that with setting up the TLS connection, perhaps? Or not?
* ldapsearchext - initiate an ldap search operation.
* Parameters:
* ld LDAP descriptor
int
ldapsearchext(
LDAP *ld,
assert( ld != NULL );

LDAP over SSL for Solaris 9 / Solaris 10

Similar Messages

Maybe you are looking for