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