I have a requirement to validate if a given user can login to a machine. I don't know their password, but the script can elevate to root using sudo. All the users are AD accounts using SSSD.
Everything I've found just validates if the user is valid or not, such as using
id -u. Doing sudo -lu doesn't work if the user has never logged in before and only shows their sudo permissions. I've also tried using ldapsearch, but that only queries the AD server to see if they have the correct profiles, but not necessarily on that server.
Create in the Domain a group with the users you want to allow in the machine and use it in the key simple_allow_groups explained below.
In the /etc/sssd/sssd.conf Add/Modify the following keys:
access_provider = simple # This will allow you to control who can log in the computer using the simple_allow_groups.
simple_allow_groups = groupname1, groupname2 # Domain groupnames allow you to limit the log on permission for just the members of the groups in this option.
Edit the sudoers (using visudo) and add:
%groupname1 ALL=(ALL) NOPASSWD: ALL
This will allow the user to run any command. If you want to limit the commands allowed, see the examples in the sudoers file.
Related
I created a user account on Amazon Linux Instance with root user. I found that if I create a user account(Example: ec2-user) that account will not have execute and write permissions on Hadoop Files System, Hive, Pig and other tools which are installed on Amazon EMR. If I have to give them explicit permissions I have to create a group which has permissions equivalent to superuser(root) account and add users to that group. Is there any other way I can set up access for those accounts to HDFS, Hive and Pigs etc.
Also while logging in as user the Linux command prompt is not prompting to enter any password even though I gave password for the user account while creating it. Is there anything configuration changes I need to make in /etc/ssh/sshd_config file?
Your question is not that clear to me.
But, let me attempt with whatever I suppose I understood.
Hadoop when security is enabled needs to have security for each user. It seems your user needs a separate space for writes and executions i.e. a Home directory.
First login as 'hdfs' user in a terminal and then create a home directory for your user in HDFS. Please check if you have a directory called /user/{yourUser}. If, not create that. Then, make sure you make {yourUser} the owner of /user/{yourUser}.
We have setup our account policies in PAM to follow the RHEL7 STIG guidelines http://rhel7stig.readthedocs.io/en/latest/. We do have some service accounts where their passwords are empty and use SSH keys to login. After the 60 days the service accounts password expire and get disabled. This is not the behavior I was expecting for a passwordless account, I did not think the password expiration would have applied to passwordless accounts. How do I tell PAM not to expire passwordless accounts?
In login.defs
PASS_MIN_DAYS 1
PASS_MAX_DAYS 60
PASS_WARN_AGE 7
FAIL_DELAY 4
In /etc/default/useradd
INACTIVE=0
Since the system doesn't care if these accounts have a password or not. You'll have to set PASS_MAX_DAYS to 99999 or what ever seem appropriate for these accounts.
Looks like I need to create these accounts as system accounts. From the useradd man page...
System users will be created with no aging information in /etc/shadow - https://linux.die.net/man/8/useradd
Example command.
useradd testuser --system
If you're using Ansible you can specify system in the user module.
- user:
name: testuser
group: testuser
system: yes
The result is visible in /etc/shadow. Notice no password max age entry for the testuser.
[root#localhost ~]# useradd testuser --system
[root#localhost ~]# grep testuser /etc/shadow
testuser:!!:17417::::::
[root#localhost ~]# grep ryan /etc/shadow
ryan:*:18976:1:60:7:0::
PAM solution offers a secure, streamlined way to authorize and monitor
all privileged users for all relevant systems.
IT teams commonly share root, Windows Administrator, and many other privileged credentials for convenience so workloads and duties can be seamlessly shared as needed. Now, with multiple people sharing the same account password, creates security, auditability, and compliance issues. Privileged accounts and credentials may be managed differently across various organizational silos, leading to inconsistent enforcement of best practices. Applications and service accounts frequently possess excessive privileged access rights by default, and also suffer from other serious security deficiencies.
The solution can be: "UsePAM no"
The solution can be: Set the users password to never expire
You might not want to change your PAM or sshd_config for compliance
reasons.
You might be using PasswordAuthentication no in sshd_config
You might have randomized passwords.
You might even have implemented CIS compliance.
Still if your users get the prompt, then root can tweak the password changed date:
for user in `grep ":x:[0-9]\{4\}" /etc/passwd|cut -d: -f1`; do chage -d today $user;
Attaching a few references:
https://access.redhat.com/solutions/5447861
https://documentation.suse.com/sles/15-SP2/html/SLES-all/sec-sec-user-management.html
Final Thoughts:
I believe that we need to keep our accounts authenticated to avoid any 3rd party or other irrelevant users accessing our data & information for the reason, that we may have confidential data that we may want to protect from diverse eyes that are on the web.
Also, you may take a look at this answer, if you need an another perspective of my answer (https://stackoverflow.com/a/46120833/18154805)
I am attempting to integrate a standalone product into an LDAP environment.
I have a RHEL 6.7 system that is configured for ldap authentication (via sss) that I need to programmatically add local users and groups to.
The input xml file has a list of users and groups with their group membership, login shell, user id and group id that should be used.
Now comes the problem, I have a Perl script that uses the XML file to configure the users and groups, it uses the getgrnam and getpwnam to query for users and groups then makes a system call to groupmod/groupadd and usermod/useradd if the user exists or not. I found that if LDAP has a group the same name as the group I am trying to create my script will see the group as existing and jump to the groupmod instead of groupadd. Then group binaries will only perform operations on local groups, and fail because the group doesn't exist locally. NSS is setup to check files then sss, which make sense why getgrnam returns the ldap group.
Is there a way to have getgrnam and getpwnam only query the local system without having to reconfigure nsswitch.conf and possibly stop/start SSSD when I run the script?
Is there another perl function I can use to query only local users/groups?
Short answer is no - the purpose of those function calls is to make the authentication mechanisms transparent. There's a variety of things you could be using, and no one wants to hand roll their own local files/ldap/yp/nis+/arbitrary PAM authentication mechanism.
If you're specifically interested in the contents of the local passwd and group files, I'd suggest the answer is - read those directly.
When I create a user on Gitlab, it creates a regular user on linux and it can login using a regular SSH protocol with same password an user.
How can I disable the SSH login using SSH to desired users? All my server is exposed to that users.
Thank you
Edit the sshd_config file adding this line
DenyUsers username1 username2 username3 username4
DenyUsers
separated by spaces. Login is disallowed for user names that
match one of the patterns. â*â and â?â can be used as wildcards
in the patterns. Only user names are valid; a numerical user ID
is not recognized. By default, login is allowed for all users.
If the pattern takes the form USER#HOST then USER and HOST are
separately checked, restricting logins to particular users from
particular hosts.
Read more: http://linuxpoison.blogspot.com/2008/08/how-to-deny-ssh-access-for-certain-user.html#ixzz3QkT71bsV
In case you need more than just the login, you can now block SSH as a all:
See GitLab 15.1 (June 2022)
Block Git access protocols at group level
To improve security, you can now block Git access protocols that you don’t use at the group level.
This is similar to the GitLab administrator setting, but can now be set per
group.
By default, both HTTP(S) and SSH are enabled.
In your group’s Settings > General > Permissions, scroll to Enable git access protocols and remove any protocols you don’t use.
See Documentation and Issue.
I am trying to come up with a best approach for creating a user called appuser in Ubuntu. The reason to create this user is:
1. This user will be used to install and start applications like Tomcat, MySQL etc.
2. Other users will login to system using their account. Then using su appuser, they should be able to login to this user and manage tomcat, mysql etc.
What is the best practice to create this user?
1)Give 755 permission to mysql and tomcat folder so any one can read and execute application but dont write or modify the data.
2)also provide grant permission to mysql DB for users.
OR
those having full permission to application of tomact or mysql other user(new users) also part of that group.
OR
you can use ACL (access control list) for the same.