Freeradius原理

FreeRadius原理，转载自：chinaunix

FreeRadius原理

分为3个部分:用户/nas/radius

用户提供认证名、密码到NAS（Network Access Server）

NAS一般是路由器、交换机等设备

NAS提交相应信息到radius服务器，由radius服务器进行认证，其中认证信息也可以存放于mysql、ldap、oracle、postgreSQL等数据库中

 

NAS发送radius-request到radius服务器，如果多次连接失败，则NAS可发送数据包到其他radius服务器

 

Radius服务器根据用户名查找相应记录，包括用户口令、访问端口、访问权限等，如果用户被否认的话，radius服务器发送radius-reject包到NAS

如果用户被确认，则radius服务器发送radius-challenge数据包，要求NAS提供更多的相关属性数值；NAS通知用户要求提供更多信息，然后再创建radius-request包，而radius服务器经核实后，再次发送radius-accept包，返回用户所需的属性（ip、mask、MTU等）

 

Radius数据包结构：

Code（8bit）、identifier(8bit)、length(16bit)、Authenticator(128bit)、Attributes（不定长）

 

Attribute结构：

Type、length、value

 

常用的Type类型：

User-Name     Password              CHAP-Password    NAS-IP-Address    NAS-Post-ID  Service-Type  Frame-Protocol等等

User-Password或CHAP-Password默认以md5加密

 

Attributes应该包括以下几个属性： 

◆ “User-Name”
◆ “User-Password”或“CHAP-Password”
◆ “NAS-IP-Address”
* “NAS-Identifier”
◆ “NAS-Port”
◆ “NAS-Port-Type”

 

早期的users文件格式：(man 5 users)

Username       check_items

                     Reply_items

其中，check items中的属性值和radius-request包中的属性值做比较，如果匹配则将reply items中的属性值添加到radius-reply包中去

如果username为DEFAULT 则匹配所有用户名

属性：Fall_Through=No表示不再查询下一条匹配记录，直接返回。

 

属性操作符：

“＝”    赋值操作符，不得用于check items，如之前无相应属性则添加

“：＝”       总用于check items，如果request包中没有该属性，则添加，并且覆盖config items中的相同属性值

“＋＝”       用户check items，总是添加当前属性值到config items中。

“＝＝”、“！＝”、“＝～”、“！～”、“＝*”、“!*”都是逻辑判断符

 

Sql模块分为：

前端：rlm_sql

后端：rlm_sql_mysql/rlm_sql_postgresql等

 

Sql查看流程：

1. Search the radcheck table for any check attributes specific to the user

 2. If check attributes are found, and there's a match, pull the reply items

     from the radreply table for this user and add them to the reply

  3. Group processing then begins if any of the following conditions are met:

     a. The user IS NOT found in radcheck

     b. The user IS found in radcheck, but the check items don't match

     c. The user IS found in radcheck, the check items DO match AND

        the read_groups directive is set to 'yes'

  4. If groups are to be processed for this user, the first thing that is

     done is the list of groups this user is a member of is pulled from the

     usergroup table ordered by the priority field.  The priority field of

     the usergroup table allows us to control the order in which groups are

     processed, so that we can emulate the ordering in the users file.  This

     can be important in many cases.

  5. For each group this user is a member of, the corresponding check items

     are pulled from radgroupcheck table and compared with the request.  If

     there is a match, the reply items for this group are pulled from the

     radgroupreply table and applied.

  6. Processing continues to the next group IF:

     a. There was not a match for the last group's check items

     (The above is exactly the same as in the users file)

  7. Finally, if the user has a User-Profile attribute set or the Default

     Profile option is set in the sql.conf, then steps 4-6 are repeated for

     the groups that the profile is a member of