Get-ADGroupMember traag op ene DC, niet op andere

[Blokker_1999]

We voeren in sommige scripts een Get-ADGroupMember -Recursive uit en vorige week begonnen enkele van deze scripts ineens te falen vanwege een timeout. Uit onze logs kunnen we opmaken dat voordat de problemen begonnen, de lookuip telkins in enkele seconden gebeurde, en nu lopen we ineens met regelmaat tegen een timeout aan, en die is als ik me niet vergis 10 minuten!

Wat het nog vreemder maakt is dat we 1 domeincontroller hebben waartegen dit commando nog wel snel loopt. Als we die controller als -Server argument meegeven, dan hebben we alsnog resultaat op enkele seconden. De andere 4 DCs doen er allemaal veel langer over en eindigen regelmatig in een timeout.

Alle servers zitten op hetzelfde patch niveau en zijn op dit moment Server 2016, daar kunnen we de oorzaak dus al niet gaan zoeken. Een herstart van de controllers brengt ook geen oplossing. De controller die nog snel reageert durven we op dit moment ook niet herstarten, al gaan we er de installatie van security updates, en hun benodigde herstart, ook niet voor tegenhouden.

Wat ik online vind zijn vooral verklaringen die op alle servers traag zouden moeten werken, zoals SIDs in de groep die niet meer geresolved kunnen worden of omdat er andere domeinen in het spel zouden zijn. Maar niets waarbij het op de ene DC wel snel zou zijn en de andere niet.

Iemand die me in de juiste richting van een oplossing kan wijzen?

Wat server resources betreft: CPU gebruik en geheugen gebruik zitten niet tegen de 100% aan, ver van zelfs. Zeker na een reboot, wanneer het geheugen nog geen 20% van de capaciteit inneemt en de CPU onder de 25% blijft is het cmdlet ook traag. Voer ik het cmdlet lokaal uit, op een DC die traag reageert in de scripts, heb ik ook onmiddelijk resultaat. De DC die snel reageert zit in hetzelfde subnet als 2 van de trage DCs, dus daar zit ook geen verschil in bijv. firewall. Verhuizen van ESXi host heeft ook geen effect.

[Vorkie]

It's always DNS.

Staat dat allemaal goed?

[Blokker_1999]

@Vorkie, voor zover ik weet wel. Ik zou het vreemd vinden dat er ineens een DNS issue zou zijn met records die de domaincontrollers zelf beheren. Verder doet het probleem zich ook voor als je specifiek een server mee geeft. En het is niet dat de server niet gevonden wordt. Al weet ik natuurlijk niet of in dat geval de keuze van server ook meegegeven wordt aan de get-aduser die in de achtergrond wordt uitgevoerd voor elke gevonden gebruiker.

[Question Mark]

Hoe ziet je omgeving eruit?

Single domainforest? Meerdere domains in een forest? Alle DC's zijn Global Catalog? Draai eens een DCDIAG op de goed functionerende DC en op een niet-goed functionerende en vergelijk deze eens?

[MAX3400]

Je hebt toch niet stiekem een "management domain" met een trust en sinds kort patches/policies uitgerold waar Kerboros, SMB of LDAP mee geraakt zijn? Het (niet) resolven van delegated groups van forest A naar B kan echt een half uur vertraging leveren.

Vorige week OoB-patch https://learn.microsoft.c...might-become-unresponsive ?

[Voor 13% gewijzigd door MAX3400 op 28-11-2022 13:49]

[Blokker_1999]

Single domain, Alle DCs zijn GC. DCDIAG vertoont niet echt verschillen, al zie ik wel op de ene DC in de systemlog dat er wat veel onbekende subnetten tegen die DC praaten, zal ik ook eens moeten rechtzetten.

Er zijn wel enkele andere domeinen in andere forests waar een trustrelationship mee bestaat maar de groepen die we met powershell benaderen en de gebruikers die erin zitten behoren allemaal tot het domein van de DCs die we aanspreken. En ook daar zou ik dus verwachten dat je geen verschil tussen de DCs zou mogen zien.

Voor zover ik heb kunnen terugvinden in onze changelogs en voor zover ik van mijn collega's gehoord heb zijn er de afgelopen weken ook geen policies aangepast die enige invloed mogen hebben op Kerberos, LDAP, SMB, ... . Enige waar wel wat veranderd is, is de firewall, maar aangezien de goede en een slechte DC in hetzelfde netwerk zitten is het relatief veilig van ook dat uit te sluiten, alhoewel ik toch maar eens die logs ga opvragen, je weet maar nooit.

En die OoB patch lijkt voor Windows client systemen te zijn, het maakt niet uit of we het op een client of een server doen en het systeem zelf blijft ook gewoon responsief, het is enkel het uitvoeren van het cmdlet dat enorm veel tijd in beslag neemt, afhankelijk van de DC die we gebruiken.

[Question Mark]

Post de output van DCDIAG eens, en eens een ipconfig /all van een client?

Werken de scripts/commando's nog wel snel als ze lokaal gedraaid worden?

Verder lijken het virtuele Domain Controllers te zijn op VMware? Wat zijn de cpu-ready waarden van de DC's? (te vinden vanuit VCenter). (ik heb wel vaker rare dingen gezien met overcommited hosts).

[Blokker_1999]

code:

Directory Server Diagnosis

Performing initial setup:

   Trying to find home server...

   Home Server = ******16B

   * Identified AD Forest. 
   Done gathering initial info.

Doing initial required tests
   
   Testing server: *****\******16B

      Starting test: Connectivity

         ......................... ******16B passed test Connectivity

Doing primary tests
  
   Testing server: *****\******16B

      Starting test: Advertising
         ......................... ******16B passed test Advertising

      Starting test: FrsEvent
         ......................... ******16B passed test FrsEvent

      Starting test: DFSREvent
         ......................... ******16B passed test DFSREvent

      Starting test: SysVolCheck
         ......................... ******16B passed test SysVolCheck

      Starting test: KccEvent
         ......................... ******16B passed test KccEvent

      Starting test: KnowsOfRoleHolders
         ......................... ******16B passed test KnowsOfRoleHolders

      Starting test: MachineAccount
         ......................... ******16B passed test MachineAccount

      Starting test: NCSecDesc
         ......................... ******16B passed test NCSecDesc

      Starting test: NetLogons
         [******16B] User credentials does not have permission to perform this operation.
         The account used for this test must have network logon privileges for this machine's domain.
         ......................... ******16B failed test NetLogons

      Starting test: ObjectsReplicated
         ......................... ******16B passed test ObjectsReplicated

      Starting test: Replications
         [Replications Check,******16B] DsReplicaGetInfo(PENDING_OPS, NULL)
         failed, error 0x2105 "Replication access was denied."
         ......................... ******16B failed test Replications

      Starting test: RidManager
         ......................... ******16B passed test RidManager

      Starting test: Services
            Could not open NTDS Service on ******16B, error 0x5
            "Access is denied."
         ......................... ******16B failed test Services

      Starting test: SystemLog

         A warning event occurred.  EventID: 0x000016AF
            Time Generated: 11/28/2022   13:48:43
            Event String:
            During the past 4.23 hours there have been 459 connections to this Domain Controller from client machines whose IP addresses don't map to any of the existing sites in the enterprise. Those clients, therefore, have undefined sites and may connect to any Domain Controller including those that are in far distant locations from the clients. A client's site is determined by the mapping of its subnet to one of the existing sites. To move the above clients to one of the sites, please consider creating subnet object(s) covering the above IP addresses with mapping to one of the existing sites.  The names and IP addresses of the clients in question have been logged on this computer in the following log file '%SystemRoot%\debug\netlogon.log' and, potentially, in the log file '%SystemRoot%\debug\netlogon.bak' created if the former log becomes full. The log(s) may contain additional unrelated debugging information. To filter out the needed information, please search for lines which contain text 'NO_CLIENT_SITE:'. The first word after this string is the client name and the second word is the client IP address. The maximum size of the log(s) is controlled by the following registry DWORD value 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\LogFileMaxSize'; the default is 20000000 bytes.  The current maximum size is 20000000 bytes.  To set a different maximum size, create the above registry value and set the desired maximum size in bytes.
         A warning event occurred.  EventID: 0x80000027
            Time Generated: 11/28/2022   13:49:45
            Event String:
            The Key Distribution Center (KDC) encountered a user certificate that was valid but could not be mapped to a user in a secure way (such as via explicit mapping, key trust mapping, or a SID). Such certificates should either be replaced or mapped directly to the user via explicit mapping. See https://go.microsoft.com/fwlink/?linkid=2189925 to learn more.
         An error event occurred.  EventID: 0x00002720
            Time Generated: 11/28/2022   14:09:41
            Event String:
            The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID 
         An error event occurred.  EventID: 0x00002720
            Time Generated: 11/28/2022   14:30:16
            Event String:
            The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID 
         ......................... ******16B failed test SystemLog

      Starting test: VerifyReferences
         ......................... ******16B passed test VerifyReferences

   Running partition tests on : DomainDnsZones
      Starting test: CheckSDRefDom
         ......................... DomainDnsZones passed test CheckSDRefDom
      Starting test: CrossRefValidation
         ......................... DomainDnsZones passed test
         CrossRefValidation
   
   Running partition tests on : ForestDnsZones
      Starting test: CheckSDRefDom
         ......................... ForestDnsZones passed test CheckSDRefDom
      Starting test: CrossRefValidation
         ......................... ForestDnsZones passed test
         CrossRefValidation
   
   Running partition tests on : Schema
      Starting test: CheckSDRefDom
         ......................... Schema passed test CheckSDRefDom
      Starting test: CrossRefValidation
         ......................... Schema passed test CrossRefValidation
   
   Running partition tests on : Configuration
      Starting test: CheckSDRefDom
         ......................... Configuration passed test CheckSDRefDom
      Starting test: CrossRefValidation
         ......................... Configuration passed test CrossRefValidation
 
   Running partition tests on : domain
      Starting test: CheckSDRefDom
         ......................... domain passed test CheckSDRefDom
      Starting test: CrossRefValidation
         ......................... domain passed test CrossRefValidation
   
   Running enterprise tests on : domain.*****.com
      Starting test: LocatorCheck
         ......................... domain.*****.com passed test
         LocatorCheck
      Starting test: Intersite
         ......................... domain.*****.com passed test Intersite

Heb wat geknipt in de systemlog, we moeten niet meermaals dezelfde melding zien staan. En zie daar wat werk staan waar tot op heden ook nog niemand iets over vermeld heeft

code:

Windows IP Configuration

   Host Name . . . . . . . . . . . . : *********19
   Primary Dns Suffix  . . . . . . . : domain.********.com
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : domain.********.com

Ethernet adapter Ethernet0 2:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : vmxnet3 Ethernet Adapter
   Physical Address. . . . . . . . . : 00-50-56-B5-9C-C4
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 192.168.69.250(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.240.0
   Default Gateway . . . . . . . . . : 192.168.72.101
   DNS Servers . . . . . . . . . . . : 192.168.5.81
                                       192.168.5.82
                                       192.168.153.61
   NetBIOS over Tcpip. . . . . . . . : Disabled

Lokaal op de DC draait het cmdlet snel, specifieer je dan de buurman van de DC dan gaat het traag, tenzij je de enige DC opgeeft die nog snel is met dit cmdlet.



En ja, op de domeincontrollers is de Windows Firewall ook actief, dit omdat deze in een netwerk met andere servers zitten en men bepaalde vormen van verkeer alsnog wenst af te blokken zonder dat we deze onmiddelijk in een apart netwerk moeten zetten.

[Killah_Priest]

Hoe zit het met andere AD Powershell commando's? Ook traag?
En directe LDAP commando's (eventueel via Powershell dmv de adsisearcher)?
De Powershell commando's gaan dmv AD Web services en niet via een directe ldap verbinding.

[ElCondor]

En heb je niet toevallig last van een ciruclaire verwijzing? Dat is in AD namelijk gewoon mogelijk, althans een paar jaar geleden nog. Toen liep een applicatie van ons, die AD groep resolutie deed hierop vast. Vooral omdat je groepen recursief aan het ophalen bent.. Wellicht toch handig om een maxdepth op te geven?