Tag Archives: Azure

Office365

Azure AD Connect Pass-Through Authentication

12 Comments

At Ignite 2017 it was announced that Pass Through Authentication (PTA) has reached General Availability (GA) so it is a fully supported scenario now.

But what is PTA? If Office 365 there are Cloud Identities, Synced Identities and Federated Identities. The first two are authenticated in Azure Active Directory, the last one is authenticated against on-premises Domain Controllers. For this to happen you need an ADFS infrastructure, consisting of multiple internal ADFS servers and multiple WAP (Windows Application Proxy) servers in the DMZ acting as ADFS proxies. Oh, and all servers need to be load balanced as well to provide redundancy and scalability.

PTA on the other hand is built on top of Azure AD Connect, and as such an interesting extension of the Synced Identities. PTA installs an agent on the Azure AD Connect server (AuthN agent) which accepts authentication requests from Azure AD and sends these to on-premises Domain Controllers. The advantage of authentication against on-premises Domain Controllers is that no passwords (or password hashes to be more precise) are stored in Azure Active Directory.

My first thought was how an authentication mechanism based on an asynchronous replication tool (Azure AD Connect synchronizes accounts every 30 minutes, and passwords within 2 minutes) ever be a reliable and safe solution. The last thing you want to happen is that you cannot authenticate to any service in the Microsoft cloud, because your Azure AD Connect server is busy doing other stuff (like automatically updating its engine for example ).

My second thought was how secure this could be. There’s no inbound connection to the Azure AD Connect server, there’s only an outbound connection on ports 80 (only used for SSL certificate revocation lists) and 443. And the communication itself should be secured as well, so…. But now that PTA is generally available more information becomes available, and things become clearer.

Authentication flow

For authentication to happen PTA uses a ‘service bus’ in Azure. The service bus is a standard Azure solution where application can store system messages in the service bus and where other applications can use these system messages. Using a service bus, you can create an asynchronous but reliable communication mechanism.

When logging to an Office 365 service the credentials are requested by Azure Active Directory, nothing new here. The credentials are encrypted and stored in the service bus. The AuthN agent on the Azure AD Connect server has a persistent connection to Azure AD and to the service bus, and retrieves the encrypted credentials from the service bus, decrypts them and presents them to the on-premises Domain Controller. The Domain Controller response (success, failure, password expired or user locked out) is returned to the AuthN agent and stored it on the service bus. Azure AD picks up this response and the user can continue working (or not of course, depending on the Domain Controller response).

image

Continue reading Azure AD Connect Pass-Through Authentication →

Office365

Upgrade to Azure Active Directory Premium

2 Comments

Recently I was working with a customer who wanted to move from Exchange 2010 on-premises to Exchange Online. This customer had a lot of Mac clients (both internally and externally). Since Mac clients are not a member of the Active Directory domain I asked how these users changed their Domain password. “Using OWA” was the answer, which makes sense.

This poses a problem in Office 365, since the change password feature is not available in Exchange Online (nor in Exchange 2013/2016 on premises BTW). I have to admit, you can change a password in the Microsoft Online Portal, but this only works when using Cloud Identities, and not when you’re synchronizing user account with their password from an on-premises Active Directory.

One nice feature in Office 365, or more specifically in Azure Active Directory is the option to implement Password writeback. This way users can change their password in Office 365, and the new password will be synchronized to your on-premises Active Directory. This is not only very interesting for customers using Mac clients, but also for customer that have (a lot of) users working remotely, without direct access to on-premises Active Directory.

Activating password writeback consists of two steps:

  • Implementing self-service password reset in Office 365.
  • Implementing password writeback.

To enable the self-service password reset functionality you need an Azure AD Basic or Azure AD Premium subscription. An overview of Azure AD options is available on the Azure Active Directory Pricing page. Continue reading Upgrade to Azure Active Directory Premium →

Office365

Password never expire in Office 365

5 Comments

When creating user accounts and Mailboxes in Office 365 the default Microsoft password policy is applied, which means you have to change your password every 90 days.

While it is a best practice to change your password on a regular basis not every customer is too happy with this. I can think of one exception and that’s a service account, this makes sense to have the password set to never expire.

To change this option for user accounts in Office 365 you have to use the Windows Azure Active Directory PowerShell module to connect to Office 365 using the following commands:

$msolcred = get-credential

connect-msolservice -credential $msolcred

Continue reading Password never expire in Office 365 →