حل مشكلة 400 admin_policy_enforced في Google Workspace
يظهر الخطأ “400 admin_policy_enforced” عندما يقوم مسؤول Google Workspace عمدًا بحظر أو تقييد الوصول إلى تطبيقات أو بيانات معينة تابعة لجهات خارجية، مما يمنع المستخدمين من تسجيل الدخول أو مشاركة المعلومات. هذا ليس عطلاً، بل هو إجراء أمني متعمد يعكس السياسات المحددة للمؤسسة.
يمكن أن يعطل سير العمل ويسبب مشكلات في الإنتاجية، خاصة عندما تتأثر أدوات العمل الحيوية. يحدث هذا الخطأ غالبًا عند محاولة ربط تطبيقات مثل Slack أو Zoom أو Asana، مما يؤدي إلى فشل في التفويض ورفض الوصول.
هناك عدة أسباب شائعة لهذا الخطأ، مثل:
- قيود إدارية – تطبيقات أو ميزات محظورة بواسطة مسؤول Workspace.
- تطبيقات جهات خارجية غير موثوق بها – أدوات غير معتمدة للاستخدام داخل مؤسستك.
- قواعد صارمة لمشاركة البيانات – سياسات تحد من كيفية الوصول إلى البيانات أو مشاركتها.
- تعطيل الوصول إلى API – منع التطبيقات من الاتصال للمستخدمين في المجموعات المقيدة.
- التسجيل في الحماية المتقدمة – قد تواجه الحسابات المشاركة في هذا البرنامج أو التي تم وضع علامة عليها كمشتبه بها ضوابط وصول أكثر صرامة.
- عوامل إضافية – عدم وجود مصادقة متعددة العوامل (MFA)، عناوين URL محظورة، محاولات تفويض من غير المسؤولين الخارقين، قيود الترخيص، أو تعارضات أسماء المستخدمين.
الآن، دعنا ننتقل إلى الحلول التي يمكن أن تساعدك في إصلاح هذه المشكلة.
1. إضافة التطبيق المحظور إلى القائمة البيضاء في Google Admin
في معظم الحالات، يحدث هذا الخطأ لأن التطبيق الذي تحاول استخدامه غير مدرج في القائمة البيضاء ضمن عناصر تحكم API لمؤسستك. عادةً ما يؤدي تعديل إعدادات الوصول لهذا التطبيق إلى حل المشكلة.
- سجل الدخول إلى وحدة تحكم Google Admin بصفتك مسؤولاً خارقًا.
- انتقل إلى الأمان > التحكم في الوصول والبيانات > عناصر تحكم API.
- انقر على إدارة وصول تطبيقات الجهات الخارجية.
- حدد موقع التطبيق المحظور في القائمة. إذا لم يكن مرئيًا، استخدم خيار “إضافة تطبيق” للبحث بواسطة OAuth Client ID.
- حدد التطبيق وغير حالته إلى موثوق به.
- انقر على حفظ.
من خلال الثقة الصريحة بالتطبيق، تتجاوز الحظر الافتراضي الذي تسبب في ظهور خطأ 400 admin_policy_enforced.
2. استخدام حساب خدمة مع تفويض على مستوى النطاق
إذا كانت المشكلة تؤثر على الأتمتة أو عمليات التكامل (مثل السكربتات أو الخدمات الخلفية)، فإن حساب الخدمة يمكنه تجاوز موافقة OAuth على مستوى المستخدم مع البقاء متوافقًا تمامًا مع سياسات المؤسسة.
يعمل هذا الحساب تحت هوية مدارة مركزيًا، مما يضمن وصولاً آمنًا ومتوافقًا مع السياسات لواجهة برمجة التطبيقات (API) للتطبيقات دون تفعيل قيود تسجيل الدخول.
- سجّل الدخول إلى Google Cloud Console بصفتك مسؤولاً.
- اختر مشروعًا موجودًا أو أنشئ مشروعًا جديدًا.
- فعّل واجهات برمجة التطبيقات (APIs) المطلوبة ضمن API & Services > Enabled APIs & Services (على سبيل المثال: Admin SDK, Gmail API, Calendar API, Drive API).
- انتقل إلى IAM & Admin > Service Accounts وأنشئ حساب خدمة جديدًا.
- فعّل التفويض على مستوى النطاق للحساب وأنشئ مفتاح JSON.
- انسخ المعرّف الفريد لحساب الخدمة.
- في Admin Console، انتقل إلى الأمان > عناصر تحكم واجهة برمجة التطبيقات > إدارة التفويض على مستوى النطاق وأضف عميلاً جديدًا باستخدام المعرّف المنسوخ.
- عيّن نطاقات OAuth المطلوبة وانقر على تفويض.
تحذير: امنح فقط الأذونات الدنيا المطلوبة لحالة استخدامك واحفظ مفتاح JSON بأمان. حسابات الخدمة المخترقة يمكن أن تعرض بيانات حساسة للخطر.
3. تعطيل الوصول عبر IMAP/POP
إذا كانت برامج البريد الإلكتروني القديمة تحاول إجراء اتصالات غير مصرح بها، فقد يؤدي ذلك أيضًا إلى ظهور الخطأ. يضمن تعطيل IMAP/POP أن الطرق المعتمدة فقط (مثل تطبيق الويب Gmail أو عملاء OAuth المصرح لهم) يمكنها الاتصال بحسابك.
- سجّل الدخول إلى Google Admin بصفتك مسؤولاً.
- انتقل إلى التطبيقات > Google Workspace > Gmail.
- وسّع وصول المستخدم النهائي وانقر على أيقونة القلم الرصاص بجوار إعدادات POP/IMAP.
- ألغِ تحديد وصول POP ووصول IMAP.
- انقر على حفظ.
هام: أبلغ المستخدمين قبل تطبيق هذا التغيير. سيؤدي ذلك إلى تعطيل الوصول لبرامج البريد الإلكتروني مثل Outlook وThunderbird التي تعتمد على IMAP/POP.
4. اتصل بدعم Google Workspace
إذا لم ينجح أي من الحلول المذكورة أعلاه، فاتصل بدعم Google Workspace. زودهم بما يلي:
- رسالة الخطأ الكاملة والطابع الزمني
- معرّف عميل OAuth أو اسم التطبيق
- أي تغييرات حديثة على عناصر التحكم الأمنية أو API
يمكنهم مراجعة سياسات مؤسستك والمساعدة في تطبيق التعديلات الصحيحة.
Comments are closed.