I’ve never really taken the time to look at pass-through authentication, I set up Azure AAD sync, then I either use ADFS or I don’t. It was only when looking at removing ADFS, that I even looked at it as an option.
How does Pass-through Authentication Work?
Remote client attempts to authenticate to Office 365 (Azure Active Directory).
Azure queues the request and sends it to an Azure Authentication Agent (on-prem), of which there may be many. Note: The requests will load balance.
The Azure Authentication Agents check the authentication request against the load Active Directory.
The Azure Authentication Agents sends its response back to Azure Active Directory.
The client is authenticated (or denied!)
Why is that Good?
Well you don’t need to deploy ADFS, or WAP. The agent only needs https (outbound) on the firewall Note: If you have a proxy server, theres some URL’s you need to allow. And you don’t need to wait for the default 30 minute AAD replication cycle for changes etc.
Solution
I’m assuming you already have Azure AD sync setup and running, (Simply accept ‘Express settings’ and accept all the defaults), once you have your local AD replicated to Azure, then you can switch over to pass-through authentication.
Open Azure AS Sync > Configure > Change user sign-in > Proceed to ‘User sign-in’ >pass-through authentication > Finish the wizard.
What happens is the ‘first’ Azure Authentication Agent is installed on the Azure AAD server > Force an AAD Sync > Then look in your Azure Portal > Azure Active Directory > Azure Ad Connect > Pass-through authentication > You should see your first agent.
You can select it and check its details. Note: You can download the Azure Authentication Agent software form this page for you to deploy additional Azure Authentication Agents.
The additional agents are simple to deploy, they will require you to authenticate to Azure though.
They will appear one at a time as deployed.
Related Articles, References, Credits, or External Links
Background: Just introduced Exchange 2016 into Exchange 2013 Environment. Mailboxes on Exchange 2016, can send external mail and internal (to Exchange 2013) mail. No mail flows from Exchange 2013 to Exchange 2016. External mail to Exchange 2016, (which flows thought the 2013 server,) also fails.
Event ID 5006
Cannot find information about owning Mailbox Server {server-path} for database {database-path} in routing tables with timestamp {time-stamp}. Recipients will not be routed to this database.
Event ID 5015
Microsoft Exchange cannot find a route to the source transport server or home MTA server {server-path} for connector {connector-path} in routing tables with timestamp {time-stamp}. Microsoft Exchange is ignoring the source transport server.
Solution
Oh I struggled with this for hours! I removed and recreated the receive connectors, on the Exchange 2016 Server. I went though ADSIEdit and checked all the databases, servers and connectors had inheritable permissions, and that the Exchange Server group had the right permissions. I restarted the transport services, and rebooted the Exchange 2016 server.
I was about 7 pages deep in Google translating Spanish and Russian tech posts, when I started to think I might have to ring Microsoft. When I stumbled on a Technet post that had the same Event IDs I posted above.
ANNOYINGLY: The fix is to reboot the 2013 Exchange server! (So I had to plan in some downtime). I was a bit skeptical this would work, and it did take a few minutes, I watched the ‘Undeliverable Queue’ change and the mail get delivered.
Thank you EngineerBoy wherever you are!
Related Articles, References, Credits, or External Links
Now that Microsoft have changed all the GUI management I struggled to locate the queue viewer. As it turns out it is NOT part of the Exchange admin center (https://localhost/ecp).
Solution
1. Launch the Exchange Toolbox application.
2. And looking a little like its Exchange 2010 predecessor, you should see the queue viewer.
3. Which operates the same as it always has.
Related Articles, References, Credits, or External Links
When attempting to send mail to an Exchange EMail Server, you see the above error message. Usually the Exchange can send mail out and exhibits no other problems. You may also see one of the following error messages in the servers event log.
This is caused by an Exchange “Feature” Called “Back Pressure”, and the usual culprit is, there is less than 4Gb (Lowered to 500Mb with SP1) on the drive that holds the mail queue.
Solution
Option 1: Free up some room on the server hard drive so that it has more than 4GB (or 500MB with Exchange SP1) free.
Option 2: Move the mail queue database to another drive that has free space. Note: This is Microsoft’s preferred action.
Option 3: Turn off Back Pressure.
1. Locate the EdgeTransport.exe.config file (Its in Exchange ServerBin).
2. Open the file with notepad and add the following key as shown, (Paste it in).
While putting in a New Exchange 2010 server today, I test moved a mailbox to this new site, and could not get mail to flow to the Exchange 2010 server at the clients main site.
451 4.4.0 Primary target IP address responded with: “451 5.7.3 Cannot achieve Exchange Server authentication.” Attempted failover to alternate host , but that did not succeed. Either there are no alternative hosts, or delivery failed to all alternative hosts.
Mail flowed from the main site to this new site, and internal mail at the new site was fine, but any mail destined for the main site, or going external (because the main site has the only server that can use the Exchange organization send connector) would fail with this error.
Solution
I did a lot of trawling to try and find the answer to this, and discovered lots of reasons for this to happen, so rather than just posting what fixed mine, from the most popular to the most obscure try these in order, and attempt to send mail after each step.
Note: Any change on an Exchange Server’s Receive Connectors should be followed by you restarting the Microsoft Exchange Transport Service (on the server you made the change on) before you try again.
1. On the server you are trying to send TO, check the properties of the Default receive connector and ensure ‘Exchange Server authentication’ is selected.
2. On the server you are trying to send TO, If you have a connector configured to ‘relay’ mail, make sure that the server(s) or network specified DOES NOT include the IP address of the server you cannot send FROM. Also Make sure on the authentication tab ‘Exchange Server authentication’ is NOT selected.
3. If you have Cisco PIX Firewalls between these two mail servers (running version 6 or earlier) make sure smtp fixup is disabled.
[box]
Petes-PIX>
Petes-PIX> enable
Password: *******
Petes-PIX# configure terminal
Petes-PIX(config)# no fixup protocol smtp 25
Petes-PIX(config)# write mem
Building configuration...
Cryptochecksum: f59a9bd3 3129b8bc 474b2415 52f2db0f
1049 bytes copied in 0.430 secs
[OK]
[/box]
4. If you have Cisco ASA Firewalls between these two mail servers, then remove esmtp from the default inspection map.
At this point I admitted defeat and picked up the phone and called Microsoft. One of their support engineers looked at the connectors and settings, and tested the DNS, had me create a new connector, still mail refused to flow. He did however get me pointed in the right direction. When attempting to Telnet to the Exchange server on the main site this is what we saw;
This is what we should be seeing;
Eureka!
I put all the firewalls in, so I know how they are configured, and I know this client has a CSC module in the ASA 5510 at the mail site, I managed to get the output above by rebooting that module, as soon as it was back online we reverted to the short list again. Also while the CSC was rebooting all the mails stuck on the outbound queue cleared.
Enabling CSC Bypass for a Remote Mail Server
Note: Your class-maps, and access-lists may have different names but this should point you in the right direction.
1. Connect to the ASA, view the policy-maps in use.
[box]
Petes-ASA# show run policy-map
!
policy-map type inspect dns preset_dns_map
parameters
message-length maximum 512
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
inspect ftp
inspect h323 h225
inspect h323 ras
inspect rsh
inspect rtsp
inspect sqlnet
inspect skinny
inspect sunrpc
inspect xdmcp
inspect sip
inspect netbios
inspect tftp
inspect icmp
inspect pptp
inspect ip-options
class global-class <<<<< Here we go
csc fail-open <<<< This is the one we are looking for
!
Petes-ASA#
[/box]
2. We can see the class-map the CSC is using is called ‘global-class’, let’s take look at that.
[box]
Petes-ASA# show run class-map global-class
!
class-map global-class
match access-list global_mpc <<<<Here's how its being applied
!
[/box]
3. Now we know that’s being applied with an access-list called global_mpc, let’s see what that’s doing.
[box]
Petes-ASA# show run access-list global_mpc
access-list global_mpc extended deny ip host 10.1.0.253 any
access-list global_mpc extended permit tcp any any object-group DM_INLINE_TCP_1
Petes-ASA#
[/box]
Note: Remember permit means inspect and deny means don’t inspect, you can see mine’s set not to scan the CSC update traffic because that’s good practice;
4. So I just need to add in the IP of the Exchange server I cannot send from to make its traffic bypass the CSC Module. Remember to put it at the top so it gets processed before the permit or it will get ignored.
[box]
Petes-ASA# configure terminal
Petes-ASA(config)# access-list global_mpc line 1 extended deny ip host 10.3.0.2 any
My colleague Allen was doing an Exchange 2003 to 2010 migration today, and things were not going well, mail refused to flow from the Exchange 2003 server to the Exchange 2010 server (it flowed from 2010 to 2003 without error). During migrations that’s not unusual, and removing and recreating the routing groups usually fixes it, but he had done that. Mail was sat on the Exchange 2003 Server outbound queues on the queue that matched the routing group connector, but refused to move with the above error.
Solution
For about 45 minutes I was also scratching my head, but then I had a brainwave. If Exchange 2003 has a ‘Smart Host’ Configured on the ‘Default SMTP Virtual Server’ then it attempts to send traffic down the routing group via the smart host, (which will obviously fail). Remove any entry from the smart host section.
When done, restart the SMTP Service, and the Exchange Routing Service, and the queues should start to clear.
Related Articles, References, Credits, or External Links