Jan's questions

I am using Powershell to pull data from Exchange via EWS API.

Import-Module "C:\ews_api\Microsoft.Exchange.WebServices.dll"
$ExchangeServer = 'EXCHANGE'
$ExchangeService = New-Object Microsoft.Exchange.WebServices.Data.ExchangeService([Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2013_SP1)
$ExchangeService.Url = "https://$ExchangeServer/ews/exchange.asmx"
$SearchRootFolder = New-Object Microsoft.Exchange.WebServices.Data.FolderId([Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::Calendar)
$SearchFolderView =  New-Object Microsoft.Exchange.WebServices.Data.FolderView([int]::MaxValue)
$SearchResult = $ExchangeService.FindFolders($SearchRootFolder, $SearchFolderView)

Executing the last line of code will cause a HTTP connection against the Exchange server, which will be left in the TCP state TIME_WAIT for 2 minutes with Windows default settings. Hitting the Exchange server with a lot of queries will result in many TIME_WAIT sessions existing at the same time.

Get-NetTCPConnection | Group-Object State

   Count    Name
   -----    ----
      28    Listen
      10    Bound
       5    Established
       6    CloseWait
     189    TimeWait

There seems to be a limit around 190 TIME_WAIT sessions in Windows, because around that mark I am getting the following error in Powershell.

Microsoft.Exchange.WebServices.Data.ServiceRequestException: The request failed. Unable to connect to the remote server
---> System.Net.WebException: Unable to connect to the remote server
---> System.Net.Sockets.SocketException: Only one usage of each socket address (protocol/network address/port) is normally permitted 10.50.222.87:443

I thought that Windows can allocate a lot more ephemeral ports than that for TCP sessions? And indeed when using another Powershell code sample, I experience no problems.

$connections = @()
for ($i = 0; $i -lt 1000; $i++) {
    $connections += [System.Net.Sockets.TcpClient]::new($ExchangeServer, 443)
}

A thousand connections are opened without problem. However they are in TCP state ESTABLISHED and not in TIME_WAIT. Why am I only running into this issue on TIME_WAIT session states and is there a way to increase this limit?

Get-NetTCPConnection | Group-Object State

   Count    Name
   -----    ----
      28    Listen
    1010    Bound
    1003    Established
       8    CloseWait

1. Created a new group DOMAIN\LapsAdmins. Currently empty.
2. Configured GPO Configure Authorized password decryptors to point to my group DOMAIN\LapsAdmins
3. Forced server1 to create a new encrypted password for the local Administrator account
4. Get-LapsADPassword server1 -AsPlainText -IncludeHistory

As expected, my user DOMAIN\dtrevor cannot decrypt the password.

5. Added DOMAIN\dtrevor to group DOMAIN\LapsAdmins
6. Logoff and logon with user DOMAIN\dtrevor
7. Get-LapsADPassword server1 -AsPlainText -IncludeHistory

As expected, my user DOMAIN\dtrevor can decrypt and view all passwords, both the current password and the whole password history

8. Removed DOMAIN\dtrevor from group DOMAIN\LapsAdmins
9. Logoff and logon with user DOMAIN\dtrevor
10. Ran gpupdate /force on server1
11. Forced server1 to create a new encrypted password for the local Administrator account
12. Get-LapsADPassword server1 -AsPlainText -IncludeHistory

Unexpectedly, my user DOMAIN\dtrevor can still decrypt and view all passwords, including the freshly generated one and also including the whole password history. Why?

Day 1: Only one Domain Controller (DC1) is present. Windows Server Backup is configured on DC1 to save the system state. Delete an important user from AD.

Day 2: Promote additional Domain Controller (DC2).

Day 3: Boot DC1 into DSRM and revert to Day 1 via System State Recovery (non-authorative). Mark the important user for restore via ntdsutil (authorative). Reboot DC1.

DC1 does not sync with DC2 and DC2 does not know show up in Active Directory Users and Computers on DC1. Active Directory Sites and Services shows the NTDS object of DC2 (synced back to DC1 from other domains in the forest I assume), but we cannot run a metadata cleanup since it cannot find the computer object. At this point because DC1 does not sync with other Domain Controllers, the whole AD was reverted back to Day 1 instead of just restoring the important user.

Can we recover from this situation? Is this expected behavior or was there a prerequisite missing in the environment?

I am trying to setup a receive connector as described in https://www.codetwo.com/admins-blog/how-to-prevent-internal-email-spoofing-in-exchange/

This receive connector listens to IP Ranges from the internal network. Here is how I created the connector:

New-ReceiveConnector -Name "Internal Clients" -TransportRole FrontendTransport -Usage Custom -Bindings 0.0.0.0:25 -RemoteIPRanges 192.168.0.50 -AuthMechanism TLS,Integrated -PermissionGroups ExchangeUsers

The IP address is from the machine I'm doing the testing from. Now I want to send a message from this computer. I am testing with PowerShell.

Send-MailMessage -SmtpServer [email protected] -UseSsl -From [email protected] -to [email protected] -Subject "Test"

In the link mentioned above, this seemed to work immediately. I however get the following error message:

Send-MailMessage: The SMTP server requires a secure connection or the client was not 
authenticated. The server response was: 5.7.1 Client was not 
authenticated

I'm logged in as [email protected]. So I thought that maybe this doesn't work because the receive connector doesn't have the anonymous access and that I have to provide credentials.

After manually providing the Credentials with the -Credentials parameter I receive the following message instead.

5.7.1 Client does not have permissions to send as this sender

This doesn't make any sense to me, since I am literally authenticating as the AD user of the mailbox, but I cannot send mails.

The FrontendTransport Receive Connector Log has the following entries:

2020-01-31T09:01:02.552Z,SERVER\Internal Clients,73D4991F209,46,192.168.0.1:25,192.168.0.50:52691,*,DOMAIN\TEST,authenticated
2020-01-31T09:01:02.583Z,SERVER\Internal Clients,73D4991F209,47,192.168.0.1:25,192.168.0.50:52691,*,,Proxy session was successfully set up. Outbound session will now be proxied
2020-01-31T09:01:02.583Z,SERVER\Internal Clients,73D4991F209,48,192.168.0.1:25,192.168.0.50:52691,>,235 2.7.0 Authentication successful,
2020-01-31T09:01:02.661Z,SERVER\Internal Clients,73D4991F209,49,192.168.0.1:25,192.168.0.50:52691,-,,Remote(SocketError)

It looks like the authentication goes through, but after that there is an error?

Okay I found the log of the connector which it gets proxied to, this basically just shows the message that I already get in my PowerShell Session:

2020-01-31T09:21:26.875Z,SERVER\Client Proxy SERVER,48F69B08,67,192.168.0.1:465,192.168.0.50:13767,>,550 5.7.1 Client does not have permissions to send as this sender,
2020-01-31T09:21:26.875Z,SERVER\Client Proxy SERVER,48F69B08,68,192.168.0.1:465,192.168.0.50:13767,-,,Remote(ConnectionReset)

So I guess my question would now be why am I getting refused to send as the sender who owns the mailbox?