ADFS - Combinando declarações de relações de confiança de provedor e AD

Question

Como parte da implementação de uma instalação do SharePoint 2013, configurei o SSO com o ADFS no Windows Server 2012R2.

Existem duas florestas do AD separadas, uma como parte do SharePoint / ADFS Hospedado e uma floresta corporativa no local.

Atualmente, tenho o AD corporativo configurado como Claims Provider Trust no SharePoint ADFS . Eu posso passar com sucesso pelo atributo de e-mail do AD corporativo para o SharePoint.

O que eu quero alcançar é alguma forma de injeção de declaração do Hosted AD Forest como parte do logon com uma conta Corporate AD .
Especificamente, os usuários serão membros de grupos de segurança para determinar o licenciamento do SharePoint. Por motivos de segurança, não desejo obter essas informações de reivindicação do AD corporativo, pois isso significa que os usuários poderão alterar seu status de licenciamento.

Assim, todos os usuários terão uma conta do AD em ambas as florestas. Single Sign On fornecido inserindo suas credenciais corporativas como parte do processo de login.

Existe alguma maneira de eu dizer ao meu hosted ADFS para procurar um usuário em sua própria floresta do AD que corresponda à incoming Email Address Claim do Corporate ADFS e, em seguida, injetar o Role claim do hosted forest com disse a reivindicação por e-mail?

Por favor, veja a imagem abaixo para o que eu estou tentando alcançar (Desculpe pelo rápido desenho MS Paint!):

Como obtenho os passos 4 e amp; 5?

Regras atuais de reivindicação
No Hosted ADFS , Acceptance Transform Rules para o Corporate Claim Provider Trust :

1. Passe pela declaração de endereço de e-mail de entrada, passe por todos os valores

No Hosted ADFS , Issuance Transform Rules para o SharePoint Relying Party :

1. Enviar atributos LDAP como reivindicações (UPN - > UPN, Grupos de símbolos - > Função, Endereços de e-mail - > E-mail)
2. Passe pela declaração de endereço de e-mail de entrada, passe por todos os valores

Answer 1

Sim, isso deve funcionar. Se você controlar as regras de declaração no ADFS hospedado e tiver uma chave do ADFS Corp em uma declaração, poderá fazer a regra de reivindicação de pesquisa do AD regular com essa chave.

    

Answer 2

Acabei fazendo isso funcionar e, na verdade, não foi tão ruim quanto eu pensei que seria - eu só precisava codificar um Issuance Transform Rule personalizado no meu SharePoint Relying Party.

Isso é o que eu criei:

c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"]
 => issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn", "http://schemas.microsoft.com/ws/2008/06/identity/claims/role"), query = "userPrincipalName={0};userPrincipalName,tokenGroups;MYDOMAIN\accountthatdoesnotexist", param = c.Value);

Essencialmente, isso significa que, se uma reivindicação de endereço de e-mail for definida no conjunto de declarações de entrada, ela consultará o AD com o endereço de e-mail e localizará um userPrincipalName que corresponde ao email address . Em seguida, ele simplesmente retorna os atributos upn e tokenGroups como as declarações upn e role das quais preciso.

Inseri isso como regra número 1 na minha terceira parte confiável. Como alguns usuários não terão um ADFS de terceiros para autenticação, acredito que isso deve dar a ele mais compatibilidade.

Após inspecionar o código de declarações padrão ao usar o modelo Enviar Atributos do AD, ele só será executado se a regra receber um windowsaccountname claim (essa reivindicação só será passada para a Parte Confiante se um usuário fizer login sem um terceiro ADFS).

Portanto, tenho uma situação em que, se um usuário estiver fazendo login em without a third party ADFS , ele ignorará minha regra personalizada, pois o repositório de atributos do Active Directory não envia um email address claim . Além disso, se um usuário estiver fazendo login em WITH a third party ADFS , ele ignorará a regra Send LDAP Attributes , pois não há um conjunto de declarações windowsaccountname !

Por fim, na minha primeira tentativa, pensei inicialmente que estava presa, pois estou usando apenas UPNs e não contas de domínio \ nome de usuário tradicionais no AD hospedado porque recebi uma mensagem de erro nos logs de eventos:

Microsoft.IdentityServer.ClaimsPolicy.Engine.AttributeStore.AttributeStoreQueryFormatException: 
POLICY3826: 
User name '[email protected]' in LDAP query';userPrincipalName,tokenGroups;[email protected]' 
is not in the required 'domain\user' format.

No entanto, uma boa notícia para mim é que a parte do nome de usuário do domínio \ nome de usuário é realmente ignorada! link

QUERY = <QUERY_FILTER>;<ATTRIBUTES>;<DOMAIN_NAME>\<USERNAME>

This part of the query identifies and locates the domain controller to connect to for execution of the LDAP query

Also note that USERNAME is ignored, even for Active Directory attribute stores.

Portanto, com um ligeiro ajuste para garantir que o filtro LDAP corresponda a userPrincipalName em vez do padrão (se o filtro de consulta estiver em branco) samAccountName , isso agora está funcionando perfeitamente!