posted Nov 1, 2015, 3:49 PM by Joshua S
[
updated Nov 10, 2015, 1:36 PM
]
This tutorial will link the Sudoers configuration to an LDAP server using OpenLDAP. This will allow for centralized authentication and authorization. Essentially, this will allow you to extend Sudo control to users and groups defined within your LDAP structure. There is even a way to implement Sudoers within LDAP (replacing or augmenting the Sudoers file), but that goes beyond the scope of this tutorial.
With any of the Dabbles on this site, if you have questions, suggestions, or thoughts, please feel free to send me an eMail (I'm still working to figure out how to enable comments on Google Sites -- suggestions would be appreciated)!
- RaspberryPi – The actual RaspberryPi hardware this will all be built around. In this tutorial, a Raspberry Pi 2 is used and has a memory card with the Raspbian operating system pre-installed.
- PuTTY SSH Client – PuTTY is a free and open-source terminal emulator, serial console and network file transfer application. It supports several network protocols, including SCP, SSH, Telnet, rlogin, and raw socket connection. Other SSH tools can be used, but this tutorial will leverage PuTTY.
Prerequisites: - Install Raspbian on a memory card for the Raspberry Pi – for a tutorial to do this, try:
- Configure Raspbian so the basic setup is complete. For a tutorial to do this, try:
- Shrink the Raspbian operating system to remove unused components thus increasing efficiency and decreasing the attack surface. For a tutorial to do this, try:
- Configure a DNS server to allow for name based addressing which is managed centrally. For a tutorial to do this, try:
- Configure an LDAP server to allow for centralized authentication and authorization which is managed centrally. For a tutorial to do this, try:
- Configure an LDAP client on the Pi to allow for centralized authentication and authorization -- managed centrally.
- Update Raspbian to the latest software versions. This should be periodically and prior to making any changes to the RaspberryPi. For a tutorial to do this, try:
Project: - I know I said this guide was going to be comprehensive and not skip any steps, so what better way to start this off than by skipping steps. I am not writing out instructions for the following (and illustrating from XKCD):
- Buying a MicroSD Card
- Buying a RaspberryPi
- Finding the IP Address of your Pi
- This can be done in many ways, including on your router or using an IP scanner such as (AngryIP Scanner or NMAP) -- if there are requests from the "Contact Me" form; I'll look to create a tutorial for this.
- Obtaining and installing PuTTY
- Using PuTTY (or the SSH client of your choice) enter the IP Address or DNS Name of the RaspberryPi.
- If this is the first time you connect, you will get a warning that the RaspberryPi's host key is unknown. Click "Accept" or "Connect Once" to proceed with the connection.
- Once connected, log onto the Pi using the credentials you created. If you have not defined your own credentials, you should, but these are the default credentials:
- UserID: pi
- Password: raspberry
- OK, now that we're connected, let's open the /etc/sudoers file with nano to make our changes. It should probably be noted, the method shown here is not preferred by some -- it is very important not to corrupt the main sudoers file as this will essentially leave the pi unusable and this method risks corrupting the main file. Alternate methods include creating additional sudoers files to be placed in the /etc/sudoers.d/ directory, but this also creates complication in this configuration thus I choose to use the simpler more streamlined approach.
- Initially, we need to define a set of Aliases. For argument sake, this is similar to defining constants in programming. It lets us define these once at the top, reference them often below, and easily change them in the future if needed.
- We'll start with creating a Host Alias -- essentially if we ever integrated multiple computers into using the same sudoers file -- or replicated one file out to multiple hosts -- this would be very helpful. In this case, we're simply defining an alias out of best practice. Let's add the following line in the Host alias specification section:
Host_Alias HA_LOCALHOST = 127.0.0.1
- OK -- now let's define our User Alias -- this let's us use local and LDAP users and groups. To do this, let's add a few lines to the User alias specification section. Note, when you put a % in front of a name, that's represents an LDAP group. For example, the group named GI_PS-Jarvis_Admins would be entered as %GI_PS-Jarvis_Admins.
User_Alias UA_INFR_ADM_BUILTIN = root, pi
User_Alias UA_INFR_ADM_LOCAL = %GI_PS-Jarvis_Admins
- The Command Alias comes next. This allows us to control which commands a given user has the rights to execute using sudo. This is really helpful if we want to give elevated privileges to a service account or a person to do a specific task -- maybe to update software, but we do not want to give full root access to all commands. Let's enter these Command Alias below. Note -- knowing how to do this is good, but standard configuration may not include this -- I'm building this out in advance for future projects that may leverage this capability.
Cmnd_Alias CA_APPL_OPR_BACKUP_OS = /sbin/reboot
Cmnd_Alias CA_APPL_SEC_INFRAMAINT_OS = /usr/bin/apt-get
- We now need to add a new section to the default sudoers file for Runas Aliases. By default the sudo command allows the user to issue any command as any user. By restricting this using a Runas Alias, you are able to require the command be run as root or another user with the desired access or authority. Enter the following lines:
# Runas alias specification
Runas_Alias RA_ROOT = root
- With each of the alias sections complete, we now need to enter the actual permission configurations. Let's leave the raw configurations alone, but enter the following lines for the custom configurations. Note, each specification uses the following format:
- <User_Alias> <Host_Alias> = (<Runas_Alias>) <Option>:<Cmnd_Alias>
UA_APPL_OPR_BACKUP_OS HA_LOCALHOST = (RA_ROOT) NOPASSWD: CA_APPL_OPR_BACKUP
UA_APPL_OPR_INFRAMAINT_OS HA_LOCALHOST = (RA_ROOT) NOPASSWD: CA_APPL_SEC_INFRAMAINT_OS
UA_INFR_ADM_BUILTIN HA_LOCALHOST = (ALL) NOPASSWD: ALL
UA_INFR_ADM_DOMAIN ALL = (ALL) NOPASSWD: ALL
UA_INFR_ADM_LOCAL HA_LOCALHOST = (RA_ROOT) NOPASSWD: ALL
- Well done! The basic configuration is complete. Now make sure you update this to include your LDAP groups and users along with your desired configurations.
|
|
