Just a quick question here: in all the documentation I've seen for
connecting PacketFence to a Palo Alto firewall for SSO, the
instructions state to grant the API account access to *everything*,
rather than just the User-ID part of the API. Does it really need all
that? I like the idea of that inte
I asked about this earlier, but I wanted to double-check after doing
more testing.
I've successfully set up separate self-registration portals for our
different user groups by putting the second portal on a separate
interface, and setting up a connection profile that filters on the
FQDN of the sec
42
> Connect with Us: <https://community.akamai.com> <http://blogs.akamai.com>
> <https://twitter.com/akamai> <http://www.facebook.com/AkamaiTechnologies>
> <http://www.linkedin.com/company/akamai-technologies>
> <http://www.youtube.com/user/akamait
nnect with Us: <https://community.akamai.com> <http://blogs.akamai.com>
> <https://twitter.com/akamai> <http://www.facebook.com/AkamaiTechnologies>
> <http://www.linkedin.com/company/akamai-technologies>
> <http://www.youtube.com/user/akamaitechnologies?fe
LDAP as auth source), each which leads to
> the the two different "select-role" portal modules, one tuned for faculty and
> the other for staff
>
> it its only 2 "paths" then its probably ok... otherwise, it could become a
> bit un-manageable
>
>
> On T
I'm not sure what the right approach is for this, or how much of this
PacketFence can do. I'm not planning on using PF as a captive portal,
I just want to use it for the self-service device registration page
for MAB on wired and wireless connections. Ideally what I wanted was a
system where our fac
