De documentatie van dit product is waar mogelijk geschreven met inclusief taalgebruik. Inclusief taalgebruik wordt in deze documentatie gedefinieerd als taal die geen discriminatie op basis van leeftijd, handicap, gender, etniciteit, seksuele oriëntatie, sociaaleconomische status of combinaties hiervan weerspiegelt. In deze documentatie kunnen uitzonderingen voorkomen vanwege bewoordingen die in de gebruikersinterfaces van de productsoftware zijn gecodeerd, die op het taalgebruik in de RFP-documentatie zijn gebaseerd of die worden gebruikt in een product van een externe partij waarnaar wordt verwezen. Lees meer over hoe Cisco gebruikmaakt van inclusief taalgebruik.
Cisco heeft dit document vertaald via een combinatie van machine- en menselijke technologie om onze gebruikers wereldwijd ondersteuningscontent te bieden in hun eigen taal. Houd er rekening mee dat zelfs de beste machinevertaling niet net zo nauwkeurig is als die van een professionele vertaler. Cisco Systems, Inc. is niet aansprakelijk voor de nauwkeurigheid van deze vertalingen en raadt aan altijd het oorspronkelijke Engelstalige document (link) te raadplegen.
Dit document beschrijft hoe u de functie Cisco Secure Endpoint Identity Persistence kunt gebruiken.
Identity Persistence is een functie waarmee u een consistent gebeurtenissenlogboek kunt bijhouden in virtuele omgevingen of wanneer computers een nieuwe image krijgen. U kunt een Connector koppelen aan een MAC-adres of hostnaam, zodat er niet telkens een nieuwe connector-record wordt gemaakt als een nieuwe virtuele sessie wordt gestart of een computer opnieuw wordt weergegeven. Deze voorziening is specifiek ontworpen voor niet-persistente VM- en Lab-omgevingen en mag niet worden ingeschakeld voor traditionele werkstations- en serverinstellingen.
Cisco raadt kennis van de volgende onderwerpen aan:
Identity Persistence is functionaliteit op beveiligde endpoints die helpt bij de identificatie van beveiligde endpoints ten tijde van de initiële registratie van de connector en deze aanpast aan eerder bekende vermeldingen op basis van identiteitsparameters zoals MAC-adres of Hostname voor die specifieke connector. De implementatie van deze functie helpt niet alleen om een correct aantal licenties te behouden, maar maakt het vooral mogelijk om historische gegevens van niet-persistente systemen correct te volgen.
Het meest gebruikelijke gebruik voor Identity Persistence in virtuele implementaties is niet-persistente virtuele desktopinfrastructuur (VDI). VDI-host desktopomgevingen worden geïmplementeerd op verzoek of behoefte van de eindgebruiker. Hieronder vallen verschillende leveranciers zoals VMware, Citrix, AWS AMI Golden Image Implementation, enzovoort.
Persistente VDI, ook wel 'Stateful VDI' genoemd, is een setup waarbij het bureaublad van elke individuele gebruiker uniek aanpasbaar is en van de ene sessie tot de andere 'blijft'. Voor dit type virtuele implementatie is de functionaliteit van Identity Persistence niet nodig, aangezien deze machines niet bedoeld zijn om regelmatig opnieuw te worden geimaged.
Net als bij alle software die mogelijk kan interageren met de prestaties van het Secure Endpoint, moeten virtuele desktoptoepassingen worden geëvalueerd op mogelijke uitsluitingen om de functionaliteit te maximaliseren en de impact te minimaliseren.
Er zijn twee scenario's die van toepassing kunnen zijn op de implementatie van Identity Persistence op Secure Endpoints fysieke machines:
Onjuiste implementatie van Identity Persistence kan deze problemen/symptomen veroorzaken:
Handmatig implementeren met Identity Persistence ingeschakeld in het beleid.
- Als u het eindpunt handmatig via de opdrachtregel implementeert en Identity Persistence al in het beleid is ingeschakeld, en vervolgens het eindpunt later verwijdert en probeert opnieuw te installeren met het switch uit verschillende groep/beleid, zal het eindpunt automatisch switches naar het oorspronkelijke beleid.
- Uitvoer van SFC-logboeken die de switch van het beleid op het eigen tonen met in 1-10sec
(167656, +0 ms) Dec 14 11:37:17 [1308]: Util::VerifyOsVersion: ret 0
(167656, +0 ms) Dec 14 11:37:17 [1308]: ERROR: ETWEnableConfiguration::IsETWEnabled: ETW not initialized due to incompatibile OS
(167656, +0 ms) Dec 14 11:37:17 [1308]: UiPublisher::PublishPolicyInfo: Name -UTMB-WinServer-Protect Serial 819 << ---------------------- Freshly Installed
(167656, +0 ms) Dec 14 11:37:17 [1308]: UiPublisher::PublishLastPolicyUpdateTime: Publish Last Policy Update time 1670439264
(167656, +0 ms) Dec 14 11:37:17 [1308]: UiPublisher::PublishAgentVersion: Agent Version 7.5.7.21234
(167656, +0 ms) Dec 14 11:37:17 [1308]: HeartBeat::PolicyNotifyCallback: EXIT
(167656, +0 ms) Dec 14 11:37:17 [1308]: AmpkitRegistrationHandler::PolicyCallback: EXIT (0)
.
.
.
(173125, +0 ms) Dec 14 11:37:22 [4704]: AmpkitRegistrationHandler::UpdateConfiguration: Enter
(173125, +0 ms) Dec 14 11:37:22 [4704]: AmpkitRegistrationHandler::UpdateConfiguration: Aborting - not registered
(173125, +0 ms) Dec 14 11:37:22 [4704]: AmpkitRegistrationHandler::ConnectionStateChanged: Starting Proxy Discovery
(173125, +0 ms) Dec 14 11:37:22 [4704]: UIPipe::SendPolicyReloaded sending policy reloaded to UI. ui.data.policy.policyName -UTMB-WinServer-Audit << --------- Auto Switch to Old Policy
(173125, +0 ms) Dec 14 11:37:22 [4704]: PipeSend: sending message to user interface: 28, id: 0
(173125, +0 ms) Dec 14 11:37:22 [4704]: UIPipe::SendStatus: notifying UI: No Product
(173125, +0 ms) Dec 14 11:37:22 [4704]: UIPipe::SendStatus: notifying UI: No Product
(173125, +0 ms) Dec 14 11:37:22 [4704]: UIPipe::SendStatus: notifying UI: No Product
(173125, +0 ms) Dec 14 11:37:22 [4704]: UIPipe::SendStatus : engine1 (0, 0), engine2 (0, 0)
(173125, +0 ms) Dec 14 11:37:22 [4704]: PipeSend: sending message to user interface: 1, id: 0
(173125, +0 ms) Dec 14 11:37:22 [4704]: UiStatusHandler::ConnectionStateChangedState: 0
(173125, +0 ms) Dec 14 11:37:22 [4704]: UiPublisher::PublishConnectionStatus: State 0
(173125, +0 ms) Dec 14 11:37:22 [4704]: AmpApiServer.cpp:AmpApiServer::PublishScanAvailable:223: Cloud connection status 0, Tetra Available 0
(173125, +0 ms) Dec 14 11:37:22 [4704]: AmpkitProxyHelper::LoadProxyFromConfig: Enter
(173125, +0 ms) Dec 14 11:37:22 [4704]: AmpkitProxyHelper::LoadProxyFromConfig proxy server is NULL
(173125, +0 ms) Dec 14 11:37:22 [4704]: AmpkitProxyHelper::LoadProxyFromConfig: Direct connection detected
(173125, +0 ms) Dec 14 11:37:22 [4704]: AmpkitProxyHelper::LoadProxyFromConfig: Exit(1)
(173125, +0 ms) Dec 14 11:37:22 [4704]: UiAgentGuidUpdater::ConnectionStateChanged
(173125, +0 ms) Dec 14 11:37:22 [4704]: UiAgentGuidUpdater::RefreshAgentGuidUi: Agent GUID: e1a756e2-65ab-4cd6-a886-ff826d74f05d
(173125, +0 ms) Dec 14 11:37:22 [4704]: UiPublisher::PublishAgentGuid: Agent GUID did not change (e1a756e2-65ab-4cd6-a886-ff826d74f05d)
(173125, +0 ms) Dec 14 11:37:22 [4704]: AmpkitSubscriptionThread::NotificationWorker: Waiting on queue
De andere bijwerking als u probeert te installeren connector die tot verschillende groep behoort. U ziet in het portal dat de connector is toegewezen aan de juiste groep maar met "verkeerde" originele beleid
Dit komt doordat Identity Persistence (ID SYNC) in feite werkt.
Zonder ID SYNC wanneer de connector volledig is verwijderd of met de switch re-register opdrachtregel. U dient de nieuwe gemaakte datum en connector GUID te zien indien de installatie ongedaan wordt gemaakt of alleen de nieuwe connector GUID indien de opdracht opnieuw wordt geregistreerd. Met ID SYNC is dat echter niet mogelijk. ID SYNC overschrijft met de oude GUID en DATUM. Dat is hoe we de host 'synchroniseren'.
Indien deze kwestie wordt waargenomen, moet de correctie worden geïmplementeerd door middel van de beleidswijziging. U moet de betrokken eindpunten terugbrengen naar de oorspronkelijke groep/het oorspronkelijke beleid en ervoor zorgen dat het beleid gesynchroniseerd wordt. Verplaats de eindpunten vervolgens terug naar de gewenste groep/beleid
Indien u App Volumes gebruikt voor uw VDI-infrastructuur, is het aan te raden dat u deze configuratiewijzigingen aanbrengt in uw snapvol.cfg-configuratie
Deze uitsluitingen moeten worden geïmplementeerd in het bestand snapvol.cfg:
Paden:
Registratiesleutels:
Op x64 systemen, voeg deze toe:
Referenties:
Volg de richtlijnen voor best practices uit het document van de leverancier (VMware, Citrix, AWS, Azure, enzovoort.) wanneer u een Golden Image maakt voor het VDI-kloningproces.
Bijvoorbeeld VMware Golden Image Process: https://docs.vmware.com/en/VMware-Horizon/2106/virtual-desktops/GUID-D9C46AEF-1C41-4711-BF9E-84362EBE6ABF.html.
Aangezien u de VMware hebt geïdentificeerd, start het AWS-samenstellingsproces de gekloonde (Child VM's) meerdere malen opnieuw op voordat de VM-configuratie is voltooid, wat problemen oplevert met het registratieproces voor het beveiligde endpoint, aangezien de gekloonde (Child VM's) op dit moment niet de definitieve/juiste hostnamen hebben toegewezen en de gekloonde (Child VM's) de Golden Image Hostname en de registers van de Secure Endpoint Cloud gebruiken. Dit doorbreekt het kloneringsproces en veroorzaakt problemen.
Dit is geen probleem met het Secure Endpoint-verbindingsproces, maar is incompatibel met het kloonproces en de registratie van Secure Endpoint. Om dit probleem te voorkomen hebben we een aantal wijzigingen vastgesteld die in het kloneringsproces moeten worden aangebracht en die ertoe bijdragen dat deze problemen worden opgelost.
Dit zijn de wijzigingen die op de Golden Image VM moeten worden geïmplementeerd voordat het beeld wordt bevroren om te klonen
1. Gebruik altijd de vlag van Goldenafbeelding op de Gouden Afbeelding ten tijde van de installatie van Secure Endpoint.
2. Voer scripts uit die helpen de Endpoint service alleen in te schakelen wanneer we een definitieve hostnaam hebben geïmplementeerd op de gekloonde (Child VM's). Raadpleeg het gedeelte Problemen met VMware Horizon-duplicatie voor meer informatie.
Wanneer u het installatieprogramma gebruikt, is de vlag voor gouden afbeeldingen /goudafbeelding 1.
De gouden beeldvlag voorkomt dat de connector start en registreert op het basisbeeld; en zo is de connector bij het volgende begin van het beeld in de functionele staat waarin hij is ingesteld door het beleid dat eraan is toegewezen.
Voor meer informatie over andere vlaggen, zie dit artikel.
Installeer het als een gouden beeld. Dit is de typische optie die met de vlag wordt gebruikt en is het enige verwachte gebruik. Hiermee wordt de eerste registratie van de connector en het opstarten bij installatie overgeslagen.
C:\> CiscoInstaller_goldenimage.exe /R /S /goldenimage 1 [other flags here…]
Het is best practice om de connector als laatste te installeren voor de voorbereiding van de Golden Image.
C:\> CiscoInstaller_goldenimage.exe /R /S /goldenimage 1
Nadat Golden Image applicaties heeft geïnstalleerd, is het systeem voorbereid en Secure Endpoint is geïnstalleerd met de / goldenimageflag, is de host klaar om te worden bevroren en gedistribueerd. Zodra de gekloonde host opstart, start Secure Endpoint en registreert deze bij de cloud. Geen verdere actie wordt vereist met betrekking tot het configureren van de connector tenzij er veranderingen zijn die u wilt aanbrengen in het beleid of de host. Als er wijzigingen worden aangebracht nadat de registratie van de gouden afbeelding is voltooid, moet dit proces opnieuw worden gestart.
Dit zijn enkele van de best practices die moeten worden gevolgd wanneer u Identity Persistence implementeert op Secure Endpoint Portal:
1. Het is sterk aanbevolen om afzonderlijke beleidsregels/groepen te gebruiken voor endpoints die compatibel zijn met Identity Persistence voor een eenvoudiger segregatie.
2. Als u van plan bent Endpoint Isolation te gebruiken en de Move Computer to Group te implementeren na een compromitterende actie. De doelgroep moet ook Identity Persistence enabled hebben en mag alleen worden gebruikt voor VDI-computers.
3. Het wordt niet aanbevolen om Identity Persistence in te schakelen op de standaardgroep/het standaardbeleid voor uw organisatie-instellingen, tenzij Identity Persistence is ingeschakeld voor alle beleidsgebieden met Overal in de organisatie als instellingenbereik.
Volg deze stappen om de Secure Endpoint-connector met Identity Persistence te implementeren:
Stap 1. Pas de gewenste instelling voor Identity Persistence toe op uw beleid:
Test - 123
Er zijn vijf opties waaruit u kunt kiezen.
over alle beleidsgebieden in de organisatie die Identity Synchronisation hebben ingesteld op een andere waarde dan Geen. De Connector kan zijn beleid bijwerken om de vorige installatie te weerspiegelen als het verschilt van de nieuwe.
N.B.: Als u Identity Persistence wilt gebruiken, raadt Cisco u aan Hostname te gebruiken via het bedrijfsnetwerk of het beleid. Een machine heeft één hostnaam, maar kan meer dan één MAC-adres hebben en veel VM's klonen de MAC-adressen.
Stap 2. Download de Secure Endpoint Connector.
Stap 3. Connector op endpoints implementeren.
Opmerking: u moet het herverdelbare installatieprogramma selecteren. Dit is een ~57 MB (grootte kan variëren met nieuwere versies) bestand dat zowel de 32- en 64-bits installateurs bevat. Als u de connector op meerdere computers wilt installeren, kunt u dit bestand op een netwerkaandeel plaatsen of het naar alle computers dienovereenkomstig duwen. Het installatieprogramma bevat een bestand policy.xml dat wordt gebruikt als configuratiebestand voor de installatie.
Met VMware Horizon konden we vaststellen dat de Child VM-machines bij het maken ervan meerdere malen opnieuw worden opgestart als onderdeel van het Horizon Compose-proces. Dit veroorzaakt problemen omdat de Secure Endpoint-services ingeschakeld worden wanneer de Child VM's niet klaar zijn (ze hebben niet de definitieve/juiste NetBios-naam toegewezen). Dit veroorzaakt verdere problemen met Secure Endpoint die verwarrend worden en vandaar de procesonderbrekingen. Na verder onderzoek kwam het Engineering Team met een oplossing voor deze incompatibiliteit met het Horizon-proces, waarbij de bijgevoegde scripts op de Golden Image VM moeten worden geïmplementeerd en het post-synchronisatiescript Functionality for VMware Horizon: https://docs.vmware.com/en/VMware-Horizon/2103/published-desktops-applications.pdf.
Dit zou waarschijnlijk het probleem zijn met elke andere leverancier, net als Citrix, AWS, en zo verder en dus kan deze oplossing ook voor hen werken.
Hier zijn de voorbeeldscripts die gebruikt kunnen worden.
rem Turn AMP to manual start
sc config CiscoAMP start=demand
rem Add host name to a system variable that we can check on startup
setx -m AMP_GOLD_HOST %COMPUTERNAME%
echo "Current hostname: %COMPUTERNAME% vs %AMP_GOLD_HOST%"
if "%COMPUTERNAME%" == "%AMP_GOLD_HOST%" ( goto same ) else ( goto notsame )
:same
rem Do nothing as we are still the golden image name
echo "No changes to the AMP service"
goto exit
:notsame
rem Turn AMP to autostart
sc config CiscoAMP start=auto
rem Turn on AMP
sc start CiscoAMP
rem Remove environment variable
REG delete "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment" /F /V AMP_GOLD_HOST
goto exit
:exit
Opmerking: de scripts in dit document worden niet officieel ondersteund door TAC
"Geautomatiseerde desktoppool" selecteren
"Onmiddellijke klonen" selecteren
Het type "Zwevend" selecteren
Namen van desktopgroepen
VMware Horizon Naming Pattern: https://docs.vmware.com/en/VMware-Horizon/2103/virtual-desktops/GUID-26AD6C7D-553A-46CB-B8B3-DA3F6958CD9C.html
Golden Image: Dit is de eigenlijke Golden Image VM.
Snapshot: Dit is het beeld dat u wilt gebruiken om de onderliggende VM te implementeren. Dit is de waarde die wordt bijgewerkt wanneer u de Gouden Afbeelding met om het even welke veranderingen bijwerkt. Rest zijn enkele van de VMware Environment specifieke instellingen.
7. Zoals eerder vermeld, Stap 10. In de wizard staat waar u het scriptpad instelt.
8. Zodra VMware Horizon is voltooid en ingediend, begint de samenstelling en worden de kinder-VM's gemaakt.
Opmerking: raadpleeg de VMware-handleiding voor informatie over deze stappen, maar deze zijn duidelijk.
Vind de Duplicate UUID’s: https://github.com/CiscoSecurity/amp-04-find-duplicate-guids
Verwijder de oude UUID’s van Stale/Old: https://github.com/CiscoSecurity/amp-04-delete-stale-guids
Er zijn een paar veel voorkomende gevallen die ervoor kunnen zorgen dat je dubbel ziet:
1. Als deze stappen zijn gevolgd tijdens de VDI-pool:
2. Gebruiker implementeert het originele gouden beeld met Identity Persistence ingeschakeld in het beleid in de ene groep en verplaatst vervolgens een eindpunt naar een andere groep van het Secure Endpoints-portaal. Vervolgens heeft het de originele opname in de groep ‘verhuisd-naar’, maar maakt het nieuwe kopieën in de oorspronkelijke groep wanneer de VM's opnieuw worden geimaged/opnieuw worden ingezet.
Opmerking: dit is geen uitputtende lijst van scenario's die duplicaten kunnen veroorzaken, maar enkele van de meest voorkomende.
Revisie | Publicatiedatum | Opmerkingen |
---|---|---|
6.0 |
28-Jun-2022 |
Een van de Horizon Screenshots bijgewerkt |
5.0 |
23-Feb-2022 |
Configuratie toegevoegd snapvol-bestand |
4.0 |
17-Nov-2021 |
De informatie op de batchscripts bijgewerkt |
3.0 |
10-Nov-2021 |
Inbegrepen scripts naar de documenttekst. |
2.0 |
10-Nov-2021 |
Eerste vrijgave |
1.0 |
10-Nov-2021 |
Eerste vrijgave |