Single Sign-On and the Corporate Directory, Part IV

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.

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:

dn: cn=login,ou=hosts,o=ci,dc=example,dc=com
objectClass: top
objectClass: ipHost
cn: login
ipHostNumber: 192.168.1.2

dn: cn=sshd,cn=login,ou=hosts,o=ci,dc=example,dc=com
objectClass: top
objectClass: ipService
cn: sshd
ipServicePort: 22
ipServiceProtocol: tcp
ipServiceProtocol: udp
description: SSH Daemon

dn: cn=all-local,cn=sshd,cn=login,ou=hosts,o=ci,
↪dc=example,dc=com
objectClass: top
objectClass: ipNetwork
cn: all-local
ipNetworkNumber: 192.168.1.0
ipNetmaskNumber: 255.255.255.0
description: Local Network

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.

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.