Re: ..::Cisco Nac::..

2011-02-26 Thread Alfonso Alejandro Reyes Jiménez
Thanks Alan. -Original Message- From: Alan DeKok To: con...@gmail.com, FreeRadius users mailing list Subject: Re: ..::Cisco Nac::.. Date: Sat, 26 Feb 2011 08:06:15 +0100 Alfonso Alejandro Reyes Jiménez wrote: > Hi everyone, I need to configure a freeradius server to grant access

Re: ..::Cisco Nac::..

2011-02-25 Thread Alan DeKok
Alfonso Alejandro Reyes Jiménez wrote: > Hi everyone, I need to configure a freeradius server to grant access to > our Network based in the Cisco Nac solution. > > I just want to know if anyone has configured Cisco Nac on their network > and any advice when doing it. I'm

..::Cisco Nac::..

2011-02-25 Thread Alfonso Alejandro Reyes Jiménez
Hi everyone, I need to configure a freeradius server to grant access to our Network based in the Cisco Nac solution. I just want to know if anyone has configured Cisco Nac on their network and any advice when doing it. Right know we are just gathering all the information related (Vendor

Re: coa proxy'ing with a NAC device

2010-07-29 Thread Alan DeKok
Kevin Ehlers wrote: > I'm having a really hard time with proxying or just dealing with > CoA's. The documentation just isn't working for me. Well... it's as clear as we know how. > I can configure the coa server. I can get the originate-coa server up > too. I can send CoA's to the server, b

coa proxy'ing with a NAC device

2010-07-27 Thread Kevin Ehlers
re-send them as if it was originating the CoA. I see that they're being processed when looking at debug mode. But I just don't know how to do anything with them. This is what I want to do: [lots of switches doing dot1x]<->[freeradius]<->[NAC device, PacketFence in this case

Re: NAC

2007-07-13 Thread Alan DeKok
Phil Mayers wrote: > I haven't been following the NEA so their work might be rubbish, Absolutely NOT. *Never*. It will solve _all_ the problems of NAC. > but the > untrusted client-side nature of the software does not make it > intrinsically worthless - the reason being

Re: NAC

2007-07-13 Thread Phil Mayers
> BTW, this is one of the MAJOR concerns I have with the NEA working group: the > explicitly declared the integrity of the client-side piece of software "out > of scope" for their working group. This is somewhat fatal, and undermines > most of the efforts. > > At least, Cisco's solution delive

Re: NAC

2007-07-13 Thread Alan DeKok
Thomas Dagonnier wrote: > The home network can always check the security when entering the home > network via VPN (for example). And when the machine is roaming? The two sites may have a trust relationship. In that case, the local site may ask the remote site if the machine is OK. Why would

Re: NAC

2007-07-13 Thread Stefan Winter
Hi, > Regarding some comments made earlier in NEA list, wouldn't > an approach similar to microsoft ("statements of health" or SoH) would > be a better solution ? > > In this case, the client would just send its status (SoH) and get an > answer from the server (+ network access granted/isolated/de

Re: NAC

2007-07-13 Thread Thomas Dagonnier
On 11/07/07, Alan DeKok <[EMAIL PROTECTED]> wrote: > > > It's another topic that I'm overall sceptical of NAC, IMO a network should > > only reactively shut a client down *after* it did something wrong, not > > proactively sniff around the local environment and

Re: NAC

2007-07-13 Thread Thomas Dagonnier
ty when entering the home network via VPN (for example). As for local access, it can't relied upon to guarantee that the endpoint will always be secure when connecting to any other local network - NAC won't be everywhere. On 12/07/07, Phil Mayers <[EMAIL PROTECTED]> wrote: > >

Re: NAC

2007-07-12 Thread Arran Cudbard-Bell
Phil Mayers wrote: > On Thu, 2007-07-12 at 12:46 +0100, Arran Cudbard-Bell wrote: > >>>> It's another topic that I'm overall sceptical of NAC, IMO a network should >>>> only reactively shut a client down *after* it did something wrong, not >>>

Re: NAC

2007-07-12 Thread Phil Mayers
> > > > It's a thorny problem no doubt. It'll be a few years before we start to > > see working, interoperable systems I think. > > yep and you still get undone by those systems which dont run a standard > OS and use the network squeezebox, PS3, xbox/xbox360, Wii/gamecube, > slingbox, polycom

Re: NAC

2007-07-12 Thread Phil Mayers
On Thu, 2007-07-12 at 12:46 +0100, Arran Cudbard-Bell wrote: > >> It's another topic that I'm overall sceptical of NAC, IMO a network should > >> only reactively shut a client down *after* it did something wrong, not > >> proactively sniff around the local

Re: NAC

2007-07-12 Thread Arran Cudbard-Bell
k with more > diseases than i would have if I went down to the Congo with not a > single jab and a penchant for swimming in the local rivers. > Or urinating in the local rivers ... Nasty little fishys > we've looked at various NAC systems over the past few years and > al

Re: NAC

2007-07-12 Thread A . L . M . Buxey
ill be largely wide open to attackwe didnt like the huge surge of bad traffic after the holiday season when their systems came back with more diseases than i would have if I went down to the Congo with not a single jab and a penchant for swimming in the local rivers. we've looked at vari

Re: NAC

2007-07-12 Thread A . L . M . Buxey
Hi, > One thing that seldom gets talked about is the absence of TPM on many > systems - making it reasonably trivial for 1st gen TNC-based clients to > submit forged responses. This can only be handled at the administrative > level e.g. formal disciplinary for any staff found running "TNCFaker" or

Re: NAC

2007-07-12 Thread A . L . M . Buxey
ot;os:patchage=91230" > Endpoint-Posture = "av:defage=31353" > Endpoint-Posture = "av:vendor=Symantec" painful. imagine keeping that file updated with what you think are the correct levels for revisions i see why Cisco quickly jumped off the software NA

Re: NAC

2007-07-12 Thread Arran Cudbard-Bell
>> It's another topic that I'm overall sceptical of NAC, IMO a network should >> only reactively shut a client down *after* it did something wrong, not >> proactively sniff around the local environment and lock it away at once. But >> NAC is here to stay

NAC

2007-07-12 Thread Phil Mayers
> I'm happy that Cisco is following that line of thinking in their NAC > solution, > by offering a web-based or downloadable client *after* the EAP session if That has its own problems. If post-auth NAC is done with some kind of web download, you are then educating users to ex

Re: NAC

2007-07-12 Thread Phil Mayers
On Wed, 2007-07-11 at 08:33 +0200, Alan DeKok wrote: > Stefan Winter wrote: > > It is actually quite important. If you are in a roaming scenario where your > > EAP session goes to your home ISP, it makes no sense to tie the posture > > information into the EAP session - it's the *access network*

NAC

2007-07-10 Thread Alan DeKok
how healthy your computer is. The home ISP at the > other end of the world doesn't care that much. It cares a little. It may want to require certain software updates, too. But the local network cares more. > My general preference is that any NAC solution should keep *authenti

FreeNAC: OpenSource NAC

2006-08-29 Thread Hector.Ortiz
FreeNAC provides easy to use VLAN assignment and LAN access control for Cisco Switches and all kind of network devices (Servers, Workstations, Printers, IP-Phones, Webcams...). FreeNAC can be considered as having two phases. Initially, we have taken OpenVMPS (which provides MAC based access con