Customizing Network Connect login pages

[bentyger_]

Hello all,

I am currently having a some problems with my Juniper IVE running JunOS 6.2. I am currently trying to disable Netconnect Connect stand-alone in a per-realm fashion. This means I can't use the Network Connect ACLs. I researched (Custom Sign-In Pages Solution Guide) and found that if you make a file <filename>-stdaln.thtml it will only apply to the Network Connect stand-alone. I.E. LoginPage-stdaln.thtml would be the default page. This pages has no forms in it, so the user cannot login.

When I direct Network Connect to the proper URL, it is still using the LoginPage.thtml and not the LoginPage-stdaln.thtml. Does anybody know why this may be happening? I've already opened a ticket with JTAC, but it doesn't seem very promising.

I have attached my LoginPage.thtml for people to investigate. It has been scrubed for of sensitive data.

[cbarcellos_]

I'm not clear on your question. Are you simply trying to disable the users ability to launch the stand alone network connect client? Or are you trying to disable access to network connect entirely, based on realm?

Access on the IVE is given based on role permissions. If you do not want a user to have access to something, do not map the user role that gives access to the resource to the user. This is normally done by LDAP or AD group membership user role mapping (under the realm).

[bentyger_]

I'm trying to disable remote access via Network Connect stand-alone client, but I need users to be able to login via a real browser (IE, Firefox). There is a security application between juniper login page and the submitted post that is bypassed when using Network Connect. Thus we need to disable Network Connect login but not normal logins.

[cbarcellos_]

What is being bypassed exactly?

[bentyger_]

We rewrite the login action addresss on the form tag and remove the password field. Bascially it is a sanctioned MitM attack.

That shouldn't matter for my problem though. If i'm getting the default login screen, it is already too late for my needs.

[cbarcellos_]

You can try to disable the standalone browser with the stand alone login page template, but I am not sure what coding could do that; Someone else here on the board might be able to help with that.

Other than the above, I don't see any other way to disable the stand alone browser. You could try to do disable it via UserAgent restrictions, but I don't know if the stand alone minibrowser shares the same UserAgent as IE does.

[bentyger_]

> You can try to disable the standalone browser with the stand alone login page template,...

That's what I am trying to do but the documentation I am finding on how to do it doesn't seem to work. I'm just trying figure out why this method isn't working. So it is sort of aggrivating. I was wondering if anyone in the community knew why this may be happening.

Here is some environment info:

Juniper IVE

Model: SA-2000

OS: 6.2R1 (build 13255)

[ruc_ · Accepted solution]

There are two options to do this:

Option one: Using the custom sign in page (which is what you are trying to do) For this

1. Download the sample.zip sign-in page template

2. After your done with all your customizations make a copy of the file 'LoginPage.thtml'

3. Open this file and remove the form elements (for a crude test I removed everything between <blockquote> and </blockquote>). I was using a beta build of 7.0R1. Note: Removing this entire section *may* have other implications.

4. Save this file as 'LoginPage-stdaln.thtml'

5. Create the zip package and upload it as the custom sign associated with your sign in URL.

Option two: Using user-agent realm level restrictions

1. Go to Realm > Authentication Policy > Browser > And select the option 'Only allow users matching the following User-agent policy.'

2. Under the sub option add an '*' (Allow) policy

3. And then add another policy for the string 'NcWin32*' and action should be 'Deny' (make sure this policy is on the top)

While you can use either one of the above (or actually maybe even both together) to stop the standalone NC client from login, I would prefer option 2 as its much cleaner and also because custom sign in page customizations are very sensitive and if one is not used to html, javascript, etc then it may need a bit of trial and error.

[bentyger_]

Thanks for the UserAgent info. I know Network Connect can run on other OSes. The UserAgent "NcWin32" makes me believe that is only the Windows versions of Network Connect. Are there different UserAgent strings for the linux/mac versions of Network Connect?

As for the Login-stdaln.thtml, I copied out customized LoginPage.thtml to LoginPage-stdaln.thtml. Maybe the original creator of the custom template broke something on the page that we need. I'll recreate it wth the version from sample.zip

[ruc_]

For my Snow Leopard (MAC OS 10.6) a policy using the string *Network Connect*  worked ok. I don't have the string for Linux handy. However its real easy to find the user agent string:

1. Start tcp dump (Under troubleshooting) on the interface where end user will login

2. Use the client machine whose user agent string you want to find out and login.

3. Stop the tcp dump and view it as 'ssl dump'

4. Search for the string "User-Agent:" (you might see your admin session's browser user-agent string as well so make sure you don't mix this with the user's user-agent string)