Conforme mencionado na atualização da minha pergunta, alterar a conta de serviço para Domain2 resolveu o problema. Então o que estava acontecendo?

O problema - explicado

Pelo que posso dizer (também com a ajuda de um representante da Microsoft), porque a conta de serviço era originalmente um Domain1 usuário, ele não pôde determinar de quais grupos locais de domínio o usuário conectado é membro quando o usuário está autenticando via Kerberos. O principal motivo de que esse era um problema do Kerberos foi quando me conectei com sucesso usando "Pipes nomeados", pois isso usa a autenticação NTLM.

Solução geral

Para reunir tudo, adicionar usuários de Domain1 com sucesso e Domain3 como membros de grupos em Domain2 para que os grupos possam ser usados ​​como logins do SQL Server com autenticação do Windows, aqui está uma lista de requisitos (ou pelo menos fortemente recomendado):

1. Relações de confiança estabelecidas entre os domínios
   1. No mínimo, as relações de confiança unidirecionais devem ser configuradas para que Domain2 confia em Domain1 e Domain3
2. Grupos em Domain2 deve ter o escopo "Domínio Local"
   1. Isso é para que você possa adicionar usuários e grupos de Domain1 e Domain3
   2. Veja aqui para mais informações
3. Use o SQL Server Configuration Manager para designar um Domain2 não administrativo usuário como a identidade da conta de serviço
   1. Documentos do MSDN por que usar uma conta de usuário de domínio pode ser preferível
   2. Mesmo que o gerenciador de configuração deva adicionar usuários a grupos específicos do SQL Server 2005 locais para você (ou seja, SQLServer2005MSSQLUser$MY_MACHINE$MY_INSTANCE), encontrei algumas instâncias em que esse não era o caso. Portanto, verifique seus grupos locais para garantir que eles foram atualizados adequadamente com seu Domain2 conta de usuário.
   3. Embora a configuração do SQL Server deva atribuir automaticamente as permissões apropriadas para seus grupos locais, novamente, encontrei algumas instâncias em que esse não era o caso. Se isso acontecer com você, você pode consultar este artigo do MSDN junto com o artigo mencionado anteriormente para obter os requisitos de permissão.
4. Configure um nome principal de serviço (SPN) para o host da instância do SQL Server (incluindo quaisquer aliases) e o Domain2 conta de serviço
   1. O SPN é necessário para autenticação mútua entre o cliente e o host do servidor
   2. Consulte este artigo do TechNet para obter mais informações
5. Dependendo de como você pretende usar a representação, convém ativar o Domain2 conta de serviço confiável para delegação
   1. Consulte este artigo do TechNet para obter mais informações
6. Ative conexões remotas para a instância do SQL Service
7. Finalmente, crie logins para o Domain2 desejado grupos e qualquer Domain1 ou Domain3 os membros devem poder se conectar remotamente!

Observação

Como sempre com qualquer atividade de rede remota, verifique seus firewalls para garantir que as portas do SQL Server não estejam bloqueadas. Embora a porta padrão seja 1433, verifique se sua porta está limpa.