Perguntas mais frequentes sobre a MAM e a proteção de aplicações

A gestão de aplicações móveis do Intune refere-se ao conjunto de funcionalidades de gestão do Intune que lhe permite publicar, emitir via push, configurar, proteger, monitorizar e atualizar aplicações móveis para os seus utilizadores.

A MAM protege os dados de uma empresa dentro da aplicação. Com a MAM sem inscrição (MAM-WE), pode gerir uma aplicação relacionada com o trabalho ou com a escola que contenha dados confidenciais na maioria dos dispositivos, incluindo os dispositivos pessoais, em cenários BYOD (Bring Your Own Device). Muitas aplicações de produtividade, como as aplicações do Microsoft Office, podem ser geridas pela MAM do Intune. Veja a lista oficial das aplicações geridas pelo Intune disponíveis para utilização pública.

A MAM do Intune suporta dois tipos de configurações:

• Intune MDM + MAM: os administradores de TI só podem gerir as aplicações através da MAM e das políticas de proteção de aplicações em dispositivos que estejam inscritos na gestão de dispositivos móveis do Intune (MDM). Para gerir aplicações que utilizem MDM + MAM, os clientes devem utilizar o centro de administração Microsoft Endpoint Manager.

• MAM sem inscrição de dispositivos: a MAM sem inscrição de dispositivos, ou MAM-WE, permite aos administradores de TI gerir as aplicações com a MAM e as políticas de proteção de aplicações nos dispositivos que não estejam inscritos na MDM do Intune. Isto significa que as aplicações podem ser geridas pelo Intune em dispositivos inscritos em fornecedores de EMM terceiros. Para gerir aplicações que utilizem o MAM-WE, os clientes devem utilizar o centro de administração Microsoft Endpoint Manager. Além disso, as aplicações podem ser geridas pelo Intune nos dispositivos inscritos em fornecedores de Gestão de Mobilidade da Empresa (EMM) de terceiros ou não inscritos numa MDM.

As políticas de proteção de aplicações são regras que asseguram que os dados de uma organização continuam seguros ou protegidos numa aplicação gerida. Uma política pode ser uma regra que é aplicada quando o utilizador tenta aceder ou mover dados "empresariais" ou um conjunto de ações que são proibidas ou monitorizadas quando um utilizador utiliza a aplicação.

Consulte as definições da política de proteção de aplicações android e as definições da política de proteção de aplicações iOS/iPadOS para obter informações detalhadas sobre cada definição de política de proteção de aplicações.

Se aplicar uma política MAM ao utilizador sem definir o estado do dispositivo, o utilizador obterá a política MAM tanto no dispositivo BYOD como no dispositivo gerido pelo Intune. Também pode aplicar uma política de MAM com base no estado gerido. Assim, quando criar uma política de proteção de aplicações, ao lado do Target para todos os tipos de aplicações, seleciona O. Em seguida, faça qualquer um dos seguintes:

• Aplique uma política de MAM menos rigorosa aos dispositivos geridos pela Intune e aplique uma política de MAM mais restritiva a dispositivos não matriculados com MDM.
• Aplique uma política igualmente rigorosa de MAM a dispositivos geridos intune como dispositivos geridos pela 3ª parte.
• Aplicar uma política de MAM apenas para dispositivos não enrolados.

Para obter mais informações, consulte Como monitorizar as políticas de proteção de aplicações.

Qualquer aplicação que tenha sido integrada com o SDK da Aplicação Intune ou encapsulada pela Ferramenta de Encapsulamento de Aplicações do Intune pode ser gerida com as políticas de proteção de aplicações do Intune. Veja a lista oficial das aplicações geridas pelo Intune disponíveis para utilização pública.

• O utilizador final deve ter uma conta Azure Ative Directory (Azure AD). Veja Adicionar utilizadores e conceder permissões administrativas no Intune para saber como criar utilizadores do Intune no Azure Active Directory.

• O utilizador final tem de ter uma licença para o Microsoft Intune atribuída à conta do Azure Active Directory dele. Veja Gerir licenças do Intune para saber como atribuir licenças do Intune aos utilizadores finais.

• O utilizador final tem de pertencer a um grupo de segurança visado por uma política de proteção de aplicações. A mesma política de proteção de aplicações tem de abranger a aplicação específica em utilização. As políticas de proteção de aplicações podem ser criadas e implementadas no centro de administração Microsoft Endpoint Manager. Atualmente, os grupos de segurança podem ser criadosno centro de administração do Microsoft 365 .

• O utilizador final deve inscrever-se na aplicação utilizando a sua conta Azure AD.

A equipa de desenvolvimento intune SDK testa e mantém suporte para aplicações construídas com as plataformas nativas Android, iOS/iPadOS (Obj-C, Swift), Xamarin e Xamarin.Forms. Embora alguns clientes tenham tido sucesso com a integração do Intune SDK com outras plataformas, como React Native e NativeScript, não fornecemos orientações explícitas ou plugins para desenvolvedores de aplicações usando qualquer outra coisa que não as nossas plataformas suportadas.

A Aplicação Intune SDK pode utilizar a Biblioteca de Autenticação da Microsoft para os seus cenários de autenticação e lançamento condicional. Conta ainda com a MSAL para registar a identidade do utilizador com o serviço MAM para gestão sem cenários de inscrição de dispositivos.

• O utilizador final deve ter a Outlook aplicação móvel instalada no seu dispositivo.

• O utilizador final deve ter uma caixa de correio Microsoft 365 Exchange Online e uma licença ligada à sua conta Azure Ative Directory.

  Nota

  Atualmente, a aplicação Outlook para dispositivos móveis só suporta a Proteção de Aplicações do Intune para o Microsoft Exchange Online e o Exchange Server com autenticação moderna híbrida e não suporta o Exchange no Office 365 Dedicated.

• O utilizador final deve ter uma licença para Microsoft 365 Apps para Pequenas e Médias Empresas ou empresa ligada à sua conta Azure Ative Directory. A subscrição tem de incluir as aplicações do Office para dispositivos móveis e pode incluir uma conta de armazenamento na cloud com o OneDrive para Empresas. Microsoft 365 licenças podem ser atribuídas no centro de administração do Microsoft 365 seguindo estas instruções.

• O utilizador final deve ter uma localização gerida configurada utilizando a poupança granular como funcionalidade sob a definição da política de proteção de aplicações "Guardar cópias de dados org". Por exemplo, se a localização gerida for OneDrive, a aplicação OneDrive deve ser configurada no Word, Excel ou PowerPoint app do utilizador final.

• Se a localização gerida for o OneDrive, a aplicação terá de ser visada pela política de proteção de aplicações implementada para o utilizador final.

  Nota

  Atualmente, as aplicações do Office para dispositivos móveis só suportam o SharePoint Online e não o SharePoint no local.

O Intune marca todos os dados na aplicação como "empresariais" ou "pessoais". Os dados são considerados "empresariais" quando provêm de uma localização empresarial. Para as aplicações do Office, o Intune considera as seguintes localizações como localizações empresariais: e-mail (Exchange) ou armazenamento da cloud (aplicação OneDrive com uma conta do OneDrive para Empresas).

Veja os requisitos de licença do Skype para Empresas. Para configurações híbridas e on-prem Skype para Empresas (SfB), consulte Hybrid Modern Auth for SfB e Exchange vai GA e Modern Auth para SfB OnPrem com Ad AD,respectivamente.

O suporte de identidades múltiplas é a capacidade do SDK da Aplicação Intune de só aplicar as políticas de proteção de aplicações à conta profissional ou escolar que tenha sessão iniciada na aplicação. Se uma conta pessoal tiver sessão iniciada na aplicação, os dados permanecem inalterados.

O suporte de identidades múltiplas permite que as aplicações com públicos "empresariais" e consumidores (por exemplo, as aplicações do Office) sejam lançadas publicamente com as funcionalidades de proteção de aplicações do Intune para as contas "empresariais".

Uma vez que o Outlook tem uma vista combinada dos e-mails pessoais e "empresariais", a aplicação Outlook pede o PIN do Intune quando é iniciada.

O Número de Identificação Pessoal (PIN) é um código de acesso utilizado para verificar que o utilizador certo está a aceder aos dados da organização numa aplicação.

O Intune só pede ao utilizador para introduzir o PIN da aplicação quando o mesmo quiser aceder aos dados "empresariais". Em aplicações de identidades múltiplas como o Word/Excel/PowerPoint, é pedido ao utilizador que introduza o PIN ao tentar abrir um documento ou ficheiro "empresarial". Em aplicações de identidade única, como as aplicações de linha de negócio geridas com a Ferramenta de Encapsulamento de Aplicações do Intune, o PIN é pedido no início, uma vez que o SDK da Aplicação Intune reconhece que a experiência do utilizador na aplicação é sempre "empresarial".

O administrador de TI pode configurar a definição“Reverificar os requisitos de acesso após (minutos)” da política de proteção de aplicações do Intune na consola de administração do Intune. Esta definição especifica o período de tempo antes da verificação dos requisitos de acesso no dispositivo e de uma nova apresentação do ecrã de PIN da aplicação. Contudo, os detalhes importantes sobre o PIN que afetam a frequência de solicitação do utilizador incluem:

• O PIN é partilhado entre aplicações da mesma editora para melhorar a usabilidade: No iOS/iPadOS, uma aplicação PIN é partilhada entre todas as aplicações da mesma editora de aplicações. No Android, um PIN da aplicação é partilhado entre todas as aplicações.
• O comportamento "Reverificar os requisitos de acesso após (minutos)" depois de um reinício de dispositivo: um "temporizador do PIN" controla o número de minutos de inatividade que determina quando mostrar novamente o PIN da aplicação do Intune. No iOS/iPadOS, o temporizador PIN não é afetado pelo reboot do dispositivo. Assim, o reinício do dispositivo não tem qualquer efeito no número de minutos que o utilizador esteve inativo a partir de uma aplicação iOS/iPadOS com a política Dot. No Android, o temporizador do PIN é reposto ao reiniciar o dispositivo. Como tal, é provável que as aplicações Android com a política de PIN do Intune peçam um PIN da aplicação, independentemente do valor definido na opção "Reverificar os requisitos de acesso após (minutos)" após reiniciar o dispositivo.
• A natureza flexível do temporizador associado ao PIN: após introduzir um PIN para aceder a uma aplicação (aplicação A) e esta sair de primeiro plano (foco de introdução principal) no dispositivo, o temporizador deste PIN é reposto. Não será pedido nenhum PIN às aplicações (aplicação B) que partilhem este PIN, uma vez que o temporizador foi reposto. O pedido aparecerá novamente depois de o valor “Reverificar os requisitos de acesso após (minutos)” ter sido atingido.

No caso dos dispositivos iOS/iPadOS, mesmo que o PIN seja partilhado entre aplicações de diferentes editoras, a solicitação voltará a aparecer quando o recheck os requisitos de acesso após (minutos) o valor for novamente cumprido para a app que não é o principal foco de entrada. Por exemplo, um utilizador tem a aplicação A do publicador X e a aplicação B do publicador Y e essas duas aplicações partilham o mesmo PIN. O utilizador está concentrado na aplicação A (primeiro plano) e a aplicação B está minimizada. O PIN seria necessário depois de o valor Reverificar os requisitos de acesso após (minutos) ser alcançado e de o utilizador mudar para a aplicação B.

O PIN Intune funciona com base num temporizador baseado em inatividade (o valor de 'Rever os requisitos de acesso após (minutos)»). Como tal, os pedidos de PIN do Intune são apresentados de forma independente dos pedidos de PIN de aplicação incorporados para o Outlook e OneDrive, que normalmente estão associados à inicialização da aplicação por predefinição. Se o utilizador receber ambos os pedidos de PIN ao mesmo tempo, o comportamento esperado deverá ser o de que o PIN do Intune tem precedência.

O PIN serve para garantir que só o utilizador correto consegue aceder aos dados da respetiva organização na aplicação. Por conseguinte, o utilizador final tem de iniciar sessão com a conta profissional ou escolar para poder definir ou repor o PIN da aplicação Intune. Esta autenticação é processada pelo Azure Active Directory através de uma troca de tokens segura e não é revelada ao SDK da Aplicação Intune. No que diz respeito à segurança, a melhor forma de proteger os seus dados profissionais ou escolares é encriptá-los. A encriptação não está relacionada com o PIN da aplicação, mas é a própria política de proteção da aplicação.

Como parte da política de PIN da aplicação, o administrador de TI pode definir o número máximo de vezes que um utilizador pode tentar autenticar o respetivo PIN antes de bloquear a aplicação. Após esgotar o número de tentativas, o SDK da Aplicação Intune pode eliminar os dados "empresariais" na aplicação.

Atualmente, o MAM (no iOS/iPadOS) permite que PIN de nível de aplicação com caracteres alfanuméricos e especiais (chamado 'código de acesso') que requer a participação de aplicações (isto é, WXP, Outlook, Navegador Gerido, Yammer) integre o SDK app intune para iOS/iPadOS. Caso contrário, as definições do código de acesso não são impostas corretamente nas aplicações visadas. Esta foi uma funcionalidade lançada no Intune SDK para iOS/iPadOS v. 7.1.12.

Para suportar esta funcionalidade e garantir a retrocompatibilidade com as versões anteriores do Intune SDK para iOS/iPadOS, todas as PINs (ou numéricas ou códigos de acesso) em 7.1.12+ são manuseadas separadamente do PIN numérico em versões anteriores do SDK. Portanto, se um dispositivo tiver aplicações com Intune SDK para versões iOS/iPadOS antes de 7.1.12 E depois de 7.1.12 da mesma editora, terão de configurar dois PINs.

Dito isto, os dois PINs (para cada app) não estão de forma alguma relacionados, ou seja, devem aderir à política de proteção de aplicações que é aplicada à app. Como tal, só se as aplicações A e B tiverem as mesmas políticas aplicadas (no que respeita ao PIN) é que o utilizador poderá configurar o mesmo PIN duas vezes.

Este comportamento é específico do PIN nas aplicações iOS/iPadOS que são ativadas com a Intune Mobile App Management. Com o passar do tempo, à medida que as aplicações adotam versões posteriores do Intune SDK para iOS/iPadOS, ter de definir um PIN duas vezes em apps da mesma editora torna-se menos um problema. Veja a nota abaixo para obter um exemplo.

Os administradores de TI podem implementar uma política de proteção de aplicações que exija a encriptação dos dados da aplicação. Como parte da política, o administrador de TI também pode especificar a altura em que os conteúdos são encriptados.

Consulte as definições da política de proteção de aplicações android e as definições da política de proteção de aplicações iOS/iPadOS para obter informações detalhadas sobre a definição da política de proteção de aplicações de encriptação.

Só os dados marcados como "empresariais" são encriptados de acordo com a política de proteção de aplicações do administrador de TI. Os dados são considerados "empresariais" quando provêm de uma localização empresarial. Para as aplicações do Office, o Intune considera as seguintes localizações como localizações empresariais: e-mail (Exchange) ou armazenamento da cloud (aplicação OneDrive com uma conta do OneDrive para Empresas). Para aplicações de linha de negócio geridas com a Ferramenta de Encapsulamento de Aplicações do Intune, todos os dados da aplicação são considerados "empresariais".

O Intune pode eliminar os dados da aplicação de três formas diferentes: eliminação total do dispositivo, eliminação seletiva para MDM e eliminação seletiva MAM. Para obter mais informações sobre a limpeza remota da MDM, veja Remove devices by using wipe or retire (Remover dispositivos através da limpeza ou extinção). Para obter mais informações sobre a limpeza seletiva através da MAM, veja a ação Extinguir e Como eliminar apenas dados empresariais de aplicações.

A limpeza elimina todas as definições e dados dos utilizadores do dispositivo ao restaurar o dispositivo para as predefinições de fábrica. O dispositivo é removido do Intune.

Veja a secção Remover dispositivos – extinguir para ler mais sobre a remoção dos dados da empresa.

A eliminação seletiva para MAM simplesmente remove os dados da aplicação da empresa de uma aplicação. O pedido é iniciado através do centro de administração Microsoft Endpoint Manager. Para saber como iniciar um pedido de eliminação, veja o artigo Como eliminar apenas os dados empresariais das aplicações.

Se o utilizador estiver a utilizar a aplicação quando a eliminação seletiva for iniciada, o SDK da Aplicação Intune verifica a existência de pedidos de eliminação seletiva a cada 30 minutos a partir do serviço MAM do Intune. Também verifica a existência de pedidos de eliminação seletiva quando o utilizador inicia a aplicação pela primeira vez e inicia sessão com a conta profissional ou escolar.

A proteção de aplicações do Intune depende da identidade do utilizador para ser consistente entre a aplicação e o SDK da Aplicação Intune. A única forma de o garantir é através da autenticação moderna. Existem cenários onde aplicações podem funcionar com uma configuração no local, mas não é garantido e nem consistente.

Sim! O administrador de TI pode implementar e definir a política de proteção de aplicações para a aplicação Microsoft Edge. O administrador de TI pode exigir que todas as ligações web em aplicações geridas pelo Intune sejam abertas usando a aplicação Microsoft Edge.

Uma grande parte da funcionalidade de proteção de aplicações está incorporada na aplicação Portal da Empresa. A inscrição no dispositivo não é necessária, mesmo que a aplicação Portal da Empresa seja sempre necessária. Para a MAM-WE, o utilizador final apenas precisa de ter a aplicação Portal da Empresa instalada no dispositivo.

As políticas de proteção de aplicações do Intune para acesso serão aplicadas numa ordem específica nos dispositivos dos utilizadores finais à medida que tentam aceder a uma aplicação direcionada a partir da respetiva conta empresarial. Em geral, um bloqueio teria precedência, seguido de um aviso que pode ser dispensado. Por exemplo, se aplicável ao utilizador/aplicação específico, uma definição mínima de versão de patch do Android que avisa um utilizador para atualizar o patch será aplicada após a definição mínima de versão de patch do Android bloquear o acesso do utilizador. Portanto, no cenário em que o administrador de TI configura a versão mínima de patch do Android para 2018-03-01 e a versão mínima de patch do Android (apenas Aviso) para 2018-02-01, embora o dispositivo que tentava aceder à aplicação tivesse a versão de patch 2018-01-01, o utilizador final seria bloqueado com base na definição mais restrita de versão mínima de patch do Android que resulta num bloqueio do acesso.

Ao lidar com diferentes tipos de definições, um requisito de versão de aplicação teria precedência, seguido do requisito de versão de sistema operativo Android e do requisito de versão de patch do Android. Em seguida, são verificados os avisos de todos os tipos de definições na mesma ordem.

Uma nova determinação do serviço Google Play será reportada ao administrador de TI num intervalo determinado pelo serviço Intune. A frequência com que a chamada de serviço é feita é acelerada devido à carga, pelo que este valor é mantido internamente e não é configurável. Qualquer ação configurada de TI para a definição de Atestado Google SafetyNet será tomada com base no último resultado reportado ao serviço Intune no momento do lançamento condicional. Se não houver dados, o acesso será permitido dependendo de nenhuma outra falha condicional de verificação de lançamento, e o Google Play Service "ida e volta" para determinar os resultados da estação de atestação começará no backend e solicitará ao utilizador assíncronamente se o dispositivo tiver falhado. Se houver dados antigos, o acesso será bloqueado ou permitido dependendo do último resultado reportado, e da mesma forma, começará uma "ida e volta" do Google Play Service para determinar os resultados do atestado e solicitará ao utilizador assíncronamente se o dispositivo tiver falhado.

As instruções sobre como fazê-lo variam ligeiramente por dispositivo. O processo geral envolve ir à Google Play Store, clicando depois nas minhas aplicações & jogos, clicando no resultado da última aplicação que o levará ao menu Play Protect. Certifique-se de que o dispositivo de verificação para ameaças de segurança está ligado.

Intune aproveita o Google Play Protect SafetyNet APIs para adicionar às nossas verificações de deteção de raiz existentes para dispositivos não enrolados. A Google desenvolveu e manteve este conjunto de API para que as aplicações android adotassem caso não quisessem que as suas apps fossem executadas em dispositivos enraizados. A aplicação Android Pay incorporou esta, por exemplo. Embora a Google não partilhe publicamente a totalidade das verificações de deteção de raiz que ocorrem, esperamos que estas APIs detetem utilizadores que tenham enraizado os seus dispositivos. Estes utilizadores podem então ser impedidos de aceder, ou as suas contas corporativas eliminadas das suas aplicações habilitadas para a política. 'Verifique a integridade básica' diz-lhe sobre a integridade geral do dispositivo. Dispositivos enraizados, emuladores, dispositivos virtuais e dispositivos com sinais de adulteração falham na integridade básica. 'Verifique a integridade básica & dispositivos certificados' diz-lhe sobre a compatibilidade do dispositivo com os serviços da Google. Apenas dispositivos não modificados que tenham sido certificados pela Google podem passar esta verificação. Os dispositivos que falharão incluem o seguinte:

• Dispositivos que falham integridade básica
• Dispositivos com um bootloader desbloqueado
• Dispositivos com uma imagem/ROM do sistema personalizado
• Dispositivos para os quais o fabricante não se candidatou, ou passou, certificação google
• Dispositivos com uma imagem do sistema construído diretamente a partir dos ficheiros de origem do Programa Android Open Source
• Dispositivos com uma imagem do sistema de pré-visualização beta/desenvolvedor

Consulte a documentação da Google no Atesstation SafetyNet para obter detalhes técnicos.

As verificações de API da SafetyNet do Google Play Protect exigem que o utilizador final esteja online, pelo menos durante o período em que a "ida e volta" para determinar os resultados do atestado é executada. Se o utilizador final estiver offline, a administração de TI pode ainda esperar que um resultado seja aplicado a partir da definição de "dispositivos de jailbroken/rooted". Dito isto, se o utilizador final estiver offline por muito tempo, o valor do "período de graça offline" entra em jogo, e todo o acesso ao trabalho ou dados escolares é bloqueado uma vez que o valor do temporizador é atingido, até que o acesso à rede esteja disponível. Ligar ambas as definições permite uma abordagem em camadas para manter os dispositivos finais saudáveis, o que é importante quando os utilizadores finais acedem ao trabalho ou aos dados escolares em dispositivos móveis.

Tanto o "atestado dispositivo SafetyNet" como o "Threat scan on apps" exigem que a versão determinada da Google dos Serviços de Jogo da Google funcione corretamente. Uma vez que estas são configurações que caem na área de segurança, o utilizador final será bloqueado se tiver sido alvo destas definições e não estiver a cumprir a versão adequada dos Serviços google Play ou não tiver acesso aos Serviços de Jogo da Google.

As políticas de proteção de aplicações do Intune permitem o controlo sobre o acesso da aplicação apenas ao utilizador licenciado do Intune. Uma das formas de controlar o acesso à aplicação é exigir o Touch ID ou o Face ID da Apple nos dispositivos suportados. O Intune implementa um comportamento em que se houver qualquer alteração à base de dados biométricos do dispositivo, o Intune pede ao utilizador um PIN quando atingir o valor do tempo limite de inatividade seguinte. As alterações a dados biométricos incluem a adição ou remoção de uma impressão digital ou de um rosto. Se o utilizador do Intune não tiver um PIN definido, este é direcionado para configurar um PIN do Intune.

A intenção é continuar a manter os dados da sua organização na aplicação em segurança e protegidos ao nível da aplicação. Esta funcionalidade está disponível apenas para iOS/iPadOS, e requer a participação de aplicações que integram o Intune APP SDK para iOS/iPadOS, versão 9.0.1 ou posterior. Precisa da integração do SDK para que o comportamento possa ser imposto nas aplicações de destino. Esta integração decorre de forma gradual e está dependente das equipas específicas da aplicação. Algumas aplicações participantes incluem: WXP, Outlook, Managed Browser e Yammer.

A política de proteção de aplicações do Intune não consegue controlar a extensão de partilha do iOS se o dispositivo não for gerido. Por isso, o Intune encripta os dados "empresariais" antes de estes serem partilhados fora da aplicação. Para o confirmar, pode tentar abrir o ficheiro "empresarial" fora da aplicação gerida. O ficheiro deve estar encriptado e não deve ser possível abri-lo fora da aplicação gerida.

As políticas de proteção de aplicações do Intune para acesso serão aplicadas numa ordem específica nos dispositivos dos utilizadores finais à medida que tentam aceder a uma aplicação direcionada a partir da respetiva conta empresarial. Em geral, uma limpeza teria precedência, seguida de um bloqueio e de um aviso que pode ser dispensado. Por exemplo, se aplicável ao utilizador/app específico, uma definição mínima do sistema operativo iOS/iPadOS que avisa um utilizador para atualizar a sua versão iOS/iPadOS será aplicada após a definição mínima do sistema operativo iOS/iPadOS que bloqueia o acesso do utilizador. Assim, no cenário em que o administrador de TI configura o sistema operativo min iOS/iPadOS para 11.0.0.0 e o sistema operativo min iOS/iPadOS (apenas aviso) para 11.1.0.0, enquanto o dispositivo que tentava aceder à aplicação se encontrava no iOS/iPadOS 10, o utilizador final seria bloqueado com base na definição mais restritiva para a versão do sistema operativo Min iOS/iPadOS, que resulta num acesso bloqueado.

Ao lidar com diferentes tipos de configurações, um requisito de versão SDK da Aplicação Intune teria precedência, em seguida, um requisito de versão de aplicação, seguido do requisito de versão do sistema operativo iOS/iPadOS. Em seguida, são verificados os avisos de todos os tipos de definições na mesma ordem. Recomendamos que o requisito de versão do SDK da Aplicação Intune só seja configurado após receber orientações sobre cenários de bloqueio essenciais por parte da equipa de produto do Intune.

Ver também

• Implementar Intune
• Criar um plano de lançamento
• Definições de políticas de gestão de aplicações móveis para Android no Microsoft Intune
• Definições de política de gestão de aplicativos móveis iOS/iPadOS
• Atualização da política de proteção de aplicações
• Validar as políticas de proteção de aplicações
• Adicionar políticas de configuração da aplicação para aplicações geridas sem inscrição de dispositivos
• Como obter apoio em Microsoft Endpoint Manager