Mysterious DEP Device Wipe

%3CLINGO-SUB%20id%3D%22lingo-sub-1392405%22%20slang%3D%22en-US%22%3EMysterious%20DEP%20Device%20Wipe%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1392405%22%20slang%3D%22en-US%22%3E%3CP%3EHi%20All%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20am%20investigating%20the%20unexplained%20wipe%20of%20a%20DEP%20enrolled%20device.%20This%20is%20the%203rd%20case%20of%20this.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EFrom%20the%20logs%2C%20I%20can%20see%20nothing%20obvious%20except%20for%20an%20AD%20password%20change%20synced%20via%20AADC.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ESo%2C%20if%20the%20password%20was%20changed%20in%20AD%20and%20synced%20to%20AA%2C%20surely%20the%20Intune%20Company%20Portal%20would%20recognize%20the%20password%20change%20and%20prompt%20for%20the%20new%20password%3F%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EAnd%20what%20if%20the%20user%20entered%20the%20old%20%2F%20wrong%20password%20multiple%20times%3F%20Would%20the%20DEP%20device%20wipe%3F%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EInfo%20greatly%20appreciated.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-1392405%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EIntune%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EMobile%20Device%20Management%20(MDM)%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1393430%22%20slang%3D%22en-US%22%3ERe%3A%20Mysterious%20DEP%20Device%20Wipe%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1393430%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F131657%22%20target%3D%22_blank%22%3E%40Stuart%20King%3C%2FA%3E%26nbsp%3B%20Do%20you%20have%20the%20%22%3CSPAN%3ENumber%20of%20sign-in%20failures%20before%20wiping%20device%22%20setting%20configured%20in%20the%20iOS%20restrictions%20profile%3F%20I%20suspect%20that%20the%20end-user%20entered%26nbsp%3Bthe%20device%20passcode%20incorrectly%20too%20many%20times%2C%20especially%20if%20there's%20no%20log%20of%20it%20in%20Endpoint%20Manager.%20Failed%20authentication%20attempts%20against%20the%20AAD%20account%20would%20not%20cause%20the%20device%20to%20wipe.%3C%2FSPAN%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1394140%22%20slang%3D%22en-US%22%3ERe%3A%20Mysterious%20DEP%20Device%20Wipe%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1394140%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F254026%22%20target%3D%22_blank%22%3E%40eglockling%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CSPAN%3E%22Failed%20authentication%20attempts%20against%20the%20AAD%20account%20would%20not%20cause%20the%20device%20to%20wipe.%22%20-%20Even%20on%20the%20Intune%20Company%20Portal%20app%3F%20Do%20you%20have%20a%20reference%20to%20that%20info%3F%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CSPAN%3EI%20have%20loads%20of%20Sign-in%20failures%20against%20the%26nbsp%3BIntune%20Company%20Portal%20app%20around%20the%20same%20time%20as%20the%20password%20change%2C%20then%20the%20device%20re-enrolling.%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CSPAN%3ERegards%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1402283%22%20slang%3D%22en-US%22%3ERe%3A%20Mysterious%20DEP%20Device%20Wipe%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1402283%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F254026%22%20target%3D%22_blank%22%3E%40eglockling%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EHi%20There%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EMany%20thanks%20for%20your%20reply.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20can't%20see%20anything%20in%20Device%20Compliance%20that%20would%20cause%20this.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThere%20is%26nbsp%3B%20Device%20Config%20setting%2C%20wipe%20after%206%20incorrect%20PIN%20attempts.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EApart%20from%20that%2C%20I%20can%20see%20no%20obvious%20reason%20why%20this%20DEP%20device%2C%20the%203rd%20separate%20one%20has%20suddenly%20wiped.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ERegards%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1400615%22%20slang%3D%22en-US%22%3ERe%3A%20Mysterious%20DEP%20Device%20Wipe%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1400615%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F131657%22%20target%3D%22_blank%22%3E%40Stuart%20King%3C%2FA%3E%26nbsp%3B%20Yes%2C%20the%20Microsoft%20Intune%20and%20Intune%20Company%20Portal%20apps%20do%20not%20define%20this%2C%20it%20is%20a%20configuration%20that%20can%20be%20deployed%20to%20managed%20devices%20that%20leverages%20the%20existing%20built-in%20OS%20feature.%20Once%20the%20config%20is%20deployed%2C%20it%20is%20the%20device%20itself%20that%20evaluates%20the%20failed%20device%20password%20(passcode)%20attempts%2C%20not%20the%20MDM%20agent.%20Failed%20sign-in%20attempts%20to%20the%20Company%20Portal%20would%20only%20affect%20the%20user%20account%20(eg.%20lock%20the%20account%2C%20block%20additional%20sign-ins%20from%20this%20device%2C%20whatever%20your%20organization%20has%20defined...).%20Do%20you%20have%20any%20compliance%20actions%20set%20that%20would%20be%20contributing%20to%20this%20behaviour%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E
Highlighted
Regular Contributor

Hi All

 

I am investigating the unexplained wipe of a DEP enrolled device. This is the 3rd case of this.

 

From the logs, I can see nothing obvious except for an AD password change synced via AADC.

 

So, if the password was changed in AD and synced to AA, surely the Intune Company Portal would recognize the password change and prompt for the new password?

 

And what if the user entered the old / wrong password multiple times? Would the DEP device wipe?

 

Info greatly appreciated.

6 Replies
Highlighted

@Stuart King  Do you have the "Number of sign-in failures before wiping device" setting configured in the iOS restrictions profile? I suspect that the end-user entered the device passcode incorrectly too many times, especially if there's no log of it in Endpoint Manager. Failed authentication attempts against the AAD account would not cause the device to wipe.

Highlighted

@eglockling 

 

"Failed authentication attempts against the AAD account would not cause the device to wipe." - Even on the Intune Company Portal app? Do you have a reference to that info?

 

I have loads of Sign-in failures against the Intune Company Portal app around the same time as the password change, then the device re-enrolling.

 

Regards

 

 

Highlighted

@Stuart King  Yes, the Microsoft Intune and Intune Company Portal apps do not define this, it is a configuration that can be deployed to managed devices that leverages the existing built-in OS feature. Once the config is deployed, it is the device itself that evaluates the failed device password (passcode) attempts, not the MDM agent. Failed sign-in attempts to the Company Portal would only affect the user account (eg. lock the account, block additional sign-ins from this device, whatever your organization has defined...). Do you have any compliance actions set that would be contributing to this behaviour?

Highlighted

@eglockling 

 

Hi There

 

Many thanks for your reply.

 

I can't see anything in Device Compliance that would cause this.

 

There is  Device Config setting, wipe after 6 incorrect PIN attempts.

 

Apart from that, I can see no obvious reason why this DEP device, the 3rd separate one has suddenly wiped.

 

Regards

Highlighted

@eglockling 

 

Hey buddy

 

On further investigation of the iOS Device Compliance and Configuration policies, I have noticed the following setting:

 

Password expiration (days): = 90

 

As roll-out was approx mid-February, 90 days would take it to mid-May, when the reset occurred.

 

Could this be the culprit?

Highlighted

@Stuart King  This would definitely make sense. The end-user probably updated the passcode when prompted, then attempted to use the old one incorrectly too many times.