For uploading and deploying SPFx packages I found these permissions to be the bare minimum:
Delegated Microsoft Graph User.Read
Delegated SharePoint AllSites.FullControl
Service Account
The second part is the service account that just has access to one site collection – Tenant App Catalog. That plus Delegated AllSites.FullControl of the app registration narrows the access to just that site. To install apps the Uploader Account needs to be Site Collection Administrator.
Least privileges for SPFx Upload & Deploy
Azure Pipelines
In our project we use Azure Pipelines where we also define the release using .yml. The deployment consists of series of bash inline scripts.
I am not going to describe all the steps for setting up node, npm and installing the office 365 cli. If you already have used Office 365 CLI with the default AAD APP it might look like this:
Now comes the tricky part! If you followed the guide mentioned above, you must have noticed the two environment variables that you need to have:
That’s straight forward when you run the cli in your own console. But the fact is (or at least from what I can see), you cannot “export” variables to other pipeline tasks.
Instead of setting the variables in the inline script, we can take advantage of the Bash task parameter called env:.
Some other findings:
Office 365 CLI needs them in all three commands: login, spo app add, and spo app deploy
If you create and export a variable in a pipeline task, it won’t persist, because every task starts a new shell session.
That means that we need to provide environment variables in every task in the pipeline, that uses Office 365 CLI with a custom Azure AD App. Or is there a better way? Anyway, the version below (the same tasks plus `env`) will work:
Eliminating Legacy Authentication
My goal is to remove the need of legacy authentication. Previously we installed spfx packages using PnP PowerShell. PnP PowerShell in Pipelines causes Legacy Authentication, it can be solved, though:
Honestly, Power Automate is great for automating repetetive stuff. But I think there is room for one-time flows as well. I’ll give you an example.
I’ve got an excel file with quite a few rows. And I need to convert it to a SharePoint List. I know there is a couple of options, such as Quick Edit in Classic View, Import an Excel file as a list (it also requires the classic view), there will be Excel import in Modern as well. But I need to also change the column names, maybe adjust something “on-the-go”.
If you had asked me to do that same thing one year ago, I would have created a script (powershell or javascript), loaded the rows and created all the list items.
But today, I find it much faster to set up a Power Automate (No worries, there is still need of “real” scripts and applications).
So my spreadsheet has two columns.
I create a new SharePoint List and adjust the columns to my needs.
After that I set up a very simple flow.
I could have loaded that excel, but I just pasted the rows directly in that flow. Hey, I will only run this once!
A positive side effect is that I also get a verification of the user accounts (my second column)
Since it run in an “Apply to each”, it keeps working even if specific rows fail.
These are my findings around Modern Sites without Office 365 Groups. It is, of course, a subject to change.
Today (2020-02-21) when you create a Modern Team Site without a group, you will get a site with the template STS#3. This oldie has been around for a while, hasn’t it?
I would always recommend creating Office 365 Group Connected sites.
How it is created
Through PowerShell/REST or from SharePoint Home, if your account is not allowed to create Office 365 Groups, it will automatically create a site without a group.
Site Creation Speed
It is really fast, much faster than the old STS#3, so something is different.
Custom Script
CustomScript is enabled. Which is the same as DenyAddAndCustomizePages=Disabled. CustomScript is a security risk, so I hope Microsoft will change that.
Groupifying
Yes, connecting to a new group is possible.
Listing Team Sites without Office 365 Groups
In SharePoint Admin you can filter them based on “Team Site (no Office 365 group)”
Jag förstår att det är väldigt mycket kod för att få till kalendervyn och att det inte är så lätt omvandla till ett modernt utseende, men det ställer till eftersom det upplevs som gammalt och inte användarvänligt ute i verksamheten.
Varför behövs en SharePoint-kalender
Jag ska lista några alternativ och förklara varför en gammal dinosaurie är fortfarande det enda vettiga alternativet (i väntan på en “modernisering” av lsitan)
En Office-365-gruppkalender
Det är en bra funktionalitet för en enkel kalender. Den saknar:
Stöd för extra kolumner och innehållstyper
Den är svår att dela med externa användare
Händelser (Events)
Om du inte hittar länken till den här sidan, finns den under <site>/_layouts/15/Events.aspx. En snygg modern sida som kan visa kalenderhändelser från flera kalendrar på SharePoint-siten. Dess begränsningar är:
Går inte att anpassa, eftersom det är en systemsida (layous-sida)
Den visar bara det minimala om händelser
En kalender utanför Office 365
Har man egen kalenderdata, är man friare, men man förlorar fördelarna med att ha/betala för en dyr platform. Om man också har ett eget gränssnitt för det kostar det att i längden med alla anpassningar och buggrättningar.
SPFx-lösning
I SharePoint skulle man kunna ha en SPFx-lösning för att presentera kalenderdata på ett snyggt sätt. Men det får avvägas mot kostnader. Det fina med inbyggda kalendern var att den bara fanns där, den ingick i plattformen.
Kalendern i SharePoint
Till fördelarna av kalendern i SharePoint hör:
Det är en del av ett större ekosystem. Power Automate eller PowerApps kan kopplas på, som ett exempel. Det visas också i moderna Events.aspx
Det är anpassningsbart på ett enhetligt sätt, som alla andra listor. Användare med rätt behörighet kan skapa nya kolumner, definiera innehållstyper med mera.
PnP-mallramverket kan både exportera och importera en kalender.
Listvyer, behörigheter, mappar, allt det ingår om man behöver det, på samma sätt som det gör för alla andra listor i SharePoint.
Möjlighet till sök och aggregering ifrån flera siter.
En chans att det moderniseras utan att man behöver investera något i det extra.
En förenklad vy genom “Händelser” av samma kalenderlista.
Lite tips och tricks för gamla kalendern
Här kommer en liten samling av enkla men intressanta tips för gamla kalendern.
#1 Välj tid för en ny händelse med en annan innehållstyp på ett smidigt sätt
Det här har varit en av de sakerna som man varit mest frustrerad över. När en kalender har flera innehållstyper, går det inte att byta innehållstyp i NewForm när du klickar i kalendervyn.
Om du väljer en annan innehållstyp, måste du manuellt ange tiden. Det tar tid. Föreslagna tiden är bara aktuella timmen här och nu.
Tipset är att:
Hitta rätt dag och markera rätt tid i kalendervyn. Rutan får en blåaktig färg.
Klicka på “Ny händelse” i Ribbon (vad var svenska namnet för det?).
Vips så har du tid och datum rätt ifrån början
#2 Kalenderöverlag
En klassiker, en av mina favoriter är möjligheten att visa kalenderhändelser med olika färger – kalenderöverlag. Tyvärr är det begränsat med färger.
#3 Visa veckovyn utan att ändra inställningar
I länken till din kalender (t.ex. i vänstermenyn), lägg till “?calendarperiod=week” i URL:en, så visas veckovyn automatiskt.
If you want to remove the Microsoft Teams Banner on your SharePoint Site, the only thing you need is to set a web property on a site: TeamifyHidden=TRUE. I’ll give you some guidance below. But before you do that, consider following:
If there is already a team created for a group connected site, the prompt won’t show up. Why fix something that is not a problem?
Only group owners will get the prompt, if they are few and they know what it is, it is better to let them to decide whether to create or not to create a team.
Only licensed users within your organization will be shown that choice. No external users or users without a license.
And the most important part: if any site owner selects “Don’t show me again” it will stop popping up for all other site owners. If you happen to have a manual step in the group creation process, then you can just click it away.
“Don’t show me again” option is per site, not per user.Internally, it is stored as a web property on root site of a site collection.
How to hide Teamify programmatically
Allright, if you still want to hide this prompt and you want to do it programmatically, you need to ensure that this web property is on every site collection root site.
Iterate through all sites
You can find a script for that on Microsoft Fasttrack github repository:
Performance and need for re-run. It iterates through all existing sites, meaning that it takes time to iterate through all of them and it requires that you run it again. In an organization with many new collaboration sites it might be a bad option.
Access to all sites. It requires SharePoint Admin, which is okay-ish, but it also requires that this admin account has access to all sites, in order to update the web property, which is not a good option when admins have a restricted access to actual sites due regulations.
CustomScript. CustomScript is disabled by default for a reason. Because it is a security risk. At least you should alter the script to reset the CustomScript setting on a site after you have changed the web property.
Hide Teamify site by site
You can of course hide the Teamify Prompt on a site without iterating. It is the same principle, but it doesn’t require iterating through all sites. You still need to be a SharePoint Administrator (or a Global Admin of course) in order to enable Custom Script. As in the case with all sites, you should reset the CustomScript to what it was.
Use GroupSiteManager Api
There is a new SharePoint Site API that you can call to hide a Teamify Prompt. All you need is to use the solution described in this sharepoint stackexchange answer:
This still requires that access to the site, but you will not need SharePoint Admin, nor will you need to change any CustomScript settings on a site. That’s better.
Calling PnP Rest Call to hide the Teamify Prompt.
Summary
There are ways of hiding the Teamify Prompt on a site collection. If you do that you should include that step in some provisioning process, and not iterate through all sites. It is better to not alter the CustomScript settings at all. First of all it is best to ask yourself why you should disable something that is done for users and for a better user adoption. Also consider that usually only few will be shown that (group owners with a license and within the organization). The group owners can also hide it by clicking “Don’t show me again” and it will disappear for all other group owners.
Site Collection App Catalogs are great for special cases (like developing apps or site unique apps), but using them on scale would be a mess.
I got a question: Why should we use the Tenant App Catalog at all when we could enable a Site Collection App Catalog on every teamsite? So the suggestion here is to install SharePoint Framework Packages on many Site Collection App Catalogs, instead of the Tenant App Catalog. In that way those wouldn’t be visible for all users in the “Add an app” page.
Technically, both ways are possible, but I would say, we should use the Tenant App Catalog for apps that are installed on many sites. I have gathered some pros and cons to help people decide.
But first, some abbreviations and notes on terminology:
SCAC = Site Collection App Catalog, (Local App Catalog)
TAC = Tenant App Catalog, (Global App Catalog)
App = SharePoint Framework Package, but also a SharePoint Add-In
Pros and Cons of Site Collection App Catalogs
👍 A SCAC makes it possible to have local instances of an app. It is perfect if you want to test an app without making it visible for the whole tenant. It is also good for apps that are only installed on one site collection. There are benefits of distributing site specific apps through the TAC, such as better governance, once installed on a site, those apps can be Disabled.
👎 Mess in all the apps and the versions. There might be different versions of the apps. The update procedure will require a special script to find all the sites and run the update. This also requires owner access to that site. If the owners would like to remove all the IT accounts in order to collaborate on confidential information, then it won’t be possible to update that site. It will lead to poor governance. Just to give it a perspective. Imagine that every smartphone had its own local App Store/Google Play. Possible but counterproductive.
👎 A SCAC is a security risk. The control and governance is handed over to site owners. It means that they can install any apps on their site collections. Poorly designed and implemented apps can lead to big security issues, in the similar way as custom script.
👎 Enabling a SCAC adds additional lists and features (such as Apps for SharePoint). It will require more space (not so much, but still), but first of all it will make some users more confused, actually more confused then some more available apps. Imagine all the support: What is it, Oops I deleted “Apps for SharePoint”.
👎 Every app will install the resources on every site collection, meaning every app will have multiple copies of the same app. It means more space needed. That is of course, not the case if you use Azure CDN.
👎 Every app will use its own urls to resources, preventing browsers from gaining performance by caching the resources cross site collections.
👎 If Azure CDN is used, you must make sure all the versions of javascript and css files are kept because you might not know which versions of an app are still used.
Pros and Cons of the Tenant App Catalog
👍 Easier to control the apps and have better governance. The Tenant App catalog tells what apps exist in your tenant. As admin you can verify that the code complies with the guidelines (by running code checks), you can make sure, every app there has all needed information such as app owner, description etc.
👍 Easier to update apps. Installing a new version of an app will update all the instances. There won’t be any custom script to traverse all the sites with that app.
👍 It is more cost efficient to follow the Tenant App Catalog approach, because it is the recommended way of installing and updating apps. Having scripts and procedures for SCAC, (even completely automated) will always cost more: to keep the scripts up to date, support etc.
👍 Benefits of the common apps. If a business unit comes up with a good solution, it can be used by other Business units, if it is discoverable and follows quality guidelines (more on that later).
👎 The Apps from the TAC are visible to all Business Units and the users might be confused. This issue can be mitigated in two ways:
The business units that have not rolled out SharePoint Online and don’t use any apps, can remove their users from the App Catalog.
Having a good naming policy, app icons, good descriptions, disabling any “auxiliary” apps. On top of that, some user guidance.
Summary of pros and cons
To summarize, Site Collection App Catalogs for reusable apps installed to many site collections, is a bad idea, because it means a security risk, less control and governance, encreased data and traffic to SharePoint Servers.
How can we scope apps to our business units
Are there other ways of scoping the apps to business units other than misusing the Site Collection App Catalogs?
First of all, it is a question of user adoption. It is better to help users instead of breaking the functionality or misusing other concepts.
Second, it is a question about governance of the Tenant App Catalog. It should be clear how an app can be added, and how that package should be wrapped:
good naming standard,
proper localization
a mandatory icon,
good description,
owner/contact person. Also, only relevant apps should be “Enabled”. All the other apps should be Disabled.
A couple of apps from your organization is a drop in the ocean compared to SharePoint Store Apps
Control with Permissions
If you remove a user from the Tenant App Catalog, the apps will disappear for that user.
There are apps, but this user cannot see any apps to install.
The permissions can set on the whole Tenant App Catalog by removing “Everyone except external users” and then adding all AD Groups who should see the apps.
The permissions could also be set on the specific packages or folders.
The permission way of scoping the apps might work. But it is important to know that it is a workaround and it breaks the default setup (where all users have READ on the TAC). This means that along the way you can bump into limitations or bugs, more or less unique to your organization. It will be harder to get help from Microsoft or from community.
I uploaded my app to two site collection app catalogs. Do I need to get approval for the app twice? – No.
I have got my approval for Delegated Groups.ReadWrite.All for App X. Now I want to use the same permissions in another app, do I need a new approval? – No.
I got my fingers and tried that guide out. This worked good, I spent some time, though, googling (binging) around to get rid of the SSL Warnings for the remote “localhost” on my Mac.
I would like to share this simple instruction on how to trust a self signed certificate from gulp-connect on Mac OS. The implication is that the certificate is on the remote linux machine (on the Visual Studio Environment), that you are connected to through the Visual Studio Code extension.
The first step (after you have connected and set up a project) is to download the certificate. It can be found in the following directory:
Choose a folder (like Desktop or whatever) to save it to. Then double click server.crt to open it in the Keychain Access.
In the Keychain Access, locate the certificate, it will have the name “gulp-connect”. Open it and enter the “Trust” section. Under “When using this certificate” select “Always Trust”.
Allowing custom script has its security implications. But what exactly does it mean? Is it dangerous? My colleauge Daniel and me have done a little experiment. There are two implications stated on MS Docs:
Scripts have access to everything the user has access to.
Scripts can access content across several Office 365 services and even beyond with Microsoft Graph integration.
To summarize, we can look at that picture:
So the risk that user 1 (the Blue User) intentionally or unintentionally places a script and lets user 2 (the Red User) run this script by linking to the page that has this script. The page must be in a “common” place.
Let’s try that. Let’s have a little hackathon.
Experiment A. Very Simple.
Scenario: the Red User (my colleague Daniel) has a site with with sensitive information (He has a list called Secrets). The Blue user (me) does not have access to that site. The Red User accidentially shares the link to the secret list. Now, to prove the security risks with the custom script, the Blue User has to get the secret information.
To make it more visual and fun, we have found a box where we have put candies and locked it with a combination lock. The code (the combination) is stored in the Secrets list.
The combination consists of three digits from 0 to 9. So there are 1000 possible combinations.
Since the Red User knows that he is going to be hacked, he acts as normal as possible, not especially suspicious. And since the experiment A is a simple one, we let the Red User to accidentially show the link to the Secrets list. That can be:
A screenshot that shows something else but contains the confidential site url
An email that is sent to a wrong recipient
A pasted link in a wrong Teams chat
etc.
So the Blue User finds out that there is a Secrets list that has the following address:
/sites/DailyWork/Lists/Secrets
“Fortunately”, the Blue User has access to a classic site (where Custom Script is allowed). He shares that site with the Red User. Now both the Blue User and the Red User have it in common.
Then, a new Web Part Page is added with a tiny script.
That script makes a REST call to the Secrets list and uploads the result in Shared Documents. For the sake of simplicity, a built-in document library is used. An attacker would probably add a hidden list for that.
Now to get the Red User to that page, the Blue User adds some “important” information so that the Red User will not become suspiciuos.
The “important” information and the actual script editor
Now it is just the matter of sending a link to the Red User. The Red User navigates to that page and the script is executed while he is reading the information on that page.
The Blue User gets the Secret that was generated by the Red User:
With that information the Blue User has hacked the combination lock and he can now open the red box with candies!
Skitgott Candy
Experiment B. Harder
For now I think it is enough with the Experiment A, the Simple Experiment. We have proved, that, indeed, security is compromised with custom script allowed. A user can get confidential information from another user. Maybe some of you want to set up a more sophisticated experiment. Make sure the “hacked” person is warned and agrees to be part of an ethical hacking act. We maybe can try more to show the importance of keeping custom script disabled and not using classic sites that have it by default.
Wrapping up
Custom Script (or DenyAddAnCustomizePages=false) is dangerous, it is of course not black and white. It provide the ability to have small appications directly on sites created by users. But as with all other aspects of IT, you should know what you are doing. Every site with custom script is a potential trojan horse. Minimizing the number of classic sites and sites with custom scripts lowers the risk. All the collaboration sites should be modern team sites without custom script.
Recent Comments