VPN வழியாக SQL Server இன்னும் NTLM க்கு ஏன் திரும்புகிறது?

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

நீங்கள் உண்மையில் பெற்ற திட்டத்தை அமர்வு பெயரிடுகிறது

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

SELECT session_id, auth_scheme, net_transport, client_net_address, login_name
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

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

முதல் நிபந்தனை: பெயர் SPN உடன் பொருந்துகிறதா?

Kerberos பெயரிடப்பட்ட சேவையை அங்கீகரிக்கிறது, எனவே வாடிக்கையாளர் ஒரு குறிப்பிட்ட முதன்மைக்கான டிக்கெட்டை அடைவிடம் கேட்கிறார். TCP வழங்குநருக்கு ஆவணப்படுத்தப்பட்ட வடிவம் MSSQLSvc/, அதைத் தொடர்ந்து முழுமையாக தகுதிபெற்ற ஹோஸ்ட் பெயர் மற்றும் இயல்புநிலை நிகழ்வுக்கு போர்ட். பெயரிடப்பட்ட நிகழ்வு MSSQLSvc/db01.corp.example:SQLPROD ஐப் பதிவு செய்கிறது, அங்கு பின்னொட்டு எண்ணுக்குப் பதிலாக நிகழ்வின் பெயர். அலியாஸ், வேறெங்கு தீர்க்கப்படும் CNAME அல்லது வெறும் IP முகவரி வழியாகக் கேட்பவரை அடைவது கேட்கப்பட்ட பெயரை மாற்றுகிறது, பொருந்தும் முதன்மை இல்லாத கோரிக்கைக்கு திருப்பித் தர டிக்கெட் இல்லை.

அதனால்தான் ஒரு பயன்பாடு ஒரு வலையமைப்பில் வேலை செய்து மற்றொன்றில் பின்வாங்குகிறது: DNS பதில், அலியாஸ் பதிவு அல்லது hosts உள்ளீடு வாடிக்கையாளர் பயன்படுத்திய பெயரை மாற்றியது. பதிவைத் தொடுவதற்கு முன் கேட்கப்பட்ட பெயரை அடைவில் உள்ளவற்றுடன் ஒப்பிடுங்கள்.

இரண்டாவது நிபந்தனை: SPN சரியான கணக்கில் உள்ளதா?

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

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

setspn -Q MSSQLSvc/db01.corp.example:1433
setspn -L CORP\svc-sql01

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

மூன்றாவது நிபந்தனை: வாடிக்கையாளர் டிக்கெட் பெற முடியுமா?

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

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

klist
klist -li 0x3e7

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

தொடக்கியை மாற்றுவது ஒரு மாறி, தீர்வு அல்ல

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

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

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