In general you will be fine. I'm not 100% sure if all possible UPNs work or just the configured suffix and the suffix matching the actual domain name of the domain, but both of those definitely will work for normal user logons (just tested on my domain). And that is the only possible pitfall.
See: Why can a user log in via more than one UPN
Edit: Only the configured UPN and the implicit UPN will work (in addition to DOMAIN\user). So if you add more UPN suffixes in the future your users will still only have two options to logon: whichever one is configured for their account and the implicit one (unless they are the same in which case that's their only UPN option). I followed one of the links in the above link.
For a non-Microsoft person, what is ADFS?
ADFS is Microsoft's solution for Single Sign On and web based authentication.
It is used primarily to provide a single set of credentials that can access a variety of sites not necessarily hosted within the same domain.
How does it differ to things like LDAP?
LDAP:
- Communicates using TCP/UDP on port 389 (or port 636 for LDAPS)
- Contains commands for searching/retrieving/adding/deleting/modifying users, profiles and other directory entries
- Can not be performed directly by a web browser, however HTTP authentication can be translated to LDAP using things like Apache's
mod_authnz_ldap
.
- When used for third-party website authentication, requires that username & password are provided to the third-party, which is not ideal for security.
- Is more of an open standard and has numerous Linux implementations.
ADFS:
- Better designed for the web as it communicates over standard HTTPS
- Follows a safer process similar (but not exact) to OAuth where the original username/password are provided directly to the organisation's ADFS server (or a proxy, but not the third-party), which if valid, returns a unique token that can be used to access a third-party website.
- Although it does use make use of some open standards (HTTPS, SAML etc.) it is Microsoft-specific and requires Internet Information Services (IIS) which only runs on Windows Servers.
See also this answer on the subject.
How does it work? What kind of information would be included in a typical request to an ADFS server? Is it designed for both authentication and authorization?
It works by having a single site (site A) that hosts the ADFS / ADFS proxy servers, which has access to the credentials (usually by communicating with an Active Directory Domain Controller). It is then given a trust between other sites (sites B & C) that require authenticating through the ADFS.
When a user attempts to access site B in their browser, the site redirects the user to the ADFS-proxy website (site A) which asks for their username & password, authenticates them, returns a set of cookies for remembering them, and redirects them back to the site B, along with an access token.
If the user then attempts to visit site C, they will also get redirected to site A for authentication from the ADFS-proxy website. If the right cookies exist, the user will not be required to enter their password again, but get instantly redirected back to site C with a token.
The ADFS can be configured with specific claims (or permissions) for the user, for authorization purposes. So it can serve both roles. (Note the difference between authentication and authorization.)
Some people prefer not to use it for authorization but instead keep the permissions management in the third-party website. The obvious downside is that both site A & B need to keep track of user accounts, while in the scenario where ADFS handles both, only the ADFS needs to be aware of the users.
Are ADFS servers typically accessible from the internet (whereas corporate AD domain controllers would not be)?
Yes, nearly always. ADFS is based on the notion that it will be primarily used for website authentication. And is built around IIS.
The ADFS-proxy site is the one that is usually accessible from the internet. However the ADFS itself is not. The ADFS is generally a separate server from the ADFS-proxy.
- ADFS Server
Server that links to the credentials, and has the claims configuration as well as the trusts. Generally not publicly accessible.
- ADFS Proxy Server
Server that hosts the IIS instance that has the login pages for the websites requiring authentication. Communicates back to the ADFS when requiring authentication. Generally publicly accessible.
Best Answer
Ryan and Joe's comments above are on target. It sounds like your users are logging in with their Implicit UPNs. Is your domain's FQDN
us.mycompany.local
?In Active Directory, each user has two UPN's:
Explicit UPN (eUPN): This is the value of the user object's
userPrincipalName
attribute. This can be changed to any value, regardless of any alternate UPN suffixes you have configured in the forest.Implicit UPN (iUPN): This is constructed by concatenating the value of the user object's
samAccountName
attribute with the value of the domain's FQDN. The FQDN is stored as the value of thednsRoot
attribute of the domain'scrossRef
object stored atLDAP://CN=DOMAIN_NETBIOS_NAME,CN=Partitions,CN=Configuration,DC=DOMAIN
)Jorge de Almeida Pinto, a DS MVP, has a series of posts that go into much more detail:
EDIT 1:
It's also worth noting that the eUPN "wins" if there is a conflict. For example, consider the following (albeit ridiculous) scenario:
example.com
user1
user1@example.com
If you attempt to login using the username
user1@example.com
, you will be logged in asUser2
. However, if you change User2'suserPrincipalName
to anything else, you would be signed in asUser1
.EDIT 2:
More info per MS: MSKB929272: Interactive logon styles and Key Distribution Center account lookup in Windows Server 2003