| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] |
My last summary sparked a number of responses that I thought I should also summarize. The first summary that includes the original question is at the bottom. I edited the responses to shorten them - I hope I didn't change the intent of the messages (I tried not to). Thanks to all who responded .. this leaves me with some avenues to investigate Klaus-Peter Thiessen wrote: >In my former company (9 employes + 5 freelancers + some extra >accounts) we did handle the Situation of accounts on multiple >machines this way: >Most users had a Windows Box (NT4, W98, W2k, Me, XP ++), there >were 2 Macs and some Linux Workstations. Also we had several >Linux servers, ot of wich 2 had two important tasks: >- one FileServer [FS] containing the home directories >- one NIS-Server [NS] containing the passwd information >The FS was NIS client, exported all important Directories thru >Samba _AND_ NFS so that all Windows and Unix/Linux Machines >(even Macintoshs with netatalk) like >- home directories >- project directories, etc >It would even re-export crucial Directories from other machines >that it had NFS mounted. >The NS exported all user information thru NIS (yp=yellow pages) >but worked like all other Linux machines with NFS mounted home >directories. >I guess FS and NS could be one machine >For only having the user accounts handled on ONE machine >NIS is probably what you want! We had the user accounts >on the windows boxes set up manually though (because our >employees had the right to install whatever OS they wanted)! >I guess using LDAP you could tie NIS and the M$-OSes >on a user base ... but then I am not a guru, just an >admin & user :-)) Torbjorn Pettersson wrote: >I've done some experimentaion on the subject, and I can say this >about it: >You don't want to use nfs to keep your accounts in sync. The >security implications alone would stop me, and also, do you >really want to rely on one single boxen to be available at all >times? >What I would suggest is one of the following: >1) Easiest one: unison. With some experimentation with it you > should be able to use it to syncronize password related files > between a limited set of boxen. >2) I wouldn't rely suggest NIS, if you aren't behind good > firewalls or not connected to internet. But if you can > disregard security issues, NIS is easy to setup and manage, > and do replication well. >3) LDAP: Have only tested to setup LDAP once, but I have some > issues with it after trying to do so. Altough I got it up and > running I must say that: a) it is far from obvious how to do > this and b) The available documentation sucks. Altough it is > possible to have several ldap server up at the same time with > replication between, with a master sync site, I failed to get > this working. >4) Hesiod: Overlooked by many, but far easier to use than LDAP, > and providing the same functionality. (It took me 3 days to > get a partially working LDAP environment up, and 2 hours to > get a working HESIOD one. built on top of bind + libc6. Got > the replication working. (Surprise. not. since it is dns zone > transfers.) >5) Kerberos: Not that usable on its own, since it doesn't > provide a catalogue server. (That is, it only handles > verifying passwords, not the actual text lines in /etc/passwd > /etc/group and so on..). But what it does, it does very well, > so this is probably what you would want in combination with a > directory server like ldap or hesiod. Possible to do > replication, and rather easy to setup. (Well, not as easy as > hesiod, but...). Comes with a suite of kerberized version of > the common network related programs, like telnet, but also do > pam plugin very well, so "everyting", like ssh, also works. >6) Security enhancing tools. You can't have to much of it. Don't > know your setup, but of the above protocols kerberos is the > only one that can go over unencrypted lines by itself without > someone looking at the traffic. If you use a catalogue server > like hesiod or ldap this is why you don't want the passwords > to be delivered by that catalogue server as well, they are > sniffable then. (Well, their encrypted part is). So you > should probably run them over ssl or ipsec. > For a production environment you want working replication, > you most likely want the extra encryption you get by > ssl/ipsec/kerberos parts. Carroll, Jim P [Contractor] wrote: >I'm pretty sure you *don't* want to attempt the NFS sharing of >the files you mention. You're just asking for major heartache. >If you just want to focus on the *nix hosts, NIS is a pretty decent win. >I've administered NIS in the past on Solaris, and it's quite nice. Having >said that, we're not using NIS here where I am now (at least not within my >administrative purview). I'd like to implement LDAP, when we have the time. >For one thing, Sun themselves are implementing an internal initiative which >will include LDAP services. LDAP might still be a wee bit rough around the >edges, but.... I think it's helpful to check out freshmeat.net for whatever >LDAP web front-ends are available. Chris Ricker wrote: >I suspect you didn't get many responses because most people would >recommend LDAP, and you said you'd already tried that.... That's still >what I'd generally recommend. It's cross-platform, it's scalable, and it >can be made reasonably secure (all things NIS isn't and can't be ;-). >Kerberos isn't a directory service. It's a secure authentication protocol. >You can use Kerberos, and I certainly would recommend it for many >situations, but you'll still need to use a directory (NIS, NIS+, LDAP, or >that hideous NFS-shared /etc someone recommended) to synchronize account >information between machines. bishop wrote: >NIS is, generally, the way to do remote auth. Or *was*, really. It >transmits the (encrypted) password strings in the clear over the net, >and sometimes broadcasts them. Even if you don't expect it, I have seen >a fellow convince my NIS server to send him a copy of my maps, which is >no good at all; 10 minutes with cracklib and he started sending me the >easier passwords on my network. >Since then, I've not seen any reasonable means to synchronize passwords >easily between machines. My employer uses a very crude timed SCP >method, actually. Although it's got many problems, it's about the best >idea he's come up with for that. >Modern email-server all-in-one kits, like SCO's mail server thingamabob, >use LDAP for authentication, and apparently these things DO tie in >samba, imap, auth-smtp, all manner of similar services, probably through >this new pam-ldap mechanism I've heard about. I hear that, once the >myriad apps all use this pam-ldap thingy, that they really do get it all >tied in. I haven't read up on that, yet. I'm comfortable with my >file-based auth, at least until I get free time to explore this new magic. >I've also heard about something called ldap-nis, which seems to provide >the latter with the former, and all your services which are NIS-aware >may soon start being aware via LDAP. >It appears that, no matter how much you try and get away, LDAP (with >SSL) may be involved in your final solution. First SUMMARY: > >> -----Original Message----- >> From: Brian Johnson [mailto:bjohnson@jecinc.on.ca] >> Sent: Friday, March 14, 2003 1:38 PM >> To: LinuxManagers@linuxmanagers.org >> Subject: SUMMARY: Integrated accounts (between apps and machines) >> >> >> I guess I was expecting email proclaiming the virtues of LDAP >> or explaining Kerberos >> or NIS >> >> I got two emails (and one I accidentally permanently deleted >> while troubleshooting >> some webmail problems) >> >> I've included my original post and the reply I got. Perhaps >> I misunderstand the >> concept, but I think using NFS to config other machines means >> exporting the /etc >> directory and then making symlinks for /etc/passwd, >> /etc/group, /etc/smbpasswd, and >> any other files the authorization system require. Seems >> pretty messy but maybe >> that's what it takes. >> >> I don't know if the XFS solution is for me and my win98 >> workstations and doesn't >> look like it will tie together the user account authentication systems >> >> Maybe all the answers to my prayers were contained in that >> email I deleted (without >> reading) >> >> >> >> Brian Johnson (bjohnson@jecinc.on.ca) wrote: >> > >> >I'm looking for some advice on ways to set up user accounts >> for use on >> >multiple machines. >> > >> >I'm getting tired of manually trying to sync multiple servers. >> > >> >The apps most used are unix accounts (file sharing and >> email), samba (file >> >sharing), and phpgroupware (web based groupware with db backend) >> > >> >I tried LDAP about a year ago and at that time unix services >> and samba >> >could be authenticated by LDAP but used different schemas >> and there was no >> >sharing of the info. There was also only very brief info on >> how to do it. >> > >> >My machines are a mix of Redhat 7.3 and 8.0 >> > >> >I'm currently looking at server setups - is there a >> different approach for >> >servers and workstations? >> >_______________________________________________ >> >LinuxManagers mailing list - http://www.linuxmanagers.org >> >submissions: LinuxManagers@linuxmanagers.org >> >subscribe/unsubscribe: >http://www.linuxmanagers.org/mailman/listinfo/linuxmanagers >> > > > >D. Stimits (stimits@attbi.com) wrote: >> >>If you make sure you have your security patches up to date, you can use >>NFS mounts for all parts of the system that must be in common, and in >>some cases also use SAMBA to export the NFS shares directly to windows. >>There is quite a bit extra to set up if you are using the XFS >>filesystem, but it has some advantages with NFS and with SAMBA, since it >>supports POSIX ACLs (Access Control Lists). XFS has other advantages, >>such as journaling and ultra-efficiency with large files and partitions >>(but the reverse is somewhat true, it isn't as efficient as it could be >>with small files, and using and setting up ACLs can be a lot of work). >>Perhaps the biggest drawback of XFS filesystem is that it is not >>integrated into the 2.4.x kernels...it requires a patch. Add to this >>that the kernels are large enough (by the time you add scsi support) >>that they will not fit on a floppy, even if forced to 2.88 MB on the >>floppy. If you want some the features of XFS though, it is the only show >>in town, and runs extremely well. Check: >> http://oss.sgi.com/projects/xfs/ >> http://oss.sgi.com/projects/xfs/features.html >> http://oss.sgi.com/projects/xfs/faq.html >> http://oss.sgi.com/projects/xfs/1.2_admin.html >> >>Note: XFS has a development email list, any bug found is usually fixed >>in a day or two. >> >>D. Stimits, stimits AT attbi DOT com _______________________________________________ LinuxManagers mailing list - http://www.linuxmanagers.org submissions: LinuxManagers@linuxmanagers.org subscribe/unsubscribe: http://www.linuxmanagers.org/mailman/listinfo/linuxmanagers
[Home] [Kernel List] [Linux SCSI] [Video 4 Linux] [Linux Admin] [Yosemite News] [Motherboards]