FreeRadius unauthorized access

[Arran Cudbard-Bell]

> If the outer identity name is not valid then why does FR log "Login OK" and under what situation would I see one without the other?

It's not invalid, you haven't defined any rules to determine it's validity so it's not really valid nor invalid. It's logging auth ok, because the inner server authenticated the user based on the inner identity, and the outer server is using the inner server's response to determine whether to send back an Access-Accept or Access-Reject.

Outer identities are often used for request routing, as in eduroam. The user may not want the institution they're visiting to know their identity, so they configure the outer identity to be anonymous@<home institution>, all the intermediary proxies just get anonymous@<home institution>, as the inner identity is protected by the TLS tunnel, but the home server receives the real identity as it terminates the TLS tunnel.

> Is it possible to set the inner/outer identity to be different just using a regular client OS?

Yes, since Windows Vista I believe, and Apple supplicants even further back... wpa_supplicant has supported it for a long time too.

The supplicants aren't the problem here, it really is the server configuration you're using.

So just to clarify, there are a few things you can do if you want to have valid identities everywhere:
* Enforce that the inner/outer identity match in the inner server.
  or
* Enforce that either the inner/outer identity match, or the outer identity is anonymous.
  or
* Set the outer identity from the inner identity and return the inner identity to the NAS, which should then use it for accounting and diagnostic/show commands.

update outer.request {
	User-Name := "%{User-Name}"
}

update outer.reply {
	User-Name := "%{User-NAme}"
}

You probably shouldn't set the reply for users authenticating at visited sites (if you're implementing Eduroam), they might get grumpy.

-Arran

Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS Development Team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 881 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20140201/235e1820/attachment-0001.pgp>