I was assisting a colleague to setup some AnyConnect for a client this afternoon, when all of a sudden I was met with this;
VPN
Logon denied, unauthorised connection mechanism, contact your administrator
Solution
This was a confusing one, I replicated the problem on my own test firewall. All I had done was change the AAA method from LOCAL to LDAP? It took me a while to figure out what was going on?
The reason why this is happening is because the GROUP POLICY your AnyConnect PROFILE is using does not have SSL enabled. (This makes no sense as it was working with LOCAL authentication, but this is how I fixed it).
You will be either using a specific group policy or the DfltGrpPolicy
[box]
IF USING THE DEFAULT GROUP POLICY
Petes-ASA(config)# group-policy DfltGrpPolicy attributes
Petes-ASA(config-group-policy)# vpn-tunnel-protocol ssl-client ssl-clientless
IF USING A SPECIFIC GROUP POLICY (Remember to include any, that already exist! e.g. l2tp-ipsec)
Petes-ASA(config)# group-policy PNL-GP-ANYCONNECT-ACCESS attributes
Petes-ASA(config-group-policy)# vpn-tunnel-protocol ssl-client ssl-clientless l2tp-ipsec
Both SSL and TLS are cryptographic protocols designed to secure communications over a network (remember the internet is just a network). Originally we had SSL version 1 and version 2. But they were, (to be honest) ‘a bit bobbins’ and full of security holes, so never really took off. Version 3 however did and was widely supported. The problem with version 3 was, (again) that was also ‘bobbins’. All this came to a head with the Poodle exploit and people started getting rid of SSLv3.
So, what about TLS? Well TLS v1.0 was largely based on, (but not compatible with) SSLv3. TLS 1.1 replaced v1.0 (circa 2006). Problems with it prompted TLS 1.2 (circa 2008). Then that was the standard until TLS v1.3 (circa 2018).
However: Just because you use the newest protocols does not necessarily mean you are more secure: Most documentation you read says TLS 1.2 ‘Should’ be secure (that’s reassuring eh!) This is because these protocols are built on cryptographic ciphers and they are only as secure as those ciphers. You can corrupt a strong protocol with a weak cipher and render it less secure. In some cases, you may need to do this, or you might simply enable a web cipher to fix a ‘problem’ without understanding the consequences.
You are ‘Probably’ Reading this Because…
If you’ve had a security audit, or a company had scanned your network and produced a report that says you are running insecure protocols and you need to do something about it.
THINK: Security is a good thing, (I’m all for it,) BUT just rushing to turn things off, can cause you problems, where possible test any remediation in a test environment, many old legacy (for legacy read ‘applications that are business critical, and you can no longer update or get support on’) may still be using these old protocols. Simply disabling SSLv3.0, TLS v1.0,1.1, and/or 1.2 can have some negative effects, either on YOUR applications or in the browsers of your clients. Remember if you provide a web based service it will also need testing with any browser that your staff, or even the public may be using to access your web based platforms.
TLS 1.0 and TLS 1.1 might be ‘depreciated’ but it’s still widely used, disabling them will probably cause you more problems than the older SSL protocols, so test, test, and test.
ISOLATE: If you have old legacy applications and you need to retain them for compliance or financial reasons, then consider simply MITIGATING the risk by taking them off the local network, and running them in isolation.
DOCUMENT: If you need TLS 1.1 then that’s fine just because a scan picked it up, does not mean that you HAVE TO run to the server room and disable it. Most compliance standards are fine with you not fixing something, providing you document what it is and why it’s still enabled.
Windows TLS 1.2 Support: Clients from Windows Vista, and Servers from Server 2008 support TLS 1.2. but all the way to Windows 8.1 and Server 2012 R2 it requires an update, so make sure you are fully up to date before attempting to use TLS 1.2.
Exchange: Support for TLS 1.1 and 1.2 wasn’t added until Exchange 2013 (CU8) and Exchange 2010 (SP3 RU9). Beware Some (Older) Microsoft Outlook clients will only work with TLS 1.0
Windows Client (Internet Explorer) Disabling SSL3 and TLS 1.0, TLS 1.1
Before disabling protocols on the server, it’s good practice to disable those protocols on the clients, some time beforehand, the easiest way to do this is via Group Policy.
Windows Server Disabling SSL3 and TLS 1.0, TLS 1.1
With the impending ‘turning off’ of cleartext LDAP queries to Windows Server, I wanted to make sure my new Duo deployments were already using LDAPS. I got LDAP deployed very quickly and easily, but making the ‘swap’ to LDAPS proved to be massively problematic.
Normally I find Duo a pleasure to deploy, but their technical documentation just confused me for this and I went running up some blind alleys, and eventually ended up logging a call to Duo to try to get it working. So to save you this pain, read on.
Solution
Firstly your domain controller(s) need to be setup to accept LDAPS queries, SORT THAT OUT FIRST. I’ve covered that in the following post;
In the following section I’ll assume you have LDAP already setup on your Duo ADSync, if this is a new deployment, and you are going straight to LDAPS, then you can ignore this next section.
Duo Existing LDAP AD Sync
It goes without saying, (but I’ll say it anyway,) your ADSync should already be connected, if you’re switching room LDAP!
So your domain controller(s) will be using TCP port 389.
Your transport type will be set to ‘Clear’.
Duo Deploy LDAPS for ADSync
The first thing that held me up was reading the Duo documentation, and wondering what I needed to add to my authproxy.cfg file! The truth is;
YOU DON T NEED TO ADD ANYTHING TO AUTHPROXY.CFG!!
Here’s a copy of mine for reference, you ONLY need the sections highlighted, the additional section on mine was for my Cisco ASA RADIUS client;
Rights and Permissions for Duo Service Account
Note: By default the Duo service on your Duo Auth Proxy server will be running under the LOCAL SYSTEM ACCOUNT. I had problems using this account, so I used the service account specified in the authproxy.cfg file. But there are some rights you need to assign to the account first. On the Auth Proxy server, run secpol.msc > Security Settings > Local Policies > User Rights Assignment > Log on as a service > Add User or Group > Add in your Duo service account.
All domain users should have the following right, but let’s take a ‘belt and braces’ approach! On a domain controller open ‘Active Directory Users and Computers’ > Right click your domain > Properties > Security > Advanced.
Add in the Duo service account, and grant;
List contents
Read all properties
Read properties
Note: They will probably, already be selected.
Finally: Add the Duo service account to the LOCAL ADMINISTRATORS group on the Duo Auth Proxy server, (Server Manager > Tools > Computer Management).
You can now open the services console and change the account the service runs under, to the Duo Service account, (Windows Key + R > services.msc > OK > Locate ‘Duo Authentication Proxy Service’ > Properties > Log On > Change the account to your service account and enter the password.) Then RESTART THE SERVICE.
Change Duo ADSync to LDAPS
To do this you are going to need a copy of your Root CA certificate (in PEM format). If you have Microsoft Certificate services make sure you get a copy of the Root CA cert in Base 64 format, (if you don’t, when you open the Certificate with Notepad, it will link like gobbledegook!)
Open your Cert with a text editor, and it should look a bit like this, copy that, (with no additional spaces on the end!) To the clipboard, you will need to paste it into the Duo Admin Panel in a minute.
In the Duo Amin Portal > Users > Directory Sync > Active Directory > ADSync > Change the port on your Domain controllers to 636 (That’s LDAPS TCP Port 636, so it needs to be open on any firewalls between the Duo Auth Proxy, and the domain controllers!)
Go to Transport Type > Change to LDAPS > Paste in your CA Certs PEM information into the ‘SSL CA Certs’ Section > Save Directory.
Why didn’t you tick ‘SSL Verify Hostname’? Simply because it fails when I do that, I’m assuming the common name on the LDAPS cert on my domain controllers is the hostname of the DC, and not its FQDN, so I needed to leave this unticked.
All being well it should say connected.
Troubleshooting Duo LDAPS
Duo have a tool that will check your domain controller certificates are OK. It’s called acert.exe or you can enable debugging,or use the connectivity tool.
Related Articles, References, Credits, or External Links
Note: This is for Cisco ASA 5500, 5500-x, and Cisco Firepower devices running ASA Code.
Below is a walk through for setting up a client to gateway VPN Tunnel using a Cisco Firepower ASA appliance. This was done via the ASDM console. The video was shot with ASA version 9.13(1) and ASDM 7.13(1).
Suggestion: If you are setting this up for the first time, I would suggest setting it up to use the ASA’s LOCAL database for usernames and passwords, (as shown in the video). Then once you have it working, you can change the authentication (AAA) to your preferred method (see links at bottom of page).
The original article was written with ASA version 8.0(4) and ASDM 6.1(3), which was a little more difficult so I will leave that procedure at the end just in case 🙂
Note: The ASDM cannot be used on the normal port (https) on the outside interface when using AnyConnect, because HTTPS or TCP port 443 needs to be free (and also IMPORTANTLYNOT ‘port-forwarded’ to a web server / Exchange server etc. for this to work). To fix that, either change the port that AnyConnect is using (not the best solution!) Or, (a much better solution) Change the port ASDM is using.
Solution
Setup AnyConnect From ASDM (Local Authentication)
In case you don’t want to watch a video! Launch the ASDM > Wizards > VPN Wizards > AnyConnect VPN Wizard > Next.
Give the AnyConnect profile a name i.e PF-ANYCONNECT, (I capitalise any config that I enter, so it stands out when I’m looking at the firewall configuration). >Next > Untick IPSec > Next.
Note: You can use IPSec if you want, but you will need a Certificate pre-installed to do so!
Now you need to upload the AnyConnect client packages for each operating system that is going to want to connect,
Once the package (with a pkg extension) is located, you can upload it directly into the firewalls flash memory.
Repeat the process for each OS that will be connecting. (PLEASE! Don’t forget to add the macOS package! or your users will see THIS ERROR) > Next > As mentioned above I’m using LOCAL (on the ASA) authentication. I always set this up first, then test it, then if required, change the authentication method > If you don’t already have a LOCAL user created then add a username and password for testing > Next.
Next (Unless you want to setup SAML) > Here I’ll create a new ‘Pool’ of IP addresses for my remote clients to use. You can also use an internal DHCP server for remote clients, again I normally setup and test with a Pool from the ASA, then if I need to use a DHCP server, I swap it over once I’ve tested AnyConnect. If that’s a requirement, see the following article;
Enter the DNS server(s) details for you remote clients > WINS? Who is still using WINS! > Domain name > Next > Tick ‘Exempt VPN traffic from network address translation’ > Next.
Next > Finish
DON’T FORGET TO SAVE THE CHANGES!! (File > Save Running Configuration to Flash)
Now any remote client attempting to connect to AnyConnect can install the client software directly from the firewall, (This is assuming you have not already installed it for them beforehand).
For Older Versions of the ASA/ASDM
Note: The information below is OBSOLETE, I only leave it here in case someone is running some VERY old versions of the ASDM and AnyConnect
1. Open up the ADSM console. > Click Wizards >SSL VPN Wizard.
2. Select “Both Options”. > Next.
3. Enter a connection name > If you have a certificate already select it here or simply leave it on” -None-” and the ASA will generate an un trusted one. > Next.
4. For this example we are going to use the ASA’s Local database to hold our user database, however, if you want to use RADIUS/Windows IAS select those options and accordingly, and then follow the instructions. Note: To set up IAS read my notes HERE > Enter a username and password.
5. Add. > Next
6. We are going to create a new policy in this case called SSL Users > Next.
7. You can now add bookmarks (Links on the VPN portal page) > Manage > Add > Type in a name > Add. > OK.
8. Give it a name and subtitle (look at step 18 to see how that displays) > Enter the internal URL for the web site > OK.
9. Add > OK.
10. OK.
11. Next.
12. Create an IP Pool (IP range to be leased to the VPN clients that is DIFFERENT to your LAN IP range) > New > enter a name, IP addresses, and the subnet mask > OK.
13. Point the ASA to the Anyconnect client you want to use (Note you can upload a software image from your PC here as well) Next > Accept the warning about NAT Exemptions (Note if you do get a warning to add a NAT Exemption see the note at the end).
14. Finish.
15. Before it will work you need to Select Configuration > Remote Access VPN > Network (Client) Access > AnyConnect Connection Profiles > Double click the Connection profile you created earlier in step 3 > Enter a name in the Aliases section i.e. AnyConnect > OK. > Tick the box that says “Allow user to select connection profile by its alias………” > Apply.
16. File > Save running configuration to flash.
17. Connect externally to https://{public_IP} (Note this has to be in the browsers trusted site list) > Enter a username and password > Login
18. You are now on the “Portal” site any bookmarks created above will be visible > Click the AnyConnect Tab.
19. Double click to launch AnyConnect.
20. The Anyconnect client will install if not used previously (User needs to be local admin) and connects.
NAT Exemptions: Note if you received a warning about needing to add the remote VPN pool as a NAT Exemption (After step 13) you will need to add the following lines to the ASA
Syntax;
[box]
access-list {name} extended permit ip {LAN behind ASA} {Subnet behind ASA} {VPN Pool Range} {VPN Pool Subnet}
nat (inside) 0 access-list {name}
Working example
access-list nonat extended permit ip 10.254.254.0 255.255.255.0 10.254.253.0 255.255.255.0
nat (inside) 0 access-list nonat
[/box]
WARNING: Make sure the name matches any existing no NAT ACLs or your IPsec vpns will fail!
Related Articles, References, Credits, or External Links
I needed to change the certificate used by an ADFS server today. I’d used a temporary self signed wildcard cert to get me up and running now I needed to replace it with a new publicly signed one.
I found a number of ways of doing this INCORRECTLY, so hopefully I will save you making the same mistakes!
Solution
Firstly you need to import your certificate, here from a PFX file, (if you want a PFX file import by double clicking the certificate, then export the certificate, include the private key, and set a password on it). I’ve done this in lots of different articles just use the search bar above it you get stuck.
Make sure your certificate has a small key over the icon, or says ‘you have a private key that corresponds to this certificate‘. If yours does not, then import it on the server/PC you created the CSR (Certificate Signing Request) on, then export it to PFX, them import it using the command above on your ADFS server.
On your certificate > All Tasks > Manage Private Keys.
Add > Object Types > Select Service Accounts > Locate and select your ADFS service account. Grant full control.
Launch the AD FS management console > Service > Certificates > Set Service Communication Certificate.
Select the correct (new) certificate > OK.
On the properties of your new certificate locate the thumbprint (not the serial number!) Copy it to the clipboard, then execute the following command;
[box]
Set-AdfsSslCertificate -Thumbprint {Paste in the thumbprint - minus the spaces!}
[/box]
Note: BEWARE: If you press tab to complete the above command make sure you DON’T use Set-AdfsCertificate it’s Set-AdfsSslCertificate(it will accept the wrong command, without error, and then wont work at the end).
Changing ADFS Certificates: Things That Might Go Wrong
Error;
The ServiceCommunications primary certificate cannot be used because the KeySpec must have a value of AT_KEYEXCHANGE (1).
This value can be changed by reimporting the certificate from a pfx file. From an elevated command prompt, use the command “certutil -importpfx filename.pfx AT_KEYEXCHANGE”. For more information, see http://go.microsoft.com/fwlink/?LinkId=798501
You will also see an Event ID 550
Solution: Import the certificate using the ‘certutil -importpfx certificate-name.pfx AT_KEYEXCHANGE‘ syntax.
Error
Solution: Disable certificate rollover with ‘Set-ADFSProperties -AutoCertificateRollover $false‘ syntax. (Note: Dont forget to enable it again afterwards!)
Related Articles, References, Credits, or External Links
I was P2Ving a server for a client this week. I did a ‘trial run’ just to make sure everything would be OK, and got this;
Yes, that says 13 days and 29 minutes! Suddenly doing this at 1700hrs on a Friday became a moot point! (Note: I was using VMware vCenter Converter Standalone version 6.2)
Solution
At first I assumed this was a network problem, so I moved everything onto the same Gigabit switch, and made sure all the NICs were connected at 1Gbps. Still no improvement. I then shut down as many services on the source machine as I could, still it was terribly slow 🙁
Firstly, make sure Concurrent Tasks, and Connections per Task are set to ‘Maximum’.
Then locate the converter-worker.xml file and edit it;
Usually located at “C:\ProgramData\VMware\VMware vCenter Converter Standalone“
Note: ProgramData is, (by default) a hidden folder!
Locate the section, <useSsl>true</useSsl>, change it to <useSsl>false</useSsl> then save and exit the file.
Then restart the ‘VMware vCenter Converter Standalone Worker‘ service.
Boom! That’s better.
Related Articles, References, Credits, or External Links
This has been bugging me for a while, I use Safari for most things, but recently going to an https (SSL secured) web page that uses a self signed, or expired certificate, give me this;
Now this is to be expected, normally you click ‘visit this website‘ it asks for you password, and away you go. However now it doesn’t, it loops you back here again and you can go round many times, until you give up and use FireFox.
Solution
This stung me yesterday when I wanted to get on the office MFD. The fix is easy, open a new private browsing window (File > New Private Window). Then go to the same URL, what’s more, once you have been to that URL, it now works in normal Safari
Related Articles, References, Credits, or External Links
This week I’ve been working on changing the site over to https. Buying a digital certificate used to be an expensive long winded affair, but not anymore. A quick internet search turned up a 3 year SSL certificate for less than 15 quid.
Getting the certificate was the easy bit, getting it installed so that Apache would use it was another ‘challenge’. On a scale of one to ten, I’m about a three (on a good day) with Linux!
Before you start, you need to generate a CSR and send that to whoever you are going to buy your cert from
What about free Certs? There are some firms that offer free certs, some require you to install software that updates the cert every ninety days, other have a short lifespan. I’m not usually one to spend any money but for a fiver a year, why not?
Solution
Your certificate vendor will sent you your certificate, it will probably come with at least one other cert. In my case it came with three other CA Certs (a RootCA and two Intermediate CA Certs). If you are unfamiliar with certificates, here’s the two golden certificate rules;
You MUST trust the authority (CA), that issued the certificate, or issued the cert to the CA that issued the cert etc.
The NAME on the certificate, either the Common Name (CN), or the Subject Alternative Name (SAN). MUST match the address you are going to.
What you will find with these <ahem> cheaper certificates, is that you trust a CA, and that CA issues another CA Certificate, (to a subordinate CA), that Issues another CA Certificate (To a Subordinate CA), and that CA issues your certificate. All these certificates form a ‘chain’ and it looks like this;
OK why is that important? Well to trust your certificate, your visitors, (and Apache) need to be able to see all the certificates in this chain, right back to the RootCA certificate at the top (which they will trust, or there’s not much point selling them!)
Some vendors will give you a certificate bundle, mine did not so I had to make one (this is not hard to do, see below). But now when you make that certificate bundle, you will have a better understanding of what you are doing, (putting all the CA certs in the chain order, into one file).
Installing SSL Certificates Into Apache
Before you start you may need to install mod_ssl ‘yum install mod_ssl’ will do that 🙂
First you need to copy all the files into CentOS, I created a folder in ‘/etc/ssl/’ called ‘localcertificates’ and copied in the domain cert, the key file (that got generated when I made the CSR – See the link above). And I’ve copied in all the CA Certificates. (I use FileZilla to do this because it’s free, and easy to use).
Now Log into your CentOS server via SSH and navigate to this directory, then use the ‘CAT’ command to make a certificate bundle with all your CA Certificates, (notice the order, SubCA2 > SubCA1 > RootCA). Note: Your certificates will probably have different names.
[box]
cd /etc/ssl/localcerts
cat COMODORSADomainValidationSecureServerCA.crtCOMODORSAAddTrustCA.crtAddTrustExternalCARoot.crt > My-CA.ca-bundle
[/box]
Now in the same directory you will have another file called My-CA.ca-bundle. To get Apache to use the certificates you need to edit the httpd.conf file. In CentOS 7 that usually lives in ‘/etc/httpd/conf’. I use nano because it’s easier to edit files with, (yum install nano). Im also going to back-up the config up as well, in case something goes wrong!
[box]
cd /etc/httpd/conf
cp httpd.conf httpd.conf-old
nano httpd.conf
[/box]
Locate the part of the file that says ‘Listen *.80’ and place a line below it that says ‘Listen *.443’.
Scroll to the end of the file and paste in the following, (change the filenames to match your own).
Note: Make Sure the Logs folder exists in /var/www if you use the same paths as me! Also SSLCertificateChainFile will change in newer versions of Apache to SSLCACertificatePath.
You can now restart Apache and browse to https://www.your-site.com. It can take a little while before it’s back up!
[box]
apachectl restart
apachectl status
[/box]
Everything’s Broken Help!!
This is why we backed up the config, first if there’s a problem ‘apache status’ usually says ‘theres a problem on line XYZ of the httpd.conf file’, if you open it in a text editor that will point you to a resolution. If all else fails, you can restore the original config like so;
[box]
cd /etc/httpd/conf
cp httpd.conf-old httpd.conf
apachectl start
apachectl status
[/box]
How To Redirect All HTTP Traffic to HTTPS in Apache?
That’s even easier, if you have a virtual host for poor 80 already setup in https.conf then just add ‘ Redirect / https://www.your-site.com/’ to it. I did not, but adding one did not break/affect my site at all. After the text you pasted in above for the virtualhost for SSL just paste in a new one for http (TCP port 80).
If you run https services (Note: I say services, this does not have to be a website), the actual security is handled by SSL/TLS, one of the things this does is encrypt the traffic between the client and server. (This is why your online banking and shopping is done over https and not http.)
Thats great, but encrypting and decrypting all that traffic takes a lot of processing cycles, if you have http servers doing that work it will divert a lot of CPU/vCPU time away from its normal job of providing web services. If you have a very busy site, you may start to scale those servers out, and load balance them, but the http servers themselves will still need the extra grunt to do the decryption/encryption work.
You can install SSL accelerators, (often refereed to as Crypto Offload Cards,) into your servers to hand-off that workload, but in a modern virtual datacenter, that does not scale well at all.
So what if you get your ‘load-balancer’ to decrypt the traffic coming in, and re-encrypt it on its way out? The https servers no longer have to do the ‘heavy lifting’. Whats more, if you put an SSL accelerator in your load balancer, that makes it run more efficiently. Thats exactly what Citrix have done, their hardware NetScalers have a Cavium CN1620-NFBE3- 2.0-G or Cavium CN1120-NFB accelerator card in them, to take this job on. (Note: This does not apply to the virtual appliance, (obviously) but that can still perform SSL offloading).
Put Simply: Your forward facing services are HTTPS, your ‘back-end’ services are HTTP.
Solution
Before you start, I’m assuming you already have your back end servers setup in NetScaler, and have those servers presented as either a ‘service group’ or as individual ‘services’. If you are unsure how to do this, follow the article below, (all the way to setting up the Virtual Server.)
I’m also assuming you have uploaded into the NetScaler, the certificate you are going to present publicly, and the CA-Root certificate, (and any intermediate CA certificates if required). If you are using ‘self-signed’ certificates you might want to see the following article;
Log into the NetScaler > Configuration > Traffic Management > Virtual Servers > Add.
Give the Virtual Server a name > Protocol will be SSL > Set the IP (VIP) > The port will be 443 > OK.
Now add in your service group (or service(s)). I have two http servers setup in a service group, (see the article above). Click ‘No Load Balancing Virtual Server Service Group (or Service) Binding.
Search arrow.
Locate and tick your back end service group > Select.
Bind
Continue.
At this point you can upload the certificate and CA certificate.
Done.
It can take a little while to ‘go-green’ if there is a problem, click the drop down error on the left for more information. If this is a new deployment you may encounter the following problem;
While attempting to install vCenter 5.5, I got the following error.
Error 26002. Setup failed to register vCenter Server. This might indicate a problem with the SSL certificates for vCenter Server. Search the VMware Knowledge Base (http://kb.vmware.com) for “Error 26006” for more information.
Earlier on in the install it had asked me if I wanted to overwrite the certs, and I just clicked OK, this probably was not such a good idea!
Solution
1. Navigate to C:Program DataVMwareVMware Virtual Center >Locate the SSL folder and rename it to SSL-OLD.
2. Navigate to C:Program DataVMwareInfrastructureInventory Service > Locate the SSL folder take a copy of it.
3. Paste that folder back in the C:Program DataVMwareVMware Virtual Center location to replace the folder you renamed earlier.
4. This is what the folder should now look like.
5. Now attempt the install, and it should complete without error.
Related Articles, References, Credits, or External Links
