I have a kentico site built with portal engine and have staging and production/live environments. I'm wondering if it's possible to restrict/lock access to the admin area (/admin url) of the live site based on roles or privilege levels. Their access to staging site should remain the same. Thanks for your input!
There is no out of the box setting for this - you would need to use two sets of users and roles, separated in each environment and disable staging of users and roles. It is not possible to have the same user/role object on two environments with different behavior.
Related
I am in a SP Online environment where users do not have owner access to their sites. This makes life difficult in several areas, one of them being the promotion of apps to the app catalog. I am in a very large organization and we are looking for the cleanest way to allow devs to promote their apps to their individual sites. We also don't want to clutter the tenant app catalog.
I have been investigating site collection app catalogs. I am assuming that - once the ability for the site to have apps is enabled - that I would need to give a dev elevated access to the site in order to publish apps directly to the site?
The second question is around apps that might belong on multiple sites. If I went this route (publishing to local apps) would it then be incumbent on the devs to publish to multiple sites in their pipeline using CLI?
Thank you in advance!
I have been building canvas apps as part of solutions on non-default environments for a while.
Recently a customer required that the app be shared (to run, not edit) with an AAD security group's members.
The SG setup is as follows;
Image of SG setup
I imagined this to be simple and indeed I was able to 'Share' the canvas app with the SG.
However, users were unable to access the app even via a direct URL unless I gave them individual access.
I have spent many hours perusing the documentation and it seems that it is all aimed at 'Dynamics/CDS' environments.
The only way that i was able to share the app to them using the SG, was to create an environment DB add then to set the SG as the env SG.
Is that the correct approach?
It seems counter-intuitive because, according to MS, if an SG is not set to an environment, then all users can access the env?
First, make sure the group you are sharing with is really a security group or security-enabled M365 group.
You can't share an app with a distribution group in your organization or with a group outside your organization.
...
You can share an app with Microsoft 365 groups. However, the group must have security enabled
You can do that at Azure Portal:
Go to Azure AD Active Directory > Groups (direct URL)
Click [Columns] and add Security enabled column to the list
Find the group and make sure it is security-enabled
Also, make sure users have permissions to access and other resources
For a shared app to function as you expect, you must also manage permissions for the data source or sources on which the app is based, such as Microsoft Dataverse or Excel. You might also need to share other resources on which the app depends, such as flows, gateways, or connections.
Source: https://learn.microsoft.com/en-us/powerapps/maker/canvas-apps/share-app
We have multiple apps under one service plan and we want to restrict the access to development slots from outside the office, So my question is Can the access restriction rules be configured in one place and applied to all the development apps/slots?
Yes you can set it up. To add an access restriction rule to your app, use the menu to open Network>Access Restrictions and click on Configure Access Restrictions
From the Access Restrictions UI, you can review the list of access restriction rules defined for your app.
Here is the documentation
My company process sensitive data and needs to restrict access to production environment. How do I organize subscriptons and (storage) accounts so that I have separate environments?
I could have completely distinct subscriptions but I want to give some devs the power to deploy on production while others should only have access to development assets.
In my ideal world, I'd add individuals to security groups. Whenever a thw dev wants to deploy on production, he/she would use his/her credentials plus an extra confirmation step, like an otp. This way I'd avoid mistakes but still keep simple users management. Is that possible in azure?
Eventually what you are wanting to do will be possible, and is possible to some degree depending on the resource. As more of the features of Azure make it into the preview portal (portal.azure.com) they are showing up with Role Based Access Controls, which is what you are looking for. Unfortunately, right now not all of the resources are there and some are there without full RBAC baked in (such as storage accounts).
For now, the best bet is to still separate by subscription. If you need developers to have the ability to perform a deployment you can create a script that performs the deployment (using stored PowerShell credentials or secured management certs) and then give the developers the ability to execute the script.
Is it possible to create a user with permissions of both a local administrator and NETWORK SERVICE?
I've got a Sharepoint timer job which runs stsadm for which it needs local administrator permissions. On the other hand temer jobs are also used by other services which need NETWORK SERVICE permissions and those to sets of permissions only overlap, so I need a user with the "sum" of the permissions to run OWSTIMER under.
(I know that most of the operations you can perform with stsadm sharepoint administration API can be used, by in my case it is the operation which moves a site collection between content databases for which there seems to be no API equivalent).
I recommend always using domain accounts - SharePoint works best on servers connected to an Active Directory server. For production environments a best practice is using a least privilege account. I always create the following domain account dedicated to SharePoint services:
DOM\spservice
You do not need to grant any special privileges to this account as SharePoint will automatically do this for you when you specify the account during setup.
I can't help you with the user permissions (Lars hit the important points), but I wanted to share some information that may be of use.
You mentioned that you're trying to move site collections between content databases and haven't found an API the can be leveraged. Have you looked into SharePoint's Content Deployment API (also know as the PRIME API) to see if it can assist? The types of which I'm speaking are located in the Microsoft.SharePoint.Deployment namespace, and they provide you with mechanisms to export (via SPExport) site collections as CAB files and then import them (via SPImport).
SharePoint leverages types in this namespace for its own content deployment paths and jobs (in MOSS); it's also the API that is leveraged by the STSADM.EXE executable for export (STSADM.EXE -o export) and complementary import operations. For that matter, it's also used by SharePoint Designer for it's site "backup" and "restore" operations.
For an example of how this API can be leveraged, check out the SharePoint Content Deployment Wizard tool on CodePlex (http://www.codeplex.com/SPDeploymentWizard).
I hope this gives you a potential alternative to shelling out to a command line in your timer job!