By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement . We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

堡垒机一般都用于管理重要的隔离区资产，所以和域控、认证服务器一样都是高价值目标。在使用域控登陆jumpserver的时候一般会要求开启MFA，所以即使三方认证的服务器沦陷，已有账号也没办法轻易登录堡垒机。但LDAP里有一个例外，那就是新用户可以直接绑定新的TOTP。假设恶意用户攻破LDAP并在堡垒机OU中添加新用户，那么如果jumpserver开启了自动导入用户的选项，新用户将可以直接绑定TOTP并访问相关资源。

但如果关闭用户同步功能，那么LDAP上对用户做的所有更改都没办法第一时间同步到jumpserver，同样会造成权限不符合预期的风险。

解决的思路也有一个，那就是允许管理员默认禁止新导入用户的登录权限：

通过域控控制账号是否激活的意义不大，因为这完全可以通过用户过滤器配置完成。

默认禁用自动导入用户的本意是为了阻止LDAP直接激活/新建一个不受MFA保护的账户，从而在LDAP服务器被攻陷的情况下用MFA拦住恶意用户，在jumpserver上多上一道保险。把是否激活的选项直接绑定到LDAP上肯定是可以的，但那样和使用用户过滤器的效果是一样的，jumpserver账号的安全性依然完全依赖域控来提供。

虽然绑定域控操作是最方便的，但这里目的并不是绑定域控，而是 提供可选的风险隔离 。我们设想一下以下场景：

恶意用户渗透进内网，发现了jumpserver，但暂时没有发现可以利用的安全漏洞。

恶意用户渗透进域控，发现jumpserver是使用LDAP绑定域控的，于是恶意用户在域控上修改了jumpserver管理员账户的密码并直接渗透进jumpserver下的资产。

当管理员强制开启MFA时，恶意用户在登录jumpserver时因为缺少TOTP验证码，发现依然不能登陆jumpserver。

恶意用户又发现一个新漏洞：新建的jumpserver用户首次登陆时可以直接绑定TOTP，于是新建了一个用户并加入到Jumpserver的OU。在首次使用新用户名和新密码登录时绑定了自己的TOTP，又顺利渗透进了jumpserver。

回到本issue，已绑定FMA的jumpserver账号是受到Jumpserver保护的。但它没办法保护在域控上新创建的账号，除非新导入的用户只能由管理员手动激活。如果新用户需要管理员登录jumpserver激活后才有机会绑定MFA(而管理员自己也需要MFA才能登录)，那么恶意用户无法通过LDAP获取任何一个新的或旧的jumpserver账号的控制权。

域控固然是安全的重中之重，但同样也是恶意用户的高价值目标，属于攻防的关键节点。堡垒机也是如此，这个可选的安全策略只是试图利用较小的代价阻止最不利情况下的风险扩散。

你的需求我大概理解了，也比较认同，但是如果只在 LDAP 端做处理，那也只能限制对接了 LDAP 方式的认证。

JumpServer 的其他认证还包括：OIDC、OAuth2、CAS 等等。（企业版功能）

目前对于用户登录有 ACL 的控制。
可以创建一个用户登录规则，设置 首次登录的用户 为拒绝。（或者企业版中设置动作为 复核 ）
属性匹配中， 首次登录的用户 目前还不支持设置，当前可以设置 用户名 、 用户组 等。

这样的策略，可以覆盖所有认证方式的用户。

你确认一下，是否可以解决你的需求，如果可以的话，我们会考虑增加 首次登录的用户 属性。

我又看了一遍你提供的解决方案，可能可以达到过滤恶意创建的用户的效果，不过我不知道用户要从首次登录转化为非首次登录的条件是什么。如果首次登陆验证完密码或绑定过MFA就撤掉用户首次登录的标签，那么恶意账号只要连续登录两次就可以进来了。但如果首次登录验证完密码不撤除这个标签，那么用户可能永远都无法完成首次登录。所以看起来好像还是很难绕过”管理员确认“这个坎。

所以下面的选项就会变成”拒绝/接受/通知/等待审批“，这种情况下如果触发审批的前置条件是”用户登陆并绑定MFA“，那和上面的可选策略就有点类似了，但逻辑上显然更符合当前的产品逻辑。