Você estava realmente muito perto de sua configuração inicial. Você estava apenas faltando 1 passo (e tem 2 passos estranhos). Porém, antes de explicar como fazer o cenário original funcionar, preciso mencionar/avisar que o cenário original não é o ideal e não deve ser utilizado, mesmo que corrigido, pois existe um método melhor e mais seguro: Module Signing. Expliquei a solução preferida para o problema geral abordado pela configuração original na minha resposta à sua pergunta relacionada: A opção Confiável deve ser desativada, mas qual é uma alternativa? .

Como você descobriu (com base em sua atualização na pergunta), o problema é devido ao uso da WITH EXECUTE AS ...cláusula (ou seja, representação) na definição do proc. Isso coloca o processo em quarentena no banco de dados atual. Sim, habilitar TRUSTWORTHY(como você tentou inicialmente) pode ajudar a superar isso, mas as regras nem sempre são diretas. Primeiro, TRUSTWORTHYafeta apenas onde um processo está sendo iniciado, portanto, não há motivo para habilitar TRUSTWORTHYno banco de dados de destino (que é uma das duas etapas estranhas). Segundo, ao habilitar TRUSTWORTHY, o foco da segurança passa a ser o proprietário do banco de dados atual (ou seja, onde o processo está sendo iniciado). Portanto, a questão é se SourceDatabaseOwnertem ou não permissão para atuar como autenticador em [TargetDatabase], nãoServiceAccount(ou seja, a etapa ausente é conceder AUTHENTICATEa SourceDatabaseOwner- o que exigirá a adição SourceDatabaseOwnercomo usuário [TargetDatabase]- e a segunda etapa estranha é conceder AUTHENTICATEa ServiceAccount).

Aqui está uma demonstração de trabalho, com base no seu código de exemplo da pergunta:

Configuração inicial

/* -- Clean Up
USE [master];
DROP DATABASE SourceDatabase;
DROP DATABASE TargetDatabase;

DROP LOGIN SourceDatabaseOwner;
DROP LOGIN TargetDatabaseOwner;
DROP LOGIN ServiceAccount;
*/

-- Create logins
CREATE LOGIN SourceDatabaseOwner WITH PASSWORD = 'Pa$$w0rd';
CREATE LOGIN TargetDatabaseOwner WITH PASSWORD = 'Pa$$w0rd';
CREATE LOGIN ServiceAccount WITH PASSWORD = 'Pa$$w0rd';

-- Create databases
CREATE DATABASE SourceDatabase;
CREATE DATABASE TargetDatabase;

-- Setup trustworthy
ALTER DATABASE SourceDatabase SET TRUSTWORTHY ON;
--------ALTER DATABASE TargetDatabase SET TRUSTWORTHY ON; -- ???????????!!

-- Setup database owners
-- ( sp_changedbowner is deprecated )
ALTER AUTHORIZATION ON DATABASE::[SourceDatabase] TO [SourceDatabaseOwner];
ALTER AUTHORIZATION ON DATABASE::[TargetDatabase] TO [TargetDatabaseOwner];

-- Add ServiceAccount to source database
USE SourceDatabase
CREATE USER ServiceAccount FOR LOGIN ServiceAccount;  
GO

-- Add ServiceAccount to target database
USE TargetDatabase
CREATE USER ServiceAccount FOR LOGIN ServiceAccount;  
GO

---------- Enable ServiceAccount to authenticate to target database
--------USE TargetDatabase
--------GO
--------GRANT AUTHENTICATE TO ServiceAccount; -- ???????????!!

-- Grant permissions
USE TargetDatabase
GRANT SELECT ON SCHEMA::dbo TO ServiceAccount;
GO

-- Create table with data
USE TargetDatabase;
GO
CREATE TABLE dbo.InterestingData (
    Id INT IDENTITY PRIMARY KEY,
    Content NVARCHAR(255)
);
INSERT INTO dbo.InterestingData (Content) VALUES ('Foo'), ('Bar');
GO

-- Create stored procedure executing under service account and
-- accessing target database
USE SourceDatabase;
GO
CREATE OR ALTER PROCEDURE dbo.GetData
WITH EXECUTE AS 'ServiceAccount'
AS
BEGIN
    SELECT SESSION_USER AS [CurrentUser];
    SELECT Id, Content FROM TargetDatabase.dbo.InterestingData;
END;
GO

Teste

-- Execution does not work under service account
-- The server principal "ServiceAccount" is not able to access the database
--     "TargetDatabase" under the current security context.
USE [SourceDatabase];
EXEC dbo.GetData;
GO

FIXAR ...

• para permitir o acesso a bancos de dados individuais

  USE [TargetDatabase];
  CREATE USER [SourceDatabaseOwner];
  GRANT AUTHENTICATE TO [SourceDatabaseOwner];
  

  — ??? —

• para permitir o acesso a todos os bancos de dados

  USE [master];
  GRANT AUTHENTICATE SERVER TO [SourceDatabaseOwner];
  

Teste novamente

USE [SourceDatabase];
EXEC dbo.GetData;
-- Success!!
GO

Se, por algum motivo, você realmente precisava/querer usar WITH EXECUTE AS(embora normalmente não haja motivo para isso, já que a assinatura de módulo permite que o proc/função/gatilho funcione de forma consistente, independentemente de quem o executa), você ainda pode fazer isso sem habilitar TRUSTWORTHYvia assinatura de módulo. Assim como na configuração original, você estava novamente perto das etapas adicionais de assinatura de módulo, mas havia novamente uma etapa ausente e uma etapa irrelevante. A assinatura de módulo muda o foco da segurança para o certificado (e, portanto, para o logon e/ou usuário baseado em certificado). Portanto, a etapa que faltava não era conceder AUTHENTICATEao usuário baseado em certificado em[TargetDatabase]. E a etapa estranha foi criar um Login para o Certificado, pois não há permissões de nível de servidor concedidas neste cenário.

Aqui está uma demonstração de trabalho, continuando a demonstração de cima (ou seja, não independente):

Desfaça a etapa extra da demonstração acima que fez as coisas funcionarem (para mostrar que a assinatura de módulo também corrige esse cenário)

USE [TargetDatabase];
DROP USER [SourceDatabaseOwner];

USE [master];
REVOKE AUTHENTICATE SERVER TO [SourceDatabaseOwner];

Teste novamente (verifique se o proc não funciona mais)

USE [SourceDatabase];
EXEC dbo.GetData;
-- error
GO

Configurar a assinatura do módulo

USE [SourceDatabase];

-- Create certificate
CREATE CERTIFICATE [SignProcedureCert]
    ENCRYPTION BY PASSWORD = 'Pa$$w0rd'
    WITH SUBJECT = 'Certificate for signing stored procedures';

-- Sign the procedure
ADD SIGNATURE TO dbo.GetData   
    BY CERTIFICATE SignProcedureCert  
    WITH PASSWORD = 'Pa$$w0rd';  
GO  
-----------------

-- Copy certificate to target DB ( CERTENCODED in SQL Server 2012+ )
DECLARE @Cert NVARCHAR(4000);
SET @Cert = CONVERT(NVARCHAR(4000),
                    CERTENCODED(CERT_ID(N'SignProcedureCert')), 1);
SELECT CERT_ID(N'SignProcedureCert'), @Cert;

EXEC (N'USE [TargetDatabase];
CREATE CERTIFICATE [SignProcedureCert] FROM BINARY = ' + @Cert);

-- Create certificate-based User to allow access to DB
USE [TargetDatabase];
CREATE USER [SignProcedureCert] FROM CERTIFICATE [SignProcedureCert];

-- Allow access to target object in target DB
USE [TargetDatabase];
GRANT SELECT ON SCHEMA::dbo TO [SignProcedureCert];
GO

Teste novamente (verifique se o proc ainda não funciona)

A configuração de assinatura de módulo que funcionou na pergunta relacionada (vinculada ao topo) não funciona aqui.

USE [SourceDatabase];
EXEC dbo.GetData;
-- error
GO

O problema é a WITH EXECUTE AScláusula na definição do proc.

FIXAR

USE [TargetDatabase];
GRANT AUTHENTICATE TO [SignProcedureCert];

Teste novamente

USE [SourceDatabase];
SELECT SESSION_USER AS [CurrentUser];
EXEC dbo.GetData;
-- Success!!
GO

Para obter mais informações sobre a assinatura de módulo em geral, visite meu site:
https://ModuleSigning.Info/