EIA+MAC认证、Portal认证

用户都在一起的

✅ 最优：全局开关（EIA 7.3-E0610+，一键根治）

操作路径（EIA 后台）

1. 进入：系统 → 系统配置 → 认证参数
2. 勾选：MAC 认证请求仅匹配哑终端用户库（核心开关）
3. 保存生效

验证

• 仅在「接入用户 - 哑终端用户」里的 MAC → MAC 认证 SSID 能上线
• 已做 Portal 绑定的 MAC（不在哑终端）→ MAC 认证 SSID 直接拒绝，不会匹配 Portal 用户
• 不影响 Portal 认证：Portal SSID 仍正常走普通用户 / 无感知

✅ 次选：接入场景隔离（旧版无全局开关，或需精细化控制）

1）新建「MAC 认证 - 哑终端专属」接入场景

• 场景名：MAC-Only-Dumb-Terminal
• 接入条件（关键）：
  • 接入方式 = MAC 地址认证
  • （可选）绑定该 SSID 的唯一标识：如SSID 名称 = MAC-SSID 或 认证 VLAN = 100
• 保存

2）新建「Portal 认证 - 普通用户」接入场景

• 场景名：Portal-Only-Normal-User
• 接入条件：
  • 接入方式 = Portal 认证
  • 绑定 Portal SSID 标识（如 SSID=Portal-SSID、VLAN=200）
• 保存

3）绑定场景到对应接入服务

• 哑终端 MAC 接入服务：绑定 MAC-Only-Dumb-Terminal 场景
• Portal 接入服务：绑定 Portal-Only-Normal-User 场景
• 效果：MAC 认证请求只匹配哑终端服务 + 场景，Portal 用户库完全不参与匹配

✅ 补充：彻底关掉 Portal 无感知（避免残留绑定）

1. EIA → 自动化 → 用户业务 → 接入参数 → 终端管理参数
2. 关闭：Portal 无感知认证（或删除已绑定的无感知 MAC）
3. 保存

✅ 结论（你直接照做）

• 有全局开关（推荐）：直接勾「MAC 认证仅匹配哑终端库」，一步到位。
• 旧版 / 需隔离：建两个接入场景，分别绑定 MAC/Portal 服务，彻底隔离。
• 最终效果：不在哑终端的 MAC，连 MAC 认证 SSID 直接拒绝，绝不会跑到 Portal 用户库匹配

你遇到的这个问题，确实是EIA平台认证逻辑带来的常见困扰。最推荐的解决方式是开启EIA平台内置的“MAC认证请求仅匹配哑终端用户库”这个全局开关，它能一键、彻底地解决该问题。

 问题根源与推荐方案分析

首先，问题的根源在于EIA平台的默认认证查找逻辑。当一个MAC地址请求认证时，EIA会在所有用户库中进行查找，这就解释了为什么已通过Portal认证的终端在切换到MAC认证网络时，能直接匹配到之前的Portal账号而非哑终端账号。

针对这个机制，主要有两种解决方案。我为你梳理了它们的核心区别，方便你决策：

 补充建议与最终效果

如果你的网络曾开启过“Portal无感知认证”功能，终端在通过Portal认证后，其MAC地址会被自动绑定到普通用户账号，这可能会干扰后续的排查或策略切换。为彻底杜绝此类串访风险，建议在 “自动化” > “用户业务” > “接入参数” > “终端管理参数” 路径下，关闭“Portal无感知认证” 功能或手动清除已有的无感知绑定条目。

无论你选择哪种方案，最终都能实现：只有在EIA哑终端用户列表中明确添加了MAC地址的设备，才能通过MAC认证接入网络。任何未在哑终端列表的MAC地址（包括曾经Portal认证过的设备）都会被直接拒绝，并且绝不会错误匹配到Portal用户库-17。