Citrix Web Interface SSO

[ghuber_]

Hi All,

Trying to get my Citrix Web Interface v5.4 to use my Juniper IVE's SSO function.  Unfortunately, it keeps prompting me for a u/p when I launch the bookmark from the IVE homepage.

This is what I did -- I setup a new web resource profile using following settings:

Non-Java ICA Client with Web Interface (Nfuse)

5.2 and above

ICA client connects over CTS client

Set the resource URL to my WI's login.aspx* page; posted the Post URL to the same URL without the * at the end.

Set SSO labels in this order:

User <USER>

Password <PASSWORD>

Domain MYDOMAIN

LoginType Explicit

Left the cookie as the default.

Set the Citrix WI to allow persistent URLs. 

Anything else?

[jayLaiz_]

that is the right settings, when you do the remote SSO with the web profile for citrix, do not make any changes to resource and post url .when defining the Web Interface (NFuse) URL, check for case sensitivity for example C or c in Citrix or X or x in Xenapp.

Regards,

Jay

[Inyoka_]

I had my problems also, quite some time time back. Debugging the forms during logon directly, I came up with the following:

Label                Name              Value
---------------------------------------------------------
LoginType        LoginType       Explicit
User                 user                  <NTUSER>
Password       password        <PASSWORD>
Domain           domain            <NTDOMAIN>
submitMode   submitMode   submit
slLanguage    slLanguage   en
State                 state                LOGIN

In addition, all the fields should be set to "Not Modifiable", of course.

May this help you!

  Mathias

[SVK_]

How do you loginto the SA?

Are you using domain credentials to login to the SA?

How do you login to citrix ?

is Citrix integrated with your domain?

[ghuber_]

Hi SVK,

I logon to the SA using domain credentials (back-end AD auth).  We have explicit/passthrough auth defined on the Web Interface. 

I tried to discuss this with JTAC, but they say this because theWI logon.aspx is a dynamic URL.  In some of the POST data for the login.aspx form, they say there is a dynamic session token being sent.  Because this is dynamic, they say that is why SSO isn't working.

To me that doesn't make much sense.  Sure WI / IIS uses a session token keep tabs on how long a user has been logged in, as well as their session settings.  That is pretty standard.  I can't believe everyone who has gotten the SSO working with WI has this disabled.

Honestly, it doesn't make sense that it is not working that that reason.   

[zanyterp_]

That URL is not dynamic; and yes, as you indicated, there is a session token that is dynamically generated that is not required as part of the POST. Can you send me the case number directly so I can clarify that with your case owner, please?

I'm more concerned about the use of passthrough authentication; I have not yet seen this work as there is no actual credential prompt. Can you enable NTLM/BasicAuth/Form POST on the WI so that there is an authentication prompt?

[MasonDon_]

We have been using it like this for years, but now we're changing things up on how our users sign to the Juniper. The change is using a user certificate for the Primary authentication to the Juniper, then using our Domain username as the secondary authentication. They choose their certificate from their local machine if they have multiple certs installed. It pulls the Domain username from the certificate and passes that to the Juniper Domain secondary login. They are then prompted for their Domain password. My issue now is that the below is trying to send the primary password to the Web Interface, which doesn't exist. I am going to play with them having to enter their password into the Web Interface.

User           user             <USERNAME> Not modifiable
Password password   <PASSWORD> Not modifiable
Domain     domain        OurDomain      Not modifiable
LoginType LoginType   Explicit              Not modifiable
State           state             LOGIN              Not modifiable

[zanyterp_]

Change



to



and the correct, secondary, password will be sent.

[SVK_]

if the username is same as that of the primary only change the password from <password> to <password[2]> this will pass the secondary password to the backend server.

Regards,

SVK