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@xxxxxxxxxx [mailto:centos-bounces@xxxxxxxxxx] On
>> Behalf Of Jeffrey Hass
>> Sent: den 29 januari 2014 08:47
>> To: CentOS mailing list
>> Subject: Re: 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@xxxxxxxxxx
> http://lists.centos.org/mailman/listinfo/centos
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
