Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added support for specifying LDAP UPN in properties file #683

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

agreenbhm
Copy link

Added support for specifying LDAP UPN in properties file. Allows for any user in LDAP (with the corresponding UPN) to authenticate. Removes requirement of users being within same OU for large LDAP deployments.

for any user in LDAP (with the corresponding UPN) to authenticate.
Removes requirement of users being within same OU for large LDAP
deployments.
@necouchman
Copy link
Contributor

@agreenbhm : A couple of notes:

  1. You need to have a Jira issue opened for a pull request, and the PR and commits need to be tagged with the Jira issue.
  2. There's already a Jira issue for this: https://issues.apache.org/jira/browse/GUACAMOLE-536
  3. There's already work being done on this front: GUACAMOLE-536: Implement additional bind types for LDAP #507

@agreenbhm
Copy link
Author

@agreenbhm : A couple of notes:

  1. You need to have a Jira issue opened for a pull request, and the PR and commits need to be tagged with the Jira issue.
  2. There's already a Jira issue for this: https://issues.apache.org/jira/browse/GUACAMOLE-536
  3. There's already work being done on this front: GUACAMOLE-536: Implement additional bind types for LDAP #507

Thanks for the info. Looks like that PR is nearly 2 years old. @necouchman: Given that you are the author of that PR, is there anything more that is needed to be done to get that merged? It looks like the changes I made are pretty similar to the ones you did so I'm not sure why your PR wouldn't be merged yet since it seems functional.

String searchBindLogon;
String searchBindPassword;

if(confService.getUPNDomain() != "" && confService.getUPNDomain() != null){
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The test confService.getUPNDomain() != "" performs a by-reference comparison against the String object for "", not a comparison of the content of those strings. The proper test for whether a String is empty is isEmpty(), however the null check shown here would have to occur first for that call to not throw a NullPointerException in the event the string is indeed null.

Comment on lines +132 to +133
searchBindLogon = username + "@" + confService.getUPNDomain();
searchBindPassword = password;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this should be done. The search bind DN is a very specific thing - it's the service account that Guacamole uses to resolve the DN of a user. It shouldn't be replaced with the user's own account.

If the idea here is to allow logins via UPN and avoid the search bind DN entirely, then the solution would be to allow user authentication to proceed without a user search by directly binding with the provided UPN - essentially an alternative to the direct user mapping already supported.

@mike-jumper
Copy link
Contributor

mike-jumper commented Jan 21, 2022

I'm not sure whether these changes (in spirit) nor GUACAMOLE-536 are actually necessary:

  • The LDAP support does allow for lookup of users based on their UPN. This would involve using userPrincipalName for the username attribute.
  • Multiple LDAP servers are supported via the recently-introduced multi-server LDAP support. Users can be mapped to their relevant LDAP server based on username patterns, and then the search account can narrow that to a specific user once the relevant server is determined.

I know that Active Directory allows for binding with UPNs, and so adding a feature that would tell Guacamole to accept usernames matching that pattern and attempt to bind with those usernames directly would make configuration easier, but I'm not sure that's what these changes or GUACAMOLE-536 are intended to be.

EDIT: Sorry - that should be GUACAMOLE-536*. Copy-pasta of other things I also happen to have open.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants