RADIUS Specific Authentication
RADIUS specific authentication can be divided into two parts. The first
one takes place before Common authentication
process, the second one - after this process. RADIUS specific authentication
is not executed if IRADIUSAuthentication
interface is not implemented by server extension, and only then common
authentication is performed.
First, it is checked if the packet is returned as a response to a previously
issued Challenge-Response packet (determined by State attribute
present in the packet). If it's true:
- EAP-Message attribute is looked for.
If this attribute is present in the packet, but IEAP
interface is not supported by server extension, ClearBox Server performs
EAP-MD5 authentication. As the request packet contains State
attribute, it means that the EAP message in the packet is MD5 response.
Server calls ICommonAuthentication::GetUserPassword
to get user password. If it's not available in clear text form or user
was not found by his name, ICommonAuthentication::LogonStatus
is called with authRes parameter set to AR_NOUSER or AR_NOPWD
respectively, and authentication result is ACCESS_REJECT. Then server
generates a MD5 response from its original challenge and its copy of
user password it just has received. If they are not equal, user is rejected
with ACCESS_REJECT and ICommonAuthentication::LogonStatus
is called with authRes set to AR_WRONGPWD. If they are equal,
server goes to the next step.
If IEAP interface is supported, ClearBox Server combines all
EAP-Message attributes into one array of bytes and passes it
to IEAP::ProcessMessage method,
which returns authentication result (ACCESS_ACCEPT/ ACCESS_CHALLENGE/
ACCESS_REJECT) and list of attributes to be put into response packet.
Authentication result returned by this method is sent back as access
code (ACCESS_ACCEPT/ ACCESS_CHALLENGE/ ACCESS_REJECT) to the RADIUS
client.
- If the access-request packet is sent by NAS as a response to the previously
issued Access-Challenge packet, then server calls IRADIUSAuthentication::ChallengeDataReply
method of server extension and passes it an attribute that server extension
has requested in IRADIUSAuthentication::GetChallengeResponseAttributes
method implementation. This method returns authentication result (ACCESS_ACCEPT/
ACCESS_CHALLENGE/ ACCESS_REJECT).
If authentication result (ACCESS_ACCEPT/ACCESS_CHALLENGE/ACCESS_REJECT)
has not been received then
Common authentication process begins.
Authentication method is defined by attributes found in the packet.
If none of known methods was found, user is rejected (ACCESS_REJECT).
Some changes are made in this process to perform EAP authentication.
If at this point there's an Access-Request packet with EAP message embedded,
this means that it's initiating EAP/Identity response from the authenticated
peer (client).
- If IEAP interface is implemented by the server
extension then the authentication result is determined by IEAP::ProcessMessage
return value.
- If is not implemented, then the server generates MD5 challenge, so
authentication result is ACCESS_CHALLENGE.
If user was accepted then IRADIUSAuthentication::CanAuthenticate
is called if IRADIUSAuthentication
interface is implemented by server extension. The final authentication
result is received:
See Also
Authentication concepts, RADIUS
concepts
© 2001-2003 XPerience Technologies. www.xperiencetech.com
|