2

I have been working on getting /etc/security/access.conf to work as expected and so far every user can still login. Details are below.

I added the following line to /etc/pam.d/login

account required pam_access.so

I also added the following lines in /etc/security/access.conf

+ : root : ALL
+ : group_name : ALL
- : ALL : ALL

group_name is a group inside of our LDAP server (FreeIPA). Any user is still able to login regardless if they are a part of ${group_name}. I can SSH into the server without any issues from any user. Can someone help point out where I am incorrect at? I am running RHEL 6.5. Thanks

| improve this question | | | | |
  • Maybe this isn't the proper way of restricting logins to one group including root...if someone has other suggestions I am open to new ideas. Thank you. – Azifor Mar 15 '16 at 21:06
  • If you're using FreeIPA you should probably be doing your HBAC in that rather than configuring it on the host itself. – Bratchley Mar 15 '16 at 21:40
  • 1
    Please read this for CLI howto, there are analogous steps in the web ui though. – Bratchley Mar 15 '16 at 21:42
  • 1
    One use case for access.conf would be if there were only a particular service that you wanted to add these restrictions to. It doesn't sound like you want to be that specific, though. – Bratchley Mar 15 '16 at 21:43
  • @Bratchley Weird that they would have this catch-all access-all rule on by default that overrides all other rules... I will look into using this feature more. Thank you. – Azifor Mar 15 '16 at 21:57
3

From man access.conf:

Each line of the login access control table has three fields separated by a ":" character (colon): permission:users/groups:origins

The first field, the permission field, can be either a "+" character (plus) for access granted or a "-" character (minus) for access denied.

The second field, the users/group field, should be a list of one or more login names, group names, or ALL (which always matches). To differentiate user entries from group entries, group entries should be written with brackets, e.g. (group).

So your /etc/security/access.conf should look like this:

+ : root : ALL
+ : (group_name) : ALL
- : ALL : ALL
| improve this answer | | | | |
  • Sorry for the late accepted answer. Hard to go back and verify at this time but i believe this was the overall solution – Azifor Feb 22 '18 at 11:39
2

mrc02_kr is right, I think.

+ : root : ALL
+ : (group_name) : ALL
- : ALL : ALL

But this leaves out an important step: you have to tell authconfig that you want to enforce PAM access control. Before doing this, the access.conf file does nothing.

* A WORD OF CAUTION: * What I am about to describe works on my systems, but it is very dangerous, and may leave you locked out of your system if you do it incorrectly or your setup is different. Take the precaution of having an open console session to repair problems. If this is a VM, take a snapshot. Make backups. Use a test box before doing it an anything you care about. Do not reboot while having problems. As I have no FreeIPA experience, this might bork up your setup. You have been warned. OK, back to the answer:

First, I made a backup of my authconfig:

authconfig --savebackup authconfig_working_outofbox01

Next, I added a local group for accounts authorized for ssh (but I am fairly sure that this will work for groups in FreeIPA... but not 100% sure. I have used a configuration using a LDAP group... it has just been a while.)

Next, I updated the acces.conf file, adding:

+ : (ssh_auth) : ALL
- : ALL        : ALL EXCEPT LOCAL

Next, I edit the file: /etc/sysconfig/authconfig, changing

USEPAMACCESS=no

to

USEPAMACCESS=yes

Lastly, tell authconfig to update:

authconfig --updateall

Now test every user type to be sure you got the results you wanted. This seems very under documented on the internet, making me think that few shops use this. I like it as a solid step in hardening systems.

| improve this answer | | | | |
1

If you are running openSSH and are okay to utilize ssh restrictions on your users, you can edit /etc/ssh/sshd_config file and add one or more of these following lines

DenyUsers
AllowUsers
DenyGroups
AllowGroups

but be very careful while using these. If you use AllowUsers directive, whoever is NOT on that line, will automatically be denied and making typo while editing, may block your own access as well. So, always have a back door, like a console and root password before you modify these settings.

I am quite sure it is clear what these keywords/directives in the sshd config file does. If in doubt, check man page for sshd or search for these words using google. Myriad of documents exist.

Last but not the least, don't forget to restart sshd once you complete editing the config file

| improve this answer | | | | |
  • Thank you Mel. I have attempted this, but the AllowGroups does not appear to pull from ldap and does not let any users specified in that group to login. – Azifor Mar 15 '16 at 21:19
  • Oh, I did not see the LDAP portion of your question previously. In that case PAM auth is your best bet but I know it is not trivial to get it working. – MelBurslan Mar 15 '16 at 21:20
1

RHEL 6.5 supports SSSD. You can set an access filter under your domain/LDAP definition of /etc/sssd/sssd.conf .

domains = LDAP
...
[domain/LDAP]
id_provider = ldap
auth_provider = ldap
...   
ldap_access_filter = memberOf=cn=MyGroupOfUsers,ou=MyOU,o=MyOrg
...

Then be sure to restart sssd

service sssd restart
| improve this answer | | | | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.