The user's credentials never get copied or duplicated anywhere. The
authentication method you choose simply tells PF where to talk to and how to
talk to it. The backend user store will return a value that PF understands and
will act upon, but as for the user's account info, it never leaves the store.
This is what is known as an Authentication Oracle. PF (using your chosen auth
method) acts as a go-between for your user and the identity store, hence the
mystical name of oracle : )
PF does store some info about the user in its DB, but nothing related to the
user's credentials.
In short, every time the user hits a network managed by PF their credentials
(and a few other things) are checked to make sure they are still allowed access.
Jake Sallee
Godfather of Bandwidth
System Engineer
University of Mary Hardin-Baylor
900 College St.
Belton TX. 76513
Fone: 254-295-4658
Phax: 254-295-4221
HTTP://WWW.UMHB.EDU
From: David Schiller [mailto:[email protected]]
Sent: Monday, September 17, 2012 9:01 PM
To: [email protected]
Subject: Re: [PacketFence-users] Only some SNMP traps sent
Thanks, this info is very helpful. If you are using LDAP or external Radius
authentication on the captive portal and a user hits that for the first time,
do their credentials get copied over to the PF FR server? Or do they have to
have a separate account on FR?
I promise to let this thread die after your reply.
On Sep 17, 2012 6:18 PM, "Sallee, Stephen (Jake)"
<[email protected]<mailto:[email protected]>> wrote:
<WARNING>
long post
</WARNING>
TLDR version ... http://bit.ly/rzaNtq
2 things:
1) If you are working on a new problem, start a new thread. It is helpful
for the people who will search this thread later for information. The title of
this thread has nothing to do with the last 3 emails you have posted.
2) If you encrypt a wireless (or even a wired) network your users WILL
have their identity challenged BEFORE they can connect. The nature of that
challenge is up to you, it could be username + password or via certificate,
etc. But the fact is that any encrypted network will require some form of
identity to access it.
>From reading this thread I see you want 2 networks:
1) Open network:
a. No restrictions on who can access, no registration needed, completely
open access. You will handle the traffic by only allowing specific traffic
through a firewall.
b. This network does not need to have any affiliation with PF at all, as
your stated requirements are basically not to do anything.
2) Secure Network:
a. I would NEVER use the term "secure", encrypted is fine but do not say
"secure", I don't know where you are from but this could open you up to legal
ramifications.
b. This is the network PF will manage access to.
c. If you want to encrypt a network you will need to challenge the
identity of a user BEFORE they can fully associate. 99.9% of the time this is
done by a username and password check ... however you can also do this via
certificates using TTLS or TLS. But you CANNOT encrypt a network without SOME
form of identity challenge. This is the very nature of encryption.
You also make some interesting remarks about the RADIUS server.
PF uses FreeRADIUS (FR), the most widely deployed RADIUS server in the world.
It is good, I promise : )
To your assertion that you want FR to do the vlan assignment and not
authentication ... I think this is coming from a fundamental misunderstanding
of how FR and indeed PF in general works.
There are excellent resources on how FR works on the internet and on their
mailing list. I would HIGHLY suggest that you look into both. Once you get
your packetfence environment up and running you will quickly realize how much
you depend on it. To that end you should take the time to become intimately
acquainted with how it works ... or find and pay someone who is.
However, back to your statement, FR is the engine that makes vlan assignment
possible. It does this by acting as the authentication, authorization, and
accounting center ... this is why you will see RADIUS also referred to as a AAA
server and in cisco gear the configuration directives for RADIUS are under the
AAA heading.
Even if you do not use RADIUS authentication for your captive portal, you will
still need to use it for setting the users' vlan and radius can only manage
connections that it is set to manage. In short, you WILL use RADIUS to
authenticate your users ... it is the technology that makes vlan switching
possible.
What we are calling "vlan switching" is just short hand for what is really
happening. What is REALLY happening is this:
1) User attempts to associate with network
2) IF network is encrypted or access is controlled somehow the user's
identity is challenged by RADIUS
3) RADIUS talks to PF via a perl module
4) PF looks up the user and returns the correct info to RADIUS
5) RADIUS sends the correct info back to the switch / AP
6) IF the user is registered then they are now associated with the
network: if not they are now on their way to the captive portal
7) The user validates their identity via the captive portal and is then
kicked off the network via SNMP or RADIUS CoA
8) Go to step 1
If you want a remote RADIUS server to do the authentication simply have FR send
all the pertinent info to it because AFAIK you cannot have one RADIUS server
auth a client and another set its network access ... this would be a glaring
vulnerability and very exposed to attacks. You CAN have all of the requests
seen by PF's RADIUS server forwarded (read proxied) to another server; but at
this point, unless there is some very technical reason, you are simply adding
overhead without much gain. There are times when proxying a request is
necessary, but that is a discussion for another time.
I hope this info is helpful, I know it won't completely solve your issues but
it should give you some foundational understanding and, perhaps, from there you
can find your way onward to Network Access Control Nirvana! Good luck!
Remember ... if all else fails, call Inverse. Pay them a few bucks and watch
them perform their magic ... it's pretty freakin' sweet.
Jake Sallee
Godfather of Bandwidth
System Engineer
University of Mary Hardin-Baylor
900 College St.
Belton TX. 76513
Fone: 254-295-4658<tel:254-295-4658>
Phax: 254-295-4221<tel:254-295-4221>
HTTP://WWW.UMHB.EDU
From: David Schiller [mailto:[email protected]<mailto:[email protected]>]
Sent: Monday, September 17, 2012 5:26 PM
To:
[email protected]<mailto:[email protected]>
Subject: Re: [PacketFence-users] Only some SNMP traps sent
So I got farther into this... and I don't think this is what I want. Now, when
a user gets onto Internal, they are immediately asked for a username/password
while they are associating. Digging into it a little, it looks like this new
Radius I activated on PF is now being used for authentication... I do not want
this... I just want to use PF's Radius to to VLAN switching. I want the
authentication to be done via the captive portal, and that will authenticate
off of a different remote Radius server.
I could really use some hints on how to get PF's Radius to do the VLAN
switching. Hopefully this setup is not so outside the normal PF usage that it
is possible.
On Fri, Sep 14, 2012 at 2:15 PM, David Schiller
<[email protected]<mailto:[email protected]>> wrote:
So now I'm stuck on the issue I think you were talking about with vlan
encryption over an open wireless... what is the best solution for this? Are
you saying we need a WPA password on Internal for this to work? I am trying to
set that up but it's confusing with all of the options for authentication...
which seem to conflict at times.
On Fri, Sep 14, 2012 at 1:18 PM, Francois Gaudreault
<[email protected]<mailto:[email protected]>> wrote:
Hi,
> SSID Open: people will just connect to this on vlan 96 and instantly
> have access (firewalled downstream to limited outgoing ports)
>
> SSID Internal: people will connect to this on vlan 95, they will see the
> registration portal, authenticate (via a different RADIUS server), and
> then they will be switched to vlan 94 and have full network access
>
> Looking over your replies, I started to think that maybe the scheme you
> listed is more like for Guest access, they get the portal, and then
> users that want full network access will have to have some other type of
> credential and they never see a portal?
Correct. That's the usual flow people will do.
In you case, if you want to have a fully open SSID, you put :
- OPEN
vlan 96
- SECURE
vlan 94 backup 95
The backup vlan is just a way to list more than one VLAN on the same SSID.
--
Francois Gaudreault, ing. jr
[email protected]<mailto:[email protected]> ::
+1.514.447.4918<tel:%2B1.514.447.4918> (x130) ::
www.inverse.ca<http://www.inverse.ca>
Inverse inc. :: Leaders behind SOGo (www.sogo.nu<http://www.sogo.nu>) and
PacketFence
(www.packetfence.org<http://www.packetfence.org>)
------------------------------------------------------------------------------
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
PacketFence-users mailing list
[email protected]<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/packetfence-users
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
PacketFence-users mailing list
[email protected]<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/packetfence-users
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
PacketFence-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/packetfence-users
