https://thedotnetblog.com/ar/tags/kerberos/Articles, tutorials and insights from the .NET community.Hugoar@thedotnetblog (The .NET Blog)@thedotnetblogMon, 20 Jul 2026 00:00:00 +0000https://thedotnetblog.com/ar/news/emiliano-montesdeoca/ntlm-git-libcurl-azure-devops-server-action-plan/Mon, 20 Jul 2026 00:00:00 +0000Emiliano Montesdeocahttps://thedotnetblog.com/ar/news/emiliano-montesdeoca/ntlm-git-libcurl-azure-devops-server-action-plan/إزالة NTLM في سبتمبر 2026 ليست مشكلة توافق بسيطة؛ إنها موعد نهائي لهوية معمارية لبيئات Azure DevOps Server المحلية.<p>إزالة NTLM القادمة في libcurl هي واحدة من تلك التغييرات التي تبدو تقنية لكنها في الواقع تنظيمية. إذا كان مسار Git عبر HTTPS إلى Azure DevOps Server لا يزال يعتمد على NTLM، فمشكلتك ليست أدوات، بل دين هوية.</p> <p>المصدر الأصلي: <a href="https://devblogs.microsoft.com/devops/upcoming-change-ntlm-removal-in-git-libcurl-impact-to-azure-devops-server-customers/">https://devblogs.microsoft.com/devops/upcoming-change-ntlm-removal-in-git-libcurl-impact-to-azure-devops-server-customers/</a></p> <p>Microsoft محقة في الدفع بقوة هنا. NTLM لديه نقاط ضعف تشفيرية معروفة ولا يجب أن يكون افتراضيًا للمؤسسات الحديثة. الجزء الخطير هو أن العديد من البيئات تعتقد أنها تستخدم Kerberos عندما تكون في الواقع تعيش على التراجع الصامت لـ SPNEGO إلى NTLM. ذلك الوهم يختفي في سبتمبر 2026.</p> <p>رأيي: لا تتعامل مع هذا كمشكلة &ldquo;إصدار عميل.&rdquo; إعادة تمكين أعلام NTLM، أو تثبيت بنيات Git قديمة، أو الأمل في بقاء التراجع متاحًا هو حل مؤقت قصير العمر بمخاطر طويلة الأمد. إذا كانت استراتيجية علاجك هي التخفيض والتأخير، فأنت تزيد الهشاشة التشغيلية بنشاط.</p> <p>يجب أن يكون تسلسل الترحيل العملي حادًا وقابلاً للقياس.</p> <p>أولاً، تحقق من سلوك المصادقة الحالي الآن. قم بتشغيل فحوصات قائمة على التتبع والتحقق من صحة ذاكرة التخزين المؤقت للتذاكر في سياقات المطورين ووكلاء البناء الحقيقية، بما في ذلك مسارات خارج المجال والشبكات البعيدة. ثانيًا، أصلح Kerberos من النهاية إلى النهاية: SPNs، وأسماء DNS المستعارة، وإعدادات موازن التحميل، والتفويض، وقابلية الوصول إلى وحدة تحكم المجال. ثالثًا، حدد سيناريوهات غير المنضمة إلى المجال أو مجموعة العمل مبكرًا وصمم مسار SSH حيث لا يمكن جعل Kerberos موثوقًا.</p> <p>تحتاج أيضًا إلى وضوح الملكية. فرق الأمان يجب أن تحدد خطوط الأساس للسياسات، لكن هندسة المنصة يجب أن تملك جاهزية التنفيذ. هذا لا يمكن أن يكون مهمة جانبية لمسؤولي المستودعات الأفراد. يتطلب تغييرات منسقة عبر IIS و AD وحافة الشبكة ووكلاء CI وإرشادات مطور الأجهزة.</p> <p>خطر دقيق واحد هو الأتمتة. وكلاء البناء وحسابات الخدمة غالبًا ما تعمل في سياقات حيث تكون تذاكر Kerberos مفقودة أو غير صالحة، حتى عندما يكون المستخدمون البشريون بخير. إذا اختبرت فقط سير عمل المطورين التفاعلية، فستفوت نقاط الكسر الأكثر خطورة.</p> <p>الجانب الإيجابي حقيقي. الانتقال النظيف إلى Kerberos أو SSH لا يتجنب الكسر فقط، بل يقلل سطح الهجوم ويوائم ضوابط الهوية مع توقعات الامتثال الحديثة. الفرق التي تبدأ هذا الانتقال الآن ستتعامل مع سبتمبر كحدث عادي. الفرق التي تنتظر ستصحح أخطاء المصادقة تحت ضغط الإصدار.</p> <p>هذا ليس تحذيرًا للأرشفة. إنه موعد نهائي للتنفيذ ضده.</p>