Hello Oliver,

Please see this previous discussion on the topic. All still applies:

 Rdp mfa 

Let us know if you have further questions.

Thanks.

Regards,

Luciano Testa

I have a complete different case.

Hello,

So is this configured already as per that previous thread?

Thanks.

Regards,

Luciano Testa

Hi,

the old post has nothing at all to do with mine .
I want to do RDP via mstsc.exe without using the AAF Windows client as credential provider but with the normal Windows credentials provider.
Alternatively, it would also be okay to do RDP via mstsc.exe with a different AAF event. Is it possible to change the event just for msts.exe? The event should remain the same on the client.

Regards,

Oliver

Hello,

Yes, apologies about that.

I am checking this internally but in the meanwhile I found this in the documentation that seems related:

Enabling Non-Enrolled Users to Log In to Remote Desktop and User Account Control through Offline Mode

You can enable the non-enrolled repository users to perform offline login to the remote desktop and
User Account Control (UAC) with the allowUnknownUserOfflineCredUI parameter.

By default, the Windows Client does not allow non-enrolled users to do offline login to remote
desktop and UAC.

Before you enable this parameter, ensure that the Username disclosure option is set to ON in the
Login Options policy of the Administration portal.

To allow non-enrolled users to do offline login to the remote desktop and UAC, perform the
following steps:

1 Open the configuration file C:\ProgramData\NetIQ\WindowsClient\config.properties.
If the file does not exist, create a new file.

2 Specify allowUnknownUserOfflineCredUI:true (default value is false) in the
config.properties file.

3 Save the configuration file.

Thanks.

Regards,

Luciano Testa

Hi,

thanks for your reply. That's already a good hint. In my case, however, all users in AD are also synchronized to the AAF server.
This means that the user is known but does not have a chain.

The following is the case:
There is an event with three chains on my client:
LDAP Password + Token
LDAP Password + OTP
LDAP Password + NetIQ App
I have removed LDAP Password Only to force 2FA.
If I now want to RDP to a server, I remain in the context of the event and the user with whom I want to RDP is not assigned to any of these chains (nor should he be).

Is there a way to do RDP via mstsc.exe without being in the context of the event on my client?

I hope I have described the problem clearly.

Best regards
Oliver

Hi,

Update:

We successfully addressed the initial issue within the following context, which included an AD Server with or without an installed AAF client, a Windows Desktop with an installed AAF client, and a Hoppingstation (PAW) with an installed client. Our objective was to implement two-factor authentication (2FA) for the login from the Windows Desktop to PAW, while preserving one-factor authentication (1FA) for the login from PAW to additional servers using an Active Directory (AD) user (Operator for servers).

The challenge we faced was the inability to implement 1FA solely for the Windows password, as the event did not allow for "only" the Windows password to enforce 2FA for the PAW Connect.

To resolve this, we devised a new Windows Password chain exclusively accessible to server operators. This new chain was then integrated into the event, ensuring that PAW users are mandated to utilize 2FA, while server operators can proceed with 1FA by employing the newly created Windows Password chain.

2. Remaining Issue:

An unresolved issue persists when trying to log in with the local admin account from a system with the installed AAF Client to another system also equipped with the AAF Client (e.g., Loadbalanced Terminal Server Session Host, when attempting to connect to a specific session host without utilizing load balancing). The password prompt appears in the AAF Client on the initiating system and reappears on the target system after the RDP connection. While this situation might be manageable, the challenge arises from the inability to copy within this context, necessitating the manual entry of a lengthy and randomly generated password.

Does anyone have any ideas on how to resolve this issue?

Regards,

Oliver