guacamole-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Couchman <>
Subject Re: LDAP restrictions
Date Thu, 05 Apr 2018 09:00:53 GMT
Replied to myself before seeing this one, but will respond inline, here,

On Wed, Apr 4, 2018 at 6:15 PM, Joseph L. Casale <>

> From: Nick Couchman <>
> Sent: Wednesday, April 4, 2018 3:52 PM
> To:
> 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.

Yeah, if I had thought about it for 5 more minutes before clicking send, I
would have seen this :-).

> > I think I understand that you do not want to store the password in the
> > 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:(

Got it, that makes sense.

> > When you say "some directories" you really mean Active Directory, right?
> Yup;)
> > 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
> file?
> > If we were to allow <login id> or domain\<login id>,  you'd
> still
> > have to store the password in the 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'll just reiterate what I already said in the previous e-mail - go ahead
and file a JIRA issue for this and we can take a look at the code and see
if there's a relatively easy way to allow the contextless logins with the
client.  I'm not certain how easy this will be - the current LDAP API
that's used by the client is the old Novell JLDAP one (it's in the process
of being switched over to the new Apache one), so I'm not sure what the API
will actually allow to be used as a LDAP username, but it's worth a shot.

> > 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.

Personally I'm not a fan of "flat" LDAP trees - I think one of the reasons
to do LDAP-based authentication, in whatever directory, is so that you can
organize your tree using the various objects provided by the directory.
So, I definitely understand not wanting to flatten everything.  If you have
enough control over your LDAP tree that you could create an OU and alias
everyone, then this might give you a work-around in the interim until we
sort out either secure password storage or contextless LDAP logins.

Aside from the JIRA issue about contextless logins, if you have suggestions
about how to more securely store the password for an LDAP search bind DN,
you could file a JIRA issue for that, as well.


View raw message