Zoho Banner September 2011

Archive for the ‘Azure Active Directory’ Category

I recently had a challenge with a customer that had on-premises Skype for Business (SfB) and were looking to migrate to SfB Online. They did not want to federate the two infrastructures, but instead wanted to undertake a re-pointing of users at a given point in time by modifying the DNS records. When they introduced AAD Connect the default synchronisation included the SfB attributes, which is standard behaviour when AAD Connect detects that the schema extensions for SfB are present in on-premises AD. The presence of SfB-related user attribute values in the synchronisation flow caused SfB Online to detect all existing SfB on-premises users as hybrid. It meant my customer could not assign SfB Online access to synchronised users, which would have been a problem for testing the cut-over. The workaround for this was to modify the AAD Connect synchronisation rules to set the SfB attribute values to null.  The steps implemented to achieve this are shown below.

1. Stop the AAD Connect sync scheduler. 

From an elevated Powershell prompt run the following command

Set-ADSyncScheduler -SyncCycleEnabled $false

2. Open the Synchronisation Rules Editor and create an editable copy of the ‘In from AD – User Lync’ inbound synchronisation rule.



3. Set the new rule to have a higher precedence (lower numeric value) than the original rule. 



4. Leave the scoping filter as is, i.e. no change.



5. Leave the join rules as is, i.e. no change.



6. Edit the transformation for each of the shown values.  Change the flow type to Expression and the source to Authoritative Null.



7. Save the rule.

8. Start the AAD Connect Sync scheduler and run a full (initial) synchronisation by running the following Powershell commands:

Set-ADSyncScheduler -SyncCycleEnabled $true
Start-ADSyncSyncCycle -PolicyType Intial

9. Confirm that the synchronised users no longer appear as hybrid users in SfB Online.  Run the following Powershell command:

Get-CsOnlineUser | ft userprincipalname, interpretedusertype -AutoSize

Note. This command requires the Skype for Business Online Windows Powershell Module, available here.

The output should show your synchronised users with an InterpretedUserType of  ‘NoService’.  If any appear as ‘HybridOnPrem’ then the custom synchronisation rule has not taken effect.

The synchronised users should now be available to enable for Skype for Business Online.


Hopefully, this has been useful to you.  Let me know if you have any corrections or suggestions for improvements by adding a comment.


Last week I came across an issue when attempting to create a new custom synchronisation rule in Azure AD Connect. When I tried to finish the wizard and add the rule, I received the error: “Object reference not set to an instance of an object”.


The workaround is to add a tag to the rule on the Description page, as shown below.  The tag doesn’t need to be meaningful.


The issue appears to be specific to version 1.1.561.0 (July 2017) of AAD Connect. It wasn’t a problem in previous versions and it has been addressed in version 1.1.614.0 (September 2017).

For the latest of AAD Connect versions and version history, see https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-version-history


I hit this problem while working with Azure AD Connect at a customer earlier this week.  The situation was that AAD Connect had already been configured with Pass-Through Authentication, which was working as expected.  The next step was to enable Seamless Single Sign-On, but this failed with the following: ‘Failed to create single sign-on secret for True’.


The trace log file showed this:

[ 18] [ERROR] EnableDesktopSsoTask: Failed to create desktopsso secret for myadds.org. Exception message: System.Management.Automation.CmdletInvocationException: Exception has been thrown by the target of an invocation. —> System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. —> System.Runtime.InteropServices.COMException: The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)

I immediately thought this was probably an issue with the firewall between the server running AAD Connect and the on-premises AD Domain Controllers.  The difficulty I had was that my customer’s environment was really locked down and I didn’t have access to the firewall or to the tools I would normally use to troubleshoot something like this. So, basically I decided to try and reproduce it with my own Azure AD environment.

As expected, the problem came down to a missing firewall port (TCP 445).  This port is (as of 3rd August 2017) not listed in the port requirements on this web site (Table 1):


In my first test, I configured the firewall rules a per Table 1, i.e. without port 445 and attempted to enable SSO via AAD Connect.  I received the same ‘The RPC server is unavailable’ error.

I then removed SSO manually using the Powershell method.


In my second test, I tried to enable SSO using the Powershell method.  Again, I see the RPC error.


Looking at the firewall logs, I see a failed connection attempt to the ADDS DC on port 445.

2017-08-02 13:09:47 DROP TCP 50423 445 0 – 0 0 0 – - – SEND

After adding port 445 to the allowed firewall ports, I re-attempted disabling + enabling SSO using the Powershell method.  This time the cmdlet completes successfully.


The status now looked good and confirms that the missing firewall rule allowing traffic from the AAD Connect server to the DCs on port 445 (TCP) was the culprit.


Interestingly, it looks like I would have hit the missing TCP 445 problem when enabling Pass-Through Authentication (i.e. prior to enabling Seamless SSO), but for the fact that I chose to use an existing AD Forest Account.  If I had tried to let the Wizard create the account required for PTA it would also have failed due to TCP 445 not being available.

Hopefully this should give you enough to go on if you come across a similar issue.

This post provides a quick introduction to the features available with Azure Active Directory Business to Business (B2B) Collaboration – currently in Public Preview.  I’ll cover how to add someone outside your organisation to your Azure AD instance, as well  as how to assign administrative privilege over the Azure subscription to the external partner through RBAC delegation.

Let’s kick things off by adding the external partner via the new Azure Portal. In this example the external partner is named Badger Lafarge and has an Gmail account.  My Azure tenant is named Fish Eagle.

Once logged into the Azure Portal, select Azure Active Directory from the left hand menu.


Select Users and Groups from the presented options.


Select All Users


The full list of existing users will appear.  Select the Add option.


Complete all the required information for the users and any additional profile and group in formation. Note that you have the ability to enter the text that will be sent into the body of the invitation email sent to the user.


You will see that in this example I have chosen to add the user to a group named MSDN Subscription Admins. This group has been delegated the Owner role to the Fish Eagle MSDN subscription.  I’ll show where this is configured later in the article.


After completing the setup, select Create.  At this point an invitation will be sent to the user, as shown in the example (Gmail) below.


The user then clicks on Get Started.  At this point Azure will determine whether an account (either in a different Azure AD or a Microsoft Account) already exists for the user based on the email address.  In my example, the user Badger Lafarge does not have any account, so one needs to be setup.  This is the normal Microsoft Account process and as such I don’t need to show it here.


Note that the welcome message indicates the invitation relates to access to myapps.microsoft.com.  While assigning access to apps within an Azure tenant to partners is probably the most common scenario, it is not the use case here and can be ignored.

After completing the account setup, the external partner (Badger Lafarge) is presented with the MyApps portal.  This shows the B2B setup workflow has completed successfully.  You can then see the partner account present in Azure AD.  Note the globe icon that indicates the external status.


Now that Badger Lafarge has been set up correctly, he can log into the Azure Portal using the credentials he configured as part of the Microsoft Account creation.  You can see from the following screenshot that once logged into the Azure Portal the external account (Badger) has access to the resources available in my tenant within my MSDN subscription (Fish Eagle).


With the Owner role assigned to my MSDN subscription, Badger can now do pretty much anything he wants to with my Azure resources.  He can stop and start machines, delete storage accounts, create new resource groups, generally do a lot of damage and spend up large!  This is by way of a warning – with great power comes great responsibility – be careful how you assign permissions and use the principle of ‘least privilege’ as you would normally.

In case you missed it earlier, not all external partners you add are automatically assign Owner rights over your subscription.  That would be madness!  Instead, when I created Badger as an external partner in my Azure AD I chose to add him to the MSDN Subscription Admins group.  This is not a built in group.  Instead it is a group I manually created within my Azure AD with the specific purpose of assigning Owner permissions over my subscription using Azure’s RBAC features.  Of course I could have assigned him the Owner role directly (i.e. not using an Azure AD group), but where is the fun in that?  The screenshot below shows where the Owner role assignment is configured within the Azure Portal.


That’s basically it.  Once you have the external partner in your Azure AD you can do other tasks such as assignment to your Apps (exposed via the MyApps portal) and delegation within our Azure AD instance.

What I really like about the B2B feature is how easy it is to set up within the Portal.  Hopefully that is clear from this blog post.


The other day one of my customers was testing remote access to a web application via the Web Application Proxy (WAP). Everything seemed to working except some reports. These generated “HTTP Error 400. The request URL is invalid”. Given that the reports worked well inside the corporate network it pointed to an issue with the WAP.

Further investigation revealed that the requested URL for that generated the error was unusually long (approximately 500 characters).

The WAP uses HTTP.sys under the hood. HTTP.sys is a kernel-mode device driver that first drew breath in IIS 6.0 (shipped with the now unsupported Windows Server 2003).

As it turns out HTTP.sys imposes a 260 character limit on URLs. Fortunately, this limit is configurable by modifying the registry, as described in the following KB article:


The steps to increase the limit are:

  1. 1. Create a UrlSegmentMaxLength DWORD value under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters and set it to 600 (decimal)
  2. 2. Reboot the WAP server.

This resolved the issue for my customer. I hope it helps you too!


Here are two ways to find the GUID (also referred to as the TenantID) associated with your Azure Active Directory (AAD) instance.

1. Embedded in the URL in the Azure Portal

Log into the Azure Portal. Select Active Directory from the left hand pane. Click on the Active Directory instance you are interested in (you may have more than one). Copy and paste the URL into Notepad. It should look something like this:


The GUID is highlighted above.

2. In the registry of your Azure AD joined Windows 10 workstation

If you have a Windows 10 machine that you have joined to Azure AD then you can find the GUID as a key name in the registry in the following location:



Hopefully, you found this useful. Let me know what other Azure AD topics you would like to see.

This article explains how to link your O365 tenant to an existing Microsoft Azure subscription, so that you can manage your O365 users from within Azure. Why would you want to do this? Well, perhaps you just want to centralise your administration functions, but it also gives you other benefits, such as the ability to assign Multi-Factor Authentication (MFA) and to control the cloud applications to which the users have access.

Here’s how I did it…

I have an Office 365 Small Business tenant as well as a Microsoft Azure account that I fund through my MSDN subscription’s monthly credit. Until a couple of months ago I managed these as completely separate entities, logging in with separate credentials for each. Then a friend (thanks Kev!) sent me some information on how to link the O365 directory to my existing Azure account. The process is made possible by the fact that all O365 tenant identities are stored in Azure Active Directory (AAD). Here’s a brief overview of the process:

In this example I manage my existing Azure subscription using my Microsoft Account (formerly Windows Live ID) named passport@activedir.org.  My O365 tenant is named Badger Lafarge (badgerlafarge.onmicrosoft.com)

1. Sign in to Microsoft’s Azure Management Portal with your Account Administrator account, e.g. passport@activedir.org

2. Select Active Directory from the left hand menu bar.

3. Choose New from the bottom menu bar.



5. Choose Existing Directory from the drop down list




6. When re-directed to the sign-in page, sign-in with your O365 admin account credentials


7. Select continue when prompted and then sign back in with your Azure Account Administrator account


8. You should now see your O365 tenant listed as a new directory (see below)



That’s it! At this point you are ready to manage your O365 accounts via the Azure Portal (or via Powershell of course).

In a follow-up article I will explain how to enable these accounts for multi-factor authentication (MFA).