Mirek S.
-
Posts
143 -
Joined
-
Last visited
-
Days Won
2
Posts posted by Mirek S.
-
-
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.
-
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.
-
> 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.
-
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.
-
Hello,
We are aware of this issue, please contact support for HF. (SR had to be pushed out due to APNS deprecation in november 2020)
Sorry for the inconvenience.
M.
-
Hello,
AdminConnector: Connected: false
MDM requires Agent is installed on same system
HTH,
M.
-
Hello,
It seems like You have changed server CA. (that is server certificate validation fails)
In such case You must also reconfigure MDM like You did with Agents (via MDM policy). For such change to apply Agent next to MDM must be able to connect to ESMC server. You might need to manually restart MDM after changing CA.
HTH,
M.
-
Connection parameters (and other configuration options) are set during installation, so these settings were not changed from initial setup. Once policy is applied it stays in configuration (some of our products have a feature that policy removal restores original settings, MDM does not have this feature).
ERA/ESMC will not try to do something behind scenes without user approval, so no worries.
Actually we will create improvement for newer versions so some connection settings are taken from Agent as it does not make sense/is misleading to configure this separately.
-
Hello,
First create MDM policy on device which has MDM installed
And edit connection list same as You would with Agent
HTH,
M.
-
Well, if you're changing subnet and Agents are deployed in a way they contact server via IP adress, You will need to reconfigure both Agents and MDM (as I previously pointed out MDM also has server connection settings in it's policy).
If you're using IP address for MDM device endpoint You will loose connectivity from all enrolled devices and will need to re-enroll those.
if You're using DNS names and DNS entires are correctly updated (or traffic is forwarded from some other endpoint) in both cases subnet change should work without issues.
As for last connection time, I believe some data related to devices are sent over Agent next to MDM, with last connection time being one of those (which means Agent is configured properly, however MDM can't connect to server as noted in OP)
HTH,
M.
-
Hello,
I guess we would need logs (in this case those in proxy directory) in trace severity. However as far as I'm aware MDM should not care where server is - MDM only cares about device endpoint which must remain the same - so this is likely connectivity/firewall issue.
Some data are sent/received over Agent installed next to MDM. Device data are sent over MDM proxy component (for which connection can be configured in MDM policy.
HTH,
M.
-
Hello,
The main benefit of ABM is administrators don't need to touch device at all - it's enrolled into MDM during it's first setup (or after factory reset) based on information Administrators configure in ABM portal and MDM policy.
From ESET MDM point of view I think we only support Find (in Apple terminology it's lost mode) and supervised restrictions.
There is some guide on our side as well.
Generally its also possible to setup device into supervised mode by Apple Configurator however we currently don't support this as there was no demand from customers.
HTH,
M.
-
Hello,
For iOS Find device has to be in supervised state, with current implementation it's only possible via ABM program (Apple Business Manager). Some device commands and policies (as marked in policy editor) are only available in such state.
HTH,
M.
-
Hello,
I wouldn't currently recommend using "Update ESET products" (which is just software installation task) for deployments where EESA is installed over Google play store.
Currently this breaks auto-update which should happen over Google play store based on device settings (so You will be stuck with manually updating all phones each time EESA version is released). Web/Repository versions of EESA requires user to manually update unless it's installed in Device Owner mode.
In Your case it would be better to contact phone user and check why EESA isn't auto-upgraded. As for why task failed, we would likely need to see EESA and MDM logs, so please contact Your local customer care.
HTH,
M.
-
Please provide version of configuration (CE2) module server has and browser You're using.
Could be some faulty version. Please also try in a different browser.
I assume in EP this screen works correctly?
-
Or login with user which actually has rights to access database.
Note that windows authentication for MSSQL also requires special upgrade procedure (user performing upgrade should be same as user who installed product, which might be ... difficult)
HTH,
M
-
It just seem like invalid link on partner list. Certificate is issued to eset.ro (not nod32.ro) while both DNS entires lead to same IP.
-
Hello,
Device ID in MDM database is pseudorandom due to google privacy policy (unless device is enrolled in Device Owner mode). To remove device from MDM run stop managing task wait a few minutes (due to replication), EESA should be uninstalled if device still has connectivity. It should be safe then to remove device from ESMC console. Devices which receive stop managing task have DeEnrollmentFlag set to 1 in Device table (I believe since 7.0 version) if there's a quirk and it's not removed automatically.
HTH,
M.
-
Hello,
There is an improvement tracked for this, however I can't say if it will be next released version.
M.
-
Hello,
Apple APNS endpoint has this chain
0 s:/C=US/ST=California/L=Cupertino/O=Apple Inc./CN=gateway.push.apple.com
i:/C=US/O=Entrust, Inc./OU=See www.entrust.net/legal-terms/OU=(c) 2012 Entrust, Inc. - for authorized use only/CN=Entrust Certification Authority - L1K
1 s:/C=US/O=Entrust, Inc./OU=See www.entrust.net/legal-terms/OU=(c) 2012 Entrust, Inc. - for authorized use only/CN=Entrust Certification Authority - L1K
i:/O=Entrust.net/OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.)/OU=(c) 1999 Entrust.net Limited/CN=Entrust.net Certification Authority (2048)So required root CA is "Entrust.net Certification Authority (2048)" - this however might vary on Your geolocation. You might test this by openssl - "openssl s_client -connect gateway.push.apple.com:2195"
Root CA must be installed into system certificate store, MDM does not use CA machinery built into ESMC.
HTH,
M.
-
Hello,
Currently there is only workaround. You will have to decode QR code provided by WebConsole, add line into json
"android.app.extra.PROVISIONING_LEAVE_ALL_SYSTEM_APPS_ENABLED": "true"
and encode into QR code again. Google by default disables system application with DO enrollment.
HTH,
M.
-
Hello,
Short answer: Please add root CA of your 3rd party certificate into pkcs#12 which is configured as HTTPS certificate. See for example this thread.
Long answer: Certificates provided by 3rd party certification authorities (usually) don't contain root CA as trust is established by system certificate store and certificate and chain provided by HTTPS server. We require root CA in configured pkcs#12 as we establish MDM - device trust during device enrollment - we install root CA onto device. In our wording we note chain even if - only - root CA is missing (as it's impossible to determine whenever chain is complete without root CA, even thought it's not technically correct).
HTH,
M.
-
Hello,
Please create customer care ticket from mentioned device - it should include device logs to help android developers to determine what is wrong. Devices should connect every ~half an hour to check with MDM.
HTH,
M.
-
Hello,
I would not recommend using ODBC driver newer than 5.3.11.
Other than incompatibilities later MySQL ODBC drivers/client library also switched to unconditional use of openssl instead of internal TLS implementation they used to have and in some cases this triggers startup clashes of openssl initialization where MDM requires some setup and MySQL actually uses different one causing runtime issues.
HTH,
M.
MDM and weak certificate
in ESET PROTECT On-prem (Remote Management)
Posted · Edited by Mirek S.
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.