Jump to content

Mirek S.

ESET Staff
  • Posts

    143
  • Joined

  • Last visited

  • Days Won

    2

Mirek S. last won the day on January 17 2020

Mirek S. had the most liked content!

About Mirek S.

  • Rank
    Newbie
    Newbie

Profile Information

  • Gender
    Male
  • Location
    Czech Rep.

Recent Profile Visitors

2,860 profile views
  1. Hello, This is not possible as Apple devices does not allow for such change when they are enrolled. You will have to reinstall MDM with external hostname and enroll devices again. HTH, M.
  2. Hello, MDM certificate change is somewhat complicated process due to support for self-signed certificates. MDM first installs dual-trust profile (device will trust both old and new certificate), then replaces enrollment profile with trust to new certificate. At this moment both certificates are still trusted. When all devices arrive into previous state (or timeout happens) MDM exchanges it's outside HTTPS certificate with new one. Then process of uninstallation of dual-trust profile (installed as first step) is run. Until all this is complete there is some protection state on devices / MDM. As a sidenote for newer EESA versions EESA (as iOS) also trusts 3rd party root CAs preinstalled in device certificate store. Currently certificate change process isn't adapted to this, however even if some protection state persists entire process is safer with such certificates as devices which fail to exchange trust will still continue to connect. If some protection state persists after MDM certificate is exchanged please contact support as it (as always) could be issue on our side. HTH, M.
  3. Hello, Currently only newly enrolled devices (or reenrolled ones) will have profile signed with new certificate. M
  4. Hello, We do support iOS/iPadOS 15, however there were multiple changes in v15 which are not implemented in MDM. There is currently no roadmap to add support iOS v15 new features (except for policies which will be delivered by module update). If You're experiencing issues with iOS 15 please contact customer care. HTH, M.
  5. Hello, Only TLS not aware (just port forwarding without traffic introspection) is supported on both ports. 9980 (by default enrollment port) allows for reverse/application proxy. 9981 (by default mdm port) requires client certificate authentication and thus supports only port forwarding. HTH, M.
  6. Hello, MDC uses - so called - silent license. It should activate the same way as EP server, and does not eat any license from total (license is used just for telemetry and module updates) Devices use EESA license. You might use EP endpoint license but those are more expensive. Generally licensing for devices works the same way as for other producs. HTH, M.
  7. Hello, Please contact local customer care, without actual logs we can't tell. One mistakes customers make relatively frequently is using new APNS certificate (which isn't prohibited by MDM) instead of renewed one which will break connectivity. Phones don't need renewed APNS certificate only MDM needs it (and with correct one connectivity is immediately restored). In case of a new APNS certificate iOS devices have to be reenrolled instead. HTH, M.
  8. Hello, As @MichalJ noted, this is "issue" on MSP provider side, where he installed certificate which is not by default trusted by Android devices. Situation can be remedied by using 3rd party certificate (not ESMC/not self-signed) trusted by Android certificate store by default. Note this issue is related only to enrollment, after enrollment is complete (I.e. You manually choose to trust MSP generated certificate) connection is secure. There does not seem to be official list of trusted root CAs preinstalled with Android, so I'll at least point out same list for Apple devices. https://support.apple.com/en-us/HT205205 For our cMDM solution I believe we are using digicert signed certificate which works across large range of devices and versions. Whether You require Your MSP to fix that certificate depends on Your flow. If Your users (or users across Your company) are skilled enough to ensure it's actually the MSP certificate and not a DNS spoof which could enroll You to different MDM or not. Another option would be manually adding root CA of MSP used certificate into Android trusted root CA store with some secure delivery path prior to enrollment. My opinion would be to require this as certificates can be for free (Let's encrypt was successfully used with our users) and extra load of verification of where You're enrolling should not be Your business in MSP managed environment. HTH, M.
  9. Hello, Please contact customer care, this is nothing we can solve over forum and without logs. What comes to mind is that previous versions did not have MariaDB installation prevented and it caused issues "like" this. Thanks, M.
  10. Hello, To my knowledge there is no restriction of VPN used with EESA as EESA does not care for internet/intranet connection (now) and it's main point of interception is filesystem. HTH, M.
  11. Currently there is only anti-phishing protection it's settings are in EESA policy. Web control is in plan for future however is currently not available. You can post in EP feature requests if You have something specific in mind. HTH, M.
  12. If You mean RAM - no, AFAIK only total RAM can be displayed. If You mean disk space (SSD/internal flash etc...) 8.0 added this for iOS devices. 8.1 will probably add it for Android. Cloud MDM already has this implemented for both OSes.
  13. * Create static group named "MDM Device Enrollment Managers" * Move Agent installed next to MDM into this static group * Create permission set "MDM Device Enrollment Managers" ** In "Static Groups" add "MDM Enrollment Device Managers" Group You created in previous step. ** In functionality enable at least "Read" for "Groups & Computers" * Assign this permission set to user who You want to be able to see enrollment links. NOTE: This user will also require write rights to some other static group which can come from other permission set so he can actually create new devices via enrollment wizard. You want this static group different than "MDM Device Enrollment Managers" as user would have rights to reconfigure MDM and run stuff on server. Downside is users will be able to see configuration of server and MDM. I'm unsure there is any way around this. Possibly @MartinK would be able to think of a beter way around current limitations.
  14. Hello, Your user must be able to see MDM server Agent in EP console to have access to that MDM enrollment links. AFAIK that is the only protection there currently is in place. HTH, M.
  15. @ChrisC Hello, after testing addition to ABM via Apple Configurator 2 we found some quirks in process. * Device must have internet connectivity during erasure phase (You can't input it manually on device). For devices without data SIM this can be archieved by installation of WiFi profile (including valid authentication) via APC2. * Checkbox "Activate and complete enrollment" must be disabled in APC2. * Device must be assigned to MDM server on ABM side before any progress on device is made after reset. * MDM must synchronize with ABM before any progress on device after reset is made and after it's assigned to MDM on ABM server. This can be archieved by restarting MDM service and waiting 2 minutes. * URL configured in APC2 seems to be only used to preinstall certificates onto device. You may input any URL or empty field to skip this step and even though APC2 will output error in step directly following this one it's harmless. We will most likely document some parts or entire process and possibly look into improving ABM synchronization part where MDM restart is currently required to force sync. HTH, M.
×
×
  • Create New...