Convert On-Prem AD Users from Office 365/Azure AD to In-Cloud accounts
Hi We have currently setup a ADConnect Sync to Office 365, this is working well. We would like to start converting Sync'ed accounts in Office 365/Azure AD to "In Cloud" accounts. Can you advise or does anyone know how we might approach this? Or can point to alternative resources? We need to ensure the accounts in Office 365/Azure AD remain active and usable. Much appreciated Paul
Using the extensionAttributes in Active Directory
So I'm working on expanding the data stored about User Objects in an Active Directory, but we are looking for possible candidates to store the data in, as a lot of the fields have already been used. We found the fields 'extensionAttribute(1-15)' and looked online for some information about them. I couldn't find a lot of information about them. What I found was they are a result of implementing Exchange to your system. Are they suited for adding extra data to an User Object? Will they not be removed at a point? Can I find some more documentation about them somewhere? Won't they be affected when we may want to implement other systems in the future?
Azure Active Directory Premium P1 is coming to Microsoft 365 Business Premium
With Microsoft 365 Business Premium (previously Microsoft 365 Business), we’re on a journey to deliver a comprehensive productivity and security solution for businesses with less than 300 employees. It integrates your favorite Office apps and collaboration tools including Microsoft Teams with advanced security and device management capabilities. We're adding another key capability to the Microsoft 365 Business Premium subscription - full Azure Active Directory Premium P1 license.Microsoft Intune support for Android Enterprise fully managed devices is now generally available
Support for Android Enterprise fully managed devices is now generally available in Microsoft Intune. This is designed for corporate-owned devices that are used primarily for work, to separate work and personal apps and data while enabling data security and end-user privacy. In this scenario, IT admins have granular controls on the entire device and end users enjoy the consumer-like experience and convenience to work from anywhere using the Android devices they love.Principle 'XYZ' could not be found or this principal type is not supported - Azure SQL DB and MI
In this blog article, we will be discussing the possible scenarios to get the error "Principle 'XYZ' could not be found or this principal type is not supported" while adding an AAD user or group to your Azure SQL database or Azure SQL managed instance.Use managed identity instead of AzureWebJobsStorage to connect a function app to a storage account
In a function app, usually we use appsetting AzureWebJobsStorage to connect to storage. This blog shows you how to configure a function app using Azure Active Directory identities instead of secrets or connection strings, where possible. Using identities helps you avoid accidentally leaking sensitive secrets and can provide better visibility into how data is accessed. This will not work if the storage account is in a sovereign cloud or has a custom DNS. IMPORTANT! When running in a Consumption or Elastic Premium plan, your app uses the WEBSITE_AZUREFILESCONNECTIONSTRING and WEBSITE_CONTENTSHARE settings when connecting to Azure Files on the storage account used by your function app. Azure Files doesn't support using managed identity when accessing the file share. That is to say, if your functio app is running on Consumption/EP, plan, you can only delete and recreate function app on app service plan to avoid using File Share. For more information, see Azure Files supported authentication scenarios Below are the steps to do configuration. 1. Enable system assigned identity in your function app and save it. 2. Give storage access to your function app. Search for Storage Blob Data Owner, select it. 3. If you configure a blob-triggered function app, repeat the step 2 to add Storage Account Contributor and Storage Queue Data Contributor roles which will be used for blob trigger. 4. Return to Access Control (IAM), click Role assignments, search for your function app name to confirm the roles are added successfully. 5. Navigate to your function app. Select Configuration and edit AzureWebJobsStorage. Change the name to AzureWebJobsStorage__accountname. Change the value to your storage account name. (The new setting uses a double underscore ( __ ), which is a special character in application settings.) 6. Delete the previous AzureWebJobsStorage. Then you will find your function app still works fine.
