[BBLISA] Linux and desktops on isolated LAN

Tue Jul 31 15:59:40 EDT 2007

I'm new to this list to let me start off by saying "Hello!"

Now for Scott's questions... You've asked a lot of questions covering
a lot of seperate topics.. let me see if I can help you out on this...

My advice is to break your project up into three distinct parts:

1: unification authentication and authorization
2: installation of your raid array and tape backup system
3: unification of storage paths for /home

1: A/A
Depending on what your environment is (startup? school lab? home
office) you'll want to plan a head here. Since you need windows and
linux/unix to both participate in the same authentication space,
you're going to end up taking one of a few different routes.

Before you begin you'll want to understand how both platforms handle AA.

Unix standard process: (Local account databases)
(verbosity turned down for the sake of brevity )

Authentication:
User requests login from a TTY (or xdm/gdm) process by providing it a
username/password combination. Login process turns around and provides
these credentials to PAM. PAM consults its configuration files, and
looks at /etc/passwd and /etc/shadow to verify the credentials are
valid. If valid, collection of the authorization data begins.

Authorization
Login again consults PAM for where to look up its account data. PAM
again looks in /etc/passwd and /etc/shadow for the corresponding UID,
GID, and EGIDs (/etc/group) Login gathers additional information such
as user shell and home directory. Login begins the interactive user
environment (spawns a shell)

Windows standard process:
The Windows process is a bit more complicated but is essentially the
same. (again, verbosity turned down for the sake of brevity )

Authentication:
User requests login from Winlogon by providing it a username/password
combination
Winlogon turns around and consults its local SAM database

Authorization
Winlogon again consults the local SAM database for various
authorization information (is the user allowed on this machine, at
this time? etc) Winlogon gathers additional information (home
directory, etc)

Your goal is to manipulate where these platforms look to find this
data, preferably storing secrets in a single place. The processes
changes to look like this:

Unix SSO process:

Authentication:
User requests login from a TTY process by providing it a
username/password combination. Login process turns around and provides
these credentials to PAM. PAM consults its configuration files, and
looks at at either NIS, LDAP, or Kerberos v5 database to verify the
credentials are valid. If valid, collection of the authorization data
begins.

(If using kerberos, a ticket ends up in /tmp for the user, and
processes can now utilize this ticket for SASL/GSSAPI authentication
to other services on the network.)

Authorization
Login again consults PAM for where to look up its account data. PAM
looks in NIS or LDAP database for the corresponding UID, GID, and
EGIDs. Login gathers additional information such as user shell and
home directory. Login begins the interactive user environment (spawns
a shell)

Windows SSO process

Authentication
User requests login from Winlogon by providing it a username/password
combination Winlogon turns around and consults the NETLOGON.DLL. If
joined to an Active Directory, NETLOGON.DLL consults the kerberos
database on an Active Directory server to verify if the credentials
are valid. If valid, a kerberos ticket is cached and the collection of
the authorization data begins. If joined to an NT4 style domain (aka,
Samba 3), it talks NTLMv2 and establishes authentication that way.

Authorization
Winlogon gathers authorization data from NETLOGON.DLL. NETLOGON.DLL
either grabs this information out of an NTLM database (NT4 or Samba),
or from the PAC field within the previously issued kerberos ticket.
Winlogon talks to Samba via MSRPC, which then turns around and
consults NIS or LDAP for various information (home directory, etc)

(Wow, that ended up being a lot longer than I initially envisioned).

If you made it through all that, you may be tempted to try all sorts
of different configurations. Most of them wont work as expected. Here
are some things things that "work" in order of "properness"

1) Native mode Active Directory for Windows Authentication,
Authorization, Unix machines configured to do their User
authentication directly against it. Seperate MIT Kerberos realm hosted
on unix for storage of machine and service principals, and a separate
LDAP resource to house unix POSIX information (authorization data:
UID, GID, ./etc/group)

2) sed 's/LDAP/NIS/g'

3) NT4 mode Samba Domain Controller and an LDAP or NIS backend

4) Windows authenticating against an MIT realm.

All of these have their drawbacks.For example, with number 4, you
cannot share authorization data across windows machines.

Since this email has gotten long enough already, I'll just reccommend
one to you and save you a lot of headache: 3a

Set up samba to act as an NT4 style domain controller talking to an
openldap server on the backend. Configure your linux clients to use
LDAP over SSL (not tls) authentication via (pam_ldap, libnss_ldap).

Use the smbldap tool suite to manage your accounts:

http://freshmeat.net/projects/smbldap-tools/
or
http://dag.wieers.com/rpm/packages/smbldap-tools/

A line in your samba config will let you change your passwords from
the windows machine on both "sides" if you want. (the windows password
is stored as a field in the LDAP record),

2: From the way you phrased your initial question its a bit unclear
what exactly it is that you're trying to accomplish: "what is the best
way to parse data and user accounts to
the desktops to share data preservation for backups?"

It sounds like you are looking for some sort of "decentralized" backup
solution in lieu of your raid array. While this might be possible via
some fancy GFS type thing, I'd say "just use a mesh of rsync's for now
untill your raid array arrives, then hook your tape backup to it, then
export a point on the filesystem tree via NFS.

3: Use of an automouter can be helpful for larger environments (NIS
and LDAP can both be used), but a static fstab entry might be easier
to deal with in the simpler, short term case:

homedirs:/var/mnt/drbd0/home    /home   nfs
rsize=1024,wsize=1024,tcp,soft  0       0

Sorry for the length of the reply and the lack of actual configuration
specifics.... I hope I've pointed you in the right direction.

-s

On 7/31/07, David Allan <dave at dpallan.com> wrote:
> > clients automatically mount server:/home onto /home.  Even more elegant is
> > to use automount (a bit tougher to set up).  You see, sometimes there's a
>
> I'll second the recommendation to use automount.
>
> I'd also strongly recommend using NFS/NIS/automount together.  The three
> services are really designed to operate together, and if you don't use NIS
> you'll run into all sorts of irritating uid/gid syncronization problems
> down the road.
>
> All of this is somewhat oldschool, and it's impossible to overstate the
> security difficulties, but if you're on a truly isolated lan where all the
> users trust one another, it will work very nicely.
>
> Dave
>
> _______________________________________________
> bblisa mailing list
> bblisa at bblisa.org
> http://www.bblisa.org/mailman/listinfo/bblisa
>