H2o.ai fails to query openLDAP passes 'cn' instead of 'uid' - ldap

I configured h2o application to use openLDAP configuration referring to the link:
https://docs.h2o.ai/sparkling-water/2.3/latest-stable/doc/tutorials/ldap.html
Added userNameAttribute=uid to ovreride 'cn' to use 'uid' field instead.
However it is not working. The query getting passed on LDAP still has cn=user_id instead of uid=user_id.
Am I doing something wrong or is a bug?
ldap.conf:
ai.h2o.org.eclipse.jetty.plus.jaas.spi.LdapLoginModule required
debug="true"
useLdaps="true"
contextFactory="com.sun.jndi.ldap.LdapCtxFactory"
hostname="ldap.h2o.ai"
port="389"
bindDn="cn=admin,dc=h2o,dc=ai"
bindPassword="h2o"
authenticationMethod="simple"
forceBindingLogin="true"
userBaseDn="ou=users,dc=h2o,dc=ai"
userNameAttribute="uid";
};```

userIdAttribute="uid" worked for me.
Now the authentication from LDAP is successful, however now it's failing with same exception mentioned at:
https://github.com/eclipse/jetty.project/issues/2648, and the suggested fix is NOT included in h2o.jar, hence the failure.
#h2o team needs to update the h2o.jar with this fix.

Related

Wildfly Server local server debug panel shows error "http connector is not enabled for server profile"

I setup a local JBoss/Wildfly server launch configuraiton in Intellij Idea. When I attempt to start the server, the configuration panel pops up and shows following error.
Error: HTTP connector is not enabled for server profile
I could not find anything in the Idea help what this means and how to fix it. The server is a keycloak distro but is just plain wildfly 10 with an extra subsystem.
Has anyone seen this before and knows how to fix the error?
I can't reproduce this with fresh installation of keycloak 3.2.1 from here
IDEA looks for the 2 following xpath's searching for a HTTP connector settings:
"/ns:server/ns:profile/*[local-name()='subsystem']/*[local-name()='server']/*[local-name()='http-listener'][#*[local-name()='socket-binding' and .='http']]",
"/ns:server/ns:profile/*[local-name()='subsystem']/*[local-name()='connector'][#*[local-name()='socket-binding' and .='http']]"};
For me playing with the fresh keycloak distribution the first xpath hits at the following markup:
<subsystem xmlns="urn:jboss:domain:undertow:3.0">
<buffer-cache name="default"/>
<server name="default-server">
<http-listener name="default" socket-binding="http" redirect-socket="https"/>
Please check your configuration around this place.
If this does not help, please attach your standalone.xml or at least the relevant part of it.
In my case changing of 'JRE' from 'Default' to explicit one (Even though it was the same as it was in parentheses in the default version) solved the problem.

process.env.PORT is undefined

I am trying to go to production on one of my node.js applications which runs ion windows server 2012. After a week of troubleshooting and reading everything I could get to online, the problem seems to be the "process.env.PORT" variable.
The symptoms are as follows:
The website works fine when:
set PORT=3510 in console
domain.com:3510/index.html in remote browser
However, when I type:
domain.com
I get a 404 - File or directory not found.
When I console.log the "process.env" object at startup of my server.js, the console.log prints an object with several properties but no "PORT" property (unless I "set PORT=3510"). Without setting the port manually prior to launching the server.js, "process.env.PORT" console.logs reports undefined.
However, If manually specify the port, the server still does not work because, according to what I read, node expects "process.env.PORT" to be a named pipe and not a number.
So the problem is very specific:
How do I set the "process.env.PORT variable" on windows 2012 server so that nodejs can work with it?
You need to set it in the web.config file. You can set a key as "PORT" with the value you need. See the below web.config file as an example...
<configuration>
<appSettings>
<add key="PORT" value="3510" />
</appSettings>
...(Other configurations here)
</configuration>

JBAS010153: Node identifier property is set to the default value. Please make sure it is unique

I am getting the following WARN message while I start my host which is one of the Host Controller (HC) that is attached to the Domain Controller(DC).
[Server:server-two] 14:06:13,822 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 33) JBAS010153: Node identifier property is set to the default value. Please make sure it is unique.
And my host-slave.xml has the following config...
<server-identities>
<!-- Replace this with either a base64 password of your own, or use a vault with a vault expression -->
<secret value="c2xhdmVfdXNlcl9wYXNzd29yZA=="/>
</server-identities>
I hope this config is the reason...... maybe I didn't understand..... but I couldn't find node identifier property rather this is the default secret value which I hope could be the cause of this WARN message.
However, I didn't mention HC to lookup host-slave.xml..... the command which I ran to start my HC is.....
[host-~-\-\-\bin]$./domain.sh -Djboss.domain.master.address=nnn.nn.nn.88 -b nnn.nn.nn.89 -bmanagement nnn.nn.nn.89 &
nnn.nn.nn.88 is my DC
Else please advise what's cause of the WARN message.
And please let me know the implication of this WARN message and advise us on the required config to overcome and sort out any consecutive consequences that would've been bound for this WARN.
I'm new to wildfly, and noticed this warning when I started it standalone from eclipse (I'm doing the following tutorial: https://wwu-pi.github.io/tutorials/lectures/eai/020_tutorial_jboss_project.html)
The fix was to add a node-identifier to the core-environment in the subsystem:
<subsystem xmlns="urn:jboss:domain:transactions:2.0">
<core-environment node-identifier="meindertwillemhoving">
<process-id>
<uuid/>
</process-id>
</core-environment>
<recovery-environment socket-binding="txn-recovery-environment" status-socket-binding="txn-status-manager"/>
</subsystem>
This is in file [wildfly]\standalone\configuration\standalone.xml.
This is the same answer as https://developer.jboss.org/message/880136#880136
According to WFLY-10541 if you are using WildFly v14.0.0 or newer you can pass the following to the startup script to set the transaction node identifier:
-Djboss.tx.node.id=<some-unique-id>
Setting the node identifier to an unique value is only required for proper handling of XA Transactions.
You can set it as follows in your XML configuration:
<subsystem xmlns="urn:jboss:domain:transactions:6.0">
<core-environment node-identifier="${jboss.tx.node.id}">
It needs to be a unique value up to 23 bytes long.
More about this here: http://www.mastertheboss.com/jboss-server/jboss-configuration/configuring-transactions-jta-using-jboss-as7-wildfly
Building on #kaptan's answer I added the following to the bottom of
bin/standalone.conf:
JAVA_OPTS="$JAVA_OPTS -Djboss.tx.node.id=`hostname -f`
This way I don't have to remember to add the "-Djboss.tx.node.id=" when running up wildfly by hand.
For this <server-identities> is not the issue. In fact, it shouldn't be touched at all.
When JBoss is started in domain mode by domain.sh, by default there will be three servers server-one server-two server-three. When you are running one more HC attached to the DC.... the defaulted server which is in auto-start mode will get clash when we start HC attaching to DC,- by the following command.
[host-~-\-\-\bin]$./domain.sh -Djboss.domain.master.address=nnn.nn.nn.88 -b nnn.nn.nn.89 -bmanagement nnn.nn.nn.89 &
Or by having the host configuration at HC (default host.xml... until unless we choose a different one....).
<domain-controller>
<remote host="${jboss.domain.master.address:nnn.nn.nn.88}" port="${jboss.domain.master.port:9999}" security-realm="ManagementRealm"/>
<domain-controller>
In order to solve this, we need to turn auto-start to false..... And we need to create a new server-group...... To that group we need to add dc-created-server and hc-created-server..... we can choose the appropriate same profile either full-ha or full for both created servers across DC and HC.
SO when we start the group by configuring the required HEAP size including permgen space... You could start both DC and HC.... and in DC you could see both of your-created-servers are started in the created server-group.
DC- Domain Controller
HC- Host Controller
To deploy you need to upload .ear or web-archive in the Application Console. You cannot place it in the deployments folder as how you do in standalone mode with .dodeploy file.
If you upload the same .ear next version do the Replace option instead of the Remove & Add option in the upload process.

unable to set security domain via jboss-web.xml

We have an app that is being deployed as an ear. Within this ear, there is a war that needs to use a specific security domain.
To achieve this, we have configured the standalone-full-ha.xml with the following security section
<security-domain name="ourDomain" cache-type="default">
<authentication>
<login-module code="blah.blah.OurDomain" flag="required" />
</authentication>
</security-domain>
ear/war/WEB-INF/jboss-web.xml is configured as follows:
<?xml version="1.0" encoding="UTF-8"?>
<jboss-web>
<security-domain>Quark</security-domain>
<disable-audit>true</disable-audit>
</jboss-web>
With this configuration, the app tries to authenticate against the "other" domain which is there in JBoss by default.
log entries as follows:
TRACE [org.jboss.security] (http-/127.0.0.1:8080-6) PBOX000224: End getAppConfigurationEntry(other), AuthInfo: AppConfigurationEntry[]:
[0]
LoginModule Class: org.jboss.as.security.remoting.RemotingLoginModule
ControlFlag: LoginModuleControlFlag: optional
Options:
name=password-stacking, value=useFirstPass
[1]
LoginModule Class: org.jboss.as.security.RealmDirectLoginModule
ControlFlag: LoginModuleControlFlag: required
Options:
name=password-stacking, value=useFirstPass
When trying to define this as part of the ear in ear/META-INF/jboss-app.xml, that made the whole thing blow up pretty spectacularly - so figured that was less likely to be the way to resolve this.
If the default security domain is changed to ourDomain however, it all works as expected.
This doesn't seem to be a big deal - however, it feels better to be able to leave as much of the configuration in the app as possible.
Any pointers to resolve this appreciated.
Your security domain name specified in jboss-web.xml needs to match the name of some security domain in your JBoss config, in your case the web descriptor specifies Quark while the security subsystem defined domain named ourDomain.
Whenever JBoss can not find the security domain you request in your jboss-web.xml, it will fallback to the default security domain, which in case of 7.x is named other.

How to run svcutil.exe from behind authenticating proxy

I want to run the svcutil.exe tool to access a web service on the internet. Unfortunately, whenever I try, I get a bunch of errors that include the following message:
The request failed with HTTP status 407: Proxy Authentication Required ( The ISA Server requires authorization to fulfill the request. Access to the Web Proxy filter is denied.
As I have learned from this related post (with more details here), the problem is that I am sitting behind an authenticating proxy. That post explains that I need to edit the app.config file, but I can't figure out how to do that. I think I will use the /svcutilConfig:alternate_app.config switch, but I don't know how to construct a valid .config file to pass to that switch. What is the default app.config file that svcutil.exe uses?
Well, I think I have figured out the answer to my question:
It turns out that the default .config file used by svcutil.exe is called svcutil.exe.config, and (at least for me) it lives in this folder:
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin
I decided to just edit that file directly (rather than fumble around with the /svcutilConfig switch). I needed Admin privileges to do so.
The final contents of that file looked like this:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<runtime>
<generatePublisherEvidence enabled="false" />
</runtime>
<system.net>
<defaultProxy useDefaultCredentials="true" />
</system.net>
</configuration>
(with the secret sauce buried in the <system.net> element.)
In order for this all to work, I had to start the Command Prompt as Administrator, navigate to the folder listed above, and run the svcutil.exe command from there.
Hope this helps some other poor soul who gets stuck in this mess! Thanks to #AndrewWebb for the clues that got me going!