Re: LDAP restrictions
Replied to myself before seeing this one, but will respond inline, here, too On Wed, Apr 4, 2018 at 6:15 PM, Joseph L. Casale <jcas...@activenetwerx.com> wrote: > 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 (=) > 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 > > 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:( > Got it, that makes sense. > > > 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 @domain.com or domain\, 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'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. https://issues.apache.org/jira/browse/GUACAMOLE -Nick
Re: LDAP restrictions
>
>
> 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?
>
Sorry, I'm being very dense, here, and it just clicked what you're saying.
Your tree is not set up such that you could just specify:
ldap-user-base-dn: ou=users,dc=domain,dc=com
ldap-user-attribute: uid
And then have it automatically do uid={username},ou=users,dc=domain,dc=com
for the bind DN, without having to have a specific account for searching
the tree? And, in Active Directory, in particular, you can bind to the
tree no matter where your user account is located by just binding with {
username}@domain.com or DOMAIN\{username}.
So, based on that, now that my brain has started working, I'd say the
following things:
- This is still a "feature" of Active Directory, and isn't widely-supported
across LDAP directory trees. You're welcome to go to the Apache JIRA page
for Guacamole and file a feature request for this and we'll see if it's
sometihng that can be easily added.
- As I mentioned before, you should be able to create a user account with
fairly limited permissions but still the ability to search the tree for
those users and only read the attributes necessary to allow Guacamole to
work.
- The other option that I've used when hitting this limitation before is to
create a specific ou and alias all of the user accounts that need access to
an application within that OU, thereby creating both the "flat" structure
required for the application to function and also allowing you to continue
to sort the tree as required. So, something like
ou=Guacamole_Users,dc=domain,dc=com and then
uid=user1,ou=Guacamole_Users,dc=domain,dc=com points to
uid=user1,ou=Users,ou=Department,dc=domain,dc=com.
Sorry for the misunderstanding...if I had thought about it for five more
minutes before clicking send, I'd have got it.
-Nick
Re: LDAP restrictions
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 (=) 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 @domain.com or domain\, 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
