Thus far I have set my environment to Azure Sync with Duo to import my users. I have people display names set to their full name and will use a fake example that is giving me an issue which is "Sean O'Malley". This persons email address which is also their UPN is "firstname.lastname@example.org". I would use the first initial of the first name and full last name after. If there is a person with the same last name and first name that starts with the same first letter, lets say "Sam", then their profile would be "email@example.com".
So, my issue with this profile is that their sAMAccountName would be "seano'malley". Thus normalization would make it so this doesn't match the UPN which would be "somalley". I am wondering then if it would be ok to set "UsernameFormatForService" to "2" so it sends the userPrincipalName as the Duo username (e.g. "firstname.lastname@example.org").
So explaining that here are the summary of my questions and other ones I have:
1) Should setting UPN as the UserNameFormatForService be ok?
2) Would sAMAccountName be the same thing for these two users logging on to the same computer? I believe sAMAccountName sets the filepath for the user like 'seano'malley'. Let's say in a wild scenario there is a person with the same name logging into the computer. One of them would just have a "2" in their upn. But, I wonder if there would be an issue here for their sAMAccountName and how the filepaths for the users being made would be.
3) When doing UAC it asks for email and password now. So, for admin I have to type in ".\admin" along with password. Is there a way to only require "admin" instead? Seems like some users will not remember to do this.
Thanks in advance to anyone with more information on this
1. If you want to send the UPN to Duo as the username then that is how you set the Duo application to send the UPN as the username. However....
2. Is this an Azure-joined workstation with cloud-only users? In that scenario I believe Windows tries to create local sAMAccountNames with the domain "AzureAD\" and doens't disambiguate, leading to possible collisions like you describe. There is a known issue with Duo for Windows Logon and Azure-joined workstations and cloud-only users where because the OS path doesn't create unique sAMs it cannot identify the correct user. Please contact Duo Support to learn more about this and be associated with the bug report for cloud-only Azure user local account username disambiguation at the workstation for Windows Logon.