Like most directory services, Azure Active Directory stores information about users and the organizations they belong to. It lets users log in, then supplies them with tokens they can present to applications to prove their identity. It also allows synchronizing user information with Windows Server Active Directory running on premises in your local network. While the mechanisms and data formats used by Azure Active Directory aren’t identical with those used in Windows Server Active Directory, the functions it performs are quite similar.
Understanding Azure Active Directory
It’s important to understand that Azure Active Directory is designed primarily for and used by cloud applications. It can be used by applications running on Azure, for example, or on other cloud platforms. It’s also used by Microsoft’s own cloud applications, such as those in Office 365. If you want to extend your data center into the cloud using Azure Virtual Machines and Azure Virtual Network, however, Azure Active Directory isn’t the right choice. Instead, you’ll want to run Windows Server Active Directory in Virtual Machines.
To let applications access the information it contains, Azure Active Directory provides a REST API called Azure Active Directory Graph. This API lets applications running on any platform access directory objects and the relationships among them. For example, an authorized application might use this API to learn about a user, the groups he belongs to, and other information. Applications can also see relationships between users-their social graph-letting them work more intelligently with the connections among people.
Another capability of this service, Azure Active Directory Access Control, makes it easier for an application to accept identity information from Facebook, Google, Windows Live ID, and other popular identity providers. Rather than requiring the application to understand the diverse data formats and protocols used by each of these providers, Access Control translates all of them into a single common format. It also lets an application accept logins from one or more Active Directory domains. For example, a vendor providing a SaaS application might use Azure Active Directory Access Control to give users in each of its customer’s single sign-on to the application.
Directory services are a core underpinning of on-premises computing. It shouldn’t be surprising that they’re also important in the cloud.
Figure: Multi-Factor Authentication provides the functionality for your application to verify more than one form of identification
Security is always important. Multi-factor authentication (MFA) helps insure that only users themselves access their accounts. MFA (also known as two-factor authentication or “2FA”) requires users provide two of these three methods of identity verification for user sign-ins and transactions.
- Something you know (typically a password)
- Something you have (a trusted device that is not easily duplicated, like a phone)
- Something you are (biometrics)
So when a user signs in, you can require them to also verify their identity with a mobile app, a phone call or a text message in combination with their password. By default, Azure Active Directory supports the use of passwords as its only authentication method for user sign-ins. You can use MFA together with Azure AD or with custom applications and directories by using the MFA SDK. You can also use it together with on-premises applications by using Multi-Factor Authentication Server.
Multi Factor Authentication Scenarios
Login protection on sensitive accounts such as bank logins and source code access where unauthorized entry could have a high financial or intellectual property cost.