About mchaffin

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:  username@foo.domain.com Explict UPN:  username@domain.com Email:  username@domain.com   Problem: 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 -> username@domain.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: foo\username1 domain.com\username2 foo\username3   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: domain.com\username second.com\username third.com\username   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:   username@domain.com rather than foo\username   Simple abstraction of the NetBIOS name would make all of this a workable solution.  Foo == domain.com  ... View more