Arin's Tech Musings

 If you have used or are still using Azure AD PowerShell for interacting with Azure AD, you should probably already have taken note that Azure AD PowerShell will be deprecated on June 30, 2023. The alternative - Microsoft Graph PowerShell SDK, uses the power of the new Microsoft Graph and all underlying Graph APIs - allowing you to do much more than just Azure AD related tasks, supports PowerShell 7 making it work cross platform, use modern authentication and a whole bunch of other things that you expect from a modern solution. See link to learn more: https://learn.microsoft.com/en-us/powershell/microsoftgraph/overview?view=graph-powershell-1.0 The SDK supports two types of authentication: delegated access and app-only access. If you follow the tutorial in the documentation, you will be using the delegated permission model. This is effective for ensuring least privilege. However, there is one important thing when dealing with delegated permission

So you need to run a PowerShell script inside a Azure Automation account and the script uses AzureRM cmdlets. How would you authenticate? Do you use a user account? But the user account could have more permissions than what is actually required for your script, opening a whole discussion around security. I have also seen organizations create user accounts that are used as service accounts. But what does Microsoft say? "Automated tools that use Azure services should always have restricted permissions. Instead of having applications sign in as a fully privileged user, Azure offers service principals. " So what is an Azure Service Principal? An Azure service principal is an identity created for use with applications, hosted services, and automated tools to access Azure resources. This access is restricted by the roles assigned to the service principal, giving you control over which resources can be accessed and at which level.  Service Principals offer 2 kinds o

For SharePoint administrators, there was quite a radical change with the introduction of O365/SharePoint Online. One of the biggest changes for them were the limitations to the Administration Portal. The Central Admin allowed admins perform a plethora of admin tasks which were either not anymore allowed or were no longer available via the UI. Of course many admins did prefer the PowerShell route, some tasks were just easier via the UI. One such task that I have seen most admins perform via the UI was the deletion of a site-collection including the recycle bin. This is commonly done when a site provision failed and the same site needed to be provisioned again. However, deleting a site-collection was not enough. It was still in the recycle bin, and SharePoint was always smart to prevent you from creating another site-collection while a site with the same URL was present in the Recycle Bin. In on-premises, it is possible for admins to access the Recycle Bin via CA and delete the site