"[eap] = reject" after "Calling eap_md5 to process EAP data"
hi, I am trying to configure MAC auth by implementing EAP/MD5 as it is described here: http://wiki.freeradius.org/modules/Rlm_eap#My-Userbase-is-in-LDAP-and-I-want... FR v.3.0.8 is on FreeBSD 10.1R supplicant is on FreeBSD 10.1R connected (by wire) to FR wia switch but something is wrong and I can not understand what ... please help me to see what I do not see ... as backend I have LDAP and in it, userPassword format is Cleartext-Password (for the sample from the debug bellow it is `00-25-90-D9-76-2C' as I understand from the debug bellow, I successfully pass authorization but fail to authenticate against eap_md5 ... why? ---[ quotation start ]------------------------------------------- Mon Jul 6 20:27:36 2015 : Debug: (0) Received Access-Request Id 200 from 192.168.0.1:49205 to 192.168.0.254:1812 length 137 Mon Jul 6 20:27:36 2015 : Debug: (0) NAS-IP-Address = 192.168.0.1 Mon Jul 6 20:27:36 2015 : Debug: (0) NAS-Port-Type = Ethernet Mon Jul 6 20:27:36 2015 : Debug: (0) NAS-Port = 14 Mon Jul 6 20:27:36 2015 : Debug: (0) User-Name = '002590d9762c' Mon Jul 6 20:27:36 2015 : Debug: (0) Acct-Session-Id = '050002C0' Mon Jul 6 20:27:36 2015 : Debug: (0) Called-Station-Id = '5C-A4-8A-6F-33-C6' Mon Jul 6 20:27:36 2015 : Debug: (0) Calling-Station-Id = '00-25-90-D9-76-2C' Mon Jul 6 20:27:36 2015 : Debug: (0) EAP-Message = 0x0200001101303032353930643937363263 Mon Jul 6 20:27:36 2015 : Debug: (0) Message-Authenticator = 0xa54f71eb9a3b95ad330025032c88cedb Mon Jul 6 20:27:36 2015 : Debug: (0) session-state: No State attribute Mon Jul 6 20:27:36 2015 : Debug: (0) # Executing section authorize from file /usr/local/etc/raddb/sites-enabled/default Mon Jul 6 20:27:36 2015 : Debug: (0) authorize { Mon Jul 6 20:27:36 2015 : Debug: (0) modsingle[authorize]: calling preprocess (rlm_preprocess) for request 0 Mon Jul 6 20:27:36 2015 : Debug: (0) modsingle[authorize]: returned from preprocess (rlm_preprocess) for request 0 Mon Jul 6 20:27:36 2015 : Debug: (0) [preprocess] = ok Mon Jul 6 20:27:36 2015 : Debug: (0) policy rewrite_called_station_id { ... Mon Jul 6 20:27:36 2015 : Debug: (1) ldap: User object found at DN "uid=00-25-90-D9-76-2C,authorizedService=802.1x-mac@xyz,uid=jdoe,ou=People,dc=xyz" Mon Jul 6 20:27:36 2015 : Debug: (1) ldap: Processing user attributes Mon Jul 6 20:27:36 2015 : Debug: (1) ldap: control:Cleartext-Password += '00-25-90-D9-76-2C' Mon Jul 6 20:27:36 2015 : Debug: (1) ldap: control:Password-With-Header += '00-25-90-D9-76-2C' Mon Jul 6 20:27:36 2015 : Debug: (1) ldap: reply:Service-Type := Framed-User Mon Jul 6 20:27:36 2015 : Debug: (1) ldap: reply:Tunnel-Type := VLAN Mon Jul 6 20:27:36 2015 : Debug: (1) ldap: reply:Tunnel-Medium-Type := IEEE-802 Mon Jul 6 20:27:36 2015 : Debug: (1) ldap: reply:Tunnel-Private-Group-Id := 'VLAN3499' Mon Jul 6 20:27:36 2015 : Debug: (1) ldap: Attribute "radiusCheckAttributes" not found in LDAP object Mon Jul 6 20:27:36 2015 : Debug: (1) ldap: Attribute "radiusReplyAttributes" not found in LDAP object Mon Jul 6 20:27:36 2015 : Debug: rlm_ldap (ldap): Released connection (4) Mon Jul 6 20:27:36 2015 : Debug: (1) modsingle[authorize]: returned from ldap (rlm_ldap) for request 1 Mon Jul 6 20:27:36 2015 : Debug: (1) [ldap] = updated Mon Jul 6 20:27:36 2015 : Debug: (1) modsingle[authorize]: calling eap (rlm_eap) for request 1 Mon Jul 6 20:27:36 2015 : Debug: (1) eap: Peer sent code Response (2) ID 1 length 34 Mon Jul 6 20:27:36 2015 : Debug: (1) eap: No EAP Start, assuming it's an on-going EAP conversation Mon Jul 6 20:27:36 2015 : Debug: (1) modsingle[authorize]: returned from eap (rlm_eap) for request 1 Mon Jul 6 20:27:36 2015 : Debug: (1) [eap] = updated Mon Jul 6 20:27:36 2015 : Debug: (1) modsingle[authorize]: calling files (rlm_files) for request 1 Mon Jul 6 20:27:36 2015 : Debug: (1) files: Searching for user in group "disabled" ... Mon Jul 6 20:27:36 2015 : Debug: (1) files: User is not a member of "disabled" Mon Jul 6 20:27:36 2015 : Debug: (1) files: Searching for user in group "auth-mac" ... Mon Jul 6 20:27:36 2015 : Debug: (1) files: EXPAND (&(radiusGroupName=auth-mac)(|(&(cn=%{%{Stripped-User-Name}:-%{Calling-Station-Id}})(|(authorizedService=802.1x@xyz)(authorizedService=802.1x-mac@xyz)))(&(cn=%{User-Name})(authorizedService=802.1x-eap-tls@xyz)))(|(cn=%{Stripped-User-Name})(cn=%{User-Name})(cn=%{Calling-Station-Id})))-76-2C)(|(authorizedService=802.1x@xyz)(authorizedService=802.1x-mac@xyz)))(&(cn=002590d9762c)(authorizedService=802.1x-eap-tls@xyz)))(|(cn=)(cn=002590d9762c)(cn=00-25-90-D9-76-2C))) EXPAND TMPL LITERAL Mon Jul 6 20:27:36 2015 : Debug: (1) files: Performing search in "ou=People,dc=xyz" with filter "(&(radiusGroupName=auth-mac)(|(&(cn=00-25-90-D9-76-2C)(|(authorizedService=802.1x@xyz)(authorizedService=802.1x-mac@xyz)))(&(cn=002590d9762c)(authorizedService=802.1x-eap-tls@xyz)))(|(cn=)(cn=002590d9762c)(cn=00-25-90-D9-76-2C)))", scope "sub" Mon Jul 6 20:27:36 2015 : Debug: (1) files: User found in group object "ou=People,dc=xyz" Mon Jul 6 20:27:36 2015 : Debug: rlm_ldap (ldap): Released connection (4) Mon Jul 6 20:27:36 2015 : Debug: (1) files: users: Matched entry DEFAULT at line 238 Mon Jul 6 20:27:36 2015 : Debug: (1) files: ::: FROM 2 TO 4 MAX 6 Mon Jul 6 20:27:36 2015 : Debug: (1) files: ::: Examining Reply-Message Mon Jul 6 20:27:36 2015 : Debug: %{User-Name}, you are comming as MAC Auth object. Mon Jul 6 20:27:36 2015 : Debug: Parsed xlat tree: Mon Jul 6 20:27:36 2015 : Debug: attribute --> User-Name Mon Jul 6 20:27:36 2015 : Debug: literal --> , you are comming as MAC Auth object. Mon Jul 6 20:27:36 2015 : Debug: (1) files: EXPAND %{User-Name}, you are comming as MAC Auth object. Mon Jul 6 20:27:36 2015 : Debug: (1) files: --> 002590d9762c, you are comming as MAC Auth object. Mon Jul 6 20:27:36 2015 : Debug: (1) files: ::: APPENDING Reply-Message FROM 0 TO 4 Mon Jul 6 20:27:36 2015 : Debug: (1) files: ::: Examining Fall-Through Mon Jul 6 20:27:36 2015 : Debug: (1) files: ::: APPENDING Fall-Through FROM 1 TO 5 Mon Jul 6 20:27:36 2015 : Debug: (1) files: ::: TO in 4 out 6 Mon Jul 6 20:27:36 2015 : Debug: (1) files: ::: to[0] = Service-Type Mon Jul 6 20:27:36 2015 : Debug: (1) files: ::: to[1] = Tunnel-Type Mon Jul 6 20:27:36 2015 : Debug: (1) files: ::: to[2] = Tunnel-Medium-Type Mon Jul 6 20:27:36 2015 : Debug: (1) files: ::: to[3] = Tunnel-Private-Group-Id Mon Jul 6 20:27:36 2015 : Debug: (1) files: ::: to[4] = Reply-Message Mon Jul 6 20:27:36 2015 : Debug: (1) files: ::: to[5] = Fall-Through Mon Jul 6 20:27:36 2015 : Debug: (1) modsingle[authorize]: returned from files (rlm_files) for request 1 Mon Jul 6 20:27:36 2015 : Debug: (1) [files] = ok Mon Jul 6 20:27:36 2015 : Debug: (1) modsingle[authorize]: calling expiration (rlm_expiration) for request 1 Mon Jul 6 20:27:36 2015 : Debug: (1) modsingle[authorize]: returned from expiration (rlm_expiration) for request 1 Mon Jul 6 20:27:36 2015 : Debug: (1) [expiration] = noop Mon Jul 6 20:27:36 2015 : Debug: (1) modsingle[authorize]: calling logintime (rlm_logintime) for request 1 Mon Jul 6 20:27:36 2015 : Debug: (1) modsingle[authorize]: returned from logintime (rlm_logintime) for request 1 Mon Jul 6 20:27:36 2015 : Debug: (1) [logintime] = noop Mon Jul 6 20:27:36 2015 : Debug: (1) if (notfound){ Mon Jul 6 20:27:36 2015 : Debug: (1) if (notfound) -> FALSE Mon Jul 6 20:27:36 2015 : Debug: (1) if (reject){ Mon Jul 6 20:27:36 2015 : Debug: (1) if (reject) -> FALSE Mon Jul 6 20:27:36 2015 : Debug: (1) } # authorize = updated Mon Jul 6 20:27:36 2015 : Debug: (1) Found Auth-Type = EAP Mon Jul 6 20:27:36 2015 : Debug: (1) # Executing group from file /usr/local/etc/raddb/sites-enabled/default Mon Jul 6 20:27:36 2015 : Debug: (1) authenticate { Mon Jul 6 20:27:36 2015 : Debug: (1) modsingle[authenticate]: calling eap (rlm_eap) for request 1 Mon Jul 6 20:27:36 2015 : Debug: (1) eap: Expiring EAP session with state 0xeb89e5b7eb88e1eb Mon Jul 6 20:27:36 2015 : Debug: (1) eap: Finished EAP session with state 0xeb89e5b7eb88e1eb Mon Jul 6 20:27:36 2015 : Debug: (1) eap: Previous EAP request found for state 0xeb89e5b7eb88e1eb, released from the list Mon Jul 6 20:27:36 2015 : Debug: (1) eap: Peer sent method MD5 (4) Mon Jul 6 20:27:36 2015 : Debug: (1) eap: EAP MD5 (4) Mon Jul 6 20:27:36 2015 : Debug: (1) eap: Calling eap_md5 to process EAP data Mon Jul 6 20:27:36 2015 : Debug: (1) eap: Freeing handler Mon Jul 6 20:27:36 2015 : Debug: (1) modsingle[authenticate]: returned from eap (rlm_eap) for request 1 Mon Jul 6 20:27:36 2015 : Debug: (1) [eap] = reject Mon Jul 6 20:27:36 2015 : Debug: (1) } # authenticate = reject Mon Jul 6 20:27:36 2015 : Debug: (1) Failed to authenticate the user Mon Jul 6 20:27:36 2015 : Debug: (1) Using Post-Auth-Type Reject ... Mon Jul 6 20:27:36 2015 : Debug: (1) Post-Auth-Type REJECT { Mon Jul 6 20:27:36 2015 : Debug: (1) modsingle[post-auth]: calling attr_filter.access_reject (rlm_attr_filter) for request 1 Mon Jul 6 20:27:36 2015 : Debug: %{User-Name} Mon Jul 6 20:27:36 2015 : Debug: Parsed xlat tree: Mon Jul 6 20:27:36 2015 : Debug: attribute --> User-Name Mon Jul 6 20:27:36 2015 : Debug: (1) attr_filter.access_reject: EXPAND %{User-Name} Mon Jul 6 20:27:36 2015 : Debug: (1) attr_filter.access_reject: --> 002590d9762c Mon Jul 6 20:27:36 2015 : Debug: (1) attr_filter.access_reject: Matched entry DEFAULT at line 17 Mon Jul 6 20:27:36 2015 : Debug: (1) attr_filter.access_reject: Attribute "Service-Type" allowed by 0 rules, disallowed by 0 rules Mon Jul 6 20:27:36 2015 : Debug: (1) attr_filter.access_reject: Attribute "Tunnel-Type" allowed by 0 rules, disallowed by 0 rules Mon Jul 6 20:27:36 2015 : Debug: (1) attr_filter.access_reject: Attribute "Tunnel-Medium-Type" allowed by 0 rules, disallowed by 0 rules Mon Jul 6 20:27:36 2015 : Debug: (1) attr_filter.access_reject: Attribute "Tunnel-Private-Group-Id" allowed by 0 rules, disallowed by 0 rules Mon Jul 6 20:27:36 2015 : Debug: (1) attr_filter.access_reject: Reply-Message = '002590d9762c, you are comming as MAC Auth object.' allowed by Reply-Message =* '' Mon Jul 6 20:27:36 2015 : Debug: (1) attr_filter.access_reject: Attribute "Reply-Message" allowed by 1 rules, disallowed by 0 rules Mon Jul 6 20:27:36 2015 : Debug: (1) attr_filter.access_reject: EAP-Message = 0x04010004 allowed by EAP-Message =* 0x Mon Jul 6 20:27:36 2015 : Debug: (1) attr_filter.access_reject: Attribute "EAP-Message" allowed by 1 rules, disallowed by 0 rules Mon Jul 6 20:27:36 2015 : Debug: (1) attr_filter.access_reject: Message-Authenticator = 0x00000000000000000000000000000000 allowed by Message-Authenticator =* 0x Mon Jul 6 20:27:36 2015 : Debug: (1) attr_filter.access_reject: Attribute "Message-Authenticator" allowed by 1 rules, disallowed by 0 rules Mon Jul 6 20:27:36 2015 : Debug: (1) modsingle[post-auth]: returned from attr_filter.access_reject (rlm_attr_filter) for request 1 Mon Jul 6 20:27:36 2015 : Debug: (1) [attr_filter.access_reject] = updated Mon Jul 6 20:27:36 2015 : Debug: (1) modsingle[post-auth]: calling eap (rlm_eap) for request 1 Mon Jul 6 20:27:36 2015 : Debug: (1) modsingle[post-auth]: returned from eap (rlm_eap) for request 1 Mon Jul 6 20:27:36 2015 : Debug: (1) [eap] = noop Mon Jul 6 20:27:36 2015 : Debug: (1) policy remove_reply_message_if_eap { Mon Jul 6 20:27:36 2015 : Debug: (1) if (&reply:EAP-Message && &reply:Reply-Message) { Mon Jul 6 20:27:36 2015 : Debug: (1) if (&reply:EAP-Message && &reply:Reply-Message) -> TRUE Mon Jul 6 20:27:36 2015 : Debug: (1) if (&reply:EAP-Message && &reply:Reply-Message) { Mon Jul 6 20:27:36 2015 : Debug: (1) update reply { Mon Jul 6 20:27:36 2015 : Debug: (1) &Reply-Message !* ANY Mon Jul 6 20:27:36 2015 : Debug: (1) } # update reply = noop Mon Jul 6 20:27:36 2015 : Debug: (1) } # if (&reply:EAP-Message && &reply:Reply-Message) = noop Mon Jul 6 20:27:36 2015 : Debug: (1) ... skipping else for request 1: Preceding "if" was taken Mon Jul 6 20:27:36 2015 : Debug: (1) } # policy remove_reply_message_if_eap = noop Mon Jul 6 20:27:36 2015 : Debug: (1) } # Post-Auth-Type REJECT = updated Mon Jul 6 20:27:36 2015 : Debug: (1) Delaying response for 1.000000 seconds Mon Jul 6 20:27:36 2015 : Debug: Waking up in 0.3 seconds. Mon Jul 6 20:27:36 2015 : Debug: Waking up in 0.6 seconds. ---[ quotation end ]------------------------------------------- -- Zeus V. Panchenko jid:zeus@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET)
the configuration described in the initial post successfully works on freeradius-2.2.5 ... how to understand, what differs? ---[ quotation start ]------------------------------------------- +} # group authorize = updated Found Auth-Type = EAP # Executing group from file /usr/local/etc/raddb/sites-enabled/default +group authenticate { [eap] Request found, released from the list [eap] EAP/md5 [eap] processing type md5 [eap] Freeing handler ++[eap] = ok +} # group authenticate = ok # Executing section post-auth from file /usr/local/etc/raddb/sites-enabled/default +group post-auth { ++[exec] = noop +} # group post-auth = noop Sending Access-Accept of id 26 to 192.168.0.1 port 49205 Reply-Message = "002590d9762c, you are comming as MAC Auth object." Tunnel-Private-Group-Id:0 = "VLAN3499" Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Type:0 = VLAN Service-Type = Framed-User EAP-Message = 0x03010004 Message-Authenticator = 0x00000000000000000000000000000000 User-Name = "002590d9762c" ---[ quotation end ]------------------------------------------- -- Zeus V. Panchenko jid:zeus@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET)
On Jul 6, 2015, at 1:56 PM, Zeus Panchenko <zeus@ibs.dn.ua> wrote:
I am trying to configure MAC auth by implementing EAP/MD5 as it is described here: http://wiki.freeradius.org/modules/Rlm_eap#My-Userbase-is-in-LDAP-and-I-want...
FR v.3.0.8 is on FreeBSD 10.1R supplicant is on FreeBSD 10.1R connected (by wire) to FR wia switch
but something is wrong and I can not understand what ... please help me to see what I do not see ...
You edited the default configuration and broke it. Don't do that.
as backend I have LDAP and in it, userPassword format is Cleartext-Password (for the sample from the debug bellow it is `00-25-90-D9-76-2C'
as I understand from the debug bellow, I successfully pass authorization but fail to authenticate against eap_md5 ...
why?
Because you deleted the "pap" module from the "authorize" section. It should be listed last there. It takes care of normalizing passwords. In this case, turning Password-With-Header into Cleartext-Password.
---[ quotation start ]------------------------------------------- Mon Jul 6 20:27:36 2015 : Debug: (0) Received Access-Request Id 200 from 192.168.0.1:49205 to 192.168.0.254:1812 length 137
PLEASE just post "radiusd -X". This is what is requested in the FAQ, "man" pages, and daily on this list. Adding extra debug information doesn't help in most cases. Here, it just makes the problem harder to spot. Alan DeKok.
Ok I see that. I assume the username is coming from this portion of the client.cnf? [client] countryName = FR stateOrProvinceName = Radius localityName = Somewhere organizationName = Example Inc. emailAddress = user@example.com commonName = user@example.com I would have expected FR3 to ignore UserID/PWD when using EAP/TLS Certificates??? if it doesn’t do I have to create a username for each client cert? Or is there a conf file that I need to modify to work with EAP/TLS?
On Jul 7, 2015, at 2:07 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Jul 6, 2015, at 1:56 PM, Zeus Panchenko <zeus@ibs.dn.ua> wrote:
I am trying to configure MAC auth by implementing EAP/MD5 as it is described here: http://wiki.freeradius.org/modules/Rlm_eap#My-Userbase-is-in-LDAP-and-I-want...
FR v.3.0.8 is on FreeBSD 10.1R supplicant is on FreeBSD 10.1R connected (by wire) to FR wia switch
but something is wrong and I can not understand what ... please help me to see what I do not see ...
You edited the default configuration and broke it. Don't do that.
as backend I have LDAP and in it, userPassword format is Cleartext-Password (for the sample from the debug bellow it is `00-25-90-D9-76-2C'
as I understand from the debug bellow, I successfully pass authorization but fail to authenticate against eap_md5 ...
why?
Because you deleted the "pap" module from the "authorize" section. It should be listed last there. It takes care of normalizing passwords. In this case, turning Password-With-Header into Cleartext-Password.
---[ quotation start ]------------------------------------------- Mon Jul 6 20:27:36 2015 : Debug: (0) Received Access-Request Id 200 from 192.168.0.1:49205 to 192.168.0.254:1812 length 137
PLEASE just post "radiusd -X". This is what is requested in the FAQ, "man" pages, and daily on this list. Adding extra debug information doesn't help in most cases. Here, it just makes the problem harder to spot.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Jul 7, 2015, at 4:23 PM, Kris Armstrong <kris.armstrong@me.com> wrote:
Ok I see that. I assume the username is coming from this portion of the client.cnf?
In a way. That file is used to create the certificate. The common name of the certificate then becomes the EAP-Identity and the User-Name.
I would have expected FR3 to ignore UserID/PWD when using EAP/TLS Certificates???
It doesn't need passwords. It *does* need User-Name, for things like proxying.
if it doesn’t do I have to create a username for each client cert?
No. But you *do* need to tell FreeRADIUS that the realm (i.e. domain name) is local, and that it shouldn't be stripped from the User-Name. See raddb/proxy.conf. This is documented.
Or is there a conf file that I need to modify to work with EAP/TLS?
No. Alan DeKok.
Alan DeKok <aland@deployingradius.com> wrote:
On Jul 6, 2015, at 1:56 PM, Zeus Panchenko <zeus@ibs.dn.ua> wrote:
as I understand from the debug bellow, I successfully pass authorization but fail to authenticate against eap_md5 ...
why?
Because you deleted the "pap" module from the "authorize" section. It should be listed last there. It takes care of normalizing passwords. In this case, turning Password-With-Header into Cleartext-Password.
emm ... as I figured out, the problem is in password format though ... it has to be the same as User-Name attribute value passed by NAS to FR ... in my case it was MAC address in lowercase without delimiters (it is how commutators, at least Cisco SF300 format User-Name) while in LDAP DB I'm trying to switch to the format of FR normalized MAC (uppercase dash delimited) ... is this problem due to pap issue you described? after I changed password to the value of User-Name attribute passed from NAS, the Access-Accept succeeded ... so, now I wonder, can I somehow rewrite User-Name value to use normalized MAC? I think it is good idea to use FR normalized MAC format in LDAP DB for login/password, and for that I'd like to put Calling-Station-Id value to User-Name and further, to use normalized format is it sound good? or may be this practice is already common and I am reinventing the wheel?
PLEASE just post "radiusd -X". This is what is requested in the
sorry, I will -- Zeus V. Panchenko jid:zeus@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET)
On Jul 7, 2015, at 4:54 PM, Zeus Panchenko <zeus@ibs.dn.ua> wrote:
emm ... as I figured out, the problem is in password format though ... it has to be the same as User-Name attribute value passed by NAS to FR ...
The password isn't the User-Name.
in my case it was MAC address in lowercase without delimiters (it is how commutators, at least Cisco SF300 format User-Name) while in LDAP DB I'm trying to switch to the format of FR normalized MAC (uppercase dash delimited) ... is this problem due to pap issue you described?
No.
after I changed password to the value of User-Name attribute passed from NAS, the Access-Accept succeeded ...
so, now I wonder, can I somehow rewrite User-Name value to use normalized MAC?
Don't do that.
I think it is good idea to use FR normalized MAC format in LDAP DB for login/password, and for that I'd like to put Calling-Station-Id value to User-Name and further, to use normalized format
Not everyone uses LDAP.
is it sound good? or may be this practice is already common and I am reinventing the wheel?
In v3, see raddb/policy.d/canonicalization It has policies to normalize MAC addresses in Calling-Station-Id. The same policies can be applied to other attributes, too. Alan DeKok.
Alan DeKok <aland@deployingradius.com> wrote:
is it sound good? or may be this practice is already common and I am reinventing the wheel?
In v3, see raddb/policy.d/canonicalization It has policies to normalize MAC addresses in Calling-Station-Id. The same policies can be applied to other attributes, too.
just have written rewrite_mac_auth_user_name in likeness of rewrite_calling_station_id and it works, User-Name is rewritten but now I receive EAP complain regarding EAP-Identity which differs from the rewritten User-Name ... -- Zeus V. Panchenko jid:zeus@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET)
On Jul 8, 2015, at 4:27 AM, Zeus Panchenko <zeus@ibs.dn.ua> wrote:
just have written rewrite_mac_auth_user_name in likeness of rewrite_calling_station_id and it works, User-Name is rewritten but now I receive EAP complain regarding EAP-Identity which differs from the rewritten User-Name ...
Well, I did say doing that would break EAP. The solution is to put the "fixed" User-Name into the Stripped-User-Name attribute. The default configuration uses that in preference to User-Name. It's meant for getting "user@example.com" and then looking up "user" in a database. But using it to "fix" the MAC address will be fine, too. Alan DeKok.
Alan DeKok <aland@deployingradius.com> wrote:
emm ... as I figured out, the problem is in password format though ... it has to be the same as User-Name attribute value passed by NAS to FR ...
The password isn't the User-Name.
what am I missing then, please? in my case Access-Accept succeeded only when I changed the password to the value of User-Name attribute ... isn't "MAC auth" mean login=password=MAC ?
so, now I wonder, can I somehow rewrite User-Name value to use normalized MAC?
Don't do that.
why? if not, then what is the way to achieve the desired? to store login/password as FR normalized MAC address and eap_md5 understand that (while User-Name differs)?
In v3, see raddb/policy.d/canonicalization It has policies to normalize MAC addresses in Calling-Station-Id. The same policies can be applied to other attributes, too.
does it mean I can transform original User-Name value like a1b2c3d4e5f6 to A1-B2-C3-D4-E5-F6 ? -- Zeus V. Panchenko jid:zeus@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET)
On Jul 8, 2015, at 6:25 PM, Zeus Panchenko <zeus@ibs.dn.ua> wrote:
what am I missing then, please? in my case Access-Accept succeeded only when I changed the password to the value of User-Name attribute ...
isn't "MAC auth" mean login=password=MAC ?
For some systems, yes.
so, now I wonder, can I somehow rewrite User-Name value to use normalized MAC?
Don't do that.
why? if not, then what is the way to achieve the desired? to store login/password as FR normalized MAC address and eap_md5 understand that (while User-Name differs)?
In general, mangling the User-Name is a bad idea. It means that the authentication and accounting may have different views of what the user name is. It means that EAP may not work correctly. It means that proxying may break. You're better off using a temporary attribute for the "mangled" user name, and leaving User-Name alone. But in the end it's your system...
In v3, see raddb/policy.d/canonicalization It has policies to normalize MAC addresses in Calling-Station-Id. The same policies can be applied to other attributes, too.
does it mean I can transform original User-Name value like a1b2c3d4e5f6 to A1-B2-C3-D4-E5-F6 ?
That's what the policy tries to do. Alan DeKok.
I tried uncommenting the line nostrip from the proxy.con. that didn’t work.
On Jul 7, 2015, at 7:09 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Jul 8, 2015, at 6:25 PM, Zeus Panchenko <zeus@ibs.dn.ua> wrote:
what am I missing then, please? in my case Access-Accept succeeded only when I changed the password to the value of User-Name attribute ...
isn't "MAC auth" mean login=password=MAC ?
For some systems, yes.
so, now I wonder, can I somehow rewrite User-Name value to use normalized MAC?
Don't do that.
why? if not, then what is the way to achieve the desired? to store login/password as FR normalized MAC address and eap_md5 understand that (while User-Name differs)?
In general, mangling the User-Name is a bad idea. It means that the authentication and accounting may have different views of what the user name is. It means that EAP may not work correctly. It means that proxying may break.
You're better off using a temporary attribute for the "mangled" user name, and leaving User-Name alone. But in the end it's your system...
In v3, see raddb/policy.d/canonicalization It has policies to normalize MAC addresses in Calling-Station-Id. The same policies can be applied to other attributes, too.
does it mean I can transform original User-Name value like a1b2c3d4e5f6 to A1-B2-C3-D4-E5-F6 ?
That's what the policy tries to do.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
I tried uncommenting the line nostrip from the proxy.con. that didn’t work.
On Jul 7, 2015, at 7:09 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Jul 8, 2015, at 6:25 PM, Zeus Panchenko <zeus@ibs.dn.ua> wrote:
what am I missing then, please? in my case Access-Accept succeeded only when I changed the password to the value of User-Name attribute ...
isn't "MAC auth" mean login=password=MAC ?
For some systems, yes.
so, now I wonder, can I somehow rewrite User-Name value to use normalized MAC?
Don't do that.
why? if not, then what is the way to achieve the desired? to store login/password as FR normalized MAC address and eap_md5 understand that (while User-Name differs)?
In general, mangling the User-Name is a bad idea. It means that the authentication and accounting may have different views of what the user name is. It means that EAP may not work correctly. It means that proxying may break.
You're better off using a temporary attribute for the "mangled" user name, and leaving User-Name alone. But in the end it's your system...
In v3, see raddb/policy.d/canonicalization It has policies to normalize MAC addresses in Calling-Station-Id. The same policies can be applied to other attributes, too.
does it mean I can transform original User-Name value like a1b2c3d4e5f6 to A1-B2-C3-D4-E5-F6 ?
That's what the policy tries to do.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Alan DeKok <aland@deployingradius.com> wrote:
why? if not, then what is the way to achieve the desired? to store login/password as FR normalized MAC address and eap_md5 understand that (while User-Name differs)?
In general, mangling the User-Name is a bad idea. It means that the authentication and accounting may have different views of what the user name is. It means that EAP may not work correctly. It means that proxying may break.
You're better off using a temporary attribute for the "mangled" user name, and leaving User-Name alone. But in the end it's your system...
ok, I understood the idea and I'm confused even more ... please advise, what is the possible way to achieve what I described? to leave User-Name intact and to manage all possibilities in UI to DB (to manage new user creation or existent ones modification) with account of the hardware User-Name-representation-types? or it is possible with some eap_md5 configuration indeed? -- Zeus V. Panchenko jid:zeus@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET)
participants (4)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Kris Armstrong -
Zeus Panchenko