# GWS - Admin Directory Sync

{{#include ../../../banners/hacktricks-training.md}}

## Basiese Inligting

Die hoof verskil tussen hierdie manier om gebruikers met GCDS te sinkroniseer, is dat GCDS handmatig gedoen word met 'n paar binaries wat jy moet aflaai en uitvoer terwyl **Admin Directory Sync sonder 'n bediener** deur Google bestuur word in [https://admin.google.com/ac/sync/externaldirectories](https://admin.google.com/ac/sync/externaldirectories).

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 (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.

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 aandui om alle groepe te sinkroniseer).

### Van AD/EntraID -> Google Workspace (& GCP)

As jy daarin slaag om 'n AD of EntraID te kompromitteer, sal jy totale beheer oor die gebruikers & groepe hê wat gesinkroniseer gaan word met Google Workspace.\
Let egter daarop dat die **wagwoorde** wat die gebruikers in Workspace mag gebruik **die dieselfde kan wees of nie**.

#### Aanval op gebruikers

Wanneer die sinkronisasie plaasvind, kan dit **alle gebruikers van AD of net diegene van 'n spesifieke OU** sinkroniseer of net die **gebruikers wat lede van spesifieke groepe in EntraID is**. Dit beteken dat om 'n gesinkroniseerde gebruiker aan te val (of 'n nuwe een te skep wat gesinkroniseer word), jy eers moet uitvind watter gebruikers gesinkroniseer word.

- Gebruikers mag **die wagwoord hergebruik of nie van AD of EntraID nie**, maar dit beteken dat jy die **wagwoorde van die gebruikers moet kompromitteer om in te log**.
- As jy toegang het tot die **e-posse** van die gebruikers, kan jy **die Workspace-wagwoord van 'n bestaande gebruiker verander**, of **'n nuwe gebruiker skep**, wag totdat dit gesinkroniseer word en die rekening opstel.

Sodra jy toegang tot die gebruiker binne Workspace het, kan daar 'n paar **toestemmings standaard gegee word**.

#### Aanval op Groepe

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 **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.

As die sinkronisasie van, byvoorbeeld, EntraID, na Workspace **geconfigureer is om die domein** van die ingevoerde objek **met die e-pos van Workspace te vervang**, sal dit moontlik wees vir 'n aanvaller om die groep `gcp-organization-admins@<entraid.email>` in EntraID te skep, 'n gebruiker in hierdie groep toe te voeg, en wag totdat die sinkronisasie van al die groepe plaasvind.\
**Die gebruiker sal in die groep `gcp-organization-admins@<workspace.email>` bygevoeg word, wat voorregte in GCP opgradeer.**

### Van Google Workspace -> AD/EntraID

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-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}}
