Just upgraded to 10.1 last night and am exploring the WebClient. However, my normal users (which are assigned a custom role) don't see any data in the WebClient like I do (i'm superuser/admin). What privileges must be set in order to allow access to the WebClient?
I've startet my tests with an empty DB and my simple testuser has no problem with the WebClient.
But I don't want give the WebClient to all users. Thus, the question is also: What privileges must be set in order to disallow access to the WebClient? And: Can I hide the client for some users or groups completely?
The WebClient honors the security strings configured for a user in OneClick client. So the user can only see what he has access to. For example Landscape and GC.
Frank_Elliger, I need to check on your question. But wanted to understand more. Why would you want to completely block access to certain users? Who are those users typically?
I have a user that logs into one click and can see his devices and can see the alarms for those devices. Simultaneously pulls up the webclient and there's no data.
as long as the WebClient has only a few functions it's better for me (as administrator and supporter), if I'm able to give the access only to users, which know how to use it and what will not work. This is not a knock-out criterion, but would be helpful.
If this is still an issue I recommend opening a case with Spectrum support
Could you please try to configure the user security string as mentioned:
. Webclient may not be able to show alarms if the Security String is not configured properly for the logged in user. To check this, in OneClick console select the user in the Users tab, click Details tab in the Component Detail, and verify the Security String shown here is same as configured for the devices.
As mentioned before, I know the security strings are setup properly because when the user logs into OneClick, they can see their devices.
I will be opening a case with support.
Same situation on our environment. We could fix it by setting up the "Security string ***" equal to Legacy "SNMP Security String ***,0" for the USER Model
Can you elaborate? You go to the user model and set the legacy snmp security string to be like the security string? Or the other way around? Since we use user groups, we'd do that on the group, i assume?
We have changed all users and the group security to. eg."username SDdeploy" "security string = grpSD" "legacy snmp community string = grpSD,0"
For all users and for the group, the security string is "ADMIN" and the legacy SNMP Community string is "ADMIN,0". Are you saying to get yours to work, you specify some other string besides "ADMIN"? We understood the security string on the user to be what determines what other user can modify this user. We don't want anyone other than admins to be able to modify these users.
Yes, we have more one security string for different usergroups with different privileges in a distributet environment. The security is role defined (eg OperatorRW) for the group and you can allow or deny access for user administration. We have created many different roles (eg. view only, modelling, using SANM ...) These roles are attched to a group or for users only. This means some user within a group get more privileges. And yes, all these user have access to the webclient and get the alerts defined by the security string.
Ok. Perhaps that will resonate with someone else. Being a noob to Spectrum, i didn't catch very much of that. I'm opening a support case now.
We also had the same problem while accessing the web client. We opened a support ticket and the result was:
The user must have (read) access to his own user model!
So we changed the security string for the user itself (component details of the user) to something new like 'webaccess' and in access tab we give them a security community 'webaccess' with a read-only role. Now it is working.
When you use the default configuration (security string ADMIN for a user model) it will work if the user has also the security community ADMIN assigned with at least read access.
That is silly! I can't believe this product is this mature and the developers are making a boneheaded move like this. We obviously don't want to grant the ADMIN security community to all users. We also may have a security problem with giving users RO access to other user models. That means, in order to implement a similar workaround, we may have to have individual security communities for each user, which will be a nightmare to manage.
We will likely put the webclient on hold if this is the real reason why it isn't working. Too bad, we were pretty excited to see the first attempt by CA to go fully web based.
Turns out this is our solution as well. We were on a meeting with some of the architects and we brought this up along with some other problems. They mentioned how users have to have access to their own model. Here are our requirements and how we did it:
So, we set the security string of the user to "WebClient" and granted access to "WebClient" from the group level with the same role.
We had a call with Stuart_Weenig and got this working. But for the sake of larger audience we would like to explain that having same security community will not give access to operators to view or edit other users with same security community. So we should not have a problem.
Hope this helps.
New development folks: turns out if you only grant RO access to a user's own user model, then he can access the data in the web client but he can't save preferences. In order to save preferences, the user must have RW access to his own model. This was our experience. Can anyone else out there confirm? HansJK ?
Yes, I can confirm this. I tested some of the model privileges and it seems that the user must have the 'Model Write-Model Notes' privilege for saving the preferences.
In Spectrum 10.2 below prerequisites are NOT needed for alarms to show & to save preferences in Webclient :
1)The user must have (read) access to his own user model!
2)user must have the 'Model Write-Model Notes' privilege for saving the preferences.
Request to check in 10.2 .