Linux Authenticating against Active Directory

April-July 2012


Table of Contents

The situation
Prerequisites
Outline
Kerberos may need AD nameserving
Debian/Ubuntu Linux with AD Kerberos Server
Kerberos Basics
Troubleshooting
Querying AD with ldapsearch
Troubleshooting
UIDs from AD LDAP in Debian/Ubuntu Linux, with libnsswitch
UIDs from AD LDAP in Debian/Ubuntu Linux, with sssd
Sssd-based authentication when simple bind isn't allowed
Troubleshooting
Joining an Active Directory domain with Debian/Ubuntu Linux
Mounting a Windows share from Debian/Ubuntu Linux, using AD authentication
Mounting without DFS
Mounting with DFS
Ubuntu NFS4 server/client with AD Kerberos/LDAP
Kerberos config for NFS4 (both server and client)
The NFS4 Server
The NFS4 Client
Troubleshooting
Debian Squeeze based Samba server with AD Kerberos and LDAP

We want redundant storage for our couple of hundred Linux PCs.

These are the surroundings: an open (as in: not firewalled) network. About 15,007 Windows PCs, and expect to have as many virtual Windows workplaces in the near future. Around 50,000 accounts. Two dozen terabytes of data. Hundreds of servers for all kinds of purposes and with various OSes. Many more Linux nodes in compute clusters.

Instead of maintaining a shadow infrastructure for Linux, we want to use a common infrastructure with Windows. This article is about using AD authentication (i.c. LDAP and Kerberos) on Debian and/or Ubuntu Linux. And it is about setting up redundant storage, accessible from both Linux, Windows and other platforms.

For Linux hosts, we are now still using an NFS4 server with Kerberos, as described in my NFS4-HOWTO. That old HOWTO may still be interesting if you want to have your own Kerberos server before trying to use AD, or if explanations here are too brief.



All computer objects in the LDAP tree are created by the unixJOINer through commands from Linux, in the unit OU=Extra Workstations (see below for its DN). To do that, the account needs the following permissions on the OU:

  • Create Computer Objects

  • Delete Computer Objects

  • Read All Properties

  • Write All Properties

  • Read Permissions

  • Modify Permissions

  • Change Password

  • Reset Password

  • Validated write to DNS host name

  • Validated write to service principle name

If your setup doesn't permit an account with these permissions, you can also add machines to the domain from within the AD server, see this TechNet blog by Jose Barreto.

The ENUMuser account has the permissions of a Domain User. I.e. on Supplemental Workstations it has list and read permissions.

[Note]Note

There is one more ingredient to these experiments, of paramount importance: a friendly AD admin, or a couple of them, who will deal out accounts, tell you DNs, Wireshark around, and generally cooperate. Without one, don't even try.