Category Archives: Azure Active Directory

Office 365 Management APIs prevent deleting an Azure AD Tenant

Have you ever tried deleting an Azure Active Directory Tenant? Sometimes you may need to do this if you have multiple test directories in your Azure tenant. Today I’m going to discuss one specific issue which had prevented me from deleting couple of test Azure AD tenants I had in my Azure subscription.

Scenario

I’ve had two Azure AD tenants which I’ve deployed for testing and wanted to delete from my subscription. As for the preparations I deleted all users, groups and application in both directories except the default user (Microsoft Account). As soon as I hit DELETE it was prompting below error.

“Directory contains one or more applications that were added by a user or administrator.”

Now I was pretty much sure that I deleted all the SaaS applications from both directories but I went ahead and checked the application list just to be sure.

Office365 API (1)

I can see one application called “Office 365 Management APIs” in the list which cannot be deleted and none of the directories were originated from Office 365 subscriptions.

Office365 API (2)

Fix

I created a new global administrator user in each directory additional to the default Microsoft Account I had. (user@domain.onmicrosoft.com). Then I signed into my Azure AD tenant using Azure AD PowerShell. Here I’ve used the Connect-MsolService cmdlet and used the credentials of the new admin account to sign in.

I’ve executed following cmdlet to remove all SaaS applications from Azure AD. Note that there may be failures  because some of the applications simply can’t be removed from Azure AD but it shouldn’t be a problem to delete the particular Azure AD tenant.

Get-MsolServicePrincipal | Remove-MsolServicePrincipal

When I switched back to Azure portal after exiting the PowerShell Session I could still see the Office 365 Management APIs application, but I decided to delete the global administrator for each directory and hit the DELETE button. Guess what I could successfully remove both Azure AD tenants without any issue.

This TechNet article came in very handy to troubleshoot this issue and contains more of the deletion scenarios for an Azure AD tenant.

Office 365 woes | Password Sync doesn’t synchronize with Azure AD Connect

Microsoft has retired DirSync tool and introduced one tool to synchronize your on-premises identities to Microsoft Azure Active Directory. This tool “Azure AD Connect” can be used in both Office 365 only & Azure AD without O365 scenarios to extend your local AD to the cloud. One of the key advantages is the ability to synchronize the password hash of local AD account with Azure AD where the users will have a single identity & password rather than two different sets of credentials. This is a hash of the password hash stored in your local AD not clear text password. This feature is heavily used in Office 365 deployments to provide SSO (Single/Same Sign On) capabilities to the users to provide single consolidated identity.

I’m working on an Exchange 2013 Hybrid setup these days where one of the prerequisites is to setup Directory Synchronization. We have identified the password hash sync is also required in this situation. When I completed the Azure AD Connect setup wizard I got below error at first. If you are unfamiliar with configuring AAD connect you can refer here.

Now surprisingly I cannot connect to Azure AD via PowerShell and got the same error. My credentials were correct and I decided to check that with my laptop (different ISP) and it was a success. Surprisingly the local ISP has some connectivity issues with Office 365 IP ranges and frequent timeouts were evident and then we changed the network path to a different ISP to resolve the issue.

Since the wizard was completed and no accounts were synced, I decided to go for a manual force sync with PowerShell. Notice the path for DirSync binaries; it hasn’t been changed in AAD Connect as well. The option Initial will do a full synchronization where the option delta will do a delta sync only.

C:\Program Files\Microsoft Azure AD Sync\Bin> .\DirectorySyncClientCmd.exe Initial

All the user accounts were properly synced this time but when I tried to login to Office 365 using an AD account it always says that the password is incorrect.

Investigation

When I tried to review the existing configuration for Azure AD connect I noticed that it reports the password sync as disabled. Uninstalling the tool, installing again and performing couple of full sync were useless and still I was getting the same issue when I’m trying to login.

  1. Verified password sync is disabled via using PowerShell

    Following cmdlets have been used to verify above and I noticed password sync was in fact disabled although I checked the option in Azure AD connect setup.

    Import-Module ADSync

    Get-ADSyncAADPasswordSyncConfiguration -SourceConnector <‘LOCAL DOMAIN NAME>

  2. Enabled password sync via PowerShell

    Set-ADSyncAADPasswordSyncConfiguration -SourceConnector <‘LOCAL DOMAIN NAME> -TargetConnector <‘xxxxxxx.onmicrosoft.com – AAD’> -Enable $true

After executing above cmdlets and another full synchronization I noticed below error has been logged in Directory Synchronization event log, still with no luck with passwords.

In the Synchronization Service Manager (C:\Program Files\Microsoft Azure AD Sync\UIShell\miisclient.exe) displays status of “stopped-extension-dll-exception” for operations on the Microsoft Azure Active Directory Connector.

Solution

  1. The “stopped-extension-dll-exception” error was due to the fact that password policy of Azure AD Sync account, set to expire after a certain number of days. This account is created automatically once you run the Azure AD Connect wizard.

    To set the password to never expire following cmdlets were used.

    PS C:\> Connect-MsolService

    Provide your O365 admin credentials to connect to Azure AD service.

    PS C:\> Set-MsolUser -UserPrincipalName <Sync Account UPN> -PasswordNeverExpires $true

  2. Make sure the sync account is a global administrator in your office 365 tenant. In my case it was not and I have assign the user role Global Administrator to that account. You can refer the original Microsoft Office 365 support article on how to do that here.
  3. To overcome the “Password Synchronization has not been activated for this company” error is logged in Event Viewer I executed below cmdlet again in PowerShell.

Set-ADSyncAADPasswordSyncState -ConnectorName < ‘xxxxxxx.onmicrosoft.com – AAD’> -Enable $True

Morale of the Story

When I ran the Azure AD Connect wizard for the first time I selected Start the synchronization process ASAP option as below. Due to the issues I have faced with internet connectivity it wasn’t much of a success.

Also I didn’t select the Use an existing service account option during installation. By default, Azure AD Connect will create a local service account for the synchronization services to use in that case the account that wasn’t a global admin. The user role (which should be global admin), password expiration policy & password is unknown in this automatically created account. Therefore I highly recommend to use an existing global administrator account in your O365 tenant to overcome this.

Also always use the Customize option where you have control over additional configuration options such as above service account while setting up Azure AD Connect.

Connect Windows 10 Devices to Azure AD | Part 2

In my last post I explained how to join a Windows 10 device to Azure AD. Now it’s time to check how we can enforce organizational policies to same. Before that let me logoff from my standard user account and come back to log on prompt.

Win10 Join Azure AD 12You can see that my organizational account is displayed in the log on screen. After I have logged in it will take some time to setup the Apps and will test your patience (lol kidding). Notice that in-between this time you will be prompted to accept security policies enforced by your Azure AD tenant. Click Enforce these policies button to accept.Win10 Join Azure AD 10Now to test the functionality once logged in I’m going to launch the default Mail application. Voilà! my Office 365 e-mail account is already configured there.Win10 Join Azure AD 13Since my Office 365 Azure AD tenant has been on-boarded to my Azure account I can actually inspect the the devices that I have enrolled. For that I’m going to view the properties of that particular user.Win10 Join Azure AD 11Okay well where are those security polices I talked about. By default when you enroll a Windows 10 device policies such as password expiration will be provided by Azure AD. But if you need more granular control like device sweep, selective wipe, full wipe you’ll have to integrate Microsoft Intune with it. My office 365 E3 tenant already has MDM capability enabled with Intune. Therefore I can modify policies as I want from Office 365 Admin center.Win10 Join Azure AD 14Although it may seem a long shot Microsoft’s ultimate goal is to enable mobility for all users. I think this will be a huge leap assisting that vision.

Connect Windows 10 Devices to Azure AD | Part 1

Windows 10 is getting launched within next two weeks. Did you know that SMEs can get rid of their on-premise AD if they are just using it for authentication and compliance (Well Azure AD cannot replace group policies still)? Today I’m going to explore the Azure AD join feature that we have with Windows 10. I’m using a Windows 10 Insider Preview 10622 build for this.

Prerequisites

  • Azure AD Tenant – If you are using Office 365 or has an Azure subscription you already have an Azure AD tenant or can create one.
  • Windows 10 Insider Preview installed PC – The latest release would do.
  • Check wither your Azure AD tenant is allowed to enroll devices. You can check this from Azure Portal as below. Note that this feature is still in preview.Win10 Join Azure AD 09

Now let’s take a look at how we can achieve this.

  1. In your Windows 10 device, go to Settings section. There you see and option Join or Leave Azure AD. Remember to check the device is activated or not first.Win10 Join Azure AD 01
  2. It will redirect to System properties window. You can see my device is in workgroup. Now I’m  going to select Join Azure AD.Win10 Join Azure AD 02
  3. Click Continue in the authorization page.Win10 Join Azure AD 03
  4. I’m going to use my Office 365 Azure AD tenant for this task. Notice that if you have AAD premium enabled you can see your custom logo as well.Win10 Join Azure AD 04
  5. Click Join when it prompts for verification.Win10 Join Azure AD 05
  6. Now it will take about 10 minutes for the device enrollment to complete.Win10 Join Azure AD 06
  7. If all is set you can click Finish.Win10 Join Azure AD 07
  8. When I check the System properties I can see that my device is joined to my Office 365 Azure AD tenant.Win10 Join Azure AD 08Now that you have successfully joined the PC to Azure AD in the next post let’s see how we can enforce your existing security policies to this device.

Replication Failure in Azure Site Recovery

Azure Site Recovery is a great product for those who want to setup their DR environment with a minimal cost. It is based on Hyper-V replica technology for Hyper-V workloads and supports replication VMware & Physical server workloads to DR as well. Today I’m going to discuss a common issue one can encounter when enabling ASR replication to the cloud.

I’ve been working on an ASR setup during couple months and encountered strange issue when I enabled replication in protected VMs.

The enable protection job fails with below error.

Job ID: f9f84765-b18c-4002-96a4-d420dfb76ea6-2015-05-14 10:00:29Z

Start Time: 5/14/2015 3:30:29 PM

Duration: 10 MINUTES

Protection couldn’t be enabled for the virtual machine. (Error code: 70094)

Provider error: Unable to complete the request. Operation on the <Hyper-V Node>  timed out.

Try the operation again. (Provider error code: 2924)

Possible causes: Protection can’t be enabled with the virtual machine in its current state. Check the Provider errors for more information.

Recommendation: Fix any issues in the Event Viewer logs (Applications and Service Logs – MicrosoftAzureRecoveryServices) on the Hyper-V host server. If this virtual machine is enabled for replication on the Hyper-V host, disable this setting. Then try to enable protection again.

UTC Time: Thu May 14 2015 10:15:59 GMT+0530 (Sri Lanka Standard Time)

Browser: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36

Language: en-us

Portal Version: 5.4.00298.11 (rd_auxportal_stable.150511-1702)

PageRequestId: a04f08ed-8932-43f2-95bc-2faab60ed958

Email Address: xxxxxx@outlook.com (MSA)

Subscriptions: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx

In the particular Hyper-V host following error has been logged in Event logs.

Enable replication failed for virtual machine ‘XXXXXX’ due to a network communication failure. (Virtual Machine ID 807780f6-bb7c-48d5-937d-4857a654dec3, Data Source ID 2256321007502018113, Task ID 8c1a5d7d-0693-4d6b-9243-37cc5e96a7d6)

This ASR setup was a on-premise to Cloud scenario with a single SCVMM server.

After spending a good number of troubleshooting hours I finally figured out what went wrong. The Hyper-V Hosts themselves need Internet connectivity to replicate the VMs to ASR. If you cannot enable direct Internet connectivity on the Hyper-V hosts you should do so via a proxy setup. You can change the proxy settings in ASR Provider in Hyper-V Host.

ASR replication requires traffic to be sent over port 443 (SSL) and in my case only the SCVMM server was configured with Internet access. If you are using a proxy server you may need to consider allowing below for successful replication.

  • *.hypervrecoverymanager.windowsazure.com
  • *.accesscontrol.windows.net
  • *.backup.windowsazure.com
  • *.blob.core.windows.net
  • *.store.core.windows.net
  • Allow the IP addresses in Azure Datacenter IP Ranges and HTTPS (443) protocol. Also your IP address whitelist should contain that of your primary region and  West US IP address ranges.

Azure AD | Deletion Issues Part 2

If you are just messing with Azure AD for testing sometimes you want to delete any directories that you created or subsequently on boarded (i.e Office 365). Have you ever faced a scenario where you cannot delete a directory? Let’s see why is that.

You can delete an Azure AD as long as it meets below prerequisites. This ensures that users will not impacted by such action.

Scenario 1

There cannot be any active Multi-Factor Authentication Providers linked to the directory that you are going to delete.

Scenario 2

You have to delete all the users except the global administrator of that directory prior you attempt to delete the directory itself. No need to delete any groups. You can refer my previous blog post on hoe to delete orphaned Azure AD accounts if you need any instructions.

Scenario 3

All applications associated with that directory should be removed first. Remember if you have added an application from the Azure AD Application Gallery (i.e SalesForce) you cannot delete the directory at all. This is a current limitation on Azure AD which Microsoft promises a fix soon.

Scenario 4

If your directory is associated with any of the Microsoft Online Services such as Office 365, Intune or Azure AD Premium you cannot delete the directory from the portal. This is chicken and egg problem since those services use that directory for authentication. If so badly wants to do that, you’ll have to contact Microsoft Support to get that done for you and it is a lengthy process.

So remember before you start cursing Azure Team, keep in mind these little tips. I for one personally want to get rid of Scenario 3 & 4 because sometime customers are doing mistakes for signing up for multiple identities with different Microsoft Online Services and later suffer from dilemma of deletion.

Deleting an Azure AD is irreversible. So think twice before you pull the plug.

Removing orphaned local AD accounts from Azure AD

Is anyone wondering how to remove orphaned local AD accounts that were synchronized to Azure AD using DirSync? Let’s see how we can achieve this with some simple steps and little bit of PowerShell.

Scenario

Your on-premise AD DS server is no longer functional. That means loacl AD is dead.

Problem

When AD DS is no longer available you cannot remove any objects that has been synced to Azure AD. Usually if you want to deleted a synced object you should do that in local AD.

Let’s see how we rectify this issue.

When an account is orphaned you no longer see the Delete option.

Azure AD Delete User 7

  1. If you haven’t done already, install the Azure Active Directory Module for Windows PowerShell. You can find guidelines here.
  2. Open Windows Azure AD PowerShell & connect to your Azure AD tenant. If you do not know how to do that refer here.
  3. Remember for step 2 you cannot use the Microsoft Account associated with your Azure Subscription. You should authenticate using a global admin account for the particular azure AD tenant. Otherwise you’ll get an error like below.Azure AD Delete User 4 Azure AD Delete User 5
  4. Disable DirSync using below PowerShell cmdlet. Note that it can take up to 72 hours to complete this operation depending the size f your directory.
    Set-MsolDirSyncEnabled –EnableDirSync $false
  5. To verify DirSync has been fully disabled or not run below cmdlet. If it is disabled you should get a false value. This might take a while.
    (Get-MSOLCompanyInformation).DirectorySynchronizationEnabled

    Azure AD Delete User 6

  6. Alternatively you can disabled Dirsync via Azure Portal as well. Select the directory > select DIRECTORY INTEGRATION > Select DEACTIVATED from Directory Synchronization section.Azure AD Delete User 2 Azure AD Delete User 3
  7. Now you can see that orphaned account that were listed as local AD account are converted to Windows Azure AD accounts and the delete option is available.Azure AD Delete User 7Assuming you want to delete the directory you can safely do that as well. But remember if you have subscribed into any Microsoft Online Service like Office 365, Azure AD Premium, Intune etc… you cannot delete the directory and currently it’s a limitation in Azure AD.

 

Configuring Azure AD Connect Preview

Microsoft has introduced a new tool to synchronize your on-premise active directory with Azure AD. Previously  DirSync & AAD Sync were the tools used to achieve this. From my experience DirSync was mainly focused on Office 365 deployments which later neede much more improvements when Azure came in to GA.

From now on there will not be new releases of above tools and the new Azure AD Connect will be production ready within the next 3 months as per Microsoft. This tool will unify the capabilities of DirSync & AAD sync providing a single UI capable of much more.

All the new features introduced with AAD Sync are included in the Azure AD connect as well.

  • Multi-forest synchronization is possible for Active Directory and Exchange
  • Password write back from Azure AD to on-premise Active Directory

Other features like OU & Attribute based filtering from DirSync remain same. Let’s see how we set up this little beast.

  1. Download & Install AAD Connect tool from here.
  2. Open the Azure AD Connect tool in your desktop and proceed with the license agreement.AAD Connect 1
  3. You will be prompted to install any per-requisites that are needed. These include Microsoft .NET Framework 3.5, MS Online Services Sign in Assistant, Windows Azure Active Directory Module for Windows PowerShell & Azure AD Sync Engine. It’s best that you install first three prior installation to avoid issues.AAD Connect 2 AAD Connect 3
  4. Provide your Azure AD Credentials in the next screen. Note that if you are using Office 365 this would be your global administrator credentials. If you are using Azure AD standalone I would suggest that you create a separate user called DirSync which has global administrator rights for your Azure AD.AAD Connect 4
  5. You can either select Use Express Settings or Customize depending on your requirement. If you are using this tool for Same-Sign-On you can safely use Express settings. Here we are proceeding with Customize option.AAD Connect 5
  6. If you only want Same-Sign-On (Same user name & password as in on-premise AD but will be prompted for credentials) choose Password Sync. If you have implemented ADFS for Single-Sign-On (Users will be authenticated from local AD and no need to enter credentials once logged into the system using domain credentials) Select Single Sign On.AAD Connect 6
  7. Now you have to enter the credentials for your local AD. Note that you can add multiple directories here.AAD Connect 7 AAD Connect 8
  8. If you are planning an Exchange Hybrid Deployment where some user mail boxes will reside on-premise and some are in Office 365 select Exchange Hybrid Deployment. Selecting Password write-back will enable to replicate the password from Azure AD to local AD and  will allow users to self-reset their password if they are assigned Azure AD Premium licenses.AAD Connect 9
  9. The next screen is vital if you are syncing multi-forest environment.  But since I don’t have that I’m proceeding with the first option.AAD Connect 10
  10. You can configure the object mapping in the next screen. As my on-premise UPN & Cloud UPN are same I’m leaving this as default.AAD Connect 11
  11. If you want to configure filtering uncheck the Initial Synchronization check box. You can configure filtering by launching the FIM client  later. This tool is available at  C:\Program Files\Microsoft Azure Active Directory Sync\UIShell\miisclient.exeAAD Connect 12AAD Connect 13
  12. If synchronization is successful you will see the user account from your local AD in your Azure AD. Just in case if you cancel the wizard prior step 11 when you run the tool next time you can resume from where you have left. AAD Connect 14 AAD Connect 15 AAD Connect 16

One important thing. This tool is not still GA so if you are deploying this to production use at your own risk or wait few days till this becomes GA.