Thanks Fabrice! It might take me a while to get this all going. We just
hit the end of the school year, and so now there's a long list of things to
do, and I think it will take me a bit to work through this process.
Joshua Nathan
*IT Supervisor*
Black Forest Academy
p: +49 (0) 7626 9161 630 m: +49 (0) 152 3452 0056
a:
w: Hammersteiner Straße 50, 79400 Kandern
bfacademy.de
On Thu, Jun 14, 2018 at 7:22 PM Fabrice Durand via PacketFence-users <
[email protected]> wrote:
> Hello Josh,
>
> Le 2018-06-14 à 03:42, Josh Nathan via PacketFence-users a écrit :
>
> Hi Fabrice,
>
> For what it's worth, I've found the same results on both PacketFence 6.4
> and 8.0.
>
> And yes, I did/do have packetfence-local-auth enabled.
>
> Our goal is to use an external RADIUS server for authentication.
>
> Only for bfacademy.de, right ?
>
> However, the RADIUS server doesn't store the realm identification as
> part of the username, so I can't send "[email protected]", I must
> only send "josh.nathan" to the RADIUS server as the username.
>
> Which one, PacketFence or the cloud based RADIUS server ?
>
> However, since this RADIUS server is cloud-based, it will only accept
> proxying the entire EAP conversation, and rejects he authentication request
> if I don't let the inner-tunnel do the EAP as well.
>
> You need to proxy the entire radius request based on the realm.
>
> What you can do apply this PR (
> https://github.com/inverse-inc/packetfence/pull/3278).
>
> cd /usr/local/pf
> curl https://github.com/inverse-inc/packetfence/pull/3278.diff | patch
> -p1 --dry-run
>
> If no conflicts
>
> curl https://github.com/inverse-inc/packetfence/pull/3278.diff | patch -p1
>
> mv conf/radiusd/proxy.conf.inc.example conf/radiusd/proxy.conf.inc
>
> Restart PacketFence and add your cloud Radius configuration as a Radius
> authentication source.
>
> Next in the Realm configuration add your realm and associate it to your
> Radius authentication source.
>
> And restart radius on the PacketFence server.
>
> With that configuration all authentication for the realm bfacademy.de
> will be forwarded to the remote radius server and the other will be
> authenticate locally.
>
> Let me know if works and btw let me know if you have an issue with the
> code.
>
> Regards
> Fabrice
>
> The problem I ran into was that when stripping the domain from the
> username, it broke the EAP encryption, always resulting in authentication
> failure. If instead, the user withholds the domain information (ie. only
> enters "josh.nathan" into their device), this allows the EAP to maintain
> its integrity.
>
> This, of course, opened up other issues. PacketFence wouldn't proxy the
> connection if the realm wasn't set to match the Proxy realm ("bfacademy.de").
> In order to get PacketFence to do the proxy, I had to change where
> PacketFence defaults to the realm "LOCAL" to my desired proxy realm. And
> now I've run into the issue that if the realm is not set to "LOCAL", it's
> not trying the SQL database, but as it loops through, it keeps seeing the
> realm as what I set it to be ("bfacademy.de"), and then skips the local
> database.
>
> We'll be looking to upgrade to PacketFence 8.x in the relatively near
> future, but for now we're still on 6.4. Here's what our packetfence-tunnel
> config looks like:
>
> # -*- text -*-
> ######################################################################
> #
> # This is a virtual server that handles *only* inner tunnel
> # requests for EAP-TTLS and PEAP types.
> #
> # $Id: c250afa30a78fe9ff7a97b6c9b8a7c3a419a6946 $
> #
> ######################################################################
>
> server packetfence-tunnel {
>
>
> # Authorization. First preprocess (hints and huntgroups files),
> # then realms, and finally look in the "users" file.
> #
> # The order of the realm modules will determine the order that
> # we try to find a matching realm.
> #
> # Make *sure* that 'preprocess' comes before any realm if you
> # need to setup hints for the remote radius server
> authorize {
> #
> # Take a User-Name, and perform some checks on it, for spaces and
> other
> # invalid characters. If the User-Name appears invalid, reject
> the
> # request.
> #
> # See policy.d/filter for the definition of the filter_username
> policy.
> #
> filter_username
>
>
> #
> # If the users are logging in with an MS-CHAP-Challenge
> # attribute for authentication, the mschap module will find
> # the MS-CHAP-Challenge attribute, and add 'Auth-Type := MS-CHAP'
> # to the request, which will cause the server to then use
> # the mschap module for authentication.
> mschap
>
> #
> # If you are using multiple kinds of realms, you probably
> # want to set "ignore_null = yes" for all of them.
> # Otherwise, when the first style of realm doesn't match,
> # the other styles won't be checked.
> #
> # Note that proxying the inner tunnel authentication means
> # that the user MAY use one identity in the outer session
> # (e.g. "anonymous", and a different one here
> # (e.g. "[email protected]"). The inner session will then be
> # proxied elsewhere for authentication. If you are not
> # careful, this means that the user can cause you to forward
> # the authentication to another RADIUS server, and have the
> # accounting logs *not* sent to the other server. This makes
> # it difficult to bill people for their network activity.
> #
> suffix
> ntdomain
>
> %%multi_domain%%
> #
> # The "suffix" module takes care of stripping the domain
> # (e.g. "@example.com") from the User-Name attribute, and the
> # next few lines ensure that the request is not proxied.
> #
> # If you want the inner tunnel request to be proxied, delete
> # the next few lines.
> #
> update control {
> ### &Proxy-To-Realm := LOCAL
> &Proxy-To-Realm := "bfacademy.de"
> }
>
> #
> # This module takes care of EAP-MSCHAPv2 authentication.
> #
> # It also sets the EAP-Type attribute in the request
> # attribute list to the EAP type from the packet.
> #
> # The example below uses module failover to avoid querying all
> # of the following modules if the EAP module returns "ok".
> # Therefore, your LDAP and/or SQL servers will not be queried
> # for the many packets that go back and forth to set up TTLS
> # or PEAP. The load on those servers will therefore be reduced.
> #
> eap {
> ok = return
> }
>
> #
> # Read the 'users' file
> #files
>
> # Check if PacketFence local (SQL) authentication is enabled.
> # Run the packetfence-local-auth policy if it is.
> rewrite_called_station_id
>
> # Uncomment the following line to enable local PEAP authentication
> packetfence-local-auth
>
>
>
> #
> # The ldap module reads passwords from the LDAP database.
> #ldap
>
>
>
> #
> # If no other module has claimed responsibility for
> # authentication, then try to use PAP. This allows the
> # other modules listed above to add a "known good" password
> # to the request, and to do nothing else. The PAP module
> # will then see that password, and use it to do PAP
> # authentication.
> #
> # This module should be listed last, so that the other modules
> # get a chance to set Auth-Type for themselves.
> #
> pap
> }
>
>
> # Authentication.
> #
> #
> # This section lists which modules are available for authentication.
> # Note that it does NOT mean 'try each module in order'. It means
> # that a module from the 'authorize' section adds a configuration
> # attribute 'Auth-Type := FOO'. That authentication type is then
> # used to pick the appropriate module from the list below.
> #
>
> # In general, you SHOULD NOT set the Auth-Type attribute. The server
> # will figure it out on its own, and will do the right thing. The
> # most common side effect of erroneously setting the Auth-Type
> # attribute is that one authentication method will work, but the
> # others will not.
> #
> # The common reasons to set the Auth-Type attribute by hand
> # is to either forcibly reject the user, or forcibly accept him.
> #
> authenticate {
> #
> # PAP authentication, when a back-end database listed
> # in the 'authorize' section supplies a password. The
> # password can be clear-text, or encrypted.
> Auth-Type PAP {
> pap
> }
>
> #
> # Most people want CHAP authentication
> # A back-end database listed in the 'authorize' section
> # MUST supply a CLEAR TEXT password. Encrypted passwords
> # won't work.
> Auth-Type CHAP {
> chap
> }
>
> #
> # MSCHAP authentication
> Auth-Type MS-CHAP {
> packetfence # increment the StatsD counter
> if(PacketFence-Domain) {
> chrooted_mschap
> }
> else {
> mschap
> }
> }
>
>
> # Uncomment it if you want to use ldap for authentication
> #
> # Note that this means "check plain-text password against
> # the ldap database", which means that EAP won't work,
> # as it does not supply a plain-text password.
> #
> # We do NOT recommend using this. LDAP servers are databases.
> # They are NOT authentication servers. FreeRADIUS is an
> # authentication server, and knows what to do with authentication.
> # LDAP servers do not.
> #
> # Auth-Type LDAP {
> # ldap
> # }
>
> #
> # Allow EAP authentication.
> eap
> }
>
> ######################################################################
> #
> # There are no accounting requests inside of EAP-TTLS or PEAP
> # tunnels.
> #
> ######################################################################
>
>
> # Session database, used for checking Simultaneous-Use. Either the radutmp
> # or rlm_sql module can handle this.
> # The rlm_sql module is *much* faster
> session {
> radutmp
>
> #
> # See "Simultaneous Use Checking Queries" in sql.conf
> # sql
> }
>
>
> # Post-Authentication
> # Once we KNOW that the user has been authenticated, there are
> # additional steps we can take.
> #
> # Note that the last packet of the inner-tunnel authentication
> # MAY NOT BE the last packet of the outer session. So updating
> # the outer reply MIGHT work, and sometimes MIGHT NOT. The
> # exact functionality depends on both the inner and outer
> # authentication methods.
> #
> # If you need to send a reply attribute in the outer session,
> # the ONLY safe way is to set "use_tunneled_reply = yes", and
> # then update the inner-tunnel reply.
> post-auth {
> #
> rest
> if (updated || ok || noop) {
> request-timing
> -sql
> } else {
> request-timing
> -sql_reject
> }
>
> #
> # Un-comment the following if you have set
> # 'edir_account_policy_check = yes' in the ldap module
> sub-section of
> # the 'modules' section.
> #
> #ldap
>
>
>
> #
> # These attributes are for the inner session only.
> # They MUST NOT be sent in the outer reply.
> #
> # If you uncomment the previous block and leave
> # this one commented out, WiFi WILL NOT WORK,
> # because the client will get two MS-MPPE-keys
> #
> update outer.session-state {
> &MS-MPPE-Encryption-Policy !* ANY
> &MS-MPPE-Encryption-Types !* ANY
> &MS-MPPE-Send-Key !* ANY
> &MS-MPPE-Recv-Key !* ANY
> &Message-Authenticator !* ANY
> &EAP-Message !* ANY
> &Proxy-State !* ANY
> }
>
> #
> # Access-Reject packets are sent through the REJECT sub-section
> of the
> # post-auth section.
> #
> # Add the ldap module name (or instance) if you have set
> # 'edir_account_policy_check = yes' in the ldap module
> configuration
> #
> Post-Auth-Type REJECT {
> request-timing
> # log failed authentications in SQL, too.
> -sql_reject
> attr_filter.access_reject
>
> #
> # Let the outer session know which module failed, and why.
> #
> update outer.session-state {
> &Module-Failure-Message :=
> &request:Module-Failure-Message
> }
> }
> }
>
> #
> # When the server decides to proxy a request to a home server,
> # the proxied request is first passed through the pre-proxy
> # stage. This stage can re-write the request, or decide to
> # cancel the proxy.
> #
> # Only a few modules currently have this method.
> #
> pre-proxy {
> # Uncomment the following line if you want to change attributes
> # as defined in the preproxy_users file.
> # files
>
> # Uncomment the following line if you want to filter requests
> # sent to remote servers based on the rules defined in the
> # 'attrs.pre-proxy' file.
> # attr_filter.pre-proxy
>
> # If you want to have a log of packets proxied to a home
> # server, un-comment the following line, and the
> # 'detail pre_proxy_log' section, above.
> # pre_proxy_log
> }
>
> #
> # When the server receives a reply to a request it proxied
> # to a home server, the request may be massaged here, in the
> # post-proxy stage.
> #
> post-proxy {
>
> # If you want to have a log of replies from a home server,
> # un-comment the following line, and the 'detail post_proxy_log'
> # section, above.
> # post_proxy_log
>
> # Uncomment the following line if you want to filter replies from
> # remote proxies based on the rules defined in the 'attrs' file.
> # attr_filter.post-proxy
>
> #
> # If you are proxying LEAP, you MUST configure the EAP
> # module, and you MUST list it here, in the post-proxy
> # stage.
> #
> # You MUST also use the 'nostrip' option in the 'realm'
> # configuration. Otherwise, the User-Name attribute
> # in the proxied request will not match the user name
> # hidden inside of the EAP packet, and the end server will
> # reject the EAP request.
> #
> eap
> }
>
> } # inner-tunnel server block
>
>
> Joshua Nathan
> *IT Supervisor*
> Black Forest Academy
>
> p: +49 (0) 7626 9161 630 m: +49 (0) 152 3452 0056
> a:
> w: Hammersteiner Straße 50, 79400 Kandern
> bfacademy.de
>
>
>
>
>
> On Wed, Jun 13, 2018 at 4:56 PM Fabrice Durand via PacketFence-users <
> [email protected]> wrote:
>
>> Hello Joshua,
>>
>> i don't know your setup but what exactly are you trying to do ?
>>
>> Based on the realm you want to forward to another radius server ?
>>
>> Did you enabled packetfence-local-auth in Freeradius ? (
>> https://packetfence.org/doc/PacketFence_Installation_Guide.html#_eap_guest_authentication_on_email_sponsor_and_sms_registration
>> )
>>
>>
>> Regards
>>
>> Fabrice
>>
>>
>>
>> Le 2018-06-13 à 09:03, Josh Nathan via PacketFence-users a écrit :
>>
>> Hello,
>>
>> So, I'm running into trouble with 802.1X authentication...
>>
>> When users include the domain name when authentication, EAP breaks with
>> the strip username command. If they don't include the domain name, the
>> only way I've found to get PacketFence to perform the proxy is by forcing
>> the domain (inserting "&Proxy-To-Realm := "bfacademy.de" into the
>> authorize section packetfence-tunnel). However, if I force the domain,
>> then it doesn't seem to search the local SQL database in the event that
>> we've created a guest account. Is there a documented way to do both? We
>> do need the 802.1X proxied to another RADIUS server.
>>
>> Thanks,
>>
>> Joshua Nathan
>> *IT Supervisor*
>> Black Forest Academy
>>
>> p: +49 (0) 7626 9161 630 m: +49 (0) 152 3452 0056
>> a:
>> w: Hammersteiner Straße 50, 79400 Kandern
>> bfacademy.de
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>
>>
>>
>> _______________________________________________
>> PacketFence-users mailing
>> [email protected]https://lists.sourceforge.net/lists/listinfo/packetfence-users
>>
>>
>> --
>> Fabrice [email protected] :: +1.514.447.4918 (x135) ::
>> www.inverse.ca
>> Inverse inc. :: Leaders behind SOGo (http://www.sogo.nu) and PacketFence
>> (http://packetfence.org)
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> PacketFence-users mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/packetfence-users
>>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
>
> _______________________________________________
> PacketFence-users mailing
> [email protected]https://lists.sourceforge.net/lists/listinfo/packetfence-users
>
>
> --
> Fabrice [email protected] :: +1.514.447.4918 (x135) :: www.inverse.ca
> Inverse inc. :: Leaders behind SOGo (http://www.sogo.nu) and PacketFence
> (http://packetfence.org)
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> PacketFence-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/packetfence-users
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
PacketFence-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/packetfence-users
