I've realized two tests with the same result. Radius server reply with a Access-Reject.
First test : The users file without Auth-Type
=============================================
See below users file :
----------------------
# a0153 :
#---------------------------------------------------------
a0153 Auth-Type := LDAP
cisco-avpair = "shell:priv-lvl=15",
Service-Type = Administrative-User#=========================================================
# Test's User for 802.1x
#=========================================================
chapalain User-Password == "aaaa"
Service-Type = Framed-User# Reject all #--------------------------------------------------------- DEFAULT Auth-Type := Reject
See below the end of radiusd's log :
------------------------------------
Listening on IP address *, ports 1812/udp and 1813/udp, with proxy on 1814/udp.
Ready to process requests.
rad_recv: Access-Request packet from host 10.154.253.18:1812, id=48, length=108
NAS-IP-Address = 10.154.253.18
NAS-Port-Type = Async
User-Name = "chapalain"
Service-Type = Framed-User
Framed-MTU = 1500
Calling-Station-Id = "00-0b-cd-ac-7a-fa"
EAP-Message = 0x0200000e0163686170616c61696e
Message-Authenticator = 0xe13858cff2a5d611f623b7c67ad54263
modcall: entering group authorize for request 0
modcall[authorize]: module "preprocess" returns ok for request 0
rlm_eap: EAP packet type response id 0 length 14
rlm_eap: No EAP Start, assuming it's an on-going EAP conversation
modcall[authorize]: module "eap" returns updated for request 0
rlm_realm: No '@' in User-Name = "chapalain", looking up realm NULL
rlm_realm: No such realm "NULL"
modcall[authorize]: module "suffix" returns noop for request 0
users: Checking chapalain at 10
rad_check_password: Found Auth-Type EAP
auth: type "EAP"
modcall: entering group authenticate for request 0
rlm_eap: EAP Identity
rlm_eap: processing type md5
rlm_eap_md5: Issuing Challenge
modcall[authenticate]: module "eap" returns handled for request 0
modcall: group authenticate returns handled for request 0
users: Matched DEFAULT at 15
modcall[authorize]: module "files" returns ok for request 0
modcall: group authorize returns updated for request 0
rad_check_password: Found Auth-Type Reject
rad_check_password: Auth-Type = Reject, rejecting user
auth: Failed to validate the user.
Login incorrect: [chapalain/<no User-Password attribute>] (from client sw-info-ouest-test port 0 cli 00-0b-cd-ac-7a-fa)
Delaying request 0 for 1 seconds
Finished request 0
Going to the next request
--- Walking the entire request list ---
Waking up in 1 seconds...
Second test : The users file with Auth-Type := Local
=====================================================
See below users file :
----------------------
# a0153 :
#---------------------------------------------------------
a0153 Auth-Type := LDAP
cisco-avpair = "shell:priv-lvl=15",
Service-Type = Administrative-User#=========================================================
# Test's User for 802.1x
#=========================================================
chapalain Auth-Type := Local, User-Password == "aaaa"
Service-Type = Framed-User# Reject all #--------------------------------------------------------- DEFAULT Auth-Type := Reject
See below the end of radiusd's log :
------------------------------------
Listening on IP address *, ports 1812/udp and 1813/udp, with proxy on 1814/udp.
Ready to process requests.
rad_recv: Access-Request packet from host 10.154.253.18:1812, id=47, length=108
NAS-IP-Address = 10.154.253.18
NAS-Port-Type = Async
User-Name = "chapalain"
Service-Type = Framed-User
Framed-MTU = 1500
Calling-Station-Id = "00-0b-cd-ac-7a-fa"
EAP-Message = 0x0201000e0163686170616c61696e
Message-Authenticator = 0x5f73497fa70542209ff3699f57600825
modcall: entering group authorize for request 0
modcall[authorize]: module "preprocess" returns ok for request 0
rlm_eap: EAP packet type response id 1 length 14
rlm_eap: No EAP Start, assuming it's an on-going EAP conversation
modcall[authorize]: module "eap" returns updated for request 0
rlm_realm: No '@' in User-Name = "chapalain", looking up realm NULL
rlm_realm: No such realm "NULL"
modcall[authorize]: module "suffix" returns noop for request 0
users: Checking chapalain at 10
rad_check_password: Found Auth-Type Local
auth: type Local
auth: No User-Password or CHAP-Password attribute in the request
users: Matched DEFAULT at 15
modcall[authorize]: module "files" returns ok for request 0
modcall: group authorize returns updated for request 0
rad_check_password: Found Auth-Type Reject
rad_check_password: Auth-Type = Reject, rejecting user
auth: Failed to validate the user.
Login incorrect: [chapalain/<no User-Password attribute>] (from client sw-info-ouest-test port 0 cli 00-0b-cd-ac-7a-fa)
Delaying request 0 for 1 seconds
Finished request 0
Going to the next request
--- Walking the entire request list ---
Alan DeKok wrote:
Jean-Paul Chapalain <[EMAIL PROTECTED]> wrote:>
The radius server receive a 'Access-Request' with the good identity but it return a 'Access-Reject'.
Hmm...
users: Checking chapalain at 10 rad_check_password: Found Auth-Type eap auth: type "EAP" modcall: entering group authenticate for request 0
Ah... that's the problem. The "files" module shouldn't be calling rad_check_password. The simple solution is to delete the "Auth-Type := eap" from the "users" file.
I'll see if I can come up with a more complete patch in a few days.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
