Office 365'teki kurumsal tek oturum açma kullanıcıları, kurumsal ağlarının içinden Skype for Business Online'da oturum açamıyor

SORUN

Aşağıdaki senaryoyu inceleyin:

• İşletmeler için Office 365, eğitim için Office 365 veya Office 365 iş müşterisi Active Directory Federation Services (AD FS) 2.0'da tek oturum açma (SSO) kurar.

• Kurumsal ağlarının içinden bağlanan federe kullanıcılar, Lync 2013'ten Skype for Business Online'da (eski adıyla Lync Online) oturum açabiliyor ve aşağıdaki hata iletisini alıyorlar:

  Sunucu geçici olarak kullanılamadığı için oturum açamıyor.

Not Bu sorun yalnızca Lync 2013'ü kurumsal ağlarının içinden kullanarak Skype for Business Online'da oturum açan Enterprise SSO kullanıcıları için geçerlidir. Sorun Microsoft Lync 2010'daki kullanıcılar, Skype for Business Online'da olmayan kullanıcılar veya şirket ağlarının dışından bağlanan kullanıcılar için geçerli değildir.

ÇÖZÜM

Önemli Bu bölümdeki adımları dikkatle izleyin. Kayıt defterini yanlış değiştirirseniz ciddi sorunlar oluşabilir. Değiştirmeden önce, sorunlar oluşması durumunda geri yükleme için kayıt defterini yedekle. Birçok olası nedeni olduğundan, en iyisi aşağıdaki çözümleri gözden geçirmek ve sonra yapılandırmayı doğrulamaktır.

1. Bir AD FS 2.0 Federation Server çiftliği dağıttığınızda, Kerberos kimlik doğrulamanın düzgün çalışmasını sağlamak için kayıtlı bir SPN'ye ihtiyaç darayan etki alanı tabanlı bir hizmet hesabı belirtmeniz gerekir. Daha fazla bilgi için aşağıdaki TechNet wiki'ye bakın:

   AD FS 2.0: Hizmet Hesabı için SPN (servicePrincipalName) nasıl yapılandırılabilenSPN'yi AD FS 2.0 hizmet hesabında el ile ayarlamanız gereken nedenler şunlardır:

   • SPN kaydı, çiftliğin ilk yapılandırması sırasında başarısız oldu.

   • Federasyon Hizmeti adı değiştirildi.

   • Hizmet hesabı değiştirildi.

2. AD FS 2.0 hizmetinin önceki adımda belirtilen etki alanı tabanlı hizmet hesabı altında çalıştırdığından emin olun. Örneğin, aşağıdaki resimde, TRLABV3 iç ana bilgisayar adıdır ve ADFSSvc hizmet hesabıdır:

3. AD FS 2.0 sunucusunu, 40 kilobayttan (KB) büyük istek üstbilgilerini kabul etmek üzere yapılandırın. Kullanıcı birçok Active Directory Domain Services (AD DS) kullanıcı grubuna üye olduğunda bunu yapmanız gerekebilir. Bir kullanıcı birçok AD DS grubuna üye olduğunda, kullanıcı için Kerberos kimlik doğrulama belirteci boyutu artar. Kullanıcının Internet Information Services (IIS) sunucusuna gönderdiği HTTP isteği, WWW-Authenticate üstbilgisinde Kerberos belirteci içerir. Bu nedenle, grup sayısı arttıkça üstbilgi boyutu artar. HTTP üstbilgi veya paket boyutu IIS'de yapılandırılan sınırların ötesine geçerek artarsa, IIS isteği reddedebilir ve yanıt olarak bir hata gönderebilir. Daha fazla bilgi için aşağıdaki Microsoft Bilgi Bankası makalesine bakın:

   2020943 "HTTP 400 - Kötü İstek (İstek Üstbilgisi çok uzun)" hatası Internet Information Services (IIS)Bu sorunu çözmek için aşağıdaki yöntemlerden birini kullanın:

   1. Kullanıcının üyesi olduğu AD DS kullanıcı gruplarının sayısını azaltın.

   2. Kullanıcının istek üstbilgilerinin çok uzun kabul edilemeyecek şekilde IIS çalıştıran sunucudaki MaxFieldLength ve MaxRequestBytes kayıt defteri değerlerini değiştirin. Bu iki kayıt defteri değeri aşağıdaki kayıt defteri alt anahtarının altında yer alır:

      HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters

4. Bir çiftlikte birden fazla AD FS 2.0 sunucusu dağıttıysanız ve bunları dengeli bir şekilde yüklemelerini söylediyseniz, Lync 2013 istemcisi isteği AD FS 2.0 sunucusuna yönlendiremeyebilir. Doğrudan AD FS 2.0 sunucusuna işaret eden istemcideki Hosts dosyasına AD FS 2.0 sunucusu için bir giriş eklemek, yük dengeleyicisinin sanal IP'sini atlatır.

5. Önceki çözümler sorunu çözmediyse ve Lync 2010'a düşürme bir seçenek değilse, sorunu çözmek için aşağıdaki adımları izleyin. Not Bilgisayarda zaten yerel bir yönetici hesabı yoksa, bu çözümün çalışması için bir hesap oluşturmanız gerekir.

   1. Windows Gezgini'nde çalıştırılabilen Lync 2013'e göz atın:

       C:\Program Files\Microsoft Office 15\root\office15 

   2. Shift tuşuna basılı tutun ve sonra Lync.exe'ye sağ tıklayın.

   3. Farklı kullanıcı olarak Çalıştır'ıtıklatın.

   4. Bilgisayardaki yerel yönetici hesabının kimlik bilgilerini girin ve enter tuşuna basın.

DAHA FAZLA BİLGİ

Bu sorun genellikle AD FS 2.0'daki bir yanlış yapılandırma nedeniyle oluşur. Microsoft Exchange Online gibi diğer hizmetler bu yapılandırmaya rağmen doğru çalışabilir. Olağan nedenleri burada listelenmiştir:

• ServicePrincipalName (SPN) doğru şekilde yapılandırılmamıştır. Bunun nedenleri şunlardır:

  • SPN kaydı, çiftliğin ilk yapılandırması sırasında başarısız oldu.

  • Federasyon Hizmeti adı değiştirildi.

  • Hizmet hesabı değiştirildi.

• AD FS 2.0 hizmeti doğru hizmet hesabı altında çalışmıyor.

• Lync 2013'ün istek üstbilgisi, üstbilgi çok büyük olduğundan IIS ve AD FS 2.0 sunucusu tarafından reddedilir. Kullanıcı hesabı çok fazla AD DS kullanıcı grubuna üye olduğundan bu sorun oluşabilir.

• AD FS 2.0 sunucu çiftliği yük dengeli ve istek AD FS 2.0 sunucusuna ulaşmıyor.

AD FS 2.0'ı Office 365'te SSO ile kullanmak üzere dağıtma konusunda daha fazla bilgi için aşağıdaki TechNet web sitesine bakın:

Tek oturum açma ile kullanım için AD FS için planlayın ve dağıtınKullanıcıçok fazla AD DS grubuna üye olduğunda, aşağıdaki giriş Microsoft Çevrimiçi Hizmetler Oturum Açma Yardımcısı izleme günlüklerine girilir (bu günlükler genellikle C:\ MSOSSPTrace):

##TestHook: URL-https://<ADFSServer>/adfs/services/trust/2005/windowstransport@transport.cpp_245..........<HTML><HEAD><TITLE>Bad Request</TITLE><META HTTP-EQUIV="Content-Type" Content="text/html; charset=us-ascii"></HEAD><BODY><h2>Bad Request - Request Too Long</h2><hr><p>HTTP Error 400. The size of the request headers is too long.</p></BODY></HTML> 

Hala yardıma ihtiyacın var mı? Microsoft Topluluğu'nagidin.