https://www.ariclevin.com/Azure/Post/configuring-oauth-cds

In recent weeks, I had to do that same for an additional user, but while going through the logic of implementing this, I notices some changes.

After the creation of the User account and the registration of the App in AD, when I went to create the account in my Dataverse environment. The username, full name (first and last names) and the email addresses were locked. The only setting that I was able to enter was the Client Id.

I even tried using God Mode so that I can enter my own User Name (for the AD account) that I specified, but when I saved the new Application User, the User Name would store whatever name was entered in the App Registration record.

This change was implemented a few months back, as Microsoft was trying to simplify the creation of App Users, so that the user can be created only be entering the Client Id. After the user account has been created we are able to modify the email address, first and last name, but the name (domain name) and the last name cannot be changed. The last name seems to be configured to what is stored in AAD as the App Registration name. Might need to play around with this a little, but if you have access to AAD, you should created this in the right way

I asked around a little bit, and it seems like a few days ago there has been a change in Microsoft Docs on how applications user should be created. The link is provided below:

https://docs.microsoft.com/en-us/power-platform/admin/manage-application-users

The new changes are that now Application Users can be created right for the Power Platform Admin Center. As a prerequisite we have to register the App in Azure Active Directory, but once the app is registered, we can add in directly by following the steps below.

Navigate to Power Platform Admin Center, select the environment, click settings, and under Users + permissions select Applications Users as shown in the image below

In the Application Users settings you will see a list of all the App Users that are currently configured for your dataverse environment. Click on the Command bar New app user button as shown below:

This will pop up a panel where you can start creating the new App User account. Under neither the App label, click on the App an app link:

This will pop up an additional panel which will show all of the apps that are registered in Azure Active Directory. Select the Microsoft Dynamics CRM (Dataverse) app registration that you previously configured, and click on the Add button

Once the app registration is added, we will need to select the Business Unit and to add the security roles. Click on the pencil icon next to Security role, which will pop up an additional panel showing the list of available security roles. Select one or more roles that need to be assigned to this user, as shown below:

The final page is shown below. Click on the create button to create the app user in your Dataverse instance, and it can be used after that.

This is a great step moving forward, but I still wish the User account details could be set on the creation of the App User to an actual AAD user.

The post New Dataverse functionality in creation of App Users appeared first on Aric Levin's Digital Transformation Blog.

Microsoft Dynamics provides the ability to create Stub Users. Stub users are user records that are created in Dynamics CRM. These records are designed for users that do not exist in CRM, but can be referenced during an import process. The user accounts cannot be logged into the system, and modifications to the user records are not possible either.

Stub users can only be created using the Create or Create Requests methods of the SDK (or using an import tool such as SSIS with Kingswaysoft).

Stub users are different from interactive users and disabled users. The following table shows the difference between the users types:

Stub users are different from regular disabled users in the sense the disabled users can consume a license, and disabled users can still be a part of Office 365 or Active Directory.
When migrating users, the users should be originally created in the target environment (whether Online or On-Premise), and only then the migration should occur.

Another import thing to note, is that when stub users are created, they are automatically assigned the SalesPerson security role, and that security role cannot be altered. If you need to provide these users other permissions, you will need to modify the SalesPerson security role to have those permissions, and revoke them after your migration has been completed, as stub user records cannot be modified in any way after they are created.

The post Stub Users Reviewed appeared first on Aric Levin's Digital Transformation Blog.