Azure AD

Hey, I’m back. Long time since I did some writing on this blog. But I needed to get this one out. As you all know I’m a huge fan of the Microsoft Teams extensibility model and now with the SSO support for Tabs, it’s even easier to create integrated experiences for your end users where they can consume data and information from the Microsoft Graph or LOB systems. I recently did a small appearance at the Microsoft 365 PnP webcast showcasing how to configure and scaffold a Microsoft Teams project that uses this new SSO Tab feature. You can watch the recording here:

SharePoint Framework (SPFx) is a fantastic development model on top of (modern) SharePoint, for user interface extensibility, and it have evolved tremendously over the last year since it became general available. The framework is based on JavaScript extensibility in a controlled manner, compared to the older JavaScript injection mechanisms we used to extend (classic) SharePoint, that comes with a lot of power. Using SharePoint Framework our JavaScript has access to the whole DOM in the browser, meaning that we can do essentially what we want with the user interface – however, of course, we shouldn’t, only certain parts of the DOM are allowed/supported for modification. These areas are the custom client-side Web Parts we build (that squared box) or specific place holders (currently only two of them; top and bottom). For me that’s fine (although there’s a need for some more placeholders), but if you want to destroy the UX it is all up to you.

I’ve been building chat-bots for a while now and I’m seeing more and more requests of building these bots for enterprises. For bots targeted at the enterprise, perhaps being hosted in Microsoft Teams, one of the first requirements is that they should get data from their internal systems and most specifically from Office 365, through the Microsoft Graph. The problem here is that we need to authenticate and authorize the user, through Microsoft Azure AD, to be able to access these resources. A Microsoft Bot Framework bot, does not inherit the credentials or security tickets from the application the bot is being invoked from, so we need handle this ourselves. For instance, even though you have logged in to Microsoft Teams, or Skype for Business or your Intranet – your security token cannot (and should not) be passed to the Bot.

Over the last few days the issue on how to prevent users to create Office 365 Groups has popped up in all sorts of conversations. This blog post will show you how to do it in the correct way, and serve as a future reference. I’m not the only one who have blogged about this, it’s in many places including official documentation. But in many places both scripts and some caveats are either wrong or outdated. One post covers this topic really well, and in a good and correct way and it’s this post by John P. White - Disable Office 365 Groups, part 2. Read it! This post however will show you how to do it in a more direct way, using PowerShell.

One very common requirement in SharePoint, and other portal solutions for that matter, is to have the possibility to target content to a dynamic audience of users and even secure information based on dynamic rules. Traditionally this has been done with Audiences in SharePoint. Audience is a dynamic set of users that is compiled, usually once a day, and at compile time the rules of the Audience is evaluated. A SharePoint Audience is used to target information, but cannot be used to protect content - ie as a security group.