Neil Neely wrote: > 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 > For Open packages, look at Luke Howard's PADL products <http://www.padl.com>. When I was last working on this (a couple of years ago), PADL didn't have caching, but I believe that this has been done since then. Luke is very dedicated to the work, and is responsible for creating the standard (RFC2307) that is accepted as 'the standard' for Unix to AD connectivity. His company also offers commercial support if that is important to your organisation.
The two commercial packages that I've seen that are built to to this are Quest(Vintela) and Centrify. Microsoft's SFU is underpowered, but if you have only a few users and machines, you might be able to get away with it for now. I can't recommend it for any sizable organisation. SFU does not scale well as all lookups are done directly to AD - it's meant for a large Windows site that has a very small Unix infrastructure. Try doing an 'ls -l' in a directory with files owned by hundreds (or thousands) of different users - and be prepared to wait.... Quest and Centrify have local caching of AD data, so the load on your AD servers is minimal most of the time, and there is no latency on obtaining user data. For 'future-proofing' look for RFC2307bis compatibility (unfortunately, this RFC was never brought through for ratification, but it does describe Kerberised LDAP compatibility with functionality that scales to large infrastructures). All of the products (including SFU) require extensions to the AD schema, and since AD schema changes are irreversible once installled, experiment with whichever product(s) that you are interested in on a test domain before committing yourself. VMware is your friend - I did a lot of playing around with Win2K3 servers running under VMware, using snapshots to play 'Groundhog Day' with the AD data (instant schema change reversal :-). AD is a solid back end service. I hammered AD servers during testing, and the only way that I could make them crash was to do a nasty DOS attack (by accident :-) - I hammered Kerberos authentication requests without closing the TCP connections, and eventually ran out of sockets on the server... For every other load test that I performed, AD degraded 'gracefully', i.e., it came up to a maximum number of transactions per second, and held it - regardless of additional load applied. Further load did not cause it to 'crowbar' (it didn't drop off in the number of transactions per second as more load was applied). I was not expecting this kind of solid performance from a Windows server (having heard the horror stories about IIE and Exchange). AD on Win2K3 also expands nicely when you add replicas. It was also 5-6 times faster than the Solaris NIS+ servers that we were running at the time when retrieving individual results. Where AD (and every other LDAP server that I've seen) falls down (compared to NIS+) is when you 'walk a map', since the NIS+ protocol is built to deliver the entire map in large chunks, and LDAP returns each entry individually. This is why you want caching in the client - map walks become 'free', and the load on your AD (or other LDAP server) is greatly reduced. OTOH, I'm an 'OS gourmand' - I eat them all! While I admit to a little bias, I'm do try to use the OS/platform/application that does the best job for a given service (which also must take into account local expertise for maintaining the system). If you have competent Windows admins taking care of your AD infrastructure (as my $WORK does), I would have no qualms about basing your Unix authentication and authorisation on AD. Having dealt with Sun and their NIS+ fiascos for a number of years (they didn't really get their act *mostly* together until Solaris 10), AD on Win2K3 was a pleasant change! (AD on older versions of Windows has some performance and configuration limitations that were corrected in 2K3.) - 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/
