[NTLUG:Discuss] Easy openldap

[Chris Cox]

On 12/02/2010 12:20 PM, Robert Pearson wrote:
....snip....
> I have a very interesting NTLUG personal archive of NIS vs.
> LDAP/OpenLDAP vs. AD vs. LDAP/OpenLDAP+AD Questions & Answers. Chris
> Cox is the resident expert.
> 

Here's my take:

1. Windows DOES NOT play well with other OS's.

2. Windows WILL NEVER play well with other OS's.

3. The idea that Linux (or other) can SUCCESSFULLY replace Windows AD for a
Windows centric network is STUPID (see #1 and #2).

4. The concept of #3 isn't necessary for Linux to take over MOST (99%) of the
network.

I see a LOT of "solutions" out there.  The problem is that they almost always
strive to take the hardest most complex approaches to solving (IMHO, a simple)
problem.

Now... let me tell you, my solution does involve replacing some pieces of
infrastructure that Windows LOVES to own.  Those being DHCP and DNS.  But, in
general, Windows accepts that other people want to own those things... so I
THINK (emphasis on THINK) we can handle those pieces without Windows getting
terribly mad.  Also, I THINK SMB protocol can be done by Linux without making
Windows terribly mad... however I DO emphasize that Microsoft can SHUT that down
as well... and they can do that AT WILL.

Are we sure we want Windows on the network at all?  You know, myself and
thousands of others DO NOT use Windows anymore.  We communicate, collaborate,
create, play games, program, innovate, etc.... and NO Windows involved at all.

Requirement: Humans... not couch potatoes... not lazy sloths... not the bane of
society.... just true humans.  People that still think, can learn and be
productive... it's REALLY that simple.  Unfortunately, from what I've seen so
far, most System Administrators have apparently opted out of humanity... sigh...



But... there is a transition point... duh... so...  as I presented on months
earlier:


1. Windows AD Domain controller WITHOUT DNS and DHCP (it's EASIER if this is
done at OS installation btw).

2. Linux box with DHCP and DNS with underscore SRV zones enabled for dynamic
update by the IP of the domain controllers in #1.  THIS IS THE ONLY WAY to
successfully handle dynamic DNS updates for DHCP clients that are NOT Windows
boxes btw.  Windows CAN'T do this right... nor is there any hope that they will.

3. Linux box with NIS (could be LDAP, but NIS is simpler, easier, requires a LOT
less work... but only scales up to about 5000 users or so).

4. Linux box JOINED to the Windows AD domain using Samba winbind (no... you
don't need LDAP or Kerberos for this) and this same box is a NIS client of the
NIS domain.  This box should expose a NAS via SMB and possibly NFS
simultaneously.  Ideally, the home directories for the users of a Linux +
Windows network.

Aside: Use SUSE/SLES for all of this if you don't any extra headaches.  Biggest
headaches would be on the Ubuntu side.  Biggest disappointment will be on the
Red Hat side (because you spent a lot of money on them.. a LOT of money).

5. Back to #1, upon Windows client login into the domain, mount/access SMB from
the #4 machine.  The #4 machine upon access by the Windows client checks the
request aginst AD (is it a valid auth'd user) and creates the NIS user
information (needs to match name for name to avoid building a smbusers file) as
well as the SMB/NFS dir (again, preferably home dir).  Aside: Why home dir?
Well... it allows you to configure new users on the AD to have their home dir as
\\linux4\homes (which AD thinks is a bit wackadoodle and will warn that you have
multiple users using the same home dir... but if you know Samba, then you know
it's a private view into JUST your specific home dir).  Also, it helps if at
login, if a private SSH key does not exist that the user creates one... my
favorite SSH client on the Windows side is PuTTY... so assume the user upon
login from the Windows host, creates their PuTTY key pair and drops the private
key into their (hopefully) home dir (again, this is why it helps if #4 NAS
exposes the home dir).  The public part, also is stored on the SMB mounted home
dir in the .ssh/authorized_keys file.  For GOOD security, the SSH key probably
should have a passphrase.  The AD login script for the new user should attempt
to access the user's private key \\linux4\homes\private.ppk (excuse me if I got
the name wrong).  By default, pageant (PuTTY Agent) on a default PuTTY install
will get invoked when accessing a PuTTY private key and force load (prompting
for passphrase if needed).

Done.

Ok... #5 was a doozy.

But if the Samba config on #4 smashes the usernames across AD and Linux (in this
case NIS as well), then what you end up with is a seamless Linux + Windows
environment with NIS users that CAN have NO PASSWORD.  Thus when the NIS creates
that Linux4 does when #5 happens occurs, you can "nuke" the NIS hashes (I like
to assign the DES password hash to all tildes.. .which is invalid base64, which
means its an invalid DES hash).

Result:  Windows user logs in... sets up PuTTY data.... (might  have to log out
an log back in again just to keep it simple for them)... and then they can SSH
into every Linux/Unix box on the network if you assume the Linux/Unix home dirs
are the same area exposed by Linux4... automounted via NFS via automount typical
of a NIS+NFS based *ix network.

Security:  If the user is eliminated from AD, access to the magic SMB share goes
away hopefully with user's private key.  Optionally... a skulker could clean out
the Linux4 user stuff and the home dir.... but this could even be done manually
(probably safer).  Users on this networked are auth'd by AD (because WE HAVE to
trust it... or Microsoft gets mad) and the SSH key load off the auth protected
share is the entry mechanism into the other hosts.  You DO have to do some other
things though... realize that the Linux/Unix systems are NOW passwordless... so
any subsequent auths on the *ix hosts would have to either be done against the
AD (e.g. Samba winbind style or using some other kind of GSSAPI auth which may
involved a messed up LDAP + Kerberos).  IMHO, you'd handle this via PAM where
possible and possibly with a secured proxy auth to a host that knows how to do
this (e.g. Linux4).  Alternatively, you can build trusts that if a user is on
the *ix box, they HAD to get there via an approved auth... thus... you simply do
everything without passwords (e.g. imagine sudo with the NOPASSWD option, for
example).  If all of your *ix boxes are Linux (the ideal) this becomes easier,
because they could all be joined to the Window AD domain.. then then passwords
could just be through AD.  Then you wouldn't go passwordless... you could
actually really log into hosts (for example via something else besides SSH key'd
access) using your NIS-smashed-to-AD username and your AD password.  In fact...
if JUST Linux.... you could even eliminate NIS... but NIS is useful for handling
other hosts and it makes automount, etc. easier.


I have successfully set this system up in my own lab AND this WILL go live
shortly (though not quite as elegantly) at IBM, at least for the development Lab
in Irving.. but possibly also in Littleton, MA and Dublin, OH.  IBM could say
"no"... but that's really not in the spirit of "Smarter Planet".


If  you KNOW what you are doing... the above isn't terribly hard... the problem
is in the KNOWING... and while it's possible to go through it all a light speed
(e.g. this message)... I'm not being VERY detailed... and doing a class on this
could be a WHOLE day affair.  But if you do this kind of stuff enough...
eventually it becomes easy as pie.

And Windows dies due to lack of revenue.... Chris's "way" means "not enough
money for Microsoft".

Btw... all of this is "what I do" for a paycheck and DOES NOT include my special
projects (things IBM hasn't dreamed of yet) that are designed to truly change
the world.  Humans are VERY smart... but I HATE complex solutions.  So rest
assured, what you see here will not only work... but I'd be really surprised if
it ever failed... so NO BABY SITTING (I HATE baby sitting).