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

Parents
  • 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. 

Comment
  • 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. 

Children
  • 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.