Edward Ned Harvey wrote: > Oh boy - you've touched on a fun topic. One that I've worked on a lot (and > I'm sure a lot of other people here have as well.) > > There are several options available - Each one has its strengths and > weaknesses. What I describe here is by no means a complete list. Just a > list of what I can talk about. > > --- Option 1: > The easiest one to set up is Unix services in Windows Server. Just add > "Identity Management for UNIX" to your server, and voila - you now have extra > tabs available for each user and group inside of AD. You should know - This > stores the unix passwords on the server in a different format than the > standard active directory password store, and since the original password > store is non-reversible encryption, installation of UNIX services doesn't > work instantly. Each user must reset their password once after the service > is installed, before their password will work for UNIX. If you enable the > NIS server, that's the absolute simplest way to get things working. > > There are a couple of downsides to the above solution - (a) If you want to > follow the redhat user-private-group convention, then you run into a barrier. > In AD, you cannot have a username and a group of the same name. The > simplest solution is simply create "eharvey" and "eharveygroup" - but it is > recommended to keep object names to 8 characters or less. Just a small > obstacle. (b) Many people will tell you NIS is not the most secure protocol > in the world. It does use encryption, but it's a weak form of encryption. > Make your decision based on your organization's requirements. (c) There are > a lot of advanced features available in things like LDAP, or standard unix > NIS, which are not available in MS NIS. The MS NIS is only usable for basic > functionality - pure posix - username,password,UID,GID,FullName, and shell. This is actually more dangerous (security-wise) because with NIS you are exposing the encrypted passwords via NIS, which can then be used to crack the passwords. NIS passwords are also limited to eight characters, and if you sync (or allow your users to sync) their NIS and AD passwords, you are exposing both your Windows and Unix accounts. AD passwords can be much longer than eight characters and the encrypted format is not exposed to the world (unless you do something really bad to your AD config :-).
I would only (barely) consider installing NIS in a very well controlled, trusted environment - and even then, I'd probably skip it. (I've spent a lot (too much!) of the last 20 years managing NIS and NIS+ environments - PLEASE move on to more current technology!) If (after all my protestations against it :-) you do choose to use NIS via AD, take Clif's advice and use the AD server as a master with Linux replicas to handle the actual load - AD's NIS does not do well under load. NIS clients also don't like switching between replicas (slaves), they take their time switching and you can lose processes in the meantime, so keep your NIS slaves close to the clients (network-wise) and put them on stable, unloaded machines to prevent timeout. I would not put them on virtual machines, or machines shared with other services other than something lightweight like DNS. For a small number of client machines (which sounds like your situation) a single NIS slave might seem like enough, but two is a better idea. The slaves go away for a period of time when being updated. I would also put only the slaves into the 'ypservers' table on the slaves to prevent the clients from attaching themselves to the AD 'master' NIS server. > --- Option 2: > LDAP. This is very good, very powerful and extensible, reliable, and secure. > If you can figure out how to get it working. Your first-time setup will not > be easy, I promise you that. I think people normally take a class or two, > read a couple of books, and google around for a while before they can get > this working between unix & ad for the first time. After you're an expert it > isn't hard anymore. Perhaps somebody has a recipe? There is always a risk > that some AD schema change could mess something up - for example if you > upgrade your server from 2003 to 2008 or whatever. The risk should be > minimal, so don't be scared - just be cautious and use backups liberally. > > You need to store posix information somewhere. I believe another person > mentioned you can store it in AD as long as you install the UNIX services and > NIS, but simply disable NIS. > IIRC there are some issues with using LDAP for such authentication (if your machines are not in the AD domain they don't have 'machine accounts'), but I believe that they can be worked around - if your machine administrators permit it, which may be a challenge since it does reduce the security of the AD infrastructure. > --- Option 3: > Kerberos. Same pros/cons as ldap, just another protocol. Has the advantage > of single sign on support. I'm guessing that the LDAP setup will be slightly > easier than the Kerberos setup. But I'm not really sure. > Kerberos brings more complexity with it - tickets and their management. Tickets time out - or you can set the timeout very long and expose your accounts to nefarious ticket reuse. The AD clients for Unix that I've seen have strategies for managing ticket timeout. If you're considering Kerberos, you might as well go to full-blown AD, and get the advantages of full integration. > --- Option 4: > Winbind. This is a clever little component of samba. It allows your linux > client to join the windows domain just like another windows client. It has > some snags with password synchronization (but with a little massaging you can > get it to work). The main problem is - Each client has no authoritative > source for UID/GID posix unification, so each client autogenerates the > UID/GID's for each user account. As long as you're on a standalone machine, > no problem. But if you have a bunch of clients all using NFS, then there's a > problem. You need to ensure "eharvey" has the same UID on all the machines, > or else the permissions on the NFS server will get screwed up. There are > solutions to this problem - I believe another user posted a response to this > effect. > > > I haven't tried this, but would only consider such solutions for a small lab environment or other non-production application. It is far too unregulated, and you will have issues when files on the server (or attached NFS filesystem) can't be properly 'owned' until each user signs on to each client machine. It does sound like a useful trick for private one-offs, though... Try this at home! :-) - Richard _______________________________________________ Tech mailing list [email protected] http://lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
