הטמעה של חשבונות משתמשים

יש שני סוגים עיקריים של זהויות משתמשים בהרשמה ל-Android Enterprise: חשבונות Google מנוהלים וחשבונות Google Play מנוהלים. חשבונות Google Play מנוהלים הם חשבונות שממוקדים במכשיר, כלומר הם לא משויכים לזהות Google של משתמש ספציפי. לעומת זאת, חשבונות Google מנוהלים מקושרים לזהות Google הארגונית של המשתמש, מה שמשפר את חוויית המשתמש בכך שהוא נשאר מחובר במכשירים שלו.

בעבר, חשבונות Google Play מנוהלים היו ברירת המחדל. עם זאת, Google ממליצה עכשיו לכל הפיתוחים החדשים להשתמש בתהליך ההרשמה המשופר, שברירת המחדל שלו היא יצירת חשבונות Google מנוהלים.

בסוף המסמך הזה מופיעות הנחיות לגבי ההטמעה הישנה, אבל כל פיתוח חדש צריך להתבסס על תהליך ההרשמה החדש שמפורט כאן.

סקירה כללית

תהליך משופר של שיוך מכשירים מייעל את הגדרת המכשיר באמצעות כמה רכיבים חדשים ושינוי באופן ההטמעה של בקרי מדיניות מכשירים (DPC) בהתאמה אישית. הגישה החדשה הזו מחייבת פתרונות DPC מותאמים אישית שישתלבו עם Android Management API (AMAPI) SDK ועם Android Device Policy כדי לבצע פונקציות של הכנת מכשירים ורישום משתמשים.

ערכת AMAPI SDK מספקת את ממשקי ה-API הדרושים לאינטראקציה עם מדיניות המכשיר של Android במכשיר עצמו. בצד השרת, פתרונות לניהול ניידות בארגון (EMM) ישתמשו ב-Play EMM API כדי ליצור את טוקני ההרשמה שנדרשים כדי להתחיל את תהליך ההרשמה של המכשיר.

אפליקציית Device Policy ל-Android ממלאת עכשיו תפקיד מרכזי בטיפול בפעולות בצד המכשיר. ‫AMAPI SDK משמש לניהול ההתקנה והעדכונים הנדרשים במכשיר. בנוסף, Android Device Policy משתלטת על תהליך האימות של המשתמש, מטפלת באימות המשתמש ישירות ומספקת את זהות המשתמש ל-EMM. אם Google לא מצליחה לאמת את המשתמש מסיבה כלשהי, נוצר חשבון חדש ב-Google Play לארגונים והוא מתווסף למכשיר כגיבוי.

חלק מרכזי בתהליך ההרשמה החדש הזה הוא ניהול הגישה של המכשיר לשירותי Google. כברירת מחדל, המכשירים מתחילים במצב מוגבל, ומערכת ה-EMM ממלאת תפקיד חשוב בהפעלת הגישה אחרי שהמכשיר עומד בדרישות.

שילוב API

לפני שמתחילים, חשוב לוודא שמשתמשים בגרסה העדכנית ביותר של לקוח Play EMM API ושל AMAPI SDK.

מדריך הטמעה של רישום

במדריך הזה מפורטים השלבים הנדרשים להטמעה של הרשמה. המאמר כולל מידע על הכנת הסביבה, טיפול בשיטות שיוך שונות וניהול מחזור החיים של המכשיר.

הכנת הסביבה

לפני שמתחילים בהגדרת החשבון, צריך להכין את סביבת המכשיר. ההכנה הזו כוללת עדכון של חנות Play לגרסה האחרונה שלה והתקנה שקטה של מדיניות המכשיר של Android‏ (com.google.android.apps.work.clouddpc) במכשיר. התקנת אפליקציית Android Device Policy חיונית כי היא מכילה רכיבים קריטיים בתהליך הגדרת החשבון. אין צורך לבצע הכנה ידנית של הסביבה במערכות EMM. במקום זאת, הם צריכים להשתמש ב-EnvironmentClient, כפי שמתואר במאמר, ולפעול לפי דוגמאות הקוד שמופיעות בו.

קוד לדוגמה

כדי להשתמש ב-API‏ AccountSetup כדי להוסיף את החשבון לצורכי עבודה למכשיר, כלי ה-DPC צריך קודם לאמת שהסביבה של המכשיר מוכנה.

  • משתמשים ב-EnvironmentClientFactory כדי ליצור מופע של EnvironmentClient ולקרוא ל-prepareEnvironment או ל-prepareEnvironmentAsync

    val notificationReceiverServiceName = ComponentName(context,
NotificationReceiver::class.java)

// An EMM should implement android.app.admin.DeviceAdminReceiver and use that
// class to instantiate a ComponentName

val admin = ComponentName(this, com.example.dpc.DeviceAdminReceiver::class.java)

EnvironmentClientFactory.create(context)
    .prepareEnvironment(
        PrepareEnvironmentRequest.builder()
            .setRoles(
                listOf(
                    Role.builder().setRoleType(
                        Role.RoleType.DEVICE_POLICY_CONTROLLER
                    ).build()
                )
            )
    .setAdmin(admin)
            .build(),
          notificationReceiverServiceName,
        )

[Proceed with AccountSetup]

הפעולה הזו עשויה להימשך כמה שניות או דקות, כי יכול להיות שאפליקציות יותקנו או יעודכנו כדי לאמת סביבת עבודה תקינה. ‫Google ממליצה להתחיל את התהליך הזה ברקע מוקדם ככל האפשר, ולהציג ממשק משתמש מתאים בזמן שהמשתמש ממתין. כשהפעולה מסתיימת, המכשיר מוכן לשימוש ב-AccountSetup API על ידי DPC.

תהליך ההרשמה

ספקי EMM צריכים להפסיק להשתמש ב-users.generateAuthenticationToken() וב-users.insert() בכל המכשירים. במקום זאת, מערכות EMM צריכות לקרוא ל-API במכשיר כדי לבצע אימות של משתמשי קצה. ה-API החדש יחזיר את userId ואת email אל ה-DPC. אם Google לא מצליחה לאמת את המשתמש, ייווצר חשבון מנוהל ב-Google Play והוא יתווסף למכשיר. במקרה כזה, Google תחזיר את userId של החשבון הזה.

‫Google מציגה עכשיו את השימוש באסימוני הרשמה, שצריך להעביר אל ה-API לאימות. מערכות EMM קובעות מתי ואיך ליצור את האסימון, והוא יכול להיות חלק ממטען ייעודי (payload) קיים של הרשמה (למשל, קוד QR או הגדרה ללא מגע).

פטור לטוקנים קיימים של הרשמה

חלק מהלקוחות משתמשים באסימוני הרשמה עם תאריכי תפוגה ארוכים כדי לבצע הרשמות חוזרות. כדי לוודא שלא תהיה הפרעה לתהליכי העבודה הקיימים, טוקנים שנוצרו לפני שהדרישה 'אימות באמצעות Google' הופעלה לראשונה פטורים מההנחיות החדשות להתחברות. האסימונים הישנים האלה ימשיכו לפעול כמו קודם, ויאפשרו למשתמשים לרשום מכשירים בלי לעבור את תהליך האימות של Google. עם זאת, כל האסימונים שנוצרו אחרי שהפעלנו את דרישת האימות של Google יפעלו לפי כללי האימות החדשים. המשמעות היא שבמכשירים שמשתמשים באסימונים החדשים האלה, המשתמשים יצטרכו לעבור אימות בהתאם להגדרות שנבחרו על ידי מנהל ה-IT.

‫Google ממליצה ליצור את האסימון לפי דרישה ולהחליף את ה-API הקיים לחשבונות Google Play מנוהלים ב-API החדש כדי לצמצם את השינוי.

שילוב אופייני של DPC עם ממשקי API קודמים
איור 1. שילוב אופייני של DPC עם ממשקי API קודמים
דוגמה לשילוב של DPC עם ממשקי API חדשים למכשירים ללא משתמש
איור 2. דוגמה לשילוב של DPC עם ממשקי API חדשים למכשירים ללא משתמש
דוגמה לשילוב של DPC עם ממשקי API חדשים למכשירי משתמשים
איור 3. דוגמה לשילוב של DPC עם ממשקי API חדשים למכשירי משתמשים

תהליך ההרשמה המשופר של DPC בהתאמה אישית כולל את השלבים הבאים:

מצב המכשיר הראשוני החשוב: כשרושמים מכשיר באמצעות DPC מותאם אישית, חשבון Google שנוסף למכשיר מתחיל במצב מושבת. המשמעות היא שהגישה לשירותי Google, כולל Google Play, מוגבלת בהתחלה.

הסטטוס הזה מוגדר כברירת מחדל כ'מושבת', והדרישה הבאה שחלה עליו היא שמערכת ה-EMM תסמן את המכשיר כעומד בדרישות (למשל, על ידי קריאה ל-Devices.SetState). הסטטוס הזה רלוונטי במיוחד בתנאים הבאים:

  1. הארגון אימת את הבעלות על הדומיין שלו ב-Google.
  2. אדמין ה-IT הפעיל באופן מפורש ניהול של מכשירי Android ניידים על ידי צד שלישי עבור היחידה הארגונית הספציפית של המשתמש במסוף Google Admin.
  1. יצירת טוקן רישום: מערכת ה-EMM יוצרת טוקן רישום באמצעות Play EMM API.
  2. הכנת הסביבה: ב-DPC המותאם אישית נעשה שימוש בתהליך הכנת הסביבה כדי לוודא שהמכשיר מוכן להרשמה.
  3. התחלת ההרשמה: ה-DPC המותאם אישית מפעיל את startAccountSetup API ב-AMAPI SDK, ומעביר את אסימון ההרשמה. הערה: לפני שקוראים ל-API הזה, ה-DPC צריך להיות בעלים של המכשיר או של הפרופיל.
  4. הפעלת פעילות אימות של Google: אם נדרש, ה-DPC המותאם אישית מפעיל את ה-API‏ launchAuthenticationActivity ב-AMAPI SDK, ומעביר את AccountSetupAttempt. הפעולה הזו מתחילה פעילות אימות של Google, ומחזירה את המשתמש ל-DPC המותאם אישית אחרי שהאימות מצליח. המשתמש יכול גם לדלג על התהליך הזה. במקרה כזה, חשבון Google Play לארגונים יתווסף למכשיר. אפשר להגדיר את האפשרות הזו באמצעות googleAuthenticationOptions.
  5. סיום הרישום: AMAPI SDK שולח הודעה ל-DPC בהתאמה אישית על תוצאת הרישום.
  6. הפעלת שירותי Google: אחרי ש-DPC בהתאמה אישית יקצה את המכשיר באופן מלא ויאשר שהוא עומד בכל כללי המדיניות של הארגון, שרת ה-EMM חייב לקרוא ל-Devices.setState() עם הפרמטר accountState שמוגדר ל-"enabled".
  • למה זה חשוב: קריאה ל-API הזו מסמנת את המכשיר כעומד בדרישות.
  • התוצאה של אי ביצוע השיחה: בלי השיחה הזו Devices.setState(setStateRequest), החשבון יישאר במצב 'מושבת'. המשתמש לא יוכל לגשת אל Google Play (כדי להתקין או לעדכן אפליקציות) ואל שירותים אחרים של Google שדורשים אימות של החשבון.

ניהול מצב המכשיר והגישה לשירות

אחרי ההרשמה הראשונית, מערכת ה-EMM אחראית לשמירה על הגישה של המכשיר לשירותי Google על סמך סטטוס התאימות שלו.

טיפול בשיבושים בשירות: BAD_DEVICE_MANAGEMENT

אם הגישה של מכשיר לשירותי Google נחסמת, ‏ Google Play Services‏ (GMSCore) ישדר Intent עם הפעולה: com.google.android.gms.auth.BAD_DEVICE_MANAGEMENT. יכולות להיות לכך כמה סיבות:

  • ה-EMM אף פעם לא קרא ל-Devices.setState("enabled") אחרי הרישום הראשוני של המכשיר.
  • המכשיר כבר לא עומד בדרישות של מדיניות ה-EMM, וה-EMM עדיין לא הפעיל אותו מחדש.
  • מערכת ה-EMM הגדירה באופן מפורש את מצב המכשיר כ'מושבת' באמצעות קריאה ל-Devices.setState() עם accountState שהוגדר כ'מושבת'. יכול להיות שהסיבה לכך היא בעיות אבטחה, פעולות ניהוליות או סיבות אחרות.

ה-Intent הזה כולל קוד סטטוס, כמו "ThirdPartyDeviceManagementRequired".

ב-DPC בהתאמה אישית חובה להטמיע BroadcastReceiver כדי להאזין ל-Intent‏ BAD_DEVICE_MANAGEMENT הזה.

כשמקבלים את ההודעה הזו, ה-DPC צריך:

  1. הערכה מחדש של התאימות: בודקים אם המכשיר עומד בכל כללי המדיניות שהוגדרו על ידי ה-EMM.
  2. פעולה שצריך לבצע:
    • אם התאימות נשמרת: בקר ה-DPC צריך לשלוח הודעה לשרת ה-EMM. בשלב הבא, שרת ה-EMM צריך להתקשר אל Devices.setState() עם accountState שמוגדר ל-"enabled" עבור מזהה המשתמש ומזהה המכשיר הספציפיים, כדי לנסות לשחזר את הגישה לשירות.
    • אם המכשיר לא עומד בדרישות: אחרי שהבעיות נפתרות והמכשיר עומד בדרישות, מערכת ה-EMM צריכה להתקשר אל Devices.setState().

המנגנון הזה מבטיח שתהיה דרך לזהות מצבים שבהם מכשיר מאבד גישה לשירותי Google ולשחזר את הגישה.

שיקולים לגבי השתלטות על חשבון Enterprise

יכולים להתרחש שינויים בסוג החשבון של הארגון (לדוגמה, מ-ManagedGoogleDomainType.TYPE_TEAM ל-ManagedGoogleDomainType.TYPE_DOMAIN). בדרך כלל התהליך הזה לא גורם לניתוק הקישור ל-EMM, אבל לפעמים הוא יכול לשבש את הגישה לשירותי Google במכשירים.

מערכות EMM צריכות לדעת שאם משתמשים מדווחים על בעיות בגישה לשירות אחרי אירוע ידוע של השתלטות, יכול להיות שיהיה צורך להתקשר אל Devices.setState() כדי לסנכרן מחדש את מצב המכשיר עם השרתים העורפיים של Google במסגרת מבנה הלקוח החדש, גם אם נראה שהמכשיר תואם למדיניות EMM. בדרך כלל לא נדרשות שיחות יזומות לכל המכשירים אחרי ההשתלטות, אבל זה כלי חשוב לפתרון בעיות גישה.

הגדרת חשבון – קוד לדוגמה

  1. כדי להתחיל תהליך של הגדרת חשבון, אפליקציית השיחות יכולה להשתמש ב-AccountSetupClient ולהפעיל את השיטה startAccountSetup() או startAccountSetupFuture(). דוגמה להטמעה, ראו את דוגמת הקוד הבאה:

    // Create AccountSetupClient
val client = AccountSetupClientFactory.create(
    this,
    activityResultRegistry
)
lifecycle.addObserver(client.lifecycleObserver)

// Create adminComponent
val notificationReceiver = ComponentName(this, AccountSetupNotificationReceiver::class.java)
// Helper method to get enrollment token created with Play EMM API
val enrollmentToken = getEnrollmentToken()
val request =
    StartAccountSetupRequest.builder()
        .setEnrollmentToken(enteredText)
        .setNotificationReceiverServiceComponentName(notificationReceiver)
        .setAdminComponentName(
            ComponentName(this, com.example.dpc.DeviceAdminReceiver::class.java))
        .build()
try {
    val accountSetupAttempt = client.startAccountSetup(request)
    // handle attempt
} catch (e: Exception) {
    // handle exception
}

  2. מטמיעים את הממשק AccountSetupListener ומספקים יישום של אופן הטיפול בעדכוני הסטטוס שהתקבלו.

  3. ‫Extend NotificationReceiverService ומספקים את המופע AccountSetupListener שנוצר בשלב 2 על ידי החלפת getAccountSetupListener().

    // Handles account setup changes
class AccountSetupNotificationReceiver :
      NotificationReceiverService(),
      AccountSetupListener {

    override fun getAccountSetupListener(): AccountSetupListener = this

    override fun onAccountSetupChanged(accountSetupAttempt:
  AccountSetupAttempt) {

        when (accountSetupAttempt.state.kind) {
            StateCase.ADDED_ACCOUNT -> {
                val enterpriseAccount = state.addedAccount()
                val userId = enterpriseAccount.userId
                val deviceId = enterpriseAccount.deviceId
                // Handle account added state.

                // IMPORTANT: The device/account is now added but *DISABLED*
                // for Google services. Your EMM backend MUST be notified to
                // perform policy compliance checks and then call Devices.setState()
                // to activate Google Play and other services.

            }
            StateCase.AUTHENTICATION_ACTIVITY_LAUNCH_REQUIRED -> {
                val request = LaunchAuthenticationActivityRequest.builder()
            .setAccountSetupAttempt(accountSetupAttempt)
            .build();
                // Send the attempt to the foreground activity to call:
                accountSetupClient.launchAuthenticationActivity(request)
            }
            StateCase.ACCOUNT_SETUP_ERROR -> {
                // Handle error state.
                val failureReason = state.accountSetupError().failureReason
            }
            else -> {
                // Handle unknown account setup attempt state.
            }
        }
    }
}

  4. מוסיפים את הכיתה המורחבת NotificationReceiverService ל-AndroidManifest.xml ומוודאים שהיא מיוצאת.

      <application>
    <service
        android:name = ".accountsetup.AccountSetupNotificationReceiver"
        android:exported = "true" />
  </application>

    אם האפליקציה מטרגטת SDK בגרסה 30 ואילך, צריך להוסיף רכיב queries אל AndroidManifest.xml כדי לציין שהיא תבצע אינטראקציה עם ADP.

      <queries>
    <package android:name="com.google.android.apps.work.clouddpc" />
  </queries>

הנחיות לבדיקה

בקטע הזה מפורטות הנחיות ושיטות מומלצות לבדיקת ההטמעה.

בדיקה של PrepareEnvironment

  1. קבלת המצב הנוכחי של המכשיר: מערכת ה-EMM מפעילה

    adb shell dumpsys package com.google.android.apps.work.clouddpc | grep versionName

    כדי לקבל את הגרסה של Android Device Policy שמותקנת במכשיר. אם לא מותקנת Android Device Policy, צפוי פלט ריק.

  2. שילוב של PrepareEnvironment: ה-DPC המותאם אישית מפעיל את prepareEnvironment API ב-AMAPI SDK, ומעביר את הבקשה הנכונה.

  3. המתנה לתוצאה של PrepareEnvironment: ה-DPC המותאם אישית ממתין לסיום של prepareEnvironment.

  4. מאשרים שהפעולה PrepareEnvironment הושלמה בהצלחה: בסיום, שירות ה-EMM פועל שוב

    adb shell dumpsys package com.google.android.apps.work.clouddpc | grep versionName

    הפעם גרסת Android Device Policy צריכה להיות גבוהה יותר מאשר בשלב 1.

בדיקת אימות של חשבון Google

  1. יצירת ארגון לבדיקה: פתרון ה-EMM יוצר דומיין לבדיקה של ארגון Google שמקושר ל-EMM לבדיקה, עם enterprises.generateSignupUrl.
  2. הפעלת אימות Google: פלטפורמת ה-EMM מפעילה אימות Google עבור ארגון הבדיקה בהתאם להוראות האלה במסוף Google Admin.
  3. יצירת טוקן הרשמה: מערכת ה-EMM יוצרת טוקן הרשמה באמצעות Play EMM API עם הסוג userDevice.
  4. התחלת ההרשמה: ה-DPC המותאם אישית מפעיל את startAccountSetup API ב-AMAPI SDK, ומעביר את אסימון ההרשמה.
  5. נדרשת פעילות להפעלה: ה-SDK של AMAPI שולח הודעה ל-DPC המותאם אישית שצריך להפעיל פעילות כדי לאמת את המשתמש.
  6. אימות המשתמש: ה-DPC המותאם אישית מפעיל את launchAuthenticationActivity כדי להתחיל את הפעילות. המשתמש מאומת באמצעות חשבון Google מנוהל (חלק מהארגון שנוצר בשלב 1).
  7. סיום הרישום: AMAPI SDK שולח הודעה ל-DPC בהתאמה אישית על תוצאת הרישום.

בדיקת דילוג על אימות ב-Google

נשתמש בהגדרה שתיארנו קודם.

הפעם, בשלב 7, המשתמש לוחץ על דילוג במקום לבצע אימות באמצעות חשבון Google שלו. הצירוף מסתיים בהצלחה, עם חשבון שירות במכשיר (כלומר, AuthenticationType הוא אנונימי).

בדיקת מכשירים ללא משתמשים

תהליך ההרשמה המשופר של DPC בהתאמה אישית כולל את השלבים הבאים, כשאימות Google מושבת:

  1. יצירת ארגון לבדיקה: אפשר להשתמש באותו ארגון שנוצר קודם.
  2. יצירת טוקן הרשמה: מערכת ה-EMM יוצרת טוקן הרשמה באמצעות Play EMM API עם הסוג userlessDevice.
  3. התחלת ההרשמה: ה-DPC המותאם אישית מפעיל את startAccountSetup API ב-AMAPI SDK, ומעביר את אסימון ההרשמה.
  4. סיום הרישום: AMAPI SDK שולח הודעה ל-DPC בהתאמה אישית על תוצאת הרישום.