I'm really new to XMPP and I decided to go with ejabberd. Firstly I tried to configure it on ubuntu, but I got error after error and I just switched to windows. The server is running now.
I've installed XAMPP and I tested the connection with strophe.js.
I've read some of the documentation on ejabberd and watched the tutorial videos and that guy talks about stateless configuration( use ejabberd only of messages and have my own database in which I save messages,users etc). I want to achieve that, but I don't really know where to start. I assume that I would have to post the message to my database for storing and also to the ejabberd for pushing.
Any ideas/examples/tutorials?
Edit:
2016-05-22 20:28:32.746 [error] <0.532.0>#ejabberd_sql:check_error:991 SQL query 'Q9525209' at {sql_queries,145} failed: <<"Unknown Host">>
2016-05-22 20:28:32.746 [error] <0.532.0>#ejabberd_sql:check_error:991 SQL query 'Q9525209' at {sql_queries,145} failed: <<"Unknown Host">>
2016-05-22 20:28:32.746 [error] <0.532.0>#ejabberd_auth:is_user_exists:316 The authentication module ejabberd_auth_sql returned an error
when checking user <<"admin">> in server <<"localhost">>
Error message: <<"Unknown Host">>
Configuration:
##
## MySQL server:
##
odbc_type: mysql
odbc_server: "127.0.0.1"
odbc_database: "ej_chatapp"
odbc_username: "root"
odbc_password: "password"
##
## If you want to specify the port:
odbc_port: 3306
auth_method: odbc
In my videos, Stateless configuration is mentioned in the context of ejabberd SaaS: https://ejabberd-saas.com
ejabberd SaaS provide API that can be used to point to your own backend. Those API are not available in ejabberd, only available in SaaS to ease integration with customer backends.
Related
I want to set up a new ftp server using vsftpd on RHEL8, for user authentication we would like to use LDAP(389 directory server). As I understood ldap_pam.so module is deprecated in RHEL8, so I'm wondering how to connect the remote LDAP server to my vsftpd service without PAM module?
The standalone pam_ldap and libnss_ldap modules (developed by PADL) are obsolete, but they have near-drop-in replacements that come with the nslcd daemon and are also called pam_ldap and libnss_ldap. They might be found in the "nss-pam-ldapd" package.
(The old modules were removed in part because they performed LDAP requests in-process, requiring libldap and all its dependencies to be loaded into every single process that performed user lookups, which caused all kinds of problems. The newer variant of pam_ldap that comes with nslcd/nss-pam-ldapd does not have such issues.)
However, Red Hat's preferred option is probably the sssd service, which uses pam_sss and libnss_sss modules. It is somewhat optimized for MS AD and FreeIPA, but can still work with any generic LDAP (and Kerberos) server.
Here is the full setup for connection between vsftpd and ldap in rhel8:
in /etc/vsftpd/vsftpd.conf
pam_service_name=vsftpd
in /etc/pam.d/vsftpd:
#%PAM-1.0
auth required pam_sss.so domains=vsftpd
account required pam_sss.so
in /etc/sssd/sssd.conf
[sssd]
config_file_version = 2
services = nss, pam
domains = vsftpd
[domain/vsftpd]
id_provider = ldap
sudo_provider = none
auth_provider = ldap
ldap_uri = ldap://example.com
ldap_search_base = ou=example1,ou=example2
I would like to ask if there is a possibility to force the authentification mechanisms in the ejabberd config. Currently the ejabberd server is providing a list of the available, authentification mechanisms.
In the ejabberd log we can see the list:
Send XML on stream = <<"<stream:features><mechanisms
xmlns='urn:ietf:params:xml:ns:xmpp-sasl'><mechanism>PLAIN</mechanism>
<mechanism>X-OAUTH2</mechanism><mechanism>SCRAM-SHA-1</mechanism>
</mechanisms><starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
</stream:features>">>
Some users (in our case CPEs (Routers, Set-top boxes)) are able to use the SCRAM-SHA, some of them are only able to use the PLAIN method, etc.
2021-07-20 14:42:09.763 [info]
<0.6716.0>#ejabberd_c2s:handle_auth_success:432 (tls|<0.6716.0>) Accepted
c2s SCRAM-SHA-1 authentication for acs01#test.ejabberd.com by sql backend
from 192.168.0.1
2021-07-20 14:42:31.765 [info]
<0.6721.0>#ejabberd_c2s:handle_auth_success:432 (tcp|<0.6721.0>) Accepted
c2s PLAIN authentication for 00b052101005#test.ejabberd.com by sql backend
from 88.229.19.19
2021-07-20 14:42:36.438 [info]
<0.6722.0>#ejabberd_c2s:handle_auth_success:432 (tcp|<0.6722.0>) Accepted
c2s SCRAM-SHA-1 authentication for 001565a36103#test.ejabberd.com by sql
backend from 103.217.240.30
Is it possible to force the xmpp server to offer only one method?
You can disable SASL mechanisms using
https://docs.ejabberd.im/admin/configuration/toplevel/#disable-sasl-mechanisms
For the other methods, looking at the source code they are automatically enabled/disabled:
https://github.com/processone/ejabberd/blob/8afc320aba7bdb51f7a76973be2d9cbf200c6310/src/ejabberd_c2s.erl#L376
Of course, you can simply delete there the lines you don't want at all, recompile and install.
SQ 5.6, LDAP plugin 2.0.
I've successfully installed the LDAP plugin and restarted the SQ server. In the log (/opt/sonar/logs/sonar.log) the plugin is apparently deployed, but seemingly no attempt is made to initialize/enable it or connect to the LDAP server.
INFO web[o.s.s.p.ServerPluginRepository] Deploy plugin LDAP / 2.0 / 2910f3981167a70a201ccfae01471dfd26c794b7
.
.
INFO web[o.s.s.p.RailsAppsDeployer] Deploying app: ldap
These are the only mentions of ldap/LDAP in the log.
Relevant part of the conf/sonar.properties file:
sonar.security.realm=LDAP
ldap.url=ldap://myldap:389
ldap.user.baseDn=ou=mycompany,ou=People,dc=myurl,dc=com
I believe I've verified ldap.url and ldap.user.baseDn via JXplorer (an LDAP browser).
What really puzzles me is that I don't see anything like the following in the logs, which is what I'd expect from the SQ docs:
INFO org.sonar.INFO Security realm: LDAP ...
INFO o.s.p.l.LdapContextFactory Test LDAP connection: OK
No errors of any kind are noted in the log.
Any idea why SQ is not even apparently trying to kick off LDAP authentication on a restart?
I had the same problem. I'm running Sonarqube using docker. It did not pick up on changes when I restart the server from the Sonarqube UI. Only after restarting the docker image it could pick up the changed file.
Well, now it just started working. I don't have an answer as to why though. Maybe something changed with my LDAP server, or there was some latency that needed to be overcome. I didn't change anything on my end that I'm aware of. In any case, thanks to those that responded.
Currently I am having an issue really need some help.
We are trying kerberize our hadoop cluster including hive server2 and oozie. My oozie job spins off a java action in data node which tries to connect to kerberized hive server 2.
There is no user’s kerberos keytab for authentication. So I can only use delegation token passed by oozie in the java action to connect to hive server 2.
My question is: is there any way that I can use delegation token in a oozie java action to connect to hive server 2? If so, how can I do it through hive JDBC?
Thanks
Jary
When using Oozie in a kerberized cluster...
for a "Hive" or "Pig" Action, you must configure <credentials> of
type HCat
for a "Hive2" Action (just released with V4.2) you must configure
<credentials> of type Hive2
for a "Java" action opening a custom JDBC connection to HiveServer2,
I fear that Oozie cannot help -- unless there is an undocumented hack that would make it possible to reuse this new Hive2 credential?!?
Reference: Oozie documentation about Kerberos credentials
AFAIK you cannot use Hadoop delegation tokens with HiveServer2. HS2 uses Thrift for managing client connections, and Thrift supports Kerberos; but the Hadoop delegation tokens are something different (Kerberos was never intended for distributed computing, a workaround was needed)
What you can do is ship a full set of GSSAPI configuration, including a keytab, in your "Java" Action. It works, but there are a number of caveats:
the Hadoop Auth library seems to be hard-wired on the local ticket
cache in a very lame way; if you must connect to both HDFS and
HiveServer2, then do HDFS first, because as soon as JDBC initiates
its own ticket based on your custom conf, the Hadoop Auth will be broken
Kerberos configuration is tricky, GSSAPI config is worse, and since
these are security features the error messages are not very
helpful, by design (would be bad taste to tell hackers why their intrusion
attempt was rejected)
use OpenJDK if possible; by default the Sun/Oracle JVM has
limitations on cryptography (because of silly and obsolete US
exports policies) so you must download 2 JARs with "unlimited
strength" crypto settings to replace the default ones
Reference: another StackOverflow post that I found really helpful to set up "raw" Kerberos authentication when connecting to HiveServer2; plus a link about a very helpful "trace flag" for debugging your GSSAPI config e.g.
-Djava.security.debug=gssloginconfig,configfile,configparser,logincontext
Final warning: Kerberos is black magic. It will suck your soul away. More prosaically, it will have you lose many man-days to cryptic config issues, and team morale will suffer. We've been there.
Like Samson said Java action in Oozie requires additional authentication to connect to some "kerberized" services like hive. It can be achieved in a relativly simple way, without modifications in application.
Oozie action
<action name="java-action">
<java>
...
<main-class>some.App</main-class>
<java-opts>-Djavax.security.auth.useSubjectCredsOnly=true -Djava.security.krb5.conf=/etc/krb5.conf -Djava.security.auth.login.config=jaas.conf</java-opts>
<file>hdfs://some/path/App.jar</file>
<file>hdfs://some/path/user.keytab</file>
<file>hdfs://some/path/jaas.conf</file>
</java>
...
</action>
jaas.conf
com.sun.security.jgss.initiate {
com.sun.security.auth.module.Krb5LoginModule required
useKeyTab=true
useTicketCache=true
principal="USER#EXAMPLE.COM"
doNotPrompt=true
keyTab="user.keytab"
};
I have been trying to make an application which needs to bind to LDAP server using GSSAPI using the ticket provided by the Kerberos server. I am using Novell's JLDAP library for this purpose.
I am able to get a ticket from the authentication server but when I try to bind to the Service Server(LDAP in my case ), I get GSSException: Major Status: (589824, Invalid token was supplied), Minor Status: (0, Unknown error)
and the bind fails.
The AS(Authentication Server) and SS(Service Server(LDAP server)), both are behind a single proxy.
In this case, do they need mutual authentication?
I not sure but it seems my java code is not able to get/recognize/decrypt the token recieved from the AS(Authentication Server).
I am providing the mechanism name as "GSSAPI" in the SASL bind method of Novell's LDAPConnection.java
Did anyone face this kind of trouble? What would be the cause and probable solutions for this? Please explain.
Have you configured eDirectory to support GSSAPI?
Errors for GSAPPI show in the ndsd.log file on the eDirectory server.
You can also enable +LDAP and +NMAS trace in ndstrace to see all communications for GSAPPI.
This may also be helpful.