FSSO FortiGate Single Sign On

Posted on 16/05/2022 by PeteLong

FSSO KB ID 0001786

If you are applying polices with your FortiGate, e.g. Web Filtering or IPS, then the ability to track actual users rather than IP addresses is advantageous, it’s all very well blocking access to adult material or gambling sites, from the corporate network, but most companies want to know WHO is attempting to connect to what and when.

To do that the firewall needs to learn what users are where, we can make all users actively authenticate to the firewall as they attempt to get on the web, but that does not make for a great user experience, it’s better to passively learn where your users are, and what machines they are using, then we can the use that in a policy. (let’s not get to far ahead for the moment).

Q. How do we learn where your users are, and what machines they are on?

A. FSSO

To enable FSSO you need to understand the difference between two pieces of software, the FSSO Collector, and FSSO DC Agent. The DC Agent (as the name implies) run on each of your DCs, it captures login events and then does DNS lookups to see what machines people are using. The Collector takes the output from one or more DC Agents and collates it for the firewall, it does not have to run on a domain controller (but it can).

I only have one server! Well thats OK, both the collector and agent can be on the same box

However most networks will have multiple Domain Controllers, so your FSSO topology may look a little more like this.

Or if you have an even larger network, you may want to build in a backup collector(s)

Deploy FSSO

In my small test environment I’m going to put the collector and agent on a single DC. Your first challenge is actually getting the FSSO software. Log into your FortiCloud portal and proceed as if you want to download some FortiGate firmware.

Then in the version of FortiGate firmware that matches your firewall you will find an FSSO directory, (unless your’e in the dark ages your domain controllers will be x64 bit) so in my case I want FSSO_Setup5.0.0306_x64.exe (that will download the collector setup, that also includes the DC Agent software as well, which you can also download separately if you wish).

Install Collector

Accept the EULA, change the install directory if you don’t want it on the C: Drive > Enter some administrative credentials > Next.

My FortiGate has LDAPS Lookups so I’m going for Advanced > Next.

Install > When complete, Im installing the DC Agent on the same server so MAKE SURE ‘Launch DC Agent Install Wizard” IS ticked, and click finish.

Warning: Installing a DC Agent will result in the reboot of this DC, (you might want to do the next step out of hours).

Install DC Agent

Accept the defaults > Next > Select the Domain > Next > Select any user(s) you want to be exempt > Next.

Select DC Agent Mode > Next > It will prompt for a reboot, let it do so.

Post reboot launch FortiGate Single Sign On Agent Configuration > And change the password to something memorable, (you will need to enter this onto the FortiGate in a minute).

Register FSSO on FortiGate

Back on the Fortigate > Security Fabric EXTERNAL Connectors > FSSO Agent on Windows AD.

Give it a sensible name > Enter the IP address and the password you set above > Apply and Refresh > OK.

You will know it’s working because it will give you a free up arrow (it can take a little while, be patient).

Create FSSO Groups

Now you can add GROUPs based on FSSO learned groups, like so.

Once you have the FSSO groups defined, you can use them in policies. Below I’ve added Domain Users to my default outbound policy.

WARNING: If you have any devices, or assets that need access out you will need to add a new rule to alow them out explicitly before this rule, or their internet access will suddenly stop.

Monitor FSSO Events

To make sure the system is working you can go to Events > User Events > Make sure your user logon activity is getting logged.

Cisco ASA Static (One to One) NAT Translation

Posted on 17/01/2020 by Migrated

KB ID 0000691

Problem

Note: This is for Cisco ASA 5500, 5500-x, and Cisco Firepower devices running ASA Code.

If you have a spare/available public IP address you can statically map that IP address to one of your network hosts, (i.e. for a mail server, or a web server, that needs public access).

This is commonly referred to as a ‘Static NAT’, or a ‘One to One translation’. Where all traffic destined for public address A, is sent to private address X.

Note: This solution is for firewalls running versions above version 8.3. If you are unsure what version you are running use the following article.

Find out your Cisco ASA version (Operating system and ASDM)

If you only have one public IP address you would need to carry out port forwarding instead.

Cisco ASA 5500 (and PIX) Port Forwarding

Solution

In the following example I will statically NAT a public IP address of 81.81.81.82 to a private IP address behind the ASA of 172.16.254.1. Finally I will allow traffic to it, (in this example I will allow TCP Port 80 HTTP/WWW traffic as if this is a web server).

Create a Static NAT and allow web traffic via ASDM

Note for the command line alternative see below.

1. Connect to the ADSM.

2. Configuration > Firewall > NAT Rules > Add > Add “Network Object” NAT Rule.

3. Give the ‘object’ a name (I usually prefix them with obj-{name}) > It’s a Host > Type in it’s PRIVATE IP address > Tick the NAT section (press the drop-down if its hidden) > Static > Enter it’s PUBLIC IP address > Advanced > Source = Inside > Destination > Outside > Protocol TCP. Note: You could set this to IP, but I’m going to allow HTTP with an ACL in a minute, so leave it on TCP > OK > OK > Apply.

4. Now navigate to Firewall > Access Rule > Add > Add Access Rule.

5. Interface = outside > Permit > Source = any > Destination = PRIVATE IP of the host > Service > Press the ‘more’ button > Locate TCP/HTTP > OK > OK > Apply.

6. Then save your work with a File > Save Running Configuration to Flash.

Create a Static NAT and allow web traffic via Command Line

1. Connect to the ASA via Command Line.

2. Log In > Go to enable mode > Go to configure terminal mode.

[box]

User Access Verification

Password:*******
 
Type help or '?' for a list of available commands.
 PetesASA> enable
 Password: *******
 PetesASA# conf t
 PetesASA(config)

[/box]

3. First I’m going to allow the traffic to the host (Note: after version 8.3 we allow traffic to the private (per-translated IP address). This assumes you don’t have an inbound access list if you are unsure execute a “show run access-group” and if you have one applied substitute that name for the word ‘inbound’.

Warning before carrying out applying the ‘access-group’ command, see the following article;

Cisco ASA – ‘access-group’ Warning

[box]

PetesASA(config)# access-list inbound permit tcp any host 172.16.254.1
PetesASA(config)# access-group inbound in interface outside[/box]

4. Then to create the static translation.

[box]

PetesASA(config)# object network obj-172.16.254.1 
PetesASA(config-network-object)# host 172.16.254.1 
PetesASA(config-network-object)# nat (inside,outside) static 81.81.81.82 
PetesASA(config-network-object)# exit 
PetesASA(config)#

[/box]

5. Then save the changes.

[box]

PetesASA(config)# wr mem 

Building configuration... 
Cryptochecksum: 89faae4b 7480baa4 bf634e87 470d2d30 
6224 bytes copied in 1.10 secs (6224 bytes/sec) 
[OK]

[/box]

Static NAT Commands to Copy & Paste

[box]

access-list inbound permit tcp any host 172.16.254.1
access-group inbound in interface outside
object network obj-172.16.254.1
 host 172.16.254.1
 nat (inside,outside) static 81.81.81.82

[/box]

Note: Check and change the values in bold as appropriate

Cisco ASA – Port Forward a ‘Range of Ports’

Posted on 06/01/2020 by PeteLong

KB ID 0001111

Note: This is for Cisco ASA 5500, 5500-x, and Cisco Firepower devices running ASA Code.

This comes up on forums a lot, some applications and most phone systems require a ‘LOT’ of ports to be open. Normally thats fine you just give the internal IP a static public IP and open the ports. But what if you don’t have a spare public IP? I’ve already covered port forwarding before.

Cisco PIX / ASA Port Forwarding

Until version 8.4 you couldn’t even do this, you needed to create a translation for each port! Note: There is a bug in versions 9.0 and 9.1 that can stop this working, so check your OS with a ‘Show Ver’ command to be sure.

As I said this come up a lot on forums so when it asked on EE the other day, I fired up GNS3 and works out how to do it. Here is my topology;

So I will setup ‘port forwarding’ from the outside interface of ASA-1 for TCP ports 1000 to 2000 to then Internal Server (10.2.2.10).

1. Setup object groups for your internal server and for the range of ports you are going to forward.

[box]

!
object network Obj-Internal-Server
 host 10.2.2.10
!
object service Obj-Ports-Range
 service tcp destination range 1000 2000
!

[/box]

2. Then allow the traffic in with an ACL See MY WARNING before doing this.

[box]

!
access-list inbound extended permit tcp any host 10.2.2.10 range 1000 2000
!
access-group inbound in interface outside
!

[/box]

3. Perform the PAT translation from the outside interface to the internal server.

[box]

!
nat (outside,inside) source static any any destination static interface Obj-Internal-Server service Obj-Ports-Range Obj-Ports-Range
!

[/box]

Note: A lot of people ask to ‘port forward’ a range of ports when they actually mean ‘I would like to open a range of ports to an internal IP address’. Thats essentially just a one-to-one static NAT. I’ve already covered that before, but in our example i use a spare public ip 192.168.253.100.

[box]

!
object network Obj-External-Server
 host 192.168.253.100
!
object network Obj-Internal-Server
 host 10.2.2.10
 nat (inside,outside) static Obj-External-Server
!
access-list inbound permit tcp any host 10.2.2.10 range 1000 2000
!
access-group inbound in interface outside

[/box]

VMware Unified Access Gateway: Horizon Deployment

Posted on 09/10/2019 by PeteLong

KB ID 0001605

Problem

With older versions of Horizon View, we simply deployed another Connection server and called it a Security Server. The drawback of that is, it requires another Windows licence. You can now deploy VMware UAG (Unified Access Gateway), try to think of it as a ‘Netscaler for VMware’, and like other VMware solutions it’s a small appliance built on VMware’s ‘Photon’ Linux.

Below is a typical deployment and shows you the ports you will be required to open on your firewall to make this work;

You can deploy multiple UAGs and have them behind a load balancer, or point individual UAGs to separate Horizon Connection servers. Her I’m simply deploying one internal Horizon Connection Server, and one VMware UAG in my DMZ.

Step 1: Deploy the UAG Appliance

I’ve covered deploying OVA files before, but essentially download the OVA, and within your vSphere client select deploy OVF template. Navigate to, and select the OVA file you have downloaded from VMware > Next.

Select your Datacenter and optionally folder > Next.

Pick where you want to deploy the appliance (Cluster etc.) > Next.

Review your settings > Next.

I’m deploying into a DMZ so there will be no shortcutting the firewall! > Single NIC > Next.

Select the storage you want to deploy the appliance to > Next.

Confusingly, (as we have picked single NIC?) set them all to the correct port group > Next.

Specify the IP address > Scroll down.

Complete the DNS and IP settings > Give the appliance a name > scroll down.

Untick CEIP > Set the admin, (needed for the web front end), and root (needed for console login) passwords.

Select the edition to deploy (based on your licence) > Next.

Review the settings > Finish.

Step 2: UAG Pre Configuration Tasks

To allow users to access Horizon machines externally, you need to ensure you have granted Remote Access Rights in Horizon Administrator, Note: This is in addition to any Entitlements you have already setup for the machine pools.

Take a copy of the Thumbprint, from the Horizon Connection Server you will be pointing the UAG at, keep it handy you will need it in a minute.

Optionally

If your UAGs are going into a DMZ there’s a chance that they wont be able to resolve internal domain names, (you can specify internal IP addresses of course). I prefer to enter the names/FQDNs of my connections servers, in the appliances hosts file, so it can be resolved. Log into the console as root;

[box]

vi /etc/hosts

[/box]

If you’re unsure how to use vi, (i.e you don’t wear sandals, or have a ginger pony tail.) Press I (insert) make your changes > Press Esc > Type :wq {Enter}.

Step 3: Configure UAG for Horizon

Connect to the UAG with a web browser (https{ip-address}:9443) > Login with the admin account > ‘Configure Manually’.

Optional: Add Certificate

If you have a publicly signed certificate, the easiest way to import it is with a PFX file and a password, (use the search box above, I’ve covered creating PFX files many times). You need to go to Advanced Settings > TLS Server Certificate Settings > Select admin and internet interfaces, (as required) > Browse to the PFX file and enter the password you set, (for the pfx file!) > Save.

General Settings > Edge Service Settings > SHOW > Horizon Settings > Enable Horizon > Save.

Enter the URL of the internal connection Server, and the Thumbprint you took note of, (above) > Enable PCOIP.

Set the external PCIOP URL to the external IP of the UAG, (or load balancer if using one) and add :4172 to the end, Enable Blast > Set the public URL of the UAG, (or load balancer if using one) and add :443 to the end. Enable Tunnel, and set the same URL again with :443 on the end. If you want to, open the ‘more options’ section and take a look at the optional settings, though I’m leaving everything else on the default settings > Save.

Have a cup of coffee, refresh the page a few times > Log off and back on again, and hopefully all the options should ‘go green‘. If not, check the firewall ports, and make sure the UAG can resolve the name of the connection server.

Over in Horizon Administrator > Select each internal connection server and remove ‘Secure Tunnel‘, PCOIP Secure Gateway, and select ‘Do not use Blast Secure Gateway‘ > OK.

You can register the UAGs, in the Gateway section, but you wont see anything change until they have been used ‘in anger’.

You can now test externally by trying to connect with a Horizon Client.

vCenter – Management Ports

Posted on 03/07/2017 by PeteLong

KB ID 0001324

Problem

A while ago my colleague was struggling to get into a vCenter server. Normal https (TCP 443) wasn’t letting him in, I knew you could manage the appliance directly, (but I couldn’t remember the port number!) He knew there was an alternate port number, but we didn’t know what it was.

Solution

vCenter Appliance (Direct) Management Port

TCP: 5480

i.e. https://{ip-or-host-name}:5480

vCenter / vSphere Management Port

TCP: 443

i.e. https://{ip-or-host-name}

vCenter / vSphere Alternative Management Port

TCP: 9443

i.e. https://{ip-or-host-name}:9443

Note: You can also connect to the PSC, (Platform Services Controller) If you installed this role on the same appliance. The URL for that is https://{ip-or-host-name}/psc

Cisco ASA – Allowing Microsoft Activation

Posted on 15/09/2016 by PeteLong

KB ID 0001237

Problem

Activation occurs over TCP 80 and 443, so usually this will not trip you up. However if you are on a site with a very restrictive firewall config, then you might want to add the following.

Solution

I’ll break with the norm, and just post the config in its entirety, (just remove the comments in red.)

[box]

!The Firewall needs a domain name of its own.
!
domain-name petenetlive.com
!
!Setup DNS Lookups so the firewall can resolve the FQDNs we are going to use.
!
dns domain-lookup outside
dns server-group DefaultDNS
 name-server 8.8.8.8
 name-server 8.8.4.4
!
!Create objects for each of the activation FQDN's.
!
object network Obj-go.microsoft.com
  fqdn go.microsoft.com
object network Obj-wpa.one.microsoft.com
  fqdn wpa.one.microsoft.com
object network Obj-crl.microsoft.com
  fqdn crl.microsoft.com
object network Obj-wwwtk2test1.microsoft.com
  fqdn wwwtk2test1.microsoft.com
object network Obj-wwwtk2test2.microsoft.com
  fqdn wwwtk2test2.microsoft.com
object network Obj-db3.sls.microsoft.com
  fqdn db3.sls.microsoft.com
!
!Create objects for each of the activation subnets.
!
object network Obj-MS-Activation-Subnet-1
 subnet 64.4.0.0 255.255.192.0
object network Obj-MS-Activation-Subnet-2
 subnet 65.52.0.0 255.252.0.0
!
!Create an object group that holds all the objects.
!
object-group network Obj-GP-MS-Activation
 network-object object Obj-go.microsoft.com
 network-object object Obj-wpa.one.microsoft.com
 network-object object Obj-crl.microsoft.com
 network-object object Obj-wwwtk2test1.microsoft.com
 network-object object Obj-wwwtk2test2.microsoft.com
 network-object object Obj-db3.sls.microsoft.com
 network-object object Obj-MS-Activation-Subnet-1
 network-object object Obj-MS-Activation-Subnet-2
!
!Create a service object for the activation ports.
!
object-group service Obj-SVC-MS-Activation tcp
 port-object eq www
 port-object eq https
!
!Allow the traffic Out (SEE THE WARNING BELOW!)
!
access-list outbound extended permit tcp any object-group Obj-GP-Microsoft-Activation object-group Obj-SVC-MS-Activation

[/box]

Warning: Before Executing the access-list command, make sure the ACL name matches your existing ACL. In the example above I’ve used outbound, See the following article for clarification;

Cisco ASA – ‘access-group’ Warning

Publishing Remote Desktop Services With Web Application Gateway

Posted on 23/01/2016 by PeteLong

KB ID 0001143

Problem

Getting this article to completion has been a bit of a journey! This is the final post that will stitch together all the others I’ve posted over the last couple of weeks, that will enable you to publish your RemoteApps with ‘Remote Desktop Web Access’, and have that service presented securely from your DMZ. I’ll be using Active Directory Federation Services, (you don’t have to, but it’s more secure than simply using ‘pass-though’ security).

Solution

Prerequisites

Topology: Simply getting your ‘ducks in a row’ will take a lot longer than actually deploying the service. Here is the topology that I’m going to deploy;

Firewall Rules: You will see I’ve labelled all the Certificate/CRL rules as optional, this is because you would only need them if you were using self signed certificates. In this example that’s what I am doing, this means that all my remote clients need the root certificate installing on them, so for production I suggest you purchase a publicly signed wildcard certificate for simplicity.

DNS Requirements: For your internal domain and the DMZ it’s simple enough but your external clients will need to be able to resolve your public URL (and the URL of your CRL is used).

Certificate Services (Optional): If you want to deploy self signed wildcard certificates you will need a PKI environment and a published CRL. See the following article;

Windows Certificate Services – Setting up a CRL

Once setup you will need to generate a self signed wildcard certificate. See the following article;

Certificate Services – Create a ‘Wildcard Certificate’

Active Directory Directory Services: You need to have your ADFS farm deployed and ready to add your relying trust to. See the following article;

Deploy Active Directory Federation Services

Web Application Proxy: The Role needs installing ready to have the publishing rule added for Remote Desktop Web Access. See the following article;

Deploying Windows ‘Web Application Proxy’

MAKE SURE: You have ran Windows updates on the WAP server, there are a number of bugs that have been fixed, ensure you have at least KB2975719, and in addition you need to have KB2983037 Hotfix installed.

Step 1: Add A Relying Trust To Active Directory Federation Services For Web Application Proxy

On your ADFS Server > Administrative Tools > AD FS Management > AD FS > Trust Relationships > Relying Party Trusts > Add Relying Party Trust.

Next.

Enter data about relying party trust manually > Next.

Give the trust a name > Next.

AD FS Profile > Next.

Next.

As an identifier, add in the UEL to access Remote Desktop Web Access > Next.

I do not want to configure multi-factor authentication settings for this relying party trust at this time > Next.

Permit all users to use this relying party > Next.

Next.

Untick “Open Edit Claim Rules dialog for this relying party trust when the wizard closes’ > Close.

You should see your relying part trust listed, take note of its name.

Step 2: Configure Web Application Proxy To Publish Remote Desktop Web Access

On the WAP Server > Administrative Tools > Remote Access Management > Select the Server > Publish.

Next.

Select ‘Active Directory Federation Services (AD FS) > Next.

Note: As mentioned above, you can choose ‘pass-through’, then author authentication is done on the internal RD Web Access server (which is less secure).

Select the relying trust you created above > Next. (If it’s not there check https is open, and you can resolve the AD FS service name) > Next.

Give the publishing rule a name, and enter the URL the service will be published on, (this is usually the same inside and outside but does not have to be) > Select your wildcard certificate > Next.

Publish.

In PowerShell execute the following command;

[box]

Get-WebApplicationProxyApplication -Name “SmoggyNinja Remote Desktop Web Access” | Set-WebApplicationProxyApplication -DisableHttp

[/box]

Then the following command;

[box]

Get-WebApplicationProxyApplication -Name “SmoggyNinja Remote Desktop Web Access” | Set-WebApplicationProxyApplication -DisableTranslateUrlInRequestHeaders:$true
[/box]

Note: You only actually need this command if you’re using different URLs but let’s stick with a script that works.

Step 3: Additional Works.

On the Remote Desktop Session Host Server run the following commands;

[box]

Import-Module Remote Desktop

Set-RDSessionCollectionConfiguration -CollectionName SN-RDS-COLLECTION -CustomRdpProperty “pre-authentication server address:s:https://remote.smoggyninja.com`nrequire pre-authentication:i:1″

[/box]

RSA SecurID Error – ‘106: The Web server is busy. Please try again later’

Posted on 17/11/2015 by Migrated

KB ID 0000975

Problem

Not the most descriptive of errors! In fact this has got nothing to do with the busyness of the web server at all.

Solution

What’s actually happening is the RSA agent on this machine (in this case a web server) cannot communicate with the RSA Authentication Manager. In my case the web server was in a DMZ, and the RSA Authentication Manager Appliance was in another DMZ. The ports required (TCP 5500, UDP 5500, and TCP 5580). were not open from the agent to the appliance. Once I fixed that, we were up and running.

Access a Windows Share Through a Firewall

Posted on 17/11/2015 by Migrated

KB ID 0001061

Problem

I needed to access a folder on a server in a clients DMZ the other week, and the thought struck me ‘I have no idea what ports I need to open to accomplish this?’

Solution

Bear in ming I’m just talking about the ports that need to be open, you will still need to authenticate to the remote machine with a user-name and password (unless you have the share wide open which I would not advise).

The Ports that need to open FROM the machine you are connecting with TO the machine you are connecting to are;

TCP Port 139 NetBIOS SSN NetBIOS Session Service.
TCP Port 445 Microsoft DS Directory Share
UDP Port 137 NetBIOS Name Service
TCP Port 138 NetBIOS Datagram Service

Windows Server 2008 R2 – Configure RADIUS for Cisco ASA 5500 Authentication

Posted on 17/11/2015 by Migrated

KB ID 0000688

Problem

Last week I was configuring some 2008 R2 RADIUS authentication, for authenticating remote VPN clients to a Cisco ASA Firewall.

I will say that Kerberos Authentication is a LOT easier to configure, so you might want to check that first.

Solution

Step 1 Configure the ASA for AAA RADIUS Authentication

1. Connect to your ASDM, > Configuration > Remote Access VPN. > AAA Local Users > AAA Server Groups.

2. In the Server group section > Add.

3. Give the group a name and accept the defaults > OK.

4. Now (with the group selected) > In the bottom (Server) section > Add.

5. Specify the IP address, and a shared secret that the ASA will use with the 2008 R2 Server performing RADIUS > OK.

6. Apply.

Configure AAA RADIUS from command line;

[box]

aaa-server PNL-RADIUS protocol radius
aaa-server PNL-RADIUS (inside) host 172.16.254.223
  key 123456
  radius-common-pw 123456
  exit

[/box]

Step 2 Configure Windows 2012 Server to allow RADIUS

7. On the Windows 2008 Server > Launch Server Manager > Roles > Add Role.

8. If you get a welcome page > Next > Select Network Policy and Access Server > Next >Next.

9. Select ‘Network Policy Server’ > Next > Install.

10. Close, when complete.

11. Whilst still in Server Manager > Network Policy and Access Server > NPS (Local).

12. Register Server in Active Directory >OK > OK.

13. Expand RADIUS Clients and Servers > Right click RADIUS Clients > New.

14. Give the firewall a friendly name, (take note of what this is, you will need it again) > Specify its IP > Enter the shared secret you setup above (number 5) > OK.

15. Expand policies > right click ‘Connection Request Policies’ > New > Give the policy a name > Next.

16. Add a condition > Set the condition to ‘Client Friendly Name’ > Add.

17. Specify the name you set up above (number 14) > OK > Next > Next > Next.

18. Change the attribute to User-Name > Next > Finish.

19. Now right click ‘Network Policies’ > New > Give the policy a name> Next.

20. Add a condition > User Groups > Add.

21. Add in the AD security group you want to allow access to > OK > Next > Next.

22. Select ‘Unencrypted Authentication PAP SPAP” > Next > No > Next > Next > Finish.

Step 3 Test RADIUS Authentication

23. Back at the ASDM, in the same page you were in previously, select your server and then click ‘Test’.

24. Change the selection to Authentication > Enter your domain credentials > OK.

25. You are looking for a successful outcome.

Note: if it fails check there is physical connectivity between the two devices, the shared secrets match. Also ensure UDP ports 1645 and 1646 are not being blocked.

To Test AAA RADIUS Authentication from Command Line

[box]

test aaa-server authentication PNL-RADIUS host 172.16.254.223 username petelong password password123

[/box]

26. Finally, save the firewall changes > File > Save running configuration to flash.

Deploy FSSO

Install Collector

Install DC Agent

Register FSSO on FortiGate

Create FSSO Groups

Monitor FSSO Events

Related Articles, References, Credits, or External Links

Problem

Solution

Create a Static NAT and allow web traffic via ASDM

Create a Static NAT and allow web traffic via Command Line

Static NAT Commands to Copy & Paste

Related Articles, References, Credits, or External Links

Problem

Step 1: Deploy the UAG Appliance

Step 2: UAG Pre Configuration Tasks

Optionally

Step 3: Configure UAG for Horizon

Optional: Add Certificate

Related Articles, References, Credits, or External Links

Problem

Solution

vCenter Appliance (Direct) Management Port

vCenter / vSphere Management Port

vCenter / vSphere Alternative Management Port

Related Articles, References, Credits, or External Links

Problem

Solution

Related Articles, References, Credits, or External Links

Problem

Solution

Step 1: Add A Relying Trust To Active Directory Federation Services For Web Application Proxy

Step 2: Configure Web Application Proxy To Publish Remote Desktop Web Access

Step 3: Additional Works.

Related Articles, References, Credits, or External Links

Problem

Solution

Related Articles, References, Credits, or External Links

Problem

Solution

Related Articles, References, Credits, or External Links

Problem

Solution

Step 1 Configure the ASA for AAA RADIUS Authentication

Step 2 Configure Windows 2012 Server to allow RADIUS

Step 3 Test RADIUS Authentication

To Test AAA RADIUS Authentication from Command Line

Related Articles, References, Credits, or External Links