Is there anyway that we can give security measures for nifi, like any username and password for the nifi UI page. And also anyway to give storage for the configuration made in the NIFI UI page.
Need some suggestion on this issue.
All user authentication and authorization mechanisms are only available once TLS is enabled. This was an intentional design decision because entering sensitive user credentials over a plaintext HTTP connection is unsafe and exposes the user to many opportunities to have those credentials, which unfortunately they may reuse for other services, stolen.
After enabling TLS for the NiFi application, LDAP, Kerberos, OpenID Connect, Knox, and client certificates are all available as authentication mechanisms.
With the default settings you can point a web browser at
https://127.0.0.1:8443/nifi
The default installation generates a random username and password, writing the generated values to the application log. The application log is located in logs/nifi-app.log under the installation directory. The log file will contain lines with Generated Username [USERNAME] and Generated Password [PASSWORD] indicating the credentials needed for access. Search the application log for those lines and record the generated values in a secure location.
The following command can be used to change the username and password:
$ ./bin/nifi.sh set-single-user-credentials <username> <password>
Related
I am integrating an application with LDAP in my organisation.
I am implementing HTTPS to send the password from the frontend to my application server, and then forwarding the password from my application server to the LDAP server using TLS. This keeps the password safe in transit.
However there is still the problem that my application server is still able to see the password in plaintext before it forwards the password to the LDAP server.
If I hash it on the front end then the password will not match the password on the LDAP server.
Is this a risk that I need to accept in order to integrate my application with LDAP? Or am I implementing this incorrectly somehow?
My application server is a python flask application and I am implementing LDAP3.
Thanks in advance.
For the question:
Is this a risk that I need to accept in order to integrate my
application with LDAP?
Yes.
The use of SASL Mechanisms which are supported by most LDAP Server Implementations can SASL authentication, this is However, this requires the LDAP Client (DUA) to be able to present an encoded value that contains the SASL mechanism name and an optional set of encoded SASL credentials.
Maybe you could use SASL with a ServerLess Architecture?
Regardless of the technology implemented, any password based authentication would require the user providing credentials which, at some point need to be gathered and therefore subject to this risk.
THe use of OpenID Connect could limit the exposure so the to the OpenID Provider's Authorization Server; but the risk is still present.
WebAuthn eliminates passwords and may be an option.
-jim
My Java app for Windows requires uploading results to a server using an ftp client. Currently, I have the port, sever URL, username and password in an ini file that the app installer places on the users computer. I'm concerned that a user can easily open the ini file and see these credentials and thus be able to log in to my account on the server. I'm considering encryption of the username & password. Or, just ask the user to provide his/her own credentials, perhaps using Google or other free outgoing service? Are there better ways of handling this?
With SFTP, a connection can be authenticated using a couple different techniques one of them involves using Public / Private Key Pair.
With key-based authentication, you will need to generate a SSH private key and public key beforehand. If you want to connect to a partner's SFTP server, you would then send your SSH public key to them so they can load onto their server and associate with your account. Then, once you've connected to their SFTP server, your client software will transmit your public key to the server for authentication. If the keys match, along with any username/password supplied, the authentication will succeed.
Finally got back to this issue, and here's what I've learned.
First, I've decided to provide FTP access on my hosting server with a "home" directory so the user can't access site data other than his own. I will provide the username and password to the user. Second, the username will be stored in the Windows app database. Third, neither the password or a SaltHash of that password will be stored in the database. Thus the user must type in the password on each FTP upload.
The reason for not using SaltHash because is it's pointless. I.e., if I did go to the trouble of creating and storing a SaltHash, the user would still have to type in a password. That entered password could be salt hashed and compared with the stored SaltHash to be sure it's valid but that's no better than getting an acceptance or rejection from the server.
Or, what am I missing?
TL;DR -- How do I override all internal passwords for GitLab (non-admin, non-external) users so that they cannot change their password and must use SAML to login?
We have an internal GitLab server that is set to authenticate via SAML to an AD which has MFA enabled (Azure reverse proxy).
Security has found out that users are setting a local password in GitLab and getting around MFA and logging locally into the server.
They're asking me to remove the login screen completely. I rather set an internal password for non-admin and non-external users, and somehow disable the password recovery (blocking email?). Is that possible?
This is the closest thing I found but no easy way to script that as far as I can see. https://docs.gitlab.com/ee/security/reset_root_password.html
I haven't really have had much experience with Kerberos but I am trying to set up SSH authentication with AD on one of my servers using sssd. I have followed the instructions on the sssd documentation here and got it working but I am struggling to understand why I need a keytab file to set this up?
I've been doing a bit of reading about Kerberos lately and it appears you only need to create a keytab file on the server when the server needs to authenticate to AD without user interaction or when you need to implement SSO (when a user requests a ticket for that service).
I simply want my users to enter their username / password when logging in via SSH and have sssd authenticate this user against AD and create a TGT ticket for them. The funny thing is - even when I don't setup sssd and only set up the kerberos side I can run kinit and I get a ticket!
So my question is this: Can I set up SSH authentication using sssd without generating a keytab file on the server? if not then why not?
Your question in the Subject line "What is the reason for a Kerberos keytab file when setting up SSH authentication on a server?" boils down to a one-line answer: it allows for Kerberos single sign-on authentication to the Directory server by de-crypting the inbound Kerberos service ticket to "tell" who the user is. As far as your other question, "Can I set up SSH authentication using sssd without generating a keytab file on the server?", the answer is yes, you can. But you will be prompted for a username or password whenever you connect to the SSH service, unless you choose to cache the password in whatever SSH utility you might be using to connect. Caching the password though, in such a method, is not considered to be "single sign-on".
For additional reference, you can read more about my article on Kerberos keytabs on Microsoft Technet: Kerberos Keytabs – Explained. I frequently go back and edit it based on questions I see here in this forum.
I'm trying to write a script which takes a username via argument and password via stdin. I'd like the script to contact the kerberos server and verify the password. I'm going to use this to authenticate perforce users via an auth-check trigger. I'm not too wedded to any particular language although bash and perl are already installed on the (centos 5) system concerned.
Any hints/suggestions would be much appreciated.
Thanks,
Fenster
This Perforce article has some useful links to get started.
http://kb.perforce.com/article/74
I think Kerberos saves a ticket on the machine you're authenticating on, so perhaps Perforce's SSO framework would be better. Check out this project:
http://www.assembla.com/spaces/sso-p4/wiki
Be aware that effectively verifying a password requires more than just doing kinit (an AS exchange). That is open to a KDC spoofing attack: the attacker hands you a password, then redirects your KDC request to his own KDC which says the password is OK.
The usual way to guard against this is for the verifier to have a service principal of its own; it kinits the user's principal, then uses the acquired TGT to obtain a service ticket for its own principal and verifies that ticket. This ensures that it is talking to the same KDC.
Just come across pwauth on google code. It can be configured to verify system passwords using the pam interface. It looks like its been designed with apache in mind but should work for any scriptable situation. Going to try and set this up this week. Will report back when i've tried it.
NB there are risks with exposing your system accounts so the link directs you to the risks page first.