Permitir que os usuários do Microsoft Entra B2B tenham acesso aos seus aplicativos locais

Aplica-se a: Círculo verde com um símbolo de marca de seleção branco. Locatários da força de trabalho Círculo branco com um símbolo de X cinza. Locatários externos (saiba mais)

Se sua organização utiliza funcionalidades de colaboração B2B do Microsoft Entra para convidar usuários de organizações parceiras, você pode agora conceder a esses usuários B2B acesso a aplicativos locais. Esses aplicativos locais podem usar a autenticação baseada em SAML ou a autenticação integrada do Windows (IWA) com a delegação restrita de Kerberos (KCD).

Acesso a aplicativos SAML

Se o seu aplicativo local usa a autenticação baseada em SAML, você pode facilmente disponibilizar esses aplicativos aos usuários de colaboração B2B do Microsoft Entra por meio do portal do Centro de administração do Microsoft Entra usando o Proxy de Aplicativo do Microsoft Entra.

Você deve fazer o seguinte:

Depois de concluir todas essas etapas, seu aplicativo estará pronto para execução. Para testar o acesso ao Microsoft Entra B2B:

  1. Abra um navegador e navegue até a URL Externa que você criou quando publicou o aplicativo.
  2. Entre com a conta do Microsoft Entra B2B que você atribuiu ao aplicativo. Você deve ser capaz de abrir o aplicativo e acessá-lo com o logon único.

Acesso a aplicativos IWA e KCD

Para fornecer aos usuários B2B acesso a aplicativos locais que são protegidos com a autenticação integrada do Windows e a delegação restrita do Kerberos, serão necessários os componentes a seguir:

  • Autenticação por meio do proxy de aplicativo do Microsoft Entra. Os usuários B2B devem autenticar-se no aplicativo local. Para fazer isso, é necessário publicar o aplicativo local por meio do proxy de aplicativo do Microsoft Entra. Para mais informações consulte: Tutorial: adicionar um aplicativo local para acesso remoto por meio do Proxy de aplicativo.

  • Autorização por meio de um objeto de usuário B2B no diretório local. O aplicativo deve executar verificações de acesso do usuário e conceder acesso aos recursos corretos. A IWA e KCD exigem um objeto de usuário no Active Directory do Windows Server local para concluir essa autorização. Conforme descrito em Como o logon único com KCD funciona, o Proxy de aplicativo precisa desse objeto de usuário para representar o usuário e obter um token do Kerberos no aplicativo.

    Observação

    Ao configurar o proxy de aplicativo do Microsoft Entra, verifique se a identidade de logon delegada está definida como Nome UPN (padrão) na configuração de logon único para IWA (autenticação integrada do Windows).

    Para o cenário de usuário B2B, há dois métodos que você pode usar para criar os objetos de usuário convidado que são necessários para autorização no diretório local:

    • MIM (Microsoft Identity Manager) e agente de gerenciamento MIM para Microsoft Graph.
    • Um script do PowerShell, que é uma solução mais leve que não requer MIM.

O diagrama a seguir fornece uma visão geral de alto nível de como o proxy de aplicativo do Microsoft Entra e a geração do objeto de usuário B2B no diretório local trabalham em conjunto para conceder aos usuários B2B acesso aos aplicativos IWA e KCD locais. As etapas numeradas são descritas em detalhes no diagrama abaixo.

Diagrama de soluções de script MIM e B2B.

  1. Um usuário de uma organização parceira (o locatário Fabrikam) é convidado para o locatário Contoso.
  2. Um objeto de usuário convidado é criado no locatário da Contoso (por exemplo, um objeto de usuário com um UPN guest_fabrikam.com#EXT#@contoso.onmicrosoft.com).
  3. O convidado Fabrikam é importado da Contoso por meio do MIM ou script do PowerShell B2B.
  4. Uma representação ou “footprint” do objeto de usuário convidado Fabrikam (Guest#EXT#) é criado no diretório local, Contoso.com, por meio do MIM ou por meio do script PowerShell B2B.
  5. O usuário convidado acessa o aplicativo local, app.contoso.com.
  6. A solicitação de autenticação é autorizada por meio do Proxy de Aplicativo, usando a delegação restrita de Kerberos.
  7. Como o objeto de usuário convidado existe localmente, a autenticação é com êxito.

Políticas de gerenciamento do ciclo de vida

É possível gerenciar os objetos de usuário B2B local por meio das políticas de gerenciamento do ciclo de vida. Por exemplo:

  • É possível configurar políticas de MFA (Autenticação Multifator) para o usuário convidado, de modo que a MFA seja utilizada durante a autenticação do Proxy de Aplicativo. Para obter mais informações, consulte Acesso condicional para usuários de colaboração B2B.
  • Todos os patrocínios, revisões de acesso, verificações de conta etc. que são executados no usuário B2B na nuvem se aplicam aos usuários locais. Por exemplo, se o usuário de nuvem for excluído por meio das políticas de gerenciamento de ciclo de vida, o usuário local também será excluído pela Sincronização do MIM ou pelo script do Microsoft Entra B2B. Para obter mais informações, consulte Gerenciar acesso para convidado com revisões de acesso do Microsoft Entra.

Criar objetos de usuário convidado B2B por meio de um script do Microsoft Entra B2B

Você pode usar um script de exemplo B2B do Microsoft Entra para criar contas sombra do Microsoft Entra sincronizadas de contas B2B do Microsoft Entra. Em seguida, use as contas sombra para aplicativos locais que usam a KCD.

Criar objetos de usuários convidados B2B através do MIM

Você pode usar o MIM e o conector MIM para o Microsoft Graph para criar os objetos do usuário convidado no diretório local. Para saber mais, confira Colaboração B2B (entre empresas) do Microsoft Entra com o MIM (Microsoft Identity Manager) 2016 SP1 com o Proxy de Aplicativo do Azure.

Considerações sobre licença

Verifique se você possui as Licenças de Acesso para Cliente (CALs) ou Conectores Externos corretos para os usuários convidados externos que acessam aplicativos no local ou cujas identidades são gerenciadas no local. Para obter mais informações, consulte a seção "Conectores Externos" das Licenças de Acesso para Cliente e Licenças de Gerenciamento. Consulte o seu representante da Microsoft ou revendedor local em relação às suas necessidades específicas de licenciamento.

Próximas etapas