Advanced LDAP Support
Plastic currently only supports basic LDAP integration.
In real-world scenarios, things aren't as clear cut and simple.
I propose extending LDAP support in the following ways:
- Support secure LDAP (LDAPs). Including self-signed certificates on the LDAPs server.
- Ability to specify Root DN.
- Ability to specify User search Base.
- Ability to specify User search filter (ie, something like sAMAccountName={0}).
- Ability to Specify Group Search Base.
- Ability to Specify Group Search Filter ((& (cn={0}) (objectclass=group) ))
- Group Membership definitions (can optimize with memberOf property).
- Configurable Local Caching of credentials, TTL etc ....
Hi,
We have released the following task. it’s compatible with the new .NET Core Plastic server:
[New] 9.0.16.4227
Server: secure LDAP connections now supported on port 636
We added support to the Plastic server for SSL connections to your LDAP server.
Configure your server (using the “plasticd configure” command, or the web based administration tool) to switch the LDAP port from 389 to 636 to take advantage of a secure connection to LDAP, assuming your LDAP server is configured to support this.
Regards,
Carlos.
-
Hi,
We have released the following task. it's compatible with the new .NET Core Plastic server:
[New] 9.0.16.4227
Server: secure LDAP connections now supported on port 636
We added support to the Plastic server for SSL connections to your LDAP server. Configure your server (using the "plasticd configure" command, or the web based administration tool) to switch the LDAP port from 389 to 636 to take advantage of a secure connection to LDAP, assuming your LDAP server is configured to support this.
Regards,
Carlos.
-
Stuart commented
Plastic is at risk from a corporate security policy without this.
-
Krzysztof commented
+1!
#1-6 are a must have. Without this integrating Plastic with LDAP servers is very problematic for some setups. No support for LDAPS (LDAP Secure) or search filters is just shocking.
-
AndréM commented
LDAPS is very important for us (like HTTPS for everything)
-
Chong Yan commented
#7: I've noticed most LDAP connectors determine group membership by running additional queries after the user login query. This is pretty inefficient. Group membership can be inferred by simply parsing the memberOf property that comes with the login query (This is not standard on all LDAP servers, but tends to be on AD servers by default).
#8: You probably don't want to query the LDAP server repeated for the same user logins. You can cache the credentials locally, and allow for much more responsive logins. The TTL setting allows you to fine tune how long to keep these cached credentials.
-
Hi Chong!
Thank you for the suggestion. Can you please elaborate the point #7 and #8?
Thanks!
-
Michael commented
Excellent idea!
-
Tim commented
+1
-
Anonymous commented
good