Read Only - i.e Remove Custom Actions for certain people

[ccdesktop]

Is there any quick way to point members of a certain AD group to a "Read Only" version of the LS Web page?

i.e. to prevent them from having the custom actions on the side?

We have created quite a few powerful Custom Actions that we probably wouldn't want some staff clicking on, but others would need full access.

Is there any simple way to do this - or will it mean creating our own custom front page?

[wgknowles]

+1 for this feature to be included in a future release.

It would be nice to create Roles (e.g. HelpDesk, Junior Tech, Senior Tech, Domain Admin)
The Custom Actions would change depending which role the user is in.

[frendel]

Just an update. We are currently doing this succesfully. We had it done before but forgot to respond.

Wasn't too hard. In our case, we created 2 extra stored procedures using the same style as listed above. Then went into the actions.aspx page and did the following.

- Make a duplicate of the MM:DataSet
- Rename the CommandText for both to be the 2 different stored procedure names (Web30ActionsBasic & Web30ActionsAdvanced)
- Make sure the parameters are adding @comp and @domain grabbing the proper values
- Rename the 2nd dataset id to something different (in our case, dscomputers2 to be simple)
- Right after the first table (which would be left alone but woul be the basic list) we would add the folowing line/code " <% If dscomputers2.DefaultView.Table.Rows.Count > 0 Then%> " which would check the 2nd dataset if it even has rows. If it doesn't, we don't need to add the 2nd table (advanced actions) but if it does, we would need to add it.
- Add the 2nd table (copy the code of the first table changing the tel to tel2, myrow to myrow2, dscomputers to dscomputer2 in any place it needs for table 2)
- Add the line/code at the very end of the page (right under the </table>) "<% End If%>"

As you can see from the picture below, we also added a row above each table that we use as a header/title for that table. That line of code is as follows.

"<tr><td colspan=2 align=center class="bottom">Basic Actions</td></tr>"

to which we added a new class to ls.css called "bottom" that has the following code which adds the grey line to the bottom of that cell as well as makes the text bold.

".bottom
{
BORDER-bottom: #CCCCCC 1px solid;
font-weight: bold;
}"

To us, it makes it look a bit better as well as keeping the actions a bit seperate. Hope this helps others. See below for result.

[sticky]

I think it's a good idea to be able to hide certain actions from certain users, especially if they're unlikely to be able to do them anyway. It'd avoid the inevitable "why can't I do this?" question. I'll definitely be looking into setting it up something like how frendel has suggested.

On another note, currently all the actions are one big list - it'd be useful if the actions were grouped according to the access rights required on the remote computer to use them, e.g.:

Basic Actions (no remote rights required):

Trigger scan
Ping
Ping (continuous)
Pathping
Traceroute

Advanced Actions (remote rights required):

Remote control
VNC
Remote desktop
Open C$
Open Admin$
Computer management
Event viewer
Remote Registry
Take screenshot
Reboot
Shutdown
Abort shutdown
Computer uptime
Delete old user profiles
Show open files
Remote processes
Who's logged on

Michael

[frendel]

sticky wrote:
I think it's a good idea to be able to hide certain actions from certain users, especially if they're unlikely to be able to do them anyway. It'd avoid the inevitable "why can't I do this?" question. I'll definitely be looking into setting it up something like how frendel has suggested.

On another note, currently all the actions are one big list - it'd be useful if the actions were grouped according to the access rights required on the remote computer to use them, e.g.:

Basic Actions (no remote rights required):

Trigger scan
Ping
Ping (continuous)
Pathping
Traceroute

Advanced Actions (remote rights required):

Remote control
VNC
Remote desktop
Open C$
Open Admin$
Computer management
Event viewer
Remote Registry
Take screenshot
Reboot
Shutdown
Abort shutdown
Computer uptime
Delete old user profiles
Show open files
Remote processes
Who's logged on

Michael

Haven't tried this yet, but it would seem like it would be easy to do. Currently, the Action.aspx page creates a table and fills each row based off the stored procedure ' dbo.Web30Actions '. With a bit of tweaking, you could create a 2nd stored procedure. One with the basic actions and another with the advanced actions. Then in the Actions.aspx, create a 2nd table. The first, loop through the normal one and then the 2nd, loop through the advanced one.

This is a pretty cool idea that I might try out lol

The only thing though is depending how complex you wanted the sorting, you'd either need a pretty complex stored procedure, or you'd need to add another column to the tsysactions table to let that do the filtering.

[Hemoco]

Regardless of the change in the console.
If the user is an administrator on the target computer he will still be able to do all the things that you want to protect.

[frendel]

We wanted to do something similar. We have the website locked down to only members of a certain group. However even with that, there are a few people that we didn't want to have access to view their screen or anything that could pose a security risk of some info (seeing something we aren't supposed to see).

As such, we created 2 columns in the ' tsysactions ' table called 'secure' and 'domain'. The secure (bit) is what tells us if that action is a secure action or an action that anyone can use. Domain (nvarchar(1)) lists a simple letter to describe whether that action is ok for all domains or a specific domain (we have specific actions for some domains)

Once that was setup, we altered the actions aspx page to include 2 variables to pass through to the stored procedure 'web30actions' to find out the computer name and domain of the screen. Once that was done, it was just adding if statements to the stored procedure to filter out what we needed. An example of our new stored procedure...

ALTER PROCEDURE [dbo].[Web30Actions](@comp varchar(300), @domain varchar(80))

AS
/* Default setting */
if @comp = 'it_laptop'
begin
SELECT Description, Action, Icon, confirmation
FROM dbo.tsysactions
WHERE (enabled = 1)
ORDER BY sortorder
end
/* Begin Secure Actions */
else if @comp = 'accounting_main'
begin
SELECT Description, Action, Icon, confirmation
FROM dbo.tsysactions
WHERE (secure = 0) and (enabled = 1) and (domain = 'F') or
(secure = 0) and (enabled = 1) and (domain = 'A') or
(secure = 0) and (enabled = 1) and (domain = 'W')
ORDER BY sortorder
end
/* Linux VNC only */
else if @comp like 'Linux%'
begin
SELECT Description, Action, Icon, confirmation
FROM dbo.tsysactions
WHERE (enabled = 1) and (domain = 'L')
ORDER BY sortorder
end
else
/* Everything else */
begin
SELECT Description, Action, Icon, confirmation
FROM dbo.tsysactions
WHERE (enabled = 1)
ORDER BY sortorder
end

What this shows is basically keeping the original procedure at the top for our it_laptop computer. For our accounting computer, we only show actions that have secure = true, enabled = true, and domain = f (main domain) or secure = false, enabled = true, and domain = a (all) or secure = false, enabled = true, and domain = w (windows). We also have a few linux machines that we sometimes need to remote into so we created a specific action for that to do the VNC with a different port number than standard. So with that one we check for the domain = l (linux) and enabled = true. Which for us is only the one action. The last one is everything else which is the same as the first one just to make sure we don't get rid of it yet we have a good starting point for the if statement.

Might not be exactly what you want to do but it's a different approach if you wanted to make things a bit more secure.

[Hemoco]

All actions are run in the context of the user visiting the webpage.
Simply restrict access on NT security level for these users.