Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Unix Operating Systems Software

Is There a Better Way to do UNIX Workgroups? 40

Posted by Cliff from the reanalysing-traditional-solutions dept.
Pauly asks: "Here I am again setting up a new workgroup of UNIX workstations and servers in the traditional office arrangement. By traditional I mean many clients being authenticated by a naming service and mounting homedirs and other shares handled by centralized file servers. I can't help thinking there has to be a better way to do this. Even though this particular LAN is behind a reasonable firewall, I don't feel that NIS/NFS (and their derivatives) are designed securely enough for today's world. Even though I have gone to great lengths to secure the dmz, it just feels wrong to ignore the internal network. I don't have any legacy application or system requirements to keep me tied to NIS/NFS. All the clients will be OpenBSD, FreeBSD or Linux machine. Therefore, I am free to use the best-of-breed tools available today. So I ask: How would you implement the traditional UNIX workgroup today and which of the latest and greatest tools available would you use?"
This discussion has been archived. No new comments can be posted.

Is There a Better Way to do UNIX Workgroups? More

Is There a Better Way to do UNIX Workgroups?

Comments Filter:

  • Yes there is (Score:5, Informative)

    by b.foster ( 543648 ) on Saturday December 29, 2001 @04:56PM (#2763127)
    Last year, I was responsible for reinstalling a large cluster of Sun Ultra machines, which were NIS and NFS for distributed authentication and file sharing. There were a couple of pitfalls along the way, but now we have a very fast, secure system up and running. A couple of points are:
    • Use Linux on the client end. It is scads more maintainable than Solaris, and its remote filesystem capabilities are very well-refined and debugged.
    • Stay away from NIS+. Support is limited and the protocol itself is complex and insecure.
    • Stay away from AFS and Coda. They are very difficult to set up properly, require running buggy code in kernel space, and force you to make dedicated hard drive partitions to support them. They also overwhelm your network to the breaking point.
    • Use Kerberos for authentication. I've tried many different implementations and found (surprisingly enough) that the UI and stability on the Win2k Active Directory server is second to none. The MIT K5 KDC is pretty nice too, but our admins prefer a GUI for user management.
    • Use NFS tunneled over SSH for file distribution. Avoid having more than one or two NFS mounts on each client machine, and always mount with "-o soft,bg".
    • Change host keys frequently to prevent trouble. I have set up scripts to do this automatically every week.
    • Set up your Kerberos server to log all activity to an SQL database, and use any of the excellent pattern analysis tools (such as UserEye) to alert you to suspicious activity.
    • Make sure you use a switched network, so that nobody can sniff traffic or engage in ARP spoofing.
    Since the time when I set up this system, we have had zero security breaches, and I earned a large (double digit percent) raise.

    Good luck!

    Bill

    • My favorite system for mixed interoperability, if you don't want to mess with kerberos, that is, is Microsoft's Windows Services for Unix. In addition, you have capabilities such as the Gateway for NFS which solves some problems, and gets Samba out of the environment, if you're concerned about open source in a production environment. Link.. [microsoft.com]

    • Re:Yes there is (Score:2, Informative)

      by def ( 87618 )
      Most of your points are quite sound, and I agree with them, especially avoiding NIS+, I worked on a network that used it for authentication and working with the database was annoying at best, however:

      Stay away from AFS and Coda

      Staying away from Coda is an excellent idea, it's a research filesystem that will probabally never be able to be used in the real world. AFS, on the other hand, is quite stable and has management and security features that far surpass any implementation of NFS. If you are serious about a network filesyste, dedicated hard drive partitions (or even RAID arrays) shouldn't be a serious obsticle. The volume management features of AFS also make such a "sacrifice" trivial.

      However, it goes without saying that AFS is not the easiest thing in the world to set up or become acustomed to. If you have the time to seriously consider a network filesystem though, I would definately recommend atleast looking at AFS.
      Also, as long as you are going to the trouble of using Kerberos for authentication (which I also agree with), AFS integrates with Kerberos quite nicely.

      Make sure you have a switced network

      While you almost certainly must have switched networking at any scale these days, it is important to note that the mere existance of a switch does not mean that traffic is immune to be ing sniffed. There are relatively simple attacks against switches that can force them to fall back into broadcast mode.

      Overall, however, I agree with your suggestions for setting up a secure system.

    • Re:Yes there is (Score:2, Insightful)

      by jslag ( 21657 )
      * Make sure you use a switched network, so that nobody can sniff traffic or engage in ARP spoofing.


      Isn't the whole point of arp spoofing, that it allows sniffing despite switches?

    • AFS:

      I work on afs volumes on a daily basis (only as a user, I'm no administrator there) and cannot share your concerns regarding stabilty (Clients are linux, I don't know the server-side at all).

      NFS:

      I'd *never* use -o soft! It will break many applications when you have a short outage. Use -o intr instead. It's the same as 'hard' but it's possible to kill applications which wait for a broken/down/unreachable NFS-server.

    • Re:Yes there is (Score:3, Insightful)

      by wfrp01 ( 82831 )
      Use NFS tunneled over SSH for file distribution.

      If you have linux clients, what's to prevent me from mounting any user's data that I want? I pop in a Linux boot CD, become root, read the necessary ssh private/public key data. Then I become any user I like, and mount away.
      • Any decent admin worried about security will disable booting from CD (and floppy) and password-protect the BIOS configuration screen.
        • But again you have to remember that if the person is determined enough and brave enough to walk up to the server, what's to prevent them from taking a screwdriver to reset the bios settings (and erase those passwords). You have to stop worrying at some point because this string of logic goes on forever.
        • Any decent admin worried about security will disable booting from CD (and floppy) and password-protect the BIOS configuration screen.

          Except that you don't always have control of all of the workstations. University personally owned computers, for example. What you're suggesting will only work in a rigidly controlled environment. Better to have a more secure filesharing methodology. NFS4, for example. Or I understand AFS to be more secure. However, this would seem to be a difficult system to use in an evironment that must also cooperate with, say, Windows clients.

          I hate to say it, but as things stand today, you'll end up with a much more secure shared filesystem if you use samba + windows clients. Unless you use a system like AFS that doesn't play nice with others. This is definitely a chink in the *nix armor.

          Maybe I just don't understand AFS well enough. I've been pinning my hopes on NFSv4, but this [samba.org] certainly looks discouraging. Maybe umich [umich.edu] will save us. By June 30th, they say... Here's to William, Jim, Kendrick, and Jake!
      • Although not foolproof, BIOS/FIRMWARE password to prevent floppy/CD booting is key. Sure you can crack the case open and reset the jumper ..blahblahblah, but now you are getting to tampering with physical hardware with can be secured as well. We are talking less then 2% of the people can will be able to break this, let along actually try to do it.

        • Re:Yes there is (Score:3, Insightful)

          by wfrp01 ( 82831 )
          Although not foolproof, BIOS/FIRMWARE password to prevent floppy/CD booting is key.

          I should have been more clear. The problem isn't the client, it's the protocol. NFS is inherently insecure. Sure, you can BIOS protect your workstations. But you can't bios protect my laptop. You can't stop me from spoofing my mac address, my ip address, etc.

          Now you're right, of course, that most people can't/won't do this. On the other hand, what are you trying to protect? When your boss asks "is this secure?", what do you say? Remember too, that you don't have be much of a whiz to do a google search.

          Are you going to export your accounting folder? How about HR stuff? There are good (well, maybe 'good' isn't the right word... ;) reasons people would want at the information therein. It really doesn't take a lot of effort to get it, if you're using NFS.
    • If you use the Arla [stacken.kth.se] AFS client, you won't have to put a lot of buggy code into your kernel, because most of the code is in a user-space daemon. The kernel module is really small.

      AFS is good. The volume management is great, and you get real access control lists with groups. How about moving a users home directory to a different server, while the user is logged in? It's completly transparent. Or how about letting people create their own groups? That is useful. And there's proper authentication.

      Random advice:

      • Use Heimdal [pdc.kth.se] Kerberos 5 KDCs (plural for redundancy). Do not use the kaserver that comes with AFS.
      • Put Heimdal and KTH-KRB [pdc.kth.se] (kerb 4) on all clients.
      • Use OpenAFS [openafs.org] servers.
      • Use OpenAFS clients for Solaris, and Arla AFS clients for Linux 2.2.x. For Linux 2.4.x, OpenAFS clients might work better. I don't know, and probably it depends.
      Finally: Do not trust your network. Ever!

  • LDAP (Score:4, Informative)

    by duffbeer703 ( 177751 ) on Saturday December 29, 2001 @04:59PM (#2763132)
    LDAP & PAM is the way to go. We recently implemented a single sign-on system @ work and it works great for 60,000 interal and about 150,000 internet users!

    I believe there is an OpenLDAP implementation is Iplanet is too expensive.
    • Isn't LDAP a bit .. overkill? The poster described a workgroup, which to me isn't more than a hundred machines, at most.

      • Re:LDAP (Score:2, Interesting)

        by sjehay ( 83181 )
        I've helped setting up an experimental lab full of machines of all sorts (mainly Linux on various types of hardware, some Windows 9x/NT and a few others such as Solaris, Irix and HPUX) - but only about 25 machines in all. This is on a shoestring - most of the hardware is fairly old and slow, and we're certainly not about to go out and spend any of our small budget on software if we can avoid it. Anyway, our solution for authentication was to use OpenLDAP on the server (this was relatively easy once we figured out how - there are plenty of HOWTOs drifting around, but reply if you can't find them and I'll dig them out for you) - on the Linux clients we could use the PAM module, on Windows, the latest Samba can pretend to be a domain server and take its information out of LDAP and there were various bits of code we found for the other Unix boxes. In the event, we just used our own little Perl scripts to do user admin, but there are plenty of web/pretty-clicky interfaces to it available. I disagree with the poster who said this was overkill for less than a hundred machines - as I say, it was easy to set up and works well for our couple of dozen slow machines (primary server is an old HP NetServer at 100Mhz). I'm afraid we're still using NFS for home directories, though, and I'm not particularly happy about that - we'll move to something better at some point, but I'm watching this thread with interest to see what suggestions the rest of the (Ask)Slashdot community might have!

    • Re:LDAP (Score:3, Informative)

      by nbvb ( 32836 )
      If you use Solaris (which I'm guessing the original poster is, because he mentioned NIS), then the iPlanet directory server is included with Solaris. You have a license for up to 300,000 entries.

      Good luck!
  • But isn't Samba supposed to do this?

  • Funny (Score:1, Interesting)

    by Anonymous Coward
    I asked a very similar question about a week ago but, got rejected. My question wasn't "what to use?" but, was "What does everyone use?" My downfall was that I asked for real world environments with multiple platforms. So, I'll ask again in the comments.

    What is everyone using for user account management in shops that support *nix as well as Windows 2000 or others like Netware?

    Surely everyone is not using NIS with its limitations. OpenLDAP seems like a logical choice but, how does one authenticate Windows 2000/XP to OpenLDAP, despite Microsoft's claims that Active Directory is LDAP compliant. Microsoft's Active Directory might be LDAP and Kerberos compliant in the loosest sense but, interoperability with Unix systems seems very elusive. So, what is everyone else doing centralize network management??
    • What I did at my last place was have two different worlds, Unix and Windows. We bit the bullet and just dealt with it.

      For Unix (Solaris), we used NIS, and not NIS+. Why? because we trusted folks inside the firewal and NIS is nice and easy. For Windows, we used the standard Windows stuff.

      • can I ask why you didn't use samba to unite the two worlds?
        ---
        • I don't have a great reason, but basically it just added another level of complexity that we didn't want to deal with at the time.

          The YP/NIS stuff by itself was easy, Windows by itself was easy so we just stopped there. In addition we weren't using Samba at the time and inertia just kept it that way. (We used an NFS client on the few Windows machines that needed Unix file sharing. There was a complex, but good, reason for using the NFS client.)

  • It's a pity that OpenBSD doesn't support this...
    except for Kerberized and/or ssl'ed CIFS/SMB
    it seems the finest solution (and any non-Windoze
    CIFS/SMB client is a PITA).
    • There's more to the story than this. "Kerberized NFS" actually uses RPC-GSSAPI, and once you push GSSAPI (Kerberos 5) into the RPC layer then you have a lot of options. Think of RPC-SUN and NIS+, NFS+.

      I know that one OS supports it, but it hasn't been added to OpenBSD or Linux yet (AFAIK). OpenBSD still uses Kerberos 4, not Kerb5/GSSAPI, and Linux has had some policies that made it hard to add crypto. Hopefully a suitable patch will be available through the new security API.

  • NDS (Score:1)

    by tiggerX ( 546950 )
    Novell NDS works very well in mixed environments.

  • openLDAP+Krb5+openafs

    sounds quite nice.

    anybody used this ?

Slashdot Top Deals

An authority is a person who can tell you more about something than you really care to know.

Close