最近搭了企业级加密的server 2003服务器，教程完全google，无任何自主创新。折腾了一周，总算搞定了，同时也验证了server 2003下的TLS和PEAP0加密算法是正常的。
至于搭建server 2003无线认证服务器，可以参考这篇教程，WLAN无线基站使用802.1x+RADIUS服务器认证配置超详细文档，很详细，一步一步操作毫无压力。
虽然按时完成了领导交代的任务，但是回顾一下，整个过程学到的东西好少，对802.1X，对加密算法，对radiator服务器，这些知识点还是似懂非懂的。仔细算下来，整个任务中，除了忙忙碌碌的去差资料，似乎缺少了点主观能动性和总结。知识点总是抱着够用就行的心态，没有扩展学习。业余时间都浪费在打魔兽当中了。失败。
说太多有点伤感，也有点恨自己不争气。算了，能学多少就多少吧，顺其自然。
1，802.1X拓扑图
802.1X协议是一种2层交换协议。
A：客户端Supplicant System，一般为一个用户终端系统，该终端系统通常要安装一个客户端软件，用户通过启动这个客户端软件发起IEEE 802.1x协议的认证过程。
B：LAN还是WLAN，不但由A决定，还由D决定。比如server 2003中IAS可以选择lan和wireless。
C：认证系统Authenticator System，通常为支持IEEE 802.1x协议的网络设备。该设备对应于不同用户的端口有两个逻辑端口：受控（controlled Port）端口和非受控端口（uncontrolled Port）。第一个逻辑接入点（非受控端口），允许验证者和 LAN 上其它计算机之间交换数据，而无需考虑计算机的身份验证状态如何。非受控端口始终处于双向连通状态（开放状态），主要用来传递EAPOL协议帧，可保证客户端始终可以发出或接受认证。第二个逻辑接入点（受控端口），允许经验证的 LAN 用户和验证者之间交换数据。受控端口平时处于关闭状态，只有在客户端认证通过时才打开，用于传递数据和提供服务。受控端口可配置为双向受控、仅输入受控两种方式，以适应不同的应用程序。如果用户未通过认证，则受控端口处于未认证（关闭）状态，则用户无法访问认证系统提供的服务。
Authenticator System——— Switch （边缘交换机或无线接入设备）是—根据客户的认证状态控制物理接入的设备，switch在客户和认证服务器间充当代理角色（proxy）。 switch与client间通过EAPOL协议进行通讯，switch与认证服务器间通过EAPoRadius或EAP承载在其他高层协议上，以便穿越复杂的网络到达 Authentication Server （EAP Relay）；switch要求客户端提供identity，接收到后将EAP报文承载在Radius格式的报文中，再发送到认证服务器，返回等同； switch根据认证结果控制端口是否可用；
问题：
1）用Ominipeek抓包，过滤AP的MAC，能不能抓到AP和Radius交互的报文？（理论上不可以，Ominipeek只能抓空口的报文，即使加上过滤，也抓不到AP和Radius交互的ether报文。）
2）加密算法（TLS、PEAP、TTLS等）在哪个阶段生效？
D：认证服务器Authentication Server System：通常为RADIUS服务器，该服务器可以存储有关用户的信息，比如用户名和口令、用户所属的VLAN、优先级、用户的访问控制列表等。当用户通过认证后，认证服务器会把用户的相关信息传递给认证系统，由认证系统构建动态的访问控制列表，用户的后续数据流就将接受上述参数的监管。常见有四种，hostapd、devicecap、radiator、server 2003（2008），每种服务器支持的加密类型不尽相同。
Authentication server ———（认证服务器）对客户进行实际认证，认证服务器核实客户的identity，通知swtich是否允许客户端访问LAN和交换机提供的服务Authentication Sever 接受 Authenticator 传递过来的认证需求，认证完成后将认证结果下发给 Authenticator，完成对端口的管理。由于 EAP 协议较为灵活，除了 IEEE 802.1x 定义的端口状态外，Authentication Server 实际上也可以用于认证和下发更多用户相关的信息，如VLAN、QOS、加密认证密钥、DHCP响应等。
问题遗留：
1）现网中，根据什么选择服务器，四种服务器的优缺点？
2）设备端和服务器是否可以合二为一，由路由器担负起服务器的责任？
3）为什么有些802.1X需要证书，而有些则不需要？
2，802.1X信令流程图
资料上讲还有一种流程改图，但是我没有接触过，可以看看这篇文章。
认证过程如下：
(1) 当用户有访问网络需求时打开802.1X客户端程序，输入已经申请、登记过的用户名和密码，发起连接请求（EAPOL-Start报文）。此时，客户端程序将发出请求认证的报文给设备端，开始启动一次认证过程。
(2) 设备端收到请求认证的数据帧后，将发出一个请求帧（EAP-Request/Identity报文）要求用户的客户端程序发送输入的用户名。
(3) 客户端程序响应设备端发出的请求，将用户名信息通过数据帧（EAP-Response/Identity报文）发送给设备端。设备端将客户端发送的数据帧经过封包处理后（RADIUS Access-Request报文）送给认证服务器进行处理。
(4) RADIUS服务器收到设备端转发的用户名信息后，将该信息与数据库中的用户名表对比，找到该用户名对应的密码信息，用随机生成的一个加密字对它进行加密 处理，同时也将此加密字通过RADIUS Access-Challenge报文发送给设备端，由设备端转发给客户端程序。
(5) 客户端程序收到由设备端传来的加密字（EAP-Request/MD5 Challenge报文）后，用该加密字对密码部分进行加密处理（此种加密算法通常是不可逆的），生成EAP-Response/MD5 Challenge报文，并通过设备端传给认证服务器。
(6) RADIUS服务器将收到的已加密的密码信息（RADIUS Access-Request报文）和本地经过加密运算后的密码信息进行对比，如果相同，则认为该用户为合法用户，反馈认证通过的消息（RADIUS Access-Accept报文和EAP-Success报文）。
(7) 设备收到认证通过消息后将端口改为授权状态，允许用户通过端口访问网络。在此期间，设备端会通过向客户端定期发送握手报文的方法，对用户的在线情况进行监测。缺省情况下，两次握手请求报文都得不到客户端应答，设备端就会让用户下线，防止用户因为异常原因下线而设备无法感知。
(8) 客户端也可以发送EAPOL-Logoff报文给设备端，主动要求下线。设备端把端口状态从授权状态改变成未授权状态，并向客户端发送EAP-Failure报文。
3，认证过程端口状态
认证通过前，通道的状态为unauthorized，此时只能通过EAPOL的802.1X认证报文；
认证通过时，通道的状态切换为authorized，此时从远端认证服务器可以传递来用户的信息，比如VLAN、CAR参数、优先级、用户的访问控制列表等等；
认证通过后，用户的流量就将接受上述参数的监管，此时该通道可以通过任何报文，注意只有认证通过后才有DHCP等过程。
认证通过之后的保持：
认证端Authenticator可以定时要求Client重新认证，时间可设。重新认证的过程对User是透明的(应该是User不需要重新输入密码)。
下线方式：
物理端口Down；
重新认证不通过或者超时；
客户端发起EAP_Logoff帧；
网管控制导致下线；
4，802.1X起源
802.1X起源于802.11协议，802.1X协议主要用来解决无线局域网用户接入认证问题，随后被扩展至lan领域。
5，EAPOL协议介绍
IEEE 802.1x定义了基于端口的网络接入控制协议，需要注意的是该协议仅适用于接入设备与接入端口间点到点的连接方式。 为了在点到点链路上建立通信，在链路建立阶段PPP链路的每一端都必须首先发送LCP数据包来对该数据链路进行配置。在链路已经建立起来后，在进入网络层协议之前，PPP提供一个可选的认证阶段。而EAPOL就是PPP的一个可扩展的认证协议。
下面是一个典型的PPP协议的帧格式：
当PPP帧中的protocol域表明协议类型为C227(PPP EAP)时，在PPP数据链路层帧的Information域中封装且仅封装PPP EAP数据包，此时表明将应用PPP的扩展认证协议EAP。这个时候这个封装着EAP报文的information域就担负起了下一步认证的全部任务，下一步的EAP认证都将通过它来进行。
一个典型的EAP认证的过程分为：request、response、success或者failure阶段，每一个阶段的报文传送都由Information域所携带的EAP报文来承担。
EAP报文的格式为：
Code域为一个字节，表示了EAP数据包的类型，EAP的Code的值指定和意义如下：
Code＝1————→Request
Code＝2 ————→Response
Code＝3 ————→Success
Code＝4 ————→Failure
Indentifier域为一个字节，辅助进行request和response的匹配————每一个request都应该有一个response相对应，这样的一个Indentifier域就建立了这样的一个对应关系————相同的Indentifier相匹配。
Identifier域为一个字节。在等待Response时根据timeout而重发的Request的Identifier域必须相同。任何新的（非重发的）Request必须修改Identifier域。如果对方收到了重复的Request，并且已经发送了对该Request的Response，则对方必须重发该Response。如果对方在给最初的Request发送Response之前收到重复的Request（也就是说，它在等待用户输入），它必须悄悄的丢弃重复的Request。
Length域为两个字节，表明了EAP数据包的长度，包括Code,Identifier,Length以及Data等各域。超出Length域范围的字节应该视为数据链路层填充（padding）,在接收时应该被忽略掉。
Data域为0个或者多个字节，Data域的格式由Code的值来决定。
当Code域为1或者2的时候，这个时候为EAP的request和response报文，data域包括Type和Type Data字段，报文的格式为：
Type域为一个字节,该域表明了Request或Response的类型。在EAP的Request或Response中必须出现且仅出现一个Type。通常Response中的Type域和Request中的Type域相同。但是，Response可以有个Nak类型，表明Request中的Type不能被对方接受。当对方发送Nak来响应一个Request时，它可以暗示它所希望使用并且支持的认证类型。Type Data域随Request和相对应的Response的Type的不同而不同。
Type域的说明如下：
Type域总共分为6个值域，其中头3种Type被认为特殊情形的Type，其余的Type定义了认证的交换流量。Nak类型仅对Response数据包有效，不允许把它放在Request中发送。
Type＝1————→Identifier
Type＝2————→Notification
Type＝3————→Nak（Response Only）
Type＝4————→MD5-Challenge
Type＝5————→One-Time Password (OTP)
Type＝4————→Generic Token Card
当Code域为3或者4的时候，这个时候为EAP的Success和Failure报文，报文的格式为：
当Code为3的时候是Success报文，当Code为4的时候是Failure报文
6，802.1X认证工作机制
IEEE 802.1X认证系统使用EAP（Extensible Authentication Protocol，可扩展认证协议）来实现客户端、设备端和认证服务器之间认证信息的交换。
1) 在客户端与设备端之间，EAP协议报文使用EAPOL封装格式，直接承载于LAN环境中。
2) 在设备端与RADIUS服务器之间，可以使用两种方式来交换信息。一 种是EAP协议报文使用EAPOR（EAP over RADIUS）封装格式承载于RADIUS协议中；另一种是设备端终结EAP协议报文，采用包含PAP（Password Authentication Protocol，密码验证协议）或CHAP（Challenge Handshake Authentication Protocal，质询握手验证协议）属性的报文与RADIUS服务器进行认证。
3) 当用户通过认证后，认证服务器会把用户的相关信息传递给设备端，设备端根据RADIUS服务器的指示（Accept或Reject）决定受控端口的授权/非授权状态。
碉堡了，傻傻的格盘、分区、安装server2003，、搭建认证服务器，傻傻浪费了一周时间，今天闲来无事网上搜了一下，竟然有种东西叫WinRadius，之需要安装运行就可以便捷搭建认证服务器。看了这篇文章，真心觉得只有想不到没有做不到，任何事情都有更方便的途径，只是看你发现了没有。哎。