VNX: DOMAIN_CONTROLLER_NOT_FOUND na het upgraden van code die SMB2 beveiligde kanaalcommunicatie ondersteunt

Code is geüpgraded naar een van de hierboven vermelde versies.

Na het upgraden naar een van de volgende codes, verschenen er foutmeldingen in de logboeken die aangeven dat de domeincontroller niet beschikbaar was:
VNX2:
8.1.9.211
VNX1:
7.1.82.0

Het bericht ziet er als volgt uit:

2017-06-20 20:51:27: SMB: 3:[NASSERVER1] OpenAndBind[LSA] DC=DC01 failed: Bind_OpenXFailed DOMAIN_CONTROLLER_NOT_FOUND

De bovengenoemde codes zijn allemaal toegevoegd in een nieuwe functie waarmee de NAS-server of datamover kan communiceren met de domeincontrollers in SMB2. Voorafgaand aan deze code werd de communicatie met de domeincontroller allemaal afgehandeld in SMB1 (hoewel klanten nog steeds met ons konden praten in SMB2/SMB3).
Met de verandering naar SMB2 zijn onze opdrachten niet allemaal geserialiseerd naar de domeincontrollers. Dit lijkt ertoe te leiden dat sommige opdrachten tegelijkertijd parallel worden uitgevoerd.
Een voorbeeld is de poging om de benoemde lsarpc named pipe te openen.

In deze foutmelding is het belangrijk om de service te noteren waaraan we proberen te koppelen:

2017-06-20 20:51:27: SMB: 3:[NASSERVER1] OpenAndBind[LSA] DC=DC01 failed: Bind_OpenXFailed DOMAIN_CONTROLLER_NOT_FOUND

In de foutmelding kunnen we zien dat het LSA probeert te openen (rood gemarkeerd). Dit is waar het probleem om de hoek komt kijken. We proberen de lsarpc named pipe meerdere keren tegelijk te openen voordat we een reactie van de DC ontvangen. De eerste aanvraag is succesvol, maar de volgende mislukt. We zien de foutmeldingen die aangeven dat er STATUS_PIPE_NOT_AVAILABLE is en registreren het DOMAIN_CONTROLLER_NOT_FOUND bericht in de logboeken.

Het is belangrijk op te merken dat deze berichten dit probleem niet altijd aangeven. DOMAIN_CONTROLLER_NOT_FOUND fouten kunnen vele oorzaken hebben.
Deze specifieke heeft waarschijnlijk veel van de volgende informatieve berichten in de logboeken:

2017-06-28 14:37:45: 26041909248: SMB: 6:[NASSERVER1] sendLookupSIDs pipe lsarpc reopened
2017-06-28 14:37:47: 26041909248: SMB: 6:[NASSERVER1] sendLookupSIDs pipe lsarpc reopened

Als er vragen zijn over de vraag of het probleem al dan niet overeenkomt met het probleem, kan dit worden bevestigd in een pakkettracering. In de trace zien we meerdere gelijktijdige verzoeken om lsarpc te openen voordat een antwoord op een van deze aanvragen wordt ontvangen, gevolgd door de eerste die slaagt en de volgende mislukt met STATUS_PIPE_NOT_AVAILABLE wanneer de DC reageert.

Dit probleem doet zich vooral voor bij systemen waarvoor veel SID-zoekopdrachten op de domeincontroller nodig zijn. Als er zwevende SID's in de omgeving zijn, heeft deze de neiging om veel meer van deze fouten te registreren. Dit komt door de hoeveelheid verkeer die naar de DC wordt gestuurd, elke keer dat een ACL wordt geopend, moeten we een verzoek naar de DC sturen om de identiteit te vragen van SID's die we niet in onze SID-cache hebben. Verweesde SID's bevinden zich nooit in de SID-cache en er wordt elke keer geprobeerd ze op te zoeken, waardoor het aantal openingen dat we moeten doen voor de lsarpc met de naam pijp toeneemt.

Aangezien de eerste open poging slaagt, is dit een gebeurtenis zonder impact en kunnen deze berichten worden genegeerd.

Permanente oplossing:
Engineering is op de hoogte van het probleem en werkt aan een oplossing in een toekomstige release van code. Dit is een niet-storend probleem en kan in de tussentijd veilig worden genegeerd. Als u echter wilt proberen het bericht te verminderen of te elimineren, zijn er enkele tijdelijke oplossingen beschikbaar.

Tijdelijke oplossing 1:
Er zijn een aantal manieren om te proberen te voorkomen dat deze berichten in de logboeken worden weergegeven. Aangezien meerdere gelijktijdige open pogingen op de lsarpc-pijp het probleem veroorzaken, is de eenvoudigste manier om de berichten te verminderen het verminderen van het aantal benodigde SID-lookups.

Verweesde SID's veroorzaken deze overmatige lookups. De volgende parameter kan worden gewijzigd om lookups te forceren om naar de secmap-cache te kijken voor onbekende sids en zou de hoeveelheid verkeer naar de DC moeten verminderen:

[nasadmin@CS0 ~]$ server_param server_2 -f cifs -i acl.mappingErrorAction -v
server_2 :
name                    = acl.mappingErrorAction
facility_name           = cifs
default_value           = 8
current_value           = 8
configured_value        = 8
user_action             = none
change_effective        = immediate
range                   = (0,31)
description             = Define rules for an unknown SID/UID/GID mapping

detailed_description
Defines the rules for unknown mapping between SID/UID/GID on ACL settings. Two kinds of errors might occur: the SID set in the ACL is unknown to the Domain Controllers we are using, or the username is not yet mapped to a UID/GID. 0x01: Stores unknown sid. 0x02: Stores sid with no UNIX mapping. 0x04: Enables debug traces. 0x08: Only do lookup in cache (secmap or globalSid cache or per connection SID cache) 0x08 is HIGHLY RECOMMENDED WITH OPTION=0x01. 0x10: Disable log displayed when an unknown SID resolution takes too much time.Maximum value = 0x1F Refer to param cifs.acl.retryAuthSID

Dit vertaalt zich in de volgende info:
Bit0 = Slaat onbekende sid op.
Bit1 = Slaat sid op zonder UNIX-toewijzing.
Bit2 = Schakelt foutopsporingstraceringen in.
Bit3 = Alleen opzoeken in cache (secmap of globalSid-cache of per verbinding SID-cache)

Als bits 0 en 1 zijn ingesteld (0x3 als waarde), dan mogen zwevende SID's worden opgeslagen op ACL's van het bestandssysteem (standaard zijn ze dat niet). Er zou worden voorgesteld om de waarde te wijzigen van 0x3 naar 0x11, dit schakelt bit 0,1 en 3 in. Dit betekent dat onbekende SID's worden opgeslagen zonder unix-toewijzing en alleen in secmap en globale SID-caches wordt gekeken. Als het is ingesteld op 0x8 of een andere combinatie waarbij bits 0 en 1 zijn uitgeschakeld, mogen weeswiegen niet worden opgeslagen en moet deze parameter niet worden gewijzigd.

Als u de parameter wilt wijzigen, kunt u de volgende opdracht uitvoeren:

server_param server_2 -f cifs -m acl.mappingErrorAction -v 11

Dit vermindert waarschijnlijk de voorvallen, maar kan ze al dan niet volledig elimineren.

Tijdelijke oplossing 2:
De trefzekere manier om van deze fouten in de logs af te komen, is door het DC-communicatiegedrag terug te zetten naar wat het was vóór de nieuwe codes (wat betekent dat we alleen met de domeincontrollers in SMB1 praten).

Als u wilt terugkeren naar SMB1 voor gelijkstroomcommunicatie (het oude VNX-gedrag), neemt u contact op met Dell Support en raadpleegt u dit Knowledge Base-artikel.