Hi Juan, I found the setting in the file you pointed me to: nsslapd-minssf: 0 I changed it to 1, but as soon as I restart the ipa service with: systemctl restart ipa or reboot it reverts back to 0! Why is this happening? Many thanks! iordan -- The conscious mind has only one thread of execution.

Hi Juan, On Sat, Nov 23, 2013 at 3:03 PM, Juan Hernandez <jhernand@redhat.com> wrote:

Did you change it while the server was running? If so during stop the server will probably overwrite the file. Try to change it after stopping the server:

Yes, it was absolutely because the server was running and was writing out its configuration upon being stopped. In fact modifying the file is not good practice, you may prefer to do it

using LDAP:

I guess this method would not have suffered from the clobbered config file :D. Thanks for the additional tip, I'm quite new to LDAP.

I have just tested this in my local environment and with minssf=1 it works correctly, including the ability to search for users in the LDAP directory from the administration GUI and using those users to log in to both the administration GUI and to the user portal.

I can definitely now confirm that changing minssf to 1 worked around the issue. However, I'm faced with either an issue or a misunderstanding of how things work in oVirt. I was able to add a couple of users to IPA (user A and user B) and then import them with UserRole into oVirt. What is puzzling is that both are able to see(!!) and power on/off(!!!!!) all the machines which were created by and for user admin@internal. Some of these machines are based on the Blank template and some on a different template (if that matters). Thankfully, at least the new users are unable to attach to the console of those machines. When I created a new virtual machine and in the permissions added user A as UserRole, user A now has access to the console of that VM. However, what was again puzzling is that user B can see and power on/off the new virtual machine, but at least cannot attach to the console (consistent with my previous findings). I would have thought that users would "see" and be able to power on/off only their own VMs, and something tells me that this is the way it was intended. So what do you think is broken in my test rig? Thank you very much! iordan -- The conscious mind has only one thread of execution.

On 11/24/2013 01:57 AM, i iordanov wrote:

Hey,

I actually realized that something I wrote is inaccurate.

UserB, who was not granted permission to any VM was actually able to connect to a freshly booted UserA's VM. Subsequently, UserA was unable to connect to "his own VM" anymore, and the error message was:

Operation Failed: [user cannot force reconnect to vm]

When UserB then shut down UserA's VM, UserA was able to power it on and attach to it. Subsequently, UserB was not able to connect to the VM again with the same message UserA was getting (user cannot force connect to vm).

What I expected is that UserB would not see, not be able to power control, and not be able to attach at all to UserA's VM, so this behavior is quite puzzling to me!

Any clarification and help would be appreciated!

Thanks, iordan

Here you are experiencing two security features of the engine. The first one is the multiple level administration (a.k.a. MLA). The engine organizes objets in hierarchy: a set of data centers, then inside each data center a set of clusters, and inside each cluster a set of virtual machines. When you assign a permission to a user or group you in fact assign it to one of these objects, and objects deeper in the tree inherit them. So if you assign the "create vm" permission to user A and the default data center, then that user will have permission to create VMs on any cluster of that data center. I guess that the two users that you initially created had the permission on the default data center or the default cluster, so they have the permissions apply to all the VMs. Try to go to the data center or cluster tabs and see if the users have permissions there, then remove them as needed. The other thing you are experiencing is the prevention of hijacking of the console of a VM. For desktop virtual machines the engine automatically remember who was the last user that connected to the console of the VM, and will not allow connections by other users. This is to protect the console. Imagine that user A opens the console of virtual machine X, then logs in to the operating system and opens its very confidential document in its favorite application. Then user B, tries to access the same console and gains access to the confidential document. To prevent this this console hijacking is disabled by default, in order to hijack the console the virtual machine X has to be first rebooted, because these guarantees that the confidential document isn't available. However, if you need to allow this console hijacking you can use a flag in the "Console" section of the VM properties dialog, click in "Show advanced options" and then you will see a "Advanced parameters" section that contains a "Disable strict user checking" checkbox. Checking that checkbox disables this behavior. Also, you can give the permission to hijack consoles to users editing their roles and adding the action VM -> Administration Operations -> Override opened console session.

On Sat, Nov 23, 2013 at 7:50 PM, i iordanov <iiordanov@gmail.com> wrote:

...

Hi Juan,

On Sat, Nov 23, 2013 at 3:03 PM, Juan Hernandez <jhernand@redhat.com>wrote:

...

Did you change it while the server was running? If so during stop the server will probably overwrite the file. Try to change it after stopping the server:

Yes, it was absolutely because the server was running and was writing out its configuration upon being stopped.

In fact modifying the file is not good practice, you may prefer to do it

...

using LDAP:

I guess this method would not have suffered from the clobbered config file :D. Thanks for the additional tip, I'm quite new to LDAP.

...

I have just tested this in my local environment and with minssf=1 it works correctly, including the ability to search for users in the LDAP directory from the administration GUI and using those users to log in to both the administration GUI and to the user portal.

I can definitely now confirm that changing minssf to 1 worked around the issue.

However, I'm faced with either an issue or a misunderstanding of how things work in oVirt. I was able to add a couple of users to IPA (user A and user B) and then import them with UserRole into oVirt. What is puzzling is that both are able to see(!!) and power on/off(!!!!!) all the machines which were created by and for user admin@internal. Some of these machines are based on the Blank template and some on a different template (if that matters). Thankfully, at least the new users are unable to attach to the console of those machines.

When I created a new virtual machine and in the permissions added user A as UserRole, user A now has access to the console of that VM. However, what was again puzzling is that user B can see and power on/off the new virtual machine, but at least cannot attach to the console (consistent with my previous findings).

I would have thought that users would "see" and be able to power on/off only their own VMs, and something tells me that this is the way it was intended. So what do you think is broken in my test rig?

Thank you very much! iordan

-- The conscious mind has only one thread of execution.

-- Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3ºD, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.

On Nov 24, 2013 5:08 PM, "i iordanov" <iiordanov@gmail.com> wrote:

Hi Juan,

Thanks for your suggestions!

On Sun, Nov 24, 2013 at 5:36 AM, Juan Hernandez <jhernand@redhat.com>

...

Here you are experiencing two security features of the engine. The first one is the multiple level administration (a.k.a. MLA). The engine organizes objets in hierarchy: a set of data centers, then inside each data center a set of clusters, and inside each cluster a set of virtual machines. When you assign a permission to a user or group you in fact assign it to one of these objects, and objects deeper in the tree inherit them. So if you assign the "create vm" permission to user A and the default data center, then that user will have permission to create VMs on any cluster of that data center. I guess that the two users that you initially created had the permission on the default data center or the default cluster, so they have the permissions apply to all the VMs. Try to go to the data center or cluster tabs and see if the users have permissions there, then remove them as needed.

When I looked at the Data Centers and Clusters tabs and examined the

wrote: permissions given to the users, UserA and UserB have UserRole permissions granted on both the default data center and the default cluster. Moreover, I am unable to remove them, as the "Remove" selection is always grayed out.

Furthermore, examining the permissions on UserA's VM, I can see that only

UserA has been granted UseRole permission on it. No other user is mentioned.

So do the UserRole permissions granted to UserA and UserB in the Data

Center and Cluster explain the fact that they can see and attach to "other people's VM's"?

If so, do I have to take the data center and cluster down to remove the

UserRole permissions for the users? Also, how could I prevent this permission from getting added to the Data Center and Cluster automatically? I haven't added it myself and it says that it's an inherited permission (System). You probably added the user role to the user from the users tab, rather than just adding at vm level . You don't need to add the user first.

...

The other thing you are experiencing is the prevention of hijacking of the console of a VM.

Yes, I understand. I remember seeing the option you mention when

creating/editing VMs. I mentioned this more as a way to explain why UserB was initially not able to connect to UserA's VM where in fact, it was possible upon a clean boot.

Any additional help is appreciated!

iordan

-- The conscious mind has only one thread of execution.

_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users