User Profile
Moombas
Level 4.1: Jelly Bean
Joined 3 years ago
User Widgets
Contributions
Re: Disable random mac address during EMM enrollment
This goes for several manufacturers i guess but only takes part when device is enrolled already. AFahmy did you look into the Wifi settings when enrolling the device if you can disable MAC randomization there when setting up WiFi settings there already for that specific Wifi? There's no flag i know of to disable it in normal Wifi QR or QR code (enrollment) afaik.Re: Not able to restrict personal email from logging into Work GMAIL app for BYOD enrolled devices
Currently i don't have BYOD devices being managed but ever tried adding gmail as a wark app to the device with managed app config? So, combination would be "username" filled in (should be somehow a macro) and disabling "allow unmanaged accounts" setting. Screenshots taken from Mobicontrol.Re: [Feedback] App installs: share your experiences & suggestions
Pretty sure it's not possible on the way the playstore is working and yes, i was thinking about that a long time ago but came to the decision that if you use play store functionalities (where the private one is part of), it must work like this because that's the identifier (like in a DB) the playstore looks out for the app information like version and so on. So if you would allow it, they get mixed up or need to be 2 completely seperate systems etc. where both doesn't sound good. So, finally you need to use a MDM which can provide apk's directly, so having version control there (like WS1 and Mobicontrol or others) or you need the app developers to create an apk with a bundleID unique for you like "their.bundleID.yourCompany" so you can make use of the private play store. But again, would way more likely have a full version control inside of MGP or even the possibility to load apk's directly from playstore to provide them via the MDM (maybe isolate the download possibility to managed google playstore accounts and ofc only to free apps).Re: Share your deployment experiences with Android zero-touch enrollment
I think thats the dream of everyone but i mean the minimum you always have is to establish a data connection (insert SIM card, scan Wifi QR code (even possible via StageNow) or install eSIM) and after that everything should run without the need of user interaction if fully managed. I think some things may be needed on COPE devices and BYOD is something completely different.Re: [Feedback] App installs: share your experiences & suggestions
Hmm, sounds weird foir me but as i don't know the background of your setup won't target on that as on my understanding it's like: Enroll device into MDM (which requires max. one app (the app needed by the MDM to enroll the device into it)), then the MDM provides all apps and settings to the device. And on our end one step between, as we need the enduser to type in something which is grabbed by the MDM to provide the final configurations/apps and after that is ready to use. Means, the device is not used before all apps and settings are provided by the MDM. And we don't need the "setting" you mention but can provide one that endusers are not allowed to manage apps (install/uninstall,...).Re: What security threats do you experience the most?
It's just an example and shows even if you need complex passwords, you could make it a bit easier even if you in addition replace letters by numbers instead but keeping some kind of same syntax and so on but this is "user based password training" but still less secure than using an additional physical access. And just a related link to it (sry for the German but in my opinion fits to 100% my opinion): https://www.notebookcheck.com/Chaos-Computer-Club-fordert-Abschaffung-des-AEndere-Dein-Passwort-Tags.955034.0.htmlRe: What security threats do you experience the most?
No, writing down is definitely nothing they should do ever. But IT needs to find a good solution in case of good password settings, which the end user may be able to remember because with the good (not too complicated) password (but still matching character rules) which also may then result in the less need of renewing it. This could lead to less written down passwords. But in general, i still raise my hand for Authenticators being used as MFA or even additional to the password a physical device like employee card or finger print being used. And just to add here: Sometimes you also just need to be creative to find a good way to create your own good passwords. Example: Year-Day-SystemToAccess-SomethingUnique Result of Example: 2023-05-Java-IHate This contains automatically numbers, characters and (Capital) letters where year and day is the one you changed the password for example. So everything is something you can somehow easy remember and just need to put in together and being different from system to system.Re: [Feedback] App installs: share your experiences & suggestions
I think, from what i read, you do the app providing the wrong way. You provide apps the normal way after the enrollment is done and then you can use for example https://developers.google.com/android/management/reference/rest/v1/enterprises.policies?hl=de#installtype:~:text=Anwendungen%20delegiert%20werden.-,BLOCK_UNINSTALL,-Gew%C3%A4hrt%20Zugriff%20auf to block the unintallation if needed (without a limit of apps being provided) which i see as the only reason for using your option mentioned before.Re: [Feedback] App installs: share your experiences & suggestions
I think i mentioned this already several times (always in case of COPE or fully managed!): We need one of the following things: Possibility to grab the original apk files from play store, to use app deployment from MDM side (if available) to have full version control (ofc only for free apps, paid apps must be then requested from the developer). Recommended: To get full version control via managed play store Choose update option per app: Always update (always to latest version) Install/stay on x.x.x (available versions need to be read out from playstore), needs to be changed if you choose a new one Never update (stays on the version intially installed) Permissions set per app (not asked for yet from my side): Show all permissions in an option available on the system Already tick the ones the app would request Possibility to tick permissions not asked by the app but you want to grant Possibility to untick permissions asked by the app but you don't want to grant Or even both to have the best experience...Re: What security threats do you experience the most?
I can terrifying 100% agree to this from mattdermody : "The biggest security threat or vulnerability we are exposed and actually affected by the most are the end users themselves." But those sometimes are the result of IT handling passwords. They need to be too complicated, changed too often,... yeah sounds strange from security side but look at the results: users note down passwords on easy to see/find locations users store passwords in cleartext somewhere users always try to use still somehow "readable" passwords (like: Id0ntl1ke!t) ... Which may finally less secure than using strong passwords (ofc) but somehow easy to remember and not too often to be changed and even better maybe make the use of MFA as much as possible (today i think this should be a minimum but still not the case). Also using password managers are not secure because instead of mutliple passwords to be cracked, you only need one (the one from the manager). So if here Software is used which is not secure enough it's getting even worse.Re: Share your deployment experiences with Android zero-touch enrollment
So, back from my vacation will put on my 2 cents here as well: First of all, we use ZTE for all our devices used in stores (fully managed only) for several reasons like, easy wipe and re-enroll without guide or other things needed and so on. Also making them useless if someone steals the device and trying to enroll it (it will get stuck at some point by sure ;) making it useless except you use it 100% offline which is also something which would make it 99% useless). But i also agree to points mentioned here but in my opinion could be solveable somehow: Add options in the config to skip screens getting closer to ZT for cutomers as well For all known "default" Android screens, seperate options For all "unknown" OEM developer screens, one option to skip those Requirement: The relevant screens are somehow "tagged" by the system so it knows what to skip (Please) add the possibility to flag devices as "lost" in ZTE to get them moved to a seperate menu (so you could revert back, if needed) and when enrolled always only show the support information and the only option to factory reset (and if nothing was changed end up there again). Or something similar. Also would like to keep devices here even we maybe cleaned up those models because of a model renewal so those devices stay useless. Improve the functions more into a direction like Knox already have (possibility to add tags, see device model etc. directly in the table without the need of export,...). I don't see problems related to WLAN devices as all modern devices can just scan a Wifi QR to establish such a connection fast and easy BUT StageNow is better on it to crypt this data instead of having it in clear text as Android Wifi QR codes do yet, this needs to be improved on my opinion (same for if you share the Wifi settings via QR, it's shown in clear text under the QR, WHY? Security wise a mess...). So, stopping here on that off topic a bit.Re: Unable to register to Android Enterprise with Corporate email Address
Does this maybe require a Google account assigned to it? Emilie_B That could be an easy and fast thing. "You will need to use your company email address, and will also need a Google Account." https://www.androidenterprise.dev/s/onboarding-guidance So siddeshp did you create a Google account with this mail address? If not, you need to do so and then try again to register.Re: Impact of Intune's NFC restriction setting on IC card reading and Nearby Share
First of all, be aware that the Wish 4 seem not to be AER (i only see Aquos Wish without a number) which can cause problems in management possibilities. I want to add here a description from the MS sides related this setting: "Beam data using NFC (work-profile level): Block prevents using the Near Field Communication (NFC) technology to beam data from apps. When set to Not configured (default), Intune doesn't change or update this setting. By default, the OS might allow using NFC to share data between devices." So, apps can't share data via NFC Beam, which doesn't mean they can't read it or it in general is turned off. I also see no option in our MDM to do so, only for (COPE (guess) and) fully managed devices if you have an OEM config app that has this option available for your devices (https://play.google.com/store/apps/details?id=jp.co.sharp.android.shoemconfig&hl=de).Re: [PRODUCT UPDATE] Zero-touch enhancement: New admin controls
I fully agree to the namings here "but" In general i see this still as a first step in role management. I still dream of getting a real role management system at some point, to define roles myself with permissions chosen from the table per custom role. And something i don't need but others may: Be able to assign roles to devices, meaning that devices without roles assigned can be seen by everyone but devices with role(s) assigned can only be seen and managed by the relevant roles + owner accounts. But now Google will say, we gave them now a bit they requested for, now they want more and more... YES that's how product development is most likely to happen 😜Re: Barcode setup without ENROLLMENT_TOKEN
Forgot to mention, we use StageNow on our side only to provide Wifi settings for Zebra devices which have internet access through it even later and everything else goes through ZTE. Only for those which are in a separated network get fully staged with StageNow barcodes. So both work fine, depending on your setup and requirements/environment.
