UserLogin vs. UserName
Closed this issue · 13 comments
This isn't really an "issue" with the app (I don't think...), but more of a problem that we are having with implementation. The only way we have been able to get the display names to show up correctly (for instance, in the top right-hand corner of the SharePoint pages) is by setting the Unique Identifier in AzureCP to DisplayName. However, if we do that, it also changes the UserLogin values to i:0e.t|azuread|, which we do NOT want.
How do we get the user's Display Name to show up as their username, and still use their UPN for their UserLogin value?
AzureCP should always set the value with the UPN, regardless of the display name which is different.
Can you check the SharePoint logs and filter on product/area "AzureCP" to see exactly how AzureCP creates the entities?
And you can configure this in AzureCP "Global configuration" page, and more deeply in the "Claim types configuration" page
When you say “ AzureCP should always set the value with the UPN”, which value are you referring to? The SP UserLogin value? When we change the AzureCP unique identifier to DisplayName, it is setting the UserLogin value to [claims header]|[DisplayName], and the SP Name value to [DisplayName]. When we set the AzureCP unique identifier to UPN, it is setting the SP UserLogin value to [claims header]|[UPN], and the SP Name value to [UPN].
I will have to get you that info tomorrow. It’s after 3AM here, and I’ve got to get to bed. We do have a Production deployment scheduled for less than 48 hours from now though, so I will try to get it to you as soon as I can. Even if we do have to go to Production like this though, I’m not too concerned, as it only seems to be effecting the new users that we add to SP. The users that we convert using Convert-SPWebApplication do appear to be keeping their correct DisplayName value for the SP Name attribute, and only the SP UserLogin value is getting changed to the UPN format. That convert command is being run while the Trusted Token Issuer is still configured to use AzureAD though. We only change it to use AzureCP after the conversion (otherwise the Convert-SPWebApplication command fails).
The user identifier is always the trailing part:
i:0e.t|aadtrust|aaduser1@tenant.onmicrosoft.com
With Azure AD, this identifier is always the userPrincipalName (for members) and you should really not change it.
But AzureCP lets you choose a different attribute to display (here I set it to DisplayName):
We have ours set to OnPremiseUserPrincipleName because we do not use our On-Prem AD UPNs as the identifier when syncing our users to Azure. We use the On-Prem AD user's mail attribute to sync them to Azure. This is because we have almost 800 different domains, so it was going to be impossible to add them all as additional suffixes to our On-Prem AD. So... That is why we use OnPremisesUserPrincipleName instead of UPN for the unique identifier in AzureCP.
We do have the display setting set to DisplayName, but that is not what is being displayed in our QA Farm. What is exceptionally strange is it works as expected in our DEV Farm. Just not in our QA Farm. Both Farms use the same App Registration in Azure, and appear to have the exact same configurations in SharePoint.
QA Farm:
QA Farm:
DEV Farm:
DEV Farm:
I can't provide you any logs for when AzureCP creates the entities because it is not even finding them when I search by DisplayName. It only finds a user when I search by their On-Prem UPN. Here are the log entries for when it fails to find a user by DisplayName, though:
12/08/2020 14:18:06.41 w3wp.exe (0x5294) 0x00BC AzureCP Core 1337 Verbose [AzureCP] Getting new access token for tenant 'CED.onmicrosoft.com' on cloud instance 'AzurePublic' using client ID e154b69b-ebbb-44c7-8f11-785f3bb74351 and a client secret. a962959f-0936-d0c2-034a-ce39647173c8
12/08/2020 14:18:06.82 w3wp.exe (0x5294) 0x45E4 AzureCP Core 1337 High [AzureCP] Got new access token for tenant 'CED.onmicrosoft.com' on cloud instance 'AzurePublic', valid for 1 hour(s) and retrieved in 407 ms
12/08/2020 14:18:06.98 w3wp.exe (0x5294) 0x1FA0 AzureCP Lookup 1337 Medium [AzureCP] Got 0 users/groups in 552 ms from 'CED.onmicrosoft.com' with input 'Evan Talley' d962959f-d9e0-d0c2-034a-c68683e75721
We are actually having the same problem in the DEV environment now. I'm not sure what changed that could have caused the SP Name value to change from DisplayName to OnPremisesUserPrincipleName when we add new users in DEV now. It does still at least allow me to search by DisplayName, though, and the preview even shows the account as:
AzureCP
DisplayName=Sunil Kunapalli
Here's a screenshot of that:
Here are the logs from when I just added this user to a group on the SP site:
12/08/2020 17:57:57.79 w3wp.exe (0x54EC) 0x30F8 AzureCP Lookup 1337 Medium [AzureCP] Got 1 users/groups in 172 ms from 'CED.onmicrosoft.com' with input 'Suni'
12/08/2020 17:57:57.79 w3wp.exe (0x54EC) 0x1EF0 AzureCP Lookup 1337 Verbose [AzureCP] 1 entity(ies) to create after filtering 726f959f-235e-c0f0-e7ec-29dde7d966d4
12/08/2020 17:57:57.79 w3wp.exe (0x54EC) 0x1EF0 AzureCP Claims Picking 1337 Verbose [AzureCP] Added entity: display text: 'Sunil Kunapalli', claim value: 'SKunapalli-c@SYSTEMS.CED.local', claim type: 'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn' 726f959f-235e-c0f0-e7ec-29dde7d966d4
12/08/2020 17:57:57.79 w3wp.exe (0x54EC) 0x1EF0 AzureCP Claims Picking 1337 Medium [AzureCP] Returned 1 entities from input 'Suni' 726f959f-235e-c0f0-e7ec-29dde7d966d4
12/08/2020 17:57:58.16 w3wp.exe (0x54EC) 0x3398 AzureCP Lookup 1337 Medium [AzureCP] Got 1 users/groups in 74 ms from 'CED.onmicrosoft.com' with input 'Sunil'
12/08/2020 17:57:58.16 w3wp.exe (0x54EC) 0x1EF0 AzureCP Lookup 1337 Verbose [AzureCP] 1 entity(ies) to create after filtering 726f959f-b37b-c0f0-e7ec-221dc6137ea1
12/08/2020 17:57:58.16 w3wp.exe (0x54EC) 0x1EF0 AzureCP Claims Picking 1337 Verbose [AzureCP] Added entity: display text: 'Sunil Kunapalli', claim value: 'SKunapalli-c@SYSTEMS.CED.local', claim type: 'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn' 726f959f-b37b-c0f0-e7ec-221dc6137ea1
12/08/2020 17:57:58.16 w3wp.exe (0x54EC) 0x1EF0 AzureCP Claims Picking 1337 Medium [AzureCP] Returned 1 entities from input 'Sunil' 726f959f-b37b-c0f0-e7ec-221dc6137ea1
12/08/2020 17:58:02.99 w3wp.exe (0x54EC) 0x1EF0 AzureCP Lookup 1337 Medium [AzureCP] Got 1 users/groups in 175 ms from 'CED.onmicrosoft.com' with input 'skunapalli-c@systems.ced.local' 726f959f-b37b-c0f0-e7ec-221dc6137ea1
12/08/2020 17:58:02.99 w3wp.exe (0x54EC) 0x4874 AzureCP Lookup 1337 Verbose [AzureCP] 1 entity(ies) to create after filtering 736f959f-b368-c0f0-e7ec-20e7fb6ac450
12/08/2020 17:58:02.99 w3wp.exe (0x54EC) 0x4874 AzureCP Claims Picking 1337 High [AzureCP] Validated entity: display text: 'Sunil Kunapalli', claim value: 'SKunapalli-c@SYSTEMS.CED.local', claim type: 'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn' 736f959f-b368-c0f0-e7ec-20e7fb6ac450
This is what the user appears as, after adding them. Notice that the SP Name value is the OnPremisesUserPrincipleName, instead of the DisplayName:
I will say that I did have to make one change to the Trusted Identity Provider today. I'm not sure if that is related. I haven't made ANY changes to the AzureCP configuration, though. The change I made to the TIP was, I changed the ClaimsProviderName from AzureCP, back to AzureAD temporarily. I had to do this so that I could run Convert-SPWebApplication against an additional WebApp. After the conversion of the claims for that WebApp was completed though, I immediately changed the ClaimsProviderName on the TIP back to AzureCP. I can't imagine that causing this issue.....
I reset the AzureCP config, and then add my tenant back, change the identifier to OnPremisesUserPrincipleName, and change the Display value to DisplayName. That seems to have fixed the issue in my DEV environment. However, doing the same thing in my QA environment did NOT fix the issue. The OnPremisesUserPrincipleName is still being used for the SP Name value. This is causing some permissions to get removed when users log into the sites. I am not sure what else to do here. Why is it not honoring the DisplayName setting??
I just discovered that it is only working incorrectly for at least SOME users. For instance, I just added two other users, and it added them with the correct DisplayName values. When I add my own account though, or a handful of other accounts that I know of that have been experiencing the same issue, it still uses the OnPremisesUserPrincipleName for the SP Name value! Why would it be working one way for one account, and another for another account? All of the accounts are coming from the same Claims source! In fact, it is our ONLY claims source (I hid the On-Prem AD source).
Ah Ha! I figured it out in QA. I had to remove my old account that was still using the UPN as the displayname (using Remove-SPUser). THEN, when I added a new permission for my account, it used my correct display name.
@Grime121 nice catch. To avoid this kind of confusion in such tests, you can try in new site collections, where users/groups don't exist yet in the UserInfo table.
Is it safe to delete entries from the UserInfo table that have the tp_Deleted value (or whatever that column is called) set to a non-zero number? Or can that cause issues? Surely there is some way to clean up that table.... We’ve had these Content DBs going back to SP 2010, and are a fairly large company. So, there are a TON of deleted users in there. Not to mention (and more importantly) the user accounts that are no longer valid, such as the no longer used <UserName> formatted login IDs, and now all of the Windows Claims accounts that have been replaced with Trusted Claims accounts. I’d really like to clean out all of those after 1) Converting to Claims-Based login IDs when we upgraded to SP 2013, and 2) Converting to Trusted Claims IDs during this current project.
There is no supported way to delete entries from the UserInfo table, even for stale, long deleted users.
That’s too bad. We’re still having some sign-in issues with one of the three sites in PROD, but it doesn’t appear to be related to AzureCP. The permissions all look correct, but users are still getting “Site is not shared with you.” Hopefully we can get it sorted out this evening, though. Thanks for helping me work that issue out with you!