If this is the case, then Kerberos authentication seems to fail. The LDAP query made by Access Manager uses the sAMAccountName, as this is the name that it sees the user is logged in with.
Use sAMAccoutName instead of userprincipalname as the User Attribute in the Kerberos Class.
In Active Directory there is defined Alternative UPN Suffixes field in Active Directory Domains and Trusts. For example, AD may use domain.local, and there may be an alternative UPN suffix defined, such as company.local. Users can then have this alternative suffix (such as User2.Lastname@company.local) in their userPrincipalName.
After setting the user account with the alternative suffix, Kerberos authentication for that user fails, because the suffix is wrong. The LDAP query made by Access Manager uses only the default Active Directory suffix.
Use the Identity Manager Active Directory driver to add the needed information to some other attribute in Active Directory, such as uid instead of userprincipalname. The content of the uid attribute should be the content of sAMAccoutName the Active Directory domain name. For example, this could be LastUser2@domain.local.
Scenario 1 is actually a bit different than you have described. First, the value used for the search is always the UPN as it is received in the token. you can see this in the NAM log as: amLogEntry> 2015-11-24T20:23:49Z VERBOSE NIDS Application: Performing LDAP search (&(userprincipalname=Adm@POINTBLUETECH.COM)(objectClass=User)) in context com.novell.nam.common.ldap.jndi.JNDIUserStoreSearchContext@2f294d15
The issue is that when the UPN prefix and the samAccountName differ then then windows never even sends the negotiate header. This can be confirmed in the trace.
Scenario 2 can be addressed by adding additional UPN suffixes to the Kerberos class configuration.