OnCloud

Using Azure AD B2B collaboration support for Google IDs and Conditional Access

Mike Duddington — Thu, 30 Aug 2018 13:16:25 GMT

Hi, Alex Simons announced the public preview of Azure AD B2B Collaboration support for Google IDs, so i thought I'd share my findings on configuration, user experience and bring Azure AD Conditional Access into the mix. The first step to setting this up is to add Google as an identity provider in your Azure AD tenant. This has been beautifully documented by the Azure AD team here. Once you have followed those steps then you are ready to roll... Now it's time to add a guest user. There are numerous ways to invite guest users but for the purposes of this post I'm inviting from the Azure AD Portal. NOTE: At the time of writing this document it's only @gmail.com users that are supported. Once invited the user then the user receives an invitation. The user then clicks "Get Started" and then they are prompted to authenticate with their GoogleID. Once successfully authenticated the user then has to review the permissions and "Accept". Access is then provisioned. The user is now logged on using their Google ID! Now lets have a look at what that account looks like in Azure AD. The user is now provisioned in Azure AD as a "Guest" user and the "Source" is Google. You may be aware of a recent public preview which enables you to target Conditional Access policies at "guest users". This is a great feature and allows you to target all guest users (including GoogleID's) to provide additional protection when they are accessing your organisations resources. Let's set up a Conditional Access Policy which will enforce Azure Multi-Factor Authentication for all guest users. Create a new Conditional Access Policy and select "All guest users (preview)", make the relevant "Cloud app" assignments and any additional conditions you would like to test. NOTE: This will apply to all users with the userType attribute set to guest Now select "Require multi-factor authentication" as a control to enforce when granting access. As always with Conditional Access make sure you understand the impact of the policy and always test before enabling in production. Let's have a look at the user experience. Access the resource (At this stage the URL must include the tenant context e.g. https://myapps.microsoft.com/?tenantid=) and the user is prompted for authentication. Once the user has entered their GoogleID credentials they are prompted with the following. The user is now forced to register their MFA details, undergo verification and then they get access to the resource. Subsequent authentications the user is prompted for MFA. In summary, invited users can now use their GoogleID to access Azure AD integrated resources. Your organisation also has the ability to enforce a stronger level of authentication with Conditional Access to ensure a higher level of protection for your companies resources. Thanks for reading!! MD Follow me on Twitter for future posts.

Deploying Azure AD Password protection for Windows Server Active Directory

Mike Duddington — Thu, 21 Jun 2018 15:02:24 GMT

Hi, As you will have seen from Alex Simon's announcement yet another great Azure AD public preview has landed! "Azure AD Password Protection and Smart Lockout" will provide further protection to your organisation from weak passwords and bad actors. Despite organisations setting stringent password complexity rules, users are still setting passwords that are relatively weak but do satisfy password complexity requirements. For example:

Predictable combinations: e.g. "June2018!" & "CompanyName12!"
Common passwords with predictable formats: e.g. "Password12!"
Common character substitutions: e.g. "Pa$$w0rd12!"

"Azure AD Password Protection and Smart Lockout" protects by preventing users from setting their passwords to common, weak and risky ones and by preventing bad actors from trying to brute force those accounts. This post will focus on the "Password Protection for Windows Server Active Directory" components that allow you to extend the password protection you get in Azure AD to your on-premises Active Directory. I will walk through the key features, example deployment and user experience. To use this feature an agent is installed on to your domain controllers and a proxy agent is also installed (on the AAD Connect server in my example). The "Password Protection Proxy" proxies password policy requests from the DC's "Password Protection Agents" so your DC's aren't connecting to the internet. Link to the preview agents here.

Key Features

The key features this component provides are:

Protect all password set and reset operations in Azure and Windows Server Active Directory by ensuring they do not contain weak or leaked password strings.
Control Azure AD password protection for both Azure AD and on-premises Windows Server Active Directory from a unified control panel in Azure AD portal.

Deployment

Domain Controller(s): I execute the AzureADPasswordProtectionDCAgent.msi on each of my domain controllers (can be deployed with SCCM and installed silently). NOTE: this agent doesn't connect to the internet, all updates are done via the Password Protection Proxy. Click "Next" and select all the defaults to complete the install. A restart is required so plan carefully to ensure no disruption. We now move on to the installation of the Password Protection Proxy. Password Protection Proxy: On my AAD Connect server I install the AzureADPasswordProtectionProxy.msi. Select all the defaults to complete the install. That's all the installations completed so its time to run a couple of PowerShell cmdlets. The cmdlets you need to run are detailed below and they are required to register the Forest and Password Protection Proxy with Azure AD\Active Directory. Some things to note:

For each cmdlet I was prompted for a credential for the Azure AD instance (this needs to be Global Adminstrator).
You also need to be logged in as a domain admin to run these cmdlets (Root Domain).
I ran these cmdlets from the server the Password Protection Proxy was installed on.

Lets have a look at the portal and enable Azure AD Password Protection for Windows Server Active Directory. Navigate to the Azure AD blade in the Azure Portal > Authentication methods > Password protection (Preview) and you will see the below. I click "Yes" for "Custom banned passwords. ("Dudders2018!" is the example I will be using) I click "Yes" for "Enable password protection on Windows Server Active Directory" I select a mode. "Enforced" will prevent banned\custom passwords from being set. "Audit" will log when a banned\custom password has been set.

User Experience

We are going to test 2 scenarios with the Mode set to "Enforced".

Trying to set a password that we have defined on the "Custom banned password list"
Trying to set a password that Azure AD has detected as weak\risky.

NOTE: When deploying it is strongly recommended to start Password Protection in "Audit" mode. This will help you gauge the level of weak passwords being set and plan education for users accordingly. Let's try and reset my password to "Dudders2018!" It fails to set, displays the standard password complexity message and logs the following events in the authenticating DC. Let's try and reset my password to "Password12!" It also fails to set, displays the standard password complexity message and logs the following events in the authenticating DC. I tried to set "June2018!" (which isn't in the custom list) as a password and that also failed as Azure AD has already defined this pattern of passwords as weak\risky. Just to prove that this is working, I change the mode to "Audit", wait for the DC's to update the local policy and then try and reset the password to "Dudders2018!" & "June2018!". It lets the banned\weak passwords get set but the following event log is set. This could be useful when you're considering rolling out this feature to see how many users are using passwords that are considered weak or at risk. Hope thats useful! MD @Dudders1

Blocking Legacy Clients with Azure AD Conditional Access

Mike Duddington — Wed, 06 Jun 2018 13:47:37 GMT

Hi, A great new feature has been added to Azure AD Conditional Access that provides the ability to block access from legacy clients (In preview at the time of writing this post). I've had many customers ask for this capability so I thought I'd put together a quick run though on how to configure it and the user experience for a legacy client (Outlook 2010). The "legacy clients" we are referring to are the non ADAL\Modern-Auth clients that are using legacy authentication methods (more information here) A good example being Basic Auth over SSL used with Outlook 2010 and below. This presented a challenge for some customers as they would configure Conditional Access Policies and they wouldn't apply to users using these older clients (and therefore have to use more clunky methods to block these clients). Below is an example of a Conditional Access Policy that blocks access from all legacy clients to all Microsoft Cloud Applications. I have created a Conditional Access Policy that is targeted to group of users and all cloud applications. (please target Conditional Access Policies carefully and always test on a small subset of users\applications before rolling out!). Within the "Conditions" > "Client apps (preview)" blade there is now a "Other clients" checkbox. As this is a "Condition" it allows you to target all "other clients" aka legacy clients and apply a "Block" without affecting your more modern ADAL clients (e.g. Office 2016). NOTE: There is also a "Modern authentication clients" condition which allows you to target a policy at ADAL\Modern Auth clients. Before enabling the policy you need to be aware of a couple of things (more info here).

Once enabled this policy could take up to 24 hours to apply.
Configuring this policy for “Other clients” will apply to all clients that are using legacy authentication methods. You should use this to test on a small subset of users\apps and once you are clear on what impact the policy will have then consider rolling it out to a wider scope.

Now enabled, the next day I open Outlook 2010 and I'm prompted for credentials. Despite entering correct credentials the authentication is denied and user is re-prompted. I would recommend communications to helpdesk and users in advance so that users don't mistakenly think there password is incorrect. Outlook 2016 and other Modern Authentication Clients continue to work as expected. Hope thats useful! MD @Dudders1

Getting the best out of Azure AD

Mike Duddington — Fri, 27 Oct 2017 09:19:14 GMT

Hi, I spent some time with a customer yesterday who had a particular requirement around securing access to Office 365. After a quick discussion it emerged they had paid for Azure AD Premium (via EMS licensing) but weren't using key features that would help address their requirement. After 10 mins of walking through Azure AD features we looked at Conditional Access and discussed what policy to deploy to meet their requirement. This got me thinking...what "no brainer" Azure AD features would I recommend customers deploy\use straight away? This is my top 5 list. (some features only require a single Azure AD Premium License, some require all users to be licensed and some require a small number of licenses.) 1.Enable Azure AD Privileged Identity Management (PIM) - You only need Azure AD P2 licenses assigned to administrators to use this. PIM will add a change control\approval process to the use of Azure AD\Azure admin accounts to provide "Just in Time" access. It achieves this by converting the type of your Azure AD admin roles from "permanent" to "eligible". This allows your organisation to approve (or deny) requests for administration rights for "eligible" administrators as and when they are needed. A very important tool to further protect the most important accounts in Azure AD. PIM controls the who, when and for how long...you still need to control the what. The principles of "least privilege" still apply and regular reviews of Administrators access need to be performed. Azure\Office 365\Azure AD have extensive RBAC models but it is easy to create custom roles to ensure that the bare minimum is granted to an administrator. PIM and "Access Reviews" helps you determine what administration roles have access to, when the access has been used and you should perform regular reviews as to what administration rights an individual should have. 2.Configure Azure AD Conditional Access - This functionality is included with Azure AD Premium and licensed on a per user basis (if you have EMS licensing then you likely are covered for those users). Conditional Access works by providing you the ability to allow\deny access or potentially step up authentication based on the following parameters. (In my customers scenario we were able to set up a policy and apply to test users within minutes)

Group membership - Allow users to access a resource if they are a member of a group.
Location - Allow, Deny users based on the location from which they are trying to access resources (IP\Country Based).
Device Platform - Allow or Deny users to access a resource based on the OS of the device they are trying to access from.
Device State - The ability to enable\disable a device and include the state of the device in the authorisation decision. i.e. require that users accessing Exchange from a browser on an unknown device perform MFA.
Sign-in and user risk - Advanced protection to determine the risk of the access request. I.e. user is attempting to logon from USA and had previously logged on from UK 5 mins earlier (Available with Azure Identity Protection - P2).

3.Enable Azure MFA - Having MFA enabled is obviously a good idea. If you have Azure AD Premium for your users then you are able to enable them for MFA and use Conditional Access to determine when it should be invoked. i.e user is on an unknown device, location based, risk level etc. In particular I would recommend the following as a minimum.

MFA for administrators is a must have. If you don't have Azure AD Premium for your users but do have Office 365 E3 licencing then you do have MFA licences for Azure administrators.
Enroll your users in MFA (MFA Registration Policy provided with Azure AD Identity Protection - P2) even if you don't plan to enforce MFA yet. Reason being if you need to react to an event then MFA is a great tool to step up security. Having users enrolled in MFA means that you can do this quickly.

4.Enable Azure Connect Health - AADConnect is an integral part of an organisations identity management. Azure AD is the identity platform for Azure, Office 365 and potentially lots of your 3rd party SaaS applications. The health of these services are very important and when it comes to identity its important that users are provisioned, de-provisioned and able to log on in a secure and reliable fashion. Azure Connect Health monitors your AADConnect and AD FS services and reports errors to you. Accessing the Sync Error Report doesn't require an Azure AD Premium license but you do need AAD Premium Licenses for the Azure Connect Health agents you deploy. It's a great tool to provide visibility of a key part of your identity management infrastructure. 5.Use Azure AD Reporting - Reporting comes with all editions of Azure AD and its a valuable feature to gain insight into what is happening with Azure AD users and a place to review the Security\Auditing that is provided with the service. The levels of security reporting depend on the licencing you have. Its broken down in to 3 types:

Azure Active Directory Free and Basic editions, you already get a list of users flagged for risk and risky sign-ins.
Azure Active Directory Premium 1 edition extends this model by also enabling you to examine some of the underlying risk events that have been detected for each report.
Azure Active Directory Premium 2 edition provides you with the most detailed information about the underlying risk events and it also enables you to configure security policies that automatically respond to configured risk levels.

Hope this helps and if you have Azure AD Premium licensing then make use of these great features, its good stuff :) MD (@Dudders1)

Azure AD - Ignite 2017 Announcement Summary

Mike Duddington — Mon, 02 Oct 2017 16:07:44 GMT

Hi, With the masses of information coming out of Ignite 2017 last week, I thought i'd throw together a quick summary of the key Azure AD announcements for your perusal. Some really great announcements and major enhancements in Conditional Access. Pass Through Authentication (PTA) is now generally available - This feature has been in preview for a while and is now GA including the S-SSO scenarios provided with PTA and Password Hash Synchronisation. More information here Conditional Access Enhancements - Conditional Access has taken a big step forward with the announcements of the following functionality.

Azure Information Protection Integration (Preview) - For me this is the big one and customers have been waiting for this!. It was announced that Conditional Access now has integration with Azure Information Protection (AIP). So this means you can protect documents with AIP and use conditional access policies to control access to these files. Whereas before, access to AIP protected documents relied on only user authentication, now with conditional access integration you can factor in User, Device state, Location, Risk into the authentication process. More information here.
Support for macOS device based conditional access (Preview) - Now you can configure conditional access policies for Intune managed macOS devices, More information here.
New IP based Conditional Access Conditions (Preview) - historically, when defining IP ranges to allow\block with conditional access you only had the option to manually add IP ranges. Now you will also be able to select country\region based IP ranges that allow you to allow\block based on country\region. Can save quite a bit of work!

3rd Party MFA Providers - So we all love Azure MFA... but feedback from customers highlighted they would like the option to use 3rd party MFA providers with Azure AD. @Ignite it was announced that Microsoft have formed partnerships with Duo, RSA and Trusona to provide MFA with Azure AD. Having had a quick look at each option they all look very good. All integrate easily and you can select an MFA provider that suits your needs.
Terms of Use Controls (Preview) - This feature allows you present a "Terms of Use" policy to a user which they will need to accept before they get access to an application(s). More information here.
Session Control (Preview) - There has been a session control preview available for SharePoint Online for some time. Essentially its the ability to grant access to an application but provide reduced functionality in that session. e.g. The user is logging in from a unknown location, allow log on but restrict the session so the user cannot download data. @Ignite it was announced that Azure AD Conditional Access will integrate with Microsoft Cloud App Security to extend this capability to many more SaaS applications. The Microsoft Cloud App Security Integration is currently in private preview but will bring some seriously great control to SaaS apps secured using Azure AD. See here for details.

Azure AD Privileged Identity Management (PIM) - Has been extended to the Azure platform to enable you to do "Just in Time" administration for Azure workloads. i.e. provide time limited access to Azure RBAC roles to manage VM's etc. Additional Identity types for B2B - @Ignite it was announced that additional identity providers would be added to the current Azure B2B platform. This will provide the ability for additional identities e.g. Google to be used for B2B scenarios. Hope that's helpful and I'll blog about some of these new capabilities soon! MD @Dudders1

Azure AD B2C - Part 3 - User Experience

Mike Duddington — Thu, 27 Jul 2017 10:45:27 GMT

In this final post of the series we will test the Azure B2C applications we have set up in the previous posts (link here). We will show the user experience with Azure AD B2C using different B2C policies and using email\social identities for signup\logon. Just to recap we have 2 applications:

A Job Portal that requires users to log in so relevant jobs are surfaced to those users and to simplify job application. This application must provide email and a social identity provider as authentication types and no MFA is to be enforced.
A Payroll Portal that requires stronger authentication to allow users to view payslips, manage bank details etc. This application must provide email and a social identity provider as authentication types and MFA is to be enforced.

Let's test the Contoso Jobs Portal first. I navigate to the Contoso Jobs Portal and I'm a new user (Joe Bloggs) who needs a job! So Joe clicks "Sign up/Sign in" and is re-directed to the Azure AD B2C page. Joe doesn't want to use social login so decides to "Sign up now" and is presented with the following sign-up page. Joe enters the required information (as defined in the sign-up policy) and has to verify that the email address is valid and belongs to Joe. Joe now clicks "Create". Joe is now logged in and her account is provisioned in the Azure B2C directory. From this point Joe can log on and use the Job Portal with those credentials. However Joe has now moved house and needs to change her Postal code\Zip code. To do this Joe clicks on her name and selects "Edit Profile" (Note: "Reset Password" so Joe can reset her password inline with the policy you have defined.) Joe is then presented with the "update profile" page which shows the information that Joe is allowed to edit. Joe changes the Postal code\Zip Code, clicks "Continue" and is returned to the application. Joe now gets a job! She has worked her first week and now it's time to view her payslip on the Contoso Pay Portal. She already has an account in the Azure B2C directory so no need to sign up but will it seamlessly sign in??? Joe enters her credentials and is presented with the following: No, she isn't seamlessly signed in....but remember this is the behaviour we want. A single factor of authentication for the Contoso Jobs Portal but we wanted a stronger level of authentication for the Contoso Pay Portal. Joe now enters a phone number and clicks "Send Code". Joe enters the code she has received and is logged into to the Pay Portal! Another person has decided to look for a Job. Mike Smith is a little more adventurous and would like to use his Facebook credentials for log on to the Contoso Jobs Portal. Mike connects to the portal and clicks on "Sign up/Sign in". He is then presented with the Azure AD B2C page. Mike clicks on the "sign in with your social account" button and is presented with the following Mike enters his credentials and clicks "Log in" and is presented with this: Mike accepts the terms and then is presented with the Azure AD B2C sign in page to ensure all the required attributes are populated. These will be auto populated if the information is present in your Facebook profile. If not it will prompt you to enter the additional information. Mike will need to verify the email address and then click continue. Now Mike is logged into the Contoso Jobs Portal with Facebook, his social identity provider! So to wrap up. Contoso Recruitment wanted to provide a simple, secure and consistent authentication experience for consumers to access their public facing applications. Each application has differing security\authentication requirements but Contoso Recruitment wanted to achieve this with a single identity to access all of their public facing applications. I hope this series of posts has shown how this is easily achieved using Azure AD B2C. That's the last post in the series. Follow me if you would like to see future posts. Thanks for reading. MD

Azure AD B2C - Part 2 - B2C Policies

Mike Duddington — Thu, 27 Jul 2017 10:44:56 GMT

Azure AD B2C provides the ability to set up policies to control how users can logon, sign up, edit profile information and reset passwords. These polices can be used on a per application basis. The policy assignment is performed by defining the policy name within the application itself. The policies we will discuss are the:

"Sign-up policy" - the policy to allow users to self-provision\sign up for the service.
"Sign-in policy" - the policy that defines the authentication types, strength of authentication and application claims to send.
"Profile editing policy" - the policy to define what users can edit within their Azure AD B2C User Profile.
"Password reset policy" - the policy to define password reset options for users.

As you can see from the above we can actually have a combined "sign-up or sign-in" policy which is handy as we have 2 applications so we can just create one for each application. Let's create the policy for the Contoso Job Portal and then I'll show you what is different for the Contoso Pay Portal. Click "sign-up or sign-in policies" and click "Add". Identity Providers - select the Identity options you wish to use with this policy\application. For the Contoso Job and Pay Portal we will select "Email signup" and "Facebook". Sign-up attributes - select the information you wish to collect from the user during sign up (include the ability to select any additional attributes you have added from Part 1). For the Contoso Job and Pay Portal we have selected 5 attributes. Application claims - select claims you wish to pass back to the application after successful authentication. For the Contoso Job and Pay Portal we have selected "Display Name" (which is required by the application) and "Identity Provider" (which if not selected now will be automatically added once the policy is created as we have added Facebook as an identity provider). Multifactor authentication (MFA) - do you need to enforce Multifactor authentication for these users? For the Contoso Job Portal policy we have left "Multifactor authentication" as disabled but for the Contoso Pay Portal we will enable it to meet the requirements set out in Part 1 of this series. Page UI customization - this provides the ability to customise the UI for your users. We will leave as default but feel free to customise. So that's the policy for the Contoso Job Portal taken care of. The Contoso Pay Portal will be exactly the same apart from the fact that we will enforce MFA. So now we have defined the "sign-up or sign-in" policy for both applications. Select each policy, click "Run now" to test and show the Azure AD B2C page your users will see. As you can see Facebook and email address are presented as sign-in options and there is also the "Sign up now" link defined. Now you have to define the Profile Editing and Password Reset Policy. I won't step though these in detail as the run through above should mean they will make sense to you. Key things to consider are:

what attributes you will allow users to edit in their profile?
what identity providers you will allow "password reset" to occur with?
whether you will enforce MFA for a password reset?

So that's the set up completed! In the next post we will test the user experience with the different applications. Next post located here

Azure AD B2C - Part 1 - Overview

Mike Duddington — Thu, 27 Jul 2017 10:44:24 GMT

Hi, Azure AD B2C has been generally available for a while now and I'm seeing real interest from customers on this topic. I have lots of customers that have public facing applications and have real headaches managing the identity\security aspects. This is exactly the problem that Azure AD B2C is looking to address by providing:

A single identity platform that supports your customer facing applications (OpenID Connect and OAuth 2.0 capable applications).
Seamless authentication and provisioning with Azure AD B2C or consumer identities.
Granular authentication control on a per application basis.
Resilience, performance and scale.

In this series of posts we will look at B2C features, deployment and the consumer experience, but first let's define an example scenario. Contoso Recruitment has 2 customer facing websites that both require authentication. Contoso Recruitment wants their customers to be able to use consumer identities for a better experience and to reduce the amount of management required to support customer facing applications. Applications are:

A Job Portal that requires users to log in so relevant jobs are surfaced to those users and to simplify job application.
A Payroll Portal that requires stronger authentication to allow users to view payslips, manage bank details etc.

So it makes sense for both sites to use the same authentication platform (as job seekers will hopefully become employees and vice versa) but obviously the payroll site has a need for a greater level of security. So how does Azure AD B2C address this requirement? Let's take a look... I have 2 web applications (Contoso Jobs Portal and Contoso Pay Portal) which I have set up with Visual Studio using the sample applications located here. The first step is to set up the applications in Azure AD B2C. In the Azure Portal navigate to the "Azure AD B2C" Blade. Within the "Azure AD B2C" Blade select "Applications" and click "Add". Enter a name for the application and select the type of application you are integrating. In my case it's a "Web App/Web API" so I need to add a "Reply URL" which is the location that Azure AD needs to send the authentication token\response to. (https://localhost:44316/ in my example as I'm running the application locally). Click "Create" and you should see that it has successfully provisioned with the "Application ID" populated You'll need The "Application ID" for your application integration and you'll need a "Client Secret\Key" which is generated in the settings of the application you have just created. Now let's move on to the next step which is to configure the "Identity Providers". By default "Local Accounts - Email" is provided which allows users to provision\log on with an email address (which under the hood is provisioned as a Azure AD B2C account) but you have many options to select here including Consumer\Social Identities. I'm going to add Facebook as an Identity Provider. Note: the ever increasing list of Social Identity providers. So the next step (Facebook in this example) is to register the application with the Social Identity Provider. I have done this with Facebook and it has provided me a "AppID" and "App Secret" which I will use in the next step (see here for more information on Facebook app integration). With this "AppID" and "App Secret" I can complete the addition of the Social Identity Provider in Azure AD B2C. (AppID = Client ID and App Secret = Client Secret) Now click "Create" and we now have "Local Accounts" and "Facebook" as Identity Providers that we can use for our applications. The next step is to review the "User Attributes". This is a list of user attributes that you will hold within the B2C directory. I will stick to default but feel free to add more if you need to collect more information about your users or you have specific information you will use in authentication claims. Next is the "User and Groups" Blade. Within this Blade you can add, remove, view, edit users that are present in the directory, create groups, configure authentication options and define what users are able to do. So to summarise what we have done so far...We have added our applications into Azure AD B2C, added a social identity provider, defined the attributes we use within the directory and had a look at how you manage users and groups in Azure AD B2C. In the next post we will set up the B2C policies that we will use to provide the granular control we need for this scenario, located here. MD

Getting Ready for Microsoft Cloud Identity - AAD Connect

Mike Duddington — Fri, 14 Jul 2017 14:14:57 GMT

Hi, The process to deploy AADConnect is a well-trodden path and there is lots of installation guidance out there. This post is going to go into to a little more detail on deployment considerations and the options you are presented with during the installation. Build Number - AADConnect is regularly updated with new features. At the time of writing this post I am working with build 1.1.557.0. To see the latest version of AAD Connect look here. Server Specs - The hardware requirements for the AADConnect server are documented here. AADConnect can be deployed on a virtual server (including Azure IaaS) providing the ability to re-size the VM should the need arise. Database Choice - For a majority of customers this isn't relevant but is good to know as who knows what will happen in the future. AADConnect by default installs a free version of SQL (SQLExpress) and as long as the total number of AD Objects stays below 100,000 objects then you don't have anything to think about. But if your close too or exceed 100,000 AD objects then you will need to purchase and deploy a full SQL Server instance (or use an existing one). The AADConnect "custom" installation provides and option to "Use an existing SQL Server" which will allow you to use a full SQL instance. AADConnect Installation The Installation of AADConnect is a simple one. You download the latest version from here, run it and now we'll walk through the key options. User sign in - asks you to select an Authentication type. As you may remember I have a previous post that walks through the options and how they work.

Password Synchronisation - Select this option to synchronise a "hash of hash" of users passwords to Azure AD (You can also select the "Enable single sign on" checkbox with this option).
Pass-through Authentication - Select this option to authenticate users with your on-premises AD (You can also select the "Enable single sign on" checkbox with this option).
Federation with AD FS - Select this option to authenticate users with your on-premises AD FS Farm (The wizard will assist with the set up the AD FS farm or utilise an existing one).

Azure AD Sign-in configuration - shows the Active Directory UPN domains and domains that you have registered in Azure AD. You are required to select an attribute to use as the username. I would personally recommend that you stick with UPN as it is the most user friendly option (as UPN can match email address in many cases). If you note from the diagram you will see that I have a domain that is showing as "Not Added". This is because I have used additional UPN suffixes to change what UPNs users will have (instead of using the implicit UPN of dudders.com) Domain and OU filtering - This is where you configure what objects are in scope of synchronisation to Azure AD. As I have mentioned in a number of previous posts only do so if there is a clear security\policy reason to do so. Typically customers only filter things like service, disabled accounts as there is generally no value to having them in Azure AD. Uniquely identifying your users - This page is trying to answer 2 questions.

Do I have to deal with duplicate users across multiple directories, if so then how do I match them? (Avoiding issues/duplicates in Azure AD)
What do you want the Source Anchor (the attribute that links the on-premises AD object to the Azure AD Object) to be?

Hopefully you don't have duplicate users across directories but if you do then select the attribute that will best allow a match to occur. On the Source Anchor attribute, unless you have a very specific reason for not doing so I would recommend that you remain with the Default option "Let Azure manage the source anchor for me" This is actually using an attribute called msDS-ConsistencyGuid which is the best future proof option. See my previous ramblings on source anchor (ImmutableID) considerations here. Optional features - Please review these features as they contain workload specific features. So depending on what licensing you have and what services you are looking to use in the Microsoft Cloud you may need to enable features here. A common example being "Exchange Hybrid Deployment". AADConnect plays a pivotal part in all of these features. That's the primary options covered. On the last page it provides a summary of the configuration and you can decide whether to start syncing straight away. Note the "enable staging mode" option. This is the checkbox you would enable if this server is the "staging server" which I covered briefly here. MD

Azure Site Recovery Overview (Azure to Azure)

Mike Duddington — Fri, 14 Jul 2017 13:53:06 GMT

Hi, I'm temporarily deviating from Cloud Identity topics to show you a new Azure feature (that is in preview at the time of writing this post). Azure to Azure Site Recovery allows you to replicate\failover virtual machines from one Azure region to another. Azure Site Recovery has been around for a while and until recently only provided the ability to failover to Azure from On-Premises and between On-Premises datacentres. Now you can do Azure to Azure as well. Let's set it up and have a look. Firstly, lets set up a "Recovery Services Vault" Make sure you create the Recovery Services Vault in a different region to the Source Virtual Machines. In this example we will be failing VM's over from East US to West US 2 (with the Recovery Vault being located in West US 2). Once the Recovery Services Vault is created, open it, then click on "Site Recovery" then "Prepare Infrastructure". Select "Azure - Preview" for the Source and "To Azure" as the Target, click OK. Then Click "Step 1:Replicate Application" In "Source" configure the source locations details. (Source Region, and Source Resource Group), click OK. Select the Virtual Machine(s) you wish to replicate\failover. (Note: look at this link for supported VM types\configurations and verify that your subscription allows for creation of VM's in the Target ), click OK. On the "Settings" blade you need to provide the information on Target Resource Group, Network, Storage and Availability sets. Click "Customize" to select existing ones or ASR will automatically create new ones in the Target for you. Also configure the "Replication Policy" you want which will need to be changed in line with your RPO objectives. When all information is entered click "Create target resources". When they are created click "Enable Replication" and watch the magic happen...After a few minutes you will see in the "Overview" blade that "Site Recovery Jobs" has job's in progress. It will take some time for your VM(s) to replicate but once they do you will see the VM(s) in the "Replicated Items" icon. Now the VM(s) are replicated now it's time to define what happens in the event of the very, very, very slim chance of you needing to failover. This is done by creating a "Recovery Plan". Within the Site Recovery Portal select "Recovery Plan (Site Recovery)" and add a new Recovery Plan with the source, target and VM(s) selected. Click OK to provision the plan. Once provisioned open the "Recovery Plan" and you should see the following. Note the "Test Failover" button. You can customise the Recovery Plan" and incorporate Azure Automation Runbooks to do pre/post actions. e.g. running PowerShell to change DNS entries, restarting services etc etc. More info here Finally lets failover...click the dots and select "Failover" (you should do a test failover first to verify all is working correctly, also Note "Failover Direction" so you now know how to fail back). Drum Roll... And a few minutes later... Thanks for reading and I hope that was useful. MD