A few months ago I wrote an article about getting free exchange certificates with Lets ‘Encrypt’. And that still works peachy, I implemented it on my test Exchange 2019 server (in Hybrid mode) and all appeared well.
Some time later, (remember this is my test network so it’s not in production.) I noticed that mail was not getting forwarded from O365 to the on premises Exchange server. I’ve also had to fix similar problems like this before here.
These were to sort of errors I was seeing;
450 4.4.317 Cannot connect to remote server [Message=451 5.7.3 STARTTLS is required to send mail] [LastAttemptedServerName=mail.petenetlive.com] [LastAttemptedIP=x.x.x.x:25] [DB8EUR05FT046.eop-eur05.prod.protection.outlook.com]
450 4.4.317 Cannot connect to remote server [Message=451 4.4.0 TLS negotiation failed with error SocketError] [LastAttemptedServerName=mail.petenetlive.com] [LastAttemptedIP=x.x.x.x:25] [DB3EUR04FT033.eop-eur04.prod.protection.outlook.com]
So the problem is obviously something to do with the certificate on the on premises server, so either it’s misconfigured or Microsoft O365 does not like the ‘Lets Encrypt’ certificate.
Solution
Firstly I made sure the send and receive connecters were using the correct certificate.
Note: Above, change the server names and send connector name to match your own.
At this point I was pretty sure that the problem was with that cert so I bought myself a 12 month SSL cert (for the princely sum of $17) and used that instead.
How To Swap Hybrid Connector Certificates
Get the Thumbprint for the NEW publicly signed certificate (Get-ExchangeCertificate). Then use the following PowerShell.
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
If you have something boring/repetitive to do then Powershell is your friend! I needed to do this for a client that’s replacing their Office365/Azure AD MFA (Multi Factor Authentication) with Duo.
Solution
Connect to your Microsoft Services Online, i.e. Office365/Azure, using your administrative credentials with the following command;
[box]
Connect-MsolService
[/box]
Then (Note: I’ve got more than 1000 users so I need to add the MaxResults switch).
Why would you want to disable ADFS authentication? Well what if ADFS is down, or you want to revert to some other authentication method? I was in a position a few weeks ago where I needed to disable ADFS on a clients Azure AD Sync. At that time the Microsoft Tech on the phone steered us towards doing what I can only describe as a ‘forced de-federation’. This involved using Powershell and it resets the password on all the ‘cloud’ accounts and puts those passwords in a text file.
I need to migrate the same client to ADFS in the near future, so I wanted to investigate what to do if I had a problem in future, “How do I roll back?” and more importantly “How do I limit disruption if theres a problem?“
So I built it on the test bench, and did it myself.
Solution
To disable ADFS you need to substitute it for something else, the most common (and easiest) options to work with are ‘Password Hash Synchronisation‘ or ‘Pass-Through Authentication’. I’m going to use password hash synchronisation, but I will also link to pass-through authentication, if you prefer that option.
First job, is to make sure you are on the newest version of Azure AD Connect you can get your hands on. Older versions will not have the options you require. The version you see below was the newest at time of writing.
Then we need to enable password hash synchronisation > Launch Azure AD Connect > Configure > Customise Synchronisation options > Proceed to ‘Optional Features’ > Tick ‘Password Hash Synchronisation’ > Complete the wizard.
WAIT! Let your AD replicate the password hashes, I usually just Force a Delta Azure AD Replication. Then you need to swap from ADFS. Launch Azure AD Connect > Configure > Change user sign-in > Next > Tick “Password Hash Synchronisation’ > Accept the warning > Next.
Note: Yes I saw the warning too, but I had users logged into Outlook etc, and no-one was re-prompted, and no-one was refused authentication. Even so, If you are concerned you might want to do this on a weekend, or after hours.
OK what about ‘Pass-Through Authentication”? If you want a long term scalable ADFS replacement this might be a better option for you, there are some hoops to jump through, and a bit more planning and forethought. See the following article for an explanation;
I upgraded my On-Premises Hybrid Exchange server recently, from Exchange 2016 to Exchange 2019. I remembered to add the new server onto the Office 365 send connector, but there was no mail flow between an on premises mailbox and an office365 mailbox?
Solution
This happens because, (even if you are using the same certificate on the new and old servers) the certificate that is used for TLS security between your on-premises Exchange server and Exchange online, does not get ’embedded’ properly on the send/receive connectors. You may see either (or both) of the following two problems.
Check The Office 365 Mail Flow
Log into Office 365 > Admin > Exchange Admin Center > Mail Flow > Connectors > Select the ‘Outbound’ connector > Validate this connector.
Herein lies the problem!
450 4.4.317 Cannot connect to remote server [Message=SubjectMismatch] [LastAttemptedServerName={on-prem-fqdn}] [LastAttemptedIP={on-prem-ip}}:25] [{outlook-FQDN}]
At first I thought the on-premises server was presenting the wrong cert for TLS, turns out it was not presenting a cert at all! You can check by executing the following command on the RECEIVE CONNECTOR;
If it returns no entry (like the image below), then you need to simply attach the correct certificate. To do that first get the ‘thumbprint’ of the correct certificate;
[box]
Get-ExchangeCertificate
[/box]
Copy the correct thumbprint, and embed it with the following commands;
Get-MailboxPermission -Identity "Alias or email" | Format-Table
[/box]
Add Office 365 Mailbox Delegation Permissions
[box]
Add-MailboxPermission -Identity "Alias or Email of account granting rights TO" -User "Alias or Email of account granting rights FROM" -AccessRights FullAccess -InheritanceType All
[/box]
To check it worked simply use the Get-Mailboxpermission again;
Remove Office 365 Mailbox Delegation Permissions
[box]
Temove-MailboxPermission -Identity "Alias or Email of account removing rights TO" -User "Alias or Email of account removing rights FROM" -AccessRights FullAccess -InheritanceType All
[/box]
Related Articles, References, Credits, or External Links
If you are using Azure AD Connect, (AAD Connect) to sync your on-premise Active Directory with Azure AD (i.e. for Office 365), then there may be times when you need to manually ‘force a replication’ because by default it’s going to take 30 minutes between each normal ‘delta replication’
Solution
If you are directly on the server that’s running Azure AD connect, then use the following PowerShell. If you Don’t know which server is running AD connect the see the following link;
Firstly you need to add in the correct module, (you only have to do this once). Though the module should be already installed on the Sync server, let’s not tempt fate and check. (You can also use Get-Module to view installed modules).
[box]
Import-Module ADSync
[/box]
Note: If you get an error you may need to run Import-Module “C:\Program Files\Microsoft Azure AD Sync\Bin\ADSync\ADSync.psd1”
Then to Manually Force a Synchronisation;
[box]
To Perform a FULL Sync
Start-ADSyncSyncCycle -PolicyType Initial
To Perform a (Normal) Delta Sync
Start-ADSyncSyncCycle -PolicyType Delta
[/box]
You can view the Sync settings with;
[box]
Get-ADSyncScheduler
[/box]
But I don’t like that, I prefer to watch synchronisations going on on the ‘Syntonisation Service Manager’ console, you can spot and troubleshoot errors in here also 🙂
Note: To Troubleshoot Sync errors, see the procedure I use in the following post;
I was doing some work for a School recently, their staff were already using Office 365 and their tenancy was all setup. Now they wanted to roll Office 365 out to the pupils, and sync to their on premises Active Directory.
Now we could have simply excluded the staff from the Azure AD Connect Sync, but they want to manage their passwords etc. on-premises. Microsoft will tell you if you DON’T have an on-premises Exchange (they didn’t), then you simply need to enter the correct email address on the user object and the correct accounts will match up and sync, however they did not, this happened instead;
Unable to update this object because the following attributes associated with this object have values that may already be associated with another object in your local directory services: [ProxyAddresses SMTP:username@domain-name.com;]. Correct or remove the duplicate values in your local directory. Please refer to http://support.microsoft.com/kb/2647098 for more information on identifying objects with duplicate attribute values.
OK, I’ve worked A LOT with Exchange and I know that ProxyAddress and Email address are related, but not the same AD attribute. But changing that didn’t fix the problem either?
Solution
Well we are syncing on-premises Active Directory and Azure Active Directory, and we DON’T want to change anything on site. So logically wherever the ‘fix’ is, it will be in Azure. (If you only ever use the Office 365 portal then buckle up)
Within Office 365 Admin > Admin Centers > Azure Active Directory.
Welcome to Azure! > Azure Active Directory > Azure AD Connect > Connect Health.
Sync errors.
Duplicate Attribute.
Select the affected user(s) > Troubleshoot.
Double check it is the same user! (If you get this wrong all manner of carnage will unfold!) Yes > Apply Fix > Confirm.
Now wait for a directory replication, (or force one manually with PowerShell). The errors should now cease.
Related Articles, References, Credits, or External Links
If you have one, (or more) users and you want to BLOCK those users from sending ANY email attachments, here’s how to do it;
Solution
Log into your Office 365 tenancy with administrative access > Admin > Admin Centers > Exchange Admin > Mail Flow > Rules > Add > Filter Message By Size.
Name: Give it a sensible name. Apply This Rule If: The message size is greater than or equal to = 1.00 KB (we will change this in a minute!) The Sender Is: Add the user(s) in question. Do The Following: Reject the message with the explanation = “Enter some sensible text”.
Scroll down.
Tick: Stop processing more rules.
Save.
Now this blocks all attachments over 1KB (1024 bytes), but this still lets a user send a smaller attachment! The ONLY way to fix that, is to drop the limit using PowerShell.
If you are used to running ‘on-prem’ Exchange then allowing an IP/Hostname to relay mail (sent mail through without authenticating) it’s handy for things like older multifunction scanners, or applications that need to send emails. Now you SHOULD be sending mail through Office 365 ‘authenticated’, but that’s not always possible.
Solution
From Office 365,Launch The Exchange admin console.
Mail flow > Connections > Add.
From: Your Organisations email server.
To: Office 365
Give the connector a sensible name > Next.
Enter the PUBLIC IP or PUBLIC HOSTNAME > Next.
WARNING: Where possible ensure this IP is only used by the internal host that needs to relay, if you only have one public IP (And you NAT/PAT all your internal IPs to this public IP), then filter the hosts that can send mail ‘outgoing’ on your firewall. If you don’t, and an internal client gets infected it will be able to send unauthenticated mail though your office 365 account!
Text
Save.
Related Articles, References, Credits, or External Links
