Category: Networking

Author Lance LingerfeltPosted on

LDLNET LLC IT Consulting Business is currently CLOSED.

I am still available for music performance through my company but the IT Side of the business has been closed as I am on a full time project and cannot devote any outside time to IT consulting. Thank everyone for supporting me over the years. My blog will still remain current so please check here often for the latest updates for Exchange, M365, Security, Compliance, and Windows!

Author Lance LingerfeltPosted on

Using RDP to access an Azure AD Domain Joined Computer

I have a VM that is joined to my Azure AD test tenant domain. I was having issues using RDP to access the box with my Azure AD credentials (username@tenant.onmicrosoft.com). I kept getting the following when trying to connect:

Azure AD Credentials would not work to RDP to the client.

So I started researching and found that this was an common issue that many have started to face with their Azure AD Joined machines. Unfortunately, at this time it isn’t quite as easy as “open up a new RDP connection, type in the computer, type my email, and connect”.  Here are the steps to connect a session to that Azure AD joined computer.

Steps to connect RDP to an Azure AD joined computer.

First, open remote desktop as if you were going to connect to any other computer. Type in the computer name or IP address and expand the the Show Options section. Next, click the Save As button to save the RDP file to your computer. At this point you can close the Remote Desktop Connection window as it isn’t needed any longer.

Next, open Notepad. Click File -> Open -> location your RDP file that was saved in the previous step. 

Go to the very bottom of the list of parameters and add the following two lines:

enablecredsspsupport:i:0
authentication level:i:2

Save the changes to the .rdp file

NOTE: You can also add your username that will be used to connect to the session in the file as well:

username:s:.\AzureAD\YOURusername@YOURtenantname.onmicrosoft.com

Example RDP File

Now you are ready to connect! Double click on the RDP file and connect to the Azure AD Joined computer.

KEEP RESEARCHING!
STAY POSITIVE! THE WORLD WILL CHANGE FOR THE BETTER FOR ALL OF US!

REFERENCES:
Remote Desktop to Azure AD Joined Computer

Author Lance LingerfeltPosted on

The Windows Time Service, Hyper-V Hosts, and DCs that are VMs.

The sheer craziness of it all! I noticed that my clocks were off on my servers by FOUR minutes. I had originally set in group policy for the PDC emulator for my domain, a VM on one of my Hyper-V hosts, to get the time from the Public NTP hosts. I then configured a group policy to have all the other machines get their time from the PDC Emulator.

This was working great for me until I realized that my Hyper-V hosts were actually controlling the time of the VMs. They were also configured to get the time from the PDC Emulator, but essentially, due to how Hyper-V is configured, the PDC Emulator VM was getting the time from the Host. So, once the time got thrown off, everything went wacky on me!

I’d read through a couple of articles and found the configuration flaw of Hyper-V and the need for those servers to get their time from the external NTP hosts as well as be configured as NTP servers themselves. This totally went against my Group Policy configuration which caused the issue!

Luckily, I had a stand alone server that is a tertiary DC in the domain not running Hyper-V. I was able to get my time synced again properly after performing the following configuration.

  • I had to move the FSMO roles to the tertiary DC with the following cmdlet:

  • I then made sure the tertiary DC was syncing time correctly by running the following on that server:

  • I then removed the Group Policy Object for syncing the time source to the DC that I had linked to my Hyper-V Servers OU in Active Directory
  • Ran a gpupdate /force on the Hyper-V host to remove the policy there
  • I then had to reconfigure the Hyper-V hosts to be NTP Servers and clients that got their time from a public NTP server:

The one problem Hyper-V host that was syncing with the DC VM would not change settings via Group Policy nor through the w32tm cmdlet. I even went into the registry and tried to modify the following keys to make the changes stick:

The values would just not change, most likely due to the time not being synchronized. I had to reboot the server and then run through the process again in order for the changes to stick.

I did look at another article that said to do the following on the DC VM in order for time NOT to sync with the Hyper-V Host:

Go into Hyper-V console on the host machine, right-click on the client VM AD server, and select Settings. Once in here, on the left look under:

Management –> Integration Services
Untick Time Synchronization
Click Apply/OK

Virtual Machine Settings within Hyper-V

Things are running smoothly now. Please view the references at the bottom of the post. There are a couple of great articles about the Time Synchronization process with Hyper-V and why it needs to be setup the way I have it now. I wished I had read it before I originally set this up. I will post the article about getting group policy to handle the time sync process. Just remember, if your PDC Emulator is a VM, don’t sync it to a public NTP server. Sync it to your Hyper-V Host and have the Host sync publicly.
In the long run, I think it is a good design solution to have your Hyper-V hosts time synced to the Public NTP servers than having to remember to configure each VM DC you create to NOT time sync with the host. To each is own though, and one thing I learned from working Microsoft, there are multiple ways to get to the same goal that are technically sound methods.

THANKS FOR READING!
PLEASE COMMENT!

REFERENCES:
Setup of NTP on Hyper-V servers
Time Synchronization in Hyper-V
“It’s Simple!” – Time Configuration in Active Directory
NTP Circular Time Sync – Windows Server 2012 R2 / Hyper-V

Author Lance LingerfeltPosted on

Installing an ‘IP-less’ Exchange Server 2019 Database Availability Group

Yesterday, I posted on how Exchange now uses the Resilient File System (ReFS) to optimize and protect Exchange critical files. Another layer of protection is using a database availability group (DAG) for redundancy and is a necessary factor when designing an Exchange Enterprise Environment.
In this example, I will walk you through the installation of an Exchange Server 2019 DAG as I configured in my environment. This DAG will contain two Exchange Servers in the same site with a third Windows Server 2019 server being the File Share Witness (FSW).

Two Server Exchange DAG Configuration

For my configuration, I configured two identical Windows Server 2019 VMs (same procs, RAM, vhdx drives, partitions, etc…). I configured the Exchange Data Volume using ReFS and mounted them to the same folder on the C: Drive on each server. This is very important for replication to take place successfully when the databases are added to the DAG.


I next went to the Admin server where the FSW would be hosted and added the Exchange Trusted Subsystem Account to the local Administrators group on that server:

IMPORTANT!
Add the Exchange Trusted Subsystem Account to the Local Administrators Group on the FSW.

NOTE: The reason that this is an ‘IP-less’ DAG is that I’m creating a DAG with no cluster administrative access point (CAAP). The DAG has no IP address of its own, and no computer object in Active Directory. The main implication of this is that backup software that relies on the CAAP or backup operations won’t work. This option of an ‘IP-less’ DAG was first introduced in Exchange Server 2013 SP1/CU4, so by now any decent backup products should support this configuration. But you should always verify this with your backup vendor of choice. Also be aware that this is only supported for DAGs that are running on Windows Server 2012 R2 (or later).

Next, we create the DAG from Exchange PowerShell using the New-DatabaseAvailabilityGroup cmdlet. Now remember that since you are using the ReFS system for your database volumes, you will need to specify the -FileSystem parameter within the cmdlet to assure proper setup and replication of the data files.

Next, we add the Exchange Servers that hold the databases that will be replicated within the DAG:

The DAG will now show the two servers as Operational Member Servers:

The FSW Directory was created on the admin01 server when the DAG was created. We can verify that with the following cmdlet:

Next, we add the databases that we want replicated to the DAG as replicated databases. I want all my Databases on EX01 to replicate to EX02 and vice versa for the EX02 Databases. I want the activation preference to remain on the server that the databases were originally created on so I will use the -ActivationPreference parameter to accomplish that. I will go into more detail on Activation Preference in another post.

Now we verify that the Database Copies are healthy on each replication member using the Get-MailboxDatabaseCopyStatus cmdlet. You will see a Healthy Status on the replicated copies:

POSITIVE ENERGY!
KILL NARCISSISM!
HAPPY TROUBLESHOOTING!

REFERENCES:
Installing an Exchange Server 2016 Database Availability Group

Author Lance LingerfeltPosted on

Issue with NAT on Cisco ASA

I was working on upgrading my ASA firewall and was running into an issue with internet working on my device, but none of my server services were responding to requests:

Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (no-adjacency) No valid adjacency

I had configured 1-to-1 Object Based NAT translations for my servers for this purpose as had been configured on my prior ASA device. I had just copied the NAT rules to the new device thinking that it should just work. Needless to say, I had to call Cisco TAC and open a case. This seemed to be an issue for them as well. We kept getting the same error as above with another error listed during the NAT translation of the packets:

ifc selected is not same as preferred ifc
Doing route lookup again on ifc inside

We could ping internally to the server successfully from the ASA through the inside port:

LDLNET-FW01(config)# ping LDLNET-LAN 192.168.100.x
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.100.x, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

Packet Capture:

4 packets captured
1: 01:01:21.086894 192.168.100.2 > 192.168.100.x: icmp: echo request
2: 01:01:21.087153 192.168.100.x > 192.168.100.2: icmp: echo reply
3: 01:01:21.087886 192.168.100.2 > 192.168.100.x: icmp: echo request
4: 01:01:21.088069 192.168.100.x > 192.168.100.2: icmp: echo reply

Again, I had created Object based NAT translations that should have worked for all the inside ports and allowed the packet traffic through properly:

object network Exchange_Server
nat (any,any) static ExchOut net-to-net

Not having knowledge what the net-to-net statement within the NAT Rule stood for, we ended up scrapping all of the Object based NAT rules and created a new rule using a static route:

nat (LDLNET-LAN,outside) source static Exchange_Server ExchOut description Exchange NAT Both Directions

Doing this worked for us and allowed traffic that was NOT translating correctly to be translated and flowing correctly through the ASA.

Phase: 17
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 12345, packet dispatched to next module
Module information for forward flow …
snp_fp_tracer_drop
snp_fp_inspect_ip_options
snp_fp_tcp_normalizer
snp_fp_translate
snp_fp_adjacency
snp_fp_fragment
snp_ifc_stat

Module information for reverse flow …
snp_fp_tracer_drop
snp_fp_inspect_ip_options
snp_fp_translate
snp_fp_tcp_normalizer
snp_fp_adjacency
snp_fp_fragment
snp_ifc_stat

Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: LDLNET-LAN
output-status: up
output-line-status: up
Action: allow

Great! This is working now! The only issue is that I had to create static rules that go through the single interface on the ASA. What if I need to connect other devices to the ASA on different interface ports? Well, I will have to create the static NAT rules for those ports as well. If the current interface fails, I will have to recreate the static NAT Rules for the interface port that I change to. Secure in a way, but not how I think it should be designed.

If anyone has any suggestions for the configuration of this, why I was getting the error, or a way to get the Object Based NAT rules working properly, PLEASE COMMENT!

I’M ALWAYS LOOKING FOR THE BEST SOLUTION!
PLEASE LEAVE YOUR COMMENTS!

LDLNET LLC (844) 884-7838
Contact sales@ldlnet.net for more information!