ข้อมูลประจำตัวและบัญชีผู้ใช้

การจัดสรรข้อมูลประจำตัว (หรือการจัดสรรบัญชี) คือกระบวนการตั้งค่าบัญชี และสร้างการเชื่อมต่อระหว่างระบบทั้ง 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)ไม่ได้ตั้งค่า
accountTypedeviceAccount, userAccountuserAccount
displayNameชื่อที่คุณแสดงในรายการ UI เช่น ภายใน Google Play อย่าใช้ข้อมูลส่วนบุคคลที่ระบุตัวบุคคลนั้นได้ไม่ได้ตั้งค่า
managementTypeemmManagedgoogleManaged, 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: ลูกค้ารับผิดชอบวงจรของบัญชี

การใช้ Directory API (ที่มีสิทธิ์เข้าถึงแบบอ่านอย่างเดียว) และ GCDS

ในกรณีนี้ ลูกค้าของคุณจะสร้างและดูแลรักษาบัญชี 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 มีหน้าที่รับผิดชอบวงจรของบัญชี

การใช้ Directory API ที่มีสิทธิ์การอ่าน-เขียน

ในกรณีนี้ คุณต้องจัดการกระบวนการสร้างบัญชี 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