iMC iNode中常见用户下线原因分析讲解.docx

上传人:b****6 文档编号:7879099 上传时间:2023-01-26 格式:DOCX 页数:9 大小:132.11KB
下载 相关 举报
iMC iNode中常见用户下线原因分析讲解.docx_第1页
第1页 / 共9页
iMC iNode中常见用户下线原因分析讲解.docx_第2页
第2页 / 共9页
iMC iNode中常见用户下线原因分析讲解.docx_第3页
第3页 / 共9页
iMC iNode中常见用户下线原因分析讲解.docx_第4页
第4页 / 共9页
iMC iNode中常见用户下线原因分析讲解.docx_第5页
第5页 / 共9页
点击查看更多>>
下载资源
资源描述

iMC iNode中常见用户下线原因分析讲解.docx

《iMC iNode中常见用户下线原因分析讲解.docx》由会员分享,可在线阅读,更多相关《iMC iNode中常见用户下线原因分析讲解.docx(9页珍藏版)》请在冰豆网上搜索。

iMC iNode中常见用户下线原因分析讲解.docx

iMCiNode中常见用户下线原因分析讲解

iMCiNode中常见用户下线原因分析

1概述

AAA认证系统流程中,客户端下线后,在AAA认证系统会根据认证设备上传的属性值来确定具体的下线原因(具体可参考:

iMCUAM常见下线原因分析)并记录认证失败日志,这样,网络管理员就可以根据用户下线的原因来定位具体问题,而对于最终来讲,能感知的就是终端的提示信息,如果使用我司iNode客户端认证,认证失败时也会根据AAA服务器下线原因显示相关的提示信息,很大程度,客户端认证失败提示和iMC侧的认证失败日志吻合,现就iNode下线原因做一总结。

2常见下线原因分析及总结

2.1认证失败,客户端提示服务器无响应

问题现象:

客户端认证信息窗口提示“RADIUSServerNoResponse”,认证失败。

1、确认问题PC所连的接入交换机与iMC服务器之间是否通讯正常(除了路由可达之外还包括端口是否被屏蔽),最直接的定位方法是登陆服务器,从服务器侧ping接入交换机。

2、登陆服务器,打开部署监控代理,查看进程选项卡下iMC各进程是否运行正常(显示绿色表示运行正常)。

3、检查“业务-接入业务-接入设备配置”中的配置,确认设备是否已经正确添加以及共享密钥是否配置正确。

4、如果以上检查不能发现问题,则需要分析用户接入组件的调试日志。

如果在日志中看到如下记录,则表明服务器收到来自192.168.121.1的Radius报文,但该IP地址并未作为认证接入设备的IP地址添加到iMC中,请确认“业务-接入业务-接入设备配置”中的配置。

%2008-10-1412:

51:

58;[WARNING

(2)];UAM;$SYS$;(NULL);(NULL);(NULL);InvalidSourceIPorportnumber(from192.168.121.1:

1812).

如果在日志中看到如下记录,则表明接入设备的共享密钥配置与设备上配置的不一致,请确认“业务-接入业务-接入设备配置”中的配置或设备配置。

%2008-10-1412:

53:

29;[ERROR

(1)];UAM;$SYS$;(NULL);(NULL);(NULL);CheckMsgAttr():

InvalidMessage-Authenticatorreceivedfrom192.168.121.1,returnHWR_FAIL.

如果在日志中看到如下记录,则表明服务器上用于监听认证请求报文的端口(缺省为1812)被其他应用程序占用。

若无法确定是什么程序占用了端口,请在服务器的命令行窗口中使用netstat–aon查看占用端口的进程PID,然后在Windows任务管理器中查找该PID所对应的执行程序。

%2008-10-1401:

12:

43;[ERROR

(1)];UAM;$SYS$;(NULL);(NULL);(NULL);FailtobindSocketwithPortforReceiveThread.

5、若以上操作仍不能定位问题,请记录问题处理的过程、发生问题的时间点和用户名并收集用户接入组件调试日志,联系H3C技术支持人员处理。

 

2.2用户不存在或者用户没有申请该服务

问题现象:

客户端提示“开始进行身份验证”,之后立即报“连接中断”。

在服务器侧查看认证失败记录,“认证失败原因”一栏显示为“用户不存在或者用户没有申请该服务”

处理步骤:

1、查看认证失败日志中的“帐号名”,首先在“所有接入用户”中查询该帐号名是否存在。

在确认帐号名存在的前提下,查看认证失败日志中的登录名是否与该用户绑定的服务后缀一致。

如果该用户是LDAP用户,正常情况下登录名应该显示为“用户名@域的NetBIOS名”,该用户应该绑定一个以域的NetBIOS名为服务后缀的服务;如果该用户是普通用户,则登录名为客户端连接属性中填写的用户名,该用户应该绑定一个无服务后缀(服务后缀为空)的服务。

2、请确认是否存在这种情况,用户登陆域时直接在登陆信息窗口中用户名一栏写成“域用户名@域名”,而此时“登陆到”一栏将灰选。

“登陆到”如果灰选的状态停留在“登陆到域”,则域统一认证会失败,认证失败记录显示为“用户不存在或者用户没有申请该服务”,因为iMC中的账户名不允许包含@符号。

3、如果经过以上操作确认无法定位问题,请记录问题处理的过程、发生问题的时间点和用户名并收集用户接入组件调试日志,联系H3C技术支持人员处理。

2.3安全检查代理服务器没有回应,即将强行下线

问题现象:

用户成功通过身份认证,但过数秒钟后客户端提示“安全检查代理服务器没有回应……”,用户被强制下线。

处理步骤:

导致该问题的直接原因是用户通过身份认证后,PC无法与策略服务器正常通讯。

1、终端通过DHCP获取地址的情况下,若客户端出现错误提示时PC仍处于正在获取地址的状态,或已经显示获取地址失败,请先确认该PC的接入环境是否启用了GuestVLAN,如果未启用GuestVLAN,请确保客户端连接属性中的“连接断开后自动更新IP地址”没有被选中。

如果启用了GuestVLAN,请确保客户端连接属性中的“连接断开后自动更新IP地址”已经被选中。

此外,在GuestVLAN环境中,若下线后还未切换到GuestVLAN就立即发起认证,则也有可能导致该问题。

所以建议在GuestVLAN环境中,下线后等待至少10秒钟以上再发起认证。

2、如果iNode客户端参数确认没有问题,但仍获取不到地址。

则需要分析DHCP获取地址(可在取消认证的环境下尝试重新获取地址并在终端抓包)异常的原因。

3、如果终端能够及时获取地址或者配置的是静态IP地址,请确认该地址是否能够与iMC服务器通讯。

常用的做法是在终端打开命令行窗口,长ping服务器的地址。

观察当iNode客户端提示认证通过的那一刻,终端是否能够立即ping通服务器。

如果身份认证通过后不能ping通服务器,则需要排查网络原因。

此外,可以将认证取消后从终端ping服务器,如果认证取消后即可以ping通服务器说明地址本身以及网络没有问题,则需要重点排查交换机侧的问题。

如果认证取消后仍不能ping通服务器,则进一步证明地址配置(获取)有误或网络本身存在问题。

4、如果iNode客户端提示认证通过的那一刻,终端能够立即ping通服务器。

则需要分别从服务器侧和客户端侧排查问题。

首先确保服务器侧的部署监控代理中显示iMC各进程运行正常(参见第二章2.1节)。

在此基础上排除通讯端口被屏蔽的可能,需要确保客户端的1024以上随机端口与服务器侧9019端口的UDP通讯正常。

某些情况下,客户端侧或者服务器侧安装的第三方桌面安全类的软件有可能将通讯屏蔽。

排查问题时建议临时将安全软件关闭。

5、如果以上操作仍不能定位问题,请在复现问题时同时收集客户端调试日志以及策略服务器调试日志,并联系H3C技术支持人员处理。

 

2.4和安全检查代理服务器通信发生错误,当前连接即将被强行中断

问题现象:

用户成功通过身份认证,但过数秒钟后客户端上提示“和安全检查代理服务器通信发生错误……”,用户被强制下线。

处理步骤:

1、iMC与思科交换机配合,当思科交换机上配置了主备iMC服务器的地址时,则有可能在该用户出现问题的这次认证过程中,交换机发生了主备服务器切换(即用户认证到备iMC上)。

可建议该用户在出现问题后,再次尝试认证,正常情况下第二次认证应该能够通过。

此后维护人员可以登陆备份服务器查看在线用户列表,确认该用户是否认证到了备份服务器上。

2、此时需要分析造成交换机主备Radius服务器切换的原因。

首先建议检查交换机配置,排除RadiusServer地址是否配置有误的可能。

如果主iMC地址配置有误,用户第二次会成功认证到备机上。

另外还有一种情况,主iMC服务器的地址配置正确,但在主iMC服务器的地址之前还误配置了其他RadiusServer的地址也会导致该问题,只不过这种情况下第二次认证时是成功认证到主iMC服务器上。

3、排查交换机到主iMC服务器认证失败的原因需要综合考虑多方面的可能。

正常的认证失败(如用户密码错误)不会导致交换机发生主备Radius服务器切换,只有当Radius报文交互未完成的情况下在会导致主备Radius服务器切换。

交换机与主服务器之间网络不通、网络中的丢包(连续几个认证交互报文在交换机与服务器之间被丢弃)或者主服务器软硬件故障都是有可能发生的。

如果此时可以从其他交换机成功认证到主服务器上,则基本可以排除主服务器软硬件故障的可能。

这种情况下如要继续排查问题,建议首先排除交换机与主服务器之间网络不通的可能,稍后可再次验证从发生主备切换的交换机上是否能够成功认证到主服务器上。

4、如果连续认证仍然报同样的错误,请首先检查交换机上是否配置了“aaaaccountingdot1xdefaultstart-stopgroupradius”命令,缺少该命令将导致从该交换机上认证的所有用户必现该问题,始终无法通过安全检查。

其次,请检查iNode客户端的连接属性中的参数配置。

确保在与思科设备配合的DHCP环境中,没有勾选“上传IP地址”。

5、若确认配置无误,请再次复现该问题,同时记录问题处理的过程、发生问题的时间点和用户名,收集客户端调试日志、用户接入组件调试日志、策略服务器调试日志,联系H3C技术支持人员处理。

2.5IP或MAC地址绑定检查失败

问题现象:

客户端认证失败,从服务侧查看认证失败记录显示为“IP或MAC地址绑定检查失败”。

处理步骤:

1、请查看接入用户信息页面中,已绑定的IP或者MAC与问题账户实际的IP/MAC是否一致。

如该帐号需要更换已绑定的IP/MAC地址或者新增IP/MAC绑定,可以直接修改接入用户信息。

2.6域统一认证失败,服务侧查看认证失败记录显示为“LDAP用户密码错误”

问题现象:

客户端认证失败,从服务侧查看认证失败记录显示为“LDAP用户密码错误”。

处理步骤:

与微软AD配合做域统一认证时,iMC服务器本地不会储存域账户的密码,每次认证时都实时将验证密码的工作交由AD服务器处理。

1、发生该问题时,如果不能登陆桌面,首先请用户确认是否在登陆时密码输入错误,其次确认是否有可能在AD服务器上重置了该用户的密码而未知会终端用户。

若以上操作无法定位问题,请复现该问题,同时记录问题处理过程,收集iMC服务器上的抓包信息,联系H3C技术支持人员处理。

2、发生该问题时,如果能够成功登陆到桌面,说明至少用户当前输入的密码曾经成功通过认证,在操作系统本地已经有缓存。

那么可以判断导致该问题的最直接的原因是AD上密码已经更新,而当前仍然是使用的老密码登陆。

请终端用户确认是否在登陆桌面时错误地输入了旧密码。

3、若确认已使用新密码登陆,请再确认登陆操作系统时是否正确选择了登陆域,登陆桌面的过程中,登陆窗口的右侧是否提示“正在进行域统一认证请稍后”。

可能存在这种情况,用户登陆域时直接在登陆信息窗口中用户名一栏写成“域用户名@域名”,而此时“登陆到”一栏将灰选。

这种情况下“登陆到”如果灰选的状态停留在“登陆本机”,则此时不会触发域统一认证。

4、在确保登陆域的基础上,可以在客户端连接属性手工重置密码,然后直接使用该连接认证(无需重启PC触发域统一认证),验证问题是否解决。

5、若以上操作无法定位问题,请复现该问题,同时记录问题处理过程,收集iMC服务器上的抓包信息,联系H3C技术支持人员处理。

 

2.7域统一认证失败,服务侧查看认证失败记录显示为“管理员配置错误”

请检查“LDAP业务管理-服务器配置”中的管理DN是否配置正确。

如果管理员在AD上所处的位置改变或管理员的实际密码修改了未在iMC上同步更改都会造成问题。

2.8余额不足

在计费场景下,认证用户余额不足而下线。

2.9用户密码错误,您已经被加入黑名单

在使用iMC的认证功能组件UAM时,有将用户加入黑名单的功能,目前有有三种方式可以将普通帐号加入黑名单:

第一种情况:

管理员主动将某帐号加入黑名单。

这种情况下,黑名单功能仅仅针对帐号本身,一旦该帐号加入黑名单不论在哪台客户端PC上登录均有效。

请二种情况:

如果采用计费功能的话,帐号因欠费加入黑名单。

这种情况下,也只针对帐号本身。

和第一点情况一样。

第三种情况:

由于密码多次输入错误(比如超过10次),即恶意登录尝试加入黑名单。

这种情况和前两种有区别,它针对帐号和用户使用的那台客户端PC的MAC。

也就是说,某帐号在某台PC上多次输入密码错误而加入黑名单后,如果在其他PC上用正确的用户名和密码登录能正常上线,而不受黑名单的限制。

这样做的目的是:

防止当某人盗用其他人帐号,多次恶意在别的PC上登录多次而加入黑名单,但帐号拥有者本身在自己的电脑上使用正确的帐号上线不受限制。

缺省情况下是一天内输入10次错误的密码会被自动加入黑名单,即第三种情况。

到第二天凌晨自动解除。

“业务>>接入业务>>系统配置>>系统参数配置”中的“认证失败阈值”可调整可供尝试密码的次数。

2.10LDAP服务器上不支持CHAP认证

问题现象:

结合LDAP服务器做认证时,输入用户名,密码后认证上线提示LDAP服务器不支持CHAP认证。

处理步骤:

由于结合微软AD(LDAP)认证,无法将用户密码同步到IMC系统来,故,终端在认证上线后,认证账号的密码还需到AD上校验,如果采用CHAP认证方式,那么认证服务器和AD之间的密码校验不可逆,认证失败,此时,如果是dot1x认证,则需要修改认证方式为pap或者eap(eap方式需要结合我司iNode客户端)dot1xauthentication-methodpap/eap,如果是Portal认证方式,则在Portal服务管理>>设备配置>>端口组信息配置里修改认证方式:

2.11补丁检查失败

问题现象:

在使用iNode客户端进行Windows系统补丁自动更新时,提示“补丁检查失败”。

可以采处理步骤:

1.查看”添加删除程序”中,WSUS客户端插件是否正确安装。

2.在进行补丁检查的时候,用ping命令测试与WSUS服务器之间的连通性,确保与WSUS服务器之间路由可达。

3.察看下发的隔离ACL是否正确。

确保隔离ACL中允许到达WSUS服务器的ACL条目已生效。

2.12用户已失效

问题现象:

客户端发起认证时,客户端提示该用户已失效。

处理步骤:

一般情况下,用户都有一个有效期,一旦过了有效期,该用户将不可用,可以不设置有效期。

2.13接入时段限制

问题现象:

客户端发起认证时,客户端提示接入时段限制。

处理步骤:

iMCUAM或者老CAMS可以设置上网时间段限制,在固定的时间内才能认证上网,具体配置如下,配置好后在服务里引用即可。

2.13无效认证客户端版本

问题现象:

客户端发起认证时,客户端提示无效认证客户端版本。

处理步骤:

iMCUAM为了防止客户端被破解,可以通过iNode的字典文件来校验客户PC的iNode客户端是否合法的客户端,如果UAM发现该客户端不合法,终端将无法通过认证,只能安装正确的iNode客户端。

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 农林牧渔 > 水产渔业

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1