Re: Linux authentication via AD
From: Scott Lowe (me_at_privacy.net)
Date: 07/10/05
- Next message: jafar: "Re: PermitRootLogin (was: Re: Tightening SSH access)"
- Previous message: Chris Cox: "Re: Linux authentication via AD"
- In reply to: Chris Cox: "Re: Linux authentication via AD"
- Next in thread: Chris Cox: "Re: Linux authentication via AD"
- Reply: Chris Cox: "Re: Linux authentication via AD"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Sun, 10 Jul 2005 14:40:17 -0400
On 2005-07-10 12:27:47 -0400, Chris Cox <ccox_nopenotthis@airmail.net> said:
> 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?
>>
>> TIA.
>>
>
> 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.
Fortunately, I don't need to scale into the thousands of users. At
least, not for my own network. However, whatever solution I implement
I'll probably start recommending to my customers, and those networks
may need to scale into the thousands.
> 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.
The cross-platform appeal is nice. Primarily I need to integrate Linux
servers, but I do have a few OpenBSD servers. If NIS is more fully
supported across both platforms, then that's an advantage over LDAP.
Either way (NIS or LDAP), I'll need to extend the Active Directory
schema. Also, if the AD domain controllers are acting as the NIS
servers, then it sounds like that addresses the typical insecurity of
the way passwords are stored.
> 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.
Unfortunately, I don't host any shares on the Linux servers, so I don't
know that this solution will work for my network. We do use Samba, of
course, but that's from a client-side perspective so that Linux (and
Mac OS X) systems can access the Windows-based file servers.
> 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.
Thanks again for your response. I guess my key focus is whether other
individuals feel that the storage of Unix-specific attributes (like
UID, GID, etc.) in AD is a benefit that is worth the additional effort
when it comes to integrating these logins.
-- Scott Lowe
- Next message: jafar: "Re: PermitRootLogin (was: Re: Tightening SSH access)"
- Previous message: Chris Cox: "Re: Linux authentication via AD"
- In reply to: Chris Cox: "Re: Linux authentication via AD"
- Next in thread: Chris Cox: "Re: Linux authentication via AD"
- Reply: Chris Cox: "Re: Linux authentication via AD"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|