[KLUG Members] Re: An off-shoot IPX/SPX question... -- Kerberos-AFS is the best answer ...

[Bryan J. Smith]

--=-kExgJ2a8SveEUFsbTFpn
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Tue, 2002-12-10 at 14:35, Tahnesha Pinckney wrote:
> Hi all,
> My boss seems to think that there's a way to setup Linux machines to
> communicate with Windows via IPX/SPX using a Netware machine as a
> go-between.

1) That's grossly inefficient and less reliable no matter who protocol
you use.

2) A "go between" protocol that still uses those other protocols does
not improve the security of those other protocols.

3) Adding another layer only complicates things, possibly negatively on
security as well.

4) The underlying lower protocols used for networking/transport do not
matter, it's the session-level that does.  E.g., IPX/SPX is _not_ where
NetWare encrypts, it encrypts at NCP (session+ layers) because it also
runs over TCP/IP.

5) There are many other services on your network that run unecrypted,
and your LAN is as exploitable as your most insecure service.

Sixth, you've got far more worry from users that browse the Internet.=20
Desktops are more likely to be compromised.

> He seems to think it might be safer, security-wise, instead of
> establishing a Samba share.

A) Samba _does_ offer encrypted SMB-SSL at the session-layer, but
Windows clients don't support it.

B) Linux supports NCP (as well as IPX/SPX at lower layers, which doesn't
matter as mentioned in #4 above), and probably has the ability to do
encryption with NCP-SSL.  But the question is, as with "A", does the
NetWare client support it's implementation?  As with "A", probably not?

C) Secondly, as touched on in #5 above, you should look at addressing
your _entire_ network's security with something like Kerberos
ticketing.  This is assuming, of course, everything on your network can
be Kerberosized.

D) In combination with "C", you can _immediately_ take advantage of the
Andrew Filesystem (AFS), was _designed_ for Kerberos off-the-bat.=20
OpenAFS offers an Open Source UNIX client/server and Windows client
(i.e. it replaces the need for both NFS and Samba) that you can use now:
  http://www.openafs.org

E) I think your boss is trying to think of an excuse for Novell.  If
you've got Novell on your network, and it works, don't rip it out (which
is a mistake I see so many companies make).  But if you don't have
Novell, it's a total, 100% non-applicable excuse for it.  ;-p

F) You _might_ investigate Novell's eDirectory product (basically NDS
for non-Novell platforms) which includes RSA DES encryption.  But I
don't know if this will address your total LAN services.  In any case,
you don't need (or want) a NetWare server dorking up all your services
(unless you already have NetWare/NDS in place -- that's a different
story).

G) Wait for Samba 3.0 which integrates with ActiveDirectory and/or
Kerberos (or try out the Alpha releases which some people saw are quite
stable ;-).

> I tend to disagree, seeing as though if you're behind a sensitive
> firewall, you really don't have much to worry about.

Er, Firewalls can be a _false_ sense of security.  Same deal with 802.1X
wire/network-level encryption.  Networking filesystems are security
nightmares on their own.  Your boss has the right idea, but _dead_wrong_
(totally _wrong_way_) solution.

KERBEROS CONSIDERATIONS, AUTHENTICATION AND THE "ACTIVEDIRECTORY" PUSH

Most SysAdmins who run Kerberos-AFS have the attitude, "you can't
exploit a LAN if it's entirely encrypted."  I tend to agree.  But if you
are going to go Kerberos, you must seriously look at Kerberosizing all
of your network services.

RedHat has basically done that with its Linux product since version 7.=20
Microsoft has been moving there since Windows 2000, although that
requires all clients are NT 5.x (2000/XP) or later (although there _are_
design decisions with Win2K's version that defeat its purpose -- e.g.,
it's Kerberoized DDNS service has holes).  But, of course, RedHat's
services are largely UNIX-only ones (although Samba 3.0 will change
that), and Windows's services are Microsoft-centric (and the
non-Windows, Kerberos changes are client-only and still forthcoming).

Worse yet, since Microsoft has forced all major software vendors who
write Windows services to adopt ActiveDirectory, which means clients
must be in an ActiveDirectory, most companies are just going
ActiveDirectory.  So even if you try to adopt Kerberos-AFS and use
something like pGINA to have your Windows systems authenticate against
Kerberos instead of AD, since many new 3rd party Windows server products
(and not just Exchange or MSSQL anymore) require ActiveDirectory on your
network, it's becoming less and less of an option.

ACCTSYNC FOR WAN/LANS WITH OPENLDAP AND "SEGMENTED" ACTIVEDIRECTORY

One local, multi-campus WAN/LAN to me (FIT) has actually come up with a
way to address this.  They keep their Windows servers on its own
"ActiveDirectory" domain, but they setup all accounts under an OpenLDAP
(with traditional MD5 hash or optional SASL-Kerberos authentication)
which runs the "backbone."  A Win32 service FIT wrote called "AcctSync"
then checks for new accounts or password changes in the OpenLDAP
directory, and also sends any password changes on its side back.

For more info on "AcctSync," see it's SourceForge page here: =20
   http://acctsync.sourceforge.net

> If any of you can help me difuse his argument, please do so.  Any and
> all info would greatly appreciated.

Again, your boss has the right idea, but wrong solution.

The most obvious answer is a Kerberos key server and AFS for all your
network filesystem needs between UNIX and Windows systems.=20
Unfortunately, Kerberos brings in the larger issue of "how can we make
sure everything is Kerberosized?"

And while AFS offers many things over NFS and SMB (like being a
"virtualized filesystem," read-only fail-over, extra
security/permissions, etc...) it still has a few trade-offs too.  E.g.,
NFS v3 supports >2GB files (not AFS nor SMB do) and it does not support
Windows Jet-engine file locking (e.g., multiple-users access MS Access
files).


--=20
Bryan J. Smith, E.I. (BSECE)       Contact Info:  http://thebs.org
[ http://thebs.org/files/resume/BryanJonSmith_certifications.pdf ]
------------------------------------------------------------------
  The more government chooses for you, the less freedom you have.


--=-kExgJ2a8SveEUFsbTFpn
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQA99mN7DjEszaVrzmQRAh2FAKDWXyFDnTvDbODURrFHt+YfXvARIwCfc9m1
yc+9KHVZEcyntxr5Hhj/Ac4=
=G/sV
-----END PGP SIGNATURE-----

--=-kExgJ2a8SveEUFsbTFpn--