PowerScale: Udefinert autorisasjonsfeil etter oppgradering til OneFS 9.5 eller nyere for Active Directory-brukere

Hvis en klynge oppgraderes til OneFS 9.5 og verdien for maskinkontoattributtet msDS-SupportedEncryptionTypes er ikke angitt, kan godkjenningen mislykkes. Active Directory-leverandøren kan se ut til å være i en ustilnet tilstand eller kan mangle isi auth Statusutgang.

Som standard er denne verdien satt til 31 (eller 0xF1 i heksadesimal) første gang klyngen kobles til Active Directory. I henhold til veiledningen for sikkerhetskonfigurasjon av OneFS 9.5 på produktsiden for Dell Support PowerScale OneFS har vi mange støttede krypteringstyper for SMB og Kerberos.
 

Figur 1: Verdien for msDS-SupportedEncryptionTypes -attributtet vises som <ikke-angitt>.

Eksempel fra Powershell:

DistinguishedName : CN=NINEFIVEOH,CN=Computers,DC=testdomain,DC=local
DNSHostName       : ninefiveoh.testdomain.local
Enabled           : True
Name              : NINEFIVEOH
ObjectClass       : computer
ObjectGUID        : 8dbed342-6a12-41ff-889f-8249cc39b673
SamAccountName    : NINEFIVEOH$
SID               : S-1-5-21-3532647020-1821455699-3245163308-1110
UserPrincipalName :

Utdataene ovenfor inkluderer ikke et felt for attributtet msDS-SupportedEncryptionTypes, som vanligvis rapporterer en heltallsverdi.

Nedenfor er et eksempel fra en annen klynge der vi ser at den angitte verdien fylles ut for attributtet:

DistinguishedName             : CN=COREBUDDY,CN=Computers,DC=testdomain,DC=local
DNSHostName                   : corebuddy.testdomain.local
Enabled                       : True
msDS-SupportedEncryptionTypes : 31   <<<<<<<<<<<<<<<<
Name                          : COREBUDDY
ObjectClass                   : computer
ObjectGUID                    : e29236a7-cc36-4686-bca9-010ba4143ca3
SamAccountName                : COREBUDDY$
SID                           : S-1-5-21-3532647020-1821455699-3245163308-1104
UserPrincipalName             :

Et annet symptom er at det er spesifikke meldinger som fylles ut /var/log/lsass.d.log Fil som vist nedenfor:

2023-04-14T02:40:07.877593+00:00 <30.3> ninefiveoh-1(id1) lsass[13628]: [lsass] Failed to read msDS-SupportedEncryptionTypes for account CN=NINEFIVEOH,CN=Computers,DC=testdomain,DC=local
2023-04-14T02:40:07.877656+00:00 <30.3> ninefiveoh-1(id1) lsass[13628]: [lsass] Error 40044 (symbol: LW_ERROR_NO_SUCH_DOMAIN) occurred while putting an LDAP connection back in the domain free list.
2023-04-14T02:40:23.903189+00:00 <30.3> ninefiveoh-1(id1) lsass[13628]: [lsass] Failed to read msDS-SupportedEncryptionTypes for account CN=NINEFIVEOH,CN=Computers,DC=testdomain,DC=local
2023-04-14T02:40:23.903268+00:00 <30.3> ninefiveoh-1(id1) lsass[13628]: [lsass] Error 40044 (symbol: LW_ERROR_NO_SUCH_DOMAIN) occurred while putting an LDAP connection back in the domain free list.

For å bekrefte at dette er problemet, må administratoren kontrollere maskinkontoobjektet for klyngen i Active Directory. Dette kan gjøres på en av to måter:

• Åpne Active Directories Users and Computers (ADUC) i en DC.
  1. I det øverste båndet i vinduet velger du Vis og klikker på Avanserte funksjoner.
  2. Høyreklikk på objektet og gå til fanen Attributtredigering og bla for å finne msDS-SupportedEncryptionTypes attributt.
  3. Dobbeltklikk på Attributt-feltet , og undersøk desimaltallet som er rapportert i det nye vinduet.
• Bruk følgende PowerShell-kommando på en DC med riktig maskinkontonavn.

  Get-ADComputer -Identity <machine account name> -Properties msDS-SupportedEncryptionTypes

For de ovennevnte må administratorer bruke en konto i Active Directory med rettigheter på domenenivå for å løse problemet.

Manuell sletting av msDS-SupportedEncryptionTypes -attributtet på maskinkontoobjektet til klyngen resulterer i at Active Directory rapporterer en NULL-verdi. Dette består ikke kontrollene i den nyere koden som en del av en serie med forbedringer for bedre sikkerhetsstøtte.

Eldre klynger som ble med i Active Directory uten å angi denne verdien, kan også være utsatt for dette problemet. Dette er fordi ingen verdi er angitt med mindre en ny bli med i Active Directory ble utført.

Løsning:
Endre attributtet til en annen verdi enn en tom verdi. Et trygt alternativ er å velge standardverdien på 31 eller 24, avhengig av sikkerhetskrav. Dette gjøres via brukergrensesnittet eller Powershell. 

Du finner en liste over verdier og hvilke krypteringstyper de støtter, på Microsofts nettstedblogg.  

Følgende kommando (med riktig maskinkontonavn og heltall satt inn) kan brukes av en Active Directory-administrator på en DC i stedet for brukergrensesnittet til å tilordne en verdi til attributtet.

Set-ADComputer -Identity COMPUTERNAME$ -Add @{'msDS-SupportedEncryptionTypes'="<INTEGER>"}

Eksemplet nedenfor angir msDS-SupportedEncryptionTypes attributtet til standardverdien 31 for klyngemaskinkontoen NINEFIVEOH$:

Set-ADComputer -Identity NINEFIVEOH$ -Add @{'msDS-SupportedEncryptionTypes'="31"}

Når endringene er implementert, må de replikeres til alle domenekontrollere i Active Directory-miljøet. En godkjenningsoppdatering eller målrettet LSASS-omstart på klyngen kan være nødvendig for å fjerne tilstanden etter. 

Dell Engineering har publisert kodeforbedringer i OneFS 9.5.0.3 som løser dette problemet. Administratorer kan fortsatt se at forhåndskontroller for IOCA-oppgradering mislykkes hvis de ikke har en verdi angitt før oppgraderingen. Hvis en administrator har begrenset klyngerettighetene i AD for å endre attributter, MÅ de oppdatere attributtet manuelt før oppgraderingsaktivitet finner sted. Hvis attributtet ikke oppdateres når klyngen ikke har tilstrekkelige rettigheter til å gjøre det, blir data utilgjengelig.

Her er noen anbefalte ressurser relatert til dette emnet som kan være av interesse:

• PowerScale: Slik kjører du IOCA Cluster Analysis Tool 
• Gjeldende korrigeringsfiler for PowerScale OneFS