by Leonardo Neves Bernardo

This article will discuss about security related issues at sudo environments. Will be evaluated advantages and disadvantages of to centralize sudo with LDAP back-end. Another issue summarized in this article is about taking care with content of sudo registers.

In the early days of UNIX, there were only two kinds of users: administrators and common users. Until now, this structure remained in the same model. Nevertheless, in our day by day activity, it is very common to meet some situations where it is necessary to delegate some responsibilities to operational groups and the others, who are not administrators nor common users. Some administrators do some insecure techniques like: sharing of root passwords, creation of users with uid 0, changes in file permission, and so on. These techniques are a solution for the immediate problem, but don’t follow least privilege principle.

Around 1972, the notable Dennis Ritchie invented the setuid bit. The setuid bit allows users to run an executable with the permissions of the executable’s owner. The most common situation is when an executable is owned by root. Programs must be carefully designed when the setuid bit permission is enabled, because vulnerable applications allow an attacker to execute arbitrary code under the rights of the process being exploited. After setuid bit creation, the division between root and other users starts to be broken. Unfortunately, to take advantage of this feature, it is necessary to rewrite the programs.

Around 1980, Bob Coggeshall and Cliff Spencer wrote Substitute User DO, or SUDO, one setuid program to run other programs without the necessity of these programs being rewritten. Sudo became the most used tool for privilege escalation in the UNIX environment. Sudo is under constant development. Security concerns are very important in sudo and sometimes some vulnerabilities are discovered and corrected immediately.

Basics about /etc/sudoers

The sudoers file is composed of three sections: defaults, aliases and user specifications.


Defaults defines options to be used in every sudo entry. It’s possible to overwrite options in each entry. We will discuss a little about some options ahead in this article.


Aliases are variables used to group names. There are four types of aliases: User_Alias, Runas_Alias, Host_Alias and Cmnd_Alias. The name of an alias must start with an uppercase letter. Let’s explain a little about each alias:


Is used to define group of users, for example:

User_Alias WEBMASTERS = user1, user2

You’ve probably realized UNIX has groups of users stored in the UNIX group of users (NSS group database) and there is no need to redefine those groups again. To use a UNIX group inside sudo, you need to append % in the register. In the following example, the UNIX group webmasters can be used inside sudoers as WEBMASTERS:

User_Alias WEBMASTERS = %webmasters


Is used to define group target users. Not always root is the target user, it’s possible to use another users. xRunas_Alias is used to group them. Example:

Runas_Alias OPERATORS = operator1, operator2


/etc/sudoers is prepared to be distributed among hosts. Hostnames, IP addresses and other kind of addresses are grouped in Host_Alias. Like User_Alias, it’s possible to use a UNIX group of hosts, called netgroup (NSS netgroup database). Netgroup is not very common, but is useful for big environments. To use UNIX netgroup inside sudo, you need to append + in the register. In the following example, a UNIX netgroup webservers can be used inside sudoers as WEBSERVERS:

Host_Alias WEBSERVERS = +webservers

There are others possibilities to use Host _ Alias, like lists of hostnames or ip addresses:

Host_Alias WEBSERVER = host1, host2
Host_Alias WEBSERVER =,


Cmnd_Alias groups commands inside lists. Example of Cmnd_Alias:

CmnaAlias PRINTING= /usr/sbin/lpc, /usr/bin/lprm

For each one type of alias, there is one name built-in called ALL. It’s possible to use sudo without any aliases, but aliases are recommended if you intend to use /etc/sudoers.

User Specifications

In the end of the sudoers file, there are user specifications entries. The sudoers user specification is in following form:

user host = (runas) command [,command,..]
user can be user, UNIX group prepending with % or User_Alias
host can be host, netgroup prepending with + or Host_Alias
runas can be user or group of user and unix group

command can be a command, list of commands divided by comma or Cmnd_Alias. command support wildcards.

Let’s see an example of user specification:

root ALL = (ALL) ALL

In the above example, it is shown one user entry which permits the root user to run all commands (last ALL), in all hosts (first ALL), becoming all users (ALL inside parenthesis) when running a command.

The following example is more restrictive than the first example:

neves neves-laptop = (root) /usr/sbin/useradd

In this case, the user neves has permission to run the command /usr/sbin/useradd as user root in host neveslaptop only. As you can see, the second example is more adapted to the least privilege principle.

Let’s go to see the result when user neves runs a command directly:

$ /usr/sbin/useradd neves2
 useradd: cannot lock /etc/passwd; try again later.

User neves doesn’t have access to add user directly, but with sudo it could be possible:

$ sudo /usr/sbin/useradd neves2
 [sudo] password for neves:

Well, it is a typical use of sudo and now it is possible to delegate some activities for operators group. By default, sudo requests the user password and maintains user password in cache for 5 minutes.

Let’s see a little more complex example using aliases:

User_Alias OPERATORS = neves, neves2
 Host_Alias DESKTOPS = neves-laptop, neves-laptop2
 Cmnd_Alias MNGUSERSCMDS = /usr/sbin/userdel, /usr/sbin/
 useradd, /usr/sbin/usermod

Now, beyond useradd command, user neves is allowed to run usermod and useradd commands and sudoers is organized with aliases.

To manage /etc/sudoers, it is strongly recommended to use the visudo command. The advantage of the use of visudo is that it assures sudo syntax is correct before allowing one to save the sudoers file. We’ve seen a little about file /etc/sudoers. Almost all environments use this way to control sudo and it is okay for standalone servers or small environments. We will see that file sudoers is not the best configuration for big and medium size networks.

Common situations about sudoers distribution

Although it’s possible to use /etc/sudoers setup in a perhost basis, sudo doesn’t have any built-in way to distribute /etc/sudoers file among servers. It’s very common in some companies that some team is in charge of operating and distributing /etc/sudoers. In another companies, there are scripts using version control (cvs, svn, etc), transfer commands (rsync, rdist, rcp, scp, ftp, wget, curl, etc.) or file share (nfs, netbios, etc.) to distribute /etc/sudoers. Although the use of scripts is better than manual operation, there are a lot of security issues to be considered in this case. There are some questions that need to be answered:

Are Changes in /etc/sudoers audited?

Imagine one attacker using sudo to get root access in your environment. It’s important to think about which information you have in your log when something like that happens.

Do operators or scripts need root access to change /etc/sudoers?

If you are using push strategy to distribute /etc/sudoers, then probably the source will have rights to change destination servers, as the usual, with root access. In the worst case, with push strategy, you probably created one unique point where it is possible to get root access to entire environment.

Is the source of /etc/sudoers trusted?

Instead push strategy, perhaps you are using pull strategy. In this case, all servers are getting /etc/sudoers from one central point. There are two major concerns in pull strategy, first it’s necessary to protect from man in middle attacks and second is to raise security level of central point. In general, pull is the best strategy to deploy sudoers files, because security problems don’t compromise the entire environment. If you use one software of configuration management like puppet or cfengine to distribute sudoers and protect the configuration management server, your environment probably has a reasonable level of security. Even so, the pull strategy with configuration management lacks real time updates and sometimes lacks an auditing of changes in sudoers files.

Using back-end LDAP

Now let’s discuss about the current best way to use sudo. With an LDAP back-end, sudo becomes a client-server service. For each use of sudo, the LDAP server will be consulted. We join the best advantages of LDAP and the best advantages of sudo to create one authorization system for UNIX environment.

Advantages of LDAP

Some advantages to use LDAP as sudo back-end are:

  • LDAP protocol is standards-based
  • If well structured with replication servers, you will have a high availability service
  • There are access control lists (ACLs)
  • It’s possible to audit all changes and all consults
  • LDAP is cross-platform, it’s possible even to change from one server to another completely different one (e.g.: from openldap to Microsoft active directory)
  • LDAP is very fast for search operations (almost all commands in sudo service)
  • It’s possible to use cryptography/TLS as requirement

Beyond these advantages, maybe the most important security consideration is that it is not necessary to open some security breach to distribute the sudoers file.

I don’t think it’s necessary restate about the importance of protecting your LDAP server(s). Some basic actions like to use firewall, TLS and put LDAP servers in segregated network are outside the scope of this article. If you have a non protected LDAP environment, it is probably better to use another strategy.

Creating LDAP structure

We will explain about how to build one basic LDAP server (OpenLDAP) to store sudo information. We will use OpenLDAP software, because OpenLDAP is the most widely known LDAP server distributed as open software. The procedures are about compilation of OpenLDAP, but if you prefer, you could install by package manager and achieve the same results. If you have one OpenLDAP server running, it is possible for you to jump to next topic. You could use another LDAP server instead openldap, but we won’t explain about this, please look for information in sudo documentation.

First of all, download the latest release of the Berkeley DB from the Oracle site ( and latest version of OpenLDAP from the OpenLDAP site (

Compiling and installing Berkeley DB:

# tar -zxvf db-4.8.30.NC.tar.gz
 # cd db-4.8.30.NC/build_unix/
 # ../dist/configure && make && make install

OpenLDAP needs to find berkeley DB before compilation:

# export CFLAGS=”-I/usr/local/BerkeleyDB.4.8/include”
 # export CPPFLAGS=”-I/usr/local/BerkeleyDB.4.8/include”
 # export LDFLAGS=”-L/usr/local/BerkeleyDB.4.8/lib”
 # export LD_LIBRARY_PATH=”/usr/local/BerkeleyDB.4.8/lib”

Compiling and installing OpenLDAP:

# tar -zxvf openldap-2.4.26.tgz
 # cd openldap-2.4.26
 # ./configure && make depend && make install

Let’s start with a minimal OpenLDAP configuration file. Create a /usr/local/etc/openldap/slapd.conf with Listing 1 content.

And finally, start LDAP server with the command:

# /usr/local/libexec/slapd

OpenLDAP will bind TCP port 389, verify with netstat command:

# netstat -an | grep 389
 tcp 0 0* LISTEN
 tcp6 0 0 :::389 :::* LISTEN

The next step is to create the root of your LDAP tree. Create one file named base.ldif with Listing 2 content.

And add content with the command ldapadd:

# ldapadd -D”cn=admin,dc=example,dc=com” -w”secret” -f
 adding new entry „dc=example,dc=com”
 adding new entry „cn=admin,dc=example,dc=com”
Listing 1. Minimal slapd.conf
#slapd.conf file
include /usr/local/etc/openldap/schema/core.schema
pidfile /usr/local/var/run/
argsfile /usr/local/var/run/slapd.args
database bdb
suffix “dc=example,dc=com”
rootdn “cn=admin,dc=example,dc=com”
rootpw secret
directory /var/lib/ldap
index objectClass eq

Listing 2. Base ldif

dn: dc=example,dc=com
objectClass: dcObject
objectClass: organization
dc: example
o: example
dn: cn=admin,dc=example,dc=com
objectClass: organizationalRole
cn: admin

Use ldapsearch to verify funcionality of your LDAP directory, as showed in Listing 3.

If the results are like Listing 3, your OpenLDAP is okay.

Remember that there are no security concerns in this server example. Your LDAP base is dc=example,dc=com, your admin user is cn=admin,dc=example,dc=com and your password of admin user is secret.

Listing 3. Test with ldapsearch
# ldapsearch -x -b “dc=example,dc=com” -LLL
dn: dc=example,dc=com
objectClass: dcObject
objectClass: organization
dc: example
o: example
dn: cn=admin,dc=example,dc=com
objectClass: organizationalRole
cn: admin

Listing 4. Slapd.conf with sudo structure

#slapd.conf file
include /usr/local/etc/openldap/schema/core.schema
include /usr/local/etc/openldap/schema/sudo.schema
pidfile /usr/local/var/run/
argsfile /usr/local/var/run/slapd.args
database bdb
suffix “dc=example,dc=com”
rootdn “cn=admin,dc=example,dc=com”
rootpw secret
index objectClass eq
index sudoUser eq

Creating sudo container

Now it’s necessary to prepare your OpenLDAP to accept sudo information. First step is to include the sudo.schema. Download the latest stable sudo release source from the sudo site ( and copy the sudo.schema to the openldap schema directory:

# tar -zxvf sudo-1.8.2.tar.gz
 # cp sudo-1.8.2/doc/schema.OpenLDAP /usr/local/etc/

Edit slapd.conf to include the sudo.schema and index to sudoUser attribute. Listing 4 shows slapd.conf with information related to sudo. Restart slapd to reread the new configuration:

# killall slapd
 # /usr/local/libexec/slapd

Create the file ldif sudo container, with the following content:

dn: ou=SUDOers,dc=example,dc=com
 objectClass: top
 objectClass: organizationalUnit
 ou: SUDOers

Add to the directory with ldapadd:

# ldapadd -D”cn=admin,dc=example,dc=com” -w”secret” -f
 adding new entry „ou=SUDOers,dc=example,dc=com”

Your OpenLDAP is okay to control access with sudo. You have two possibilities at this moment, migrate your /etc/sudoers or start from zero.

Migrating sudoers content

Usually the easiest way to migrate sudoers information to LDAP is using a script sudoers2ldif. sudoers2ldif is located at plugins/sudoers, from the sudo source. To generate ldif file from /etc/sudoers, use the following commands:

# SUDOERS_BASE=ou=SUDOers,dc=example,dc=com
 # export SUDOERS_BASE
 # /usr/src/sudo-1.8.2/plugins/sudoers/sudoers2ldif /etc/
 sudoers > sudoers.ldif

And importing sudoers.ldif content to LDAP server:

# ldapadd -D”cn=admin,dc=example,dc=com” -w”secret” -f
 adding new entry „cn=defaults,ou=SUDOers,dc=example,dc=com”
 adding new entry „cn=root,ou=SUDOers,dc=example,dc=com”
 adding new entry „cn=OPERATORS,ou=SUDOers,dc=example,dc=com”

The script sudoers2ldif creates one register called defaults containing the default options and creating one LDAP register for each /etc/sudoers entry. Sometimes it’s necessary to correct resulting ldif file before importing to LDAP. It happens because, depending your sudoers file, it sometimes creates more than one LDAP entry with the same DN (distinguished name). Duplicate DNs aren’t supported by LDAP protocol.

LDAP sudoers registers

First, the difference between /etc/sudoers and sudoers inside LDAP is that, inside LDAP there are no aliases.

First of all, sudo looks for the register cn=defaults and parses it like a Defaults section in /etc/sudoers. The cn=defaults is a list of sudoOptions.

Other sudo registers, in general, are formed by combination of attributes sudoHost, sudoUser and sudoCommand. It’s possible to use multiple values in each these attributes.

Listing 5 shows one example of sudo LDAP entry. In Listing 5, there is a sudo LDAP register with multiples of sudoUser, multiples of sudoHost and multiples of sudoCommand. It’s possible to use attributes sudoRunAs, sudoOption, sudoRunAsUser, sudoRunAsGroup, sudoNotBefore, sudoNotAfter, sudoOrder, sudoNotBefore and sudoNotAfter are very interessing, because it’s possible to define the time that permission is valid in sudo.

Listing 5. sudo LDAP entry
dn: cn=OPERATORS,ou=SUDOers,dc=example,dc=com
objectClass: top
objectClass: sudoRole
sudoUser: neves
sudoUser: neves2
sudoHost: neves-laptop
sudoHost: neves-laptop2
sudoRunAsUser: ALL
sudoCommand: /usr/sbin/userdel
sudoCommand: /usr/sbin/useradd
sudoCommand: /usr/sbin/usermod
Listing 6. ldap.conf with sudo
base dc=example,dc=com
uri ldap://localhost/
ldap_version 3
SUDOERS_BASE ou=SUDOers,dc=example,dc=com
Modify /etc/nsswitch.conf and add sudoers backend:
sudoers: ldap

Compiling and configuring sudoers LDAP client

Above 1.6.8 version of sudo, LDAP support is available. Some linux distributions, like Red Hat now distribute software packages of sudo with LDAP support, but in general, some Unix vendors and linux distributions distribute sudo without LDAP support.

Let’s see how to compile sudo with LDAP and NSS (Name Service Switch). With NSS, sudo will be one of NSS databases, like passwd or group. If your UNIX doesn’t have NSS support, it’s possible to use LDAP support inside sudo, but you need to look at your operating system documentation to learn how to use LDAP backends in authentication.

Download, uncompress and install sudo with LDAP support:

# tar -zxvf sudo-1.8.2.tar.gz
 # cd sudo-1.8.2
 # ./configure --with-ldap && make && make install

Edit your /etc/ldap.conf using Listing 6 as reference. We will enable SUDOERS _ DEBUG to confirm that our sudo binary is using LDAP back-end.

And let’s test the configuration, as shown in Listing 7.

Listing 7. Testing sudo with LDAP
$ sudo /usr/sbin/useradd neves2
LDAP Config Summary
uri ldap://localhost/
ldap_version 3
sudoers_base ou=SUDOers,dc=example,dc=com
binddn (anonymous)
bindpw (anonymous)
ssl (no)
sudo: ldap_initialize(ld, ldap://localhost/)
sudo: ldap_set_option: debug -> 0
sudo: ldap_set_option: ldap_version -> 3
sudo: ldap_sasl_bind_s() ok
sudo: Looking for cn=defaults: cn=defaults
sudo: found:cn=defaults,ou=SUDOers,dc=example,dc=com
sudo: ldap sudoOption: ‘env_reset’
sudo: ldap search ‘(|(sudoUser=neves)(sudoUser=%neves)
sudo: searching from base
sudo: ldap sudoHost ‘neves-laptop’ ... MATCH!
sudo: order attribute raw: 3
sudo: order attribute: 3.000000
sudo: result now has 1 entries
sudo: ldap search ‘(sudoUser=+*)’
sudo: searching from base
sudo: adding search result
sudo: result now has 1 entries
sudo: sorting remaining 1 entries
sudo: searching LDAP for sudoers entries
sudo: ldap sudoRunAsUser ‘ALL’ ... MATCH!
sudo: ldap sudoCommand ‘/usr/sbin/userdel’ ... not
sudo: ldap sudoCommand ‘/usr/sbin/useradd’ ... MATCH!
sudo: ldap sudoCommand ‘/usr/sbin/usermod’ ... MATCH!
sudo: Command allowed
sudo: LDAP entry: 0x1f90790
sudo: done with LDAP searches
sudo: user_matches=1
sudo: host_matches=1
sudo: sudo_ldap_lookup(0)=0x02
sudo: removing reusable search result

In Listing 7, we’ve seen that sudo consulted LDAP to get information about authorization. Look at line:

sudo: ldap search ‘(|(sudoUser=neves)(sudoUser=%neves)
 Sudo looks for user, ALL and all groups of user using charactere ‘%’

Don’t forget to remove the SUDOERS _ DEBUG line from /etc/ldap.conf. It’s recommended to remove the old sudo binary (usually /usr/bin/sudo) and the old /etc/sudoers file.

Using groups and netgroups to organize sudo registers

There are no aliases in sudo when we are using LDAP. Aliases are useful to organize registers and avoid operation confusion. It’s possible to implement the same aliases functionality in NSS aware operating systems to User_Alias and to Host_Alias. Unfortunately, it’s not possible to use command aliases (Cmnd_Alias).

The idea is to create a group container inside LDAP to store sudo groups like User_Alias. These groups will visible to whole environment. Sometimes your environment is LDAP aware and next steps could be already done.

Extend your slapd.conf to include following schemas:

include /usr/local/etc/openldap/schema/cosine.schema
 include /usr/local/etc/openldap/schema/inetorgperson.schema
 include /usr/local/etc/openldap/schema/nis.schema

Create ldif file to group container with the content:

cn: ou=group,dc=example,dc=com
 ou: groupd

Import to LDAP:

# ldapadd -x -h localhost -D”cn=admin,dc=example,dc=com”
 -w secret -f groups.ldif
 adding new entry „ou=group,dc=example,dc=com”

Create a ldif file with your group. Take care about the gidNumber, because the gidNumber mustn’t conflict with local gid numbers:

dn: cn=sudooperators,ou=Group,dc=example,dc=com
 objectClass: top
 objectClass: posixGroup
 cn: sudooperators
 gidNumber: 3000

Import to ldap:

# ldapadd -D”cn=admin,dc=example,dc=com” -w”secret” -f
 adding new entry „cn=sudooperators,ou=group,dc=example,dc

Configure your /etc/ldap.conf to add NSS group database:

nss_base_group ou=Group,dc=example,dc=com

Configure your /etc/nsswitch.conf to include ldap backend in group database, changing line starting with group to:

group compat ldap

Now, sudo groups inside LDAP are ready to be used inside the sudo register. Use sudoUser in the following format:

sudoUser: %group

The next step is to prepare a netgroup container. Netgroup is a part of NIS and NIS is an old software used to centralize network information. It is more often recommended to use LDAP instead NIS. Create a file named netgroup.ldif with the following content:

dn: ou=netgroup,dc=example,dc=com
 objectClass: organizationalUnit
 ou: netgroup

And import to directory:

# ldapadd -D”cn=admin,dc=example,dc=com” -w”secret” -f
 adding new entry „ou=netgroup,dc=example,dc=com”

Create a netgroup ldif file with content like Listing 8. Import to LDAP:

# ldapadd -D”cn=admin,dc=example,dc=com” -w”secret” -f
 adding new entry „cn=desktops,ou=netgroup,dc=example,dc=com”
Listing 8. netgroup example ldif file
dn: cn=desktops,ou=netgroup,dc=example,dc=com
objectClass: nisNetgroup
objectClass: top
cn: desktops
nisNetgroupTriple: (neves-desktop,,)
nisNetgroupTriple: (neves-desktop2,,)

Listing 9. Sudo LDAP register with LDAP groups and netgroups

dn: cn=desktops_sudooperators,ou=SUDOers,dc=example,d
objectClass: top
objectClass: sudoRole
cn: desktops_sudooperators
sudoCommand: /usr/sbin/userdel
sudoCommand: /usr/sbin/useradd
sudoCommand: /usr/sbin/usermod
sudoHost: +desktops
sudoUser: %sudooperators

The nisNetgroupTriple has 3 fields, host, user and domain. Even though it’s possible to use these 3 fields in sudo directly, it’s more recommended use NSS groups and use only first field of nisNetgroupTriple to store the names of computers. It’s necessary to maintain the format with parenthesis and divided by commas (,,). Configure your /etc/ldap.conf to add NSS netgroup database:

nss_base_group ou=Group,dc=example,dc=com

And configure your /etc/nsswitch.conf to include the ldap backend in the group database by changing the line started by group to:

group compat ldap

Finally, it’s possible to change sudoHost to following format:

sudoHost: %netgroup

Listing 9 shows a complete sudo register with sudoGroup and sudoHost using LDAP groups and netgroups in ldif format. Even though it’s possible to use netgroups inside /etc/netgroups and groups inside /etc/groups, using LDAP as a back-end is more powerful because of centralized control. I recommend using groups and netgroups always and avoiding the use of multiples of sudoUser or sudoHost in the sudo register. This way, you will avoid confusion and will have the sudo structure standardized.

Protect sudo registers

Option noexec

Inside some Unix commands, it’s possible to run other Unix commands. Examples of this are editors vi and vim and the find tool. With vi and vim it’s possible to run commands using :!. Putting vi inside sudo is like putting bash or ALL, because one user executes :!bash and has a entire control of operation system, running commands with super user powers. Another example is the find tool with exec action. Imagine one user with the find tool, using the following command:

# sudo find /etc/ -exec chmod o+rwx {} ;

Probably, if you are responsible for this operating system, you would be in trouble.

Sudo has a option to prevent this kind of security problem through named noexec. With noexec, if your operating system supports LD_PRELOAD, sudo will prevent the execution of another command. Running sudo vim, and after that vim command :!bash, for example, will show the following message error:

“Cannot execute shell /bin/bash”

Even though noexec is effective for many security problems related to sudo, it sometimes is useless. In the above example, we control the possibility of a normal user to getting a shell with super user power inside vim, but imagine if the same user runs vim by sudo and after that the user opens /etc/passwd and change uid for himself to 0. Whether the operating system doesn’t have LD _ PRELOAD support or binary is compiled statically, the noexec feature of sudo won’t work. Fortunately all modern flavors of Unix have LD _ PRELOAD support. If you control binaries of the operating system with file integrity software like tripwire, samhain or aide, concerns about binaries statically compiled are reduced. I recommend you to use sudoOption: noexec in cn=defaults.

Take care about variables

Sudo has some options like env_reset, env_keep and env_check to control which environment variables will be available to use by commands called by sudo. It’s very important to watch how the variables are interpreted by the destination command to avoid some security holes. In general, use env_reset enabled in cn=default. With this, only a few variables will be available in destination com mand.

Use valid commands

Put in sudo only valid commands, in preference with absolute path. If you use sudo registers to some command which doesn’t exists, if one user gets root access in that moment, he can install his own binary in the path appointed by sudoCommand. After that, this user will get root access by sudo every time without your knowledge. Beyond cares about valid commands in sudoCommand, it’s highly recommended to complement with a file integrity software like tripwire or aide.


Leonardo Neves Bernardo got started with Unix in 1996 when considered this operating system more interesting than any other. For more than fifteen years he worked with several IT area and now he is more focused with IT security area. Leonardo is LPIC-3, LPIC-302 and LPIC-303 certified and hold a Bachelor’s degree in Computer Science from Universidade Federal de Santa Catarina, Florianópolis, Santa Catarina Brazil as well as RHCT and ITILv3 Foundation certifications. Visit his linkedin profile at:

iXsystems values privacy for all visitors. Learn more about how we use cookies and how you can control them by reading our Privacy Policy.