AuthLite

Notified:  June 05, 2019 Updated: June 05, 2019

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Authy

Notified:  June 05, 2019 Updated: June 06, 2019

Statement Date:   June 05, 2019

Status

  Not Affected

Vendor Statement

We do not provide windows login integration at any level.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Centrify

Notified:  June 05, 2019 Updated: June 06, 2019

Statement Date:   June 06, 2019

Status

  Affected

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Duo Security

Notified:  April 22, 2019 Updated: June 18, 2019

Status

  Affected

Vendor Statement

The Windows login/lock screens are secured by credential providers that collect credentials and perform other authentication-related activities,such as multi-factor authentication(MFA). Some are provided by Microsoft—the most common one being the password provider that usually collects the password as part of login. Other third-party providers,such as Duo,work similarly to the Microsoft providers,but add an additional element of MFA to the login. With changes introduced in v1803 of Windows 10 and Server 2019,Microsoft has decided to use the credentials cached on the client machine to both re-authenticate the connection and unlock the previously-locked desktop,upon reconnecting Remote Desktop Protocol(RDP)sessions. In doing so,Microsoft has hindered credential providers from being able to prompt when a machine is unlocked in this context. By forcing the use of cached credentials,Microsoft has broken functionality used by credential providers to add resilience to this workflow. To be clear,this is not a vulnerability or defect in Duo's service,but rather,it is a defect in how Microsoft has decided to unlock reconnected RDP sessions that have cached,valid authentication credentials without prompting the user. We are unaware of Microsoft providing any effective workarounds for this unexpected change,but will continue to evaluate options to provide an integration as was previously achieved. We hope that Microsoft will provide appropriate configuration to allow those that want the previous functionality to be restored to be able to do so.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Vendor References

Gemalto AV

Notified:  June 05, 2019 Updated: June 17, 2019

Statement Date:   June 17, 2019

Status

  Not Affected

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Idaptive

Notified:  June 05, 2019 Updated: June 05, 2019

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

ManageEngine

Notified:  June 05, 2019 Updated: June 05, 2019

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Microsoft

Notified:  April 19, 2019 Updated: June 11, 2019

Statement Date:   May 29, 2019

Status

  Affected

Vendor Statement

After investigating this scenario, Microsoft has determined that this scenario is using valid,cached credentials. It does not compromise security boundaries or bypass security features. Therefore it does not meet the Microsoft Security Servicing Criteria for Windows. The RDP behavior change observed in VU#576688 was introduced in Windows Server 2019. The change allows the connection to proceed in the earliest phase of connection. As long as it is connected,the client will cache the credentials used for connecting and reuse them when it needs to auto-reconnect. As a best practice,Microsoft recommends that users always lock the client RDP and all computers when unattended.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Okta Inc.

Notified:  June 05, 2019 Updated: June 07, 2019

Statement Date:   June 06, 2019

Status

  Affected

Vendor Statement

This is not a vulnerability or defect in Okta’s service or multi-factor authentication(MFA)integration to Windows Server. Rather,this is an issue in how Microsoft unlocks reconnected Remote Desktop Protocol(RDP)sessions without calling the credential provider. The Okta MFA Credential Provider does not currently support Windows 10 or Windows Server 2019. However,any organization that has chosen to use the Okta MFA Credential Provider for Windows 10 or Windows Server 2019 may be vulnerable to this Microsoft issue,and users may not be prompted for authentication or MFA upon re-establishing an RDP session. As of June 6,we are unaware of any official Microsoft fix,and advise our customers to reach out to Microsoft for next steps.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Vendor References

Ping Identity

Notified:  June 05, 2019 Updated: June 05, 2019

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

RSA Security, Inc.

Notified:  June 05, 2019 Updated: June 05, 2019

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

SecureAuth

Notified:  June 05, 2019 Updated: June 06, 2019

Statement Date:   June 05, 2019

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Silverfort

Notified:  June 05, 2019 Updated: June 17, 2019

Statement Date:   June 05, 2019

Status

  Not Affected

Vendor Statement

Due to the way our products operates,we are not affected by this vulnerability. We use a unique technology which allows us to enforce MFA on top of the authentication protocol itself(e.g. Kerberos,NTLM,LDAP)without relying on Windows login screen.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Vendor References

Symantec

Notified:  June 05, 2019 Updated: June 05, 2019

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

TUNIX Digital Security

Updated:  June 11, 2019

Status

  Not Affected

Vendor Statement

TUNIX/Authenticationservice interacts at a level that is not affected.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Vasco

Notified:  June 05, 2019 Updated: June 05, 2019

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Watchguard Technologies, Inc.

Notified:  June 05, 2019 Updated: June 05, 2019

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

View all 17 vendors View less vendors