ApacheDS webapp and Cloudfoundry - ldap

I deployed an embedded apacheds application to public cloudfoundry! but i can't access it from ldap client in my machine!!
my server properties:
host: http://kenzdz.cloudfoundry.com/
port: 10389
root dn: ou=system
when i use a class in the same project to acces the server,it success like the link show it:
http://kenzdz.cloudfoundry.com/ldaptest : it is a servlet that acces the ldap server
but when i use a ldap client like jexplorer to acess remotely to the server it doesn't success.
is it because an embedded ldap server i cant do it?

Cloudfoundry.com only allows inbound http(s) traffic on ports 80 and 443, respectively (see May i open a port on Cloud Foundry?). So you won't be able to interact using the LDAP protocol with the app you deployed.

Related

CAS server - can't acces CAS address after the copy of the war file generated in /var/lib/tomcat9/webapps/

I am currently setting up a CAS server in a local network which will have to authenticate users belonging to ldap directories so that they can then connect to a web server.
A Windows Server 2019 Active Directory is the gateway to the WAN.
Environment:
Windows Server 2019 with Active Directory and DHCP, routing and DNS installed which make the link between the WAN and the LAN; IP: 192.168.100.10
LDAP Server on Centos 7 on the LAN registred on the Active Directory (no ssl certificate generated); IP: 192.168.100.50
CAS Server on Debian 11 on the LAN (no ssl certificate generated for tomcat and cas); IP: 192.168.100.101
All pinging between each other;
I'm following this process to install and configure the cas server:
https://www.esup-portail.org/wiki/pages/viewpage.action?pageId=972292097
This is my build.gradle configuration file:
build.gradle
This is my cas.properties configuration file:
cas.properties
After the copy of the war file generated in /var/lib/tomcat9/webapps/; i restart tomcat9 service.
The problem is that i can't access the cas address:
erreur_acces_site
When i check the status of Tomcat service, i got this error:
error_tomcat_service_status
Can anyone enlighten me? I can't see what's going wrong.
Moreover, if someone has a detailed procedure, which describes the environment and the prerequisites, recent and educational to install a CAS server for Centos 7, I am strongly interested
Thank you in advance!
When I remove the CAS dependencies in build.gradle and LDAP authentication config in cas.properties, I can access the CAS login screen.

LDAP with Liferay - Unknown host where exists

I have to integrate LDAP with two different services: exoPlatform and Liferay. So I set up an LDAP server via a Docker image with these configurations:
Server Name: openldap
Base Provider URL: ldap://openldap:389
Base DN: cn=users,ou=Platform,o=acme,dc=example,dc=org
My admin account is just: cn=admin
With exoPlatform, it works fine, I can log in with my LDAP accounts.
Here the configurations in the picketlink-idm-openldap-config.xml:
<option>
<name>providerURL</name>
<value>ldap://openldap:389</value>
</option>
<option>
<name>adminDN</name>
<value>cn=admin,dc=example,dc=org</value>
</option>
<option>
<name>adminPassword</name>
<value>admin</value>
</option>
But for Liferay, it tells me that the host is not known...
Unable to bind to the LDAP server
liferay | javax.naming.CommunicationException: openldap:389 [Root exception is java.net.UnknownHostException: openldap]
Caused by: java.net.UnknownHostException: openldap
I don't know if it's related but I'll say it anyway just in case, I have 2 different docker-compose that I launch at the same time:
one that contains the images openldap, phpldapadmin, exoPlatform and mysql1
one that contains the liferay and mysql2 images
I am also behind a corporate proxy, but I don't remember having done anything special for exoPlatform.
I simply added the proxy settings to Catalina Tomcat for my exoPlatform and Liferay images.
Also, I have set LDAP authentication to enabled in the Liferay control panel with the Bind method.
This a network issue between your containers, exoPlatform works but Liferay doesn't because the specified host openldap does not exist in its own container, and as well the 389 port may not be accessible from there.
You can have a quick check without running java/ldap by running the following command from the Liferay container :
telnet openldap 389
It will probably outputs "Network is unreachable", in this case you need to create a network and connect containers to that network >>>
How to communicate between Docker containers via "hostname"

How to change the "cn" value to IP address instead of localhost in websphere Application server

I am trying to set up a client-server EJB using two different machines on my network. while installing WAS server it prompted me to add admin credentials, so LTPA is enabled (hope it enabled SSL). Now on client EJB deployed WAS server I have to configure the outbound IIOP SSL certificate(Correct me if I am wrong on this). But unfortunately in the server WAS admin console I can see SSL Signer certificates cn(Host/domain) parameter as localhost. the same "localhost" is arriving when I try to "retrieve from port" in client EJB WAS server.
I have attached the "Retrieve from port" screenshot
Client WAS retrieve from port action
Even I have tried changing the hostname in the server WAS under the Server-> Communications -> Port to IP address instead of localhost.
I expect it should bring domainname.ipaddress
"Retrieve from port" action always brings "localhost" from the remote server
As per the comment by #Gas, I am following this below link
https://www.ibm.com/support/knowledgecenter/en/SSAW57_8.5.5/com.ibm.websphere.nd.multiplatform.doc/ae/tsec_sslreplacecell.html
will update in short

How to set up SSL on WildFly 9 Domain Mode?

I currently have a WildFly 9 cluster up and running with access to my application over port 8080, I would like to set up SSL and have access only on port 8443, but I cannot seem to find any documentation for where the security realm and https listener are placed in Domain mode.
I have the keystore and certificate all set up and was able to get https working in a demo using standalone mode, but I need to be able to do it in domain mode.
Can anyone help me out and share how they've accomplished this?
Solved it! It turns out for some reason JBoss was not registering my Security Realm and HTTPS listener. To do this you need to use bin/jbosscli and the commands:
RUN THE "CONNECT" COMMAND FIRST
/host=master/core-service=management/security-realm=SSLRealm/:add()
---where SSLRealm is the name of the realm
/host=master/core-service=management/security-realm=SSLRealm/server-identity=ssl/:add(keystore-path=Keystore.jks, keystore-relative-to=jboss.domain.config.dir, keystore-password=password)
---this assumes the keystore lives in the domain/configuration directory
Restart the server.
I then ran into issues figuring out the command to register the HTTPS listener, but I found the WildFly web console at serverURL:9990 has a way to do it too:
Once logged in to the webconsole
Configuration->Profiles->for each profile which is used->Undertow->HTTP->View
From there
HTTP Server->default-server->view
Finally
HTTPS Listener->ADD enter a name like: default-https, Security Realm: the name chosen for the security realm (for this example SSLRealm), Socket Binding: https and click save
Restart again
You should now have access at your serversURL:8443
To set it up on slave servers you should only need to copy the keystore to each slave servers domain/configuration and then add the security realm replacing /host=master/ with /host=slave/ in the command. And then restart the server.
Double check the Domain.xml file on the slave has the https listener you created originally in the webconsole (it should automatically be put into all of the clusters domain.xml files)

how to listen ldap client requests on port 636 with unboundid ldap listener

I have created a test environment. I have one ldap client, ldap listener (as a ldap proxy) and a ldap server. Ldap client sends ldap requests to ldap proxy on port 389 (SSL). Ldap proxy decodes the ldap requests and forwards them to the ldap server on port 389. And the proxy forwards the reply of the ldap server to ldap client successfully.
I created SSL certificate on ldap server. And this time I tested that ldap client sends ldap requests to ldap proxy on port 389 (SSL). Ldap proxy forwarded requests to the ldap server on port 636. And the proxy forwards the reply of the ldap server to ldap client successfully.
But there is a problem when I try to use SSL on both sides. I mean
ldap client (port 636) -> ldap proxy (port 636) -> ldap server (port
636)
My client throws an exception
javax.net.ssl.SSLHandshakeException: Remote host closed connection
during handshake
I am using unboundid ldap sdk and LdapDebugger example as a ldap proxy. How can I configure ldaplistener to accept SSL encrypted requests(port 636)?
thanks in advance...
If you're using the ldap-debugger tool provided with the LDAP SDK, it currently only supports SSL for communicating with the backend server, but not when communicating with a client. That is, the "--useSSL" option applies only for communication between the LDAP debugger and the backend directory server, and not between the client and the LDAP debugger. However, because this is potentially a very useful feature, I have just committed a set of changes that add this capability, so if you check out and build the latest version of the LDAP SDK, you will find that the ldap-debugger tool has a new "--listenUsingSSL" argument that controls this.
Note that regardless of whether you're using the ldap-debugger tool or you have created your own listener via Java code, you need to ensure that you have a Java keystore that contains the SSL certificate that will be presented to clients. If the LDAP server you're using is Java-based (e.g., the in-memory directory server provided with the LDAP SDK), then you probably already have this. Otherwise, you'll need to create one. If you're just doing this for testing purposes, a self-signed certificate should be just fine (as long as the client trusts it, or is configured to blindly trust all certificates).