VPN இணைகிறது, ஆனால் SQL Server Windows அங்கீகாரத்தை நிராகரிக்கிறது

சுரங்கப்பாதைகள் எழுகின்றன, சேவையகங்கள் ping க்கு பதிலளிக்கின்றன, ஆனால் தரவுத்தள உள்நுழைவு இன்னும் அங்கீகாரப் பிழையுடன் தோல்வியடைகிறது. இந்தக் கலவை VPN இணைப்புகளில் பொதுவானது மற்றும் பிணையம் உடைந்துவிட்டது என்று அரிதாகவே பொருள் தருகிறது, ஏனெனில் அணுகக்கூடிய கேட்பவர் மற்றும் ஏற்கப்பட்ட உள்நுழைவு இரண்டு வெவ்வேறு முடிவுகள். நுழைவாயிலை திருப்திப்படுத்திய அடையாளம் தரவுத்தள வாடிக்கையாளர் வழங்கும் அடையாளமாக இருக்க வேண்டிய அவசியமில்லை. எந்தக் கணக்கு வந்தது என்பதைக் கண்டறிவதே முழு வேலை.

அறிகுறி: அணுகக்கூடிய சேவையகம், நிராகரிக்கப்பட்ட உள்நுழைவு

நேர முடிவு தொகுப்பு எந்தக் கேட்பவரையும் அடையவில்லை என்று சொல்கிறது. அங்கீகாரப் பிழை கேட்பவர் பதிலளித்து சான்றுகளை நிராகரித்தது என்று சொல்கிறது. இந்த இரு செய்திகளும் உங்களை வெவ்வேறு குழுக்களுக்கு அனுப்புகின்றன, அவற்றைக் கலப்பது ஒருபோதும் பிரச்சினையாக இல்லாத தீவனச் சுவர் விதிகளுக்கு ஒரு நாளை வீணாக்குகிறது.

பிழை உள்நுழைவுத் தோல்வியாக இருக்கும்போது, துறைகளைப் பார்ப்பதை நிறுத்துங்கள். மீதமுள்ள கேள்வி என்னவென்றால், வாடிக்கையாளர் எந்த Windows அடையாளத்தை வழங்கினார், சேவையகம் அந்த அடையாளத்தை ஏற்றுக்கொண்டதா, மற்றும் அது அனுமதி உள்ள தரவுத்தளப் பயனராகத் தீர்க்கப்பட்டதா என்பதே.

இரண்டு அடையாளங்கள், ஒரு சுரங்கப்பாதை

VPN கணக்கு நுழைவாயிலில் அங்கீகரிக்கப்படுகிறது, மற்றும் பெரும்பாலான வரிசைப்படுத்தல்களில் அங்கேயே முடிகிறது. தரவுத்தள வாடிக்கையாளர் தனித்தனியாக ஒரு Windows டோக்கனை வழங்குகிறது, அது அதை இயக்கும் செயல்முறையிலிருந்து எடுக்கப்படுகிறது, அல்லது இணைப்புச் சரம் கேட்டால் SQL உள்நுழைவை வழங்குகிறது. நுழைவாயிலின் உள்ளூர் VPN பயனருக்கு SQL Server ஐ ஹோஸ்ட் செய்யும் களத்துடன் எந்தத் தொடர்பும் இல்லை, சுரங்கப்பாதை அத்தகைய தொடர்பை உருவாக்காது.

தனிப்பட்ட கணினியை VPN உடன் இணைப்பது அதை களத்திலும் சேர்க்காது. உள்ளூர் கணக்கின் பெயரை மாற்றி அதன் கடவுச்சொல்லை களப் பயனருடன் பொருத்துவது பதிவுச் செயல்முறை அல்ல, மேலும் அது களக் கட்டுப்படுத்தி அந்தப் பயனராக ஏற்காத டோக்கனை உருவாக்குகிறது.

சில உள்ளூர் Windows தொலை அணுகல் வாடிக்கையாளர்கள் தங்கள் சுயவிவரம் அவ்வாறு அமைக்கப்பட்டிருந்தால் பிணைய வளங்களுக்கு VPN சான்றுகளை மீண்டும் பயன்படுத்தலாம். அந்த நடத்தை ஒரு குறிப்பிட்ட வாடிக்கையாளர் மற்றும் சுயவிவரத்திற்கானது, பொதுவாக VPN இணைப்புகளுக்கானது அல்ல, எனவே ஊகிப்பதற்குப் பதிலாக பயன்படுத்தப்படும் வாடிக்கையாளருக்கு அதைச் சரிபார்க்கவும்.

வாடிக்கையாளர் கேட்ட பயன்முறையைப் படியுங்கள்

இணைப்புச் சரம் வாடிக்கையாளர் எடுக்கும் அங்கீகாரப் பாதையைத் தீர்மானிக்கிறது. ஒருங்கிணைந்த பாதுகாப்பு Windows டோக்கனைப் பயன்படுத்துகிறது; பயனர் மற்றும் கடவுச்சொல் ஜோடி SQL உள்நுழைவைத் தேர்ந்தெடுக்கிறது. இவை சேவையகக் கட்டமைப்பில் தனித்தனி பயன்முறைகள், மேலும் கொடுக்கப்பட்ட இணைப்பு முயற்சிக்கு அவற்றில் ஒன்று மட்டுமே இயக்கப்பட முடியும்.

Server=tcp:sql.lab.example,1433;Database=ops;Integrated Security=SSPI;Encrypt=True;TrustServerCertificate=False;

Windows உள்நுழைவு தோல்வியடைந்ததால் SQL உள்நுழைவுக்கு மாறுவது அடையாளக் கேள்வியை மறைக்கும் தற்காலிக தீர்வு, மேலும் அது பொதுவாக புதிய உள்நுழைவும் கடவுச்சொல்லும் உருவாக்குவதை எப்படியும் கோருகிறது. வரிசைப்படுத்தலுக்கு Windows அங்கீகாரம் தேவைப்பட்டால், பயன்முறையை வைத்துக்கொண்டு அடையாளப் பாதையைச் சரிசெய்யுங்கள். SQL உள்நுழைவுக்கும் அதன் சொந்த அனுமதிகள் தேவை, எனவே தற்காலிக தீர்வு பராமரிக்க இரண்டாவது கணக்கை வாங்குகிறது.

எந்த பயன்பாடு இணைகிறது என்பதையும் உறுதிப்படுத்துங்கள். கணினிக் கணக்காக இயங்கும் சேவை, திட்டமிடப்பட்ட பணி மற்றும் ஊடாடும் வினவல் சாளரம் ஒரே கணினியில் மூன்று வெவ்வேறு டோக்கன்களை வழங்கலாம், மேலும் பயனர் whoami இயக்கும்போது பார்ப்பதுடன் கடைசியானது மட்டுமே பொருந்துகிறது.

சேவையகம் உண்மையில் என்ன பார்த்தது என்று கேளுங்கள்

எந்த உள்நுழைவை சேவையகம் தீர்த்தது, இணைப்பு எவ்வாறு அங்கீகரிக்கப்பட்டது என்பதை அது உங்களுக்குச் சொல்லும். விசாரிக்கப்படும் அமர்வின் உள்ளேயே வினவலை இயக்குங்கள், ஏனெனில் நிர்வாகியின் தனித்தனி வெற்றிகரமான இணைப்பு தோல்வியடையும் வாடிக்கையாளரைப் பற்றி எதையும் நிரூபிக்காது.

SELECT ORIGINAL_LOGIN() AS original_login,
       SUSER_SNAME() AS current_context;
SELECT auth_scheme, net_transport
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

முதல் வரிசை அமர்வைத் திறந்த உள்நுழைவை இப்போது நடைமுறையில் உள்ள பாதுகாப்புச் சூழலிலிருந்து வேறுபடுத்துகிறது, மேலும் ஆள்மாறாட்டத்தின் கீழ் இவை வேறுபடுகின்றன. இரண்டாவது அங்கீகாரத் திட்டத்தைப் பெயரிடுகிறது, எனவே KERBEROS, NTLM மற்றும் SQL ஊகங்களுக்குப் பதிலாக தெரியும் உண்மைகளாக மாறுகின்றன. Kerberos எதிர்பார்த்த இடத்தில் NTLM தெரிவிக்கும் இணைப்பு கடவுச்சொல் பிரச்சினை அல்ல, பெயர் தீர்வு அல்லது SPN பிரச்சினை.

பிழை எண் அதை மேலும் குறுக்குகிறது. நிலை 5 பொதுவாக உள்நுழைவுப் பெயர் அறவே தீர்க்கப்படவில்லை என்று பொருள், நிலை 8 பொதுவாக கடவுச்சொல் பொருந்தவில்லை என்று பொருள், நிலை 11 சான்று ஏற்கப்பட்டது ஆனால் சேவையக அணுகல் தோல்வியடைந்தது என்று பொருள். முழு செய்திக்குப் பதிலாக நிலையை நிர்வாகியிடம் கேளுங்கள், ஏனெனில் செய்தி மட்டும் வேண்டுமென்றே தெளிவற்றது.

அடையாளம் வந்த பிறகும் Kerberos தோல்வியடையும்போது

சேவையகம் நோக்கம் கொண்ட Windows அடையாளத்தைப் பார்த்தும் ஒருங்கிணைந்த அங்கீகாரம் இன்னும் தோல்வியடைந்தால், பிரச்சினை பரிமாற்றமே. Kerberos க்கு SQL சேவைக் கணக்கிற்குப் பதிவுசெய்யப்பட்ட சேவை முதன்மைப் பெயர் (SPN) மற்றும் அதற்குப் பொருந்தும் பெயரில் சேவையைக் கோரும் வாடிக்கையாளர் தேவை. IP முகவரி வழியாக இணைப்பது பெயர் அடிப்படையிலான SPN உடன் பொருந்த முடியாது, மாற்றுப்பெயர் அதுவும் பதிவுசெய்யப்பட்டிருந்தால் மட்டுமே பொருந்த முடியும். எல்லாவற்றுக்கும் முன் வாடிக்கையாளர் தட்டச்சு செய்த பெயரைச் சரிபார்க்கவும், ஏனெனில் ஹோஸ்ட் பெயரால் வேலை செய்து IP யால் தோல்வியடையும் இணைப்பு இந்தப் பிரச்சினையையே விவரிக்கிறது.

சோதனை மற்றும் பிழை மூலம் நகல் SPN களை உருவாக்குவதற்குப் பதிலாக பதிவுசெய்யப்பட்ட அடையாளத்தையும் சேவைக் கணக்கையும் மறுபரிசீலனை செய்ய நிர்வாகியைக் கேளுங்கள். நகல் பதிவுகள் அசல் பிரச்சினையை விட கண்டறிய கடினமான இடைவிட்ட தோல்விகளை உருவாக்குகின்றன.

அங்கீகாரம் வேலை செய்த பிறகும் உள்நுழைவுக்கு தரவுத்தளப் பயனர் மற்றும் அனுமதிகள் தேவை. வெற்றிகரமான VPN உள்நுழைவு, வெற்றிகரமான Windows உள்நுழைவு மற்றும் குறிப்பிட்ட அட்டவணையைப் படிக்கும் அனுமதி ஆகியவை மூன்று தனித்தனி முடிவுகள், மேலும் டிக்கெட்டை மூடுவதற்கு முன் ஒவ்வொன்றும் அதன் சொந்த சரிபார்ப்புக்குத் தகுதியானது.