ldap通过java检查用户名密码组合
要使用 ldap 测试用户名-密码组合,我执行以下操作
- 连接到 ldap 服务器,
- ,使用主用户帐户搜索用户
- 以检查使用 InitialLdapContext 和给定组合打开另一个连接。
这对我来说效果很好,直到我注意到一些正确的组合不起作用。 (这些大多是不久前创建的帐户)
有没有一种方法可以将用户列在 ldap 目录中,但不允许连接到 ldap 服务器本身?我当前的代码只是使用 masteruser 来搜索要检查的用户名,但最终它只是一个带有用户名-密码组合的新连接来检查。
我是否应该与主用户连接,然后使用用户名-密码组合进行绑定?
这是我检查组合的部分:
static boolean CheckLDAPConnection(String user_name, String user_password) {
try {
Hashtable<String, String> env1 = new Hashtable<String, String>();
env1.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
env1.put(Context.SECURITY_AUTHENTICATION, "simple");
env1.put(Context.SECURITY_PRINCIPAL, user_name);
env1.put(Context.SECURITY_CREDENTIALS, user_password);
env1.put(Context.PROVIDER_URL, ip);
try {
//Connect with ldap
new InitialLdapContext(env1, null);
//Connection succeeded
System.out.println("Connection succeeded!");
return true;
} catch (AuthenticationException e) {
//Connection failed
System.out.println("Connection failed!");
e.printStackTrace();
return false;
}
}
catch (Exception e) {
}
return false;
}
To test a username-password combination with ldap i do the following
- connect to an ldap server with a masteruser account
- search for the user to check
- open another connection by using InitialLdapContext and the given combination.
This works fine for me till i noticed that some correct combinations wont work. (these are mostly accounts which were created short time ago)
Is there a way a user is listed in a ldap directory but isnt allowed to connect to the ldap server itself?! My current code just uses the masteruser to search for the username to check, but in the end its just a new connection with the username-password combination to check.
Should i possibly connect with the masteruser and then bind with the username-password combination?
this is the part where i check the combination:
static boolean CheckLDAPConnection(String user_name, String user_password) {
try {
Hashtable<String, String> env1 = new Hashtable<String, String>();
env1.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
env1.put(Context.SECURITY_AUTHENTICATION, "simple");
env1.put(Context.SECURITY_PRINCIPAL, user_name);
env1.put(Context.SECURITY_CREDENTIALS, user_password);
env1.put(Context.PROVIDER_URL, ip);
try {
//Connect with ldap
new InitialLdapContext(env1, null);
//Connection succeeded
System.out.println("Connection succeeded!");
return true;
} catch (AuthenticationException e) {
//Connection failed
System.out.println("Connection failed!");
e.printStackTrace();
return false;
}
}
catch (Exception e) {
}
return false;
}
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
找到用户的 DN 后,您应该将这些凭据添加到第一个上下文的环境中,然后尝试 reconnect()。这将执行 LDAP 绑定操作。
Once you have found the user's DN you should then add those credentials to the first context's environment and then try a reconnect(). That does the LDAP bind operation.
我们通过直接使用其用户和密码来创建 LDAP 连接来检查 LDAP 的用户和密码。如果可以创建连接,则授权使用。然后在具有相同连接的LDAP中搜索用户权限(如果没有权限则无法访问有关用户的应用程序)。可能不是最好的方法,但在 2 层应用程序中使用主用户创建第一个 LDAP 连接是不可能的(在客户端 GUI 中存储主用户的安全问题),就像我们的例子一样。
也许你可以改变你的方法。
这种方法有一些缺点,如创建新用户,因此需要向 GUI 的“管理员”用户授予 LDAP 的特殊权限以创建其他用户,但不管理 LDAP...
We check user and password against LDAP by using directly its user and password to create the LDAP connection. If connection can be created, use is authorized. Then search for user permission in the LDAP with the same connection (if no permission can not access the application regarding the user is validated). Could not be the best approach but using a master-user to create the first LDAP connection is not possible in a 2-tier application (security concerns about storing the master-user in the client GUI) as in our case.
Maybe you can change your approach.
This approach have some disadvantages, as creating new users, so need to grant special permissions on the LDAP to an "admin" user of the GUI to create other users but don't administrate the LDAP...