企业官网建设流程全解析

简介：SANGFOR_ACSG_v12.0.25用户自注册与自管理配置指导是一份面向深信服ACSG系统管理员、网络安全专业人员及IT运维团队的官方配置文档，主要解决v12.0.25版本中用户自助注册、终端注册及用户信息自管理的落地配置问题。资源为单个PDF文件，压缩包约1.97MB，便于下载后直接查阅或打印。内容按介绍、概况、使用方法三章组织，其中使用方法部分详细展开前提条件、配置入口，以及账号注册的适用场景、支持的认证方法与具体配置步骤，并延伸至终端注册和用户信息自管理等实操环节。文档还涵盖本地认证、LDAP认证、RADIUS认证等常见接入方式，可帮助管理员根据企业实际环境选择策略。对于需要在新员工入职、外部合作伙伴接入等场景下开放自助入网能力的网络管理员，可直接对照完成策略配置与权限划分；截至页面统计，已有91人学习下载，适合具备一定ACSG设备基础、希望系统掌握用户自注册与自管理配置要点的技术人员参考。

1. 从管理员手动建号到用户自助：自注册能省下多少事

提到 Sangfor（深信服）这个名字，不少网管的第一反应是“电脑上那个怎么也删不掉的客户端”；但在企业网络里，Sangfor AC 是一台上网行为管理设备。而这次要拆的这份《SANGFOR_ACSG_v12.0.25_用户自注册与自管理配置指导》，解决的核心问题恰好相反——不是删不掉，而是管不过来。传统模式下，每个上网账号都要管理员手动创建，员工换手机号、调部门、离职复职，信息全靠人工同步，既慢又容易错。自注册与自管理把“录入信息”这件小事交给用户自己，管理员只需要在审批列表里点通过或拒绝，账号和终端信息由用户自行维护。这份 20 页的配置指导适合正在用或准备用深信服 AC 做上网认证的网管、IT 运维和一线技术支持人员，看完能直接照着配。

2. 先看清能力边界：哪些认证支持自注册，哪些不支持

自注册功能不是所有认证方式都能用的。配置前如果不先确认这一点，后面大概率会在认证策略页面里对着灰色按钮发呆。这一章先把支持矩阵和背后的原因讲清楚，再落到配置入口。

2.1 自注册支持矩阵：一张表看清边界

文档里写得非常明确，支持面其实很窄，分三类就能记住：

解读一下这张表。账号自注册只挂在“密码认证”这类认证策略下，终端自注册只挂在“不需要认证”这类策略下。换句话说，你想让用户自己注册账号，就必须走密码认证的通道；你想让终端先登记再上网，就必须走不需要认证的通道。两者不在同一套策略里生效，也没有互相替代的关系。至于 LDAP、RADIUS 或者任何自定义认证服务器，文档原文说得很直接——都不支持自注册，选了不支持的认证服务器，自注册功能会变灰。这个“变灰”是个很直观的信号，配置时一旦发现按钮点不了，先回头检查认证服务器选的是什么。

2.2 为什么 LDAP、RADIUS 不支持：用户源不在 AC 手里

理解了支持矩阵之后，自然会问一句：为什么本地密码认证和微信/短信快捷登录能注册，LDAP 和 RADIUS 就不行？这要从自注册的本质说起。自注册做的事情是在 AC 本地用户库里新建一条账号记录，并把这条记录和注册时填写的绑定信息（手机号、邮箱）关联起来。本地密码认证的用户源本来就在 AC 上，往本地库里插入一条数据，AC 自己就能闭环完成。外部密码认证里的微信/短信快捷登录，表面上走的是外部认证服务，但最终也会在 AC 侧落地一个可识别的账号或绑定关系，所以同样具备注册条件。

LDAP、RADIUS 这类外部认证则完全不同。用户源存在第三方系统里，AC 只负责把认证请求转发出去，自身并不持有用户数据。当用户提交“注册”请求时，AC 没有能力在远端用户库里创建账号，也没法保证注册信息能同步回第三方。如果硬要支持，要么 LDAP 侧开放写权限，要么 RADIUS 协议里加私有属性，这在真实网络环境里几乎不可行。所以文档直接把这条路径封死了，从产品侧看属于合理的设计取舍。作为配置人员，不用在这个问题上纠结，记住结论就行：需要自注册，账号就走本地或外接密码认证，终端就走不需要认证。

2.3 配置入口：三条路径和“提前定义”的思路

配置入口在控制台里分布在两个区域。一个是“用户认证与管理 → 认证策略”下，分别对应“不需要认证”和“密码认证”两种策略；另一个是“用户认证与管理 → 用户自服务 → 用户自注册”，这里集中管理注册表单和审批规则。具体入口如下：

• 用户认证与管理 → 认证策略 → 不需要认证 → 自注册获取
• 用户认证与管理 → 认证策略 → 密码认证 → 启用自注册
• 用户认证与管理 → 用户自服务 → 用户自注册

配置思路有两种。第一种是配置认证策略时，逐一把自注册相关选项配好，适合认证策略少、现场只跑一种认证模式的场景。第二种是提前在“用户自服务 → 用户自注册”里把注册内容、绑定方式、审批规则定义好，再到认证策略里直接引用。官方文档的示例采用的是“提前定义、策略引用”的方式，我也推荐这么干。因为一台 AC 上往往不止一条认证策略，提前定义一次，后面所有策略引用同一份注册配置，后续要改表单字段或者审批规则时只改一处，不会出现不同策略下注册表单不一致的尴尬。新配现场如果直接上手第二种思路，后面维护会轻松很多。

2.4 注册数据流：注册请求提交后去了哪里

搞清楚数据流，排错时才知道去哪儿看。账号注册提交后，AC 实际做了两件事：一是在本地用户库创建一条用户记录，记录所属组、绑定方式、注册时填写的扩展字段和账号过期时间；二是根据审批设置决定这条记录的初始状态。免审批时记录直接生效，用户马上能用；需要审批时记录处于“待审批”状态，不会出现在可认证的账号列表里。终端注册的数据流类似，但落地的是一条终端记录，AC 将终端 MAC 地址和注册时填写的使用人信息绑定，形成一条“这台设备是谁在用”的关联。免审批则放行，需要审批则等待管理员在审批列表里操作。理解了这两条数据流，后面遇到“注册了但看不见用户”“终端注册后列表里没有记录”这类问题，排查方向就清晰了——不是策略没生效，而是记录状态还卡在审批环节。

3. 配置账号自注册：注册内容、绑定方式与审批的三层设置

这一章是全文的核心，账号自注册从“用户自服务”里的表单定义，到认证策略的引用，再到用户侧的实际效果，每一步都有关键参数。配的时候按三层走：先定义注册内容，再配绑定和审批，最后挂到认证策略上。

3.1 注册内容项怎么设计：字段、默认值与必填

在“用户自服务 → 用户自注册 → 新增账号注册”下，第一步要配置的是“注册内容设置”。这里的本质是设计一张注册表单，类比一下就是注册论坛账号时要求填写的那一串信息。常见的内容项有手机号、邮箱、性别、生日等等。每一项有三个属性需要定义：

设计表单有一个原则：最少采集手机号或邮箱，因为后面绑定方式要用；其余信息按管理需求取舍，别把表单做得太长。每多一个必填项，都会增加用户当场放弃注册的概率，尤其是访客和临时人员场景，表单越长流失率越高。如果某个字段只是历史遗留需求，实在不想显示给用户，可以给默认值配一个固定值，让它在后台自动带上。

3.2 绑定方式与所属组：手机号邮箱二选一还是都要

注册内容设置完成后，紧接着是“注册绑定方式”。这里支持手机号绑定和邮箱绑定两种，而且绑定关系直接影响后续的找回密码能力。如果配了手机号绑定，用户后续忘记密码时可以通过手机验证码找回；如果配了邮箱绑定，就走邮箱验证。我一般建议两个都开，给用户留一条备用通道，避免出现“手机号收不到验证码就彻底没法找回密码”的窘境。

再往下是“注册用户所属组”。本地用户注册时可以指定一个具体的所属组，注册成功的账号会落到这个组里。这个组非常关键，因为它决定了账号上线后继承哪些上网权限策略。建议按策略下发的维度去建组，比如“研发部注册用户”“市场部注册用户”，而不是把所有注册账号统一丢进一个“注册用户”组。统一丢进去的后果是，后续想做部门级的上网权限区分时，还得先想办法把用户重新分组，等于给自己埋了个大坑。

3.3 审批设置和高级选项：从通知到过期时间

表单和绑定配好之后，进入审批设置区。这里有两个决策点。第一，自注册输入的内容是否需要审批，由管理员自行决定。需要审批的场景，审批管理员权限最低要给到“审批列表”权限，否则管理员登录控制台后根本看不到待审批的请求，用户那边就会一直卡在“等待审核”状态。第二，审批结果是否通知用户。这个选项可选，但一旦勾选，就依赖短信通知服务器可用。配置前先确认短信平台是通的，否则审批通过或拒绝后用户收不到任何消息，体验会变得很奇怪。

高级设置里还有两项值得注意。一个是账号过期时间可配，这个常用于临时人员或外包人员，比如设置账号三个月后自动失效，到期后不用管理员手动清理。另一个是“账号支持建立用户绑定”，用于把注册账号和已有用户数据关联，适合公司已经有一批存量账号、想让自注册补充到现有账号体系的场景。新部署直接开自注册的现场，这项一般不需要动，保持默认即可。

3.4 认证策略引用：把自注册挂到密码认证上

注册表单和审批规则定义好之后，需要把它们挂到认证策略上才会真正生效。以本地密码认证为例，操作步骤是：

1. 进入“用户认证与管理 → 认证策略”，新增一条认证策略
2. 认证方式选择“密码认证”
3. 认证服务器选择“本地用户认证服务器”
4. 勾选“启用自注册”
5. 自注册方式选择“认证上线的组”
6. 提交策略

第 5 步的“认证上线的组”要单独解释一下。它决定用户通过自注册提交后，账号被放进哪个组织，这个组要和 3.2 里“注册用户所属组”保持一致，否则会出现策略上写的归属和实际归属不一致的问题。如果认证服务器选的是微信/短信快捷登录这类外部密码认证，同样可以勾选启用自注册，差别只在于用户注册后可以选择用微信或短信方式完成绑定登录，而本地密码认证则走常规账号密码。如果在配置时发现“启用自注册”是灰色的，先回 2.2 确认认证服务器有没有选错——选成 LDAP、RADIUS 时这个选项就是灰色的。

3.5 用户视角走一遍：免审批和审批的完整流程

策略生效后，用户侧看到的效果是：访问一个需要认证的网页，被重定向到认证页面，右下角出现“注册”入口。点击注册后，按表单填写并提交。免审批场景下，注册完成后账号立即生效，用户直接用账号密码认证即可。审批场景下，信息提交后显示等待管理员审核，管理员在控制台审批列表里看到待审记录，点“通过”则注册完成，点“拒绝”则注册不通过。如果配置了“审批结果通知用户”，用户会收到一条审批结果通知。

注册不通过时有个细节需要分别看待。如果管理员在拒绝时填写了审批意见，这个意见会记录到审批历史，用户后续用这个账号登录时，会看到“审批拒绝”及原因提示；如果管理员直接拒绝且没填意见，提示更接近“用户名密码错误”，因为该账号根本没有在本地库中建立。所以作为审批管理员，拒绝时顺手填一句原因，能大幅减少后续工单量。注册通过后的账号，如果认证策略里同时开了快捷登录，用户也可以用快捷登录方式完成认证，不必每次输入账号密码。

4. 终端注册与用户信息自管理：不用认证也能录入信息

账号注册解决的是“谁在上网”的问题，终端注册解决的是“这台设备是谁在用”的问题。两者适用场景不同，配置入口不同，但审批和数据落地逻辑高度相似。这一章把终端注册和认证通过后的个人信息自管理放在一起讲，因为它们在实施上经常是配套出现的。

4.1 终端注册和账号注册：一个要账号，一个要终端

账号注册建立在密码认证之上，用户带着账号信息上网，AC 通过账号识别用户身份。终端注册则完全反过来，它挂在“不需要认证”的策略下，终端访问网页时先弹出注册信息收集页，填完直接放行（或审批后放行），整个过程不产生账号，只产生一条终端记录。用一句话概括：账号注册适合需要登录认证的内部网络，终端注册适合访客网络、临时工网络这类原本就不做账号认证、但希望掌握终端使用人信息的场景。

实际部署时经常出现混用。比如办公区走密码认证加账号自注册，访客区走不需要认证加终端自注册，两条策略并存，互不干扰。这也是为什么文档把两种注册机制分开讲，底层逻辑完全不同，不能混为一谈。

4.2 配置终端注册：表单、审批和认证策略两步走

终端注册的配置分两步。第一步，在“用户自服务 → 用户自注册 → 新增终端注册”里定义终端注册表单。审批设置和高级配置与账号注册完全一致，包括是否需要审批、审批结果是否通知、账号过期时间等，这里不再重复。唯一需要注意的是，终端注册表单和账号注册表单是两份独立的表单，字段要按终端场景单独设计，比如“使用人姓名”“所属部门”“终端用途”，别把账号注册的手机号、邮箱字段原样复制过来，终端场景下更需要的是设备归属和使用人信息。

第二步，把终端注册挂到“不需要认证”的策略上。进入“认证策略”，找到那条不需要认证的策略，勾选“自注册获取”，保存。这里没有账号注册那种“认证上线的组”的选项，因为终端注册不产生账号，只产生终端记录，归属由注册时填写的内容决定。

4.3 效果呈现：填完直接上网还是等审批

策略生效后，终端访问网页会被引导到注册信息页。免审批场景下，输入注册信息后直接上网，用户几乎感知不到这是“注册”的过程，顶多以为填了个入网登记表。需要审批的场景下，输入信息后页面会提示等待审批结果，管理员在审批列表通过后，终端下一次访问网络时就能正常上网。

从管理员视角看，审批通过后，就能在用户列表中看到这台终端对应的使用人信息。这对访客网络和临时工网络非常实用，核心诉求不是管控，而是知道“这台设备是谁在用”。出了问题找人的时候，不用再对着 IP 和 MAC 一头雾水。

4.4 跨三层绑定 MAC：这个坑必须在配置前避开

终端注册和账号注册最大的区别，在注册提交那一刻就决定了：终端注册会自动绑定终端的 MAC 地址。这个 MAC 就是后续识别这台终端的唯一凭据。问题来了——如果终端和 AC 之间隔着三层交换机，AC 看到的源 MAC 是网关的 MAC，不是终端真实 MAC。文档原文特别强调：跨三层环境必须开启跨三层识别。没开的话，所有注册终端绑定的是同一个网关 MAC，十几台设备在系统里会显示成同一台，IP 还在反复横跳，完全失去采集意义。

跨三层识别的开启方式通常依赖设备型号和网络拓扑，常见做法是通过 SNMP 读取三层设备的 ARP 表，或者在三层交换机上做端口映射，让 AC 能获取到终端真实 MAC。配置完成后，还要把之前绑定错误的终端记录清理掉，让用户重新提交一次注册。这里有一个容易被忽略的点：开启跨三层识别不会自动纠正历史数据，只对之后的注册生效，所以清理旧记录这步不能省。

4.5 个人信息中心：进入方式与允许修改绑定终端

账号注册和终端注册都完成之后，用户信息自管理是日常运维中最常用到的功能。用户注册时填写的手机号或者邮箱变更了、密码忘了、换了一台电脑，这些都不应该再找管理员。

个人信息中心的访问方式有几种。可以直接访问http://ACIP/homepage/index.html?_FLAG=1，也可以直接访问http://ACIP（80 端口）进入。还有一种方式是利用认证后跳转功能，用户认证成功后自动跳到个人信息中心，这个体验最顺，适合作为默认入口。

在个人信息中心里，用户可以点击“编辑信息”修改注册时填写的资料。绑定终端这一项默认只能查看，用户不能自己改。如果希望用户能处理“换电脑”这类需求，需要到“认证高级选项 → 个人管理中心设置”里勾选“允许修改绑定终端”。勾选后，用户在个人信息中心就能自行解绑旧终端、绑定新终端，省去管理员后台改 MAC 的工作。不过这里也要权衡：开放修改绑定终端意味着用户可以在多台设备间自由切换，如果公司对终端入网有强管控，建议保持默认关闭，只让管理员后台调整。

5. 常见问题与避坑：四条现场踩过的配置误区

配置指导文档最后有一章注意事项，原文只列了四条，但每一条都是现场最容易翻车的地方。这一章把它们展开成完整的踩坑记录，每条按“现象 → 原因 → 解决”来写，方便直接对照排查。

5.1 80 端口变成个人中心：重定向测试方法失效

现象：配好认证策略后，用浏览器访问http://ACIP，本期望看到认证页面，结果打开的是个人信息中心。不少同事会以为认证没生效，反复重启认证服务，甚至重做策略。

原因：v12.0.25 版本已经将 AC 的 80 端口改为个人管理中心页面，不再承担认证重定向入口的职责。这个变更很容易被忽略，因为旧版本的 AC 上 80 端口一直是用来触发认证重定向的。

解决：不要在 80 端口上验证认证重定向。用未认证的终端访问一个 HTTP 网页，观察是否被重定向到认证页面，这才是有意义的测试方式。如果坚持要用 IP 测试，确认访问的是实际认证页面的地址。我第一次配这个功能时，就是光顾着在认证策略里开开关，忽略了 80 端口的变化，结果测试重定向花了一个多小时才反应过来。

5.2 跨三层环境：注册终端全绑到网关 MAC

现象：多台终端通过终端自注册上网，管理员查看在线用户，发现所有终端都归属同一个 MAC 地址，用户信息全部串在一起，看起来“大家都在用同一台设备”。

原因：终端和 AC 之间隔了三层设备，数据包到达 AC 时源 MAC 已经是网关的 MAC。终端注册自动绑定 MAC，绑定的不是真实终端 MAC，而是网关 MAC。

解决：先开启跨三层识别，让 AC 能正确获取终端真实 MAC。然后清理已经注册的终端记录，让用户重新提交一次注册。最后核对注册列表里每台终端的 MAC 是否各不相同。需要特别注意，开启跨三层识别只影响之后的新注册，之前绑定的错误记录不会自动纠正，必须手动清一次。这条在文档注意事项里排得很靠前，现场遇到“终端注册全部堆在同一 MAC”的问题时，优先查这条。

5.3 手机号唯一：重复注册被卡的原因

现象：员工离职后账号被删，新员工入职用同一个手机号注册，提交时报重复注册错误，注册流程被中断。

原因：注册绑定方式里选了手机号绑定后，系统限制一个手机号只能绑定一个账号。手机号成了用户唯一性的约束，重复使用必然冲突。

解决：有两种处理路径。一是管理员在后台把旧账号的绑定关系清理掉，释放这个手机号；二是让用户换一个新的手机号进行注册。如果公司手机号资源紧张且人员流动频繁，建议配置时同时开启手机号和邮箱绑定，给用户多一条注册通道。另外，已注册用户后续换手机号，可以在个人信息中心点“编辑信息”自行修改绑定手机号，不需要重新走一遍注册。

5.4 访客二维码认证：录入信息并不等于自注册

现象：访客二维码认证页面也支持录入信息项，于是有同事把二维码认证当成自注册用，指望这些信息生成账号或终端记录。配置完成后发现，数据根本进不了用户列表，审批通过了也看不到任何用户信息。

原因：访客二维码认证填写的信息，仅用于审批人审核时确认访客身份，不属于自注册，也不会产生账号或终端绑定记录。文档注意事项原文专门点了一句：二维码认证自己支持录入信息项，但不属于自注册。

解决：需要账号或终端记录，就走自注册通道；访客二维码认证的信息只当作审批辅助材料，不要期望它进入用户管理体系。如果访客场景既要收集信息又要留痕，可以同时开终端自注册和访客二维码认证，让访客填一次终端注册表单，审批人再结合二维码里的身份信息做二次确认。

6. 把全链路验证一遍：从注册申请到审批通过的检查清单

配置完成不是终点，验证通过才是。这一章给出一套完整的检查流程，照着走一遍，可以避免“配置看起来都对，上线后用户却注册不了”的尴尬。

6.1 用户侧验证流程

用一台未认证的终端，开浏览器无痕窗口走一遍全流程。先访问一个 HTTP 地址，确认被重定向到认证页面，再确认认证页面右下角有“注册”入口。点击注册，填满必填项，提交。

免审批场景下，提交后直接用新账号密码认证，确认能正常上网。审批场景下，提交后换管理员账号登录控制台，确认审批列表里出现待审记录。这一步缺一不可，尤其是“右下角注册入口是否存在”，很多配置问题在入口阶段就暴露了。

6.2 管理员侧检查清单

上线前逐项确认以下内容，每一项都对应前面章节里讲过的坑：

6.3 先小范围放量再全量上线

配置全部确认后，不要直接在全部终端上放量。先找一台测试终端、一个测试账号走通全部流程，再放给一个部门试用，观察一到两天。这段观察期重点看三个信号：注册按钮是否出现在认证页面、审批列表是否能正常收到待审记录、审批结果通知是否真的能送达。等这些信号都稳定了，再放开全量。放量之后用户遇到的问题，大概率会集中在“账号被拒”和“重复注册”两类，对应的现象和原因在前面第 5 章都能对上。

回到我自己，自注册这个功能第一次配置时的教训还在：忽略 80 端口变化、漏开跨三层识别、表单设计得太长，三个坑逐一踩过。从那以后，每次给 AC 配自注册，我都强制走一遍这份检查清单，先把 80 端口和跨三层识别写在最前面。完整的《SANGFOR_ACSG_v12.0.25_用户自注册与自管理配置指导》PDF 在深信服技术社区（bbs.sangfor.com.cn）可以找到，直接用文档名检索也能下到，20 页的篇幅里截图比文字更直观，建议动手配置前先把“注意事项”那一章读一遍。希望帮到你。

本文还有配套的精品资源，点击获取