<div>
Gotcha. &nbsp;I mean I'm only using DirSync with Password Sync right now but eventually may go full ADFS... maybe better to get them accustomed to using the new UPN suffix right away. &nbsp;Any downside to that? &nbsp; <br />
<br />
So the office 365 users I can change their user account over to the UPN in AD User profile so DirSync grabs it and they can continue to login normally as they have been even if that is set to @xxxx.com?
</div>


<div>
When you switch to AD FS they need to have proper UPN, but even then it's not mandatory for them to login to their workstations with the UPN. The 'old' format will still work, and when logging in to O365 resources from within the corporate environment they can have seamless SSO experience even with using domain\samaccountname. <br />
<br />
If they are hitting the O365 portal directly however, they will need to enter the UPN. This is valid for pretty much every credentials prompt they will receive related to O365 resources. So yes, it makes sense to start 'training' them, or at least raising some awareness so they are mindful there is a difference between the two methods at least for some things.
</div>


<div>
Well I mean what's &quot;best practice&quot;? &nbsp;To just let them continue using the traditional domain\samaccountname or switching over to using the UPN to log into their workstations?
</div>


<div>
I cannot say UPN is best practice, because it's not a required attribute and depending on your provisioning process, it might not even be populated for the user. But yes, it's preferable to use it instead of samaccountname.
</div>


<div>
<div class="content wysiwyg-content">
I'm implementing DirSync using Azure AD Connect utility to link existing domain accounts to their existing Office 365 accounts. &nbsp;I've set up the UPN to match the Office 365 domain suffix. &nbsp; As I understand it domain users can still login to their PCs with their standard .local user account in addition to the UPN but SHOULDN'T they login using &nbsp;&quot;username&quot;@xxxx.com instead of their .local account in order to follow same-sign-on standards?
</div>
</div>


I'm implementing DirSync using Azure AD Connect utility to link existing domain accounts to their existing Office 365 accounts.  I've set up the UPN to match the Office 365 domain suffix.   As I understand it domain users can still login to their PCs with their standard .local user account in addition to the UPN but SHOULDN'T they login using  "username"@xxxx.com instead of their .local account in order to follow same-sign-on standards?

When using DirSync (Azure AD Connect) to sync to Office 365 accounts is it best to have users sign in to their domain PCs now using UPN?

Office 365 is a group of software plus services subscriptions that provides productivity software and related services to its subscribers. Office 365 allows the use of Microsoft Office apps on Windows and OS X, provides storage space on Microsoft's cloud storage service OneDrive, and grants 60 Skype minutes per month. Office 365 includes e-mail and social networking services through hosted versions of Exchange Server, Skype for Business Server, SharePoint and Office Online, integration with Yammer, as well as access to the Office software. All of Office 365's components can be managed and configured through an online portal; users can be added manually, imported from a CSV file, or Office 365 can be set up for single sign-on with a local Active Directory using Active Directory Federation Services.

Microsoft 365

Microsoft Azure is a cloud computing platform and infrastructure for building, deploying and managing applications and services through datacenters. It provides both platform-as-a-service (PaaS) and infrastructure-as-a-service (IaaS) services and supports many different programming languages, tools and frameworks, including both Microsoft-specific and third-party software and systems. Cloud Services is a PaaS environment and can be used to create scalable applications and services; there are specific software development kits (SDKs) provided by Microsoft for Python, Java, Node.js and .NET. Azure also has file and storage services, data management, analytics and DNS services.

Azure

Active Directory (AD) is a Microsoft brand for identity-related capabilities. In the on-premises world, Windows Server AD provides a set of identity capabilities and services, and is hugely popular (88% of Fortune 1000 and 95% of enterprises use AD). This topic includes all things Active Directory including DNS, Group Policy, DFS, troubleshooting, ADFS, and all other topics under the Microsoft AD and identity umbrella.