Re: MAC auth bypass with freeradius/openldap
On Wed, Jun 22, 2011 at 08:23:09AM -0700, g17jimmy wrote: I guess I was too quick to call it, and it looks like the problem is still on the NAS. You will see that the client first gets access using the MAC address as the CSID, but at some point, the client or NAS decieded to re-auth but this time using the IP address that the client had acquired. It's doesn't look like it's associated with the reauthentication period as that is set to 1 hour and the issue occurred within about 10 minutes. I'm pretty sure this has nothing to do with radius and everything to do with my switch config, so sorry if this post is inappropriate. These are accounting packets, not authentication packets. They're basically status messages from the NAS to the radius server telling you the session is "alive". Presumably it's snooping ARP or DHCP which is why it changes to using IP. If you don't need accounting you can just ignore this. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: MAC auth bypass with freeradius/openldap
I don't know why it wasn't working when I posted that last one, I had a message that the port was not authenticated on the client, but the log I posted clearly shows that it matched on the username of the switch since there is an ldap user called admin and the switch admin user is also admin. Admittedly this is not great security, but this is not going to be the case for long. -- View this message in context: http://freeradius.1045715.n5.nabble.com/MAC-auth-bypass-with-freeradius-openldap-tp4511949p451.html Sent from the FreeRadius - User mailing list archive at Nabble.com. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: MAC auth bypass with freeradius/openldap
I guess I was too quick to call it, and it looks like the problem is still on
the NAS. You will see that the client first gets access using the MAC
address as the CSID, but at some point, the client or NAS decieded to
re-auth but this time using the IP address that the client had acquired.
It's doesn't look like it's associated with the reauthentication period as
that is set to 1 hour and the issue occurred within about 10 minutes. I'm
pretty sure this has nothing to do with radius and everything to do with my
switch config, so sorry if this post is inappropriate.
rad_recv: Accounting-Request packet from host 192.168.1.254 port 49154,
id=0, length=112
User-Name = "0010182b9065"
NAS-IP-Address = 192.168.1.254
NAS-Port = 24
Called-Station-Id = "00-1A-70-8B-2B-8C"
Calling-Station-Id = "00-10-18-2B-90-65"
Acct-Status-Type = Start
Acct-Session-Id = "052D"
Acct-Authentic = Local
NAS-Port-Type = Ethernet
+- entering group preacct {...}
++[preprocess] returns ok
[acct_unique] Hashing 'NAS-Port = 24,Client-IP-Address =
192.168.1.254,NAS-IP-Address = 192.168.1.254,Acct-Session-Id =
"052D",User-Name = "0010182b9065"'
[acct_unique] Acct-Unique-Session-ID = "42587646b94a35b4".
++[acct_unique] returns ok
[suffix] No '@' in User-Name = "0010182b9065", looking up realm NULL
[suffix] No such realm "NULL"
++[suffix] returns noop
++[files] returns noop
+- entering group accounting {...}
[detail]expand:
/var/log/radius/radacct/%{Client-IP-Address}/detail-%Y%m%d ->
/var/log/radius/radacct/192.168.1.254/detail-20110622
[detail] /var/log/radius/radacct/%{Client-IP-Address}/detail-%Y%m%d expands
to /var/log/radius/radacct/192.168.1.254/detail-20110622
[detail]expand: %t -> Wed Jun 22 09:15:40 2011
++[detail] returns ok
++[unix] returns ok
[radutmp] expand: /var/log/radius/radutmp -> /var/log/radius/radutmp
[radutmp] expand: %{User-Name} -> 0010182b9065
++[radutmp] returns ok
[attr_filter.accounting_response] expand: %{User-Name} -> 0010182b9065
attr_filter: Matched entry DEFAULT at line 12
++[attr_filter.accounting_response] returns updated
Sending Accounting-Response of id 0 to 192.168.1.254 port 49154
Finished request 7.
Cleaning up request 7 ID 0 with timestamp +60184
Going to the next request
Ready to process requests.
rad_recv: Accounting-Request packet from host 192.168.1.254 port 49154,
id=0, length=97
User-Name = "admin"
NAS-IP-Address = 192.168.1.254
Called-Station-Id = "192.168.1.254"
Calling-Station-Id = "192.168.1.118"
Acct-Status-Type = Stop
Acct-Session-Id = "052C"
Acct-Authentic = Local
Acct-Session-Time = 1280
Acct-Terminate-Cause = Idle-Timeout
+- entering group preacct {...}
++[preprocess] returns ok
[acct_unique] WARNING: Attribute NAS-Port was not found in request, unique
ID MAY be inconsistent
[acct_unique] Hashing ',Client-IP-Address = 192.168.1.254,NAS-IP-Address =
192.168.1.254,Acct-Session-Id = "052C",User-Name = "admin"'
[acct_unique] Acct-Unique-Session-ID = "0f743b391350fbbb".
++[acct_unique] returns ok
[suffix] No '@' in User-Name = "admin", looking up realm NULL
[suffix] No such realm "NULL"
++[suffix] returns noop
++[files] returns noop
+- entering group accounting {...}
[detail]expand:
/var/log/radius/radacct/%{Client-IP-Address}/detail-%Y%m%d ->
/var/log/radius/radacct/192.168.1.254/detail-20110622
[detail] /var/log/radius/radacct/%{Client-IP-Address}/detail-%Y%m%d expands
to /var/log/radius/radacct/192.168.1.254/detail-20110622
[detail]expand: %t -> Wed Jun 22 09:25:47 2011
++[detail] returns ok
++[unix] returns noop
[radutmp] expand: /var/log/radius/radutmp -> /var/log/radius/radutmp
[radutmp] expand: %{User-Name} -> admin
rlm_radutmp: No NAS-Port seen. Cannot do anything.
rlm_radumtp: WARNING: checkrad will probably not work!
++[radutmp] returns noop
[attr_filter.accounting_response] expand: %{User-Name} -> admin
attr_filter: Matched entry DEFAULT at line 12
++[attr_filter.accounting_response] returns updated
Sending Accounting-Response of id 0 to 192.168.1.254 port 49154
Finished request 8.
Cleaning up request 8 ID 0 with timestamp +60791
Going to the next request
Ready to process requests.
--
View this message in context:
http://freeradius.1045715.n5.nabble.com/MAC-auth-bypass-with-freeradius-openldap-tp4511949p4514401.html
Sent from the FreeRadius - User mailing list archive at Nabble.com.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: MAC auth bypass with freeradius/openldap
The NAS is a Linksys/Cisco SFE2000 switch. There is very little flexibility in how to configure the switch and the documents do not detail how to configure it for 802.1x or mac bypass, other than to say it can do it. The client is a windows system being plugged into a port on the switch. I will say that your reply helped, fixed the problem. The switch manual had no detail on configuration for making it work and I had made the config I thought needed to be made and had one thing out of place. I set the 802.1x authentication method to 'radius'. I changed that to 'none' and it's working. -- View this message in context: http://freeradius.1045715.n5.nabble.com/MAC-auth-bypass-with-freeradius-openldap-tp4511949p4514243.html Sent from the FreeRadius - User mailing list archive at Nabble.com. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: MAC auth bypass with freeradius/openldap
On 06/21/2011 09:53 PM, g17jimmy wrote:
I've been looking at this for a day now and it seems like I'm close, but
something is not right. I have a freeradius server with an openldap backend
for MAC auth bypass. This system is just for test, but it is an essential
first step in my project.
The debug you sent is not mac-auth bypass. It's 802.1x/EAP, and it's
failing for a bunch of reasons.
Firstly, if you want to do mac-auth, you must configure mac-auth on the
switch. 802.1x is not mac-auth.
rad_recv: Access-Request packet from host 192.168.1.254 port 49154, id=0,
length=99
NAS-IP-Address = 192.168.1.254
NAS-Port-Type = Ethernet
NAS-Port = 24
User-Name = "0010182b9065"
Acct-Session-Id = "052B"
EAP-Message = 0x021101303031303138326239303635
Message-Authenticator = 0x57f15349b978ec4c8dcdda92f6cc6fed
The EAP-Message indicates this is EAP/802.1x
+- entering group authorize {...}
++[preprocess] returns ok
[ldap] looking for check items in directory...
[ldap] looking for reply items in directory...
WARNING: No "known good" password was found in LDAP. Are you sure that the
user is configured correctly?
EAP needs known-good passwords...
[ldap] user 0010182b9065 authorized to use remote access
rlm_ldap: ldap_release_conn: Release Id: 0
++[ldap] returns ok
++[expiration] returns noop
++[logintime] returns noop
[pap] WARNING! No "known good" password found for the user. Authentication
may fail because of this.
...so it's going to fail. Anyway, but it doesn't get that far, because...
Now things get really broken:
++[pap] returns noop
Found Auth-Type = EAP
+- entering group authenticate {...}
[eap] EAP Identity
[eap] processing type tls
[tls] Initiate
[tls] Start returned 1
++[eap] returns handled
Sending Access-Challenge of id 0 to 192.168.1.254 port 49154
EAP-Message = 0x010100061520
Message-Authenticator = 0x
State = 0xc26dceefc26cdb5c17fcb167e47515a3
Finished request 4.
This is FreeRADIUS saying, "OK, proceed, using EAP-TLS please"
Going to the next request
Waking up in 4.9 seconds.
rad_recv: Access-Request packet from host 192.168.1.254 port 49154, id=0,
length=134
Cleaning up request 4 ID 0 with timestamp +348
NAS-IP-Address = 192.168.1.254
NAS-Port-Type = Ethernet
NAS-Port = 24
User-Name = "0010182b9065"
Acct-Session-Id = "052B"
State = 0xc26dceefc26cdb5c17fcb167e47515a3
EAP-Message =
0x0201002204103007f2c1a22a920adc933106b4a62923303031303138326239303635
Message-Authenticator = 0xf9ba8e6f27790169ab8ee1b280fbb4e9
+- entering group authorize {...}
++[preprocess] returns ok
Found Auth-Type = EAP
+- entering group authenticate {...}
[eap] Request found, released from the list
[eap] Response appears to match, but EAP type is wrong.
This is just broken. FreeRADIUS said "use EAP-TLS" and your client
replied with "ok, using EAP-something-else".
What is the NAS and what is the client here?
Is the NAS trying to do mac-auth via some kind of EAP? That's just
crazy, and even if it wasn't, it's managed to break the EAP conversation
so it can't possibly work.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
