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.
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.
This is a really great question and the answer is they can use whatever you setup for them here’s some options:
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.
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.
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.
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:
Check out my earlier post on Setting up a strong identity management solution.
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
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 email@example.com 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.
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.
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.
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.
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.
Currently groups and their membership are synchronized from on-prem to the cloud but write-back isn’t available.
We look for correlation with attempts to contact malware servers from the devices that users sign-in from.
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.
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.
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.
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!
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!
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 (!)
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.
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.
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.
There are typically three types of forest topologies:
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.
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).
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
The post Setting up a solid identity and access management foundation appeared first on Enterprise Devices + Infrastructure.
In this episode, Brad talks about a recent trip to some customers in the mid-west, an incredible learning experience, seeing some of the real world challenges of trying to cobble point solutions together for EMM. Simon and Brad then talk about Conditional Access controls, Microsoft Ignite and much more.
Don’t forget to register for the Enterprise Mobility Core Skills Jumpstart Series, starting with Azure AD Core Skills and checkout the introductory blog post.
Brad also mentioned the Enterprise Mobility Roadmap
Check out these sessions at the Ignite conference about Enterprise Mobility:
The post Endpoint Zone Episode 6: Conditional Access, Ignite, Azure Remote App appeared first on Enterprise Devices + Infrastructure.