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:
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:
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.
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 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:
1
2
3
4
5
6
7
Get-MailboxDatabaseCopyStatus-Server EX01|ft-a-wr
Name Status CopyQueueLength ReplayQueueLength LastInspectedLogTime ContentIndexState
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
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:
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!
Contact sales@ldlnet.net for more information!
Cookies Notice for itblog.ldlnet.net
This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. AcceptRead More
