After a recent lab on the test bench, I ended up with a 2008 x32 standard server. It took me a while to get this setup and running, so I wanted to keep it (or turn it into a VMware template should I ever need another). But first I needed to ‘remove it’ from the domain it was in. However, when attempting to do so this happened;
Computer Name /Domain Changes
The following error occurred validating the name “Host-Name”
A general network error occurred
That stinks of DNS? But the machine could resolve DNS, ping the domain name, was authenticated to the domain, and could ping itself by netbios name and FQDN?
Leave Domain (via Command Line)
With modern servers and clients we can simply ‘force’ a machine out of the domain with some PowerShell. In an old machine like this (2008 ran Powershell version 1 natively) those commands are not open to us. So to solve the problem I had to go a little more ‘old school’
Remember – You will need to either know the local administrator password, or a local account with administrative access before you drop it out of the domain, (or post reboot you wont be able to login!)
Working for a cloud service provider, (and a Duo partner). I get a lot of queries about Duo MFA for Office 365. Typically (I think) the best solution is to enable Azure Conditional Access and couple that with Trusted sites, so clients get challenged when out on the road, but not in the office. The drawback of this is Azure Conditional Access requires a P1 License, at time of writing that’s about $6 a month on top of you normal 365 licence. So it can work out expensive.
A couple of weeks ago, I was on a call with a client who wanted to use Duo Access Gateway to provide Duo MFA to their 365 tenancy. I’ve done the same thing for other clients with ADFS before, Basically you are just Federating a DAG into your Azure AD, rather than Federating an ADFS Server
This is what it looks like;
Duo MFA: DAG & Office 365 Pre-Requisites
Azure AD Sync needs to be setup, and a registered domain setup in your office 365 tenancy. (NOT the onmicrosoft domain!)
You need (at least) Duo MFA licensing to deploy. One level above free ($30 for a year).
DAG Server 2 x CPU, 4GB RAM, 60Gb HDD (Windows Server 2012 or newer (2019 supported) Note: You can also deploy DAG on Linux.
DAG Server should be in a DMZ, (not domain joined).
Download the newest version of PHP in zip format. and drop it on your desktop, then run the Duo Windows installer. You may be prompted to install the C++Runtime software (which may require a reboot). Post reboot the installer will launch.
Browse to and select the PHP Zip file > Next > Select the correct server hostname (if it’s not listed, then you need to enter it in the ‘hostname’ section of the https binding in IIS manager > Next > If you want to manage the DAG from any other IP addresses enter them > Next > Install.
When done launch the ‘Configure’ page > Create an access password > Submit.
Configure Duo DAG Active Directory LDAPS Access
In the next step we need a copy of your CA Certificate (the CA that issued your domain controller(s) kerberos certificates). If you have just glazed over have a read of the following article;
Get Ready for LDAPS Channel Binding
From the DAG console > Authentication Source > Configure Sources > Select Active Directory* > Enter the FQDN of a domain controller, (the DMZ server needs to be able to resolve this I suggest putting it in the server hosts file). > Port will be 636 (LDAPS) > Select LDAPS > Scroll down.
*You cant use Azure as a authentication source for Office365 MFA, (counter intuitively!)
Browse to and select the CA certificate you downloaded above > Set the attributes to “mail,sAMAccountName,userPrincipalName,objectGUID” > Search Base (I’m setting it to the top of my active directory e.g. ‘DC=pnl,DC=com’ > Search Attributes (I’ve set the same as the attributes above) > Search Username, set to a normal domain user account, (I’ve set-up a service account that’s just a member of ‘domain users’ > Scroll down > Type in the users password > Save Settings.
What should happen is, it should say LDAP Bind Successful, if it does not;
Make sure TCP Port 636 is open from the DMZ server to the Domain Controller(s)
Make sure you used the domain controller FQDN NOT its IP address, (the IP address is NOT on the Kerberos certificate).
Install the Remote Server Admin tools for ADDS – this will give you access to LDP exe which you can test LDAPS connectivity with (I’ve written about LDP before, use the search box above).
When happy, ensure Active Directory is set as the Active Source.
Federate Duo DAG With Azure Active Directory
Within the Duo DAG management console > Applications > Metadata > Download the Certificate > Copy all the URLS to a notepad file.
Copy the notepad file, and the certificate, to a domain joined server/PC that has the the Azure Active Directory Module for Powershell installed.
Execute the following commands, (change the values in RED to match your own);
[box]
Connect-MsolService
Log into your Tenancy, when prompted
get-msoldomain -domain your-domain-name.com
Make sure it says 'Managed' and NOT 'Federated'!
$dom = "your-domain-name.com"
$url = "https://portal.petenetlive.co.uk/dag/saml2/idp/SSOService.php"
$uri = "https://portal.petenetlive.co.uk/dag/saml2/idp/metadata.php"
$logoutUrl = "https://portal.petenetlive.co.uk/dag/saml2/idp/SingleLogoutService.php?ReturnTo=https://portal.petenetlive.co.uk/dag/module.php/duosecurity/logout.php"
$cert=New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("C:\dag.crt")
$certData = [system.convert]::tobase64string($cert.rawdata)
Set-MsolDomainAuthentication –DomainName $dom -Authentication Federated -PassiveLogOnUri $url -ActiveLogOnUri $url -IssuerUri $uri -LogOffUri $logoutUrl -PreferredAuthenticationProtocol SAMLP -SigningCertificate $certData
get-msoldomain -domain your-domain-name.comNOW it should say 'Federated'!
[/box]
Duo MFA Protect Office 365
Log into your Duo online admin console > Protect an application > Locate Office 365 (2FA with SSO self hosted) > Protect.
Unless ALL your mail clients* support modern authentication then tick “Allow legacy mail clients that only support basic auth to bypass 2FA”
*Modern Authentication Supported on: Outlook 2013 (or newer), older Android mail clients don’t, though on modern versions of Android that you can install MS Outlook on does. Modern Apple IOS devices support modern authentication.
Click ‘Save Configuration‘.
Click “Download your Configuration File” this will download a JSON configuration file, put it somewhere your Duo DAG server can get to.
Add Office 365 MFS to Duo DAG
Back on the DAG server > Applications > Browse > Select the JSON file you downloaded above.
Open a web page, and try to log into office 365, after you’ve entered your username, you should be forwarded to your DAG for 2FA
Related Articles, References, Credits, or External Links
I’ve been aware of Let’s Encrypt for a while, they are a non profit Certification Authority, who will provide you with a free certificate, and you can use them for most things you want to secure with a digital certificate. The only reason I’ve never used them in the past is, their certificates have a short (3 month) lifespan, and I see enough things breaking when people forget to renew 12 month certificates! This site went down a couple of years ago because the certificate expired while I was on holiday in Las Vegas, and is was a pain to get fixed!
I’ve got some work coming up that requires me to have a publicly signed certificate, so I thought I’d give it a whirl, it was incredibly easy and painless.
Obviously you need a Windows server, with the IIS role installed, and a website that you want to secure. It does not already need to have a certificate or have https configured, if you have or have not already done that it will all be reconfigured for you! In additional you need a publicly registered domain name, you’re on my website so you know I have one of those, and finally a DNS host record (A Record) that you will use to browse to the web server. The will be ‘stamped’ onto the certificate as the certificate common name (CN).
The website will need to be publicly accessible via TCP Port 443 (https) on the IP address you’ve set in public DNS.
To do all the heavy lifting you need a peice of software, the easiest (I’ve seen) is win-acme (at time of writing the latest version is 2.1.14.996) you simply download it as a zip file.
Extract the contents of that zip file to a folder on your hard drive.
I’ve only got one website, you may be hosting multiple sites, select the appropriate number.
I’m replacing every binding (you can have multiple bindings per site, but I’ve never seen that myself) > It then shows the bindings it finds > Select ‘A’ for all.
Yes to continue > No (unless you want the EULA to open in a web window for you to read) > Yes to agree to the terms (without reading them, shame on you!) > Enter a contact email address.
The software will go and get your certificate, install it, and bind it to your website. If it fails at this point it’s usually because the name for the certificate does not match your public DNS name, or the firewall is stopping your traffic.
Force IIS to Use Let’s Encrypt Free Certificate
To force client to use HTTPS and not HTTP, you will need to tick the option below (Require SSL);
If you take a look at your certificate you will see it’s got a three month lifespan, BUT, you dont have to worry about renewing it because…
Let’s Encrypt Free Certificate Auto Renewal
As well as getting your certificate, win-acme also created a scheduled task to check your certificate validity and renew it before it expires. Cool eh?
Where Does Win-ACME Store its information
Good question, it took me a little while to find that out, essentially once ran it creates a new folder in %programdata% (That’s a hidden folder on the C drive usually) called win-acme all your settings are in there, so if you make a mistake like entering the wrong email address, you can delete this folder and start again.
How To Remove Let’s Encrypt IIS Free Certificate & Settings
Remove the certificate from IIS.
Remove the win-acme folder from %Programdata%.
Delete the scheduled update task from ‘Task Sheduler‘.
Related Articles, References, Credits, or External Links
Outlook URL: I first noticed this a few weeks ago, When copying and pasting a URL into an email it shortens the URL and gives it the pages title. At first i thought my firms Devs had changed the way our CRM works, but then I noticed it happening with SharePoint URLs as well, this is what I mean;
I don’t have a problem with it, in fact I much prefer it! However I got an email this morning from someone asking how to turn it off. As it transpires it has nothing to do with Outlook at all. It’s a feature of the Microsoft Edge browser.
Outlook URL Shortening is Really Microsoft Edge
Within Microsoft Edge > Preferences > Share, Copy, and Paste > Select your preference, if you want to disable this feature select ‘Plain Text’
And now the actual URL will be posted.
Related Articles, References, Credits, or External Links
When considering Securing FortiGate remote administration, I’ve written about changing the https management port to something other than TCP 443 before, I suppose that’s security by obfuscation (though even a script kiddy with one hours experience, will be able to spot an html responses). Typically with other vendors you limit remote administration access, to specific IP addresses (or ranges). So how to do the same in Fortigate?
FortiGate Trusted Hosts
With FortiGate the approach is slightly different, (to Cisco anyway) in that, you allow access from ‘Trusted Hosts‘ and you do that ‘Per Administrator’ not for the entire remote access solution (like HTTPS or SSH). On reflection I like this, because by default you will have a user called ‘admin’ and an attacker will ‘possibly’ know that. With FortiGate you can restrict the admin account so it can only log on from inside, or from management hosts/networks or from an Out of Band management network.
You can also give an administrative password to one partner and only allow access from that partner’s public IP/Range, or if like my firm we need to support a lot of firewalls we can hard code this into our default deployments and retain remote administration. (Though FortiManager is the direction you want to be headed in, for that!)
System > Administrators > Create New > Administrator.
Create a username/password > Select the admin level required > Enable ‘Restrict Login to Trusted Hosts’
Here’s an example where the admin account can only manage the firewall form the 192.168.1.0/24 network, and a management host 192.168.2100.3 For ‘external‘ access I’ve got a new administrator, who can get access from my management host, (for belt and braces), a single public network, and a public IP address.
Related Articles, References, Credits, or External Links
