VLAN-mapping by DEFAULT Entry fails

[Phil Mayers]

robiwan at arcor.de wrote:
> Dear all,
> 
> I use a WindowsXP, EAP-Type MD5-challenge as supplicant and a Cisco Catalyst Switch 3750 as authenticator and i want that user hugo will be mapped in VLAN 50 on the switch. This works properly.
> 
> Every other user should be mapped in VLAN 999, my guest-vlan. I try this with a DEFAULT-entry, but this does not work, the switch does not accept any other user, in my case user nobody is unauthorized for my authenticator.
> 
> My other configuration files are seen at the end of this text.
> 
> 
> Thanks in advance...
> Robert
> 
> 
> My entire users file:
> ======================
> 
> hugo            User-Password == "hugo01"	# line 54
>                 Tunnel-Type = VLAN,
>                 Tunnel-Medium-Type = 6,
>                 Tunnel-Private-Group-ID = 50
> 
> DEFAULT         Auth-Type := Accept		# line 69
>                 Tunnel-Type = VLAN,
>                 Tunnel-Medium-Type = 6,
>                 Tunnel-Private-Group-ID = 999

You've overridden Auth-Type. Don't do that. Just this is what you want:

DEFAULT
	Tunnel-Type = VLAN,
	Tunnel-Medium-Type = 6,
	Tunnel-Private-Group-ID = 999

> 
> 
> 
> My radiusd output for user nobody, (my authenticator do not accept this):
> ==========================================================================
> 
> rad_recv: Access-Request packet from host 10.187.0.15:1645, id=218, length=127
>         NAS-IP-Address = 10.187.0.15
>         NAS-Port = 50103
>         NAS-Port-Type = Ethernet
>         User-Name = "nobody"
>         Called-Station-Id = "00-14-69-5B-8B-03"
>         Calling-Station-Id = "00-0B-5D-84-AE-CA"
>         Service-Type = Framed-User
>         Framed-MTU = 1500
>         EAP-Message = 0x0203000b016e6f626f6479
>         Message-Authenticator = 0x48b3cb8e3c0c39e55e33121529f28c7d
>   Processing the authorize section of radiusd.conf
> modcall: entering group authorize for request 0
>   modcall[authorize]: module "preprocess" returns ok for request 0
>   modcall[authorize]: module "chap" returns noop for request 0
>   modcall[authorize]: module "mschap" returns noop for request 0
>     rlm_realm: No '@' in User-Name = "nobody", looking up realm NULL
>     rlm_realm: No such realm "NULL"
>   modcall[authorize]: module "suffix" returns noop for request 0
>   rlm_eap: EAP packet type response id 3 length 11
>   rlm_eap: No EAP Start, assuming it's an on-going EAP conversation
>   modcall[authorize]: module "eap" returns updated for request 0
>     users: Matched entry DEFAULT at line 69
>   modcall[authorize]: module "files" returns ok for request 0
> modcall: leaving group authorize (returns updated) for request 0
>   rad_check_password:  Found Auth-Type Accept
>   rad_check_password: Auth-Type = Accept, accepting the user
> Sending Access-Accept of id 218 to 10.187.0.15 port 1645
>         Tunnel-Type:0 = VLAN
>         Tunnel-Medium-Type:0 = IEEE-802
>         Tunnel-Private-Group-Id:0 = "999"
> Finished request 0
> Going to the next request
> --- Walking the entire request list ---
> Waking up in 6 seconds...
> --- Walking the entire request list ---
> Cleaning up request 0 ID 218 with timestamp 4472b042
> Nothing to do.  Sleeping until we see a request.

So, having overridden auth-type, the radius server just returns accept 
instead of an EAP-Challenge, which will probably be confusing the switch 
or supplicant no end.

You will have to put the password for "nobody" in the users file (and 
any other users). EAP-MD5 is a challenge/response method, and the server 
will need to know the password to validate the response and send the 
correct reply.