I am able to authenticate radius users using radius server+pam+ssh with creating local user with blank password in linux.
Is it possible to authenticate radius users without creating users in local machine with blank password?
/etc/pam.d/ssh file as below
#%PAM-1.0
auth sufficient pam_radius_auth.so debug
auth sufficient pam_unix.so use_first_pass
auth required pam_auth_status.so
account sufficient pam_unix.so
account required pam_auth_status.so
session required pam_unix.so
You can authenticate the user without creating an entry for him in /etc/passwd and /etc/shadow files. But now , the user is not associated with any shell in '/etc/passwd' , so it can be of no use.
Do you want to launch a shell after authentication or you want the user just to be authenticated?
I found two nss libraries that could help in this case:
libnss-mapuser from Cumulus Linux.
libnss-ato
The general process is that these will map unknown (but authenticated) user to a single user template. Each user will get his/her own /home folder though but both libs have in common that the user id will be the same.
These packages are mainly targeted at network devices where there is no ldap setup done. Cumulus describes the setup nicely.
I recommend reading https://serverfault.com/questions/538383/understand-pam-and-nss to understand what is happening there.
Related
So far I have always been able to log in successfully via sso.
cf login -a url --sso
I need another way to log in for my pipeline script and tried the following command.
cf login [-a API_URL] [-u USERNAME] [-p PASSWORD] [-o ORG] [-s SPACE]
This command does not work with my user, nor with a technical user to whom all necessary roles have been assigned (M D A). I get the following message.
API endpoint: url
Password>
Authenticating...
Credentials were rejected, please try again.
Does anyone know how to solve this problem?
Or maybe an alternative to create a gradle task, for example, that can be executed in a jenkins pipeline.
At the end, I want to automate a deploy (to cloud) of an artifact with my Jenkins pipeline.
You provided —sso flag, so you shouldn’t see a password prompt. Instead you should be given the url to get a token.
Maybe your CF has been misconfigured and does not support SSO yet. I tried to fix the CF CLI to avoid this but it was oddly rejected https://github.com/cloudfoundry/cli/pull/1624
Try fixing your CF installation (it needs to provide some prompts), or skip the —sso flag usage.
Using --sso and -u/-p are not doing the same thing on the backend, and there's no guarantee that a user which can login through SSO is also set up to login as a user stored directly in UAA. UAA has multiple origin's from which users can be loaded, like SAML, LDAP and internal to UAA. When you use the --sso flag, you are typically logging in via a user from your company's SAML provider. When you use the -u/-p flags, it's typically LDAP or UAA, something UAA validates directly.
In order for what you are trying to do to work, you would need to have a user available with an origin in SAML (for --sso) and a user in origin LDAP or UAA (internal), and technically those would be two separate users (despite the fact that they may have the same credentials).
At any rate, if you normally login with the --sso flag and you want to automate work, what you really want is to get a UAA client that is set with the grant type of client credentials. You can then use cf auth CLIENT_ID CLIENT_SECRET --client-credentials to automate logging in.
Typically you don't want your user account to be tied to pipelines and automated scripts anyway. If you leave the company and your user get deactivated then everything breaks :) You want a service account, and that is basically a client enabled with the client credentials grant type in UAA.
I installed google two factor authentication on my linux server.
(thanks to: https://github.com/google/google-authenticator-libpam)
When I try to access root account via ssh, authenticator works fine.
Verification code: .....
Password: ....
[root#hostname] works fine :)
But!! access other user account and try to access root account using su,
authenticator only require password.
[user#hostname] whoami
user
[user#hostname] su
password: .....
[root#hostname] What?!!!
I set all config to default value.
How can I fix it??
This is the default way this works. Since you are using the google-authenticator-libpam module you are only adding two factor authentication to the actual external interface login via the addition of auth required pam_google_authenticator.so to the sshd config file.
The proper security implementation (or at least one of the proper ways) is to not allow external login for the root user, going one step further and locking down ssh to only allow login from users who have two factor authentication enabled is even better.
To do that you would add the following in your sshd config :
AllowUsers admin bob
To enable Google two factor authentication for su - you have to add following parameter at the end of file /etc/pam.d/su :
auth required pam_google_authenticator.so
Save it and try login using the normal user and then su -, it will prompt for verification code.
i.e. no need to restart sshd service.
I have a private hosted registry at www.myDockerRepo.company.com:2222. To login to this repository I follow these steps
docker login www.myDockerRepo.company.com:2222
username : xxx
password : ***
email : xyz#company.com
WARNING: login credentials saved in /home/vagrant/.docker/config.json
Login Succeeded
Can these credentials be saved before hand in the config.json so that clients dont need to manually enter these credentials n every login? What is the best practice to login to private registries?
Yes, you can manually add the creds to the config. Just copy the file over from a host that you already logged in with.
As far as best practices, they depend on the setup, but most common is to use a generic system account for your registry that is only used by the hosts, and then when setting up the hosts and installing docker, drop in the config file for that system user. Then all pushes and pulls from those servers will be with that account.
If you try and reuse a user account, things will break if that user changes their password. It also allows you to have different permissions for hosts, maybe pull only access vs push, etc.
I am trying to configure Grafana for my organization. I was able to configure LDAP and MySQL database pretty easily but when I try to invite a new user to an org in Grafana, it always asks the user to join Grafana.
This would be an OK behavior if at that point Grafana would authenticate against LDAP. Instead, it creates a new user in its own database. This would lead to conflict with LDAP in case the user's AD passwords changes.
This works perfectly when a user had previously logged in to Grafana. An invite sent after would directly take the user to login page.
Is it possible to do the same in case the user is not already registered in Grafana? I really want to avoid saving user credentials in Grafana database.
Any help would be appreciated. Thanks.
I am not a Grafana expert, but looking through the source code on GitHub it certainly seems that new user registration will not go through LDAP. This is obvious in the LDAP related configuration file where you see the read-only credentials needed to look up users in the LDAP directory. A read-only administrator in LDAP will not be able to create new users as this would be necessary during a registration step. The code also indicates that registration creates temporary users in the internal store.
Using the Jenkins OpenID plugin I'm able to configure Jenkins to use my Google Apps OpenID as a provider. Anonymous users are still able to access that application (they have read access only), but I want to have it so that users are forced to login using the Google App domain or they are denied access.
I'm currently using the Jenkins Authorization setting of "Logged in users can do anything", I've tried using the "Matrix based authentication" and denying anonymous users, assuming logged in users would still have permissions, is there a special group value I can use for "logged in users" in matrix based authentication?
It seems like "Matrix-based security" will only work for specific users when using Google Apps OpenID (I don't believe Google apps for domains has support for OpenIDTeam extension
Yes there is a special group you can use to do this but finding the information about how to do it isn't obvious.
If you hover over the 'Overall - Read' column on the Matrix-based security table you'll get the solution.
It states
The read permission is necessary for viewing almost all pages of Jenkins. This permission is useful when you don't want unauthenticated users to see Jenkins pages - revoke this permission from the anonymous user, then add "authenticated" pseudo-user and grant the read access.
I use the following technique in combination with the OpenID plugin which allows me to specify a Google Apps for Business domain to secure Jenkins with
Warning: Make sure you've got a backup of your installation before you start because if you get something wrong you may lock yourself out of your Jenkins. Unpicking the plugins and settings would take longer than just restoring from a backup.
Ensure your choice of OpenID provider is still working ok with your current 'Logged in users can do anything' setting
Select the 'Matrix based-security' mode for Authorization
Add a new 'authenticated' group (lower case 'a') to the Matrix-based security table.
Use the 'check all' icon at the right hand end of the new 'authenticated' row to tick all the permission boxes.
Use the 'check all' icon at the right hand end of the 'Anonymous' row to untick all the permission boxes.
Save the settings
Reload Jenkins
Now each time a user wants to see Jenkins they have to be already signed into their Google Account and no-one can get to see any Job names or views without login.
Hope this helps.