Can't access local AD

[panki27]

Hi, I've tried running Set-OutlookSignatures for the first time.
The script throws an error while trying to access the on-prem AD. I believe this is happening because the forest name is identical to the domain name.

Output (sorry for the German verbose message - I don't think there's a way to easily change this, other than changing entire OS language...):

Enumerate domains @2023-08-16T10:53:15+02:00@
  User forest: contoso.com
    Child domain: a.contoso.com
    Child domain: b.contoso.com
    Child domain: c.contoso.com
    Child domain: d.contoso.com
    Child domain: e.contoso.com
    Child domain: f.contoso.com
    Child domain: g.contoso.com
    Child domain: h.contoso.com
    Child domain: i.contoso.com
    Child domain: j.contoso.com
    Child domain: k.contoso.com
    Child domain: l.contoso.com
  Trusted domain: contoso.com
AUSFÜHRLICH: Ausnahme beim Aufrufen von "Add" mit 2 Argument(en):  "Das Element wurde bereits hinzugefügt. Schlüssel im Wörterbuch: "contoso.com". Hinzuzufügender Schlüssel: "contoso.com"."
  Problem connecting to logged-in user's Active Directory (see verbose stream for error message).
  Assuming Graph/Entra ID/Azure AD from now on.

The issue is here: https://github.com/GruberMarkus/Set-utlookSignatures/blob/dfae4b37a84987ed76dc962b0fe52e29260019de/src_Set-OutlookSignatures/Set-OutlookSignatures.ps1#L1170

Debugging the $LookupDomainsToTrusts variable shows that it already contains contoso.com, which is then being added a second time, which leads to the above exception.

I was able to work around it like this:

if ( -not $LookupDomainsToTrusts[$TrustedDomain.properties.name]) {
    $LookupDomainsToTrusts.add($TrustedDomain.properties.name.tolower(), $TrustedDomain.properties.name.tolower())
}

But I'm not sure if this is the best approach. If you think it is, let me know and I'll create a PR.

[GruberMarkus]

Deutsch ist überhaupt kein Problem. But let's stick to English, to make it easier for other users to follow this issue.

You are right with your assumption and your sample code would work. I will consider integrating the code in the next hotfix release - but we must find the root cause first: Why does Set-OutlookSignature detect this specific trust anyhow?

Please open the Active Directory Domains and Trusts MMC snap-in and check, if the root domain contoso.com has configured a trust to itself. If yes, than this is something you should investigate (I have never seen such a configuration, and ad-hoc can't imagine why this would be neccessary).

[panki27]

Hi Markus,
I've checked this by opening the properties of the root domain contoso.com and checking the list of outgoing and incoming trusts.

There is no reference to contoso.com, only to the child domains a.contoso.com, b.contoso.com and so on.
But thank you for this hint, I'll keep investigating.

[panki27]

After using several Powershell cmdlets, I can confidently say there is no "special" trust relation from the parent domain to itself (which would be really weird, indeed).

My guess is that this happens because forest name == domain name, which is against M$ best practice. So I really can't fault your script here!

[GruberMarkus]

Nonetheless, the code change you proposed makes sense and I will integrate it in the next hotfix release (which will very likely be released until the end of this week).