为什么某些 AD/LDAP 集成应用程序需要服务帐户，而其他应用程序则不需要？
我正在构建一个简单的 LDAP Flask 集成 api，通常我会看到以下模式：
# Base
app.config["LDAP_HOST"] = os.getenv("LDAP_HOST")
app.config["LDAP_DOMAIN_NAME"] = os.getenv("LDAP_DOMAIN_NAME")
app.config["LDAP_USERNAME"] = os.getenv("LDAP_USERNAME")
app.config["LDAP_PASSWORD"] = os.getenv("LDAP_PASSWORD")
@auth.verify_password
def verify_password(username, password):
if session.get('username'):
return True
if not username and not password:
return False
try:
# Simple LDAP wrapper
sad = Simple_AD(
server_name = app.config["LDAP_HOST"] ,
# Option 1 - With dedicated service account
username = app.config["LDAP_USERNAME"],
password = app.config["LDAP_PASSWORD"],
# Option 2 - Binding with the user's actual creds provided in the basic auth request itself
username = username
password = password
)
ldap_user = sad.get_aduser(samaccountname=username)
if ldap_user:
session['username'] = username
return True
except:
return False
我的问题是为什么某些应用程序在进行 LDAP 绑定时使用专用服务帐户，而我可以轻松地与实际用户提供的凭据进行绑定？
我可以理解一些边缘情况限制，例如：
- 用户没有对目录的完全访问权限
- AD/LDAP 审核日志将显示用户而不是服务帐户
除了这些小事情之外，是否有理由为 ldap 维护专用的用户名/密码束缚自己？
我通常在这里追求的是不必维护另一个服务帐户。
谢谢！
I'm building a simple LDAP flask integrated api, and typically I've seen the pattern of:
# Base
app.config["LDAP_HOST"] = os.getenv("LDAP_HOST")
app.config["LDAP_DOMAIN_NAME"] = os.getenv("LDAP_DOMAIN_NAME")
app.config["LDAP_USERNAME"] = os.getenv("LDAP_USERNAME")
app.config["LDAP_PASSWORD"] = os.getenv("LDAP_PASSWORD")
@auth.verify_password
def verify_password(username, password):
if session.get('username'):
return True
if not username and not password:
return False
try:
# Simple LDAP wrapper
sad = Simple_AD(
server_name = app.config["LDAP_HOST"] ,
# Option 1 - With dedicated service account
username = app.config["LDAP_USERNAME"],
password = app.config["LDAP_PASSWORD"],
# Option 2 - Binding with the user's actual creds provided in the basic auth request itself
username = username
password = password
)
ldap_user = sad.get_aduser(samaccountname=username)
if ldap_user:
session['username'] = username
return True
except:
return False
My question is why do some applications use a dedicated service account when doing the LDAP bind, when I can easily bind with the actual user's provided credentials?
I can understand some edge case limitations like:
- User doesn't have full access to the directory
- AD/LDAP audit logs will show user instead of service account
Besides these minor things, is there a reason to maintain a dedicated username/password JUST for ldap binding itself?
Not having to maintain ANOTHER service account is generally what I'd be after here.
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
一般来说，为了绑定到 LDAP，您需要一个 DN，而不是普通的用户名。当用户帐户分布在不同的 OU 中时，根据普通用户名猜测实际 DN 可能并非易事，并且搜索 LDAP 可能需要对其进行身份验证（如 AD 的情况）。由于用户倾向于以用户名身份登录，而不是CN=username,OU=usersDepartment,DC=domain,DC=com，应用程序可能首先使用自己的服务帐户调用 LDAP 搜索来查找用户名的 DN，然后将其用于绑定。
Active Directory 还允许您使用 userPrincipalName 而不是 DN 进行绑定，因此尝试绑定为 [电子邮件受保护]而不是用户名。可以指示用户以这种方式登录，或者应用程序可以在绑定尝试时添加 @domain.com 部分（如果可行）。
应用程序可能需要使用自己的服务帐户的另一种情况是当用户的密码不可用并且应用程序仍然需要从 LDAP 读取一些用户信息时。常见情况是在某些后台进程中获取信息（当当前用户没有登录时），或者当用户使用应用程序特定的令牌或 API 密钥而不是 LDAP 密码对应用程序进行身份验证时；应用程序可能希望在此类访问时验证用户的组成员身份，为此，它需要拥有自己的一组凭据，因为用户提供的身份验证仅适用于应用程序本身，而不适用于 LDAP 服务器。
In general, in order to bind to LDAP you would need a DN, not a plain username. When user accounts are distributed among different OUs, it may not be trivial to guess what is the actual DN based on plain username, and searching LDAP may require authentication on its own (as in case of AD). Since users tend to log in as username, not as CN=username,OU=usersDepartment,DC=domain,DC=com, application may use its own service account to first invoke LDAP search to find a DN for username, which will then be used to bind.
Active Directory will let you also bind using userPrincipalName instead of DN, so it might be helpful to attempt to bind as [email protected] instead of username. Either users can be instructed to log in this way or the application can add @domain.com part upon binding attempt if feasible.
The other case when application might need to use its own service account would be when the user's password is not available and the application still needs to read some user information from LDAP. Common case would be getting information in some background process (when no current user is logged in) or when the user authenticates to the application using application-specific token or API key instead of LDAP password; the application may want to verify e.g. user's group membership upon such access and for that it would need to have its own set of credentials, since user's provided authentication would only be good for the application itself and not for LDAP server.