Anda menerima informasi yang peringatan "Peringatan SuperSocket Info" ketika account layanan SQL Server adalah pengguna domain

Terjemahan Artikel Terjemahan Artikel
ID Artikel: 303411 - Melihat produk di mana artikel ini berlaku.
BUG #: 232774 (SHILOH_BUGS)
Perbesar semua | Perkecil semua

Gejala

Ketika SQL Server dimulai pada komputer yang menjalankan Microsoft SQL Server 2000 atau Microsoft SQL Server 2005, SQL Server program selalu mencoba untuk mendaftar server virtual di Active Directory. Acara berikut ini mungkin login di log peristiwa:

SuperSocket info: (SpnRegister): kesalahan 8344 SuperSocket Info: (SPNRegister): kesalahan 1355 SuperSocket info: SpnUnRegister(): 8344 kesalahan.

CatatanKesalahan 1355 sama dengan ERROR_NO_SUCH_DOMAIN. Kesalahan 8344 sama dengan izin yang tidak cukup untuk melakukan operasi pendaftaran. Hal ini terbukti sebagai peringatan untuk fungsi SPNRegister dan kesalahan untuk fungsi SpnUnRegister .

Pesan ini bukanlah sebuah pesan kesalahan. Teks ini adalah hanya peringatan bahwa SQL Server tidak dapat mendaftar nama utama layanan (SPN). Hal ini menunjukkan bahwa mekanisme keamanan yang akan digunakan Otentikasi Microsoft Windows NT Challenge\Response (NTLM) bukan otentikasi Kerberos.

Pesan ini hanya boleh dipertimbangkan masalah jika instalasi SQL Server membutuhkan otentikasi Kerberos atau pengaturan keamanan jaringan mencegah fallback ke NTLM negosiasi. Jika tidak, pesan ini dapat diabaikan dengan aman.

Penyebab

Pesan ini biasanya muncul karena layanan SQL Server rekening menjalankan sebagai pengguna domain yang tidak memiliki izin yang diperlukan untuk mendaftar SPNs. Dengan Microsoft Windows 2000 Service Pack 3 (SP3), Anda dapat mengaktifkan otentikasi Kerberos pada server cluster. Untuk petunjuk tentang cara untuk melakukan ini, Lihat artikel berikut pada Pangkalan Pengetahuan Microsoft:
319723 Informasi tentang SQL Server 2000 Kerberos dukungan, termasuk SQL Server virtual server pada server cluster

Pemecahan masalah

Anda juga dapat mengedit izin akses kontrol pengaturan account di layanan direktori Active Directory untuk mengaktifkan izin servicePrincipalName membaca dan menulis servicePrincipalName izin untuk account layanan SQL.

Peringatan Jika Anda menggunakan Antarmuka layanan direktori Aktif (ADSI) Edit snap-in, utilitas LDP, atau LDAP versi 3 klien, dan Anda salah memodifikasi atribut objek direktori aktif, Anda dapat menyebabkan masalah serius. Masalah ini mungkin mengharuskan Anda untuk menginstal Microsoft Windows 2000 Server, Microsoft Windows Server 2003, Microsoft Exchange 2000 Server, Microsoft Exchange Server 2003, atau Windows maupun asing. Microsoft tidak dapat menjamin bahwa masalah yang disebabkan oleh salah memodifikasi atribut objek Active Directory dapat diselesaikan. Memodifikasi atribut ini risiko Anda sendiri.

Teknik pemecahan masalah

Untuk mengatasi pesan jenis ini dan mengaktifkan layanan SQL Server untuk membuat SPNs secara dinamis untuk contoh SQL Server Anda, minta administrator domain untuk menambahkan sesuai izin dan hak pengguna ke rekening startup SQL Server.

Untuk mengaktifkan account layanan SQL Server untuk mendirikan SPNs dengan benar pada startup, ikuti langkah berikut:
  1. Klik Mulai, klik Menjalankan, jenis ADSIEDIT.MSC, lalu klik Oke.
  2. Dalam ADSI Edit jendela, memperluas Domain [DomainName], memperluas DC = RootDomainName, memperluas CN = pengguna, klik kanan-atas CN =AccountName, lalu klik Properti.

    Catatan
    • DomainName mewakili nama domain.
    • RootDomainName adalah pengganti untuk nama domain akar.
    • AccountName mewakili account yang Anda tetapkan untuk memulai layanan SQL Server.
    • Jika Anda telah menetapkan Sistem lokal untuk memulai layanan SQL Server, AccountName mewakili account yang Anda gunakan untuk masuk ke Microsoft Windows.
    • Jika Anda telah menetapkan account pengguna domain untuk layanan SQL Server, AccountName mewakili account pengguna domain.
  3. Dalam CN =AccountName Properti kotak dialog, klik Keamanan tab.
  4. Pada Keamanan tab, klik Lanjutan.
  5. Dalam Setelan Keamanan tingkat lanjut kotak dialog, pastikan bahwa pengguna diri tercantum di bawah Izin entri. Jika pengguna diri tidak tercantum, klik Tambahkan, dan kemudian menambahkan pengguna diri .
  6. Di bawah Izin entri, klik DIRI, lalu klik Mengedit.
  7. Dalam Izin masuk kotak dialog, klik Properti tab.
  8. Pada Properti tab, klik Objek ini hanya dalam Menerapkan Daftar, dan kemudian pastikan bahwa hak akses berikut yang dipilih di bawah Izin:
    • Baca servicePrincipalName
    • Menulis servicePrincipalName
  9. Klik Oke tiga kali, dan kemudian tutup ADSI Edit jendela.
Untuk bantuan dengan proses ini, hubungi dukungan produk Active Directory. Lihat artikel Pangkalan Pengetahuan Microsoft ini jika Anda menghubungi dukungan produk.

Ketika Anda melakukan prosedur ini, Anda menghilangkan masalah SPN untuk instalasi baru atau instalasi yang telah memiliki TCP/IP port atau nama domain diubah.

Penting Kami merekomendasikan bahwa Anda tidak memberikan WriteServicePrincipalName hak untuk account layanan SQL ketika kondisi berikut ini benar:
  • Ada beberapa pengendali domain.
  • Berkerumun SQL Server.
Dalam skenario ini, SPN untuk SQL Server mungkin dihapus karena latency di replikasi direktori aktif. Ini dapat menyebabkan masalah konektivitas ke SQL Server misalnya.

Asumsikan bahwa Anda memiliki yang berikut:
  • Contoh virtual SQL yang bernama Sqlcluster dengan dua node: Node A dan Node B.
  • Node A disahkan oleh pengendali domain A dan Node B disahkan oleh pengendali domain B.


Berikut mungkin terjadi:
  1. Contoh Sqlcluster aktif pada Node A dan terdaftar SPN SQL di pengontrol domain A selama start up...
  2. Contoh Sqlcluster gagal atas Node B ketika Node A biasanya shutdown.
  3. Contoh Sqlcluster tersebut telah dengan SPN dari domain controller A selama proses shutdown pada Node A.
  4. SPN akan dihapus dari domain controller A tetapi perubahan ini belum belum dapat ditiru untuk pengendali domain B.
  5. Ketika memulai pada Node B, contoh Sqlcluster mencoba untuk mendaftar SQL SPN dengan pengontrol domain B. Karena, SPN masih ada Node B tidak mendaftar SPN.
  6. Setelah beberapa waktu, pengontrol domain A bereplikasi penghapusan SPN (dari langkah 3) untuk pengendali domain B sebagai bagian dari replikasi direktori aktif. Hasil akhirnya adalah bahwa ada SPN tidak sahih untuk contoh SQL dalam domain dan karenanya Anda melihat masalah sambungan ke Sqlcluster instance.

Catatan Masalah ini telah diperbaiki pada SQL Server 2012.

Status

Microsoft telah mengkonfirmasi bahwa ini merupakan masalah di SQL Server 2000 dan SQL Server 2005.

Referensi

Untuk informasi lebih lanjut, klik nomor artikel berikut ini untuk melihat artikel di dalam Pangkalan Pengetahuan Microsoft:
235529Kerberos dukungan pada cluster server berbasis Windows 2000
269229 Cara secara manual membuat kembali account layanan gugus

Properti

ID Artikel: 303411 - Kajian Terakhir: 07 April 2013 - Revisi: 4.0
Berlaku bagi:
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL Server 2005 Workgroup Edition
  • Microsoft SQL Server 2000 Personal Edition
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft SQL Server 2000 Workgroup Edition
  • Microsoft SQL Server 2000 Developer Edition
  • Microsoft SQL Server 2000 Enterprise Edition
Kata kunci: 
kbbug kbpending kbmt KB303411 KbMtid
Penerjemahan Mesin
PENTING: Artikel ini diterjemahkan menggunakan perangkat lunak mesin penerjemah Microsoft dan bukan oleh seorang penerjemah. Microsoft menawarkan artikel yang diterjemahkan oleh seorang penerjemah maupun artikel yang diterjemahkan menggunakan mesin sehingga Anda akan memiliki akses ke seluruh artikel baru yang diterbitkan di Pangkalan Pengetahuan (Knowledge Base) dalam bahasa yang Anda gunakan. Namun, artikel yang diterjemahkan menggunakan mesin tidak selalu sempurna. Artikel tersebut mungkin memiliki kesalahan kosa kata, sintaksis, atau tata bahasa, hampir sama seperti orang asing yang berbicara dalam bahasa Anda. Microsoft tidak bertanggung jawab terhadap akurasi, kesalahan atau kerusakan yang disebabkan karena kesalahan penerjemahan konten atau penggunaannya oleh para pelanggan. Microsoft juga sering memperbarui perangkat lunak mesin penerjemah.
Klik disini untuk melihat versi Inggris dari artikel ini: 303411

Berikan Masukan

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com