MicrosoftHi Simone_Oor,
for these permissions and applications, where the usage of Shadow Principals is possible, I use SPs. That's the most
Hello @Simone_Oor,
I use SPs for these authorizations and applications where the usage of shadow principals is possible. In the target scenario, the corresponding SPs are linked to the specific issuance groups for authentication with SmartCards.
In my tests so far, I have also tested direct memberships in the shadow principal. Unfortunately also without success.
Nesting is also a good idea. I have just tested this again, but also without success.
In addition, I once added a user directly to the local group of administrators of the target server in the resource forest. This was also unsuccessful.
I have also changed the selective authentication of the trust to forest-wide as a test, and a temporary extension of the trust to a two-sided trust, so that the group names / SIDs can also be resolved in the authentication policy, was also unsuccessful.
It seems to me that the domain controllers from the bastion forest do not validate the group memberships in the resource forest during the "Authentication Policy" processing, as a result of which I receive the following error message in all scenarios, while trying to authenticate with a user from Bastion forest to a system in resource forest.
If you find a solution for this, I would be very grateful for your feedback. The usage of kerberos amoring to separate the tiers and also the administrative accesses could give the ESAE another security boost.
Thanks and Regards
Henry
