Juniper Archives - Rebootuser

Using Juniper SA as a Reverse Proxy for ActiveSync

Posted on February 19, 2011 by owen Posted in Juniper, Security 2 Comments

This is a basic walk-through to show a Juniper SA device can be used to reverse proxy ActiveSync traffic.

Test lab setup:

Exchange 2010 DAG consisting of x2 Exchange Servers running the client access role
Juniper SA Device running 7.0R2
ActiveSync capable device – in this case I’ve used an Apple iPhone running IOS 4.2

To successfully complete this you’ll have to have the basics already setup. This includes the following:

A SA with the basic networking setup of internal, external and/or VIP(s)
A certificate assigned to the SA on the internal and/or external interfaces
An existing or new role to link with the new sign in policy that will be created
ActiveSync enabled on the Exchange Server and for the user in question

1. On the SA navigate to Authentication > Signing in > Sign-in Policies and select ‘New URL’

2. Change the user type selection to ‘Authorisation Only Access’

3. Enter a hostname – You’ll probably want to enter a ‘mobile specific’ domain i.e. mobile.mydomain.com so traffic is split from the usual user activity and can be easily monitored/restricted

4. Enter the URL of the Exchange Server (or CAS array) in the form of https://exchange.mydomain.local:443/* or https://192.168.0.1:443/* depending on if you have DNS/hostname resolution setup on your SA

5. Select ‘No Authorisation’ from the drop-down box

6. Choose a relevant Role Option from the selection given – it’s probably best to create a role specific to ActiveSync

The below has been taken from Junipers website to describe the role settings that affect an Authorisation Only Policy:

Allow browsing un-trusted SSL (Users > User Roles > RoleName > Web > Options )
HTTP connection timeout (Users > User Roles > RoleName > Web > Options)
Source IP restrictions (Users > User Roles > RoleName > General > Restrictions)
Browser restrictions (Users > User Roles > RoleName > General > Restrictions)

7. Select the ‘Allow ActiveSync Traffic Only’ check box as this will perform a very basic check of the HTTP header to make sure it matches with that of ActiveSync traffic.

Before setting up your mobile device it is worth mentioning, as it can be easily overlooked, that you’ll need to alter your firewall settings accordingly to account for these changes.

Once the above steps have been performed and the URL is reachable, i.e. the domain becomes live and resolves to the correct IP, you can begin the setup of the ActiveSync client. As stated above, this example uses an iPhone running IOS 4.2.

1. Open Settings > Mail, Contacts, Calendars > Add Account > Microsoft Exchange

2. Enter the email address, domain, username & password for the account and a description if you wish to do so

3. Select Next

4. Enter the URL previously created in step 4 above

5. The account will be created on the device – this may take some time if on the mobile network. Once the account is created you can go back into settings and select which items you wish to sync, i.e. mail, contacts and calendars. Also make sure (this is the default) that SSL is enabled.

Well that’s all there is to it really. I’ll be delving into deploying authentication via client certification using ActiveSync in a blog post shortly, one to look out for!

Setting up Juniper SA to authenticate with Active Directory

Posted on December 14, 2010 by owen Posted in Juniper 9 Comments

Integrating Active Directory authentication with a Juniper SA device will allow users to use their AD credentials when signing onto a realm, therefore aiding in the creation of a single sign-on environment.

This is simple to implement on the SA device, although most of the extra configuration work that’s required will have to be performed on the firewalls. Firewall configuration is out of scope for this entry.

1) Select Authentication > Auth Servers > Active Directory/Windows NT > New Server to create a new server entry.

2) Enter the following details:

a. Reference name/label.

b. PDC & BDC details – these can be IP or hostnames. In the case of the later, you must be sure that the SA device has the ability to query a DNS server hosting the internal domain records.

c. Domain name – enter the domain name (local) to which the SA will be querying. This can be in the form of a NETBIOS name rather than the FQDN.

d. Admin credentials – It’s probably best to create a new domain account for the sole purpose of SA integration as this can aid in monitoring. This new account needs to be assigned to the Domain Admins group.

e. Select the appropriate authentication protocol – all can be selected, although NTLM v1 isn’t ideal from a security point of view.

3) Under the Advanced options tab it’s possible to change the container name where the system(s) will be stored (default is the Computers container). You can also alter the name of the SA device.

Once the authentication realm has been configured it’s then possible to assign this to a user realm.

1) Select or create a new user realm.

2) Select General > Servers and alter the authentication server to that of the one previously created. You’ll need to open the appropriate ports on the firewall (assuming the SA device is in a DMZ and the AD server(s) are in different zones) so that a user is able to authenticate. This obviously won’t be an issue if your AD server is in the same zone as the SA(s).

Juniper SA – Authenticating with client-side certificates

Posted on December 3, 2010 by owen Posted in Juniper, Security 1 Comment

Using Client Side Certificates as authentication

For client-side certificate authentication to occur the SA device needs to know the details of the certificate authority that issues these certificates, and to have a trust relationship. This trust relationship is in the form of the CA certificate being imported into the Juniper SA configuration.

To setup a trusted client CA:

1) On the SA device open Configuration > Certificates > Trusted Client CAs > Import CA Certificate

N.B if you have a Microsoft CA installed on your network you can easily export the CA certificate by navigating to the CA’s web interface (http://%servername%certsrv) and you’ll see the option at the bottom of the screen to download the relevant certificate.

2) Select the newly imported trusted CA (the domain name should be displayed in the list of available trusted clients) to further configure the available options, i.e. using a CRL to check for revoked certificates etc.

N.B a CRL can be added by entering the CRL distribution point of the client CA in place. Again, if this is a Microsoft CA the default CRL can be located at http://%servername%certsrvcertcrl.crl.

Under the CRL checking options heading it’s possible to alter such things as the CRL download frequency etc.

Obviously if your SA is placed in a DMZ you’ll need to open the correct ports on the firewall to/from the CA and the SA device(s).

3) Also make sure that the following options are also selected:

Trusted for client authentication
Participate in client certificate negotiation

Creating a logon policy that requires users to have a certificate

This will ensure only users with a valid and trusted certificate will be able to log onto a particular realm or role. For this example I’ll show how this policy is applied to a realm, but in reality applying the same policy to a role is a very similar procedure.

1) Open user realms > %RealmName% > Authentication Policy > Certificate

2) Select the option ‘only allow users with a client-side certificate signed by Trusted Client CAs to sign in’

3) You’ll be required to enter details of the fields and values that will be considered valid for login. For the purpose of this example I’ll create a field that will check the organisational name on the certificate and match with the expected value.

Under the Certificate field heading enter ‘o’ (without the quotes). This is the pointer for Organisational name.

Under the Expected value heading enter the name of organisation, i.e. companyA (this will need to match the organisational name of that issued on your certificate from your local CA).

I’ve used the organisation name here, but anything that’s found in the certificate i.e. first/last name, county or country can be used instead, or as well as, the field used in this example.

That’s all there is to it!

NC#2; Using Juniper Network Connect GINA for client login

Posted on October 30, 2010 by owen Posted in Juniper, Security Leave a comment

The GINA component will allow a user to log onto a company system (assuming cached credentials are enabled) by initiating a VPN connection to the network upon logon. This makes the whole process of using a VPN smoother and less prone to user error than using a client, or even webpage authentication, as the end-user is taken through the logon process step by step.

Enabling the GINA

Network Connect will need to be enabled for the realm/role that the user is logging into. I’ve recently blogged about creating a Network Connect policy; this entry can be found here.

The system used to connect to the company network must be part of the domain
The system must hold cached credentials for the user logging in
The system must have a network connection/Internet access at logon

NB. One caveat I’ve found so far is that client side certificate authentication can’t be used with the GINA.

Setup on the Juniper SA

You’ll need to make sure that the Network Connect role policy allows for using the GINA. This can be achieved by following the steps below:

1) Navigate to user roles > **role name** > network connect and tick the box ‘launch NC during windows interactive user logon’

2) Choose the preferred options in regards to how the client should start (i.e. required or optional) – if optional is selected the user will be prompted during logon to activate this feature.

3) Log off/on to the system using a domain profile that has been cached. The connection state is displayed at the top of the GINA window. Enter your credentials here.

N.B The username and password fields are automatically populated using the credentials provided on initial logon. These can be altered (and may need to be in the case of using RSA authentication with/without AD integration).

That’s all there is to it. Very simple to implement and even simpler for the end-user to operate.

NC#1; Setting up Network Connect on A Juniper SA device

Posted on October 22, 2010 by owen Posted in Juniper, Security 1 Comment

As you may have noticed from my last few blog posts I’ve been playing around with a Juniper SA device running in my home test environment. Recently I’ve written about using the WSAM or Virtual Desktop Profiles to ‘redirect’ traffic to an end-user. This posting get’s back to the good old VPN style setup by using a program called Network Connect. This is a client based SSL VPN, that is itself pretty customisable. The Juniper Admin can restrict users on a device, protocol and port basis, as well as using features such as split tunnelling (i.e. access to two or more subnets) as well as bandwidth throttling.

Setting the Network Connect Server address

1) Select network > network connect and ‘entire cluster’ (if the SA’s are in a cluster)

2) Enter the IP address to be used for the network connect server. As specified make sure that the IP address is different from the internal or external addresses already in use by the SA(s)

3) Enter an IP address filter (if required) or leave as *

Enabling Network Connect

1) Select user roles > **role name** > network connect

2) Select the split tunnelling mode preferred.

NB Although it is generally very useful for the client to have access to their local subnet this can also prove a security risk. If the client requires internet access it’s generally best to route this via the Juniper SA devices to a proxy server where the traffic will also be filtered using company policy. However, I realise that sometimes routing both corporate traffic and all other services, whether HTTP or otherwise, can prove very tasking over a slow VPN line. This is where it may be best to allow some kind of split tunnelling rule. I’ll leave it up to you to decide which is best.

3) Select auto-launch network connect

Creating a Network Connect Access list

1) Create a new access policy and give it a relevant name

2) You’ll need to enter the resources that the NC clients will have access to. The entry .*.:* will allow access to all protocols, all ports and all ips on the company network. This is generally not a good idea!

Best practise is to manually detail each service, i.e. tcp://myserver.company.local:80 will give NC users access to just HTTP on myserver. This may be continued to include HTTPS and perhaps an ICMP rule to allow for PING to check of the server availability etc. You may find that the resource list grows quite large.

3) Select the role(s) to which this access policy should apply

Defining Network Connect Clients

1) NC clients can be assigned an IP address via an internal company DHCP server or a static address pool. I personally don’t use a DHCP server due to the extra f/w configuration (and in my opinion f/w weakening) so I’d define a static pool. Here you would just enter a list of IP addresses that can be assigned to clients. Each IP address should begin on a new line.

2) Transport encryption modes can be customised to suit. Again I generally go with the highest encryption available (AES256/SHA1), but performance will be hit. A compromise could be made here, especially if users are having to operate on 3G or GPRS.

3) DNS settings can be customised as wished. If the Juniper SAs use different DNS servers or a different DNS domain you’ll need to manually supply the settings here to match those of the internal company network.

4) Set a proxy server (if required).

5) Choose the roles this NC connection profile will apply to.

Spilt-tunnelling networks

1) If you are using spilt-tunnelling networks then you’ll need to enter the resources (i.e. the IP range of the company network i.e. 192.168.2.0/255.255.255.0 etc)

2) Select the roles for which this policy will apply

3) Give the policy a meaningful name and save

Bandwidth management

1) Adjust entries to suit. These can be based on guaranteed and maximum throughput.

Method #2; Integrating VMware View with a Juniper Secure Access (SA) Appliance using Virtual Desktop Resource Profiles

Posted on October 19, 2010 by owen Posted in Juniper, Security, VMware 2 Comments

I previously blogged about using WSAM on Juniper SAs to redirect traffic to a VMware View server. As mentioned, resource profiles require less configuration than the WSAM method. They’re also very useful if your company utilises other OS platforms such as Mac OSX or a variant of Linux, or if you just want a more fluid sign on due to the SSO (single sign on) capability.

You have to be mindful that AD (or LDAP) authentication needs to be used as either a primary or secondary authentication method.

Basic configuration as per below:

1) Select resource profiles > virtual desktops > new profile and enter the following details

a. Select the type of profile required (VMware View or Citrix XenDesktop)

b. Enter a meaningful name and description (if required)

c. Enter the server name or IP along with port number i.e. myview.mynetwork.local:443

d. Tick the use SSL box (especially if using View)

e. If the Juniper realm is set to use AD as its primary authentication method you’ll need to set the username field as <USERNAME> and the password field as <PASSWORD>

If the Juniper realm is set to use AD as its secondary authentication method you’ll need to set the password as <PASSWORD@SECAUTHSERVER>

f. Enter the domain name

2) You’ll need to assign the virtual desktop profile to a role

3) Assign the profile a bookmark name

If a successful connection has been made to the View server you’ll notice that in a yellow box at the top of the page under user roles > **role name** > virtual desktop > sessions > **bookmark name**;

Retrieved Desktop list from server myview.mynetwork.local:443 successfully

If the connection was unsuccessful you’ll notice the error message below;

Warning: Unable to retrieve desktop list, please re-check the server configuration in the Profile
Error: [NOT_AUTHENTICATED] []

If you can’t get the connection working correctly from the Juniper SA to the VMware View server you can enter credentials manually for testing, as below:

1) Open resource profiles > virtual desktop > **profile name**

2) Enter the AD account username of a user that has access to the VMware View Portal

3) Select the password option and enter the AD password associated with the username previously entered

4) Enter the domain name

5) Select user roles > **role name** > virtual desktop > sessions > **bookmark name** and open the bookmark

6) Under the authentication SSO heading enter the credentials of the test user. Make sure you enter in domainusername format

7) Save changes and then open the bookmark name from (user roles > **role name** > virtual desktop > sessions > **bookmark name**) and you should see a successful connection message

This can obviously also be tested from actually logging into the Juniper device

Method #1; Integrating VMware View with a Juniper Secure Access (SA) Appliance using WSAM

Posted on October 14, 2010 by owen Posted in Juniper, Security, VMware 4 Comments

I’ve been playing around with a Juniper SA appliance at home of recent times and have found the device packed full of features. Within this entry I’ll be concentrating on WSAM policies as these allow seamless integration with VMware View (tested with VDM 2.1, View 3 and View 4).

There are two methods that can be used when assigning a VMware View profile to the Juniper SA’s. If you have a newer (or updated firmware) SA model you’ll notice that there’s an option to create a Virtual Desktop Resource Profile. I’m going to show you an alternative, but just as useful, method.

The steps below will create a WSAM policy that will basically forward RDP traffic to the virtual desktops on the backend.

1) Create a new web application (resource profile > web > custom)

a. Enter a unique name for the profile

b. Enter the URL of the View server in the Base URL field, i.e. https://myview.mynetwork.local

c. Tick Autopolicy: Web Access Control – select or enter the URL of the view server (as previously defined) and set the action to allow

d. Tick Autopolicy: Rewriting Options and select No rewriting (use WSAM)

2) Assign the web application to a role (resource profiles > *select profile* > roles)

a. Select from the available roles

3) Create a new bookmark (resource profiles > *select profile* > bookmarks)

a. Enter a unique name

b. The URL field should be populated with the View server FQDN – add /index.jsp

c. I prefer the bookmark to open in a new window and to hide the address bar – select these options if you wish to do so

4) Create a new SAM application (roles > *select role* > SAM > applications > add > custom)

a. Enter a unique name for the profile

b. Enter the filename wsnm.exe

c. Enter the path as: C:Program FilesVMwareVMware ViewClientbin

5) Create another new SAM application (roles > *select role* > SAM > applications > add > custom)

a. Enter a unique name for the profile

b. Enter the filename wswc.exe

c. Enter the path as: C:Program FilesVMwareVMware ViewClientbin

The above assumes that VMware View has been installed into the default directory (this path will need altering if using with VDM 2.x)

6) Enable Windows SAM (WSAM) (roles > *select role* > SAM > applications > options) and check the following settings:

a. Windows SAM

b. Auto-launch Secure Application manager

c. Auto-upgrade Secure Application Manager

That’s all there is to it. WSAM and JSAM can be used for many more things than just redirecting View traffic. Even if the newer ‘pre-created’ policies are a little simpler to implement, it’s always nice to have an understanding of the capabilities the Juniper SA series has to offer.