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
Related
I have setup my LDAP server with user details. I have setup my Ubuntu laptop to authenticate users from LDAP. The problem is, every time user tries to log in, Ubuntu tries to reach LDAP servers to authenticate. So when network connection is out, it shows authentication failed. What I want is when user logs in first time, Ubuntu authenticates from LDAP, and creates a local user profile, and stores credential somewhere on local. So when network connection is not available, it authenticates against last used credentials. And when system connects back to internet, it authenticates against LDAP.
Please help me with this. Let me know if any clarifications are required.
I have created LDAP Server, and my ubuntu system is already authenticating users against LDAP. I want to store the LDAP credentials to a local user once the user logs in for the first time, so that these credentials can be used for authentication when network connection unavailable.
If you are using SSSD as the LDAP client, enable its built-in credential caching. Take a look at options cache_credentials (for auth) and cache_first (for account information) in the sssd.conf(5) manual page.
If you are using nslcd as the LDAP client, install pam_ccreds for authentication caching and nscd for account information caching.
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>
I have problem integrating jFrog Artifactory with an Azure LDAPS.
Azure side is successfully configure, I get response by telnet on port 636.
Logs in the artifactory show this error:
Error connecting to the LDAP server:
org.springframework.security.authentication.AuthenticationServiceException:
User name.surname#bi****.de failed to authenticate
I understand that this error points to my user. But credentials for this user are 100% correct since I have enabled Azure Active Directory Services with user, enabled LDAPS and so on.
Can anyone specified in more detail what I was doing wrong on this picture below?
LDAP Integration screen
The search filter is incorrect, but the correct value will depend on what the users will log on with. If it's their AD username, you would use "sAMAccountName={0}" but the test ID you are using appears to be an e-mail address. To authenticate with your primary e-mail address, use "mail={0}" as the search filter.
Most likely "manager DN" / "manager password" needs a value as well. When you attempt to authenticate, the server connects to the LDAP service and binds with the "manager" account. It then searches for mail= and retrieves the fully qualified DN (FQDN) of the located object. The user supplied password is then validated by attempting to bind with the retrieved FQDN and user supplied password. If anonymous users have read access to the directory, you wouldn't need a manager dn/password. Anonymous read access is atypical for AD/Azure AD.
I use a "service" (i.e. non-user) account for my manager account -- using an actual user's account means someone has to come back and change the config every time the user updates their password. I set a long/complex password on service accounts and increase the password expiry time-frame so admins aren't re-configuring their applications monthly.
I have a case on my Ubuntu Linux 16.04 servers that I need your help with:
Current Scenario
A valid AD user logs in to the Ubuntu Linux server via SSH
That user adds his public key to ~/.ssh/authorized_keys for passwordless login
I disable/lock/delete the AD user to prevent him from logging in
The user was still able to login to the server, since his public key is still there!
Expected Scenario: If I disable/lock/delete a user's AD account (or his AD password expires), he shouldn't be able to login to any server with his AD account, even if his public key is installed there.
I have hundreds of servers, and it would be very difficult to track all the installed public keys.
Any solutions or workarounds for this without disabling PKI completely?
Note: I use PBIS Open to join my Linux servers to the AD domain.
The solution is to add this to /etc/ssh/sshd_config:
AuthenticationMethods "publickey,password" "publickey,keyboard-interactive"
This will require public key and then will ask the user to enter his AD password.
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.