Een Active Directory Domain-migratie uitvoeren voor Dell Security Server

• Dell Security Management Server (voorheen Dell Data Protection | Enterprise Edition) is opgericht en domein toegevoegd.
• Er is een bestaand domein toegevoegd aan het gedeelte 'domein' onder de WebUI-console.
• Eindpunten zijn geactiveerd tegen de server.
• Er is een domeinmigratie vereist.
• We zijn van plan om ook de SID-geschiedenis van de AD-objecten te migreren.
• Eindpunten hebben volledige connectiviteit met de server en kunnen beleidsregels voor het oude domein ophalen voordat het domeinmigratieproces wordt gestart.
• Versleutelde data op de endpoints zijn volledig toegankelijk, endpoints zijn geactiveerd en het is mogelijk om ze te deactiveren en opnieuw te activeren. We kunnen bevestigen dat activeringen zonder problemen plaatsvinden met behulp van een snelle WSDeactivate van alle eindpunten.

De algemene stappen zijn niet al te complex, maar het is vereist om te begrijpen dat als het hele proces niet goed wordt uitgevoerd, gegevens verloren kunnen gaan of dat een herstel van machines nodig kan zijn. Tot slot, hoewel dit proces kan worden uitgevoerd op elke versie van Dell Security Management Server en client, raadt Dell Technologies aan om ten minste 8.3.0 client en 8.5 server te installeren, omdat er sindsdien verschillende verbeteringen zijn aangebracht die het algehele migratieproces gemakkelijker maken aan de kant van Dell Security Management Server. Hieronder vindt u een overzicht van hoe het algehele proces werkt en enkele van de meest verontrustende vragen.

De eerste stap is om te begrijpen of een domeinmigratie vereist is. Er zijn situaties, bijvoorbeeld wanneer een bedrijf overstapt op Office 365, waarin het voldoende is om een alias toe te voegen en deze in te stellen als de primaire UPN voor de AD-gebruikers. Dit is geen echte domeinmigratie en er is geen andere actie vereist voor Dell Data Protection | Enterprise Edition server dan het toevoegen van de nieuwe alias aan de lijst met domeinalias onder Instellingen, sectie Lijst met domeinalias . Als er een nieuw domein wordt gemaakt en AD-objecten moeten worden verplaatst van het oude buiten gebruik gestelde domein naar het nieuwe, moet een domeinmigratie worden gepland.

Wanneer een domeinmigratie is gepland, is de eerste stap om te overwegen om ook de SID-geschiedenis te migreren. Om de domeinmigratie aan de Dell Security Management Server kant te laten slagen, is het vereist om de SID-geschiedenis te behouden, anders worden AD-objecten beschouwd als nieuw voor onze Dell Security Management Server, en daarom kunnen we na heractivering geen gebruik maken van dezelfde coderingssleutels. Dell vereist om de SID-geschiedenis te migreren. We gaan geen tijd besteden aan hoe een domeinmigratie wordt uitgevoerd, omdat dit geen Dell Data Protection | Versleutelingstaak, maar er zijn verschillende tools in de buurt, zoals ADMT van Microsoft, waarmee een organisatie een domein A naar een domein B kan migreren. Zoals hierboven vermeld, is een migratie van de SID-geschiedenis vereist om persistentie in termen van sleutels te behouden. Het migreren van de SID-geschiedenis betekent dat we het SID-geschiedenisattribuut in AD van de SID-premigratie van de oude gebruiker uitbreiden, waardoor de continuïteit in de gemigreerde objecten wordt gegarandeerd.

Als regel aan de AD-kant:

• Wanneer de naam van een object wordt gewijzigd, wordt de waarde van het objectSID-attribuut (de SID) niet gewijzigd. Wanneer u een object van het ene domein naar het andere verplaatst, moet de objectSID worden gewijzigd, omdat een deel ervan domeinspecifiek is en de oude SID wordt toegevoegd aan de SIDHistory attribuut (ervan uitgaande dat dit wordt gemigreerd). U kunt bekijken SIDHistory met behulp van ADSI Edit (u kunt weergeven in hexadecimaal of decimaal). Als er geen waarden zijn, is er geen SID-geschiedenis of is het object nooit verplaatst vanuit een ander domein.
• SIDhistory is alleen beschikbaar bij het migreren van accounts tussen domeinen of forests.

Hieronder ziet u een screenshot van hoe u kunt bepalen of de SIDHistory is gemigreerd met behulp van de attribuuteditor:

Zodra we hebben bevestigd dat de SIDHistory van de gemigreerde gebruikers en computers zijn ook verplaatst, kunnen we verder gaan met de configuratie van Dell Security Management Server. Als er meer informatie nodig is over het uitvoeren van een domeinmigratie en het behouden van de SID-geschiedenis, raadpleegt u de volgende Microsoft-documentatie:

• 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

Hieronder ziet u wat er gebeurt tijdens een domeinmigratie aan de kant van Dell Security Management Server.

1. Aan de clientzijde:
   • We lossen de UPN van gebruikers op in de SID. We zoeken hun SID in het kluisbestand. We vinden het niet.
   • We besluiten dat dit een nieuwe gebruiker is en nemen contact op met de beveiligingsserver, waarbij we het UPN-wachtwoord doorgeven als een typisch activeringsverzoek.
2. Aan de serverkant:
   • We krijgen het activeringsverzoek. We nemen contact op met Active Directory en zoeken de UPN op. Vervolgens triageren we de gebruiker. Als onderdeel van dit triageproces merken we dat de SID in de entiteitstabel niet overeenkomt met de SID in AD. We onderzoeken de SIDHistory om te controleren op de SID in onze entiteitstabel. Als we deze niet vinden, gooien we een uitzondering en mislukt de activering omdat we die SCID al hebben. Wanneer we de SID vinden, werken we de entiteitentabel bij met de nieuwe SID (in het UID-gedeelte is het eerste deel het domein, en we werken het bij en werken het eindpuntdomeingedeelte bij).
   • Vervolgens geven we de oude sleutels, policy, DCID, enzovoort door aan de client (alsof het een heractivering is).
3. Terug naar de client:
   • Het eindpunt ontvangt deze informatie en voegt een vermelding toe aan het bestand credsys.vlt dat de gebruiker is geactiveerd en dat de gebruiker op dat moment is aangemeld zoals normaal.

Een belangrijk punt aan de kant van Dell Security Management Server is inzicht in de vraag of er een nieuw domein moet worden toegevoegd onder de WebUI om dingen werkend te krijgen met nieuwe en oude gebruikers tijdens het activeren of opnieuw activeren.

Bij een domeinmigratie voegen we het nieuwe domein niet toe aan de Dell Security Management Server console ALS het hoofddomein van het oude en nieuwe gemigreerde domein aanwezig is. Het is voldoende om het nieuwe domein toe te voegen in de vorm van een alias onder de sectie 'Instellingen', 'Domeinaliaslijst'. (En we gaan ervan uit dat er een bidirectioneel vertrouwen is tussen het bovenliggende en het nieuwe onderliggende domein.) Het serviceaccount voor het hoofddomein moet mogelijk in het bovenliggende domein worden ingesteld. Als we in plaats daarvan een domein A.local migreren naar B.local en de twee domeinen zijn niet onderliggend aan hetzelfde hoofddomein of ze behoren tot een ander forest, dan hebben we een nieuw domein nodig dat wordt toegevoegd onder onze console, omdat we alle bestaande eindpunten moeten koppelen aan het nieuwe domein en een nieuw serviceaccount.

Het begrijpen van het bovenstaande boven het correct configureren van Dell Security Management Server is een belangrijk punt, omdat we anders na de migratie met verschillende problemen worden geconfronteerd. Inzicht in het soort vertrouwen dat bestaat tussen deze domeinen en hun hoofddomeinen (indien van toepassing) en wat hun huidige domeinenlijst is onder de Dell Security Management Server console is ook essentieel. De regel is eenvoudig: als u een soort van vertrouwen hebt tussen de ouder en het kind, dan moet u onder Dell Data Protection | Enterprise Edition server het hoofddomein en de aliassen op hun plaats is voldoende. Anders moeten we net zoveel onderliggende domeinen toevoegen onder Dell Security Management Server als hun echte subdomeinen en deze regel is ook van toepassing op domeinmigratie.

Ten slotte, omdat we in het algemeen *nooit* tegelijkertijd een onderliggend en bovenliggend domein zouden moeten toevoegen, omdat het hebben van dezelfde gebruiker, mogelijk zichtbaar op beide niveaus, dingen voor ons kapot maakt. En het verwijderen van een domein is (nog) geen volledig ondersteunde taak aan de kant van Dell Security Management Server.

Als de client v8.2.1 of eerder gebruikt en de server v8.3.1 of eerder, WSDeactivate is een vereiste stap omdat we de naam van het eindpuntdomeingedeelte niet automatisch aan de serverzijde hebben gewijzigd. Dit is niet het geval op de nieuwste versies van onze Dell Security Management Server of eindpunt.

Oude domeinen kunnen niet handmatig of met behulp van de console uit de Dell Security Management Server database worden verwijderd. Dit komt doordat Dell Security Management Server een gebruiker of groep opzoekt en vervolgens bepaalt dat het om een domeinlidmaatschap gaat. Daarom, wat er moet gebeuren wanneer een domein wordt verwijderd, moeten alle objecten die deel uitmaken van dat domein ook worden verwijderd. Geen van beide opties wordt in dit stadium ondersteund. Dell onderzoekt hoe dit gedrag kan worden gewijzigd in toekomstige builds van Dell Security Management Server, maar in dit stadium is dit geen ondersteunde of haalbare taak. Even terzijde: als we ervoor kiezen om het domein (handmatig) te markeren als verwijderd in de database, krijgen we elke 15 minuten een foutmelding in de serverlogboeken voor alle bijbehorende verweesde gebruikers en groepen.

Als het schild op een gemigreerd eindpunt wordt verwijderd, zijn hier dezelfde stappen nodig die nodig zijn om een normale (niet-domein) heractivering af te dwingen tegen dezelfde Shield-ID. In vaak versleutelde bestanden moeten we dezelfde DCID in het register afdwingen voordat we het eindpunt opnieuw laten activeren tegen de Dell Data Protection | Enterprise Edition Server of Dell Security Management Server. Als er vragen zijn, neem dan contact op met het technische ondersteuningsteam voor meer hulp.

Nee, een nieuwe domeinlicentie is niet vereist omdat Dell Data Protection | Enterprise Edition Server 8.x. Op oudere versies van Dell Data Protection | Enterprise Edition Server, is nog steeds een nieuwe licentie vereist. Neem contact op met het technische ondersteuningsteam voor meer informatie.