question

Matt-2690 avatar image
0 Votes"
Matt-2690 asked zsaltzman commented

SAML UPN Claim for B2B guest user changing to Mail attribute

I'm using Azure AD to provide authentication for Citrix Netscaler via SAML. To solve a particular problem, I'm setting up a Citrix Storefront for external vendors that I'm wanting to set up for them to use their own companies login via Azure B2B. I've used the Azure B2B to On Premise AD Powershell sync script to sync the B2B users to the on prem AD.

The problem is that Azure AD is transforming the guest users from the UPN format of "user_guestdomain.com#EXT#@domain.onmicrosoft.com" to the guest users mail address (eg, user@guestdomain.com). This obviously means that the authenticated user isn't matching to the synced on prem user object which creates the UPN in the original format. According to this article this is an automatic transformation that happens with the assumption that the original format wouldn't be desired. Is there anyway to disable this and have it pass through unaltered?


azure-ad-app-registrationazure-ad-authentication-protocols
· 1
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

I've run into your same problem @Matt-2690 and after some troubleshooting I think I see where the problem is.

When the Source of the guest user is Microsoft Account, the UPN sent is the correct "user_guestdomain.com#EXT#@domain.onmicrosoft.com" format.

When the Source of the guest user is External Azure Active Directory, the UPN sent is "user@guestdomain.com" which is probably their actual UPN in their Azure tenant.

Option 2 is obviously a problem when trying to deal with the AD shadow accounts for Citrix.



EDIT: The fix is to use user.localuserprincipalname in the Unique User Identifier (Name ID) claim, this will make it use the .onmicrosoft.com upn even for External Azure Active Directory guests.

0 Votes 0 ·
Kalam-6077 avatar image
0 Votes"
Kalam-6077 answered Matt-2690 commented

The fix is to use user.localuserprincipalname in the Unique User Identifier (Name ID) claim, this will make it use the .onmicrosoft.com upn for External Azure Active Directory guests as that's their upn in your tenant..

· 3
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

Did this work for you with Netscaler SAML authentication? I changed over the unique user ID field in the SSO properties to localuserprincipalname but it doesn't seem to have made a difference - the Netscaler is still receiving the non .onmicrosoft UPN.

I might have to reset some things as I had messed around a bit with the config previously to try get things working but after not getting anywhere I benched it to work on other stuff.

0 Votes 0 ·

Yes, I'm using this with our Citrix ADC (latest 13.0 version, but should work fine in 12.1) for SAML authentication. Use the browser extension SAML-tracer to see SAML response, it should contain:

<NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">user_email.com#EXT#@domain.onmicrosoft.com</NameID>

for both types of Azure guests, Microsoft Account and External Azure Active Directory.

0 Votes 0 ·

Thanks! Turns out back when I was trying different things I set up a new App Registration. Changing the Unique ID mapping for that app solved the issue.

So yes, using localuserprincipalname is now working with the Netscaler and B2B guests can now log into XenApp!

0 Votes 0 ·
amanpreetsingh-msft avatar image
0 Votes"
amanpreetsingh-msft answered amanpreetsingh-msft edited

Hello @Matt-2690


You have full control over the attributes that you want to pass in SAML token for the federated Citrix Netscaler enterprise application.


For this purpose, you need to navigate to Azure Portal > Azure AD > Enterprise Applications > Citrix Netscaler > Single sign-on > SAML-based Sign-on > edit User Attributes & Claims > edit the claim you want to customize i.e., Name ID or any other claim that you want to pass in the SAML token and select the attribute you want to pass as Claim. You can also add additional claims and transform the claims using this option.


12544-image.png


Below is a snippet from one of my SAML token where I am passing mail as emailaddress and UPN as name claim:


12498-image.png




Please do not forget to "Accept the answer" wherever the information provided helps you. This will help others in the community as well.



image.png (32.8 KiB)
image.png (22.4 KiB)
· 4
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

Unfortunately, that's not what is happening. As per the article I linked to above "When user.userprincipalname is chosen for the User Identifier, AAD knows to use the mail value if the user UserType is Guest"

So the UPN that is passed to the Netscaler is "user@guestdomain.com" rather than "user_guestdomain.com#EXT#@domain.onmicrosoft.com"

0 Votes 0 ·

@Matt-2690 The article you are referring to was last updated more than 2 years ago by MVP community. Maybe this was true when the article was published. I have tested and confirmed that this is not the case now. If you pass user.userprincipalname attribute, you will get "user_guestdomain.com#EXT#@domain.onmicrosoft.com" and not "user@guestdomain.com".




Please do not forget to "Accept the answer" wherever the information provided helps you. This will help others in the community as well.


0 Votes 0 ·

Except what you're suggesting is not happening. I can see in the logs of the Netscaler that Azure is passing through the UPN as "user@guestdomain.com". So while that article might be two years old it seems to still be relevant.

Here is my Claims setup in Azure:
12594-claim.png

Here is the mapping in Netscaler:
12595-netscaler.png

And here is the log from Netscaler showing what UPN it's receiving (edited out personal info):
12643-netscalerlog.png


0 Votes 0 ·
claim.png (14.7 KiB)
netscaler.png (3.6 KiB)
netscalerlog.png (17.9 KiB)

@Matt-2690 That is strange. When I am testing this out, I am getting UPN and not the email address.


12589-capture.jpg


12661-untitled.png


Did you try capturing entire SAML response using fiddler or HAR file to confirm what value is being passed as Name ID in the token? Are you passing any additional attributes to Netscaler and if that is the case, have you confirmed if NameID is being used as username in Netscaler?


0 Votes 0 ·
capture.jpg (23.2 KiB)
untitled.png (15.6 KiB)
PLeinhauser avatar image
0 Votes"
PLeinhauser answered zsaltzman commented

It's been a few months since this thread opened but I wanted to see if there has been any better understanding of this.
I have an app which I am using UPN for the uniqueID. I can't use email because that can change for a user but UPN will never change. So, in my SSO apps, I use the 'user.userprincipalname'

I came across the "user_guestdomain.com#EXT#@domain.onmicrosoft.com" format when I included my Gmail account as a guest SSO user. That is what was on the token for the NameID. If I use that in the SSO app for my fedID, I get access. Now, when I setup another external user and I assumed the NameID would be the same so that's what I used in the app but for this user, the token had their real email address for the NameID on the token. I found that the user with their real email as the NameID is using their Azure federation credentials. In the Azure AD user profile, that user is a type:Guest BUT the source shows: External Azure Active Directory. My Gmail account source is: Microsoft Account.

I haven't dug deeper into this yet but this is my suspicion. I was doing that research when I came on this article. Can anyone else confirm what I'm seeing?

Thansk,
Phil

· 2
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

PLeinhauser - I realize this is a late reply but I can relay my testing experience with this exact issue.

user.userprincipalname works fine for External Guests who show "External Azure AD" as the source, however, if a "Microsoft Account" source is added, this will fail.

To get around that, using user.localuserprincipalname instead, then allows the "Microsoft Account" guests to login, but it breaks login for other AAD guests.

Ultimately we ended up having to include two Identity Claims

1) All Guests -> Attribute -> user.localprincipalname
2) AAD Guests -> Attribute -> user.userprincipalname

Now both "Microsoft Account" guests as well as "External Azure Active Directory" Guests can both authenticate without issue

43851-image.png


0 Votes 0 ·
image.png (36.4 KiB)

FYI for anyone still looking at this. AmandaSwartz-6356's reply got us moving in the right direction, but we found that for the "All guests" type, the "user.localuserprincipalname" was still returning the full/mangled value of "user_guestdomain.com#EXT#@domain.onmicrosoft.com" and NOT just the actual email address.

We update this value to "user.mail" and now everything is working for external guests, AAD guests, and members.

Reference:

128326-image.png


0 Votes 0 ·
image.png (12.2 KiB)