Simon May

Client and cloud

Simon May

  • Enable Office 365 Built-In MDM (Mobile Device Management)

    Do you have company owned mobile devices or employee-owned mobile devices that receive email? Of course, you do everyone does. Do you have a Mobile Device Management solution that you’re paying lots for but only using little of? Have you got or are you looking at getting Office 365? If the answer to any of these questions is yes then you need to be aware of Mobile Device Management in  which Microsoft announced on March 30 on the Office Blog. In this post, I’m going take you through enabling MDM management of a device but first, why is MDM in Office 365 important?

    Why is MDM in Office 365 important?

    The Exchange Active Sync (EAS) protocol has had some mobile device management like capabilities for some time, but as mobile devices and their use has evolved EAS hasn’t been the go-to management solution beyond email. OS manufacturers have invested in Mobile Device Management protocols and deeply instrumented those in their OS allowing MDM to apply policies far beyond email.

    I’ll give you a prime example of that evolution: The BYOD movement has led to people using their personal devices for work. It’s not clear legally how much control over such a device an employer has and it can vary dramatically even in one country. As a result wiping everything on a device that is personally owned could be worrisome to an employer.

    With AES, it’s only been possible to fully wipe a device. One of the capabilities that Office 365 built-in MDM brings is the ability to selectively wipe business data from the device. This is huge because if remote wipe is your only need, Office 365’s built-in MDM has you covered. More of you need to specify basic device policies (that still go beyond AES) to control device capabilities, such as encryption, password requirements, app (age) restrictions and the like. A full list of the policies enabled through Office 365 MDM is on TechNet.

    Conditional Access to Office 365 is also available through the built-in MDM. If you aren’t familiar with the principle of Conditional Access yet, it asks a simple question: Does the device meet the minimum bar for entry. You define the minimum bar. So you can set a policy that says that a device must be managed by Office 365, so you can wipe it, for example, before its allowed access to critical information. Frankly it’s ground-breaking that this ability is in an MDM offering that costs nothing extra.

    With all that in mind, what’s the answer to the question: Why is MDM in Office 365 important? The Answer: It gives you another option for management.

    For some customers, it might be the only MDM they need. Indeed I surveyed my Twitter followers and I found out something interesting (I do this regularly, you should follow me to participate and be heard). 14% of respondents to one poll were paying for MDM (which is probably about $100 per user or $51 per device per month* they could cut this from their expenditure immediately…that would probably make the boss happy!)

    How about if you still need MDM for some users that need capabilities beyond what’s built into Office 365 such as Mobile Application Management or Company Resource provisioning?

    There are people or groups of devices that need capabilities beyond what’s available built into Office 365 MDM and that is fine. Just license them for Microsoft Intune and the on-ramp is simple. Users with a Microsoft Intune license are managed through Microsoft Intune, users without are managed through Office 365 MDM! With Microsoft Intune, you get capabilities such as being able to automatically provision company resources (certificates, VPN, WiFi) and being able to distribute and manage apps.

    Ok, looks useful, let’s try this…

    That’s the why over with and hopefully you want to start taking a look. Let’s take a look through my Office 365 tenant and see what we need to do to get setup.

    Enable Office 365 MDM

    First we go to the Mobile Devices option in the Office 365 Admin portal and click Get Started to start the activation process, this will take some time to complete. If you’re using a custom domain (such as and not )to set up Office 365 as a mobile device management authority you will need to set up the correct DNS settings and exchange a certificate request from Office 365 for a certificate from Apple to work with the Apple Push Notification Network (APN) to support iOS. You’ll need to add the following two DNS entries if you’re using a custom DNS:

    Host name Record type Address TTL
    EnterpriseEnrollment CNAME 3600
    EnterpriseRegistration CNAME 3600


    REALLY neat feature. These are the same DNS entries you need to add if you’re using Microsoft Intune for MDM, which is why moving some or all users to Intune from Office 365 MDM is possible or put another way: Office 365 and Microsoft Intune co-exist for MDM.

    Optionally you can enable Multi-Factor Authentication (MFA) meaning that to enroll their device into Office 365 MDM management they need to give a second factor of authentication, such as receive a phone call or text from the Azure MFA service. Configuring this only requires MFA for device registration from that point forward, because the device is now trusted, it’s a second factor of authentication.

    Create A Device Security Policy

    Now that your Office 365 tenant is enabled for MDM we need to enable some policy. So click the Manage device security policies and access rules link. You’ll be taken to Compliance Center where you’ll click the Manage device access settings link.

    In Organization-wide settings for device access management, you can choose to allow devices that don’t support MDM management to enroll or choose to block them. If you choose block then a device must be MDM capable to be able to add an Office 365 email profile. You might want to do this for your regular users but have some users that you this rule doesn’t apply to (such as your C-level people).

    Finally, let’s create our policy and target it to some users. Click the New icon (the plus sign). Enter a policy name, and click Next. Make some policy settings: I like to set a password policy for testing purposes. The last section of the Device Security Policy determines what to do if a device is non-complaint, this is Conditional Access!

    Conditional Access

    Conditional Access, as previously stated, prevents a non-compliant device from accessing resources. If you select Block access and report violation what happens is that if any of the above policy settings aren’t set on the device (or the device has refused the setting) access to Office 365 Email, SharePoint and OneDrive for Business will be blocked from this device. If you select Allow access and report violation then the violation will just be audited (which you can see in either case in Compliance Center).

    This is simple a cool feature: It means you can definitely stop email flow to a device that isn’t enrolled, or a device that’s jailbroken or rooted, or a device that simply isn’t encrypted.

    In the case of email, all the user will get in their inbox, until they are complaint, is a single email telling them how to get complaint, and nothing more!

    If the device Click Next to set the policy.

    Something Extra Really Cool

    One other thing. If you tick the box that says Require managing email profile then what you’re saying is that if the user added their own email profile that is not good enough for them to access resources. The reason it’s not good enough is that you DO NOT have the right to wipe a non-managed email profile on iOS or Android and therefore you don’t have control over your organization’s email data.

    Ticking Require managing email profile does something really cool though. The user is prompted to remove the organizational email profile they added and, once that’s done, Office 365 will provision the email profile to the users device, making it managed!

    And that [Email Provisioning] takes is just one check box!

    Finally, Deploy the Policy

    The very last thing you’ll do is deploy the policy. Just search for a security group that you want to deploy the policy to, select the group, click Add and Ok. Then you can go to a test device and try out the policy, add an organizational email account manually on the device and (if you selected the Block option for conditional access) you’ll receive an email telling you to enroll your device by getting the Company Portal app from the store.

    Perhaps you’d like to see this in action

    Corporate Vice President, Enterprise Client and Mobility at Microsoft, Brad Anderson and I took a look at this on the latest episode of the Endpoint Zone with Brad Anderson which you can watch below:

    This is cool, I want to try it out how do I do that?

    Firstly, if you have Office 365 you should check to see if MDM is available in your Admin portal yet. If it is you’ll see it just like in the first step above. If it’s not it’s coming, Office 365 MDM is rolling out now, but it’ll take us a few more weeks to complete every Office 365 tenant (there are so many!)

    If you don’t yet have Office 365 you can get a free trial, although the functionality might not be available there yet, but it should be before the trial expires.

    Finally if you want to know even more, you should check out the free Microsoft Intune Jumpstart on Microsoft Virtual Academy next week that is part of our Enterprise Mobility Core Skills Jumpstart series. Since it’s a series you can sign-up for them all and watch them live or binge on the them as they become available on demand!

    * Airwatch Green Management Suite-Cloud as of 3/1/2015.





    The post Enable Office 365 Built-In MDM (Mobile Device Management) appeared first on Enterprise Devices + Infrastructure.

  • Endpoint Zone Episode 7: Office 365 Mobile Device Management

    This week I had the opportunity to catch up with Brad Anderson, CVP Enterprise Client and Mobility at Microsoft, as I usually do to film the Endpoint Zone. On this month’s episode we take a look, and walk through the new Office 365 MDM features including showing you how to enroll a device, set policy and selectively wipe the device: Game-changing stuff that normally requires you to buy a separate MDM solution!

    Take a look:

    The post Endpoint Zone Episode 7: Office 365 Mobile Device Management appeared first on Enterprise Devices + Infrastructure.

  • FAQ ME! Answering Questions from the Azure AD Core Skills Jumpstart

    Last week I ran the Azure AD Core Skills Jumpstart on Microsoft Virtual Academy and, as always, there were lots of questions from the audience. I thought I’d take all the questions that I could find in the questions queue and dump them to a file and compile and FAQ for you to peruse. Useful if you did or didn’t, get your question answered.

    Once on-prem AD is synced to Azure AD, do the user accounts on Azure still authenticate with or do they authenticate with their on-premises AD account to other azure based servers/apps?

    This is a really great question and the answer is they can use whatever you setup for them here’s some options:

    • If you want the user to continue to use then that will work, you can setup Azure AD Sync and effectively use it to provision the accounts into Azure AD. You could choose to enable Password (hash) sync too, although I’m not quite sure why you would. You’d probably only stay in this configuration for a short time.
    • Once you verify your DNS name com then you can add that UPN to your on-premises AD DS and configure user accounts to use that UPN. The users can then sign into Azure AD using their account. If you configure Password (hash) sync then they can use the same password as they would use on-premises and they can also use the UPN to logon on their PCs instead of contoso\user.
    • For some services – mainly those not in the browser or where the home realm is known (i.e. we know you’re calling from Contoso) you can also use contoso\user.

    Azure AD Answers

    What’s the difference between on-premises AD and Azure AD

    This is a kind of long and difficult question to answer, I’ll keep it under a paragraph but you should read more on TechNet around this if you want to go deeper.

    Azure AD is designed for a mobile world, as such it is globally available by default and isn’t based on you building your own domain controllers. It’s built to deal with hyper-scale (really large) and deals with about 18bn auths per week. Azure AD can be used for OAuth2.0 apps, which is basically how the modern web does authentication. We designed Azure AD to federate and connect with thousands of applications, prime among them Office 365, Microsoft Intune and Azure itself. That gives us a huge amount of telemetry about how people use the service that the developers can act upon.

    Contrast this with on-premises, where you design and build the infrastructure. Apps interact with AD DS either natively or via LDAP queries. You hand crank every federation and connection (and we know that many people don’t) and the data on how you use AD DS often doesn’t reach our engineers.

    There are other, huge differences but in a couple of lines that’s a starter. There is also this MSDN Article you can check out.

    Can I have azure AD in on premises?

    This question is much easier: No.

    However, you do have some components on-premises. Azure AD Sync synchronizes users from on-premises AD to Azure AD. Active Directory Federation Services (AD FS) keeps authentication on-prem and features such as Azure AD Application Proxy rely on an on-premises connector to enable reverse proxy.

    Can PCs join the Azure domain without an existing AD sync to an on-premises domain?

    No. It’s not possible to domain join a Windows PC to Azure AD today without on-prem domain controllers and computer accounts aren’t synchronized to Azure AD. In the future, you will be able to log into Windows 10 with an Azure AD user. Today, it is possible to “workplace join” a device to Azure AD thus creating an identity for the device against the joining user account. This is useful for conditional access uses, such as preventing mail flow to unregistered devices.

    Are the reports only available with Premium Azure AD?

    Azure AD Premium includes some extra, premium reports that add capabilities to your IT admin arsenal. I consider some  “big data for IT admins”. There are some other useful reports too and you can find a full breakdown by reading this MSDN library article on what they all do. However, here’s a quick list of the premium reports if you need them:

    • Sign ins from IP addresses with suspicious activity
    • Irregular sign in activity
    • Sign ins from possibly infected devices
    • Users with anomalous sign in activity
    • Application usage: summary
    • Application usage: detailed
    • Devices
    • Groups activity report
    • Password reset registration activity report
    • Password reset activity


    Scenario: Two different forests, DirSync & ADFS on one forest A. I wanted to sync both the forest user objects and Authentication has to use forest A. will this method work?

    Check out my earlier post on Setting up a strong identity management solution.


    How does AD FS work with Smart Card authentication?

    Jen Field, one of the Program Managers in the Identity team at Microsoft has a great blog post on exactly that: External authentication providers in AD FS in Windows Server 2012 R2: Overview


    Scenario: We have our on-premises domain controllers with a domain (let’s say NLCOMPANY.LOCAL) and our azure active directory with another domain, let’s say COMPANY.NL. We would like to implement azure sync between on-premises and azure active directory, but we would like the domain existing in azure COMPANY.NL to be the domain to log on the company laptops. Does it means we should create an AD on-premises with the same COMPANY.NL domain or can we do it in another way keeping our NLCOMPANY.local domain?

    This is actually a pretty common thing to need to do, so the answer is pretty easy. First authorize the domain in Azure AD. Then add the new UPN suffix to on-prem AD DS and assign specific users that UPN in their account. From this point forward they can log on as nlcompany\user or they won’t be able to use the nlcompany.local domain any further but you can add it as an extra attribute if it needs to be referenced by other apps and then point the other apps at the new attribute.

     Can we manage Azure AD exactly like we manage On-premises AD

    It really depends upon how you’ve configured your synchronization. If you don’t have any synchronization then you’ll need to manage Azure AD through the web portal or through PowerShell. If you’re syncing then you can, and should, be managing your user accounts and their attributes from the on-prem AD DS. Even in a synced scenario though you will need to go to the management portal or to use PowerShell to to manage parts of Azure AD that only exist there, such as reports.

    Are there Group policies in Azure AD?

    No – but that doesn’t mean you can’t manage settings effectively. Let’s think back to where Group Policy came from, it was grounded in doing a better job of managing Windows than simply deploying reg setting through a script. Group Policies are still incredible at this and they will be around for this purpose for a long time to come. However the types of devices that we use has changed and many of them aren’t Windows now. As such the “group policy” engine for Azure AD is Microsoft Intune and its MDM capabilities.

    Is it possible to use MFA only when user is trying to login from different country?

    Actually no, that’s not possible but probably only, respectfully, because the question isn’t very well scoped. Why would you only be worried about people potentially logging in from other countries? There are just as many, possibly more risks with users logging on without MFA in their home country. What is possible is to specify IP ranges that are exempt from requiring MFA. I would deploy this in places where I have a good expectation around physical security – such as the HQ with a small army of security professionals with guns and badges. I’d probably also deploy this to my VPN address range so as not to overly annoy users with extraneous authentication.

    Another option, now in preview, is to enable MFA on a per app basis. So, for example, your users don’t need MFA to use the company intranet (published with Azure AD Application Proxy) but they do need it to use the customer information in SalesForce.

    If you are using SharePoint 2010 on-prem and want to use application proxy to use it from the outside, can you install the connector on one of your SP 2010 servers? What is the best practice for locating the connector?

    The best practice is to install it on another server that can talk to the SharePoint server. Given that the server can be virtual then that shouldn’t be overly hard to do and because it’s talking over standard ports you can make your own, informed, decision over DMZ placement.

    Are the on-prem groups synced in AAD via sync?

    Currently groups and their membership are synchronized from on-prem to the cloud but write-back isn’t available.

    What mechanism determines if the device is potentially infected (from your logon attempts report)?

    We look for correlation with attempts to contact malware servers from the devices that users sign-in from.

    Are there specific attributes required for the sync to be successful? (other than UPN)

    Yes and the answer to this question depends upon which apps you are using that are dependent upon Azure AD. Luckily you don’t need to know exactly which attributes each app needs, although it is documented here, since the Azure AD Sync setup will do this for you.


    Resources, Next Steps

    Thank you very much for joining me for episode one of the Enterprise Mobility Core Skills Jumpstart Series. Next month, April 2014, we will be live again talking about the core skills you’ll need for Microsoft Intune. Register here.

    The post FAQ ME! Answering Questions from the Azure AD Core Skills Jumpstart appeared first on Enterprise Devices + Infrastructure.

  • Edge Show: WorkFolders for iPad + exclusive first look at iPhone

    On this weeks Edge Show I talk to Fabian from the WorkFolders team about their iPad client and I get an exclusive first look at the iPhone app too! If you aren’t familiar with work folders, it’s a really nice solution to use your existing Windows Server 2012 R2 File server infrastructure to enable sharing – across the internet – from those servers. Giving you the best of the cloud and making the best use of your on-prem investments.

    The post Edge Show: WorkFolders for iPad + exclusive first look at iPhone appeared first on Enterprise Devices + Infrastructure.

  • Setting up a solid identity and access management foundation

    Not everyone has a simple Active Directory structure, not everyone can move all their user objects and every single attribute to Azure AD, without a little nip-and-tuck. This post is going to help you deepen your core skills around Azure AD Sync Services, so you can go beyond the basics!

    Why identity is important

    In a previous post on the blog, you learnt the 5 reasons why I consider connecting your on-prem AD DS to Azure AD an essential step, for everyone. Really just boils down to one thing – making your corporate identity more available, securely. By making it possible to authenticate and authorize your users on the devices and to the apps they’re using, wherever they are, you are making your life easier from an IT management standpoint.

    In this post, we’re going deeper than just setting up a simple sync. Let’s ramp your skills up!

    Get your user’s stuff together!

    How long have you been running on your current AD? At the very most it is about 14 years… Wowzers! People’s kids have started and FINISHED school in that time and now their thinking about college!

    It’s quite possible that some of those objects in your on-prem AD DS might not be all that fresh or important anymore. Perhaps you’ve got some attributes that you just don’t need, perhaps you’ve got some user objects that you don’t need to be cloud enabled, perhaps – just perhaps – you have a non-“standard” AD DS (!)

    Think about exactly what you want to sync

    Azure AD Sync service, if you aren’t familiar with it yet, is the replacement technology for DirSync. Azure AD Sync makes some default assumptions about your environment that you need to understand.

    1. Users have only one enabled account and the forest where this account is located is used to federate the user.
    2. Users have only one mailbox.
    3. The forest that hosts a user’s mailbox has the best data quality for attributes visible in the Exchange Global Address List (GAL).
      If there is no mailbox on the user, then any forest can be used to contribute these attribute values.

    Having said that these are the default assumptions doesn’t mean that you can’t challenge them. Out of the box (so to speak) Azure AD Sync setup drop-dead easy for a simple scenario. Either single or multi AD forests, where there is no duplication.

    But what if there is duplication? Azure AD Sync can help here too, you just might need to break out the more advanced tools.

    Let’s first take a look at the components that we need to understand.

    Azure AD

    One single Azure AD can be the “recipient” of users, groups, contacts and InetUsers from multiple on-premises Active Directories. Centralization is one of Azure ADs most powerful features, but you need to help Azure AD Sync service to understand exactly what your plan is. The first step is to identify the forests that you’re going to sync from and how those forests work with each other.

    On-Prem Active Directory Forest topologies simplified.

    There are typically three types of forest topologies:

    Separate Technologies

    The first is pretty simple, two forests that don’t trust each other. For example, you might come across this if Contoso and Fabrikam were two companies under the same parent organization that shared no management structure. In this case, you could just use Azure AD Sync out of the box.

    Full mesh with optional GAL sync

    The second option is more complex. Here you have two on-premises AD DS forests that trust each other. There might be duplicated user accounts and contacts in the GAL in each company. For example, if Contoso acquired Fabrikam, IT set up trusts between them and they started to share business functions. Here you will need to set up “matching” across the forests – usually on the mail attribute as it’s uncommon for a corporate user to have multiple email address (although it does happen).

    Account Resource Forest

    The third option is when there are one or more account forests with active user accounts. Here, one forest trusts all the account forests and typically shared resources live in that forest. For example, Contoso and Fabrikam are subsidiaries of Tailspin, Tailspin is the resource forest.

    Introducing the Metaverse and Connector Spaces

    Azure AD Sync’s job is to make sense of the objects in your on-premises AD DS and deliver them into Azure AD. Azure AD Sync takes the information stored in objects in your AD DS forests and projects them into a construct (actually a SQL Server DB) called the Metaverse. Azure AD Sync does this based on synchronization rules, both inbound and outbound in Connector Spaces.

    We are getting into the internal workings, but it’s important to understand what’s happening for a less “off the peg” scenario. Really, it’s all about matching and provisioning.

    When Azure AD Sync finds and object, it takes a look at what it already knows in the metaverse to see if the new object in the connector space matches anything already there. If it does, it will, based on some attributes, join the objects. If not it will either provision or disregard the object.

    Let’s move on to look at the objects we are syncing.


    Users can exist in any synchronized forest. An active account will always contribute login information, including userPrincipalName and sourceAnchor. The user will have a number of attributes, some of those attributes can be used by the Azure AD Sync tool for user matching. For example the Mail attribute.

    Of course, many of those other attributes  store lots of bits of information. The  available attributes depend upon how the AD DS schema was extended. Do you have Exchange or Lync, for example? Azure AD Sync usually creates an Azure AD User for a user account when it doesn’t see a matching instance in the metaverse, but if it does see a match then it will join the objects.

    Disabled accounts are also synchronized to Azure AD. For non-Exchange folks, disabled accounts are often used to represent resources such as conference rooms in Exchange. A disabled account will contribute userPrincipalName and sourceAnchor, unless it is a linked mailbox in which case it’s effectively ignored because an active account will be found later.


    Contacts are common in scenarios where a global address sync has taken place between two forests. When Azure AD Sync sees a match between a Contact and a User in the metaverse it will join the two. If a User object isn’t seen, a Contact object is created. However, if a subsequent User object is found that matches the Contact then it is promoted to a User and a User object is created in Azure AD, ultimately.

    What’s the net effect?

    It’s really hard to see what the effect will be before synchronizing directories and assembling the metaverse. However, the net is that you’ll have a deduplicated, single Azure AD.

    Azure AD Sync is designed to run continuously ,on a periodic basis. On an first sync, where multiple AD DSs are imported into the metaverse, it’s impossible to know with accuracy which objects from which AD DS will be imported first. That’s why Azure AD Sync takes the approach it does to matching.

    Now you understand how Sync works a little better, what can you do with that information?

    Having grasped the basics of the sync engine, you can start to make tweaks to the rules that make sense for your organization. For example, you can change the rules for how objects in your AD DS are joined to existing objects in the metaverse. Or you can “transform” the information in the attributes, changing almost anything about it. Transformation is actually a very powerful feature and has a rich language all its own, so you can get really custom. If you’re familiar with IdFix this is a better way of fixing issues that IdFix may have found.

    You can find information on exactly how to change the Synchronization Rules in the documentation.

    Configuring Filtering

    One of the other, less “off the peg” requirements you might have, is to not synchronize everything to Azure AD. There are three ways that you can filter your AD DS based on what’s going to meet your needs. Filtering will, essentially, prevent some objects from being created in the metaverse that otherwise would.

    Domain-based filtering

    If you manage Contoso and Contoso has two domains, Contoso-US and Contoso-DK, but only the Chief Security Officer from the US part of the organization is comfortable with storing User objects in Azure AD and her German counterpart isn’t, then this is the filtering method you would use. (Also you should have a word with that CSO and possibly mail her the link to the Azure Trust Center).

    Organizational Unit based filtering

    If Contoso has a Physical-Access-Only OU, which is only used to hold the most secure user objects then OU-based filtering is the way to go.

    Attribute-based filtering

    If Contoso doesn’t have a natural partitioning structure based on AD DS or, has users with a specific attribute that must or must not be synchronized this is the way to go. For example you could add an extension attribute with a value of “NoSync” to all the user objects that you don’t want synced for some reason.

    It’s important to know that this is very different from configuring attribute synchronization in the wizard. Attribute-based filtering will import (or not import) objects into the metaverse based on attribute values for that object. Configuring the attributes (or apps) that are synchronized to Azure AD in the wizard will configure which attributes are synchronized for the objects in the metaverse. Two very different things.

    Inbound and outbound filtering

    The next important thing to realize is that there are two different types of attribute-based filtering, inbound and outbound, as defined from the viewpoint of the metaverse. That is, inbound attribute-based filters control what comes into the metaverse and outbound filters control what leaves to metaverse. When we work with synchronization rules we don’t want to mess around with the predefined rules because we would lose our changes upon upgrade of Azure AD Sync.

    For the most part, inbound attribute filtering will do what you need, only projecting the objects you want from AD DS into Azure AD. However there are times when there isn’t enough information in the attributes to filter as you would like. As an example, take the account resource forest topology. There the information as imported from the objects in the resource domain might not be enough on its own and Azure AD Sync might need to join it with information from the user domains.

    Attribute-based filtering can be configured at any time, and if you remove something through filtering it will also be removed from Azure AD. It’s possible to configure filtering in Azure AD Sync I’m not going to dive into thousands of words on this since the documentation is so good at explaining how.

    Now we’ve covered what the objects are and how to control their appearance in the metaverse and subsequently Azure AD, let’s cover attributes.

    Synchronizing Attributes to Azure AD

    One of the most useful and intelligent features of Azure AD Sync is that, during setup, you can specify what attributes are to Azure AD.

    You might not be an expert on exactly which attributes you need though, so the Azure AD team made it easy. Azure AD Sync gives you a list of all the Office 365, Microsoft Intune and Azure AD enabled apps from Microsoft, simply select which apps you use and Azure AD Sync will work out the attributes you need to sync.

    Do you want to Sync Passwords?

    This is one of the most important questions that your organization needs to answer. The ramifications are pretty huge.

    If you do choose to sync your passwords you need to know that you aren’t actually sinking the passwords. You are syncing a non-reversible hash of the passwords. To put it simply: When a user attempts to authenticate against Azure AD, the authentication provider (which could be an app or a web page) will hash the characters they enter as the password. This hash is then sent to Azure AD and compared with the hash that Azure AD has. If they match, the user gets in, if not they don’t.

    Password sync can be two way. Initially all passwords for synced users are hashed and stored in Azure AD. If a user changes their password on-prem, the password sync is quickly to Azure AD (the default is within 2 minutes). If the user changes their password in Azure AD (if you let them by enabling self service) then the reverse will happen, updating the users password on-prem.

    If you choose not to use password sync you then need to implement AD FS. You can find details and tons of resources here.

    What’s super-cool though, is that you can choose to do both. This means that if you implement AD FS and it fails for some reason, like you’re data center floods, then your users will still be able to authenticate with Azure AD using password sync. Pretty neat.

    The one sacrifice you make here is that without AD FS you won’t be able to get Single Sign On (SSO) because there isn’t any way to synchronize or share tokens.

    Checkout this article for lots of info on setting up password sync.

    Where to learn more – Azure AD Jumpstart

    This is a whistle-stop 2000 word run through that drills deeper into your Azure AD Sync core skills. You can get even more by joining me for the Azure AD Core Skills Jumpstart on Microsoft Virtual Academy.

    I made you some tweets:

    • Wow - amazing post on Azure AD Sync "core skills"

    The post Setting up a solid identity and access management foundation appeared first on Enterprise Devices + Infrastructure.