From: Nick Couchman <vn...@apache.org> Sent: Wednesday, April 4, 2018 3:52 PM To: user@guacamole.apache.org Subject: Re: LDAP restrictions
> Okay, I'm missing what "flat hierarchy" has to do with anything, here? > Either way, you still need a user account capable of searching for the > users (or a LDAP directory that allows anonymous bind/searches, which > is obviously not ideal), no matter where the users in your tree are located > - flat > or structured - so I'm failing to see how this is relevant. This is the behavior of the LDAP implementation according to the docs. If a bind dn is provided, it can search anywhere beneath the base dn otherwise the users must exist directly beneath the base dn (it constructs the users DN and searches for _that_ object). A better implementation might be to search for _all_ objects with the following LDAP filter (<ldap-username-attribute>=<user supplied logon id>) but there is still another alternative. > I think I understand that you do not want to store the password in the > guacamole.properties file plain-text, While your supporting dialog is right, it's a policy without exception. Since it's not necessary, there cannot be any provisions:( > When you say "some directories" you really mean Active Directory, right? Yup;) > Hmmm...so you're calling an LDAP DN an "unnatural restriction" when, in fact, > it is conforming to the LDAP standard :-), Haha, well sort of. See my rational above (and an alternative below) as it describes the less restrictive approach which facilitates a search. > But, all of that aside, what is the relevance of the username format required > by Guacamole to how the password is stored in the guacamole.properties file? > If we were to allow <login id>@domain.com or domain\<login id>, you'd still > have to store the password in the guacamole.properties file in plaintext, no? > How does allowing those and not requiring the DN syntax impact security or > storage of passwords? For all cases where a bind DN is not desired, then in the cases where the DSA is not lenient about the bind dn format (all but AD etc) your format pattern *will* have to be a full DN with the user logon id inserted, but for the other cases where flexibility exists (AD), we can facilitate a common bind format pattern which enumerates a user in any location in the directory tree. > I must be missing some detail about your environment or what you're trying > to accomplish, here - can you fill in the gaps in my understanding? All this is a result of the lack of ability to supply credentials _at_ connection instantiation time. We could live with the users all being direct descendants of the base dn. However, as the users have to logon with their primary IDs for those connections which need that credential _and_ logon as elevated secondary IDs which do not exist in the same directory tree. Thanks a lot for detailed responses Nick, your time is greatly appreciated. jlc
