Linux authentication via AD

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.

--
Scott Lowe

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.

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.

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

Scott Lowe wrote:
....
> 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.

The shares really don't have to do anything but trigger the user
create... so they can be read only (useless) if you want.

The are USEFUL however if you want the transparent single sign-on with
a SSH key on the client side... but actually this can be done via
other mechansims as well... so I suppose you only need the share
to communicate the info needed to perform the user create in NIS.

I have all of this working at a plastics manufacturing facility
today.

For them, their accounting package runs on Linux and they were used
to the ease of bringing up the package under Windows that they had
when the application was DOS based. Now they hit a special PuTTY
button on their desktops which automatically hits the Linux server
running the accounting package and since their SSH key was loaded
for them at login, it takes them straight into the application (I
have the application setup as their shell). But.. even without
the key, they can login into the linux box NTLM style by providing
their windows id and password.

Another nit... for portability across all Unix (especially AIX)
you'll want to keep your usernames at 8 chars or less. Password
should be just fine though.. whatever size Windows will allow.
You can always map the id's via smbusers... but it makes the automation
much more difficult.

Use kerberos with winbindd. Works with several versions of unix.
(bsd,solaris,etc)

On 2005-07-15 21:51:06 -0400, Joe Beasley <jbeasley@otaku.freeshell.org> said:

> Use kerberos with winbindd. Works with several versions of unix.
> (bsd,solaris,etc)

Since posting that message, I have moved forward with Kerberos
authentication via pam_krb5, but I'm using LDAP for the user/group
lookup. It was my understanding that until VERY recently, all UID/GID
mapping performed by winbindd was dynamic, and therefore we couldn't
assume a consistent UID or GID across multiple systems. For that
reason, I extended the AD schema and store UID and GID in AD, to be
looked up via LDAP from the Linux clients.

Has the dynamic UID/GID mapping in winbindd changed? If so, I would
assume it still requires an AD schema extension, yes?

--
Scott Lowe