Paranoid Penguin - Single Sign-on and the Corporate Directory, Part I
So you want a corporate directory, but you don't have a corporate budget. You want to reap the benefits of single sign-on, the ease of administration for yourself and the ease of use for your users. If you want all this, plus a secure and unified authorization and identity management system, read on. I'll start you down the path to sysadmin nirvana. In this series of articles, I'll show you how to build on pieces you may already have in place, add new pieces and make them all work together. Everything from the authentication servers, to mail delivery, to client integration (including Windows and OS X) will be discussed. We have a lot to cover, so let's get started!
We use MIT Kerberos V v1.4.1 and OpenLDAP v2.1.30 running on Gentoo Linux as our authentication and identity management systems, respectively. I assume you have three servers: kdc.example.com, ldap.example.com and mail.example.com. Before we go any further, you should first read the Linux Journal articles “Centralized Authentication with Kerberos 5, Part I” and “OpenLDAP Everywhere” (see the on-line Resources). We build on where those articles leave off, but keep in mind that our Kerberos realm will be CI.EXAMPLE.COM, and our base DN will be o=ci,dc=example,dc=com. Also, all of the configuration files referred to in this article are available from the on-line Resources.
This section is optional reading but is highly recommended for sites that will have many servers using SSL. Each server can self-sign its own certificate, but you lose unity and some of the power of running your own CA. If you're interested in the details of OpenSSL, I highly recommend the book Network Security with OpenSSL.
We start by choosing /etc/ssl/example.com as the base directory to store all the signed certificates, certificate revocation lists (CRLs) and accounting information. Once that directory is created, we then create the directories certs, crl, newcerts and private underneath the base. We create an empty file /etc/ssl/example.com/index.txt, and then create a file /etc/ssl/example.com/serial:
# touch /etc/ssl/example.com/index.txt # echo '01' > /etc/ssl/example.com/serial
Finally, we create the CA's OpenSSL configuration file, /etc/ssl/example.com/ca-ssl.cnf.
To create a self-signed CA certificate, we must do the following as the user who owns the /etc/ssl/example.com directory and its children, which is probably root:
# export OPENSSL_CONF=/etc/ssl/example.com/ca-ssl.cnf # openssl req -x509 -days 3650 -newkey rsa \ -out /etc/ssl/example.com/ci-cert.pem -outform PEM # cp /etc/ssl/example.com/ci-cert.pem /etc/ssl/certs # /usr/bin/c_rehash /etc/ssl/certs
For more details on the openssl req command, view the req(1) man page.
It is important to keep the passphrase for the CA key in a very safe place, because if the CA private key is compromised, all previously signed certs cannot be trusted. It is also important to keep the actual CA machine and access to it secure. How secure you keep the machine is up to you and your actual security needs, but if unauthorized users gain physical or network access, they have access to the CA private key. As I mentioned above, compromise of the CA private key compromises the entire chain of trust, making all signed certificates suspect and untrustworthy. Some suggest that the CA machine be physically secured with no network access. In order to sign certificates in this environment, you use registration authorities (RAs) to receive certificate signing requests (CSRs). The CSRs are then transferred to some secure portable media that is taken to the CA where the CSRs are signed, and the certificates written back to the portable media to be placed back on the RA for the end user to retrieve. If you think your needs might require this, the OpenCA Project was designed with this type of security in mind. It also has support for storage of signed certificates in LDAP.
We have created an OpenSSL configuration file for our CA, but that describes only how to request and sign exactly one certificate. We still need to create an OpenSSL configuration to use from now on to request normal host and user certificates: /etc/ssl/example.conf/ssl.cnf. The client configuration is a little more complex than the CA's because more variations can occur for client certificates.
Now that we have a client configuration file, let's generate a host certificate for the LDAP server. Generating a CSR can be done as a normal user:
# export OPENSSL_CONF=/etc/ssl/example.com/ssl.cnf # openssl req -new -nodes -keyout ldap-key.pem \ -out ldap-req.pem
The openssl options used are much the same as those used for generating the CA CSR. The only new option is the -nodes option, which creates an unencrypted private key.
Our next step is to have the CSR signed by the CA in order to get the public certificate. This, again, needs to be done as root:
# export OPENSSL_CONF=/etc/ssl/example.com/ssl.cnf # openssl ca -policy policy_anything -out \ ldap-cert.pem -in ldap-req.pem
At this point, we have three files: ldap-cert.pem, the public certificate; ldap-key.pem, the private key; and ldap-req.pem, the CSR. The CSR can be thrown away once the certificate has been signed by the CA. Again, protecting the private key is important, especially because it is not encrypted. It probably should be owned by root and have permissions 0400.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Paranoid Penguin - Building a Secure Squid Web Proxy, Part IV
- SUSE LLC's SUSE Manager
- Google's SwiftShader Released
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- SourceClear Open
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide