Nossa plataforma de SSO (WorkOS) ajuda as organizações a gerenciar o acesso dos usuários de forma eficaz. Ao impor logins controlados por domínio por meio do Provedor de Identidade (IdP), as organizações controlam quem pode acessar o Perplexity pelo lado delas.
Padrão: Os administradores da organização devem convidar usuários no Perplexity.
Provisionamento just-in-time: Os usuários são criados no Perplexity quando fazem login pela primeira vez via SSO/IdP, e não quando são adicionados ao IdP. Você encontrará as instruções para ativar o provisionamento JIT aqui.
Recursos de engenharia opcionais:
Ative o login automático para usuários com o domínio de e-mail da sua organização.
Adicione automaticamente à sua conta do Perplexity todos os usuários com um domínio de e-mail de propriedade da sua organização.
SCIM (Sistema para Gerenciamento de Identidade entre Domínios): automatiza o provisionamento e o desprovisionamento de usuários. O Perplexity oferece suporte ao SCIM para organizações com 50 ou mais usuários ou se houver pelo menos um usuário Enterprise Max.
Os usuários removidos do IdP não são excluídos automaticamente do Perplexity.
Se o SSO for aplicado, os usuários desprovisionados não podem fazer login, mas ainda aparecem no Perplexity até que um administrador os remova.
Recomendação: Os administradores devem revisar regularmente e remover manualmente os usuários desprovisionados para manter os registros precisos.
Se a sua organização estiver enfrentando problemas com o SSO, primeiro confirme se Exigir SSO está ativo. Quando esta opção está ativada, os logins controlados por domínio por meio do seu IdP são aplicados à sua organização.
Para fazer isso, acesse a tela Identidade nas configurações da sua organização e ative a opção Exigir SSO.
Se o SSO for obrigatório para sua organização, mas os usuários não estiverem vendo o fluxo de SSO da sua organização, verifique se o domínio ou subdomínio que eles estão usando foi verificado (veja abaixo).
Você também pode pedir que eles atualizem o navegador (pressionando ctrl+F5 no Windows ou command+shift+R no Mac), caso isso seja causado por um problema de cache.
Todos os domínios e subdomínios usados pela sua organização para login SSO devem ser verificados de forma independente.
Se a verificação do seu domínio aparecer como "pendente" ou "falhou", é provável que o registro DNS TXT ainda não tenha sido adicionado à configuração de DNS do seu domínio.
Para verificar seu(s) domínio(s):
Acesse a tela Identidade nas configurações da sua organização.
Clique em "Adicionar" ao lado da seção Domínio.
Digite o domínio da sua organização (por exemplo, yourdomain.com).
Copie o registro DNS TXT fornecido.
Adicione este registro à configuração de DNS do seu domínio com o "verification\_token=string" completo incluído com aspas duplas. Defina o TTL para 60 segundos.
Aguarde pelo menos um minuto e use nslookup -q=text yourdomain.com para confirmar que o novo registro DNS TXT foi propagado para a Internet.
Clique em "Verificar" assim que o registro DNS TXT for adicionado.
Repita para todos os domínios que sua organização usa.
Depois que um domínio for verificado com sucesso, você pode aumentar a configuração de TTL para 12 ou 24 horas (43200 ou 86400 segundos).
Se você quiser ativar os recursos de login automático ou captura automática, precisará habilitar o provisionamento just-in-time para sua organização.
Você pode fazer isso na tela Identidade, nas configurações da organização, alternando a opção “Provisionamento de conta just-in-time” para “Ativado”:
Se o JIT estiver ativo para sua organização, mas você estiver tendo problemas com o provisionamento just-in-time de um usuário específico, tente fazer login com um novo usuário.
Se isso funcionar com um novo usuário, mas não com usuários específicos, é bem provável que qualquer problema contínuo de integração de usuários não se deva ao SSO nem a uma configuração incorreta de provisionamento por parte da organização. Em vez disso, os problemas podem estar relacionados a atribuições de usuários individuais, permissões, associações de grupos no IdP ou problemas específicos dessas contas.
Se não funcionar, pode haver um problema com a configuração de SSO/JIT entre seu IdP e o Perplexity. As causas comuns incluem atributos configurados incorretamente, permissões ausentes ou parâmetros SAML/OIDC incorretos.
Se o SCIM não estiver ativo para sua organização, quando um usuário for removido do Provedor de Identidade (IdP), esse usuário perderá a capacidade de fazer login no Perplexity se o SSO for aplicado e o IdP rejeitar seu login. No entanto, a conta e os dados do usuário permanecerão no sistema Perplexity até que um administrador os exclua ou remova manualmente. O SSO padrão controla apenas a autenticação no login, não o gerenciamento ou exclusão do ciclo de vida do usuário.
O SCIM adiciona gerenciamento automatizado do ciclo de vida. Quando um usuário é desprovisionado do IdP, o SCIM envia uma solicitação ao Perplexity para desativar ou remover a conta do usuário automaticamente. Isso significa que as organizações que usam o SCIM podem automatizar a criação e a remoção de usuários, minimizando o trabalho de limpeza manual e melhorando a postura de segurança.
SCIM está disponível para organizações com 50 licenças ou mais, ou com pelo menos uma licença do Enterprise Max.
|
Mensagem de erro |
Significado |
Solução |
|
AADSTS50105 (Microsoft Entra ID) |
O usuário não é membro direto de um grupo autorizado ou não tem acesso direto. |
Entre em contato com o administrador de TI ou do Enterprise Pro para ter acesso direto ou ser adicionado a um grupo com acesso. Tente fazer login novamente após a sincronização. |
|
O usuário não está atribuído a este aplicativo (Okta) |
A conta não está atribuída ao aplicativo Perplexity no Okta. |
Peça ao seu administrador de TI ou Enterprise Pro para atribuir sua conta ao aplicativo Perplexity Enterprise no Okta. |
|
Erro 408: App\_not\_enabled\_for\_user (Google SSO) |
O acesso ao aplicativo não está ativado para sua conta ou grupo no Google Admin Console. |
O administrador deve ativar o acesso de usuário para você ou seu grupo no console de administração do Google Workspace em Apps > Web and mobile apps. Em seguida, tente fazer login novamente. |
Quando uma organização migra para um novo domínio, o Single Sign-On (SSO) pode parar de funcionar se as contas de usuário ou as configurações de domínio não forem atualizadas no Perplexity.
Para evitar falhas de SSO durante uma migração de domínio, a prática recomendada é adicionar e verificar proativamente o novo domínio no Perplexity antes de fazer qualquer alteração no provedor de identidade ou nos endereços de e-mail dos usuários.
Também é importante atualizar a configuração do provedor de identidade para incluir o novo domínio e ajustar quaisquer atribuições de grupo ou usuário adequadamente, para que os usuários mantenham as permissões de SSO necessárias após a mudança.
Se você migrou domínios antes de verificar o novo domínio e ainda tem acesso ao seu e-mail anterior com direitos de administrador, faça login com esse e-mail. Isso permitirá que você verifique o novo domínio. No entanto, se você não tiver mais acesso ao seu e-mail antigo, entre em contato conosco. Podemos desativar o SSO temporariamente para que você possa verificar o novo domínio.
Se você tiver outros problemas ou se essas etapas de solução de problemas não resolverem o problema que você está enfrentando, entre em contato conosco e nossos engenheiros de suporte terão prazer em ajudar.