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 <[EMAIL PROTECTED]> 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 > [email protected] > http://www.bblisa.org/mailman/listinfo/bblisa > _______________________________________________ bblisa mailing list [email protected] http://www.bblisa.org/mailman/listinfo/bblisa
