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?

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?
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Vasil Michev (MVP)Commented:
It doesnt matter, this is only relevant when using AD FS and logging directly to O365 resources. After you configure the new UPN suffix and assign it to users, they can use either user@domain.com (UPN) or domain\samaccountname format to login to their workstations.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
debbiezAuthor Commented:
Gotcha.  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.  Any downside to that?  

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?
Vasil Michev (MVP)Commented:
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.

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.
debbiezAuthor Commented:
Well I mean what's "best practice"?  To just let them continue using the traditional domain\samaccountname or switching over to using the UPN to log into their workstations?
Vasil Michev (MVP)Commented:
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.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Office 365

From novice to tech pro — start learning today.