Re: Linux authentication via AD
From: Chris Cox (ccox_nopenotthis_at_airmail.net)
Date: Sun, 10 Jul 2005 11:27:47 -0500
Scott Lowe wrote:
> I need some outside perspectives on this. I'm working on a project to
> use Active Directory (AD) to authenticate Linux logins. I'm not looking
> for how to do this; there's plenty of "how to's" out there that I can
> use. What I'm looking for is a "best practice" kind of recommendation.
> There seem to be two prevailing methods for accomplishing this: Using
> winbind, or using LDAP. Winbind apparently does not require a schema
> extension in AD, but also doesn't seem to offer the same kind of
> fine-grained control (you don't get the ability to specify UIDs and GIDs
> when using winbind; these are mapped dynamically). LDAP, on the other
> hand, requires a schema extension in AD but allow us to store
> Unix-specific attributes there, so that an account bears the same UID
> across all systems authenticating to AD.
> Using LDAP seems to make the most sense to me, but it is more work. Is
> the additional work really worth it? What is everyone else's
> perspective in this regard?
Let me offer a time tested alternative... but it won't scale into the
tens of thousands of users... well... maybe it will get into the lower
10 thousands reasonably well.
What I do to integrate with Windows is to use NIS and Samba. Why NIS?
NIS still follows the KISS principle (where things like LDAP definitely
doesn't IMHO). NIS works across just about every *ix environment
imagineable... both young and old. The problem with NIS is that the
passwords are stored DES and in the clear (like old style /etc/passwd
before /etc/shadow). BUT... there's a solution for this.
What we do is have a set of shares on Samba.. .that's the key to new
user creation inside of NIS. When a user is added to AD, you make sure
that his/her login mounts up an appropriate Samba share that is
appropriate for the group that person belongs to. Samba will allow
you to kick off a script for users that access a share.. in that
script you add the user to NIS using the smb area being asked for as
the hint on how that user should be setup. The password field for
the user in NIS is intentionally "nuked" (set to an untypable password).
Then each box, via pam (which works on Linux/HPUX/Solaris/AIX and even
a way to do this under older AIX) allows people to login authenticating
them to the Windows Password Server on the network via NTLM protocol
(which will always work because getting rid of it will break Windows
completely). If the user is removed from the AD Domain, the person
will not be able to login (at least not by password) since the
authentication is done to the Windows Password Server.
Additionally, at new user create time it's possible to mount a home
directory via their login script on Windows that contains their
SSH key information and so you could supply a key at create time so
that once they unlock (supply their passphrase) into PuTTY's
key server, they can jump to the *ix boxes without typing
a password. Obviously when the person is removed from they system,
you'll want to at least nuke their .ssh area. SSH tunneled clear
text passwords authenticate to the Windows Password Server as well.
It's just an alternative, and it works well for us... and it
keeps things pretty simple.
I know there are some Linux ONLY solutions and some Solaris ONLY
solutions that might be considered more politcally correct, but
this is the only way I found to get things to work across almost
every vendor and vendor version of *ix.