Print 
PDFI was working on some more Yubikey token implementations last night and I was asked “How can I only let people in a specific user group login to my server?”
This is the perfect example of what “host based access control” is designed to address.
Every operating system will use host based access control at some point.
If you take Microsoft Windows for example, you will be unable to login to a server unless your user is a member of a specific security group.
With Microsoft Windows, the host based access control, or HBAC as it is commonly referred to, is managed by Active Directory.
With Red Hat Enterprise Linux, HBAC can be managed in a similar way if you are using the FreeIPA identity management solution.
Of course, not everyone has a straight forward homogeneous infrastructure.
For example, many of you may have your Linux infrastructure directly connected to Microsoft Active Directory as your identity management solution.
This article will go through how to use host based access control (HBAC) on Red Hat Enterprise Linux systems that are connected to Active Directory.
If you are looking for information about integrating Linux directory into Active Directory, you can find out more here.
In this example, I will be using the below systems
Member Server Name: server01 Active Directory Security Group: server_admins Active Directory User: user1
Setup
What we will be setting up is a common scenario of “Only members of the security group “server_admins” should be able to log in to server01″.
To achieve this, its a simple case of editing /etc/security/access.conf.
Go ahead and edit your access.conf file so the last two lines appear as follows.
[root@server01 ~]# vi /etc/security/access.conf + : server_admins : ALL - : ALL : ALL
You will note, that the above works on a first match basis. This is very important to verify and test before you logout, just incase you lock yourself out in the process.
If a user is attempting to login and is not a member of the “server_admins” group, it will fall to the next rule. In this case, it is a catch all rule to block all forms of login.
In short, in order to login to this server now, you must be a member of the “server_admins” group.
Of course this is a very simple explanation of how host based access control functions, however to meet our original goal, this is all we need to do.
If you wish to add more options, like allowing certain users or groups but only from specific networks, or even only at particularity times, you will also be able to achieve this.
The access.conf config file is very well documented and has many good examples to base your configuration against.
Verify
Once you have set up your own specific rules, you should verify your configuration.
If I try to login as a user that is not a member of the “server_admins” group, for example: via an SSH session, the output on the console will appear as follows
[mac@localhost ~]$ ssh user1@server01 user1@server01's password: Connection closed by server01 [mac@localhost ~]$
If you tail the secure log on your server (tail -f /var/log/secure), the log output will look similar to this
Jan 12 22:42:07 server01 sshd[2649]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.0.2.254 user=user1 Jan 12 22:42:07 server01 sshd[2649]: pam_krb5[2649]: error reading keytab 'FILE:/etc/krb5.keytab Jan 12 22:42:07 server01 sshd[2649]: pam_krb5[2649]: TGT verifiedJan 12 22:42:07 server01 sshd[2649]: pam_krb5[2649]: authentication succeeds for 'user1' (user1@NT.EXAMPLE.COM) Jan 12 22:42:07 server01 sshd[2649]: pam_access(sshd:account): access denied for user `user1' from `10.0.2.254' Jan 12 22:42:07 server01 sshd[2649]: pam_winbind(sshd:account): user 'user1' granted access Jan 12 22:42:07 server01 sshd[2650]: fatal: Access denied for user user1 by PAM account 12 22:42:07 server01 sshd[2649]: Failed password for user1 from 10.0.2.254 port 43792 ssh2
Here it clearly states “Access denied for user user1 by PAM account configuration”,
this verifies that our new host based access control configuration is now in play.
If I now add user1 to the “server_admins” group, not only will my login shell look as follows
[mac@localhost ~]$ ssh user1@server01 user1@server01's password: [user1@server01 ~]$
but the logs in the secure log file will also appear as follows.
Jan 12 22:49:16 server01 sshd[2658]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.0.2.254 user=user1 Jan 12 22:49:16 server01 sshd[2658]: pam_krb5[2658]: error reading keytab 'FILE:/etc/krb5.keytab' Jan 12 22:49:16 server01 sshd[2658]: pam_krb5[2658]: TGT verifiedJan 12 22:49:17 server01 sshd[2658]: pam_krb5[2658]: authentication succeeds for 'user1' (user1@NT.EXAMPLE.COM) Jan 12 22:49:17 server01 sshd[2658]: pam_winbind(sshd:account): user 'user1' granted accessJan 12 22:49:17 server01 sshd[2658]: Accepted password for user1 from 10.0.2.254 port 45922 ssh2 Jan 12 22:49:17 server01 sshd[2658]: pam_unix(sshd:session): session opened for user user1 by (uid=0)
You’ll notice that there is no fatal or failed messages this time. This shows that everything is working well.
You can customise your own HBAC rules for as tight or as flexible as you need them to be. Just keep in mind that all your specific rules you wish to allow come before the final catch-all rule of denying access.