การจัดสรรข้อมูลประจำตัว (หรือการจัดสรรบัญชี) คือกระบวนการตั้งค่าบัญชี และสร้างการเชื่อมต่อระหว่างระบบทั้ง 3 ที่จัดเก็บข้อมูลผู้ใช้ และในบางกรณีคือการตั้งค่าการเชื่อมต่อระหว่างผู้ใช้กับอุปกรณ์
ในสภาพแวดล้อม Android Enterprise ระบบ 3 ระบบที่แตกต่างกันจะเก็บข้อมูลบัญชีผู้ใช้ ไว้
- ไดเรกทอรีผู้ใช้ขององค์กรเป็นแหล่งข้อมูลที่เชื่อถือได้เกี่ยวกับผู้ใช้
- คุณ (ผู้ให้บริการโซลูชัน EMM) ต้องดูแลไดเรกทอรีผู้ใช้ขององค์กรอย่างน้อยที่สุด
- Google จะเก็บข้อมูลบางอย่างเกี่ยวกับบัญชี Managed Google Play และบัญชี Google เพื่อให้บริการจัดการแอปผ่าน Google Play
ทรัพยากร Users
แสดงถึงบัญชี
ที่เชื่อมโยงกับองค์กร บัญชีอาจเฉพาะเจาะจงสำหรับอุปกรณ์ หรืออาจเชื่อมโยงกับบุคคลที่มีอุปกรณ์หลายเครื่องและใช้บัญชีในอุปกรณ์ทั้งหมด บัญชีดังกล่าวสามารถให้สิทธิ์เข้าถึงเฉพาะ Managed Google Play หรือ
บริการอื่นๆ ของ Google ก็ได้ ทั้งนี้ขึ้นอยู่กับวิธีที่คุณตั้งค่าองค์กรของลูกค้า
บัญชี Google ที่มีการจัดการคือบัญชีที่มีอยู่ซึ่ง Google เป็นผู้จัดการ บัญชีเหล่านี้กำหนดให้ลูกค้าต้องใช้ Google เป็นผู้ให้บริการข้อมูลประจำตัวหรือลิงก์ไดเรกทอรีผู้ใช้ขององค์กรกับ Google สำหรับ องค์กรที่ใช้บัญชี Google ที่มีการจัดการ Google มีหน้าที่ ตรวจสอบสิทธิ์ผู้ใช้ในระหว่างการจัดสรรอุปกรณ์
บัญชี Managed Google Play ช่วยให้องค์กร สร้างบัญชีผู้ใช้ที่มีการจำกัดโดยอัตโนมัติผ่านผู้ให้บริการโซลูชัน Enterprise Mobility Management (EMM) บัญชีเหล่านี้ให้สิทธิ์เข้าถึง เฉพาะ Managed Google Play EMM มีหน้าที่รับผิดชอบในการตรวจสอบสิทธิ์ ผู้ใช้เมื่อจำเป็น สำหรับกลุ่มบัญชี Managed Google Play สำหรับองค์กร นี่เป็นบัญชีประเภทเดียวที่ใช้ได้
ตารางที่ 1: ฟิลด์และเมธอดของ Users API
บัญชี Managed Google Play | บัญชี Google ที่มีการจัดการ | |
---|---|---|
ช่อง | ||
id | ||
ชนิด | ||
accountIdentifier | ตัวระบุที่ไม่ซ้ำกันที่คุณสร้างและแมป
กับรหัส (userId ) ที่ได้จาก Google Play อย่าใช้ข้อมูลส่วนบุคคลที่ระบุตัวบุคคลนั้นได้ (PII) | ไม่ได้ตั้งค่า |
accountType | deviceAccount, userAccount | userAccount |
displayName | ชื่อที่คุณแสดงในรายการ UI เช่น ภายใน Google Play อย่าใช้ข้อมูลส่วนบุคคลที่ระบุตัวบุคคลนั้นได้ | ไม่ได้ตั้งค่า |
managementType | emmManaged | googleManaged, emmManaged |
primaryEmail | ไม่ได้ตั้งค่า | ฟิลด์นี้เป็นคีย์หลักที่คุณใช้จัดการการซิงค์จากบัญชีโดเมนที่ Google จัดการไปยังบัญชีผู้ใช้ในระบบ |
เมธอด | ||
ลบ | ||
generateAuthenticationToken | ||
generateToken | ||
รับ | ||
getAvailableProductSet | ||
Insert | ||
list | ||
revokeToken | ||
setAvailableProductSet | ||
อัปเดต |
เรากำลังเปลี่ยนไปใช้บัญชี Google ที่มีการจัดการสำหรับอุปกรณ์ Android Enterprise ทั้งหมดที่พนักงานซึ่งมีข้อมูลประจำตัวของบริษัทใช้ เพื่อปรับปรุงการลงทะเบียนอุปกรณ์
สำหรับการลงทะเบียนใหม่ ตอนนี้เราขอแนะนำให้ใช้บัญชี Google ที่มีการจัดการแทนบัญชี Google Play ที่มีการจัดการ แม้ว่าเราจะยังคงรองรับบัญชี Managed Google Play สำหรับผู้ใช้เดิม แต่บัญชีดังกล่าวจะให้สิทธิ์เข้าถึงเฉพาะ Managed Google Play Store เท่านั้น บัญชี Google ที่มีการจัดการช่วยให้ผู้ใช้เข้าถึงชุดบริการทั้งหมดของ Google และฟีเจอร์ข้ามอุปกรณ์ได้
การปรับปรุงการลงทะเบียน
บัญชี Google ที่มีการจัดการจะสร้างข้อมูลประจำตัวของผู้ใช้กับ Google ซึ่งจะช่วยให้คุณได้รับประสบการณ์การใช้งานข้ามอุปกรณ์ เช่น การส่งต่อการทำงาน การแจ้งเตือน และการแชร์ในบริเวณใกล้เคียง ฟีเจอร์เหล่านี้มีความสำคัญมากขึ้นในพื้นที่ขององค์กร ซึ่งผู้ใช้มักใช้อุปกรณ์หลายเครื่อง
ตอนนี้เราขอแนะนำให้องค์กรที่ไม่ได้ใช้ Google เป็นผู้ให้บริการข้อมูลประจำตัวลิงก์ผู้ให้บริการข้อมูลประจำตัวที่มีอยู่กับ Google ซึ่งจะช่วยให้ สร้างบัญชี Google ที่มีการจัดการสำหรับพนักงานได้ในระหว่างกระบวนการเชื่อมโยง องค์กรควรใช้ผู้ให้บริการข้อมูลประจำตัวเดียวกันกับที่ใช้กับ EMM
เราได้ทำการเปลี่ยนแปลงต่อไปนี้
ตอนนี้ Google/Android จะจัดการการตรวจสอบสิทธิ์ของผู้ใช้ปลายทางในระหว่างการลงทะเบียนอุปกรณ์ ตัวควบคุมนโยบายด้านอุปกรณ์ (DPC) ของ EMM กำหนดให้ Android ต้องตรวจสอบสิทธิ์ผู้ใช้ในจุดที่เหมาะสม จากนั้น Android จะส่งคืน ข้อมูลประจำตัวของผู้ใช้ที่เข้าสู่ระบบไปยัง DPC
EMM ต้องส่งโทเค็นการลงทะเบียนไปยัง Android เมื่อขอการตรวจสอบสิทธิ์ผู้ใช้ โทเค็นนี้จะแสดงผลโดยการเรียก API ไปยัง Android Enterprise API และอาจได้รับการเข้ารหัสภายในเพย์โหลดการลงทะเบียนผ่าน QR, NFC หรือการลงทะเบียนแบบไม่ต้องสัมผัส
แม้ว่าตอนนี้ Android จะจัดการการตรวจสอบสิทธิ์และระบุตัวตนของผู้ใช้ให้กับ EMM แต่ EMM ก็ยังคงมีหน้าที่จับคู่ตัวตนของผู้ใช้กับกลุ่มหรือโครงสร้างองค์กรที่ถูกต้อง การเชื่อมโยงนี้มีความสำคัญต่อการ ใช้นโยบายที่เหมาะสมกับอุปกรณ์ ดังนั้น องค์กรจึงต้อง ลิงก์ไดเรกทอรีผู้ใช้ขององค์กรกับ EMM ต่อไป
ผู้ดูแลระบบไอทีสามารถเปิดหรือปิดใช้ฟีเจอร์การตรวจสอบสิทธิ์ผู้ใช้ปลายทางใหม่ที่ Google จัดหาให้ ได้ เราขอแนะนำให้ผู้ดูแลระบบไอทีลิงก์ไดเรกทอรีผู้ใช้ขององค์กรกับ Google เพื่อให้ผู้ใช้ได้รับประสบการณ์การใช้งานที่ดีที่สุด ซึ่งรวมถึงฟีเจอร์แบบข้ามอุปกรณ์ หากไม่มีลิงก์นี้ ผู้ใช้จะมีบัญชี Google Play ที่มีการจัดการและ จะไม่มีสิทธิ์เข้าถึงประสบการณ์การใช้งานข้ามอุปกรณ์
ข้อกำหนดใหม่สำหรับ EMM ทุกรายคือต้องระบุข้อมูลเพิ่มเติมเมื่อ สร้างโทเค็นการลงทะเบียนและการลงชื่อเข้าใช้ โดยคุณต้องระบุว่าอุปกรณ์เป็นอุปกรณ์ที่ไม่มีผู้ใช้ (เช่น คีออสก์หรืออุปกรณ์เฉพาะ) หรือไม่
ข้อดี
กระบวนการใหม่มีการปรับปรุงที่สำคัญดังนี้
การลงทะเบียนที่ง่ายขึ้น: ลดจำนวนขั้นตอนที่ต้องทำด้วยตนเอง และความซับซ้อนเมื่อเทียบกับวิธีการมาตรฐาน
การสนับสนุนบัญชี Google: ตอนนี้คุณใช้บัญชี Google กับวิธีการจัดสรรทั้งหมดได้แล้ว จึงไม่จำเป็นต้องใช้บัญชี Google Play ที่มีการจัดการ
ประสบการณ์ของผู้ใช้ที่ดียิ่งขึ้น: บัญชี Google ที่มีการจัดการจะช่วยให้คุณได้รับประสบการณ์การใช้งาน Android ที่ดียิ่งขึ้น ซึ่งรวมถึงฟีเจอร์ที่มีประสิทธิภาพในการใช้งานข้ามอุปกรณ์ เช่น การแชร์และการคัดลอกวาง
การใช้งานบัญชีผู้ใช้
ดูวิธีดำเนินการตามขั้นตอนการลงทะเบียนใหม่นี้ได้ที่ใช้บัญชีผู้ใช้
วงจรของบัญชี Google ที่มีการจัดการ
สำหรับองค์กรที่ใช้บัญชี Google บัญชีผู้ใช้ในโซลูชัน EMM
จะจำลองบัญชีผู้ใช้ที่มีอยู่ซึ่งเชื่อมโยงกับบริการอื่นๆ ของ Google
(เช่น Google Workspace) บัญชีเหล่านี้คือ googleManaged
(ตารางที่ 1) เนื่องจาก
บริการแบ็กเอนด์ของ Google เป็นแหล่งที่มาของการสร้างและข้อมูล
เกี่ยวกับบัญชี
ในฐานะ EMM คุณสามารถจัดเตรียมกลไกในคอนโซลเพื่ออำนวยความสะดวกในการสร้าง และการซิงค์บัญชีผู้ใช้ที่อยู่ในระบบอย่างต่อเนื่องกับแหล่งที่มาของบัญชีโดเมน Google โดยใช้เครื่องมือต่างๆ เช่น Google Cloud Directory Sync (GCDS) และ Directory API ของ Google Admin SDK เพื่อดูภาพรวมของแนวทางต่างๆ โมเดลข้อมูลประจำตัวของโดเมนที่ Google จัดการ กำหนดให้บัญชีผู้ใช้ต้องมีอยู่ในบริบทของโซลูชัน (คอนโซล EMM , เซิร์ฟเวอร์ EMM หรืออาจอยู่ในที่เก็บข้อมูล) ก่อนจึงจะจัดสรรในอุปกรณ์ใดก็ได้ ของผู้ใช้ในบริบทของโปรไฟล์งาน
ในระหว่างการจัดสรรข้อมูลประจำตัว ระบบจะ สร้างบัญชีผู้ใช้ในโดเมนที่ Google จัดการขององค์กร ในบางกรณี ระบบจะซิงค์ข้อมูลประจำตัวออนไลน์ที่มีอยู่ของผู้ใช้ (เช่น บัญชี Microsoft Exchange) กับบัญชี Google
ซิงค์บัญชีลูกค้า
ในการติดตั้งใช้งานบัญชี Google องค์กรสามารถใช้เครื่องมือ GCDS เพื่อ ซิงค์ข้อมูลในโดเมน G Suite กับข้อมูลในไดเรกทอรี LDAP ได้ หรือคุณจะใช้ GCDS เพื่อดำเนินการนี้ในนามขององค์กรก็ได้ หากองค์กรให้สิทธิ์เข้าถึงแก่คุณ
เครื่องมือ GCDS จะเรียกใช้ Google Directory API และซิงค์ชื่อผู้ใช้ แต่จะไม่ซิงค์รหัสผ่าน
หากองค์กรใช้ Microsoft Active Directory และต้องการซิงค์รหัสผ่าน G Suite ของผู้ใช้กับรหัสผ่าน Active Directory ผู้ใช้หรือคุณสามารถใช้เครื่องมือ G Suite Password Sync (GSPS) กับ GCDS ได้
ดูวิธีการ GCDS สำหรับผู้ดูแลระบบได้ที่เตรียมโดเมน G Suite สำหรับการซิงค์
Google Directory API
ในการติดตั้งใช้งานบัญชี Google คุณสามารถใช้ Google Directory API เพื่อ ซิงค์ Active Directory, รหัสผ่าน หรือทั้ง 2 อย่างได้
การใช้ Directory API สำหรับการซิงค์ไดเรกทอรีเท่านั้น หากมีสิทธิ์เข้าถึงแบบอ่านอย่างเดียวในโดเมน Google ที่มีการจัดการขององค์กร คุณจะใช้ Google Directory API เพื่อรับข้อมูลบัญชี Google เช่น ชื่อผู้ใช้ (แต่ไม่ใช่รหัสผ่าน) จาก Google ได้ เนื่องจากคุณไม่สามารถเขียนข้อมูลใดๆ ลงในบัญชี Google ของผู้ใช้ได้ องค์กรจึงต้องรับผิดชอบต่อวงจรของบัญชีอย่างเต็มรูปแบบ
สถานการณ์ที่ 1 และสถานการณ์การตรวจสอบสิทธิ์ SSO ที่ใช้ SAML อธิบายสถานการณ์นี้ได้สมบูรณ์ยิ่งขึ้น
ดูข้อมูลเกี่ยวกับการใช้ Directory API ในลักษณะนี้ได้ที่เรียกข้อมูลผู้ใช้บัญชีทั้งหมดในเอกสารประกอบของ Directory API
การใช้ Directory API สำหรับการซิงค์ไดเรกทอรีและรหัสผ่าน (ไม่บังคับ) หากคุณมีสิทธิ์อ่านและเขียนในโดเมน Google ที่มีการจัดการขององค์กร คุณจะใช้ Google Directory API เพื่อรับชื่อผู้ใช้ รหัสผ่าน และข้อมูลอื่นๆ ในบัญชี Google ได้ คุณสามารถอัปเดตข้อมูลนี้และซิงค์กับฐานข้อมูลของคุณเองได้ และอาจมีหน้าที่รับผิดชอบวงจรของบัญชีทั้งหมดหรือบางส่วน ขึ้นอยู่กับโซลูชันที่คุณเสนอให้แก่ลูกค้า
สถานการณ์ที่ 2 อธิบายสถานการณ์นี้ได้สมบูรณ์ยิ่งขึ้น
ดูข้อมูลเพิ่มเติมเกี่ยวกับการใช้ Directory API เพื่อจัดการข้อมูลบัญชีผู้ใช้ได้ที่คู่มือสำหรับนักพัฒนาซอฟต์แวร์ Directory API: บัญชีผู้ใช้
สถานการณ์เกี่ยวกับบัญชี Google
สถานการณ์การจัดสรรข้อมูลประจำตัวของบัญชี Google ทั่วไปบางส่วนมีอธิบายไว้ ในส่วนต่อไปนี้
สถานการณ์ที่ 1: ลูกค้ารับผิดชอบวงจรของบัญชี
ในกรณีนี้ ลูกค้าของคุณจะสร้างและดูแลรักษาบัญชี Google สำหรับผู้ใช้
คุณจะได้รับข้อมูลบัญชีผู้ใช้จากไดเรกทอรี LDAP ขององค์กร และเชื่อมโยงข้อมูลนี้กับข้อมูลบัญชี Google ที่ได้รับจาก Google โดยใช้ Directory API ของ Google
องค์กรมีหน้าที่รับผิดชอบต่อวงจรของบัญชีอย่างเต็มที่ ตัวอย่างเช่น เมื่อมีการสร้างบัญชี Google ใหม่ องค์กรจะเพิ่มผู้ใช้ลงในไดเรกทอรี LDAP ในครั้งถัดไปที่คุณซิงค์ฐานข้อมูลกับไดเรกทอรี LDAP ฐานข้อมูลจะได้รับข้อมูลเกี่ยวกับผู้ใช้ใหม่นี้
ในสถานการณ์นี้จะมีผลดังต่อไปนี้
- คุณมีสิทธิ์การเข้าถึงบัญชี Google ในระดับอ่านอย่างเดียว
- ฐานข้อมูลของคุณจะได้รับชื่อบัญชี Google แต่จะไม่ได้รับชื่อผู้ใช้หรือรหัสผ่าน LDAP
- คุณใช้ Google Directory API เพื่อรับข้อมูลบัญชีพื้นฐานสำหรับผู้ใช้ของลูกค้า
(ข้อมูลที่คุณเข้าถึงได้คือข้อมูลที่เขียนไม่ได้
ซึ่ง
Users.get
ส่งคืนมาตามคำขอ) คุณใช้ข้อมูลนี้เพื่อยืนยันว่าบัญชี Google ของผู้ใช้มีอยู่จริง เพื่อให้ผู้ใช้สามารถตรวจสอบสิทธิ์ในอุปกรณ์ของตนเองได้ - ลูกค้าของคุณใช้เครื่องมือ GCDS เพื่อทำการซิงค์ทางเดียวเพื่อสร้างบัญชี Google ของผู้ใช้ (องค์กรอาจใช้ GCDS เพื่อการซิงค์อย่างต่อเนื่องของตนเองหลังจากที่จัดสรรข้อมูลประจำตัวเสร็จสมบูรณ์แล้วด้วย) นอกจากนี้ องค์กรยังใช้เครื่องมือ GSPS เพื่อซิงค์ไม่เพียงแค่ชื่อผู้ใช้ แต่ยังรวมถึงรหัสผ่านได้ด้วย
สถานการณ์ที่ 2: EMM มีหน้าที่รับผิดชอบวงจรของบัญชี
ในกรณีนี้ คุณต้องจัดการกระบวนการสร้างบัญชี Google ในนามของลูกค้า และคุณต้องรับผิดชอบวงจรบัญชีของผู้ใช้
เช่น เมื่อข้อมูลผู้ใช้มีการเปลี่ยนแปลงในไดเรกทอรี LDAP ขององค์กร คุณมีหน้าที่อัปเดตบัญชี Google ของผู้ใช้ ในสถานการณ์นี้จะไม่มีการใช้ GCDS
ในสถานการณ์นี้จะมีผลดังต่อไปนี้
- คุณมีสิทธิ์การอ่าน-เขียนในบัญชี Google
- ฐานข้อมูลจะรับชื่อบัญชี Google และชื่อผู้ใช้ LDAP (และแฮชรหัสผ่านหากมี)
- คุณใช้ Google Directory API ในนามของลูกค้าเพื่ออ่านและ
เขียนข้อมูลบัญชีสำหรับผู้ใช้ขององค์กร (ข้อมูลที่คุณเข้าถึงได้คือข้อมูลที่เขียนไม่ได้
ซึ่ง
Users.get
ส่งคืนมาตามคำขอ) คุณใช้ข้อมูลนี้เพื่อยืนยันว่าบัญชี Google ของผู้ใช้มีอยู่จริง เพื่อให้ผู้ใช้สามารถตรวจสอบสิทธิ์ในอุปกรณ์ของตนเองได้ - ไม่ได้ใช้เครื่องมือ GCDS
สถานการณ์การตรวจสอบสิทธิ์ SSO ที่ใช้ SAML
ในการติดตั้งใช้งานบัญชี Google คุณหรือลูกค้าอาจใช้ภาษามาร์กอัปเพื่อยืนยันความปลอดภัย (SAML) กับผู้ให้บริการข้อมูลประจำตัว (IdP) เพื่อตรวจสอบสิทธิ์บัญชี Google ที่เชื่อมโยงกับผู้ใช้แต่ละราย คุณใช้ชื่อบัญชี Google เพื่อยืนยันว่าบัญชี Google ของผู้ใช้มีอยู่จริง ซึ่งจำเป็นสำหรับการตรวจสอบสิทธิ์ผู้ใช้ เมื่อผู้ใช้ลงชื่อเข้าใช้อุปกรณ์ ตัวอย่างเช่น อาจใช้ SAML ในสถานการณ์ที่ 2 ดูรายละเอียดเกี่ยวกับวิธีตั้งค่านี้ได้ที่ตั้งค่าการลงชื่อเพียงครั้งเดียว (SSO) สำหรับบัญชี G Suite