I have an existing Datastax Cassandra setup that is working. We just added authentication to the system and now we can log in with our AD accounts. This is very nice and certainly works. However applications need to use a hard-coded username/password in order to connect.
In SQL Server we were able to setup a user to run the service as and then it would connect and work through AD. However in Cassandra it is not the same.
If I don't want to include usernames and especially passwords in my app.config files what are my options?
You can use authentication via LDAP with DSE (Datastax Enterprise), so the authentication stage is done with LDAP instead of the internal authentication in DSE which you're using at the moment. Note that my comments here apply to DSE5.0 onwards but you can use LDAP auth with earlier versions of DSE from 4.6 onwards.
The documentation (link below) covers this. The basic steps are as follows:
Configure your authenticator in the cassandra.yaml to use the DSE authenticator
authenticator: com.datastax.bdp.cassandra.auth.DseAuthenticator
Create an internal role in cassandra to map to the LDAP group(s) in your LDAP server using the CREATE ROLE command
Ensure all the users you need to use map to the relevant LDAP group (part of your LDAP config)
Configure your dse.yaml to have the correct settings for your LDAP server
Restart the DSE process for the settings to take effect
The following documentation gives some good examples and background information:
https://docs.datastax.com/en/latest-dse/datastax_enterprise/unifiedAuth/unifiedAuthConfig.html
https://docs.datastax.com/en/latest-dse/datastax_enterprise/sec/authLdapConfig.html
Note: when configuring the dse.yaml note the comment in the docs regarding user_search_filter:
When using Active Directory set the filter to (sAMAccountName={0})
Related
According to the documentation, one prerequisite for using NiFi CLI against a secured NiFi instance is to configure proxy user request for the node's identity (e.g. CN=localhost, OU=NIFI).
https://nifi.apache.org/docs/nifi-docs/html/toolkit-guide.html#prerequisites-for-running-in-a-secure-environment
I understand how to configure it through the NiFi web user interface. However, is it possible to do the same through scripting?
The reason is that I am working on a NiFi installation script, and I would like to install NiFi and configure users/policies in one go if it is possible.
Thank you!
If you are trying to use NiFi CLI to setup NiFi itself, then you're only real option is for NiFi CLI to perform operations as the Initial Admin identity.
It then depends how NiFi is configured to perform authentication, meaning where is your initial admin identity coming from. Is it a DN from a client cert, a user in LDAP, a kerberos principal, etc?
If it is a client cert, then you can just configure NiFi CLI to use that cert and it should work.
If it is a LDAP user, then you need to have NiFi CLI use one of NiFi's server certs to proxy the LDAP user.
Both of these scenarios are shown in the docs:
https://nifi.apache.org/docs/nifi-docs/html/toolkit-guide.html#security-configuration
Basic username/password authentication for ELK, i was able to achieve using searchguard on windows platform.
Now i am trying to establish secure communication. I have performed the following changes,
In elasticsearch.yml
searchguard.ssl.http.enabled: true
searchguard.ssl.http.keystore_filepath: D:\Softwares\ELK\elasticsearch-5.4.0\elasticsearch-5.4.0\config\CN=localhost-keystore.jks
searchguard.ssl.http.keystore_password: 221749a2add117cf889f
searchguard.ssl.http.truststore_filepath: D:\Softwares\ELK\elasticsearch-5.4.0\elasticsearch-5.4.0\config\truststore.jks
searchguard.ssl.http.truststore_password: 6d6cf1cc017dc874960b
searchguard.authcz.admin_dn:
- CN=sgadmin
searchguard.ssl.transport.keystore_filepath: D:\Softwares\ELK\elasticsearch-5.4.0\elasticsearch-5.4.0\config\CN=localhost-keystore.jks
searchguard.ssl.transport.keystore_password: 221749a2add117cf889f
searchguard.ssl.transport.truststore_filepath: D:\Softwares\ELK\elasticsearch-5.4.0\elasticsearch-5.4.0\config\truststore.jks
searchguard.ssl.transport.truststore_password: 6d6cf1cc017dc874960b
In Kibana.yml
elasticsearch.url: "https://localhost:9200"
elasticsearch.username: "admin"
elasticsearch.password: "admin"
If i login to kibana, using http://localhost:5601, it asks for username and password. I dont know what credentails to enter here. i tried admin/admin. Its not working. Before i gave searchguard.ssl.http.... configurations, admin/admin was working fine.
After i added all the searchguard.ssl.http related configuration, the credentails are not working.
I am sure there is some other configuration in kibana.yml w.r.t searchguard configuration. I am not able to find it online. Can any one please help me here on what is missing.
Enabling TLS on the REST layer does not have any impact on user authentication/authorisation. The only difference is:
If you enable TLS on REST layer, only HTTPS access is allowed. You will see an error message if you try to access ES with HTTP
If you disable TLS on REST layer, only HTTP access is allowed. You will see an error message if you try to access ES with HTTPS.
Search Guard will authenticate the credentials against the configured authentication backend in sg_config.yml. If you use the default configuration that ships with Search Guard, it will use the internal user database and the users defined in internal_users.yml. The default "admin" user has full access to all indices and types, so you should be able to use this user to log into Kibana. If you need a user with limited access, the corresponding demo user is "kibanaro". Please refer to internal_users.yml to see all demo users.
Since ES 5.0.2, you need to install the Search Guard Kibana plugin for full authentication and session support. You can find the plugin on the corresponding GitHub repository. You install it like any other Kibana plugin, for example:
bin/kibana-plugin install https://github.com/floragunncom/search-guard-kibana-plugin/releases/download/v5.4.3-3/searchguard-kibana-5.4.3-3.zip
If you do not need advanced stuff like multi-tenancy or JWT Single Sign-on, it should start and work out of the box.
If this does not help, please post the output of your Elasticsearch log files when trying to log in.
Disclaimer: I work for floragunn, makers of Search Guard.
I am trying to kerberize my RESTful backend and I am not seeing anywhere in the GSS-API documentation how could I add a user/service - i.e., I understand the authentication process with GSS-API, but not the signup process. To make my question simpler : kinit is the command line tool used to add principals, is there an equivalent for GSS-API ? If the answer is no - should I go and look at the kinit source code and port it to my project (using system("kinit ...") raises security questions/problems so I am not thinking about using it) ?
Users should be added to the Kerberos database using API provided by Kerberos Distribution Centre. In Microsoft Active Directory, KDC uses LDAP as its database, so users can be added/removed using JNDI, as described here: http://cyberlizard.livejournal.com/120080.html.
kinit not a tool for adding users but for (simply speaking) "logging in", or (technically speaking) it's a tool that "obtains and caches an initial ticket-granting ticket for principal" (see: http://web.mit.edu/kerberos/krb5-devel/doc/user/user_commands/kinit.html), i.e. it takes credentials (i.e. for example principal and password, connects to KDC and tries to receive initial TGT from it. Client).
I'm using CDH 4.5. I installed Impala manually (without Cloudera Manager). I've configured LDAP with Impala (using the instructions at http://www.cloudera.com/content/cloudera-content/cloudera-docs/Impala/latest/Installing-and-Using-Impala/ciiu_ldap.html).
I've added ldap_uri to the /etc/default/impala file. But how do I configure the ldap bind username?
With the current configuration, if I start impala shell, I am able to login using the ldap bind username. But how do I login using actual users from AD? I need to configure the ldap bind username and / or ldap password so that impala automatically connects using the bind username and when I start the impala shell, I can connect using actual user names.
Thanks.
Apparently we don't have to use the ldap bind name. I'm able to log in with user name as "someone#abc.com" where someone is the user name in AD and abc.com is the AD search base.
Is it possible to use LDAP authentication with Liquibase?
If not, how have others solved the problem of automating changes to production database schemas using Liquibase (yet still keeping the database credentials secure)?
LDAP is used for server-side authentication. Not all databases support it, for example MySQL only supports it in it's Enterprise version.
Securing the credentials, used by clients like liquibase, falls into two categories:
Protecting data in transit
Protecting credentials at rest
To protect credentials in transit, I'd recommend using a JDBC driver which supports SSL. Some JDBC drivers support this feature, for example MySQL. Another approach is to tunnel the JDBC traffic over a SSH tunnel.
Protecting credentials at rest (in configuration files) is more difficult and depends on how you plan to invoke liquibase. If you're using ANT, I'd suggest using the answer to this question on how to read encrypted property files.