Authorized MAC users stopped authenticating
Alan Buxey
alan.buxey at gmail.com
Thu Jan 4 21:47:16 CET 2018
Just remove all the other EAP types (or comment them out). It's all quite
clear and documented in the module config file.
You don't accept the user , you never just 'accept' an EAP client, EAP-TLS
clients get authenticated by having a client cert that can be validated by
the server (through the certificate pair)
alan
On 4 Jan 2018 7:51 pm, "R.Geller" <rg1 at robertgeller.net> wrote:
> >
> >
> >
> > If you want to enforce client cert then EAP-TLS is your only widely
> viable
> > option. Disable other EAP methods.
> >
>
> > Configure EAP-TLS, and disable all other EAP types.
>
> How/Where would I do that?
>
> Also, from what I gathered in the readme for the client cert, the
> commonName field is the User-Name that will be used for logins... If the
> cert is used for authentication, do I just need an entry for the user with
> Auth-Type := Accept. I'm not sure what the users entry should look like
> for EAP-TLS
>
> Thanks..
>
> -Rob
>
>
>
>
> > On 4 Jan 2018 5:07 am, "R.Geller" <rg1 at robertgeller.net> wrote:
> >
> > > Hi Alan,
> > >
> > > I blew away all my configs, and running vanilla 3.0.13 from yum
> > install. I
> > > am using out-of-the-box configs, and created users and clients file. I
> > > created certificate files, and I also tested with eapol_test
> > >
> > >
> > > I can authenticate with windows 10 client with no issues at this point.
> > I
> > > created certificates based on README instructions with new install, and
> > > verified that I can connect with eap_test using ttls-eap-mschapv2 and
> > > others (ttls-pap)...
> > >
> > > At this point, I would like to lock down the authentication so that
> > either
> > > the client cert is required, or authorized MAC. I did configure the
> > > authorized mac previously which was working, but stopped working, and I
> > > think the reason it stopped working prior had nothing to do with the
> MAC
> > > configs, but because the CA/CERTs I created expired. They are not
> > expired
> > > now since I created them with a new EXPIRE date, but what is happening
> is
> > > that the clients/supplicant I am testing with can authenticate without
> > the
> > > root/client certs installed. I would rather authenticate with
> > > certificates, and not rely on authorized MACs at this point...
> > >
> > > Can you point me in the direction of how to configure the radius server
> > to
> > > only authenticate if the client certificate is installed?
> > >
> > > Thanks I'm advance...
> > >
> > > -Rob
> > >
> > >
> > >
> > >
> > > >
> > > > I'm Running 3.0.13 for a while now. I set it up to support cert
> > > > authentication, as well as authorized MACs. I didn't deploy any
> > clients
> > > > using certs, only set up with user/pass and authorized MACs.
> > >
> > > It may be good then to disable EAP. Especially if you're not using
> it.
> > >
> > > > Sometime last week, users couldn't authenticate. I see errors in
> debug
> > > > stated there are 2 auth types, I can see the MAC auth is working, but
> > > users
> > > > are failing to authenticate because of EAP failure. At this point, I
> > > want
> > > > to be able to use both MAC / user+pass auth, and if in the future we
> > > decide
> > > > to deploy certs, than allow that too. If we need to disable EAP or
> > certs
> > > > to get this working, that is an option too. Not sure why it stopped
> > > > working out of the blue. The radius server hasn't been touched since
> > the
> > > > initial working config.
> > >
> > > If the RADIUS server did't change, then something else did.
> > >
> > > > Any ideas?
> > > >
> > > >
> > > > (0) Received Access-Request Id 168 from 10.2.1.53:41523 to
> > > 10.2.2.35:1812
> > > > length 218
> > > > (0) User-Name = "rbadani"
> > > > (0) NAS-Identifier = "pakedge"
> > > > (0) Called-Station-Id = "90-A7-C1-B8-AC-F3:APT-CORP"
> > > > (0) NAS-Port-Type = Wireless-802.11
> > > > (0) Service-Type = Framed-User
> > > > (0) NAS-Port = 0
> > > > (0) Calling-Station-Id = "34-F3-9A-86-59-57"
> > > > (0) Connect-Info = "CONNECT 0Mbps 802.11b"
> > > > (0) Acct-Session-Id = "196EB9DAB87DC1A9"
> > > > (0) Acct-Multi-Session-Id = "A7617A3B4E8A4349"
> > > > (0) WLAN-Pairwise-Cipher = 1027076
> > > > (0) WLAN-Group-Cipher = 1027076
> > > > (0) WLAN-AKM-Suite = 1027073
> > > > (0) Framed-MTU = 1400
> > > > (0) EAP-Message = 0x02e1000c0172626164616e69
> > >
> > > Is this user supposed to be doing EAP? If so, fix your configuration
> > to
> > > allow EAP and MAC auth.
> > >
> > > If not... talk to the user and ask him what he thinks he's doing.
> > >
> > >
> > > > (0) authorized_macs: users: Matched entry 34-F3-9A-86-59-57 at line 8
> > > > (0) [authorized_macs] = ok
> > > > (0) if (!ok) {
> > > > (0) if (!ok) -> FALSE
> > > > (0) else {
> > > > (0) update control {
> > > > (0) Auth-Type := Accept
> > >
> > > You can't do this for EAP.
> > >
> > > Your "allow MAC auth" rule has to check for EAP, too. i.e. do:
> > >
> > > authorized_macs
> > > if (!ok) {
> > > reject # reject unauth MACs, even if they do EAP
> > > }
> > >
> > > if (!EAP-Message) {
> > > update control {
> > > Auth-Type := Accept
> > > }
> > > }
> > >
> > > > (0) Found Auth-Type = Accept
> > > > (0) Found Auth-Type = eap
> > > > (0) ERROR: Warning: Found 2 auth-types on request for user 'rbadani'
> > >
> > > Exactly. The default configuration doesn't have this error. So it's
> > > something you added locally.
> > >
> > > > (2) eap: Peer sent packet with method EAP PEAP (25)
> > >
> > > Is the user supposed to be doing PEAP?
> > >
> > > Alan DeKok.
> > > -
> > > List info/subscribe/unsubscribe? See http://www.freeradius.org/
> > > list/users.html
> >
> >
> > ------------------------------
> >
> > Message: 2
> > Date: Thu, 4 Jan 2018 12:47:42 +0100
> > From: Bassem Mettichi <mettichi at gmail.com>
> > To: FreeRadius users mailing list
> > <freeradius-users at lists.freeradius.org>
> > Subject: Accounting Reject reponse
> > Message-ID:
> > <CADpsxzF5Gji+3cg_KTXg9sCVBvtp+YEEhqwoV3QM-
> > iyyWbXeDw at mail.gmail.com>
> > Content-Type: text/plain; charset="UTF-8"
> >
> > Hello,
> >
> > please could and one help me when freeradius reject an accounting
> request (
> > Start, Stop, Interim-Update) how to send Response Accounting Reject
> Message
> > to client Side because default configuration freeradius dosen't send
> > response to Client Side:
> >
> > } # accounting = reject
> > (2) Not sending reply to client.
> > (2) Finished request
> >
> > Thanks in advance
> >
> > Best Regards
> > Mettichi Bassem
> >
> >
> > ------------------------------
> >
> > Message: 3
> > Date: Fri, 5 Jan 2018 01:03:25 +1300
> > From: Nathan Ward <lists+freeradius at daork.net>
> > To: FreeRadius users mailing list
> > <freeradius-users at lists.freeradius.org>
> > Subject: Re: Accounting Reject reponse
> > Message-ID: <71E420E1-1C21-451C-BA9A-A0F2EF3AF06C at daork.net>
> > Content-Type: text/plain; charset=utf-8
> >
> >
> > > On 5/01/2018, at 12:47 AM, Bassem Mettichi <mettichi at gmail.com> wrote:
> > >
> > > Hello,
> > >
> > > please could and one help me when freeradius reject an accounting
> > request (
> > > Start, Stop, Interim-Update) how to send Response Accounting Reject
> > Message
> > > to client Side because default configuration freeradius dosen't send
> > > response to Client Side:
> > >
> > > } # accounting = reject
> > > (2) Not sending reply to client.
> > > (2) Finished request
> >
> > You have included a very small snippet of your debug output - please
> > provide the whole thing, not just the parts you think are important.
> >
> > What message would you like FreeRADIUS to send in this instance? You talk
> > about "Response Accounting Reject Message” but there is no such message.
> > RADIUS accounting uses only Accounting-Request and Accounting-Response.
> If
> > there is no response, the NAS will do whatever you configure it to do -
> > i.e. fail over to another RADIUS server, or disconnect the user, or
> > something else entirely. If you wish for some sort of hard reject to take
> > place, you should look towards generating a CoA to disconnect the user
> (or
> > whatever you need to do).
> >
> > --
> > Nathan Ward
> >
> >
> >
> >
> > ------------------------------
> >
> > Message: 4
> > Date: Thu, 4 Jan 2018 08:09:51 -0500
> > From: Alan DeKok <aland at deployingradius.com>
> > To: FreeRadius users mailing list
> > <freeradius-users at lists.freeradius.org>
> > Subject: Re: Authorized MAC users stopped authenticating
> > Message-ID: <C04BB960-15A4-4B14-93DA-2806D486D82E at deployingradius.com>
> > Content-Type: text/plain; charset=us-ascii
> >
> > On Jan 4, 2018, at 12:06 AM, R.Geller <rg1 at robertgeller.net> wrote:
> > > I blew away all my configs, and running vanilla 3.0.13 from yum
> > install. I
> > > am using out-of-the-box configs, and created users and clients file. I
> > > created certificate files, and I also tested with eapol_test
> >
> > That's good.
> >
> > > I can authenticate with windows 10 client with no issues at this point.
> > I
> > > created certificates based on README instructions with new install, and
> > > verified that I can connect with eap_test using ttls-eap-mschapv2 and
> > > others (ttls-pap)...
> >
> > That's good/
> >
> > > At this point, I would like to lock down the authentication so that
> > either
> > > the client cert is required, or authorized MAC. I did configure the
> > > authorized mac previously which was working, but stopped working, and I
> > > think the reason it stopped working prior had nothing to do with the
> MAC
> > > configs, but because the CA/CERTs I created expired.
> >
> > Don't guess. Figure out the problem.
> >
> > > They are not expired
> > > now since I created them with a new EXPIRE date, but what is happening
> is
> > > that the clients/supplicant I am testing with can authenticate without
> > the
> > > root/client certs installed.
> >
> > Only if you configure the clients to do that.
> >
> > > I would rather authenticate with
> > > certificates, and not rely on authorized MACs at this point...
> > >
> > > Can you point me in the direction of how to configure the radius server
> > to
> > > only authenticate if the client certificate is installed?
> >
> > Configure EAP-TLS, and disable all other EAP types.
> >
> > And be *methodical* about changes to the config. Make a change. Test
> > it. Make a backup of the config.
> >
> > One of the top 3 reasons why people screw up their config is by making
> > random changes without testing them, or without understanding what the
> > changes do. And, it wastes enormous amounts of time.
> >
> > Alan DeKok.
> >
> >
> >
> >
> > ------------------------------
> >
> > Message: 5
> > Date: Thu, 4 Jan 2018 19:12:22 +0000 (UTC)
> > From: chuck beck <cpsonl at yahoo.com>
> > To: "freeradius-users at lists.freeradius.org"
> > <freeradius-users at lists.freeradius.org>
> > Subject: new install needs detail logging
> > Message-ID: <1394662287.492089.1515093142151 at mail.yahoo.com>
> > Content-Type: text/plain; charset=UTF-8
> >
> > Hello list, I am new to administering free radius. I have completed the
> > install of freeradius version 3.013 on 3.10.0-693.11.1.el7.x86_64. It is
> > working and authenticating a test user. I see the authentication messages
> > in the main log:
> > Thu Jan 4 10:09:05 2018 : Warning: [/etc/raddb/mods-config/attr_
> filter/access_reject]:11
> > Check item "FreeRADIUS-Response-Delay-USec" found in fi
> > lter list for realm "DEFAULT".
> > Thu Jan 4 10:09:05 2018 : Info: Loaded virtual server <default>
> > Thu Jan 4 10:09:05 2018 : Warning: Ignoring "sql" (see
> > raddb/mods-available/README.rst)
> > Thu Jan 4 10:09:05 2018 : Warning: Ignoring "ldap" (see
> > raddb/mods-available/README.rst)
> > Thu Jan 4 10:09:05 2018 : Info: Loaded virtual server default
> > Thu Jan 4 10:09:05 2018 : Info: # Skipping contents of 'if' as it is
> > always 'false' -- /etc/raddb/sites-enabled/inner-tunnel:330
> > Thu Jan 4 10:09:05 2018 : Info: Loaded virtual server inner-tunnel
> > Thu Jan 4 10:09:05 2018 : Info: Ready to process requests
> > Thu Jan 4 10:09:41 2018 : Auth: (0) Login incorrect (pap: MD5 digest
> does
> > not match "known good" digest): [chuck] (from client Geneva port 0
> > cli 10.xx.2x.4)
> > Thu Jan 4 10:09:49 2018 : Auth: (1) Login OK: [chuck] (from client
> Geneva
> > port 0 cli 10.xx.2x.4)
> > Thu Jan 4 10:11:53 2018 : Auth: (2) Login OK: [chuck] (from client
> Geneva
> > port 0 cli 10.xx.2x.4)
> > Thu Jan 4 10:12:07 2018 : Auth: (3) Login OK: [chuck] (from client
> Geneva
> > port 0 cli 10.xx.2x.4)
> > Thu Jan 4 10:12:47 2018 : Info: Signalled to terminate
> > Thu Jan 4 10:12:47 2018 : Info: Exiting normally
> > I modified very little so far on the configuration. The last thing I
> tried
> > is modifying:
> > -
> > >From the authorize section in /etc/raddb/sites-enabled/default file:
> > #
> > # If you want to have a log of authentication requests,
> > # un-comment the following line, and the 'detail auth_log'
> > # section, above.
> > # auth_log
> >
> > -
> > >From the post-auth section in /etc/raddb/sites-enabled/default file:
> > #
> > # If you want to have a log of authentication replies,
> > # un-comment the following line, and the 'detail reply_log'
> > # section, above.
> > # reply_log
> >
> > and restarting. Still no logs created in:
> > - chuck at njs-radius-01 raddb]$ sudo -u radiusd ls -lr /var/log/radius
> > total 16
> > drwxr-xr-x 2 radiusd radiusd 6 Jan 3 10:12 radwtmp
> > drwxr-xr-x 2 radiusd radiusd 6 Jan 3 10:12 radutmp
> > -rw-r----- 1 radiusd radiusd 561 Dec 29 13:44 radius.log-20180101.gz
> > -rw-r----- 1 radiusd radiusd 9895 Jan 4 10:14 radius.log
> > drwx------ 3 radiusd radiusd 26 Jan 4 10:09 radacct
> > [chuck at njs-radius-01 raddb]
> > directories are empty.
> > I don't see anything relevant in the debug output when I run with -X so I
> > did not post that here. I can if it would help. Pretty sure I'm missing
> > something simple, any ideas?thanks !-Chuck
> >
> >
> > ------------------------------
> >
> > Message: 6
> > Date: Thu, 4 Jan 2018 14:19:57 -0500
> > From: Alan DeKok <aland at deployingradius.com>
> > To: chuck beck <cpsonl at yahoo.com>, FreeRadius users mailing list
> > <freeradius-users at lists.freeradius.org>
> > Subject: Re: new install needs detail logging
> > Message-ID: <1F1587DB-9630-4954-ADB6-A9724135F90A at deployingradius.com>
> > Content-Type: text/plain; charset=us-ascii
> >
> > On Jan 4, 2018, at 2:12 PM, chuck beck via Freeradius-Users <
> > freeradius-users at lists.freeradius.org> wrote:
> > >
> > > Hello list, I am new to administering free radius. I have completed the
> > install of freeradius version 3.013 on 3.10.0-693.11.1.el7.x86_64. It is
> > working and authenticating a test user. I see the authentication messages
> > in the main log:
> >
> > It's best to read the *debug output* as suggested in all of the
> > documentation. That tells you what's going on.
> >
> > > I modified very little so far on the configuration. The last thing I
> > tried is modifying:
> >
> > What did you modify there? Did you uncomment those entries?
> >
> > > I don't see anything relevant in the debug output when I run with -X so
> > I did not post that here.
> >
> > If you don't know what you're looking for, you won't think that
> anything
> > is relevant.
> >
> > > I can if it would help. Pretty sure I'm missing something simple, any
> > ideas?thanks !-Chuck
> >
> > If you want us to help you, post the debug log.
> >
> > Alan DEKok.
> >
> >
> >
> >
> > ------------------------------
> >
> > Subject: Digest Footer
> >
> > -
> > List info/subscribe/unsubscribe? See http://www.freeradius.org/
> > list/users.html
> >
> > ------------------------------
> >
> > End of Freeradius-Users Digest, Vol 153, Issue 9
> > ************************************************
> >
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/
> list/users.html
More information about the Freeradius-Users
mailing list