How many times have you been given a VM for D365FO development, but no interactive user in the local Web application? You can program X++ code, you can build, but you cannot test. The AdminUserProvisioning tool on the desktop requires local Administrator rights, which is a separate account on new cloud VMs. Fortunately, with an access to the SQL server you can make yourself an Admin.
In essence, the trick is the same as in the past: update the USERINFO table.

1. Secure an access to the AxDB database in the Microsoft SQL Management Studio. Recent VMs may require a separate admin account, e.g.
   RUNAS /user:Administrator@builtin "C:\Program Files (x86)\Microsoft SQL Server\140\Tools\Binn\ManagementStudio\Ssms.exe"
2. Connect to the AxDB database and locate the USERINFO table, then Edit top 200 rows, find and start editing the Admin record. You may also use the SQL pane to pass the below command:
   SELECT ID, NAME, ENABLE, SID, NETWORKDOMAIN, NETWORKALIAS, DEFAULTPARTITION, EXTERNALUSER, EXTERNALID, IDENTITYPROVIDER, OBJECTID FROM USERINFO WHERE (ID = 'Admin')
   There will be most likely 4 Admin records, the last 3 non-interactive logons are created by the D365 Object server automatically and may have the SID = S-1-5-20 (NT AUTHORITY). We only need to edit the 1st – interactive – account:
   
3. As in the past (Dynamics AX 2012), the SID is the most important. The easiest way to deduct this ID and other information is to copy and paste it from another cloud environment you have an access to, for example via the table browser: https://xxx.yyy.operations.dynamics.com/?mi=SysTableBrowser&tableName=UserInfo
   
4. Update the following fields in the target record:
   

   Column	Remark
   SID	S-1-19-123456789-1234567890-1234567890-1234567890-1234567890-1234567890-1234567890-1234567890-1234567890-1234567890 The long SID is a unique identifier of your user in the Azure Active Directory (see also “Immutable ID”). It it sufficient to only replace it in the 1st [interactive] logon out of 4.
   NETWORKDOMAIN	https://sts.windows.net/ This one looks most probably https://sts.windows.net/ but may also be like https://sts.windows.net/erconsult.eu or even https://erconsult.eu/ and refers to the Azure tenant. Apparently, the syntax depends on who owns the tenant and whether your AAD is trusted by the AAD of your client.
   NETWORKALIAS	name.surname@yourdomain.xyz This is your [e-mail] account in the Office 365 tenant.
   DEFAULTPARTITION	1 Set to “1”.
   IDENTITYPROVIDER	“” This can be the same https://sts.windows.net/ or a https://sts.windows.net/ab123456-123a-456b-789c-abcde1234567/ address, where the GUID at the end is the tenant id of your Office 365 subscription (see https://www.whatismytenantid.com/). From experience, you may keep it blank.
   OBJECTIID	“” This seems to be a GUID of your user in the Active Directory. Keep it blank, the system populates it on the first logon automatically.
   EXTERNALUSER EXTERNALID	0 “” Whatever that is, you can keep the 2 columns empty. Upon the first logon the system is going to set EXTERNALUSER = 1, and EXTERNALID = some alphanumeric value.

5. Update the USERINFO record and try to connect to the D365 Web application. Experiment with the SID and the NETWORKDOMAIN if it doesn’t work.