Overview_Radius基本原理和ClearPass Radius处理流程
Task1_CPPM创建一个最简单的认证服务
Task2_ARUBA控制器集成CPPM实现MAC认证
Task3_ARUBA控制器集成CPPM实现PORTAL认证
Task4_ARUBA控制器集成CPPM实现802.1x认证
Task5_ARUBA控制器集成CPPM实现无感知认证
Task6_ARUBA控制器集成CPPM实现访客自注册认证
Task7_ARUBA控制器集成CPPM实现TACACS+认证
Task8_INSIGHT实现自动生成报表及告警
Task9_CPPM认证基本问题诊断
Hi
希望可以多一点clearpass深入一点的教学视频。
杨老师:
您好，看了视频受益匪浅。关于Portal认证有个地方想跟您请教一下。之前我了解到的Portal认证过程中，当客户端发起任意Http请求被AC重定向到Portal页面时，客户端通过推送的页面提交账号密码到Portal服务器，由Portal服务器发送账号密码至AC，最后由AC和Radius服务器进行Radius交互。视频中您提到Aruba的Portal认证过程中，不再经过Portal服务器（CPPM）将账号密码推送给AC的过程，而是AC直接截获用户在推送页面上提交的账号密码后，AC直接和CPPM进行Radius交互。请问这个理解是否正确，若过程确是上述分析的区别，其中区别是否为厂商之间的实现机制的区别？
这个问题，首先这位学员的理解是不充分的，因为作为控制器的portal认证来说，过去无论你是用内置的portal页面还是第三方的页面，从抓包内容看，都是无线终端将页面上输入的账号和密码直接http/https post到控制器的login url上的。 后来随着portal 页面的设计方式不同，例如我们的CPPM portal页面的功能设计，我们的login method增加了server-initial和policy initial，这两种方式的认证方法是让无线终端直接http/https post到cppm portal上，从而进行后续的web-auth认证。 另外我们页面上还有pre-auth认证方式，从抓包上看，是将无线终端在页面上输入的账号和密码先提交给portal平台来先预判，如果账号预验证过了，再将相关认证信息返回给无线终端，最终还是由无线终端http/https post 到控制器的login-url的，并不是由 CPPM Portal 来http/https post到控制器的login-url的