My understanding regarding the synchronization are as follows:
Create Member User in Active Directory
Assign CRM License in Active Directory
User will be created in Dynamics CRM
However, I'm not sure when will point no 3 is triggered.
Should the new member user login for the first time inside the CRM to change password for it to be created in CRM? (This is the behavior that I observed)
Or will it auto synchronized after some time?
Thank you Henk van Boeijen for your comment adding more to your comment to make it as answer and understandable to other users.
The below answer is publish by soundharya subhash under Power Platform Learning
When an new Environment is created, it takes more than an hour or some times a day to sync users from Azure AD to CRM.
Through Power Shell cmdlets, we can sync user immediately.
Install Module
Microsoft.PowerApps.Administration.PowerShell
Install-Module -Name Microsoft.PowerApps.Administration.PowerShell
Connect to Power Apps using any of these
User Name and Password
Add-PowerAppsAccount -Endpoint “prod” -Username “” -Password “”
Tenant Id, Client Id and Client Secret
Add-PowerAppsAccount -Endpoint “prod” -TenantID “” -ClientSecret “” `
-ApplicationId “”
Tenant Id, Client ID and Certificate Thumbprint
Add-PowerAppsAccount -Endpoint “prod” -TenantID “” -CertificateThumbprint “” `
-ApplicationId "
"
Get-AdminPowerAppEnvironment cmdlet gives list of environments available in Tenant, note down the environment name (guid) to which you want to sync the Users
Go to Azure Portal : https://portal.azure.com -> Azure AD -> Users -> note down the Object Id of the user you want to sync
Run the cmdlet in Power Shell
Add-AdminPowerAppsSyncUser -EnvironmentName <Guid> -PrincipalObjectId…
Reference : https://nishantrana.me/2021/01/20/force-sync-users-from-azure-ad-to-dynamics-crm/
Related
Question: In Azure SQL Managed Instance, what is the procedure for setting Password Expiration when using Azure Active Directory (AAD) Authentication? As shown below, in SSMS, I see Password Expiration option is grayed out:
To set Password expiration policy for Azure AD user accounts, you need to have Global Administrator role on your tenant.
If you don't have that role, contact admin and get yourself assigned with Global Administrator role like below:
Go to Azure Portal -> Azure Active Directory -> Users -> Select user -> Assigned roles -> Add assignments
Login to Microsoft 365 admin center with above Global admin credentials and follow below steps to set password expiration policy:
Go to Microsoft 365 admin center -> Settings -> Org settings -> Security & privacy
By default, this option is set to passwords never expire for entire organization like below:
If you want to set password expiration for particular number of days, uncheck the box and enter the number like below:
If you want to set password expiration policy for specific user, you can use below PowerShell commands:
Connect-AzureAD
#To check the expiration policy for a password of specific user
Get-AzureADUser -ObjectId <userID/UPN> | Select-Object UserprincipalName,#{
N="PasswordNeverExpires";E={$_.PasswordPolicies -contains "DisablePasswordExpiration"}
}
#To set password to expire
Set-AzureADUser -ObjectId <userID/UPN> -PasswordPolicies None
Response:
Reference:
Set an individual user's password to expire - Microsoft
AAD complains about errors in the sync process.
But I don't understand what the duplicate is there.
Already tried a full import, delta import, full sync etc.
How do I find the duplicate?
There are three attributes mainly checked during azure ad connect: userPrincipalName, proxyAddresses, and sourceAnchor/immutableID in Azure AD Connect.
You can make use of IDFix tool to identify the duplicate objects.
Please Check below scenarios if they are the cause:
If you/ User is Global Admin
Try to remove the role and sync the user without admin role or by adding user role.After the sync then you can add the role again.
Or
If it is already in sync ,Disable the directory sync process ,then delete the user
from domain (on-prem directory) and then do the azure ad sync and then add the
user role to admin back if required.
During Azure ad connect , we must take care of SMTP Soft match and ImmutableID hardmatch. soft-vs-hard-match
$credential = Get-Credential
Connect-MsolService -Credential $credential
$ADUser = "username"
$AzureADUser = "username#emaildomainname.com"
$guid =(Get-ADUser $ADUser).Objectguid
$immutableID=[system.convert]::ToBase64String($guid.tobytearray())
Set-MsolUser -UserPrincipalName "$AzureADUser " -ImmutableId $immutableID
This can take care of mismatch .See error-type-attributevaluemustbeunique & this
Note : Please do resync after any changes.
Other references:
Azure AD Sync, duplicate user - Server Fault
Troubleshoot directory synchronization errors | Microsoft Docs
diagnose sync errors (github.com)
AAD connect design concepts
I am trying to create a new service principal using the command below using azure cli v2.0.
az ad sp create-for-rbac --name ServicePrincipalName
Changing "ServicePrincipalName" to a valid URI of "http://ServicePrincipalName", which is the required format used for service principal names
Found an existing application instance of "abcd-8f27-47cf-9976-xkkfigif5e1de". We will patch it
Insufficient privileges to complete the operation.
I am not sure what privileges the Azure Admin of my tenant should assign to my user so i can create a servicePrincipal any guidelines or document pointers please
First, you have to know what this command will do. The command az ad sp create-for-rbac --name ServicePrincipalName will create an AD App(app registration) along with a service principal in your tenant, the AD App will have an Application ID URI named http://ServicePrincipalName, a Display name named ServicePrincipalName. Then the command will add the service principal to your subscription as a Contributor.
The error you got means there is already an AD App with the Application ID URI equals http://ServicePrincipalName existing in your tenant. And you are not the Owner of the AD App. (Note: in the tenant, the Display name is not unique, but the Application ID URI is.)
To solve the issue and use this command successfully, follow the tips below.
1.Change the ServicePrincipalName to a different one. (Or if your admin allow you to use the existing AD App mentioned above, just let him add your user account as an Owner to the AD App. - not recommend)
2.If your account's User type is just a Member in the tenant. Make sure in the portal -> AAD -> User settings -> Users can register applications is Yes. If your account is a Guest , except the Users can register applications need to be Yes, also User settings -> External collaboration settings -> Guest users permissions are limited need to be No.
3.Your user account should be the Owner of the subscription. Otherwise you can create the service principal successfully, but you cannot add it to the subscription.
Installed AAD Domain Services with domain name "mydomain.com"
Added verified custom domain "mydomain.com"
Made "mydomain.com" primary
Created AAD user "admin#mydomain.com"
Converted temp password to permanent password
Logged into Azure with permanent password
Added "admin#mydomain.com" to domain administrators group
Ensured VM can see domain services for "mydomain.com"
When performing domain join, receive "The user name or password is incorrect"
I've tried the following credential combinations when doing the domain join (username : password)
admin : pwd
admin#mydomain.com : pwd
mydomain.com\admin : pwd
mydomain.com\admin#mydomain.com : pwd
None of these work and ultimately give me a lock out indication. I create additional users to continue trying these steps but nothing is working.
The user "admin#mydomain.com" you created must belongs to the Azure AD DC administrators group. Only members of this group have privileges to join machines to the managed domain.
For the details, you could refer to here.
The last step in the instructions from the link below was missed. Had to enable password hash synchronization to Azure Active Directory Domain Services and wait about 20 minutes. All worked correctly after that.
https://learn.microsoft.com/en-us/azure/active-directory-domain-services/active-directory-ds-getting-started-password-sync
I am trying to delete user on Azure AD using the Graph Api but everytime i tried i came across error saying
Insufficient privileges to complete the operation.
After doing some research I found that we have to add application to “company administrators” role on Azure for delete user to work.
When trying to add the role I am getting below error.
Add-MsolRoleMember : This role does not exist. Check the name and try again.
At line:1 char:1
+ Add-MsolRoleMember -RoleName "Company Administrator" -RoleMemberType ServicePrin ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (:) [Add-MsolRoleMember], MicrosoftOnlineException
+ FullyQualifiedErrorId : Microsoft.Online.Administration.Automation.RoleNotFoundException,Microsoft.Online.Admini
stration.Automation.AddRoleMember
I believe you should be able to easily overcome this problem by using the RoleObjectId parameter in Add-MsolRoleMember.
I cover in my blog post here exactly how to do this using the MSOL PowerShell Module, and I use a few steps to first get the object Id of the Company Administrator role, and then assign it to the Service Principal.
Note that this will only affect the access your app has in your tenant.
Also you must already be a Company Administrator of the tenant to follow these instructions.
In order to make the change, you will need to install the Azure Active
Directory PowerShell Module.
Once you have the module installed, authenticate to your tenant with
your Administrator Account:
Connect-MSOLService
Then we need to get the Object ID of both the Service Principal we
want to elevate, and the Company Administrator Role for your tenant.
Search for Service Principal by App ID GUID:
$sp = Get-MsolServicePrincipal -AppPrincipalId <App ID GUID>
Search for Directory Role by Name
$role = Get-MsolRole -RoleName "Company Administrator"
Now we can use the Add-MsolRoleMember command to add this role to the
service principal.
Add-MsolRoleMember -RoleObjectId $role.ObjectId -RoleMemberType ServicePrincipal -RoleMemberObjectId $sp.ObjectId
To check everything is working, lets get back all the members of the
Company Administrator role:
Get-MsolRoleMember -RoleObjectId $role.ObjectId
You should see your application in that list, where RoleMemberType is
ServicePrincipal and DisplayName is the name of your application.
Now your application should be able to perform any Graph API calls
that the Company Administrator could do, all without a user signed-in,
using the Client Credential Flow.
Let me know if this works!
In-addition to Shawn Tabrize's solutlion. We can acquire the token which's contains corresponding permission to call the Graph API. For example, if you were requesting using Microsoft Graph REST, the Directory.AccessAsUser.All (refer here). And you need to use the admin of that tenant to acquire this access token in this scenario.
To check whether the token contains the correct permission, we can decode it from this site.