PowerScale: Autentiseringsfel för odefinierade attribut efter uppgradering till OneFS 9.5 eller senare för Active Directory-användare

Om ett kluster uppgraderas till OneFS 9.5 och värdet för datorkontoattributet msDS-SupportedEncryptionTypes inte har angetts kan autentiseringen misslyckas. Active Directory-providern kan verka vara i ett oformaterat tillstånd eller så saknas den i isi auth statusutgång.

Som standard är det här värdet inställt på 31 (eller 0xF1 hexadecimalt) när klustret först ansluts till Active Directory. Enligt säkerhetskonfigurationsmanualen för OneFS 9.5, som finns på Dells supportproduktsida för PowerScale OneFS, har vi många krypteringstyper som stöds för SMB och Kerberos.
 

Bild 1: Värdet för msDS-SupportedEncryptionTypes Attributet visas som <inte har angetts>.

Exempel från 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 :

Ovanstående utdata innehåller inte något fält för attributet msDS-SupportedEncryptionTypes, som vanligtvis rapporterar ett heltalsvärde.

Nedan visas ett exempel från ett annat kluster där vi ser att det angivna värdet fylls i för attributet:

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             :

Ett annat symptom är att det finns specifika meddelanden som fylls i /var/log/lsass.d.log filen enligt nedan:

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.

För att bekräfta att det här är problemet måste administratören kontrollera datorkontoobjektet för klustret i Active Directory. Detta kan göras på ett av två sätt:

• Öppna Active Directories Users and Computers (ADUC) på en domänkontrollant.
  1. I det övre menyfliksområdet i fönstret väljer du Visa och klickar på Avancerade funktioner.
  2. Högerklicka på objektet och gå till fliken Attributredigerare och bläddra för att hitta msDS-SupportedEncryptionTypes attribut.
  3. Dubbelklicka på fältet Attribut och undersök decimaltalet som rapporteras i det nya fönstret.
• Använd följande PowerShell-kommando på en domänkontrollant med rätt datorkontonamn.

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

För ovanstående måste administratörer använda ett konto i Active Directory med behörighet på domännivå för att lösa problemet.

Manuell borttagning av msDS-SupportedEncryptionTypes -attributet för datorkontoobjektet i klustret resulterar i att Active Directory rapporterar ett NULL-värde. Detta misslyckas med kontrollerna i den nyare koden som en del av en uppsättning förbättringar för bättre säkerhetsstöd.

Äldre kluster som har anslutit till Active Directory utan att ange det här värdet kan också vara mottagliga för det här problemet. Det beror på att inget värde anges om inte en återanslutning till Active Directory har utförts.

Lösning:
Ändra attributet till ett annat värde än ett tomt värde. Ett säkert alternativ är att välja standardvärdet 31 eller 24, beroende på säkerhetskraven. Detta görs via användargränssnittet eller av Powershell. 

En lista med värden och vilka krypteringstyper de stöder finns på bloggen Microsofts webbplats.  

Följande kommando (med rätt datorkontonamn och heltal infogat) kan användas av en Active Directory-administratör på en domänkontrollant i stället för användargränssnittet för att tilldela ett värde till attributet.

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

I exemplet nedan anges msDS-SupportedEncryptionTypes attributet till standardvärdet 31 för klusterdatorkontot NINEFIVEOH$:

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

När ändringarna har tillämpats måste de replikeras till alla domänkontrollanter i Active Directory-miljön. En autentiseringsuppdatering eller riktad LSASS-omstart i klustret kan vara nödvändig för att rensa villkoret efter. 

Dell Engineering har publicerat kodförbättringar i OneFS 9.5.0.3 som åtgärdar problemet. Administratörer kan fortfarande se att IOCA-uppgraderingsförkontroller misslyckas om de inte har angett något värde före uppgraderingen. Om en administratör har begränsat klusterbehörigheterna i AD för att ändra attribut MÅSTE de uppdatera attributet manuellt innan någon uppgraderingsaktivitet äger rum. Om attributet inte uppdateras före uppgraderingen när klustret inte har tillräcklig behörighet för att göra det blir data otillgängliga.

Här är några rekommenderade resurser relaterade till det här ämnet som kan vara av intresse:

• PowerScale: Så här kör du IOCA Cluster Analysis Tool 
• Aktuella korrigeringsfiler för PowerScale OneFS