Azure AD Sync

Azure AD Connect – User Name or Password Is Incorrect

Posted on November 21, 2015 Updated on March 24, 2016

Recently when setting up a new tenant for Azure / Enterprise Mobility Suite, the Azure AD Connect software gave me error “the user name or password is incorrect”. This was caused by using the .onmicrosoft.com account that was set as the Subscription administrator.

aadc1

To resolve this, create a new Co-Administrator account in the Azure AD Premium console. Under Settings > Administrators, create/add a new user that will be a co-administrator.

aadc2

Next, go to All Items, click the domain, select Users, then select the new co-administrator. Change the Organization Role to Global Admin.

aadc3

After completing these quick steps, then Azure AD Connect will allow the wizard to continue and complete the setup!

aadc4

This entry was posted in Azure, Troubleshooting and tagged Azure AD Sync.

References that AADP will not impact O365

Posted on April 21, 2015 Updated on April 9, 2015

I was recently asked by a customer to provide proof that registering for Azure Active Directory Premium would not cause a production change to their existing O365 implementation. Unfortunately, this is not specifically stated anywhere in Microsoft documentation. But the references below are what I found which imply that there would not be an impact to the business.

https://msdn.microsoft.com/en-us/library/azure/dn629581.aspx?f=255&MSPPError=-2147217396#BKMK_SubRelationToDir
1. “Every Azure subscription has a trust relationship with an Azure AD instance. This means that it trusts that directory to authenticate users, services, and devices. Multiple subscriptions can trust the same directory, but a subscription trusts only one directory. You can see which directory is trusted by your subscription under the Settings tab. You can edit the subscription settings to change which directory it trusts.”
2. “This trust relationship that a subscription has with a directory is unlike the relationship that a subscription has with all other resources in Azure (websites, databases, and so on), which are more like child resources of a subscription. If a subscription expires, then access to those other resources associated with the subscription also stops. But the directory remains in Azure, and you can associate another subscription with that directory and continue to manage the directory users.”
3. The key evidence is that the directory remains in Azure and will work with other subscriptions (e.g. O365)
https://msdn.microsoft.com/en-us/library/azure/jj573650.aspx?f=255&MSPPError=-2147217396#BKMK_ManageDefaultDir
1. “There are no costs for using Azure AD. The directory is a free resource. There is an additional Azure Active Directory Premium tier that is licensed separately and provides additional features such as company branding and self-service password reset.”
2. The key evidence is that AADP is an additional “tier” to Azure AD
http://blogs.technet.com/b/tune_in_to_windows_intune/archive/2014/03/11/what-happens-to-the-data-when-my-trial-expires.aspx “
1. “Trials live in the following phases: 30 days active, 30 days in grace period, 30 days disabled. Subscription is then deprovisioned”
2. “Once the final subscription (of any service like Office365 or Intune) is deprovisioned from a tenant, then the countdown starts to where that tenant is then deleted from Windows Azure Active Directory (WAAD).”
3. The key evidence is that AADP is a subscription (though not directly named in this article dated in 2013)
https://msdn.microsoft.com/en-us/library/azure/dn532272.aspx
1. Azure AD Premium can be considered as the paid add-ons for Azure AD free edition
2. Based on article Azure Active Directory Editions, any common features provided by Azure AD free edition will not be changed even if we upgrade free edition to premium edition:
  1. Directory as a service,
  2. User and group,
  3. management using UI or Windows PowerShell cmdlets,
  4. Access Panel portal for SSO-based user access to SaaS and custom applications
  5. User-based application access management and provisioning
  6. Self-service password change for cloud users
  7. Directory synchronization tool – For syncing between on-premises Active Directory and Azure Active Directory
  8. Standard security reports

This entry was posted in Azure, Windows Intune and tagged Azure AD Sync.

Azure AD DS Sync Account Permissions – Replicating Directory Changes

Posted on March 27, 2015 Updated on March 26, 2015

Microsoft has a decent outline for getting started with setup of the Azure AD Sync tool. One of the prerequisites is to prepare the AD account used for the synchronization of passwords is to grant it permissions for “Replicating Directory Changes” and “Replicating Directory Changes All”. This blog post serves as a quick guide on how to configure that.

1. Within ADUC, right-click on the domain and select Delegate Control

2. Click Next

3. Add the AD service account that will be used

4. Select to create a custom task delegation

5. Select to delegate to This folder…

6. Scroll through the list and find both “Replicating Directory Changes” and “Replicating Directory Changes All”

7. Finally, complete the wizard

This entry was posted in Azure and tagged Azure AD Sync.

Azure AD Setup – Sync Service Account – Login Failure

Posted on March 25, 2015 Updated on March 25, 2015

When setting up Azure AD synchronization tools, such as Azure AD Connect, there is the option to specify an on-premise AD user/service account to be used for the local sync authentication. During the setup wizard, you may encounter the error “Logon failure: the user has not been granted the required logon type at this computer” (image below).

This error occurs may be occurring if you’re installing Azure AD sync tools on a domain controller (DC), and the service account cannot login to the DC. In most cases, logon rights to DCs are limited to domain administrators. And if you’re following the best practices for Azure AD sync, then the service account is a low-rights domain user, and not an administrator.

Fortunately the fix is quite simple. To add logon rights, simply add the service account into the Default Domain Controllers group policy. The appropriate setting is Computer Configuration >> Policies >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment, then add the account into the “Allow log on locally” policy.

After performing a gpupdate on the domain controller, you’ll be able to click the install button and get on your way!