Labels

AAF
204
ActiveSync
2
Advanced Authentication SaaS
0
Apache Plugin
1
API
9
Authenticator Linking
6
Bitcode ios
1
Cluster Services
4
Configuration
186
Customization options
44
customize OSP login page message
6
Dashboard-Visualization
1
Dashboards-Visualization
36
Device Access
9
Display info on logon page
9
Email
6
Emergency Password Improvement
2
Endpoint ID
2
filter user reports
1
Filters
3
fingerprint
8
Flex OTP
2
Font
1
Idea
92
Installation-Deployment
34
Integrations
99
license
4
Mac
5
MacOS
7
Manage Chains at endpoint
1
Methods
39
new variable
1
Oauth2 Events Redirect URI
5
OTP
16
Outlook
2
Permissions
1
Policies
13
promoting a new GM should not require dns...
1
Readability
2
Reporting & Analysis
8
Reports
10
REST API
6
Roles and Responsibilities
3
SaaS
4
saml attribute
5
Smartphone
29
SMTP
1
SSL
6
SSO
12
Status
3
Supported Platforms
20
timeout
6
Token Lifecycle Management
1
Tokens
5
TOTP
7
UI
21
User Accounts
12
user administration
9
UX
18
Other
98
Idea ID: 2874131

Protect accessing to Network Share with MFA.

Mtrix GmbH
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. 

  • in reply to ablatzheim 

    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.

Comment
  • in reply to ablatzheim 

    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.

Children
No Data

Resources

Support
Documentation
Learning Services
Partner Programs
Privacy
Compliance
Help
Company
Privacy Policy
Terms of Use
Cookies Preferences
Accessibility
Anti-Slavery Statement
Support
Contact Us
Careers
Code of Business Conduct and Ethics
The opinions expressed above are the personal opinions of the authors, not of OpenText. By using this site, you accept the Terms of Use. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.), Hewlett Packard Enterprise Company, or Micro Focus. As of January 31, 2023, the Material is now offered by OpenText, a separately owned and operated company. Any reference to the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks is historical in nature and the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks are the property of their respective owners.