Use WinRM w. Kerberos from AAD-Joined Device to on-prem server?

Question

Hello,

Been trying to get this working;
My client computer (AzureAD Joined) where I login using my on-prem AD-account w. is synced to AAD > WinRM (ex. Enter-PSSession or using a certain MMC snap-in) to a on-prem AD-server using kerberos

Now I've read this article;
https://msendpointmgr.com/2021/08/15/sso-to-domain-resources-from-azure-ad-joined-devices-the-mega-series/
which makes me believe it would work and I also believe I know what the issue is but let me elaborate some more:

• The UPN for our on-prem AD is "myuser@ad.mydomain.com" but we transform the UPN when we sync the user to AAD so it becomes "myuser@mydomain.com" (using the email-attribute as UPN instead)

So this is what I've tried and the results I get;

test-wsman -ComputerName my-onpremserver.ad.mydomain.com -Authentication Kerberos

The WinRM client cannot process the request. Kerberos authentication cannot be used with implicit credentials if the client computer is not joined to a domain. Use explicit credentials or specify a different authentication mechanism than Kerberos.

if I then try specifying explicit credentials (e.g. -Credentials $cred where $cred being ad\mydomainuser)

WinRM cannot process the request. The following error with errorcode 0x80090311 occurred while using Kerberos authentication: We can't sign you in with this credential because your domain isn't available. Make sure your device is connected to your organization's network and try again. If you previously signed in on this device with another credential, you can sign in with that credential.
 Possible causes are:
  -The user name or password specified are invalid.
  -Kerberos is used when no authentication method and no user name are specified.
  -Kerberos accepts domain user names, but not local user names.
  -The Service Principal Name (SPN) for the remote computer name and port does not exist.
  -The client and remote computers are in different domains and there is no trust between the two domains.
 After checking for the above issues, try the following:
  -Check the Event Viewer for events related to authentication.
  -Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport.
 Note that computers in the TrustedHosts list might not be authenticated.
   -For more information about WinRM configuration, run the following command: winrm help config.

If I check my local computers EventViewer (Microsoft-Windows-Kerberos/Operational) I can see;

EventID 200: 
The Kerberos client could not locate a domain controller for domain local: 0xC000005E. Kerberos authentication requires communicating with a domain controller.

Ok so the message above seems to indicate that my on-prem domain (ad.mydomain.com) is not being identified correctly which I can also see through:

nltest /dsgetdc:ad.mydomain.com /force
Getting DC name failed: Status = 1355 0x54b ERROR_NO_SUCH_DOMAIN

however running

nltest /dnsgetdc:ad.mydomain.com /force
List of DCs in pseudo-random order taking into account SRV priorities and weights:
Non-Site specific:
   mydomaincontroller01.ad.mydomain.com  <some-ip>
   mydomaincontroller02.ad.mydomain.com  <some-ip>
   mydomaincontroller03.ad.mydomain.com  <some-ip>
The command completed successfully

So I guess that I get this error because of:
My AzureAD-synced user has a UPN of "myuser@mydomain.com" whereas my on-prem domain / user has "myuser@ad.mydomain.com"; looking up "mydomain.com" does not point to a valid domain since it should point to "ad.mydomain.com"?

Would appreciate suggestions / feedback or if I have completely misunderstood this all together :D

Best Regards

Update 2022-02-16:

When checking how our "AD Connect" is setup I can see the following for the rule that handles most of our AD-User transformation / mappings:

Source                : {}
Destination           : domainFQDN
FlowType              : Expression
ExecuteOnce           : False
Expression            : %Domain.FQDN%
ValueMergeType        : Update
MappingSourceAsString : %Domain.FQDN%

Source                : {}
Destination           : forestFQDN
FlowType              : Expression
ExecuteOnce           : False
Expression            : %Forest.FQDN%
ValueMergeType        : Update
MappingSourceAsString : %Forest.FQDN%

if I check the rule in the GUI ("My inbound sync. rule" > "Transformations") I can see:

Source: %Domain.FQDN%
Target Attribute: domainFQDN

Source: %Forest.FQDN%
Target Attribute: forestFQDN 

So those attributes seem to get passed along to AzureAD however when I try and find the actual properties in AAD (using "Get-AzADUser") I can't find them ("domainFQDN" and "forestFQDN"), and I have looked under "AdditionalProperties".

How come?

Might this be why it (see original post) isn't working?