On Tue, Mar 19, 2019 at 12:01 PM Fertig, Brian <brian.fer...@philips.com> wrote:
> Nico, > > I am trying to latter. When a user is trying to log into Guac I want that > users credentials presented to AD to see if they can. If they can then > allow them to login. At least based on the documentation I assume this is > how I have it setup. > > Part of the issue you're running into is that the LDAP authentication module is a bit limited. There's actually a JIRA issue already out there that seeks to loosen up the restrictions a bit, but it hasn't been worked, yet: https://issues.apache.org/jira/browse/GUACAMOLE-536 Basically, right now there are two modes of authentication: - Search & Bind: You specify a bind DN for an account to search the directory, Guacamole searches LDAP for the user that tries to bind as the user that has been located within the tree. So, if you specify, in your guacamole.properties file, ldap-search-bind-dn of "cn=search,ou=accounts,dc=example,dc=com", and you try to log in as "testuser", Guacamole will first bind as the cn=search user, search for "testuser", assuming testuser is found (say, cn=testuser,ou=users,dc=example,dc=com), Guacamole will re-bind as the cn=testuser account using the password specified. - Derive DN: You don't specify the ldap-search-bind-dn, but you do specify ldap-user-base-dn as "ou=users,dc=example,dc=com", then Guacamole derives the DN as cn=<username>,ou=users,dc=example,dc=com and attempts to bind with that password. Using the "testuser" account from before, Guacamole would derive the DN to cn=testuser,ou=users,dc=example,dc=com, and then use the provided password to bind. This mode is really only useful in the situation where you have a flat directory tree where all users (or at least all users that are going to be logging in to Guacamole) are found in the same OU. You can simulate this within your LDAP tree by creating account aliases within a particular OU (ou=Guacamole_Users,dc=example,dc=com) and allowing the Guacamole module to dereference aliases. The JIRA issue above deals specifically with Active Directory-style authentication, where the directory allows you to bind with <username>@<domain> (e.g. testu...@example.com). Hopefully that'll get added at some point, when we have time to work on it. Hopefully this helps. -Nick
