Instalar o Omnissa Access

Para implantar o Omnissa® Access™ no Control Plane, siga as instruções fornecidas neste guia.

Esta seção, Instalação do Omnissa Access, do guia Instalar e configurar o Omnissa Access, orienta você ao longo de todo o processo de implantação do Omnissa Access em seu ambiente. Ela inclui uma visão geral da implantação, uma descrição dos componentes da plataforma que compõem um cluster do Omnissa Access, a arquitetura de implantação compatível e uma sequência de instalação em etapas que o conduz desde a preparação inicial da máquina virtual até a criação do locatário.

Após concluir a instalação, o guia prossegue com tópicos de configuração e gerenciamento que o ajudarão a preparar e operar sua implantação.

Após concluir a configuração, você pode usar o console do Omnissa Access para gerenciar usuários e grupos, configurar e gerenciar políticas de autenticação e acesso, adicionar recursos ao catálogo e gerenciar direitos a esses recursos. Você também pode configurar a integração do Workspace ONE UEM e iniciar o Hub Services.

Visão geral da implantação

O Omnissa Access é implantado na plataforma do Control Plane em várias fases. Cada fase depende da conclusão bem-sucedida da fase anterior.

Fases da implantação

1. Preparar máquinas virtuais.
2. Configurar o nó de bootstrap e os ativos.
3. Inicializar o cluster do Control Plane.
4. Implantar a plataforma do Control Plane.
5. Implantar os serviços de infraestrutura e do Access.
6. Criar locatário.

Visão geral dos componentes da plataforma

A tabela a seguir lista os componentes de plataforma necessários para o Omnissa Access.

Arquitetura de implantação

Certifique-se de que os seguintes detalhes relacionados à arquitetura sejam atendidos, conforme exigido pelo Omnissa Access:

• Máquinas virtuais necessárias

  Tipo de Nó	Contagem	Finalidade
  Nós de infraestrutura/plataforma	3	Serviços de infraestrutura
  Nós do Omnissa Access	2 ou mais	Serviços de aplicativo do Access
  Nó de bootstrap	1	Controlador de implantação
  Balanceador de Carga	0	Para HA (alta disponibilidade) dos serviços do Access
  Total	6 VMs ou mais

  Nota: os serviços de plataforma serão executados em todos os nós de gerenciamento e nos nós do Omnissa Access.

• Alocação de serviços

  Nó	Serviços
  Nós de infraestrutura/plataforma	Nomad, Consul, Vault, Postgres, Redis, Kafka, OpenSearch
  Nós do Omnissa Access	Serviços de Nomad, Consul, Vault, Access
  Nó de bootstrap	Implantação/Operações administrativas

  Certifique-se de que todos os nós atendam aos seguintes requisitos:

  • Executem o AlmaLinux 9.6
  • Possuam endereços IP estáticos
  • Possuam nomes de host exclusivos
  • Possuam acesso SSH a partir do nó de bootstrap

• Configuração do balanceador de carga

  Configure o balanceador de carga e adicione os nós do serviço de acesso upstream, permitindo que o balanceador de carga seja redirecionado para qualquer um dos nós. Consulte Usar um balanceador de carga ou proxy reverso para habilitar o acesso externo ao Omnissa Access para conhecer os requisitos de configuração.

• Resolução de DNS

  • Entrada DNS: certifique-se de que uma entrada de DNS resolva para o IP do FQDN (IP do balanceador de carga).

    tenant.example.com

• Requisitos de certificado

  • Nome Comum (CN): nome do host do balanceador de carga (tenant.example.com).

  • Nomes Alternativos da Entidade (SANs):

    • Exemplos:
      • tenant.example.com
      • tenant-cert.example.com
      • tenant-amsso.example.com

    Certifique-se de que a parte do domínio de todas as entradas SAN corresponda ao domínio usado pelo balanceador de carga e pelos nós do cluster.

    Notas:

    • Você pode optar por usar um certificado curinga, como *.tenant.example.com para abranger todos os SANs.
    • Se você não estiver usando a autenticação baseada em certificado, tenant.example.com será o único SAN necessário. Você pode omitir tenant-cert.example.com e tenant-amsso.example.com.

  Referência de CSR

  Use uma das seguintes configurações dependendo do seu tipo de certificado.

  Certificado curinga

  [ req ]
  default_bits       = 2048
  prompt             = no
  default_md         = sha256
  distinguished_name = dn
  req_extensions     = req_ext
  
  [ dn ]
  CN = *.tenant.example.com
  
  [ req_ext ]
  subjectAltName = @alt_names
  
  [ alt_names ]
  DNS.1 = *.tenant.example.com
  

  Certificado não curinga (todos os SANs necessários)

  Se você não estiver usando um certificado curinga, liste cada Nome Alternativo da Entidade explicitamente.

  [ req ]
  default_bits       = 2048
  prompt             = no
  default_md         = sha256
  distinguished_name = dn
  req_extensions     = req_ext
  
  [ dn ]
  CN = tenant.example.com
  
  [ req_ext ]
  subjectAltName = @alt_names
  
  [ alt_names ]
  DNS.1 = tenant.example.com
  DNS.2 = tenant-cert.example.com
  DNS.3 = tenant-amsso.example.com