The new Directory Synchronisation tool from Microsoft, AAD Sync, went into General Availability a few weeks back. This new tool is toting new features such as Password Write-back, AD Attribute Filtering and multi-forest synchronisation. All in all it is a great replacement to the now defunct DirSync product.
One issue which AAD Sync allows you to solve is the use of UPNs for usernames in Azure Active Directory. A UPN appears as if it is an email address, and often AD user accounts have different UPNs to their Primary SMTP addresses. This can cause confusion for users who expect to be able to login using their email address, just like they would in any cloud service out there. You could change the users UPN to match this, however in some situations this is not possible, either due to existing applications which use the UPN or due to Security policies which do not permit internet routable UPN suffixes.
Before I explain how this works, I must say that this process should only be done on initial synchronisation as you could cause issues if you change this parameter on existing Azure AD instances. More information on the limitations and risks of doing this can be found here: http://social.technet.microsoft.com/wiki/contents/articles/24096.dirsync-using-alternate-login-ids-with-azure-active-directory.aspx
When you configure AAD Sync, you can select which username your AAD users receive based on particular AD attributes, for example, the Primary SMTP address. This allows us to give users with strange/non-conformed AD usernames (such as 17047dd) a useable and memorable AAD username which is the same as their Primary SMTP address (David.Dixon). This configuration is performed in the User Matching section of the configuration, and you must change the userPrincipalName attribute to use the mail attribute.
If your organisation is planning to use ADFS, this poses a problem as the authentication is performed on premise, and your users cannot authenticate using their SMTP address if their UPN is different! To get around this, we can configure ADFS to use the mail attribute for authentication, as per the article below.
There are a couple of issues with this concept of user provisioning and authentication in Office 365, particularly when hybrid deployments are in use. The first is that when users authenticate against ADFS internally using IWA, the UPN will be the authentication mechanism. For domain joined machines this is not a problem (as long as the ADFS hostname eg. sts.doubledit.co.uk is added to Trusted Sites in IE) however if a machine is non domain joined or outside of the internal LAN, the user will receive 2 authentication prompts, one against Exchange Autodiscover (using the UPN) and another to Office 365 once the Autodiscover redirection has taken place (using the Primary SMTP). The second issue is that ActiveSync devices cannot support double authentications and will need to be manually reconfigured to use outlook.office365.com when the users mailbox is moved.
For these reasons it is generally good practice to only implement this solution for migrations with no autodiscover redirection in place, such as pure Office 365 or cutover/staged migrations. It can be successfully used with either AADSync/DirSync w/ Password Sync or ADFS.
Quite often, a users UPN will be different from their Primary SMTP address, and this is a way to allow your Azure AD users to login using their Primary SMTP address without changing the User Principal Name, reducing confusion for the users and creating a more consistent experience.