1Y0-370 · Question #32
When attempting to launch a ShareFile MDX-wrapped app from an iOS device, users encounter an authentication error. What are two possible causes of this issue? (Choose two.)
The correct answer is C. The NTP server configured on the App Controller is unreachable. D. The email address in Active Directory does NOT match the email address of the ShareFile. See the full explanation below for the reasoning.
Question
When attempting to launch a ShareFile MDX-wrapped app from an iOS device, users encounter an authentication error. What are two possible causes of this issue? (Choose two.)
Options
- AThe StorageZone Controller is offline.
- BThe ShareFile application was signed with an invalid certificate.
- CThe NTP server configured on the App Controller is unreachable.
- DThe email address in Active Directory does NOT match the email address of the ShareFile
How the community answered
(30 responses)- A10% (3)
- B17% (5)
- C73% (22)
Community Discussion
8
Isolde G.May 9, 2026C and D are your two correct answers here. An unreachable NTP server on the App Controller causes token validation to fail because MDX authentication is time-sensitive, and a mismatch between the Active Directory email and the ShareFile account email breaks the identity linkage that the MDX-wrapped app depends on to authenticate the user.
Fatima Z.Jun 6, 2026The correct answers are C and D, and here is the mnemonic to lock them in forever: think "TIME and EMAIL or you will FAIL." The NTP issue (C) matters because App Controller uses time-sensitive tokens during the MDX authentication handshake, so if the clock drifts because NTP is unreachable, those tokens look expired or invalid before the user even gets a chance to log in. The email mismatch (D) matters because ShareFile ties your identity to your email address, and if the address in Active Directory says [email protected] but ShareFile has [email protected], the system literally cannot reconcile who you are, so it throws an auth error instead of letting you through. Options A and B are classic distractors because a StorageZone Controller going offline breaks file access, not the auth flow itself, and a bad app signing certificate would stop the app from launching in the first place rather than producing an authentication error mid-session.
Dervla O.Jun 13, 2026My eye went straight to B because "invalid certificate" and iOS in the same sentence feels like an obvious trap the exam wants you to fall into, but reading the stem a second time, the word "authentication" is doing the work, and a bad signing cert is a launch or trust issue, not an auth flow failure. Once I reframed it as "what breaks the auth handshake specifically," C clicked because time skew kills token validation and D clicked because a mismatched email means the identity lookup finds nothing, and both of those live squarely in the authentication path.
Thekla S.May 24, 2026C and D are right. Clock skew breaks token validation, and mismatched email kills the identity lookup before the session ever opens.
Isolde G.May 25, 2026Worth adding that clock skew at the Cloud Connector level will burn you the same way, because Kerberos ticket validation inside the resource location fails independently of whatever the IdP side is doing, so you can fix the SP clock and still sit there wondering why sessions drop.
Bao N.May 15, 2026NTP mismatch trips auth tokens, but why would AD email matter here?
Mateus R.May 24, 2026Does your AD email match ShareFile, and is your clock synced?
Dervla O.May 25, 2026Good check on the clock sync, but on most modern exam sims the session token is bound to your browser fingerprint, not the system clock, so that one rarely bites people anymore - the AD email mismatch is the real culprit worth verifying first.