Mencipta Pengguna Google daripada PowerShell melalui API
Hello!
Artikel ini akan menerangkan pelaksanaan interaksi PowerShell dengan API Google untuk memanipulasi pengguna G Suite.
Kami menggunakan beberapa perkhidmatan dalaman dan awan di seluruh organisasi. Untuk sebahagian besar, kebenaran di dalamnya datang kepada Google atau Active Directory, yang antaranya kami tidak dapat mengekalkan replika; oleh itu, apabila pekerja baharu keluar, anda perlu membuat/mendayakan akaun dalam kedua-dua sistem ini. Untuk mengautomasikan proses, kami memutuskan untuk menulis skrip yang mengumpul maklumat dan menghantarnya ke kedua-dua perkhidmatan.
Kebenaran
Semasa menyediakan keperluan, kami memutuskan untuk menggunakan pentadbir manusia sebenar untuk kebenaran; ini memudahkan analisis tindakan sekiranya berlaku perubahan besar-besaran yang tidak disengajakan atau disengajakan.
API Google menggunakan protokol OAuth 2.0 untuk pengesahan dan kebenaran. Kes penggunaan dan penerangan yang lebih terperinci boleh didapati di sini: Menggunakan OAuth 2.0 untuk Mengakses Google API.
Saya memilih skrip yang digunakan untuk kebenaran dalam aplikasi desktop. Terdapat juga pilihan untuk menggunakan akaun perkhidmatan, yang tidak memerlukan pergerakan yang tidak perlu daripada pengguna.
Gambar di bawah ialah penerangan skematik senario yang dipilih daripada halaman Google.
Mula-mula, kami menghantar pengguna ke halaman pengesahan Akaun Google, dengan menyatakan parameter GET:
id permohonan
kawasan yang aplikasi memerlukan akses
alamat di mana pengguna akan diubah hala selepas menyelesaikan prosedur
cara kami akan mengemas kini token
Kod keselamatan
format penghantaran kod pengesahan
Selepas kebenaran selesai, pengguna akan diubah hala ke halaman yang dinyatakan dalam permintaan pertama, dengan ralat atau kod kebenaran yang diluluskan oleh parameter GET
Aplikasi (skrip) perlu menerima parameter ini dan, jika menerima kod, buat permintaan berikut untuk mendapatkan token
Jika permintaan itu betul, API Google mengembalikan:
Token akses yang dengannya kami boleh membuat permintaan
Tempoh sah token ini
Token muat semula diperlukan untuk memuat semula token Akses.
Mula-mula anda perlu pergi ke konsol API Google: Bukti kelayakan - Konsol API Google, pilih aplikasi yang dikehendaki dan dalam bahagian Bukti kelayakan buat pengecam OAuth klien. Di sana (atau kemudian, dalam sifat pengecam yang dibuat) ββanda perlu menentukan alamat yang dibenarkan pengalihan. Dalam kes kami, ini akan menjadi beberapa entri localhost dengan port yang berbeza (lihat di bawah).
Untuk menjadikannya lebih mudah untuk membaca algoritma skrip, anda boleh memaparkan langkah pertama dalam fungsi berasingan yang akan mengembalikan token Akses dan muat semula untuk aplikasi:
Kami menetapkan ID Pelanggan dan Rahsia Pelanggan yang diperoleh dalam sifat pengecam klien OAuth dan pengesah kod ialah rentetan 43 hingga 128 aksara yang mesti dijana secara rawak daripada aksara yang tidak disimpan: [AZ] / [az] / [0-9 ] / "-" / "." / "_" / "~".
Kod ini kemudiannya akan dihantar semula. Ia menghapuskan kelemahan di mana penyerang boleh memintas respons yang dikembalikan sebagai ubah hala selepas kebenaran pengguna.
Anda boleh menghantar pengesah kod dalam permintaan semasa dalam teks yang jelas (yang menjadikannya tidak bermakna - ini hanya sesuai untuk sistem yang tidak menyokong SHA256), atau dengan membuat cincang menggunakan algoritma SHA256, yang mesti dikodkan dalam BASE64Url (berbeza dari Base64 dengan dua aksara jadual) dan mengalih keluar pengakhiran baris aksara: =.
Seterusnya, kita perlu mula mendengar http pada mesin tempatan untuk menerima respons selepas kebenaran, yang akan dikembalikan sebagai ubah hala.
Tugas pentadbiran dilakukan pada pelayan khas, kami tidak boleh menolak kemungkinan bahawa beberapa pentadbir akan menjalankan skrip pada masa yang sama, jadi ia akan secara rawak memilih port untuk pengguna semasa, tetapi saya menetapkan port yang telah ditetapkan kerana ia juga mesti ditambah seperti yang dipercayai dalam konsol API.
access_type=luar talian bermakna aplikasi boleh mengemas kini token tamat tempoh sendiri tanpa interaksi pengguna dengan penyemak imbas, response_type=code menetapkan format bagaimana kod itu akan dikembalikan (rujukan kepada kaedah kebenaran lama, apabila pengguna menyalin kod daripada penyemak imbas ke dalam skrip), skop menunjukkan skop dan jenis akses. Ia mesti dipisahkan oleh ruang atau % 20 (mengikut Pengekodan URL). Senarai kawasan akses dengan jenis boleh dilihat di sini: Skop OAuth 2.0 untuk API Google.
Selepas menerima kod kebenaran, aplikasi akan mengembalikan mesej rapat kepada penyemak imbas, berhenti mendengar pada port dan menghantar permintaan POST untuk mendapatkan token. Kami menunjukkan di dalamnya id dan rahsia yang dinyatakan sebelum ini daripada API konsol, alamat yang pengguna akan diubah hala dan grant_type mengikut spesifikasi protokol.
Sebagai tindak balas, kami akan menerima token Akses, tempoh sahnya dalam beberapa saat dan token Muat Semula, yang dengannya kami boleh mengemas kini token Akses.
Aplikasi mesti menyimpan token di tempat yang selamat dengan jangka hayat yang panjang, jadi sehingga kami membatalkan akses yang diterima, token muat semula tidak akan dikembalikan kepada aplikasi. Pada akhirnya, saya menambah permintaan untuk membatalkan token; jika permohonan tidak berjaya diselesaikan dan token muat semula tidak dikembalikan, ia akan memulakan prosedur semula (kami menganggap tidak selamat untuk menyimpan token secara setempat pada terminal, dan kami tidak tidak mahu merumitkan perkara dengan kriptografi atau membuka penyemak imbas dengan kerap).
Seperti yang telah anda perhatikan, apabila membatalkan token, Invoke-WebRequest digunakan. Tidak seperti Invoke-RestMethod, ia tidak mengembalikan data yang diterima dalam format yang boleh digunakan dan menunjukkan status permintaan.
Seterusnya, skrip meminta anda memasukkan nama pertama dan nama keluarga pengguna, menghasilkan log masuk + e-mel.
permintaan
Permintaan seterusnya ialah - pertama sekali, anda perlu menyemak sama ada pengguna dengan log masuk yang sama sudah wujud untuk mendapatkan keputusan untuk membuat yang baharu atau mendayakan yang semasa.
Saya memutuskan untuk melaksanakan semua permintaan dalam format satu fungsi dengan pilihan, menggunakan suis:
Dalam setiap permintaan, anda perlu menghantar pengepala Kebenaran yang mengandungi jenis token dan token Akses itu sendiri. Pada masa ini, jenis token sentiasa Pembawa. Kerana kita perlu menyemak bahawa token belum tamat tempoh dan mengemas kininya selepas sejam dari saat ia dikeluarkan, saya menyatakan permintaan untuk fungsi lain yang mengembalikan token Akses. Sekeping kod yang sama adalah pada permulaan skrip apabila menerima token Akses pertama:
Permintaan e-mel:$query akan meminta API untuk mencari pengguna dengan e-mel itu, termasuk alias. Anda juga boleh menggunakan kad bebas: =, :, :{PREFIX}*.
Untuk mendapatkan data, gunakan kaedah permintaan GET, untuk memasukkan data (membuat akaun atau menambah ahli pada kumpulan) - POST, untuk mengemas kini data sedia ada - PUT, untuk memadam rekod (contohnya, ahli daripada kumpulan) - PADAM.
Skrip juga akan meminta nombor telefon (rentetan tidak sah) dan untuk dimasukkan dalam kumpulan pengedaran serantau. Ia memutuskan unit organisasi yang mana pengguna harus mempunyai berdasarkan OU Direktori Aktif yang dipilih dan menghasilkan kata laluan:
Fungsi untuk mengemas kini dan mencipta akaun mempunyai sintaks yang serupa; tidak semua medan tambahan diperlukan; dalam bahagian dengan nombor telefon, anda perlu menentukan tatasusunan yang boleh mengandungi sehingga satu rekod dengan nombor dan jenisnya.
Untuk tidak menerima ralat semasa menambahkan pengguna pada kumpulan, kami boleh menyemak dahulu sama ada dia sudah menjadi ahli kumpulan ini dengan mendapatkan senarai ahli kumpulan atau gubahan daripada pengguna itu sendiri.
Menanyakan keahlian kumpulan pengguna tertentu tidak akan menjadi rekursif dan hanya akan menunjukkan keahlian langsung. Termasuk pengguna dalam kumpulan induk yang sudah mempunyai kumpulan anak yang menjadi ahli pengguna akan berjaya.
Kesimpulan
Yang tinggal hanyalah menghantar kata laluan kepada pengguna untuk akaun baharu. Kami melakukan ini melalui SMS, dan menghantar maklumat am dengan arahan dan log masuk ke e-mel peribadi, yang, bersama-sama dengan nombor telefon, disediakan oleh jabatan pengambilan. Sebagai alternatif, anda boleh menjimatkan wang dan menghantar kata laluan anda ke sembang telegram rahsia, yang juga boleh dianggap sebagai faktor kedua (MacBooks akan menjadi pengecualian).
Terima kasih kerana membaca sehingga habis. Saya akan gembira melihat cadangan untuk menambah baik gaya penulisan artikel dan berharap anda mendapat lebih sedikit ralat semasa menulis skrip =)
Senarai pautan yang mungkin berguna secara tematik atau hanya menjawab soalan: