gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2025-12-27 05:03:31 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-cloud/workspace-security/gws-workspace-sync-

Browse Source
This commit is contained in:
Translator
2025-05-20 06:05:07 +00:00
parent 335415a087
commit 3b0f414161
1 changed files with 7 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
src/pentesting-cloud/workspace-security/gws-workspace-sync-attacks-gcpw-gcds-gps-directory-sync-with-ad-and-entraid/gws-admin-directory-sync.md
View File

@@ -8,8 +8,8 @@ Die hoof verskil tussen hierdie manier om gebruikers met GCDS te sinkroniseer, i
Op die oomblik van hierdie skrywe is hierdie diens in beta en dit ondersteun 2 tipes sinkronisasie: Van **Active Directory** en van **Azure Entra ID:**
- **Active Directory:** Om dit op te stel, moet jy **toegang aan Google tot jou Active Directory-omgewing gee**. En aangesien Google slegs toegang het tot GCP-netwerke (deur **VPC-konnektore**) moet jy 'n konnektor skep en dan jou AD beskikbaar maak vanaf daardie konnektor deur dit in VM's in die GCP-netwerk te hê of deur Cloud VPN of Cloud Interconnect te gebruik. Dan moet jy ook **bewyse** van 'n rekening met lees toegang oor die gids verskaf en 'n **sertifikaat** om via **LDAPS** te kontak.
- **Azure Entra ID:** Om dit te konfigureer, is dit net nodig om **in Azure aan te meld met 'n gebruiker met lees toegang** oor die Entra ID-subskripsie in 'n pop-up wat deur Google gewys word, en Google sal die token met lees toegang oor Entra ID hou.
- **Active Directory:** Om dit op te stel, moet jy **toegang aan Google tot jou Active Directory-omgewing gee**. En aangesien Google slegs toegang het tot GCP-netwerke (via **VPC connectors**), moet jy 'n connector skep en dan jou AD beskikbaar maak vanaf daardie connector deur dit in VM's in die GCP-netwerk te hê of deur Cloud VPN of Cloud Interconnect te gebruik. Dan moet jy ook **akkrediteer** van 'n rekening met lees toegang oor die gids en **sertifikaat** om via **LDAPS** te kontak.
- **Azure Entra ID:** Om dit te konfigureer, is dit net nodig om **in te log in Azure met 'n gebruiker met lees toegang** oor die Entra ID-subskripsie in 'n pop-up wat deur Google gewys word, en Google sal die token met lees toegang oor Entra ID hou.
Sodra dit korrek geconfigureer is, sal albei opsies toelaat om **gebruikers en groepe na Workspace te sinkroniseer**, maar dit sal nie toelaat om gebruikers en groepe van Workspace na AD of EntraID te konfigureer nie.
@@ -18,7 +18,7 @@ Ander opsies wat dit tydens hierdie sinkronisasie sal toelaat, is:
- Stuur 'n e-pos aan die nuwe gebruikers om in te log
- Outomaties hul e-posadres verander na die een wat deur Workspace gebruik word. So as Workspace `@hacktricks.xyz` gebruik en EntraID-gebruikers `@carloshacktricks.onmicrosoft.com` gebruik, sal `@hacktricks.xyz` gebruik word vir die gebruikers wat in die rekening geskep is.
- Kies die **groepe wat die gebruikers bevat** wat gesinkroniseer sal word.
- Kies om **groepe** te sinkroniseer en in Workspace te skep (of dui aan om alle groepe te sinkroniseer).
- Kies om **groepe** te sinkroniseer en in Workspace te skep (of aandui om alle groepe te sinkroniseer).
### Van AD/EntraID -> Google Workspace (& GCP)
@@ -36,12 +36,12 @@ Sodra jy toegang tot die gebruiker binne Workspace het, kan daar 'n paar **toest
#### Aanval op Groepe
Jy moet ook eers uitvind watter groepe gesinkroniseer word. Alhoewel daar die moontlikheid is dat **ALLE** die groepe gesinkroniseer word (aangesien Workspace dit toelaat).
Jy moet ook eers uitvind watter groepe gesinkroniseer word. Alhoewel daar die moontlikheid is dat **ALLE** groepe gesinkroniseer word (aangesien Workspace dit toelaat).
> [!NOTE]
> Let daarop dat selfs al word die groepe en lede in Workspace ingevoer, die **gebruikers wat nie in die gebruikerssinkronisasie gesinkroniseer word nie, sal nie geskep word** tydens groepe sinkronisasie nie, selfs al is hulle lede van enige van die gesinkroniseerde groepe.
As jy weet watter groepe van Azure **toestemmings in Workspace of GCP toegeken word**, kan jy eenvoudig 'n gecompromitteerde gebruiker (of nuut geskep) in daardie groep voeg en daardie toestemmings verkry.
As jy weet watter groepe van Azure **toegangsregte in Workspace of GCP toegeken word**, kan jy eenvoudig 'n gecompromitteerde gebruiker (of nuut geskep) in daardie groep voeg en daardie toestemmings verkry.
Daar is 'n ander opsie om bestaande bevoorregte groepe in Workspace te misbruik. Byvoorbeeld, die groep `gcp-organization-admins@<workspace.email>` het gewoonlik hoë voorregte oor GCP.
@@ -50,8 +50,8 @@ As die sinkronisasie van, byvoorbeeld, EntraID, na Workspace **geconfigureer is
### Van Google Workspace -> AD/EntraID
Let daarop dat Workspace bewese met lees slegs toegang oor AD of EntraID vereis om gebruikers en groepe te sinkroniseer. Daarom is dit nie moontlik om Google Workspace te misbruik om enige verandering in AD of EntraID te maak nie. So **dit is nie moontlik** op hierdie oomblik nie.
Let daarop dat Workspace akkrediteer met lees slegs toegang oor AD of EntraID vereis om gebruikers en groepe te sinkroniseer. Daarom is dit nie moontlik om Google Workspace te misbruik om enige verandering in AD of EntraID te maak nie. So **dit is nie moontlik** op hierdie oomblik nie.
Ek weet ook nie waar Google die AD-bewyse of EntraID-token stoor nie en jy **kan dit nie herstel deur die sinkronisasie te herconfigureer nie** (dit verskyn nie in die webvorm nie, jy moet dit weer gee). Maar vanaf die web kan dit moontlik wees om die huidige funksionaliteit te misbruik om **gebruikers en groepe te lys**.
Ek weet ook nie waar Google die AD-akkrediteer of EntraID-token stoor nie en jy **kan dit nie herstel deur die sinkronisasie te herkonfigureer nie** (dit verskyn nie in die webvorm nie, jy moet dit weer gee). Maar van die web af kan dit moontlik wees om die huidige funksionaliteit te misbruik om **gebruikers en groepe te lys**.
{{#include ../../../banners/hacktricks-training.md}}