Re: LookupAccountName behavior dependent upon operating system of global catalog (GC)

There is no explicit trust "shortcut" between the two child domains, but
there is the standard transitive trust between the domains as members of the
same forest. The environment has been in place for over four years,
supporting roughly 4500 user accounts in childA.root.com and 14,000 user
accounts in childB.root.com. All other account enumeration and access across
the domains has been fine -- tools such as AD Users and Computers, scripts
using LDAP queries or direct enumeration, web applications, and so on. It's
just this one obscure LookupAccountName situation that is not working.

I checked the policy settings you noted earlier. The following settings are
in effect in *all three domains*:

Network access: Allow anonymous SID/Name translation - ENABLED
Network access: Do not allow anonymous enumeration of SAM accounts - ENABLED
Network access: Do not allow anonymous enumeration of SAM accounts and
shares - ENABLED
Network access: Let Everyone permissions apply to anonymous users - DISABLED
Network access: Named pipes can be accessed anonymously - (standard list of
named pipes)
Network access: Restrict anonymous access to Named Pipes and shares -
ENABLED

Since the settings are the same for all three domains, if they are causing
the LookupAccountName call to fail for queries against childA.root.com, it
should also fail for queries against root.com, no?

Unfortunately, I'm not at liberty to make changes to those settings in our
production environment.

FWIW, the following KB article indicates that the restrictAnonymousSam
setting does not apply to domain controllers anyway:

Client, service, and program incompatibilities that may occur when you
modify security settings and user rights assignments
http://support.microsoft.com/kb/823659

Oh, one other thing. I ran Network Monitor on the domain controllers as I
made the call to LookupAccountName. On neither the Windows 2000 Server DC
nor the Windows Server 2003 DC did any packets leave the DC to reach out to
a childA.root.com DC. Granted, since the DCs are GCs, I wouldn't expect them
to need to contact the other domain. Just wanted to throw that out there for
completeness. So, if it is somehow being converted to an anonymous call,
it's purely internal to the DC.

There still doesn't seem to be any reason for the call to be treated as
anonymous, and thus I'm still leaning toward a fix/change in Windows Server
2003 as an explanation for the behavior.


.

Relevant Pages

  • Get/set local security settings programmatically
    ... I asked a question about getting and settings Public Key Policies in Local ... Accounts: Administrator account status ... Network access: Do not allow anonymous enumeration of SAM accounts ... Machine Access Restrictions in Security Descriptor Definition ...
    (microsoft.public.platformsdk.security)
  • Re: Problem Disabling "Null Session" on W2K3
    ... Go to Administrative Tools --> Local Security ... Network Access: Do not allow anonymous enumeration of SAM accounts: Enabled ...
    (Security-Basics)
  • Re: Access Denied Browsing Solution
    ... >>I presume you made those changes on Abigail? ... Maybe check both the LSP ... >LSP Settings USER: ... >Network Access: Do not allow anonymous enumeration of SAM ...
    (microsoft.public.windowsxp.network_web)
  • Need Help with hackers
    ... Network Access: do not allow anonymous enumeration of SAM accounts and Shares ...
    (microsoft.public.win2000.general)
  • RE: LDAP Information
    ... Network access: Do not allow anonymous enumeration of SAM accounts ... That's it, you fixed the founding. ...
    (microsoft.public.windows.server.active_directory)