Variable userAttr.userPrincipalName not filled

[Frostie_]

Hello all

If have a problem in understanding when the SA will fill a system variable and when it will not.
Actually it is about userAttr.userPrincipalName.


The Situation

We have five domains from/to which the users must be able to authenticate at the SA.
The first authentication on the SA uses radius (a unix box) with LDAP for the directory search.
The second authentication uses LDAP to the Root-DC«s of the Active Directory.

Because we need a unique username for the radius server, we have choosed the UPN as the login name for the users.
E.g.

[email protected]

So in the LDAP Auth Server the filter is set to userPrincipalName=<USERNAME>.
This works fine. And as the <username> contains the UPN, I can use this variable for SSO.



The Problem


Unfortunately the UPN isn«t really short, so now I have been asked if it is possible to shorten the login name
for the users.

To accomplish this I«ve splitted the username (which actually is the full UPN) in a dynamic part, which the user enters,
and a static part, which the SA adds in the LDAP filter.

Means...The User logs in with "[email protected]" and the SA will add the missing ".company.com" in the LDAP search.
by a filter looking like this: userPrincipalName=<USERNAME>.company.com

This works fine so far, but now I can«t use <username> for SSO, as it doesn«t contain a valid username anymore.
So I thought I could use userAttr.userPrincipalName instead.

And here is the problem. Because depending on which LDAP Server I query or want kind of filter I use,
the SA doesn«t fill this variable.

So I did some tests.
Just to remember....I query the Root-LDAP which will redirect to one of the Domain-LDAP, depending on the
Domain of the user.


Query goes to Root-LDAP
User logs in with full UPN ([email protected])
Filter is set to : userPrincipalName=<USERNAME>

==> Variable userAttr.userPrincipalName is empty


Query goes to Root-LDAP
User logs in with part of UPN ([email protected])
Filter is set to : userPrincipalName=<USERNAME>.company.com

==> Variable userAttr.userPrincipalName is fill with UPN



Ok...now something strange. This query goes to the LDAP von Domain "abc".
The same which answered the query above.

Query goes to Domain-LDAP of Domain "abc"
User logs in with part of UPN ([email protected])
Filter is set to : userPrincipalName=<USERNAME>.company.com

==> Variable userAttr.userPrincipalName is empty




Then I«ve added a rolemapping rule to the realm like
"userAttr.userPrincipalName = dummy"

==> Variable userAttr.userPrincipalName is fill with UPN



Removed the dummy rule above an added an SSO using
<userAttr.userPrincipalName> as Username


==> doesn«t work




Arrrrg.



Can anyone explain me when the SA will fill userAttr.userPrincipalName with content
and when it does not?

I would love to shorten the usernames and use userAttr.userPrincipalName for SSO,
but how if I can«t be sure it will be filled?

[zanyterp_ · Accepted solution]

Have you added userPrincipalName to the LDAP server catalog to tell the IVE to retrieve that attribute from the server? This is set at Signing In>Auth Servers>LDAPserverName, Server Catalog>Attributes (put it in the text box on the right and add new if it is not already populated in the left column).

Do you see this populated when you run a policy trace?

[Frostie_]

Hello

No. I haven«t added it to the server catalog, but now I have. And now it fills the variable, no matter which server I query. Something else that i«ve learned

Thank you.

That solves my problem to reliably fill the variable, but I still doesn«t understand why the SA fills the variable when querying the Root-LDAP, but does not when the query goes to the Domain-LDAP.

I did all the queries with the same LDAP Auth server and only changed the IP address of the LDAP to query

(without the attribute added to the catalog).

Do you have an answer for that behaviour? I just want to understand the logic behind that.

[zanyterp_]

Glad to hear it is working for you; not sure how you got it sometimes and not others without the attribute being set in the server catalog.

For your other question how do you mean "root-LDAP" vs "domain-LDAP" (sorry, these are not terms I have heard yet)? Regardless of the terms, can you check at least one of the following to see what the difference is when connecting:

1) IVE TCP dump to the root LDAP server and one to a domain LDAP server (please note that this will need to be done using LDAP rather than LDAPS as the protocol in order to check the data). Once you have both captures, do you see a difference in attributes returned when filtering for "ldap" in wireshark/ethereal/preferred TCP sniffer?

2) If you connect to the servers using an LDAP browser, such as the one from softerra (free download using the LDAP browser 2.6 tab, http://www.ldapbrowser.com/download.htm), do you see a difference in the user attributes? This may be a better idea, if possible, as it removes the IVE from the picture and the servers can be queried using either LDAP or LDAPS. This will let you see how the catalog of users looks through LDAP without needing to filter through a TCP trace.

[Frostie_]

Ok. My fault. The terms "root-LDAP" and "domain-LDAP" are just abbreviation for "The LDAP Server of the Root-Domain" and "The LDAP Server of the Sub-Domain". I tried to shorten the text :-)

As I wrote in my starting post, we have five domains in an AD-Forrest.

The Users connecting to the SA are from any of these domains, which means that for the directory search I have to query the LDAP Server(s) of the Root-Domain.

In my tests I logged in (for example) as [email protected] .

As LDAP Auth Server I used the LDAP Server of the Root-Domain company.com (the "Root-LDAP" )

It answered with the referral to the LDAP Server domain1.company.com.

The SA then queried the LDAP Server of the Sub-Domain domain1.company.com and got the account information of

[email protected] (containing the UserPrincipalName)

I already traced this with tcpdump / wireshark

Then I changed the LDAP Auth Server to the LDAP Server of domain1.company.com (the "Domain-LDAP ").

Compared to the LDAP Auth Server for the Root-Domain, all I changed were the IPs and the Admin DN.

I logged in as [email protected], the SA queried the LDAP Server of Domain1.company.com (the same as in the query above) and got the account information. But without the UserPrincipalName.

That«s the point I don«t understand. In the end both queries goes to the same server and asks for the same information. But only one of them got the UserPrincipalName

Maybe this isn«t related to the SA but to LDAP itself. I«m not an LDAP expert

[zanyterp_]

Thank you for sharing your testing and outcomes.

It does sound like it might be an LDAP-behavior; I'm not an LDAP expert either, I just have learned ways to test to try and determine which side of the connection may be causing an issue. Based on your testing results it does appear to be the way LDAP is handling the queries for some reason is different since the server itslef doesn't send the attributes.

Sorry I'm not able to help more than that.

[fuman_]

Hi,

I am not sure if I really understood your problem but let me try...

There is more than one option to build a variable for the UPN. Normally your different LDAP server have a name (In this case I use AuthServername as an example ->"under Auth.Server on the Authentication area.....)

If you have more than one Authentication Server it might be a good idea to build your variable for the UPN like this if there is more than LDAP Authentication Server:

<[email protected]> instead of <userAttr.userPrincipleName>

(works for me ...)

But be aware that beginning with 6.5 the actual IVE OS versions have a strange bug with the variable for the UPN !!.

Web SSO (with Basic Authentication) did stop working in my Environment after upgrading from 6.4R5.1 to 6.5.

<[email protected]> (or the version which you did use: userAttr.userPrincipalName) does not transmit the domain-part of the UPN.

I was getting crazy on this problem since a couple month now and worked together with the Juniper support since this time - till Juniper was able approve this strange behaviour. The Juniper Support found the problem finally and told me that they are working on a fix.....(Still waiting)

The Problem is newly listed in known/unfixed Limitations of IVE OS 6.5R6 and the Release Notes give a hint that it may be a problem on previous Releases too. I have had the issue with all 6.5 (R1-R6)and the new 7.0R Firmware Releases.

Link to the release Note

"Known Issues/Limitations in 6.5R6 Release
The following list enumerates known issues in this release. Some of these issues may exist in previous releases as
well: 1. Web-sso - SSO polices working in 6.0 do not work after upgrade to 6.5 (479100)"

In my Case the problem did NOT show up on IVE OS 6.4 (R1 -R5.1) and earlier versions of the firmware ......(I did not test 6.4R6-R8)

Perhaps you have the same problem.....(depending on your IVE OS Version...) This may not be a solution, but i hope it can give you a useful information..

[Frostie_]

Hello

thanks for the information., even I don«t think that I«ve hit the bug you mentioned.
My problem simply was that the UPD had not been filled at all, regardless whether I used <userAttr.userPricipalName> or <[email protected]>, because I did not add the UPS to the auth servers catalog.

The rest was an attempt to understand / figure why the SA sometimes fills the UPD, even the UPN was not added to the
server catalog.

However..my main problem is solved (thanks again) and that«s what counts.