记一次想当然的提案的终结
时间：2019.8-10月
1.1 背景
最近了解到一位IT客户的内部要求——将独立重复工作尽量向专业共享服务台转交。
客户IT架构上，总部使用父域，十几个分支子公司使用子域，各子域是分支公司独立管理的，每个子域服务的AD用户数都相当可观。
由此想到，关于重置AD用户密码的业务是否可进行转交。因为用户因忘记密码、尝试错误次数过多或未按安全策略要求在期限内修改密码导致账户被锁定，向IT管理员提出重置密码的需求，是常见现象。这部分业务无技术含量可言，符合客户内部对于服务台的职责定位。
1.2 调研结论
* 向服务台交接业务需要开放网络权限，其中涉及139、445等高危端口，存在信息安全风险。
* 从客户ITIL系统抓取了最近3个月的数据，发现重置密码的业务量很低，平均每个分支公司每个月不到2次。于是各子公司还是集体倾向于维持现状自主维护。
1.3 感想
1、本案例是典型的在用户没提出需求的时候，自己发掘需求，进而提案。这样就注定了整个过程的低效。
2、本提案的终止与信息安全和管理模式有关，但最后回归需求，才发现原来用户没有感觉到足够的痛。因为没有痛点，所以没有动力。
3、对此业务的完美解决方案是实现用户自助重置密码平台。当然资源是否会为此投入，仍然取决于需求。
2.1 技术实现条件
软件层：
服务台是面向整个企业的团队，作为分支公司的IT管理员，自然不愿意服务台人员权限过大，从而产生风险操作。关于这点，我们可以在AD的OU上启用委派功能，仅勾选重置密码操作，实现权限最小化需求。
本案例中，我们需要在各分支公司放置用户账户的OU上设置委派，将被委派方设置为服务台员工的AD账号（父域）即可。
网络层：
服务台工作人员操作时，需要能够在管理控制台界面中切换到子域。这样才可以在通过在目标账户上右键，选择重置密码。若他们使用的电脑到父域、子域的各DC（Domain controller）之间未开通必要的网络权限，会出现无法读取OU的情况，从而无法完成重置。
根据已有经验，必要开通的网络端口如下：
TCP：135/445/389/88/10-12 UDP：389
其中445是高危端口，这也成为各分支公司考量的关键因素。
2.2 一个优化方案
为了尽量减小开放网络端口带来的风险，提出一种设想，如下图。
上方红色虚线表示，从服务台操作主机直接开通到所有子域DC的必要网络端口。（服务台操作主机为办公笔记本）
下方蓝色实现表示，各分支公司在自己的DMZ区域建立一个操作机作为跳板机，服务台只能通过修改过的远程端口来访问它，通过它再去打开AD管理控制台，进行重置密码操作。
在下面这个方案中，445高危端口的开放是在分支公司内部，从集团到分支公司只有修改过端口的远程桌面端口。分支公司操作机专机专用，同时安装server版操作系统，相比于服务台使用的普通办公电脑安全性更高。
但不可否认的是，各分支机构DC和服务台的办公电脑之间，还是新建立了联系，而这种联系可能会被利用进行无意识或有意识的信息安全攻击。
后续发展是，我申请获取了三个月以来历史服务数据，筛选计算出重置密码的工单量，发给各分支公司的IT部门的leader参考，得到了一开始所写的结论。
