Jump to content

Mirek S.

ESET Staff
  • Posts

    137
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by Mirek S.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. * 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.
  9. 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.
  10. @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.
  11. The state could persist due to "currently used" certificate, essentially worst error is reported which might not be best idea for these cases. If You try to request configuration from MDM You should be able to see if there is issue with new certificate. New certificate should be applied on MDM HTTPS interface when all devices install new trust (newly applied certificate root CA). This process is required as we support self-signed certificates and process for using already trusted 3rd party certificates never got in (yet) as most customer use self signed certificates from console. Since newer versions of EESA (10.7+ IIRC) and for all iOS versions device certificate store should also be used for MDM HTTPS certificate validation, meaning using certificates signed by 3rd party certificate authorities and already trusted by devices (verisign, let's encrypt...) can be exchanged without default timeout of one month (as can be configured by policy). HTH, M.
  12. As an explanation why this protection state happens. * Apple decided to follow CA/B rules for browsers (which is quite good for security reasons) * We (ESET) have existing userbase and as we honor our customers previous installations and configurations have to work for some time. * Prefered action for this protecion state is to actually create new certificate either via webconsole or via 3rd party CA and setting it to MDM. Disabling notification via policy is there just for extreme reasons, like our implementation issues etc... * Since EP 8.0 some parts of validation are enforced even for Android, so disabling this in policy might not work for You. Valid flow is using correct certificate/chain.
  13. @Christian Stück Nothing is in stone yet, but it's the direction ESET is currently pushing forward. In any case if this happens there would be transitional period and a way to move devices from EP to EPC. @ChrisC I will update this thread once we are able to test and figure out how it should work. However it will likely require release. The ASM issue is different as device is already in Apple remote profile (ASM/ABM sync part is similar) - MDM knows it's serial number so it allows enrollment.
  14. Thanks, We will definitely checks this. Seems like information on our side is outdated and Apple now supports adding devices not purchased via ABM/ASM into ABM/ASM. This actually helps us as well as we have multiple devices not purchased via ABM not usable for ABM testing...
  15. Currently no, And as we now have cloud MDM, there is not much of chance this will ever happen with on premises version.
  16. Hello, I believe this is different case, can You elaborate a bit why You need to run Apple Configurator 2 on devices (for supervised mode) ? Also as far as I know it's impossible to add devices not bough via ABM into ABM. M.
  17. Hello, We currently do not support ASM, only ABM is supported. IIRC main reason was EP is device centric while ASM is user centric but I might be wrong on that one. M.
  18. Hello and sorry for late response. You actually have two issues there, 1. License fails to activate. 2. APNS fails to verify peer (Apple Push Notification Server) certificate so it refuses connection. Please contact support we will need more logs to identify reasons for this behaviour. Sorry for inconvenience, M.
  19. Hello, 1. ESET PROTECT 8 was tested with iPadOS Beta 14 without any issues. I will contact our documentation team about issue in docs. One issue with Apple devices we discovered they don't work well with IP based setups, so only DNS hostnames are officially supported. 2. 3rd party (implicitly trusted and preinstalled within device certificate store) certificate is always prefered for both Apple and Android. Self-signed certificates generated in EP are essentially a historical leftover as nowdays everyone can generate DNS certificate for free from Let's encrypt and possibly other providers. In explanation this is due to certificate exchange process where there is a risk of loosing device connectivity with self-signed certificates while there is lower risk with 3rd party (implicitly trusted) ones. Choose Your poison. 3. DDNS is really about endpoint devices and if they can cache DNS records correctly (in case of DDNS just for few minutes). In world of IPv6 I see little use for this technology, but You probably have Your reason. We never verified functionality wrt DDNS with Apple/Android devices as these could behave differently based on version (and it's a lot of versions to verify). So essentially it should work, but Your mileage might differ. HTH, M.
  20. Hello, We do not officially support user profiles. As for MDM logs, I see only errors on enrollment port (9980) which can be caused by browser terminating traffic or other issues. Important is mdm communication after enrollment - port 9981 (enrollment is essentially just file download over https). If enrollment doesn't work there might be other issue. We might be able to help if we have all the logs required and You are ok with running production server in not officially supported scenario please contact our customer care (with MDM trace severity and EESA application logs) I'm unsure what You mean by EMII. IMEI is accessible only for Android devices enrolled in Device Owner mode (applications are restricted by google and can't access real device identifiers) HTH, M.
  21. Hello, Android team is currently investigating this issue with self-signed certificates. If You use self-signed certificates (ESMC generated) please fill ticket with customer care so there is more data regarding this (we will need logs from phone and mdm certificate to speed up the process). Sorry for inconvenience, M.
  22. MDM HTTPS certificate should be created by ESMC server webconsole via Peer certificates > "Mobile Device Connector" wizzard or via 3rd party CAs as mentioned in mobile devices thread. Tomcat referenced certificate is "basic one", used by ESMC server. Due to 3rd party requirements MDM requires more strict certificate(s) to work correctly. HTH, M.
  23. Hello, Enrollment links are sent to EMSC server via Agent installed on same device as MDM is (and both MDM and Agent require correctly set connection to ESMC server). In case You installed MDM multiple times in history You also have to select correct MDM instance in web console. In case previous steps does not help please contact customer care. HTH, M.
  24. > Seems, that this worked. The task is marked as "successfull". But how can I see if it is really active? MDM should be activated when protection state "Not activated" is removed from device it's installed on. In reality MDM activation does not matter "that much" as it only affects module updates and EPNS wake up calls and does not eat license - the same way as ESMC server does. > And I only found that the eramdmcore is only listening on ipv6, netstat shows no process for 9980 on the ipv4. Is that configurable? Please contact customer care. All ports set during setup (by default 9980/9981 and other internal mentioned in docs) should listen on all interfaces. IIRC there were reports of this like issue if You installed MDM on *nix machine prior to installing IPv4 interfaces. Some were sorted by simple restart of MDM service. Please also note we have cloud MDM solution, which is much easier to manage. HTH, M.
  25. Hello, This is due to changes in ESMC since version 6.5 which was last released version of VAH and can be safely ignored. HTH, M.
×
×
  • Create New...