432 results found

1. Allow setting scope values when uploading a new Custom Configuration Profile via API

   When using the SimpleMDM portal to upload a new custom configuration profile, you are able to define a scope for the profile - targeted OS, min/max OS version, and Mac architecture.

   It would be useful to be able to define these values via the Create (POST) custom_configuration_profiles API [https://api.simplemdm.com/#create-4].

   10 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   2 comments  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

2. Extend the devices - list profiles API method to return ALL profiles that a device is assigned

   The list profiles method in the devices API endpoint only returns profiles that are directly assigned to the device; it would be very helpful to the data returned included all profiles assigned to that device, including profiles assigned through groups, etc, along with an attribute that identifies how the profile is assigned.

   •  

   17 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   1 comment  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

3. Sort the Scripts -> Jobs -> History tab by newest to oldest by default

   Right now, the sorting is by name (I think?) which is not useful. It would be great to show the most recently queued jobs in the history first by default.

   10 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   0 comments  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

4. Record administrator logins in Logs

   Currently, there is no visibility in the logs when an admin session is started from a login. We'd like to see log in and log out for at least "local" SimpleMDM accounts if not IdP initiated sessions as well, populated into the admin namespace. It would be helpful if the logs contained the account email, IP address they are logging in from, and the usual timestamp / "At" value. A user agent value would be a bonus but it's understandable if that's not available.

   18 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   0 comments  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

5. Auto-admin password complexity settings

   For the auto-admin password generation done by SimpleMDM, it'd be preferable to be able to manage the level of password complexity when the password is generated. Environments can have different password policy rules that all accounts, including MDM generated, need to abide by. The Dude abides.

   Password storage apps like 1Password and Keeper offer, at minimum, password length, use of numbers, and use of special characters. See attached.

   •  

   •  

   12 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   0 comments  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

6. Report on profile status - pending, installed, failed

   SimpleMDM currently only surfaces profile assignment in the main profiles UI. To see the status of a specific profile on a device an admin must navigate to a device record. What information isn't readily available is the status of a profile. Even if it's assigned to 100 devices, there's no way to tell how many of those devices the profile successfully installed.

   Specifically asking...
   - Add three columns to the view at /profiles in the UI - installed, pending, failed.
   - In the profiles and custom profiles API endpoints include data about these status as well.

   The major driver behind this feature request is compliance reporting. Although we may have MDM configured to do a certain thing, as a SimpleMDM customer there's no way to tell in a programmatic or at a glance way if that configuration profile was actually delivered. This will become even more important with DDM not making declaration data available locally. I want to know from a compliance standpoint if my endpoints are actually in good standing without having to poll them locally (or in addition to).

   SimpleMDM currently only surfaces profile assignment in the main profiles UI. To see the status of a specific profile on a device an admin must navigate to a device record. What information isn't readily available is the status of a profile. Even if it's assigned to 100 devices, there's no way to tell how many of those devices the profile successfully installed.

   Specifically asking...
   - Add three columns to the view at /profiles in the UI - installed, pending, failed.
   - In the profiles and custom profiles API endpoints include data about these status as well.

   The major driver behind… more

   10 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   0 comments  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

7. Device Groups API - add methods

   The Device Groups API does not have the following methods:
   create, update, remove/delete, it would be very helpful if this endpoint could have those methods added, along with various options such as:

   create: parameters "name" (required), "lock_screen_message" (optional), and "track_device_location" (optional, default False)

   update: parameters "name" (optional), "lock_screen_message" (optional), and "track_device_location" (optional)

   delete: parameters: "device_group_id"

   Also, the clone method does not currently take any parameters that would allow device group settings to be configured, it would be helpful if the clone method was updated to allow the use of these parameters:

   "name" (required), "lock_screen_message" (optional), and "track_device_location" (optional, default False)

   12 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   0 comments  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

8. Enrollment Setting - Unassign Profiles at Re-Enrollment

   We heavily utilize individually assigned profiles for Macs. There are also a few default profiles assigned via group. When a new out-of-box Mac is being enrolled for the first time only those default profiles are installed (around 5). Profiles are installed quickly and reliably. Later on during provisioning our configuration management tool handles installing other required per device profiles.

   However, when a Mac from stock is being re-enrolled to be used by another person, every previously assigned profile is installed at setup assistant. Since in my case those individually assigned profiles are usually per user, team, department, etc. and no longer pertain to the new person using the Mac, the device configuration is functionally incorrect. I'd prefer if on re-enrollment they weren't assigned at all. With a significant number of profiles, there's also no guarantee they will all be installed by the time the user hits the desktop, and since MDM has no concept of priority delivery, oftentimes those individually assigned per device profiles from the last user get installed before the default ones.

   The current workaround is to use a webhook to watch for lock or unenrolled events and use the API to programmatically unassign profiles. I'd prefer not to though. I'm specifically asking for a setting, globally or per enrollment, to unassign every profile except those assigned to a group at re-enrollment.

   We heavily utilize individually assigned profiles for Macs. There are also a few default profiles assigned via group. When a new out-of-box Mac is being enrolled for the first time only those default profiles are installed (around 5). Profiles are installed quickly and reliably. Later on during provisioning our configuration management tool handles installing other required per device profiles.

   However, when a Mac from stock is being re-enrolled to be used by another person, every previously assigned profile is installed at setup assistant. Since in my case those individually assigned profiles are usually per user, team, department, etc. and no… more

   8 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   0 comments  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

9. Improve API docs with examples for each endpoint

   SimpleMDM's API documentation (https://api.simplemdm.com/) is inconsistent in what information is included per endpoint. For example, https://api.simplemdm.com/#custom-configuration-profiles shows the response body for a GET call, but the POST (create) section has no usage information. It's up to the user to intuit from other endpoints the format in which those arguments should be.

   https://api.simplemdm.com/#custom-attributes shows how to set a value for a device, but not create a new custom attribute globally.

   We (the customer) end up making assumptions about API formats which are usually true, but only able to confirm through guessing. It would help to ensure the official docs are correct and up to date.

   I'm asking for two improvements...
   1.100% example code coverage for every endpoint and action (GET, PUT, PATCH, DELETE)
   2. Provide examples in multiple languages - shell, Python, Ruby, Go, JavaScript, and Swift.

   SimpleMDM's API documentation (https://api.simplemdm.com/) is inconsistent in what information is included per endpoint. For example, https://api.simplemdm.com/#custom-configuration-profiles shows the response body for a GET call, but the POST (create) section has no usage information. It's up to the user to intuit from other endpoints the format in which those arguments should be.

   https://api.simplemdm.com/#custom-attributes shows how to set a value for a device, but not create a new custom attribute globally.

   We (the customer) end up making assumptions about API formats which are usually true, but only able to confirm through guessing. It would help to ensure the official docs… more

   7 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   2 comments  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

10. Make the `app_usage_data` portion of Munki optional

    Having just confirmed with Eric and others in the Slack channel that SimpleMDM's Munki instance doesn't make use of the app_usage_data feature in Munki - would it be possible to create a toggle to turn it off?

    Additionally there are some global regions where tracking this kind of stuff falls foul of local privacy laws...

    ...and it's upset my privacy focused end users.

    Thanks in advance

    11 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

11. Support custom MDM commands

    I'd like to see SimpleMDM support sending custom MDM commands with arbitrary payloads. Advantages being...

    1. Customers don't have to wait for SimpleMDM to implement new commands to start testing. With WWDC coming up this is especially pressing because new commands and/or keys need to be tested quickly during the summer beta cycle for any chance at improvement.
    2. Possible to test beta/RSR updates by passing in the product key to a software update command.
    3. WS1 has this feature and please don't make me say anything nice about WS1.

    As an example, here's how WS1 implements it with the author using EnableRemoteDesktop. https://macops.ca/managing-screen-sharing-in-monterey-12.1/

    I'd like this to be available through the GUI and API. Thanks!

    I'd like to see SimpleMDM support sending custom MDM commands with arbitrary payloads. Advantages being...

    1. Customers don't have to wait for SimpleMDM to implement new commands to start testing. With WWDC coming up this is especially pressing because new commands and/or keys need to be tested quickly during the summer beta cycle for any chance at improvement.
    2. Possible to test beta/RSR updates by passing in the product key to a software update command.
    3. WS1 has this feature and please don't make me say anything nice about WS1.

    As an example, here's how WS1 implements it with the author using EnableRemoteDesktop. … more

    19 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

12. Implement Munki managed uninstalls

    The SimpleMDM Munki implementation does not currently support managing uninstalls of software as a "pure" deployment of Munki might. Please implement uninstall management.

    12 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

13. Allow setting device naming schemes per enrollment

    We use the device naming template under Settings -> General. This works great for our macOS and iOS devices that come in through manual enrollment and ADE as our template contains the serial number attribute, but fails when User Enrolled devices are named because that attribute isn't available. It would be useful to allow us to set a different device naming scheme per enrollment, or at least to set a backup or some sort of logic should one of the attributes be null.

    12 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

14. Implement "force password change when the user authenticates"

    As per https://support.apple.com/en-ca/guide/deployment/dep4d6a472a/web, Apple has an API for forcing a user password change. This is useful when updating password policy - passwords that met the old policy but no longer meet the new policy are not evaluated and forced to change. This setting, however, would make it so.

    6 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    1 comment  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

15. Allow devices to be marked as unmanaged

    Another idea to borrow from Jamf Pro. Please consider allowing SimpleMDM customers to mark devices as unmanaged in order to keep them for historical or data purposes without them actively being under management and NOT taking up a license. An unmanaged device would keep the same config, but not have the ability to interact with MDM moving forward. No profile installs, polling for device info, etc. It is a record stuck in time. Devices should be able to move freely between managed/unmanaged through the GUI and API.

    As it today, every device which exists in a SimpleMDM tenant takes up a license. No matter how long ago the device was enrolled, when it last checked in, etc. a license is still consumed. Though I understand the advantage on the PDQ side for billing and revenue purposes, it would be useful as a customer to be able to keep devices within SimpleMDM as unmanaged without having to pay for the corresponding license. As best I can tell, when a device in removed it's data is not also removed. I've tested this by removing a device and re-enrolling it. Immediately after re-enrollment the old data is still present, even before MDM has had a chance to report back. My theory is when a device is removed it's simply tagged/marked as removed, with all other associated data remaining in the database. If that's the case, it's a zero or neglible cost to allow customers to mark devices as unmanaged since the only difference is whether the device is visible and requesting regular MDM actions.

    The only other options are for customers to buy more licenses (probably what PDQ prefers) or run regular cleanup to remove old/stale/retired/archived devices. While MDM is not and should not be an inventory, there are common operational and compliance needs to keep MDM device records around for longer even for devices which aren't being managed. So tl;dr - Allow devices to be marked as managed and unmanaged.

    Another idea to borrow from Jamf Pro. Please consider allowing SimpleMDM customers to mark devices as unmanaged in order to keep them for historical or data purposes without them actively being under management and NOT taking up a license. An unmanaged device would keep the same config, but not have the ability to interact with MDM moving forward. No profile installs, polling for device info, etc. It is a record stuck in time. Devices should be able to move freely between managed/unmanaged through the GUI and API.

    As it today, every device which exists in a SimpleMDM tenant takes up… more

    4 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

16. Add Support for Munki Conditionals to SimpleMDM's Munki Implementation

    Munki includes the ability to set "conditionals" for items in specific manifests to provide granular controls over the installation or appearance of items.

    For example, if I have a multi-site organization, I can set a conditional on a NOPKG item that installs a printer so that the printer install NOPKG only shows up if the device user is connecting to Munki from a specific subnet. This allows me to refine the view of available self-service printers so that, for example, the printers available at Site A only show up if the user's local IP address matches the subnet at Site A. This results in me being able to pile all of my printers into a single Manifest/Assignment Group, and prevent users from seeing an overly polluted view of the printers available.

    Other uses for conditionals include defining installs as only taking place on portable computers (such as a VPN client).

    Please see the Munki documentation for Conditonals in Manifests at https://github.com/munki/munki/wiki/Conditional-Items for more information.

    Munki includes the ability to set "conditionals" for items in specific manifests to provide granular controls over the installation or appearance of items.

    For example, if I have a multi-site organization, I can set a conditional on a NOPKG item that installs a printer so that the printer install NOPKG only shows up if the device user is connecting to Munki from a specific subnet. This allows me to refine the view of available self-service printers so that, for example, the printers available at Site A only show up if the user's local IP address matches the subnet at Site… more

    10 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

17. Make logging more detailed for MDM commands

    While I appreciate how detailed SimpleMDM logs can be, especially with raw responses from MDM, sometimes they need to provide more detail. For example, when sending an OS update command the log only contains...

    "Log Details
    Full ID E7B0DBE9-A7C1-4EC8-8CB8-BFA4AB990C59
    Created At 2023-08-17 3:34 PM
    Namespace device
    Type os.update.idle
    Level info
    Device redacted
    UDID F405AA51-FF04-4B71-900F-9C09F0515398
    Serial Number redacted

    Metadata
    {
    "update_version": "13.5.1"
    }
    "

    With OS updates in particular, it's useful to know what mode was used as well. 'downloadonly', 'notifyonly', 'installasap', or 'forceupdate' are all options, but there's no associated data. For some basic commands like Bluetooth enable/disable there's not as much need, but for more complex commands with many possible settings, having that detail is useful. Even more so when a command is queue via API, with no confirmation the passed arguments worked.

    Please consider adding more data to logs.

    While I appreciate how detailed SimpleMDM logs can be, especially with raw responses from MDM, sometimes they need to provide more detail. For example, when sending an OS update command the log only contains...

    "Log Details
    Full ID E7B0DBE9-A7C1-4EC8-8CB8-BFA4AB990C59
    Created At 2023-08-17 3:34 PM
    Namespace device
    Type os.update.idle
    Level info
    Device redacted
    UDID F405AA51-FF04-4B71-900F-9C09F0515398
    Serial Number redacted

    Metadata
    {
    "update_version": "13.5.1"
    }
    "

    With OS updates in particular, it's useful to know what mode was used as well. 'downloadonly', 'notifyonly', 'installasap', or 'forceupdate' are all options, but there's no associated data. For some basic commands like… more

    5 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

18. add the ability to deploy individual files/folders to macOS

    I would like the ability to deploy individual files or folders to our Mac devices.

    Sometimes an app has an additional config file that needs deployed to make it work. We also use PDQ Connect in our environment, and that allows for us to can create packages that contain .msi, .exe, or PowerShell or CMD scripts, then also have the option to attach additional files to use in the package (see screenshot).

    Also, there are times where we may just need to send a file/folder to all devices. Something else besides an app, profile, or script. A simple option to deploy files would be a huge help.

    I would like the ability to deploy individual files or folders to our Mac devices.

    Sometimes an app has an additional config file that needs deployed to make it work. We also use PDQ Connect in our environment, and that allows for us to can create packages that contain .msi, .exe, or PowerShell or CMD scripts, then also have the option to attach additional files to use in the package (see screenshot).

    Also, there are times where we may just need to send a file/folder to all devices. Something else besides an app, profile, or script. A simple option to… more

    •  

    3 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    2 comments  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

19. Include a 'Devices' (or 'Assigned Devices') tab on a device group page

    When inspecting a device group, it would be very helpful and handy to have a tab to inspect/manage the devices associated with that group.
    Currently you have to go back to the Groups page, find the desired group, and then click on the number in the Assigned Devices column to look at the devices in that group and perform any management activities on them.

    •  

    7 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

20. Support SCIM provisioning and de-provisioning for admin accounts

    SCIM (System for Cross-domain Identity Management) is a REST/JSON protocol defined in RFC 7644 that allows identity providers to direct service providers to make account create, update, and delete actions. It is generally used to pre-provision access for new accounts and de-provision access for accounts that no longer require it.

    Please add support for SimpleMDM to work with the SCIM protocol for administrator accounts. A minimum implementation for our purposes would be to create administrator accounts using SCIM at the default permission level, and have the delete function revoke access on the given account. In a perfect world, the SCIM API would also be able to map users to defined roles to keep permissions low - this would apply both at creation time and updating existing admin accounts to use a different role than they currently are assigned.

    SCIM (System for Cross-domain Identity Management) is a REST/JSON protocol defined in RFC 7644 that allows identity providers to direct service providers to make account create, update, and delete actions. It is generally used to pre-provision access for new accounts and de-provision access for accounts that no longer require it.

    Please add support for SimpleMDM to work with the SCIM protocol for administrator accounts. A minimum implementation for our purposes would be to create administrator accounts using SCIM at the default permission level, and have the delete function revoke access on the given account. In a perfect world, the SCIM… more

    12 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close