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. --- 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. --- 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. --- 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. > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Neil Neely > Sent: Monday, December 29, 2008 1:57 PM > To: LOPSA Technical Discussions > Subject: [lopsa-tech] AD integration with Unix > > We're looking at integrating our *nix machines with our AD servers and > are trying to find the "Best" way to do this. In this case I'm > finding my google-fu isn't working in my favor... there is no shortage > of information. Every time I think I have a complete grasp of ways > this can be done I find one more. So there are plenty of resources > for how to do this using technique X, what I really need is some > feedback from people who are further along in this evolution that can > give some perspective on which approach they think is the best. > > Disclaimer: I am in the process of learning how these bits fit > together, and if I've said something truly bizarre it is likely out of > ignorance not arrogance so I really would appreciate being pointed in > the right direction. > > Relevant background details: > ~50 production servers that are centrally managed (unified UID and > passwords) using homegrown syncing - we would like to move these to AD > Already have AD infrastructure in place authenticating staff work > stations (~50 workstations) > The servers exist to support our customers (not staff in general) > These servers do not require shared home directories for staff. > Staff accessing these servers are all performing some task relating to > "administration", though at different levels (tech support through sys > admin). > * primary concern is not securing these machines against it's > legitimate users (so NIS may be acceptable in this environment). > This economy stinks and doing this without any capital expenses is > very important. > > Combinations we are seriously considering (in no particular order): > > NIS w/Kerberos (via SFU) > > Winbind > > Likewise Open > > We've found various bits and pieces that seemed promising with each of > these approaches. This is our short list of best fit for the problems > we've got, but perhaps we've overlooked something. I would really > appreciate any pro's/con's from the trenches on this topic. "Likewise > Open" seems to be the easiest to install at this point, so is slightly > ahead in our evaluation. > > Thanks for your time, > > (sidenote: AD is being chosen because it is existing established > infrastructure here that looks like it will do the job we need, > nothing at all against openldap, this is just using the tool that > we've got so we can focus on solving other challenges.) > > Neil Neely > http://neil-neely.blogspot.com > > > > > _______________________________________________ > 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/ _______________________________________________ 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/
