Single Sign-On and the Corporate Directory, Part IV

We wrap up the single sign-on series with CUPS printing, SSH and firewall rules.

Managing Users and SSH Keys

Included in the Resources is an OpenSSH schema. One of the first uses
of this schema you might think of is keeping public keys of hosts in
one location, a kind of known_hosts directory. In fact, that is why
this schema was created. Future versions of OpenSSH will be able to
use name service switch, NSS, to look up host keys instead of always
requiring a local file containing them all. This is great because you'll
no longer need to push and pull known_hosts files when hosts are added
or removed, but unless you've patched your versions of OpenSSH, it's not
that useful yet.

At the Computation Institute, we have a large cluster that many outside
collaborators use. The cluster has its own network home directories, so
it doesn't mount the central NFS ones. We also didn't want password-based
logins where passwords are transmitted over the wire. Normally, this would
be a fine time to enforce GSSAPI-based authentication, except we don't
have control over the collaborator's desktop. So, I asked a colleague of
mine to write a script to automate creating the user's home directory
and adding a user's SSH key to her .authorized_keys file if she provided
one. Because Python is his language of choice, the mkhomedirs.py script
was born.

Here's how it works. When users are granted access to the cluster, they
are
put into the cluster-users netgroup, which is also served from LDAP. The
mkhomedirs.py script, run every hour from cron, checks the list of current
users in the cluster-users netgroup to see which ones don't have home
directories. When it finds a user without a home directory, it creates
one and copies over necessary files, such as those from /etc/skel. Once
the user provides an SSH key, the key is added to the user's sshPublicKey
attribute in LDAP. The mkhomedirs.py script also checks to see which users
don't have a ~/.ssh/authorized_keys file. If a user doesn't have that
file and has a key in LDAP, it creates the file and adds the key to it,
allowing the user to log in. This script doesn't impose the restriction
that a user's authorized_keys file must contain only those keys that are
in LDAP, but it would be trivial to add that functionality. A common
trick in a cracker's toolbox is to add his or her SSH key to another user's
authorized_keys file. If you require all keys in a user's authorized_keys
file to be in the directory, you can send off warnings when an unknown
key has been added to a user's authorized_keys file.

Automatic Firewall Rules Generation

Another way you might use LDAP is to create iptables rules
for your hosts automatically. We achieve this by enumerating all the services for a
host and all the networks that are allowed to access that service in
LDAP:

Next, we need something that will traverse all the hosts and give us
iptables rules for each one. In the on-line Resources, I've provided a
script I've written, create-iptables.sh, which does exactly that. It
depends on several Perl modules to which I've provided links in the
Resources. What it does, briefly, is copy a
prefix file for each host that has some rules that apply for all hosts and sets
up the chains we use in the script. Next, it makes sure that all the
IPs the host uses are allowed to connect back to the host. It then
traverses the services, opening holes for those networks listed for each
service. Finally, it appends the default rule set, which is to drop all
packets. All the scripts are written to the directory iptables-scripts,
and all previous scripts are saved to iptables-backups. You should create
these directories before running the script. These scripts can then be
pushed out to the proper hosts and run to keep host rules up to date.

You could easily modify this script to generate other pieces, such as
/etc/hosts.allow and network device ACLs for added security. Another
use for this type of directory structure is to generate custom scans
for nmap or nessus to eliminate false positives.

More LDAP Uses

The last example I've included is generating a dhcpd.conf file for your
DHCP server. This script requires that the hosts in LDAP be members of
both the ipHost and ieee802Device object classes and have their
macAddress and ipHostNumber attributes assigned. It's not a very
sophisticated script, in that it won't make sure that a host's IP is
valid. It also won't handle a host that has multiple IPs or multiple
subnets served by the same DHCP server.

There is a patch for ISC's DHCP server to add support for getting
information directly out of LDAP, but I prefer to wait for patches to
be vetted and included in the main distribution before use on production
servers. For those who are curious, I've included a link in the Resources.

Many more applications are including LDAP support directly, or there are
patches available. There is an LDAP sdb back end for BIND 9 for storing
zone info in LDAP, and sudo has the ability to get sudoers information
from LDAP. However, remember, if there's something you want to do with
LDAP for your organization that requires new attributes or object classes,
you can contact IANA to be assigned your own OID for use.

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.