We are moving to Office 365 and standardizing on UPN for identification. This required that we create a new UPN suffix for our AD domain. We decided to have our UPN match our email address format. Below are samples of each attribute format:
FQDN for AD Domain: foo.domain.com
NetBIOS Name: FOO
Implicit UPN: email@example.com
Explict UPN: firstname.lastname@example.org
After changing UPN to shorter Explicit UPN for test users, they were no longer able to authenticate to VPN for which they had been using just the "username" with UPN as login attribute, %USERINPUT%@%USERDOMAIN% as domain modifer and FQDN. User to Group mapping was set to sAMAccountName. Working with support discovered that regardless of settings on Authentication Profile, including forcing "domain.com" to replace FQDN, that Group membership would never match correctly although authentication phase worked properly.
Indeed once a user would authenticate successfully, the gateway was unable to verify/match their membership in the remote access AD security group. Debug logs show this:
authenticate -> email@example.com and password is...OK
check group membership for -> domain.com\username....Failed match for name
group members show -> foo\username
So, we changed User to Group mapping to use UPN without any issues. Group membership shows members as follows:
All users now authenticate correctly when using GlobalProtect although it doesn't yet appear to be offically supported.
After implementing this change, users began to complain of not being able to get to specific URLs which are also controlled by User ID and AD group membership. Again working with support, seems User ID, although set to harvest UPN for group membership, doesn't use the same values when validating user group membership or simply identifying users.
While I can revert to NetBIOS (foo\username) format for VPN login, we'd rather standardize on UPN/Email format when authenticating users to the network. We have multiple forests and domains in our environment which makes this a critical issue as we work to combine our directories across the enterprise.
What I would expect to see would be the FQDN within each of the groups mapped so that different UPN suffixes could be suported:
Furthermore, I would expect User ID to identify users based on attributes I've selected, which includes URL filtering groups so that matching can be flexible. For example source users would be identified using UPN rather than NetBIOS format:
firstname.lastname@example.org rather than foo\username
Simple abstraction of the NetBIOS name would make all of this a workable solution. Foo == domain.com
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!