¶ 6. Integrations
Aplicação: Portal Nomid MDM
Documento: V1.2.0
Última atualização: 02/07/2026
Responsável editorial: Documentação Nomid MDM
Última revisão editorial: 02/07/2026
Idioma editorial: pt-BR
O módulo Integrations conecta o Nomid MDM a serviços externos usados para provisionamento, autenticação e automação, como Android Enterprise, Zero-touch Enrollment e SSO.
Importante: Integrações normalmente exigem credenciais administrativas em serviços externos. Faça mudanças apenas com autorização e plano de validação.
Para a configuração inicial, siga Primeiros 3 passos. Antes de alterar vínculos Google, consulte Google Workspace e Android fully managed e, quando a organização não possuir Workspace, o guia de Cloud Identity.
¶ Visão geral
¶ Integrações
A tela inicial de integrações disponíveis na empresa.
Esta área é usada para visualizar quais integrações estão configuradas ou disponíveis, como Android Enterprise, Zero-touch e SSO.
¶ Elementos da tela
- Cards de integração: mostram serviços externos conectáveis ao Nomid.
- Status: indica integração ativa, pendente ou não configurada.
- Ações: abrem configuração, autorização ou revisão.
- Impacto operacional: integrações habilitam provisionamento, autenticação e automação do ambiente.
¶ Aplicação na operação
- Acesse Integrations, confira o status de cada card e entre na integração desejada. Revise integrações quando provisionamento, login ou distribuição de apps apresentar falha.
¶ Android Enterprise
¶ Tela de Android Enterprise
¶ Resultado das seleções e configurações
- Criar vínculo: conecta a empresa ao Android Enterprise e habilita gerenciamento Android/Managed Google Play.
- Revisar vínculo: confirma Enterprise ID, conta e organização antes de provisionar.
- Reconectar: corrige autorização expirada ou alteração de conta, exigindo validação posterior.
- Remover vínculo: pode interromper enrollment, apps gerenciados e políticas Android.
- Vínculo incorreto: pode associar dispositivos ou apps ao ambiente Google errado.
A tela da integração Android Enterprise.
Esta área é usada para verificar vínculo da empresa com o Android Enterprise, base necessária para políticas Android, Managed Google Play e gerenciamento de dispositivos.
¶ Elementos da tela
- Vínculo Android Enterprise: conecta a empresa Nomid ao gerenciamento Android corporativo.
- Enterprise ID: identifica o ambiente Android Enterprise vinculado.
- Status do bind: mostra se a integração está pronta para provisionamento.
- Ações de gerenciamento: permitem iniciar, revisar ou remover vínculos conforme permissão.
- Impacto: sem esse vínculo, provisionamento e políticas Android não funcionam corretamente.
¶ Pré-requisitos e validação
- Mantenha acesso administrativo à conta Google usada no vínculo.
- Confirme Enterprise ID, status ativo e domínio/organização correta antes de provisionar.
- Se apps gerenciados ou enrollment falharem, valide Android Enterprise antes de alterar políticas.
- Após reconectar ou trocar vínculo, teste enrollment e instalação de app em dispositivo piloto.
¶ Aplicação na operação
- Acesse a integração e confirme Enterprise ID, nome e status. Se apps ou enrollment falharem, valide esse vínculo antes de investigar políticas individuais.
¶ Binds Android Enterprise
¶ Resultado das seleções e configurações
- Bind de produção: conecta a empresa ao ambiente Android Enterprise usado em operação real.
- Bind sandbox: identifica vínculo de teste/homologação quando disponível, sem substituir o vínculo produtivo padrão.
- Default binding: define qual vínculo será usado como padrão em novos enrollments e operações Android da empresa.
- Refresh: atualiza informações do vínculo junto ao Google/AMAPI antes de investigar falhas de enrollment ou apps.
- Upgrade: aparece apenas quando o vínculo é atualizável; executa a migração suportada pelo backend/Google.
- Set as default: disponível para vínculos de produção que ainda não são padrão.
- Unbind: remove vínculo de produção somente após confirmação digitando
delete; pode afetar provisionamento, políticas e apps gerenciados.
A área de vínculos/bindings do Android Enterprise.
Esta área é usada para revisar vínculos Android Enterprise da empresa, distinguir produção/sandbox e controlar qual bind será usado como padrão pelo provisionamento.
¶ Elementos da tela
- Lista de binds: mostra vínculos Android Enterprise existentes.
- Tipo: diferencia vínculos de produção e sandbox.
- Default: indica o vínculo atualmente usado como padrão.
- Status e upgrade: mostram se o vínculo está ativo, se pode ser atualizado ou se exige ação administrativa.
- Ações: permitem atualizar dados, fazer upgrade quando suportado, definir como padrão ou remover o vínculo com confirmação.
¶ Pré-requisitos e validação
- Mantenha acesso administrativo à conta Google usada no vínculo.
- Confirme Enterprise ID, status ativo e domínio/organização correta antes de provisionar.
- Se apps gerenciados ou enrollment falharem, valide Android Enterprise antes de alterar políticas.
- Após reconectar ou trocar vínculo, teste enrollment e instalação de app em dispositivo piloto.
¶ Aplicação na operação
- Confira se o binding corresponde à organização correta. Em caso de troca de domínio ou conta administradora, revise essa tela antes de provisionar novos dispositivos.
¶ Zero-touch Enrollment
¶ Zero-touch
¶ Resultado das seleções e configurações
- Ativar Zero-touch: autoriza o Nomid a consultar e usar configurações de provisionamento do cliente.
- Listar integrações ativas: mostra quais contas/clientes estão conectados.
- Cliente correto selecionado: garante que dispositivos comprados pelo revendedor entrem na empresa esperada.
- Cliente incorreto: pode impedir enrollment ou apontar equipamento para configuração errada.
- Desativar/remover integração: interrompe novos provisionamentos automáticos desse cliente.
- Validar dispositivo: confirma se o equipamento está atribuído no portal Zero-touch antes do primeiro boot/reset.
A tela da integração Zero-touch Enrollment.
Esta área é usada para conectar ou revisar a conta Zero-touch usada para provisionamento automático de dispositivos Android corporativos.
¶ Elementos da tela
- Zero-touch: permite provisionamento automático de dispositivos compatíveis.
- Configurações de enrollment: associam token, política e DPC ao dispositivo comprado.
- Integração com revenda: depende de dispositivos atribuídos ao cliente no portal Zero-touch.
- Benefício: reduz etapas manuais e evita cadastro incorreto em campo.
¶ Pré-requisitos e validação
- A conta Google usada deve ter permissão no portal Zero-touch do cliente.
- Dispositivos precisam estar atribuídos pelo revendedor ao cliente correto.
- A configuração Zero-touch deve apontar para o DPC/token compatível com o Nomid.
- Depois de ativar, teste com um equipamento real de fábrica ou resetado.
¶ Aplicação na operação
- Acesse Zero-touch, valide se a integração está ativa e se o cliente correto está vinculado. Use quando dispositivos comprados de revendedor devem se registrar automaticamente no Nomid.
¶ Integrações Zero-touch ativas
A lista de integrações Zero-touch já ativas.
Esta área é usada para identificar contas/clientes Zero-touch conectados à empresa e revisar seus status.
¶ Elementos da tela
- Conta Zero-touch: mostra integrações já configuradas.
- Cliente/empresa: identifica o ambiente de compra e provisionamento.
- Status: confirma se a integração está autorizada.
- Ações: permitem atualizar, remover ou revisar a conexão.
- Uso operacional: automatiza ativação de dispositivos comprados em revendas autorizadas.
¶ Pré-requisitos e validação
- A conta Google usada deve ter permissão no portal Zero-touch do cliente.
- Dispositivos precisam estar atribuídos pelo revendedor ao cliente correto.
- A configuração Zero-touch deve apontar para o DPC/token compatível com o Nomid.
- Depois de ativar, teste com um equipamento real de fábrica ou resetado.
¶ Aplicação na operação
- Confira se o cliente esperado aparece na lista. Se não aparecer, valide permissão da conta Google no portal Zero-touch e refaça autorização com a conta correta.
¶ Ativar integração Zero-touch
O fluxo para ativar a integração Zero-touch.
Esta área é usada para iniciar autorização com o Google para conectar o Nomid MDM ao portal Zero-touch do cliente.
¶ Elementos da tela
- Fluxo de ativação: inicia a autorização com a conta Zero-touch.
- Conta Google autorizada: deve ter permissão no portal Zero-touch do cliente.
- Permissões solicitadas: habilitam leitura e gerenciamento das configurações de provisionamento.
- Confirmação: conclui o vínculo para uso nas matrículas.
- Validação: deve ser feita com um dispositivo atribuído no portal Zero-touch.
¶ Pré-requisitos e validação
- A conta Google usada deve ter permissão no portal Zero-touch do cliente.
- Dispositivos precisam estar atribuídos pelo revendedor ao cliente correto.
- A configuração Zero-touch deve apontar para o DPC/token compatível com o Nomid.
- Depois de ativar, teste com um equipamento real de fábrica ou resetado.
¶ Aplicação na operação
- Selecione em ativar, autentique com uma conta Google que tenha permissão no Zero-touch e aprove o acesso. Depois volte ao Nomid e confirme que a integração ficou listada como ativa.
¶ SSO / Identity Provider
¶ SSO
A tela de SSO / Identity Provider configura a autenticação do usuário no dispositivo. Ela não altera o método de login dos administradores no portal. Em dispositivos cuja política use o método de login SSO, o usuário deverá autenticar pelo provedor configurado.
¶ Elementos da tela
- Configured: indica que existe pelo menos uma configuração de identidade salva. O status não comprova que o login no provedor funciona.
- Configurações cadastradas: definem os provedores que podem ser usados por dispositivos com método de login SSO.
- Add Configuration: adiciona outra configuração à lista, até o limite de dez.
- Desabilitar SSO ou excluir a última configuração: remove as configurações de identidade do portal. Confirme antes uma forma alternativa de acesso ao dispositivo.
¶ Aplicação na operação
- Cadastre o provedor, salve e valide o login em um dispositivo e usuário piloto. O salvamento armazena a configuração, mas não executa teste de conexão com o IdP.
¶ Adicionar SSO
¶ Resultado das seleções e configurações
- Google Workspace: usa endpoints, issuer, escopos e chaves públicas predefinidos pelo portal. Informe Display Name, Client ID e Client Secret do cliente OIDC cadastrado no Google.
- Custom OIDC: exige informar manualmente os endpoints e os parâmetros de validação do provedor compatível.
A tela inicia o cadastro de uma configuração de identidade para os dispositivos.
¶ Elementos da tela
- Identity Provider: escolhe Google Workspace ou Custom OIDC. A tela atual não oferece Microsoft, SAML ou restrição por domínio.
- Display Name: identifica a configuração na lista do portal.
- Add Configuration: inclui o formulário preenchido na lista atual; ao salvar, o portal envia o conjunto completo de configurações.
- Client Secret: é obrigatório na criação e deve ser tratado como segredo. Na edição, deixar o campo vazio ou mascarado preserva o valor existente; informar outro valor o substitui.
¶ Aplicação na operação
- Antes de distribuir SSO, mantenha um dispositivo piloto com caminho de recuperação que não dependa da nova configuração e preserve acesso administrativo ao IdP.
¶ Identity Provider
A imagem mostra uma configuração ativa de Google Workspace. Quando ela é salva, dispositivos configurados para login SSO passam a depender da autenticação no Google.
¶ Elementos da tela
- Display Name: nome exibido para identificar a configuração.
- Client ID: identifica o cliente OIDC cadastrado no Google Workspace.
- Client Secret: autentica o cliente e não deve ser exposto. Na edição, um segredo mascarado ou vazio mantém o valor armazenado.
- Redirect URI: cadastre exatamente
https://app-settings.nomid.tech/oauth2callback.htmlno cliente do provedor; divergências impedem o retorno do login. - Add Configuration: permite incluir outra configuração sem remover a atual, respeitando o limite de dez.
¶ Aplicação na operação
- Salve os dados e execute o login em um dispositivo piloto. O status Configured confirma apenas a presença da configuração, não a autenticação bem-sucedida.
¶ OIDC customizado
¶ Resultado das seleções e configurações
- Display name: nome visível para administradores identificarem esta configuração de login.
- Provider: define que a configuração usará Custom OIDC e, por isso, exibirá os endpoints manuais.
- Client ID: identifica o aplicativo Nomid cadastrado no provedor.
- Client Secret: autentica a aplicação; vazamento permite abuso da integração.
- Authorization Endpoint: URL para onde o usuário é redirecionado para autenticar.
- Token Endpoint: URL usada para trocar o código de autorização por tokens.
- Scope: define quais dados de identidade serão solicitados, como
openid,emaileprofile, conforme o IdP. - Issuer: valor esperado no token para validar que ele foi emitido pelo provedor correto.
- JWKS URI: endereço das chaves públicas usadas para validar a assinatura dos tokens.
- Save: armazena a configuração junto com a lista atual, mas não testa o IdP. Um endpoint, issuer, chave ou segredo incorreto pode impedir o login no dispositivo.
- Delete: remove a configuração da lista; excluir a última desabilita o SSO configurado.
O formulário de OIDC customizado.
Esta área é usada para cadastrar manualmente um provedor OpenID Connect com endpoints explícitos, client ID, client secret, scope, issuer e JWKS URI.
¶ Elementos da tela
- Display name: nome administrativo da integração.
- Provider: identifica o tipo de provedor configurado.
- Client ID: identifica a aplicação Nomid cadastrada no IdP.
- Client Secret: autentica a aplicação e deve ser armazenado como segredo.
- Authorization Endpoint: recebe o redirecionamento inicial de login.
- Token Endpoint: processa a troca do código por tokens.
- Scope: informa os escopos OIDC solicitados.
- Issuer: valida a origem lógica dos tokens.
- JWKS URI: fornece as chaves públicas para validação criptográfica.
¶ Aplicação na operação
- Copie os endpoints e identificadores exatamente do painel do provedor de identidade, registre a Redirect URI fixa no IdP e salve. Teste o login com um usuário e dispositivo piloto antes de distribuir a configuração; se falhar, revise primeiro redirect URI, client ID, segredo, issuer e JWKS URI.