Utföra en Active Directory-domänmigration för Dell Security Server

• Dell Security Management Server (tidigare Dell Data Protection | Enterprise Edition) är upprättad och domänansluten.
• En befintlig domän har lagts till i avsnittet "domän" under WebUI-konsolen.
• Slutpunkter har aktiverats mot servern.
• En migrering av domän krävs.
• Vi planerar även att migrera SID-historiken för AD-objekten.
• Slutpunkter har fullständig anslutning till servern och kan hämta policyer på den gamla domänen innan domänmigreringsprocessen påbörjas.
• Krypterad data på slutpunkterna är fullt tillgängliga, slutpunkterna är aktiverade och det är möjligt att avaktivera och återaktivera dem. Vi kan bekräfta att aktiveringar sker utan problem med hjälp av ett snabbt WSDeactivate av eventuella slutpunkter.

De övergripande stegen är inte alltför komplexa, men det är nödvändigt att förstå att om hela processen inte utförs korrekt kan data gå förlorade eller en återställning av maskiner kan krävas. Även om den här processen kan utföras på alla versioner av Dell Security Management Server och klienten rekommenderar Dell Technologies att du har minst 8.3.0-klienten och 8.5-servern installerade eftersom flera förbättringar har gjorts sedan dess som gör den övergripande migreringsprocessen enklare på Dell Security Management Server-sidan. Nedan följer en översikt över hur den övergripande processen fungerar och några av de mest oroande frågorna.

Det första steget är att förstå om en domänmigrering krävs. Det finns situationer som när ett företag flyttar, till exempel till Office 365 där det räcker med att lägga till ett alias och ange detta som primärt UPN för AD-användarna. Det här är inte en riktig domänmigrering och ingen annan åtgärd krävs för Dell Data Protection | Enterprise Edition-servern än att lägga till det nya aliaset i domänaliaslistan under Inställningar, avsnittet Domänaliaslista . Om en ny domän skapas och AD-objekt måste flyttas från den gamla avvecklade domänen till den nya, är det då en domänmigrering måste planeras.

När en domänmigrering planeras är det första steget att överväga att även migrera SID-historiken. För att domänmigreringen ska lyckas på Dell Security Management Server-sidan måste SID-historiken bevaras, annars anses AD-objekt vara nya för vår Dell Security Management Server, och därför kan vi inte använda samma krypteringsnycklar efter återaktiveringen. Dell måste migrera SID-historiken. Vi går inte igenom hur en domänmigrering utförs eftersom detta inte är en Dell Data Protection | Krypteringsuppgift, men det finns flera verktyg som ADMT från Microsoft som gör det möjligt för en organisation att migrera en domän A till en domän B. Som nämnts ovan krävs en migrering av SID-historik för att vi ska kunna behålla beständigheten när det gäller nycklar. Migrering av SID-historiken innebär att vi lägger till SID-historikattributet i AD för den gamla användarens SID-förmigrering, vilket garanterar kontinuitet i de migrerade objekten.

Som regel på AD-sidan:

• När ett objekt byter namn ändras inte värdet för attributet objectSID (SID). När du flyttar ett objekt från en domän till en annan måste objectSID ändras, eftersom en del av det är domänspecifikt, och det gamla SID läggs till i SIDHistory -attributet (förutsatt att detta är migrerat). Du kan visa SIDHistory med hjälp av ADSI-redigering (du kan visa i hexadecimala eller decimaler). Om det inte finns några värden finns det ingen SID-historik eller så har objektet aldrig flyttats från en annan domän.
• SIDhistory är endast tillgängligt vid migrering av konton mellan domäner eller skogar.

Nedan visas en skärmbild av hur du avgör om SIDHistory har migrerats med hjälp av attributredigeraren:

När vi har bekräftat att SIDHistory av de migrerade användarna och datorerna har också flyttats kan vi gå vidare med Dell Security Management Server-konfigurationen. Om det krävs mer information om hur du utför en domänmigrering och hur du bevarar SID-historiken kan du läsa följande Microsoft-dokumentation:

• https://www.microsoft.com/en-us/download/details.aspx?id=19188
• https://technet.microsoft.com/en-us/library/cc974332(v=WS.10).aspx
• https://technet.microsoft.com/en-us/library/cc974384(v=WS.10).aspx

Nedan visas vad som händer under en domänmigrering på Dell Security Management Server-sidan.

1. På klientsidan:
   • Vi löser användarnas UPN till SID. Vi letar efter deras SID i valvfilen. Vi hittar den inte.
   • Vi fastställer att det rör sig om en ny användare och kontaktar säkerhetsservern och skickar UPN-lösenordet som en vanlig aktiveringsbegäran.
2. På serversidan:
   • Vi får aktiveringsbegäran. Vi kontaktar Active Directory och letar upp UPN. Sedan sorterar vi användaren, som en del av den här sorteringsprocessen märker vi att SID i entitetstabellen inte matchar SID i AD. Vi undersöker SIDHistory för att söka efter SID i vår entitetstabell. Om vi inte hittar den genererar vi ett undantag och aktiveringen misslyckas eftersom vi redan har SCID:t på plats. När vi hittar SID uppdaterar vi entitetstabellen med det nya SID (i UID-delen är den första delen domänen, och vi uppdaterar den och uppdaterar slutpunktsdomändelen).
   • Sedan skickar vi de gamla nycklarna, policyn, DCID osv. till klienten (som om det var en återaktivering).
3. Tillbaka på klienten:
   • Slutpunkten tar emot den här informationen och lägger till en post i filen credsys.vlt om att användaren är aktiverad och att användaren vid den tidpunkten är inloggad som vanligt.

En viktig punkt på Dell Security Management Server-sidan är förståelsen för om en ny domän måste läggas till under webbgränssnittet för att få saker att fungera med nya och gamla användare medan du aktiverar eller återaktiverar.

Vid en domänmigrering lägger vi inte till den nya domänen i Dell Security Management Server-konsolen OM den överordnade rotdomänen för den gamla och nya migrerade domänen finns där. Det räcker att lägga till den nya domänen i form av ett alias under avsnittet "Inställningar", "Domänaliaslista". (Och vi förutsätter att det finns ett dubbelriktat förtroende mellan den överordnade och den nya underordnade domänen.) Tjänstkontot för rotdomänen ska konfigureras, eventuellt i den överordnade domänen. Om vi istället migrerar en domän A.local till B.local och de två domänerna inte är underordnade samma rotdomän eller om de tillhör en annan skog behöver vi en ny domän som läggs till under vår konsol eftersom vi måste binda alla befintliga slutpunkter till den nya domänen och ett nytt tjänstkonto.

Det är viktigt att du förstår ovanstående faktorer om huruvida Dell Security Management Server ska konfigureras korrekt, eftersom vi annars ställs inför flera problem efter migreringen. Det är också viktigt att du förstår vilken typ av förtroende som finns mellan dessa domäner och deras rotdomäner (om sådana finns) och vilken lista över aktuella domäner som finns under Dell Security Management Server-konsolen. Regeln är enkel, om du har någon form av förtroende mellan förälder/barn och har under Dell Data Protection | Enterprise Edition-servern, rotdomänen och aliaset på plats räcker. Annars måste vi lägga till lika många underordnade domäner under Dell Security Management Server som deras verkliga underdomäner och den här regeln gäller även för domänmigrering.

Slutligen, som mer i allmänhet bör vi * aldrig * få läggas till samtidigt en underordnad och överordnad domän som har samma användare potentiellt synlig på båda nivåerna bryta saker för oss. Och att ta bort domänen stöds inte (ännu) fullt ut på Dell Security Management Server-sidan.

Om klienten är på v8.2.1 eller tidigare och servern är på v8.3.1 eller tidigare, WSDeactivate är ett obligatoriskt steg eftersom vi inte bytte namn på slutpunktsdomändelen på serversidan automatiskt. Detta gäller inte för de senaste versionerna av Dell Security Management Server eller slutpunkten.

Gamla domäner kan inte tas bort från Dell Security Management Server-databasen manuellt eller med hjälp av konsolen. Det beror på att Dell Security Management Server söker efter en användare eller grupp och sedan fastställer att det är domänmedlemskap. På grund av det, vad som måste hända när en domän tas bort, bör alla objekt som ingår i den domänen också tas bort. Inget av alternativen stöds i det här skedet. Dell undersöker möjligheten att ändra det här beteendet i framtida versioner av Dell Security Management Server, men i det här skedet är det inte en uppgift som stöds eller är genomförbar. Som en sidoanteckning om vi väljer att markera (manuellt) domänen som borttagen i databasen, börjar vi få ett fel som kastas i serverloggarna var 15:e minut för alla associerade överblivna användare och grupper.

Om skölden avinstalleras på en migrerad slutpunkt krävs samma steg som krävs för att framtvinga en normal återaktivering (icke-domän) mot samma sköld-ID här. I vanliga krypterade filer måste vi tillämpa samma DCID i registret innan vi låter slutpunkten återaktiveras mot Dell Data Protection | Enterprise Edition Server eller Dell Security Management Server. Om det finns några frågor kontaktar du det tekniska supportteamet för att få hjälp.

Nej, en ny domänlicens krävs inte eftersom Dell Data Protection | Enterprise Edition Server 8.x. På äldre versioner av Dell Data Protection | Enterprise Edition Server krävs fortfarande en ny licens. Kontakta det tekniska supportteamet för mer information.