客户迁移到 AWS 的意义之一就是包含SSO（单点登录），这是一个非常便利的解决方案。 快速查看（我们已拥有的功能）之后，发现我们能够使用ADFS。客户已经在使用ADFS进行其他服务，因此我们可以跳过说服安全团队的阶段。
花费数天挣扎于Ping Federate的错综复杂后，我们设法打开了SSO，并通过上述的 ADFS得到了一个很不错的重定向循环。 返回的SAML有我们所需的一切，Windchill 的答复是…… “错误500”。
对文档进行更深入的阅读后发现，Windchill支持ADFS SSO，但是基于从ADFS接收到的 SAML以创建新用户却不行。Windchill需要一个用户群来比对，通过使用某种类型的 ldap（使用SSL甚至更好）轮询域控制器提供最为便利。
AWS中的基础设施和客户服务器机房中的域控制器
将控制器公诸于世不太可能被安全团队所接受，但必须以某种方式对其进行轮询。
有必要与VPN客户端连接，并通过具有安全ldap的隧道轮询控制器。遗憾的是这并非易事，因为已经有一些环境在AWS中工作，每个都在不同的VPC中，每个都必须将其查询发送给AD。
这就是生活
有过很多选择（这仅是几个）：
- 使用Transit Gateway并在客户端侧进行NAT
遗憾的是，已经存在的VPC与客户端在其网络中拥有的地址重叠。当然，有办法来克服这种情况，但是我们很急，在全球性组织中折腾路由可能要持续多年的时间
使用客户尚未拥有的网络添加新的VPC，在其余VPC之间进行路由和互联，然后向这个VPC添加VPN网关
一段简短的演示（向客户突显问题），结果是决定创建一个新的VPC，在其他VPC之间执行路由和互联，连接VPN并在其上设置 VPC AWS Directory Service。
这就是我们所做的，不过遗憾的是，事实证明后者的局限性不允许对客户域中的对象进行ldap协议轮询。不可否认地，这是一个小小的挫折……更不用说必须在域之间建立信任关系了。
同时，为了不妨碍其他某些附加工具的开发，我们使用简单的SSH隧道在VPC中设置了标准的Amazon Linux，绕过了一些与AWS中缺少传输 VPC相关的限制。
另一种方法是以只读模式在AWS中公开客户的域控制器。这样的解决方案即使在VPN隧道存在问题的情况下也提供了对应用程序的访问。VPN的搭建异常顺利
我们以为已经很接近了：控制器是只读的，可以通过ldap进行轮询，且一切都进行得很顺利，但是之前同意该选项的客户安全却不行了。好吧，安全有自己的见解，并且不会提供内部CA公钥 — 经典的PKI
某种程度上带着情绪，我们决定适可而止吧。快速回顾一下事态：
- 通过VPN连接到客户网络的VPC – 存在
- 通过ldap的 AD登录数据 – 存在
少了什么？
类似于活动目录代理ldap的某种东西。我们使用VPN设置了VPC，通过ldap查询找到代理，然后顺利地将自身重定向到客户的AD，一切回到本垒。
再进行 5 个小时的测试和TAADAAM — 奏效了。OpenLDAP正在解决问题。在Windchill中进行验证，就这样。OpenLdap的EC2可以用，并且……基本上没什么好做的了。
嗯…将它放入Docker容器中如何？
嗯…在ECS中运行容器怎么样？
嗯…实际上并不需要持久存储，或许Fargate？
构建从LDAP代理到CentOS的容器一共也就是几行。然后可以创建到ECR的一个快速上传、任务的定义及服务。但是如何将流量导向到这项服务？毕竟，每次IP都会不同。也许通过 LoadBalancer？ –不。
定义服务时，可以使用“服务发现”选项，该选项在Route53中创建一个托管区域并更新通向服务的A记录 — 漂亮。现在剩下要做的就是使用Windchill将托管区域固定到VPC，并以在那里注册的名称发起ldaps查询。
最后，（为了之后不必处理），所需要做的只是定义一个简单的健康检查，多亏ECS会在通常一分钟内将一个无法操作的容器换成新的容器。
那么费用多少？
- 使用AWS AD Service 的选项1 – 约为每月90美元
- 使用EC2的选项2，这是只读模式的域控制器 – 约为每月80美元
- 使用Fargate启动模式容器的选项3 – 约为10美元（0.25 CPU，1GB RAM）