My company wants to create a security group that allows us to drag and drop users, who have given a resignation notice or who will soon be terminated, into a read-only access group. Preferably the group with automatically monitor/audit the users in the specific group and log their activity. I am unaware if AD currently supports this or if OKTA has these features. Any advice or suggestions would be spectacular.
Thank you!
There is no such feature natively available in AD. You would need to ensure that this group you create has read-only permissions on any resource that it ACLs and also remove the users from other groups that might grant read-write access.
Related
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.
I am developing an app to manage room bookings via Microsoft Graph. In the end, the app needs to read and cancel meetings that are booked into a certain room resource account.
Unfortunately, there is only the permission Calendars.ReadWrite which gives the app permissions to read and write every users calendar in the tenant, including private appointments.
I have not found any possibility to restrict the permissions or specify them more granular.
Does anyone know how to deal with this? (Or do I have to fall back again to service accounts and the old exchange web services, where I can give granular permissions to that service account?)
Thanks a lot in advance!
Application permissions imply the full the level of privileges of that scope, referenced here.
If you are scoping this specific mailboxes/calendars, you use delegated permissions with a functional account that has delegated permissions on those resources. We've had to do that before. It sucks, but that is the nature of App Permissions versus Delegate.
If you have are trying to script this, you could try the "client_secret_post" authentication method for the token acquisition mentioned here and in more detail with the OpenID Connect Spec and the OAuth 2.0 Spec.
You can now restrict the calendar/mailbox access an app will have using the New-ApplicationAccessPolicy PowerShell cmdlet. Using this you set the application up to use application permissions and then create an application access policy to limit the scope of these permissions.
There's an easy to follow guide on MS docs on how to set this up:
MS docs limit mailbox access
I'm using SonarQube-6.7.1.
We have several teams (6) who share the one production instance.
They are asking me to find a way to limit the scope of the users.
They want to see only their own projects.
What is the best way to do that
Limit the projects' Browse permissions to only the relevant people.
Start by removing the ability of "Anyone" (a special group in SonarQube that includes anonymous) to see the projects, then grant Browse as needed.
This will be easiest in the long term if you first create groups, and grant permissions to the groups rather than to the individual users.
I am using ASP.NET Boilerplate for its multi-tenancy support. When a user log in, I would like to present to the user the list of tenants it has access to. For instance, if a user with email admin#example.com is part of Tenant-A and Tenant-B, would like to offer the choice to switch between tenants.
This does not seem to be easily doable. Each user can be mapped to a single Tenant (AbpUsers table).
What would be the best way to allow a user to access multiple tenants? The only way I think this can be done is by adding a N:M table between User and Tenant, but then will ABP allow me to do context switching between tenants?
By design, tenant data (including users, roles...) are completely isolated from each other and can not be shared easily.
We solved this issue with "Account linking" feature in AspNet Zero. With this feature, you can connect your accounts in different tenants and then switch between accounts with a single click. It basically maps those accounts (users) in database and logs out & logs in automatically when you want to switch. See more info: https://aspnetzero.com/Documents/Development-Guide-Core#user-menu
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)