Idea ID: 2874131

Protect accessing to Network Share with MFA.

Status : New Idea

For now it is possible to bypass AA Windows Client Credentials Provider when accessing Network Share from machine where AA Client installed. 

How to reproduce:

--

1. Make sure that AA Client installed on machine you accessing Netwotk Share from. 

2. e.g. open "This Computer"

3. Input Shared resource path into as address 

4. Press "Enter"

5. Windows Security windows pop ups

6. It is possible to input only username name and password with no MFA

Labels:

AAF
  • Hi Andreas,
    Sorry if I wasn't clear enough. But I'm talking about case when machine with AA Client installed is joined to Domain. Also target networkshare also located at machine that joined to Domain. Please pay you attention that Microsoft Windows allow to select 3rd party credential provider for authentiction(AA Provider 3rd in the list, see screenshot). The problem that AA provider is not default + user can pickup any provider from the list.

  • Hi, 
    this is a request limited by Microsoft and not AA. The common option in the Microsoft world would be the creation of an AD and the ussage of Kerberos. If this is given, the access to a network share will not require an aiuthentication and is managed by Kerberos Tickes which allow SSO. THe case where a user is ask for a password is allways given when either the Worksatation or the Server are not a part of the domain. THis creates totally different situation within the system and generates a fallback to NTLM as authentication protocol. 

    Case 1: Workstation not part of the domain / Sever is domain member 
    In the case Kerberos Fails, the server offers NTLM as authentication for the client
    Client offers the user a Login windows.
    Credentials are deliverd by the NTLM protocol to the server.
    Server Validates credentials against DC. 
    DC Proves credentaisl 
    and so on. 
    There is no hook for a 3rd party authenticaiton implementation. 

    Case2: Workstation is part of the Domain / Server is not part of the domain. 
    This differs in the proofing methode as the lokal User store of the windows server is used. 
    But the rest is basically the same. 

    There is also no 3rd party interface to get MFA working in these cases. 

    Microsoft in general does not offer a 3rd Party interface tor serverl protocol implementations like DCOM (Admin Tools, PowerShell Remoting) or CIFS (File Sharing). THere is also no real interfce for the new SSH Server. 

  • Hi Bruno,

    Thanks for idea, but as I know AA Logon Filter is not "popular" component. Moreover, AA guide says that the main goal of AA Logon Filter is "..prevent users to log in without the Advanced Authentication Windows Client.". But it is possible to bypass MFA with AA Windows Client installed.

  • The suggestion is that security groups could be implemented with the Logon filter installed on the Domain Controller. Only authorized accounts should belong to the security group and to become a member of this security group should follow a strict request/approval workflow.