AlwaysOn Replica eklenirken alınan hata: The target principal name is incorrect. Cannot generate SSPI context.

Bu post’ta bugün karşılaştığım bir hatayı ve çözüm yolunu anlatacağım. Danışmanlık verdiğim müşterime daha önceden 3 replica’lı bir SQL Server 2012 AlwaysOn topolojisi kurmuştuk. Disaster Recovery için atadığımız cloud’da çalışan replica’yı çıkartıp, yine cloud üzerinden fakat farklı bir lokasyondan replica eklemem istendi. Çıkartılacak replica’yı önce Availability Group’tan sonrada Windows Server Failover Cluster’dan çıkarttım. Yeni replica için müşterimdeki DBA arkadaşın hazırladığı sunucuyu eklemek istediğimde SQL Server servisinin kurulması gereken domain account ile yapılandırılmadığını farkettim. Bunun üzerine Configuration Manager üzerinden SQL Server servis account’unu istenildiği şekilde yapılandırdık. Ardından Primary Replica üzerinde yeni node’u eklemek istediğimizde aşağıdaki hata mesajını aldım.

Bu hata mesajı son yaptığımız işlem sonrasında oluşmuştu. Bu işlemden önce yeni replica, Availability Group topolojisine eklenebiliyordu. Windows Server log’larına baktığımda problemin Kerberos Authentication ve Service Principal Name (SPN) ile alakalı olduğunu anladım. Security Support Provider Interface (SSPI), TCP/IP haberleşmesi için kullanılan Windows API’leri ile delege olan bir API paketidir. SSPI, Windows sunucuların birbirleri aralarında güvenli bir token ile raw veriyi transfer eder. Aldığım bu hata mesajı primary replica’nın yeni eklediğimiz secondary görevini üstlenecek replica’ya erişmek istediğinde Kerberos Authentication’ını kullanarak mevcut güvenli token’ı alamamasından kaynaklandığını gördüm. Bu probleme SQL Server servisinin account’unu değiştirdiğimde Active Directory üzerinden permission’ların resetlendiği ve token’ın kaybedilmesi yol açmıştı. Benim yaşadığım case’de sırasıyla aşağıdaki adımları izleyerek problemi giderdik.

• Sistem Yöneticisi arkadaş’a sunucuyu domain’den çıkartıp workgroup’a aldırttım.
• Sunucu workgroup’a alındığında restart ettirdik.
• Active Directory’den sunucunun computer objesini ve ona bağlı oluşan bütün objeleri sildik.
• Sunucuyu yeniden domain’e aldık.

SSPI problemlerinin kaynağı herzaman bu case’deki gibi olmaya biliyor. Benim izlediğim yol normalde tercih edilmemesi gerken bir yoldur. Fakat çok hızlı aksiyon almamız gerektiğinde bu yolu tercih etmem gerekti. Asıl tercih edilmesi gereken ve en başta uygulanması gereken SPN’in SQL Server servis account’u için dinamik yaratılması olmalıdır. Bunun için aşağıdaki adımlar izlenmelidir.

• Run‘a adsiedit.msc yazılarak low-level Active Directory editor’e geçilir.
• Sırasıyla Default naming context -> DC=domain,DC=com -> CN=Users -> CN=İlgiliAccount‘a gelinir ve sağ tıklayarak Properties’e geçilir.
• Açılan pencerede Security tab’ına geçilip Advanced‘e tıklanır.
• Advanced Security Settings ekranındaki Permission entries kısmında SELF‘in olduğu kontrol edilmeli eğer yoksa eklenmelidir.
• Permission entries kısmında SELF‘e tıklanıp Edit denir.
• Permission Entry ekranında Properties‘e geçilir.
• Apply onto listesinde This object only‘e tıklanır.
• Read servicePrincipalName ve Write servicePrincipalName permission’larının seçili olduğu kontrol edilmeli eğer seçili değilse seçilmelidir.