Using two variables in Basic SSO for USERNAME

[Frostie_]

Hello,

I«m trying to create a Basic SSO for a internal web ressource.

As the Webserver requires the Domain Name within the Username for authentication (Domain \ User),

I want to build it using two system variables.

In my case these are...

userAttr.ReplyMessage which contains the Domain Name (e.g."DomainA")

Username[2] which contains the Username (e.g."JohnD")

My Basic SSO definition for the Username looks like this.

<userAttr.ReplyMessage>\<Username[2]>

But unfortunately it seems that the SA only resolves the first variable and tries to do the login with...

DomainA\<Username[2]>

I tried different variables just to be sure, but the SA always resolved only the first variable. All following variables were interpreted as text.

Putting the Domain Name directly in the field for the Username works (DomainA\<Username[2]>),

but it has to be variably.

Does anyone has an Idea how to solve this problem?

Regards,

Marc

[zanyterp_]

are you using two auth servers? if not, you should only need <username>. 

if yes, what is your secondary authentication server? if it is AD, <username[2]> is sending domain\username\username.

you can check what is actually being sent by taking a dsrecord and looking at the information in there (look for the traffic after www-authenticate: basic)

[Frostie_]

I was able to work around this.

The Web Server also accept the UPN for login, so I«ve added userPrincipalName to the server catalog of the LDAP Server to use it for SSO.

Nevertheless I think the behaviour of the SA isn«t correct when using two (or more) variables for the username in SSO.

I can see in the logs of the Web Server that the SA tries to login with DomainA\Username[2] .

If I only use userAttr.ReplyMessage it tries to login with DomainA. (means the variable is filled corretly with the Radius Reply Message "DomainA")

If I only use Username[2] it tries to login with JohnD. (means the variable is filled correctly with the username used for the secornd authentication)

If I combine them in SSO, the SA tries to login with DomainA\Username[2].

I also tested it with <Username>\<Username[2]> just to see what happens. And the SA combined this to

something like PeterM\<Username[2]. (where PeterM is the name used for the first authentication).

So for me it seems that the SA stops to resolve any variables after it resolves the first one.

Maybe I should open a ticket for this.

[zanyterp_]

what should you be seeing if not domainA\username2?

yes, you will need a case if it is not working correctly. can you share a policy trace of this with me as well? i would like to see if i can come up with something else that way.

thank you.

[Frostie_]

Well...i should be seeing the content of both variables, not the content of the first one and the name of the second one

Maybe I did not expressed it correctly, so I took two snapshots.

One of the SSO settings and one of what I see in the logfile of the webserver which gets the request.

The variable <[email protected]> is filled with the value "Testdomain"

The variable <Username[2]> is filled with the name used for the second authentication. Here it is "Testuser".

So I would expect so see something like "Testdomain\Testuser " in the weblog.

__

[zanyterp_]

Do you mean you are seeing the literal phrase "<username[2]>" in your logs rather than what the username actually is?

Are you using two distinct usernames or the same and but different passwords

[Frostie_]

You are correct. That«s what I mean.

I use two different usernames with different passwords.

The first one ist for radius authentication and the second one for LDAP authentication.

[zanyterp_]

Odd; I will see if I can replicate in my lab & update you on what I see. Do you have a case yet? If yes, can you let me know the number?

What do you see being sent on the wire (since it's basic auth you should be able to see it)? What about the TCP dump?

[Frostie_]

I opened a case and support told me, that this is a known behaviour which has been fixed in 7.1R6 (I use 7.0R7).

Ok...this answeres my question.

I then asked about a KB article to this issue. Because I wasn«t able to find something about that in the Knowledge Base. He told me that Juniper has not published a KB article, because this issue / fix is mentioned in a few 7.0 and 7.1 release notes.

Thats a little bit odd. I mean...what good is a Knowledge Base If I don«t put information about all bugs / fixes in there. I certainly will not read through all release notes to see if a specific behaviour I just discovered is a bug or not. A simple article like "This is a know behaviour and has been fixed in 7.1R6" would have solved this issue for me within minutes.

But ok...this should be part of another discussion.

Thanks for your replies and efforts to help me with that.

[zanyterp_]

you are welcome; i am sorry i did not realize this was already known (oops). i checked and this is slated for a future 7.0 release; i will try to remember to pm you when it is out (due to release schedules, it is targeted, currently, for late-june/july).

as to this being put in a kb in addition to the release notes, the kb system is designed to give information on config details in more of a one-off form and the release notes are for fixing failure points. if we put them in both places, one will suffer/be out of date. in addition, the release notes are indexed for inclusion in search results in the kb system. with all that said, i do understand what you mean and we do occassionally do that, depending on how long the issue appears it may last (e.g. vista support, lion support).