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 @companyname.onmicrosoft.com 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 @companyname.onmicroft.com 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 @contoso.com 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.
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
- 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 firstname.lastname@example.org 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.