ravada
ravada copied to clipboard
UPC
VM Group Access Restriction Does not Work
Describe the bug I have a vm that I have converted into a base. I provided "ldap group" in the "access" part of the restriction. I wanted all the members of the group to have access to that VM. The logged-on user can just login in fine. I believe there is some sort of disconnect in checking the group membership of a user. I am attaching multiple screenshots that shows that user is not a member of any group even though it is.
Could you please look into this and give me any guidance on how to resolve this?
LDAP Successful Test for User.pdf Group Access - for Base VM.pdf LDAP User - Successful Login.pdf List Users of the LDAP Group.pdf Logged in Users shows Group Membership.pdf Users shows no group membership on LDAP side.pdf
I have tried researching the previous issues, but I had no luck finding anything on it. Any help or guidance provided is greatly appreciated! 😊
Also, I tested out this on version 1.4 as well as on version 2.10. I have been running this on Ubuntu 22.04 LTS.
Please let me know if I can provide anything else.
ok, first of all: fantastic bug report. Just FYI you can directly attach images to comments
Anyway I see in "List Users of the LDAP Group" the user is listed, but he can't access the virtual machine. Just a quick check: the machine must be set to public also. Can you check it is ? In the "Admin Tools -> Machines" tab you should see the publick check on.
Hello @frankiejol,
Thank you for your prompt response and taking time to help me with this.
I will make sure to attach files images to comments from next time onwards. I had to retract some of the information before submitting, so my apologies for that.
Lastly, I feel so STUPID and EMBARRASED. 😢🙃 I did checkbox on "public" option, and it is now working as expected. I had forgotten about that when I implemented this project a year ago. I kept thinking that "public" option will allow all logged-in users to have access which I am glad I can restrict to one ldap group.
Again, thank you so much for your time and help on this matter. Please let me know if there is anything I can do to contribute in terms of documentations and such.
Good point, I will add some message when adding access restrictions when the base is not public. Also, you commented recently about AD issues. Honestly I can't figure out what is the problem at first glance. Could it be related to this one ?
Thank you so much!
Yes, it was relating to this issue. We have AD environment that can interact as LDAP environment as well, so we were just hoping to provide access to the VM using a specified group.
Btw, there are two lines we added/modified in the LDAP.pm These are mostly because the script is looking for "OU=group, dc=ab,dc=company,dc=com" In our structure, we have "OU=group,OU=dept,dc=ab,dc=company,dc=com", so it was not able to pass through the entire LDAP directory to find them. I am attaching this screenshot in the hopes that if someone else wants to use it then they can make use of it instead of reinventing it.
The main purpose of the code is to go through all the "dept" OU in your directory and have access to all those groups.
ok ! I will check this code to see how can it be added with a configuration option or something like that.
@rajpatel-msstate what about fixing this with two configuration options ? This way we could fullfill your requirements and allow other environments with similar needs. I think we could add a field to use for the group. Then we need to add a filter. In your case you would configure:
group_field: SamAccountName
group_filter: objectClass=group
This way I could add code to construct a proper search:
my $filter = (&(objectClass=group)(SamAccountName=$name))";
By default group_field would be cn and group_filter empty.
Also, you need a different base for the groups, there is already a configuration parameter for this: groups_base. I think I will allow both "groups_base" and "group_base" and document it properly.
What do you think ?
@frankiejol Thank you for your time. I do like the idea of allowing the option to include environments with other structure, and I do think the option you are describing will work.
As for the groups_base, in our environment it will default to base parameter in LDAP. But I do think it will help those with multiple LDAP environment in a single tree.