Cannot ping the selected CA when renewing certificate

I've configured a test environment for migrating certification authorities (CAs) from Windows Server 2008 R2 to Windows Server 2019. The process is well documented and I didn't expect any issues. However, after migrating the root CA to Windows Server 2019, I couldn't renew the CA certificate on the issuing CA still running on Windows Server 2008 R2.

Attempting to renew the certificate I got this error:

Cannot ping the selected CA. Please make sure the CA is running. The RPC server is unavailable. 0x800706ba (WIN32: 1722)

On receiving this error, I tried the common things like verifying network connectivity and disabling Windows Firewall just in case. Some searching around indicated this is sometimes a result of COM+ permissions, but it looked OK. Eventually I found this event on the Windows Server 2019 CA which led me to the source of the error.

Event information:

• Log Name: System
• Source: DistributedCOM
• Event ID: 10036
• Description: The server-side authentication level policy does not allow the user CERTTEST\Administrator SID (S-1-5-21-2892548479-535578393-614425194-500) from address 192.168.0.112 to activate DCOM server. Please raise the activation authentication level at least to RPC_C_AUTHN_LEVEL_PKT_INTEGRITY in client application.
  

The actual cause is DCOM security hardening introduced by Microsoft in KB5004442. This update requires a higher level of security that Windows Server 2008 R2 doesn't support. Until March 2023 you can disable the security hardening with a registry key, but after that you can't downgrade the security.

• Path : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\AppCompat
• Value Name: "RequireIntegrityActivationAuthenticationLevel"
• Type: dword
• Value Data: default = 0x00000000 means disabled. 0x00000001 means enabled. If this value is not defined, it will default to enabled.
  

For applications that are not updated to request the higher level of authentication security, Microsoft has added new DCOM client functionality to automatically raise the security level in the November 2022 update. This should mitigate issues for most client applications on Windows Server 2012 R2 and newer or Windows 8.1 and newer.

For detailed information about KB5004442 see:

• https://support.microsoft.com/en-us/topic/kb5004442-manage-changes-for-windows-dcom-server-security-feature-bypass-cve-2021-26414-f1400b52-c141-43d2-941e-37ed901c769c
  

Updating and Verifying LDAPS Certificate

Windows domain controllers (DCs) can be used by applications as an LDAP server for user authentication or application data storage. To enable encrypted communication with LDAP on a DC, you need to install a certificate on the DC. This uses TLS similar to how a web server does for HTTPS.

If you have an enterprise CA in your Active Directory (AD) forest, a certificate is automatically issued to your DCs for encrypting LDAP communication. If you don't have an enterprise CA in your AD forest, then a certificate isn't issued to DCs automatically and LDAP communication is unencrypted.

Any server certificate added the the computer store on the DC is automatically used and available for secure LDAP. You don't need to configure the DC to use the certificate. You also have the option to install a certificate in the NT Directory Services store. If a certificate is installed into the NT Directory Services store, it is preferred over certificates in the computer store. This is useful when there are multiple services running on the DC (such as IIS) and you want to ensure that secure LDAP is using the correct certificate.

To update the certificate used by secure LDAP, put the new/renewed certificate in the same certificate store as the certificate that's being replaced. The newer certificate will be automatically selected and used for secure LDAP within a few minutes.

If you are a bit paranoid and want to confirm that the new certificate is being used before you remove the older certificate, there are no built-in Windows tools or logging events that display the information. You can use LDP.exe to test connectivity to port 636 and verify that secure LDAP is working, but this doesn't give you information about which certificate is being used.

However, you can download and use OpenSSL to verify which certificate is being used. OpenSSL can be installed on a client computer for testing connectivity rather than the DC. The following command connects to LDAPS on port 636 and displays information about the certificate being used to secure communication:

openssl s_client -connect DCName.domain.com:636

You can use the output from this command to verify the name in the certificate and expiration date.

Reference:

• https://learn.microsoft.com/en-us/troubleshoot/windows-server/identity/enable-ldap-over-ssl-3rd-certification-authority
• https://wiki.openssl.org/index.php/Binaries
  
• https://www.openssl.org/docs/man1.0.2/man1/openssl-s_client.html
  

 

Error adding authorized senders for distribution group

A client has a distribution group in Exchange Online with many members that restricts who can send to the group. This is a common scenario and works quite well.

Configuring specified senders is done in Delivery management. In the example below, Byron Wright and Jeff Smith are allowed to send. Normally to add another sender, you search for them, add, and then save.

When we were adding an additional user, we got the following error:

Error executing request: There are multiple recipients matching
the identity "<user>". Please specify a unique value.

This was verify confusing because we knew all of the email addresses were unique. However, when searching, I found a document mentioning the same error for creating rules in OWA. The cause of the error was multiple recipients having the same display name.

• There are multiple recipients matching the identity error when creating inbox rules in OWA or EMS

Sure enough, we went through the list of specified senders and found several that had duplicates with the same display names (student and staff accounts for example). After we changed the duplicate display names and synced them up to Azure AD we could add and remove specified senders as expected.

The recipient indicated in the error message is not necessarily the identity with the duplicate Display Name. If you attempt to remove users one by one and save the changes, the successful save indicates which is a duplicate. If you're using the method, make sure to note the allowed senders before you start editing.

Otherwise, you can also use the Admin center search bar to see if there are duplicates for a name. This lets you search across recipient types for users, contacts, groups, and teams.

There seems to be some inconsistency in how the uniqueness of users is evaluated. It seems that when you initially add a user it's based on the email address and the display name issue only pops up when you go to edit the list afterwards. For example, we could add Bob@adatum.com (Bob Smith) as a sender even though there was another Bob Smith. But after doing that we'd get the error if we attempted to edit the list.

Is my domain name attached to a tenant?

A common issue is verifying whether a domain name is already attached to a Microsoft 365/Azure AD tenant. If you don't check ahead of time, you often find that you can't add a new domain name to a tenant at a critical time during a project.

To check whether a domain name is already in Microsoft 365:

• https://www.whatismytenantid.com/

If there is a tenant ID, then it's already registered.

This often gets us to the point where no one knows for sure what tenant and who might be able to log in. It might have been created for volume licensing or a Power BI trial. There's really no way to know.

Instructions on how to get the domain name back:

• https://docs.microsoft.com/en-us/azure/active-directory/enterprise-users/domains-admin-takeover

 

Mailbox moves between Exchange Online tenants

For the last several years I've been involved mostly in tenant to tenant migration projects. These projects typically include migration of email, teams, and SharePoint. My focus is on email migration.

For migration, there are a number of third party tools such as MigrationWiz (Bit Titan) and On Demand Migration for Email (Quest ODME) that can be used. I don't know all of the details for all tools, but at least in the case of ODME, the migration is copies mailbox data, but doesn't synchronize it. So, if you migrate data from source to target and the user later deleted data from the source, it is not deleted in the target. Occasionally, this is annoying and causes confusion for users.

Microsoft has tenant-to-tenant mailbox moves in Preview. This type of move is a migration batch like moving mailboxes between on-premises Exchange and Exchange Online. In this case, you get true syncing which is a better quality move. It looks like a bit of a pain to setup and manage, but I expect the experience will improve over time.

• https://docs.microsoft.com/en-us/microsoft-365/enterprise/cross-tenant-mailbox-migration

The documentation claims that mailbox permissions like Full Access are maintained as long as users are part of the same migration batch. It does not mention inbox rules.

Another interesting item that's coming up is Microsoft 365 cross-tenant SMTP domain sharing. This  allows an email domain to exist in two Microsoft 365 tenants simultaneously and will make it easier to manage incremental migrations between tenants when you want to maintain the same email address. The feature is currently in private preview, but is scheduled to be moved into public preview in June 2022.

You can monitor the development status at:

• https://www.microsoft.com/en-ca/microsoft-365/roadmap?filters=&searchterms=67161
  

Query recently created users in Azure AD

Recently had a project where we wanted to identify users created an automated process in the last day. This script gets the job done.

#Gather a list of recently created users

#specify time that will be compared against -24 is the most recent 24 hours
#you can use the option funtion addDays for a longer time period
#Note that time from AzureAD is UTC

$time = (get-date).ToUniversalTime().AddHours(-24)

$users = Get-AzureADUser -All

$newusers = New-Object Collections.Generic.List

foreach ($u in $users) {
    # Write-Host $u.ExtensionProperty.createdDateTime
    If ([datetime]$u.ExtensionProperty.createdDateTime -gt $time) {
        $newusers.Add($u)
    }
}

Write-host "There are " $newusers.count " new users"
$newusers

Dell XPS 13 9380 Pulsating Fan

Short version: BIOS 1.17.0 released Jan 2022 appears to fix pulsating fan issue for Dell XPS 13 9380 in Windows 11

Update: I'm still seeing the pulsating fan occasionally, but less than before the BIOS update.

I recently upgraded my Dell XPS 13 9380 to Windows 11. The entire process was smooth and fast. I was pleasantly surprised by how well it went.

About an hour after the upgrade, as the computer was going to sleep, the fan started to turn on and off at about 1 second intervals. This pulsating stopped if you woke up the computer or (oddly) if you unplugged it from power.

When in doubt, update all drivers and firmware. So, I used Dell Support Assist to download and update all the drivers and firmware. There were about 10 updates. And after applying updates and a restart all seemed good for about 24 hours.

The next afternoon, the fan started to pulsate again. Some Windows Updates had applied since the Dell updates were installed and I was concerned that might be causing the issue. In desperation, I ran Support Assist again, and it showed two updates to apply. One of which was BIOS firmware version 1.17.0.

The BIOS update showed in the history as having been installed yesterday, but it must not have applied properly. This time, the BIOS update applied properly and the problem appears to be resolved.