Single Sign-On and the Corporate Directory, Part III
Welcome to the third installment of how to implement a single sign-on and corporate directory system. In this article, we tackle integrating Microsoft Windows clients. There's a lot involved to make it all happen, so put on your work gloves and let's get to it.
When you want to integrate Windows clients into a heterogeneous environment, you have some choices to make. Although you can run an Active Directory (AD) server and have your Linux and Apple clients bind to it for authentication and identity management, the costs involved are not minimal. It also wouldn't make for an interesting article on an open-source single sign-on and directory implementation.
When you're binding Windows clients to an open-source solution, you have two more choices to make. Do you bind them to the Kerberos realm for authentication or do you bind them to LDAP for identity management? This is an either/or choice because although Windows clients know how to speak both Kerberos and LDAP, they know how to speak them at the same time only when talking to an AD server. In other words, Windows clients can talk to a non-AD Kerberos server only when the user's identities are kept locally. Likewise, a Windows client can get identities from LDAP via Samba, but only when the passwords are also served via Samba, and Samba can't, at the moment, authenticate via Kerberos.
Having Windows authenticate against our Kerberos KDC is easier to set up, but it could be harder to maintain because every user who uses the Windows client needs to have a local account. This is fine if all you have is one Windows client to maintain, but if you have any more than that, you'll need to add every user to every client. I won't explore this option; however, if you're interested you should pick up Jason Garman's Kerberos: The Definitive Guide.
Because we're dealing with a corporate directory, I'm assuming you probably have more than one Windows machine on your network. In order to make using them and incorporating them as painless as possible, we use Samba tied to our LDAP directory as a back end. Even though we'll be configuring Samba a little differently, you should first read Craig Swanson and Matt Lung's “OpenLDAP Everywhere Revisited” (see the on-line Resources), as it will give you a good foundation on which to build. I created an organizational unit branch in the directory named samba for Samba specific entries such as machines and ID maps. Listing 1 shows the hierarchy of these special branches, and Listing 2 shows the LDIF for them.
Listing 1. Additional Organizational Units
+ o=ci,dc=example,dc=com |- ou=samba |- ou=hosts |- ou=idmap
Listing 2. LDIF for Additional Organizational Units
dn: ou=samba,o=ci,dc=example,dc=com objectClass: organizationalUnit ou: samba dn: ou=hosts,ou=samba,o=ci,dc=example,dc=com objectClass: organizationalUnit ou: hosts dn: ou=idmap,ou=samba,o=ci,dc=example,dc=com objectClass: organizationalUnit objectClass: sambaUnixIdPool uidNumber: 15000 gidNumber: 15000
I don't use the smbldap scripts from IDEALX for creating necessary entries, because I'm using LDAP for more than just Samba authentication. One main reason for not using the smbldap tool is because it assumes that it and Samba will be the only point for actions such as adding users and groups. In my environment, all users don't have the ability to log in to Windows machines. Some users may start off as Linux-only users, but then need to be given access to Windows machines later. The smbldap tools don't handle this case very well. However, the smbldap tools do handle other things nicely, so like all things, investigate all the tools available and choose the best one(s) suited to your needs.
We need several users in LDAP that will do various tasks. First we need a user who has write access to certain pieces of the directory. If you notice in /etc/samba/smb.conf, there is an option, ldap admin dn, that defines the DN of this user. This user, named samba_server, should be stored in the LDAP directory itself, and it will be the only user in the directory with a password associated with it. Because this user isn't of the posixAccount objectClass, the account is not recognized under Linux. To create this user, first run slappasswd to generate the hashed password. Then, take the hash and create an ldif file that's similar to Listing 3.
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!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Tech Tip: Really Simple HTTP Server with Python
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Returning Values from Bash Functions
- Rogue Wave Software's Zend Server
- Doing for User Space What We Did for Kernel Space
- 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