I would need to restrict the deletion of a record for system administrator without using any custom code (like javascript, plugin). Can someone please suggest me the possible approaches for this.
I assume you just want to restrict deleting with no condition to check. There seems no logic in this scenario, why would anybody need this to be implemented that too for System Administrator.
Well if it is your ultimate goal then this could be done with below steps,
Create Workflow on delete trigger.
Create step as "Stop Workflow"
Set Status as "Canceled"
Save and Activate the workflow
You can set the custom Message in step parameter "Status Message". This will be visible while deleting a record.
You can't change the system administrator role out of the box. I would suggest the following approach:
Copy the System Administrator role (e.g. System Manager), but remove delete permissions.
Give users your copied System Manager role.
Remove System Administrator role from all but 1 user.
I'm pretty sure there has to be at least 1 account with system administrator role, but at least this way you can restrict delete permissions.
Seriously the problem is not the delete privilege in System Admin role. It’s the problem with system implementation, and power users who don’t know the real power they possess. First of all, System Admin/Customizer should not be given to end users.
Solution is design another Tool admin role(like James said), Assign it & educate the users. Taking out data governance from tool users & keeping it with Dev team is not a good move. If you have Prod support team, then fine.
Learn what different user base needs in day-to-day work, design well like considering user level privileges (they can delete what they create, etc), make use of Dynamics 365 CRM powerful security concepts, approval or layered process with Tool admins or Prod support, even dashboards for junior users, senior users, Audit reports, identifying tool champions for user training & revisiting the security gaps are key steps here.
Also only Read, Append, AppendTo should be given for Master entities (country, state for example), sometimes user will edit/delete the actual data instead of lookup value.
Related
Apologies for the basic question; we're having a spring clean of the office Active Directory and plan to remove a large number of legacy users. Saying good-bye to their email is not a problem, but we have an on-premise Dynamics CRM we occasionally refer to. My question is, will there be any implications for that if I delete a user who might have entered a case?
There is no direct link between CRM on-premise 2011 & Active Directory to pull all users overnight & sync. When you create a new user in CRM by giving domain name, it will verify in AD & pull the details to store in CRM. This will happen on tab out.
So when you delete/disable an AD user it won't flow down in Dynamics. But you have to disable them manually (no delete option available). Before doing that make sure to read these best practices.
Best Practices
Make sure to Re-assign any associated records/activities to another
User or Team before disabling User. If you don’t Re-assign the records
they will still be available, but they will still be assigned to the
disabled user.
It is very important to ensure that there are no Workflows owned by
the User to be disabled. All Published Workflows need to be owned by
an administrative account, not an employee’s account.
There are situations where a User’s account only needs to be disabled
for a short period of time, so records don’t necessarily need to be
Re-assigned. (Example: the User went on vacation for a month). Take
into consideration the User’s privileges for those records. If only
the User can modify that record, then no one will be able to modify
the record, if the owner is disabled.
Read this community thread as well.
My team will develop an internal (known users) application that has an architecture based on Java as front-end and PL/SQL as back-end. So, currently we are thinking in a better solution to manage the user/permissions, and we have two options:
Each user has their own database account, granted with the permissions. Currently the legacy system use this approach and I don't like it because it manages permissions based on database objects' granularity. So, I believe it is a bad choice to have a database connection per user. Can you see more cons here?
Build some tables at database to store the users and theirs permissions/profiles and build a PL/SQL procedure to do the login, generating a token and include a parameter to all others PL/SQL to verify this token and then authorize (or not) the execution.
So, you can ask me: why not just manage your permissions in your web-application? Answer: Those PL/SQL are already done and are used by all legacy systems, and this web-application should behave according it (ie. User permissions should be managed by the PL/SQL and its granularity based in please.)
How do you proceed in this case?
I think using the database's built-in mechanism is always to be preferred over rolling our own. And that applies to logging in users as much as anything else.
The biggest single advantage of dedicated user accounts is that we can link a given session with a named user. Well, yes, duh. But the point is, doing thinks like auditing user activity or tracing a performance issue in some process is way more difficult in web applications with generic accounts.
To address your main objection, we don't have to manage database privileges at the user level. That's why we have roles. For normal users, a role will provide sufficient privileges.
So:
define a set of roles which match the various business jobs your application serves.
grant system and object permissions to those roles; remember that roles can be additive (i.e. we can grant privileges on a role to another role).
grant roles to the users.
Find out more.
I can't find much about this online so I was wondering if someone knew here.
Is SSRS 2005 if a user creates a subscription, will other users be able to view and edit those subsciptions? If not, is it possible to make subsciriptions visible to everyone?
Thanks
Quick answer is no.
Long answer is:
AFAIK, there is no site-wide subscription management functionality. The best you can do within Report Manager is site-wide schedule management, which allows admins to set up schedules at preferred times and let users choose those schedules when creating their subscriptions.
Our solution for controlling/centralising subscriptions was to set up a generic Windows user, log in to Report Manager and use that user to create all subscriptions. This means that all requests for subscriptions go through the IT department (+ or - depends on your situation. We didn't want users creating subscriptions themselves). All users who know the generic username/password can manage subscriptions in one place. Not ideal but it works for us.
Another option is that all the data for subscriptions is held on the Server, either in the Reporting Services database or in the Jobs themselves. If you are brave you can delve in and set up some sort of interface to access this.
This is definitely an area in which I find SSRS lacking.
Update:
You live and learn. I've just found that (provided you have sufficient privileges) if you open a report, then go to the subscriptions tab, you can view and edit any subscriptions that are set up on this report by any user. Still not ideal as you don't get an overview of the subscriptions across the system but better than the bleak picture I painted previously!
I've written an application and I'd like to add a registration key/serial number to it (I'm big on minimum inconvinience - ala #4 at this Eric Sink article). My question is about where to store the "activation" once the application has been registered. As I understand it, I have a trade-off between storing the key in a public place, where all users can read it (but which requires admin rights to save there) and storing a per-user activation (but then each user on the computer will have to activate independantly). That gives me two choices:
Some user, with local admin rights, activates the product. The activation is stored in HKLM, in the program files folder, or somewhere else where all users can read it, and the product is activated for all users.
A user (with or without admin rights) activates the product. The activation is stored somewhere user-centric (per-user app.config, HKCU, etc). The plus is that the user doesn't have to be an admin. The downside is that if there are 6 users who use the computer, each has to activate the product. They can each re-use the same serial, but they still have to enter it.
Is this really the trade-off? If it is, what have others done? As a developer, I'm used to people being a local admin, but in the real-world, I don't expect many of my corporate users to be local admins, which makes me lean towards option 2. Are computers not shared often enough that I shouldn't be concerned?
Again, I'm not asking about how to physically register a computer - I'm not worried about it. I'm only going to checksum the key provided and give the go-ahead, as I want to be as non-invasive as possible.
I would recommend a solution that does not require admin rights. Lots of users, especially in shared environments, won't have those rights and won't be able to find anyone with them conveniently.
Also, going forward a few years, I think it will be getting increasingly unusual to have admin rights on the computer you are using, as the security situation improves.
Registry seems to be an okay solution for business software. At least at where I used to work, regular user will not be a local computer administrator, so each installation will require local administrator account. This is a good thing since it will lessen the headache of your support staff from people installing just about everything in your business computing environment. The trade off is of course, user will be pissed that they can't install stuff or have to contact support to do it, but hey... :)
Other stuffs:
USB / other type of dongle (ala old
3DMax)
plain old text file (ala
Garmin GPS software on mobile device)
Encode them / rewrite the key into
your binary or part of your binary
(did this trick back in th old DOS
days)
Store them in your own db via web (ala EverQuest / other MMORPG games)
Local key db (ala MathLab I think)
How about using the isolated storrage for you application?
You will have the ability to store this information on a mashiene level for your registration, and the configuration changes can be persisted on a user level.
We save our activation code to the registry for the current user (HKCU) we have had very little problems with it. Our customers run on everything from home computers to thin clients on cooperate networks.
If your software will be used in schools or other educational environments you need to provide some other method. It could be as simple as a separate registration application which will save to the activation for all users. Your software would have to do two registry lookups but that is a small price to pay.
In general, most computers are used by a single user (or multiple people still using the same user account). So a user based storage will work most of the time anyway.
However it's not either/or. There are folder locations that are writable by all users - such as the ProgramData folder. The key is to make the file readable/writable by Everyone so that you can verify the content regardless of the user.
DeployLX Licensing does this for non-secure license data so that it can be used by multiple users without an admin explicitly granting permission.
You should be consistent. If administrator rights were required to install the program, it's not out of line to require administrator rights to register it. Likewise if you somehow managed to install it without administrator rights then register it without too.
If you install and register in one step this won't be an issue.
Let me state first: I know that any user that wants to run a program (or even log in), has to have access to (probably at least) the Windows system directories and the shared libraries in %ProgramFiles%, but I'd like to be able to access Skype, for example, by running it with an unprivileged user and make sure that it can't access any unnecessary files.
I fear that the only way to do this would be to identify all of the gazillion directories where I store files that I don't want this user to access and then create a new user group that can access these directories, or run Skype and Azureus in a VM.
Is there a better way?
Normally, accounts are members of the Users group at least, which does have access to many things. You could make the account a member of no groups, or the Guests group which is very restrictive.
The real issue is that the program's token (an internal security object that keeps track of what security identities a running process has) will contain the Everyone and Authenticated Users groups, which also have read access to lots of stuff. There is no way to create an account without those groups. You could remove the access that Everyone and Authenticated Users groups have to most everything, but it would be a lot of work to track all those down.
I would say that creating a standard user or guest access account for untrusted programs would be plenty secure enough. To support self-updates and to keep related files in the same place, I suggest you install those programs directly in the profile of the user account they will be running as, e.g. C:\Documents and Settings\skype\Program Files\Skype
If you want to get really fancy, you can use a restricted token to either make the Everyone, Authenticated Users, etc. groups deny only (so they can't grant any access) or create a Restricted SID list. This will be difficult to implement because there are global objects that programs will expect to access that the Everyone group has access to, which is normally a safe choice.
See CreateRestrictedToken Function.
There is also an open-source command line program I created a program for creating restricted tokens and job objects on the fly for that purpose: UlimitNT
Maybe sudown is a solution. It's a sudo-similar (as known from Linux) approach to running as unprivileged user, but having the possibility to promote to an administrative account (with password) when needed.
I suppose you could lock down the machine so the user can solely log on, not even start skype with his rights, but start skype by "run as" with sudown.
Besides using a VM you could look into using a Sandbox. Look at Sandboxie fox an example.
simply use acl apis (samples in msdn)