All right Mike, I take your comments about CAEDM personally, so let's
set the record straight:

On Thu 05 Jun 2003 at 11:56:00, Michael L Torrie said:
> Last time I took a look at CAEDM they were still doing hackery like
> juser and weird samba tricks instead of using a windows domain
> controller (Samba) and a central ldap authentication system.

I am happy to report that your information is more than a year out of
date.  As much as possible, all the UNIX machines use LDAP for
authentication and user info (via NSS).  Those exceptions involve
programs that need authentication for licensing issues; I have yet to
find any licensing system that doesn't just suck hard-core in the first
place, so it's a wonder it works as well as it does.  In these cases,
we've written PAM modules or other methods to tie the legacy code into
LDAP or directly into the user database.

We also have a Win2k Active Directory domain that populates itself from
the master LDAP servers (running on Linux), and all the Windows clients
authenticate to it.  The samba servers themselves don't use the domain
to authenticate, but use LDAP directly.

> I hope juser has finally died.  It was a terribly insecure hack.  Later
> I think they ended up storing user information in an sql database with
> passwords in plain text.  This database server was of course set to
> trust a number of specific administrator hosts without a password.  

juser has been gone for over a year.  The new duser stores all passwords
as hashes and requires authentication for any sort of access.  Even
scripts that interact with the database have their own usernames and
passwords, and the MySQL permissions restrict what degree of access they
have to each database and table.  The MySQL databases that users have
for websites are on a totally different server than the administrative
databases.

I won't claim that CAEDM's network is 100% secure -- there's probably
some hole that we haven't found.  And there are some things that --
while they aren't as bad as plaintext passwords -- could be tightened
down a little more, like using SSL/TLS in more places and setting up
Kerberos-ized services (which I'm actually working on now).  The biggest
security problems and most flagrant examples of bad hackery are related
directly to the large amounts of proprietary code that we have to
support (like Citrix, HP-UX, and a hundred million dollars worth of
badly-written CAD software), whether it's security issues with these
systems themselves, or issues with legacy in-house systems that have
been written to support such code -- like using MySQL for the admin
databases instead of something a little more robust (many times I have
wished for transaction support).  If we could, we'd run everything on
OpenBSD with encrypted file systems, an IPsec-based LAN, lock every user
into a UML sandbox that is wiped out every time they log out, and tunnel
all services that aren't SSL/TLS/Kerberos compatible through SSH.  But
that just isn't practical in our circumstances.

-- 
Soren Harward
[EMAIL PROTECTED]

____________________
BYU Unix Users Group 
http://uug.byu.edu/ 
___________________________________________________________________
List Info: http://uug.byu.edu/cgi-bin/mailman/listinfo/uug-list

Reply via email to