Active Directory: A Linux Administrator's Best Friend - InformationWeek

InformationWeek is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

IoT
IoT
Infrastructure
News
12/13/2004
01:55 PM
Connect Directly
LinkedIn
Twitter
RSS
E-Mail
50%
50%

Active Directory: A Linux Administrator's Best Friend

Believe it or not, Linux and Windows can be friends, at least when they share a common directory. Throw in a dash of LDAP and a pinch of SSL, and you've got the recipe for a flexible yet reliable authentication framework.

Indeed, Linux and Windows can be friends, at least to share a common directory. The magic of LDAP, together with the crunchy security goodness of SSL, makes for a duo that combines the stability of Linux with the pervasiveness of Redmond.

Why shoehorn Linus into Bill's world? Well, you might consider this odd marriage if you're happy with your server infrastructure but are looking for a little more security on your desktops. Linux, in contrast to Windows, has a major security feature going for it. Like all Unix implementations, Linux incorporates a security model that recognizes that normal users shouldn't be able to perform superuser actions by default.

If you're a little less reactionary, or if you're managing your Windows desktops just fine, you might simply want a common authentication framework for your workstations that run Unix. Most iterations, including Sun Solaris, will support authenticating to an LDAP directory provider.

Whatever the reason, Microsoft's Active Directory offers native LDAP access, so with a little tweaking you can get one of the major Linux distributions to talk to it. X.500 naming is almost like DNS naming, except that each part of the name is specific to its content.

Here's an example: If your domain name is vm.local, it will be represented in X.500 naming as dc=vm,dc=local. Instead of periods, use commas, and specify that each portion of the name is a domain component (dc). If you're referring to the administrator object that lives in the users container, it will be cn=administrator, cn=users,dc=vm,dc=local using X.500 notation. The "cn" in this case stands for "common name." Organizational units are specified with the abbreviation OU, so the user "SMonkey" in the organizational unit "Engineering" would be cn=smonkey,ou= engineering,dc=vm,dc=local.

Once you're comfortable with how your AD domain looks when it's represented in LDAP, there's one more concept you need to know: Lookups are performed starting at a certain location, called the base DN. In our example, our base DN is cn=users,dc=vm,dc=local.

To get Linux to talk to AD, you must modify your AD schema, install plug-ins to your servers, and otherwise touch places that might end up in server failure, database corruption and so on. You wouldn't roll out anything else that touched your critical directory infrastructure without lab testing, so don't skimp on this step here.

Read On

Choose Your AD Plug-In

You need a plug-in for Windows and Active Directory for two reasons. First, you must modify your AD schema so it has fields for data that Unix and Linux need to store, such as UID and GID. But after you modify your schema, you need software that interacts with the "Active Directory Users" MMC snap-in, letting you populate the new schema fields with user information.

There are two options for AD plug-ins that perform both necessary functions. We tested both Microsoft's Services for Unix and the freeware AD4Unix. Both will perform the tasks at hand, but we were concerned with the lack of recent development work on AD4Unix, and we experienced problems. In fact, during our testing on a lab machine that had been freshly loaded and updated, the AD4Unix plug-in caused the CPU to churn at 100 percent utilization until we ended the task. At this writing, the original home page was down, and the SourceForge project showed no updates since June 2003.

You'll need to make a decision about whether you'll allow anonymous binds to the LDAP server, or whether you'll create a special user that can authenticate. If you create a special user to bind to the directory, remember the credentials can be viewed by any Linux user because they are in the publicly readable ldap.conf file. Make sure the AD user has very limited rights.

Establish a Standard Workstation

Once you've pushed the software out to your workstations, don't think you'll be able to update your Linux workstations without more testing. More important, since there are several pieces of the puzzle that interact with one another on the Linux workstation--namely, PAM, nss_ldap and openldap--you want to ensure all three are talking to one another nicely after an update. The long and short of it is simply to treat all three as a whole. Test any revision in your lab environment; then, after confidence testing is done, roll it out. Although this is essentially a good IT and security practice anyway, it bears repeating when we're talking about something that affects your users' abilities to log in.

Jonathan Feldman is director of professional services for Entre Solutions, a Georgia-based company providing security and consulting services to the health-care, financial-services and law-enforcement markets. Write to him at [email protected].

We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
Previous
1 of 3
Next
Comment  | 
Print  | 
More Insights
InformationWeek Is Getting an Upgrade!

Find out more about our plans to improve the look, functionality, and performance of the InformationWeek site in the coming months.

News
Remote Work Tops SF, NYC for Most High-Paying Job Openings
Jessica Davis, Senior Editor, Enterprise Apps,  7/20/2021
Slideshows
Blockchain Gets Real Across Industries
Lisa Morgan, Freelance Writer,  7/22/2021
Commentary
Seeking a Competitive Edge vs. Chasing Savings in the Cloud
Joao-Pierre S. Ruth, Senior Writer,  7/19/2021
White Papers
Register for InformationWeek Newsletters
2021 State of ITOps and SecOps Report
2021 State of ITOps and SecOps Report
This new report from InformationWeek explores what we've learned over the past year, critical trends around ITOps and SecOps, and where leaders are focusing their time and efforts to support a growing digital economy. Download it today!
Video
Current Issue
Monitoring Critical Cloud Workloads Report
In this report, our experts will discuss how to advance your ability to monitor critical workloads as they move about the various cloud platforms in your company.
Slideshows
Flash Poll