Hello Sorin, Good call - not sure how far your coding goes and with what/how languages and scripts... Make sure to have as much as possible on VM's related to your security 'servers' -- so that you also get a virtual built in Disaster recovery as well. KERBEROS is a very secure, albeit cumbersome component to implement (// network wide // think of... ) Having said this, um, with the tools available with openSource.. and I'm assuming you're such a shop due to running CentOS -- you can customize the ticket transport aspect after the encrypted authentication token is created and 'capture' that and with some slight tweaks create your own 'virtual Federated' auth method by way having total control of your requests, successes, failures and the like. Note: I didn't catch it are you using the Microsoft's implementation of Kerberos? There's a reason I ask, you said you need to do something,, sounds like fairly quick, probably a good thing, if nothing else get centralization = control! - more so -- than before ~ and so it goes, you will have encapsulated tickets on steroids, to be sure.. but if you're the only person.. is your shop that big that SSL wouldn't do the trick? with some slight coding and enhancements // customization // - usually not supported by a 'given vendor' so beware there... You will see performance over the other solutions in this space and some scalability - without know 'a lot' about your infrastructure -- and appliances therefore entered into the equation - it's hard to really say. But sounds like you have Unix/Linux backend and alot of Windows stuff (we can't seem to ever get away from the highly faulty Windows suite) -- maybe when I retire, but anyway, and you're probably hitting a few AD servers -- and therefore there is the rub. I have some implementations of several solutions if you're really serious about this as I can strip out the confidential stuff (I do weird things for various 'friendly' governments, world-wide) and have seen a thing or two here... mostly what 'not to do..' Watch out for the posers out there as they will fire off the first thing from their minds and usually because they do not know much and end up with a flame or such ~ rarely a thank you.. In any event, I offer this as is and hope you enjoy your career with security. It truly is the highest paying area of IT at this given time.. I don't care what anyone says. Think of the Target stores out there and such.. and you'll see SECURITY all over 2014 and more. We most don't get it.. They do a VISIO chart and build a server and usually *uck it up worse than ever. GOOD LUCK. CentOS - is awesome for this kind of thing as a back-end and front-end. ENCIRCLE your WINDOWS servers and crush them! heh. ~ good night. Oh summary: KERBEROS good for larger scale operations that need total control and performance for many up-calls and down-calls NTLM - um, don't do it. SSL - vxx - ~! you can do this -- with customization - the rub here is customization means little if any support, if you leave, the 'company' is toast, in many cases.. there are no 'upgrades' to security with an ENHANCEMENT or customization.. and so it goes, you own it, until you die or leave... Some experience for you here. Lots of it. Tons of it. Okay.. I did my community service for the day. Wizard of Hass! On 1/29/2014 12:11 AM, Sorin Srbu wrote: >> -----Original Message----- >> From: centos-bounces at centos.org [mailto:centos-bounces at centos.org] On >> Behalf Of Jeffrey Hass >> Sent: den 29 januari 2014 08:47 >> To: CentOS mailing list >> Subject: Re: [CentOS] NIS or not? >> >> Hi friend - >> >> what is your end goal with this effort to obtain security with your >> nodes over the 'wire' - >> >> there are some other solutions -- kerberos is now used heavily by >> microsoft so that's enough to make me >> run for the hills... just saying.. >> >> i've set up other solutions to be sure -- even against the blasted (not >> a real LDAP) AD. >> >> anyway.. just some thoughts... it's not trivial. any of the solutions, btw. >> not at all.. >> >> j/h >> San Francisco/Holland/Saudi Arabia > Primarily to enable less administration in the long run with centralized > logins, instead of keeping each single client updated with respect to shadow, > passwd, bashrc, hosts and so on. > > Some sort of encryption would probably be wise to use, as NIS uses clear text > passwords. I don't trust our university network that much, even though the > traffic should pretty localized. > > I'm aware that setting up Kerberos probably will be a big project, > nevertheless, we must do something about the current mess. As I'm the single > sysadmin at the department, my time is finite. Automation is good, but as I > wrote before, regular bash-scripting (however powerful) will only take you so > far. 8-/ > -- > //Sorin > > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos