Windows NT კითხვა/პასუხი. ინტეგრირებული Windows ავთენტიფიკაციით, კლიენტის ბრაუზერი ამოწმებს თავს სერვერზე კრიპტოგრაფიული კომუნიკაციის საშუალებით.

Windows ინტეგრირებული ავთენტიფიკაცია მხარს უჭერს როგორც Kerberos v5 პროტოკოლს, ასევე NTLM (NT LAN Manager) პროტოკოლს ავთენტიფიკაციისთვის Negotiate პაკეტის მეშვეობით. თუ ხელმისაწვდომია Active Directory და შესაბამისი ბრაუზერის მხარდაჭერა (IE 5 ან უფრო მაღალი Windows 2000 პლატფორმაზე), გამოიყენება Kerberos პროტოკოლი, წინააღმდეგ შემთხვევაში გამოიყენება NTLM პროტოკოლი. ორივე Kerberos და NTLM აქვს გარკვეული შეზღუდვები. საინტერესო ფაქტია, რომ ერთის უპირატესობა მეორის სისუსტეებს შეესაბამება. Kerberos ზოგადად მუშაობს პროქსი სერვერებთან, მაგრამ firewallsმისი ფუნქციონირება არც ისე ეფექტურია. NTLM ჩვეულებრივ მუშაობს firewalls-ის მეშვეობით, მაგრამ საკმაოდ ზომიერად ურთიერთქმედებს პროქსი სერვერებთან.

რამდენიმე სიტყვა Microsoft Negotiate-ის შესახებ

Microsoft Negotiate არის პაკეტი, რომელიც ემსახურება როგორც ინტერფეისს უსაფრთხოების მხარდაჭერის სხვადასხვა პროვაიდერებს შორის. მას შეუძლია აირჩიოს ავტორიზაციის სხვადასხვა პაკეტებს შორის. IIS იყენებს Negotiate პაკეტს ავტორიზაციისთვის, ამ შემთხვევაში არჩევანია Kerberos ან NTLM. ეს პაკეტი ასევე ამატებს მხარდაჭერას მომავლისთვის ავთენტიფიკაციის პაკეტები, რაც არის Negotiate-ის უპირატესობა. ნაგულისხმევად, Negotiate ირჩევს Kerberos, როგორც ყველაზე უსაფრთხო პროტოკოლს. თუ რაიმე მიზეზით Kerberos-ის პროტოკოლი მიუწვდომელია, მაშინ Negotiate უბრუნდება NTLM-ის გამოყენებას.

NTLM ავთენტიფიკაცია

NTLM არის ძველი LM (LAN Manager) ავტორიზაციის პროტოკოლის გაუმჯობესებული ვერსია. NTLM მუშაობს კითხვა/პასუხის გზით სერვერსა და კლიენტს შორის მომხმარებლის პაროლის ქსელში მკაფიო ტექსტით გადაცემის გარეშე. კლიენტმა უნდა დაადასტუროს, რომ მან იცის მომხმარებლის პაროლი დაშიფრული ჰეშის გაგზავნით.

NTLM მუშაობს შემდეგნაირად.

1. კლიენტის კომპიუტერზე შესვლისას მომხმარებელი განსაზღვრავს მომხმარებლის სახელს, პაროლს და დომენის სახელს.
2. კლიენტი ქმნის ჰეშს მითითებული პაროლიდა წაშლის ორიგინალს.
3. კლიენტი აგზავნის მომხმარებლის სახელს მკაფიო ტექსტით სერვერზე.
4. სერვერი უგზავნის 16-ბიტიან შემთხვევით მონაცემებს კლიენტს.
5. კლიენტი შიფრავს ამ ფრაგმენტს, ასევე მომხმარებლის პაროლის ჰეშს და გადასცემს მათ სერვერს.
6. სერვერი გადასცემს მომხმარებლის სახელს, შემთხვევითი მონაცემების ნაწილს და კლიენტის პასუხს დომენის კონტროლერს.
7. დომენის კონტროლერი შიფრავს შემთხვევითი მონაცემების ნაწილს მომხმარებლის პაროლთან ერთად და შემდეგ ადარებს მას სერვერის მიერ გაგზავნილ ელემენტებს.
8. თუ მნიშვნელობები ემთხვევა, დომენის კონტროლერი აცნობებს სერვერს, რომ ავტორიზაცია წარმატებული იყო.
9. თუ მნიშვნელობები ან მომხმარებლის სახელი არ ემთხვევა, დომენის კონტროლერი აცნობებს სერვერს, რომელიც შესაბამის შეტყობინებას უგზავნის კლიენტს. შემდეგ კლიენტის ბრაუზერი მოუწოდებს მომხმარებელს ავთენტიფიკაციის მონაცემები.

Kerberos ავთენტიფიკაცია

ძველ ბერძნულ მითოლოგიაში კერბეროსი არის ზღაპრული სამთავიანი ძაღლი, რომელიც იცავდა ქვესკნელს ხალხისგან. ამჟამად, ტერმინი Kerberos ეხება უსაფრთხო ავთენტიფიკაციის პროტოკოლს რესურსებზე წვდომისთვის. Kerberos დაფუძნებულია პირადი გასაღების ავთენტიფიკაციაზე, რომლის დროსაც კლიენტი და სერვერი იყენებენ ერთსა და იმავე გასაღებს დაშიფვრისა და გაშიფვრისთვის. კლიენტი ადასტურებს გასაღების ცოდნას შეტყობინების დაშიფვრით, ხოლო სერვერი ადასტურებს გასაღების ცოდნას შეტყობინების გაშიფვრით. შემდეგ სერვერი იღებს შეტყობინების ნაწილს, შიფრავს მას და უგზავნის კლიენტს. თუ შეტყობინების მთლიანობა შენარჩუნებულია, ავტორიზაციის შედეგი დადებითი იქნება.

Kerberos ეყრდნობა ცენტრალურ სერვერს სახელწოდებით Key Distribution Center (KDC) ( გასაღების სადისტრიბუციო ცენტრი), რომელიც უზრუნველყოფს ყველა საჭირო გასაღებს. KDC გამოსცემს ეგრეთ წოდებულ TGT-ებს (ბილეთების მინიჭების ბილეთებს) და აწვდის მათ კლიენტებს, რომლებიც ითხოვენ წვდომას სერვერზე არსებულ რესურსზე.

ქვემოთ მოცემულია კლიენტის მიერ საწყისი TGT ბილეთის მიღების პროცესი.

1. მომხმარებელი შედის კლიენტის კომპიუტერში მომხმარებლის სახელით და პაროლით.
2. კლიენტი შიფრავს პაროლს და ინახავს მას.
3. კლიენტი აგზავნის შეტყობინებას KDC-ს, რომ ითხოვს ავთენტიფიკაციის სერთიფიკატებს TGT სერვისისთვის, ასევე მომხმარებლის დაშიფრულ პაროლს.
4. KDC ადარებს დაშიფრულ პაროლს მის მთავარ ასლს, რათა გადაამოწმოს მათი ვინაობა. კლიენტის მიერ მოთხოვნაზე მიმაგრებული დროის ბეჭედი ასევე მოწმდება იმის უზრუნველსაყოფად, რომ დაბეჭდილი დრო არის KDC-ის დროიდან ხუთი წუთის განმავლობაში.
5. თუ არის სრული დამთხვევა, KDC ქმნის მოთხოვნილს ავთენტიფიკაციის მონაცემები TGT სერვისისთვის გენერირებით სესიის გასაღებიშედით სისტემაში და დაშიფრეთ იგი მომხმარებლის გასაღებით.
6. KDC ქმნის სხვა ფრაგმენტს ავთენტიფიკაციის მონაცემებიდაშიფვრის საშუალებით სესიის გასაღებიშესვლა და TGT მომხმარებელი საკუთარი მთავარი გასაღებით.
7. KDC აგზავნის ორივე ფრაგმენტს ავთენტიფიკაციის მონაცემებიკლიენტს.
8. კლიენტი შიფრავს შესვლის სესიის გასაღებს პირველი სეგმენტიდან ავთენტიფიკაციის მონაცემებიდაშიფრული პაროლის გამოყენებით და ინახავს ამ სესიის შესვლის გასაღებს ბილეთების ქეშიში.
9. კლიენტი ასევე ინახავს TGT-ს თავის ბილეთების ქეშში.

კლიენტს ახლა აქვს TGT და შეუძლია გამოიყენოს ის ბილეთების მისაღებად რესურსებზე წვდომისთვის. აი, როგორ ხდება ეს.

1. კლიენტი ითხოვს ბილეთს KDC-დან სერვერზე რესურსებზე წვდომისთვის. კლიენტი აწვდის თავის TGT-ს KDC-ს სასურველ რესურსის სახელთან და ავტორიზაციის შეტყობინებასთან ერთად, რომელიც დაშიფრულია შესვლის სესიის გასაღებით.

ცოტა ხნის წინ შემექმნა ეს პრობლემა: FireFox, Chrome, Operaარ მინდა გავლა NTLM ავტორიზაცია. ერთადერთი ვინც გაიარა ეს იყო ი.ე.. დამავიწყდა მეთქვა, რომ ეს პრობლემა ჩნდება Windows7. ამ პრობლემების მოგვარების მეთოდები ქვემოთ იქნება აღწერილი.

ოპერა:ოფიციალურად არ არის მხარდაჭერილი NTLM-ავტორიზაცია, თუმცა პარამეტრებში შეგიძლიათ იპოვოთ ელემენტი, რომელიც საშუალებას გაძლევთ ჩართოთ ან გამორთოთ ეს პარამეტრი. ამიტომ, თქვენი პროქსი სერვერის პარამეტრებში უნდა დაამატოთ ძირითადი ავტორიზაცია. გამორთვა NTLM ავტორიზაცია(და რეალურად ამ ბრაუზერმა პროქსის მეშვეობით იმუშაოს) გააკეთეთ შემდეგი:

1) ბრაუზერში ჩაწერეთ about:config
2) გადადით NetWork განყოფილებაში და მოხსენით ჩართვა NTLM პარამეტრზე
3) გადატვირთეთ ბრაუზერი.

მართალია, არის ერთი ნიუანსი (უხერხულობა, ასე ვთქვათ): როდესაც პირველად დაიწყებთ, თქვენ უნდა შეიყვანოთ თქვენი შესვლის პაროლი (სრულად, ანუ დომენთან ერთად) და შეამოწმოთ ყუთი. "შენახვა". ახლა, ყოველ ჯერზე, როცა ბრაუზერს გახსნით შემდეგ ჯერზე, ავტორიზაციის ნიშანი გამოჩნდება და თქვენ უბრალოდ უნდა დააჭიროთ "კარგი". მოუხერხებელია, მაგრამ რა შეგიძლიათ გააკეთოთ?

შენიშვნა: ზოგჯერ ზოგიერთ OS-ზე, პირიქით, საჭირო იყო ჩართვა NTLM ავტორიზაცია. შესაძლოა, ეს ასევე დამოკიდებული იყო ბრაუზერისა და OS-ის ვერსიებზე.

FireFox, Chrome:ისინი მხარს უჭერენ, თუმცა თქვენ უნდა გააკეთოთ პატარა შამანიზმი. მე აღვწერ რამდენიმე ვარიანტს, რომელიც აღმოვაჩინე ინტერნეტში, შეიძლება დაგჭირდეთ ყველაფერი სცადოთ, სანამ არ იპოვით თქვენთვის შესაფერისი.

1) თქვენ უნდა დაამატოთ პარამეტრი რეესტრში HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa ე.წ. LmCompatibilityLevelტიპი DWORDდა მიანიჭეთ მას მნიშვნელობა 1 . რის შემდეგაც მოგიწევთ კომპიუტერის გადატვირთვა (ეს არის ის ვარიანტი, რომელიც მე ვარგა)

2) რომ Firefoxშეეძლო გაიაროს ntlmავტორიზაცია, როგორც ჩანს, საკმარისია გახსნა about:config მისამართების ზოლში და შეცვალოს პარამეტრები შემდეგზე:

network.negotiate-auth.delegation-uris = http://,https://
network.negotiate-auth.trusted-uris = http://,https://

შემდეგ გადატვირთეთ ბრაუზერი.

3) გახსენით პოლიტიკის რედაქტორი ( gpedit.msc) კომპიუტერის კონფიგურაცია -> Windows კონფიგურაცია -> უსაფრთხოების პარამეტრები -> ლოკალური პოლიტიკა -> უსაფრთხოების პარამეტრები -> ქსელის უსაფრთხოება: LAN მენეჯერის ავთენტიფიკაციის დონე და დააყენეთ პარამეტრი გაგზავნეთ LM და NTLM - გამოიყენეთ NTLMv2 სესიის უსაფრთხოება მოლაპარაკებების დროს.

შემდეგ ჩვენ ვხურავთ პოლიტიკას და გადატვირთეთ.

თუ გაქვთ ინგლისური ვერსია, შემდეგ ასე: მანქანის პოლიტიკა-> კომპიუტერის კონფიგურაცია->ფანჯრების პარამეტრი->ლოკალური პოლიტიკა->უსაფრთხოების ვარიანტი->ქსელის უსაფრთხოება: LAN მენეჯერის ავტორიზაციის დონე და აირჩიეთ LM & NTLM — გამოიყენეთ NTLMv2 სესია მოლაპარაკების შემთხვევაში.

4) კიდევ ერთი ვარიანტია კონფიგურაცია მეშვეობით squid_ldap:

auth_param ძირითადი პროგრამა /usr/lib/squid3/squid_ldap_auth -b "cn=users,dc=office,dc=ru" -f "sAMAccountName=%s" -h 192.168.0.74 -D "cn=ადმინისტრატორი,cn=მომხმარებლები, dc=ოფისი,dc=ru" -w "სექპასი"
auth_param ძირითადი ბავშვები 5
auth_param ძირითადი სფერო ჩემი inet Proxy
auth_param ძირითადი რწმუნებათა სიგელები 60 წუთი

external_acl_type nt_groups %LOGIN /usr/lib/squid3/squid_ldap_group -R -b "cn=მომხმარებლები,dc=ოფისი,dc=ru" -f "(&(cn=%v)(memberOf=cn=%a,cn= მომხმარებლები,dc=ოფისი,dc=ru))" -D "cn=ადმინისტრატორი,cn=მომხმარებლები,dc=ოფისი,dc=ru" -w "secpass" -h 192.168.0.74

acl all src 0.0.0.0/0.0.0.0
acl group_inet გარე nt_groups inet

http_access დაშვება group_inet
http_reply_access დაშვება ყველას
icp_access ყველას დაუშვას
http_access უარყოფა ყველა

სცადე მაინც :)

Windows-ის გარემოში მუშაობა, ყველას სისტემის ადმინისტრატორიასე თუ ისე ხვდება ავთენტიფიკაციის სისტემებს. მაგრამ ბევრისთვის ეს მექანიზმი შავი ყუთია, როდესაც მიმდინარე პროცესების არსი გაურკვეველი რჩება. ამავე დროს, საწყისი სწორი პარამეტრებიავთენტიფიკაცია პირდაპირ გავლენას ახდენს ქსელის უსაფრთხოებაზე, ამიტომ მნიშვნელოვანია არა მხოლოდ მეთოდებისა და პროტოკოლების ცოდნა, არამედ მათი მუშაობის გაგება, სულ მცირე, ზოგად დონეზე.

ამ მასალის ფარგლებში განვიხილავთ ავტორიზაციის პროცედურების მიზანმიმართულად გამარტივებულ პრეზენტაციას, რაც საკმარისია ოპერაციის ძირითადი პრინციპის გასაგებად, შემდგომში ეს ცოდნა შეიძლება გაღრმავდეს სპეციალიზებული ლიტერატურის შესწავლით.

პირველ რიგში, მოდით დავაზუსტოთ პირობები. ბევრი ადამიანი აბნევს ავტორიზაციისა და ავტორიზაციის ცნებებს, თუმცა ეს განსხვავებული პროცედურებია.

• ავთენტიფიკაცია- მომდინარეობს ინგლისური სიტყვიდან ავთენტიფიკაცია, რომელიც შეიძლება ითარგმნოს როგორც იდენტიფიკაციაან ავთენტიფიკაცია. ეს სრულად ასახავს პროცესის არსს - მომხმარებლის ავთენტიფიკაციას, ე.ი. ჩვენ უნდა დავრწმუნდეთ, რომ მომხმარებელი, რომელიც ცდილობს სისტემაში წვდომას, არის ის, ვინც ამბობს, რომ არის.
• ავტორიზაცია- სიტყვის თარგმანი ავტორიზაციანიშნავს ნებართვა, ე.ი. ობიექტზე წვდომის უფლებების შემოწმება. ავტორიზაციის პროცესის გამოყენება შესაძლებელია მხოლოდ ავტორიზებული მომხმარებლისთვის, რადგან სანამ წვდომის უფლებებს შევამოწმებთ, უნდა გავარკვიოთ იმ ობიექტის ვინაობა, რომელზეც ვაპირებთ რაიმე უფლების მინიჭებას.

ამ პროცესის წარმოსახვის გასაადვილებლად, მოდით გავატაროთ მარტივი ანალოგი. საზღვარგარეთ ხარ და პოლიციელი გაჩერდება, პასპორტს აჩვენებ. პოლიციის თანამშრომელი ამოწმებს პასპორტში არსებულ ინფორმაციას და ადარებს ფოტოს - ეს არის ავთენტიფიკაციის პროცესი. მას შემდეგ რაც დარწმუნდება, რომ თქვენ ხართ, პოლიციელი ითხოვს თქვენი ვიზის ჩვენებას - ეს არის ავტორიზაციის პროცესი, ე.ი. შენი აქ ყოფნის უფლება.

ანალოგიურად, პოლიციელი, რომელმაც გააჩერა მიგრანტი მუშაკი და შეამოწმა მისი პასპორტი, ითხოვს მუშაობის ნებართვას, თუ არ არის ნებართვა, მაშინ უცხოელმა სტუმარმა წარმატებით გაიარა ავტორიზაცია, მაგრამ ვერ შეძლო ავტორიზაცია. თუ ავთენტიფიკაცია ვერ მოხერხდა, ავტორიზაცია არ გაგრძელდება.

ავთენტიფიკაციისთვის შიგნით კომპიუტერული სისტემებიტრადიციულად, გამოიყენება მომხმარებლის სახელისა და გარკვეული საიდუმლო ფრაზის (პაროლის) კომბინაცია, რაც შესაძლებელს ხდის დადგინდეს, რომ მომხმარებელი არის ზუსტად ის, ვინც მას ამტკიცებს. ასევე არსებობს ავთენტიფიკაციის სხვა მეთოდებიც, მაგალითად, სმარტ ბარათის გამოყენებით, მაგრამ მათ ამ სტატიაში არ შევეხებით.

ლოკალური ავთენტიფიკაცია

პირველ რიგში, დავიწყოთ ლოკალური ავთენტიფიკაციით, სადაც მომხმარებელს სურს პირდაპირ შევიდეს სამუშაო სადგურში, რომელიც არ არის დომენის ნაწილი. რა ხდება მას შემდეგ, რაც მომხმარებელმა შეიყვანს თავისი მომხმარებლის სახელი და პაროლი? ამის შემდეგ დაუყოვნებლივ, შეყვანილი მონაცემები გადაეცემა ადგილობრივ უსაფრთხოების ქვესისტემას (LSA), რომელიც დაუყოვნებლივ გარდაქმნის პაროლს ჰეშირებად არის ცალმხრივი კრიპტოგრაფიული ტრანსფორმაცია, რომელიც შეუძლებელს ხდის ორიგინალური თანმიმდევრობის აღდგენას. მკაფიო ტექსტში პაროლი არ ინახება და არ არის ნაჩვენები სისტემაში.

შემდეგ LSA სერვისი დაუკავშირდება უსაფრთხოების ანგარიშების მენეჯერს (SAM) და აძლევს მას მომხმარებლის სახელს. დისპეტჩერი წვდება SAM მონაცემთა ბაზას და იქიდან იღებს პაროლის ჰეშს მითითებული მომხმარებელი, წარმოქმნილი შექმნისას ანგარიში(ან პაროლის შეცვლის პროცესში).

შემდეგ LSA ადარებს შეყვანილი პაროლის ჰეშს და SAM მონაცემთა ბაზიდან ჰეშს, თუ ისინი ემთხვევა, ავტორიზაცია ჩაითვლება წარმატებულად და შეყვანილი პაროლის ჰეში მოთავსებულია LSA სერვისის საცავში და რჩება იქ დასრულებამდე. მომხმარებლის სესია.

თუ მომხმარებელი შედის დომენში, ავტორიზაციისთვის გამოიყენება სხვა მექანიზმები, უპირველეს ყოვლისა Kerberos პროტოკოლი, თუმცა, თუ რომელიმე მხარე ვერ გამოიყენებს მას, NTLM და თუნდაც მემკვიდრეობითი LM პროტოკოლები შეიძლება გამოყენებულ იქნას შეთანხმებით. ამ პროტოკოლების მოქმედებას განვიხილავთ ქვემოთ.

LAN მენეჯერი (LM)

LAN მენეჯერის პროტოკოლი გაჩნდა ლოკალური ქსელების გარიჟრაჟზე. Windows კონტროლიდა პირველად დაინერგა Windows 3.11 სამუშაო ჯგუფებისთვის, საიდანაც ოჯახში გადავიდა Windows 9.x. ჩვენ არ განვიხილავთ ამ პროტოკოლს, რადგან ის დიდი ხანია არ არის ნაპოვნი ბუნებრივ გარემოში, მაგრამ მისი მხარდაჭერა, თავსებადობის მიზნებისთვის, ჯერ კიდევ არსებობს. და თუ თანამედროვე სისტემათუ მიღებულია მოთხოვნა ავთენტიფიკაციის შესახებ LM პროტოკოლის გამოყენებით, მაშინ, თუ თქვენ გაქვთ შესაბამისი ნებართვები, ის დამუშავდება.

რა არის ამაში ცუდი? შევეცადოთ გავერკვეთ. უპირველეს ყოვლისა, მოდით გაერკვნენ, თუ როგორ იქმნება პაროლის ჰეში LM პროტოკოლთან მუშაობისთვის, დეტალების გარეშე, მოდით გავამახვილოთ თქვენი ყურადღება მთავარ შეზღუდვებზე:

• პაროლი არ არის რეგისტრირებული და გარდაიქმნება დიდზე.
• პაროლის სიგრძე 14 სიმბოლოა;
• პაროლი იყოფა ნახევრად და იქმნება ჰეში თითოეული ნაწილისთვის DES ალგორითმის გამოყენებით.

უსაფრთხოების თანამედროვე მოთხოვნილებებიდან გამომდინარე, შეგვიძლია ვთქვათ, რომ LM ჰეში პრაქტიკულად დაუცველია და, ჩაჭრის შემთხვევაში, ძალიან სწრაფად იშიფრება. მოდით, დაუყოვნებლივ გავაკეთოთ დაჯავშნა, რომ ჰეშის პირდაპირი აღდგენა შეუძლებელია, თუმცა, დაშიფვრის ალგორითმის სიმარტივის გამო, შესაძლებელია პაროლის შესაბამისი კომბინაციის არჩევა უკიდურესად მოკლე დროში.

ახლა კი ყველაზე საინტერესო, LM ჰეში, თავსებადობის მიზნებისთვის, იქმნება პაროლის შეყვანისას და ინახება სისტემებში Windows XP-მდე და მათ შორის. ეს შესაძლებელს ხდის შეტევას, როდესაც სისტემას მიზანმიმართულად ეგზავნება LM მოთხოვნა და ის ამუშავებს მას. თქვენ შეგიძლიათ თავიდან აიცილოთ LM ჰეშის შექმნა თქვენი უსაფრთხოების პოლიტიკის შეცვლით ან 14 სიმბოლოზე მეტი პაროლების გამოყენებით. Windows Vista-დან და Server 2008-ით დაწყებულ სისტემებზე, LM ჰეში ნაგულისხმევად არ იქმნება.

NT LAN მენეჯერი (NTLM)

ახალი ავთენტიფიკაციის პროტოკოლი გამოჩნდა Windows NT-ში და, გარკვეული ცვლილებებით, დღემდე შემორჩა. და Windows 2000-ში Kerberos-ის გამოჩენამდე, ეს იყო ერთადერთი ავტორიზაციის პროტოკოლი NT დომენში.

დღეს NTLM პროტოკოლი, უფრო სწორად მისი უფრო თანამედროვე ვერსია NTLMv2 გამოიყენება Active Directory დომენურ ქსელებში სამუშაო ჯგუფის კომპიუტერების ავთენტიფიკაციისთვის, Kerberos გამოიყენება ნაგულისხმევად, მაგრამ თუ რომელიმე მხარე ვერ გამოიყენებს ამ პროტოკოლს, მაშინ შეთანხმებით NTLMv2, NTLM; და კიდევ ლ.მ.

NTLM-ის ოპერაციულ პრინციპს ბევრი რამ აქვს საერთო LM-თან და ეს პროტოკოლები თავსებადია უკან, მაგრამ ასევე არის მნიშვნელოვანი განსხვავებები. NT ჰეში იქმნება 128 სიმბოლომდე სიგრძის პაროლის საფუძველზე MD4 ალგორითმის გამოყენებით, პაროლი მგრძნობიარეა და შეიძლება შეიცავდეს არა მხოლოდ ACSII სიმბოლოებს, არამედ უნიკოდს, რაც მნიშვნელოვნად ზრდის მის სიძლიერეს LM-თან შედარებით.

როგორ მუშაობს NTLM პროტოკოლი? განვიხილოთ შემდეგი დიაგრამა:

ვთქვათ ლოკალური კომპიუტერისურს წვდომა სხვა კომპიუტერზე ფაილურ რესურსზე, რომელსაც ჩვენ განვიხილავთ სერვერად და სულაც არ არის აუცილებელი, რომ ამ კომპიუტერს ჰქონდეს ჩრდილოეთ OS ან სერვერის როლები. NTLM პროტოკოლის თვალსაზრისით, კლიენტი არის ის, ვინც წვდება, სერვერი არის ის, ვინც მიმართულია.

რესურსზე წვდომის მისაღებად კლიენტი უგზავნის მოთხოვნას სერვერს მომხმარებლის სახელით. საპასუხოდ, სერვერი აგზავნის მას შემთხვევითი რიცხვი, დაურეკა სერვერის მოთხოვნა. კლიენტი თავის მხრივ შიფრავს ამ თხოვნას DES ალგორითმის მიხედვით, პაროლის NT ჰეშის გამოყენება გასაღებად, თუმცა, მიუხედავად იმისა, რომ NT ჰეში არის 128-ბიტიანი, იმის გამო ტექნიკური შეზღუდვებიგამოიყენება 40 ან 56 ბიტიანი გასაღები (ჰეში დაყოფილია სამ ნაწილად და თითოეული ნაწილი ცალკე შიფრავს სერვერის მოთხოვნას).

სერვერის მოთხოვნა, რომელიც დაშიფრულია პაროლის ჰეშით, ეწოდება NTLM პასუხიდა უბრუნდება სერვერს, სერვერი იღებს SAM საცავიდან მომხმარებლის პაროლის ჰეშს, რომლის სახელიც მას გადაეცა და ასრულებს მსგავს მოქმედებებს სერვერის მოთხოვნით, შემდეგ კი ადარებს მიღებულ შედეგს NTLM პასუხთან. თუ შედეგები ემთხვევა, მაშინ კლიენტის მომხმარებელი არის ის, ვინც ამბობს, რომ არის და ავთენტიფიკაცია წარმატებულად ითვლება.

დომენის ავთენტიფიკაციის შემთხვევაში, პროცესი გარკვეულწილად განსხვავებულად მიმდინარეობს. ადგილობრივი მომხმარებლებისგან განსხვავებით, რომელთა პაროლის ჰეშები ინახება ადგილობრივ SAM მონაცემთა ბაზაში, დომენის მომხმარებლის პაროლის ჰეშები ინახება დომენის კონტროლერებზე. შესვლისთანავე, LSA უგზავნის მოთხოვნას დომენის ხელმისაწვდომ კონტროლერს მომხმარებლის სახელით და დომენის სახელით და შემდგომი პროცესი ხდება როგორც ზემოთ ნაჩვენები.

მესამე რესურსებზე წვდომის შემთხვევაში, სქემაც ოდნავ იცვლება:

კლიენტისგან მოთხოვნის მიღების შემდეგ, სერვერი ასევე გაუგზავნის მას სერვერის მოთხოვნას, მაგრამ NTLM პასუხის მიღების შემდეგ, ის ვერ შეძლებს გადამოწმების მნიშვნელობის გამოთვლას თავის მხარეს, რადგან მას არ აქვს დომენის მომხმარებლის პაროლის ჰეში. , ასე რომ, ის გადამისამართებს NTLM პასუხს დომენის კონტროლერზე და უგზავნის მას სერვერის საკუთარ მოთხოვნას. ამ მონაცემების მიღების შემდეგ, დომენის კონტროლერი ამოიღებს მითითებული მომხმარებლის ჰეშს და სერვერის მოთხოვნის საფუძველზე ითვლის ვერიფიკაციის კომბინაციას, რომელსაც ადარებს მიღებულ NTLM პასუხს, ეგზავნება შეტყობინება სერვერს ავტორიზაცია წარმატებული იყო.

როგორც ხედავთ, პაროლის ჰეში არავითარ შემთხვევაში არ გადაიცემა ქსელში. შეყვანილი პაროლის ჰეში ინახება LSA სერვისის მიერ მომხმარებლის პაროლის ჰეშები ინახება ან SAM-ის ადგილობრივ მაღაზიებში ან დომენის კონტროლერების მაღაზიებში.

მაგრამ ამის მიუხედავად, NTLM პროტოკოლი დღეს არ შეიძლება ჩაითვალოს უსაფრთხოდ. სუსტი დაშიფვრა შესაძლებელს ხდის პაროლის ჰეშის სწრაფად აღდგენას და თუ გამოყენებული იყო არა მხოლოდ NTLM, არამედ LM პასუხი, მაშინ პაროლის აღდგენა.

მაგრამ ჩასმული ჰეში შეიძლება საკმაოდ საკმარისი იყოს, რადგან NTLM პასუხი გენერირდება მომხმარებლის პაროლის საფუძველზე და კლიენტის ავთენტურობა სერვერის მიერ არანაირად არ არის დამოწმებული, შესაძლებელია ჩასმული მონაცემების გამოყენება ქსელის რესურსებზე არასანქცირებული წვდომისთვის. ორმხრივი ავთენტიფიკაციის არარსებობა ასევე იძლევა ადამიანის შუაგულში შეტევების საშუალებას, სადაც თავდამსხმელი კლიენტს სერვერად ეჩვენება და პირიქით, აყალიბებს ორ არხს და წყვეტს გადაცემულ მონაცემებს.

NTLMv2

გააცნობიერა, რომ NTLM პროტოკოლი არ აკმაყოფილებდა უსაფრთხოების თანამედროვე მოთხოვნებს, Windows 2000-ის გამოშვებით, Microsoft-მა წარმოადგინა NTLMv2 პროტოკოლის მეორე ვერსია, რომელიც მნიშვნელოვნად გაუმჯობესდა კრიპტოგრაფიული სიძლიერის გაუმჯობესებისა და შეტევების საერთო ტიპების წინააღმდეგობის თვალსაზრისით. Windows 7 / Server 2008 R2-დან დაწყებული, NTLM და LM პროტოკოლების გამოყენება ნაგულისხმევად გამორთულია.

მოდით დაუყოვნებლივ განვიხილოთ სქემა დომენის კონტროლერთან, თუ ის არ არის, ურთიერთქმედების სქემა არ იცვლება, მხოლოდ დომენის კონტროლერის მიერ შესრულებული გამოთვლები ხორციელდება პირდაპირ სერვერზე.

როგორც NTLM-ში, როდესაც კლიენტი დაუკავშირდება სერვერს, ის ეუბნება მომხმარებლის სახელს და დომენის სახელს და საპასუხოდ სერვერი უგზავნის მას შემთხვევით ნომერს - სერვერის მოთხოვნა. საპასუხოდ, კლიენტი ასევე აგენერირებს შემთხვევით რიცხვს, რომელსაც, სხვა საკითხებთან ერთად, ემატება დროის ანაბეჭდი, რომელიც ე.წ. მომხმარებლის მოთხოვნა. დროის შტამპის არსებობა საშუალებას გაძლევთ თავიდან აიცილოთ სიტუაცია, როდესაც თავდამსხმელი თავდაპირველად აგროვებს მიღებულ მონაცემებს და შემდეგ იყენებს მას თავდასხმის განსახორციელებლად.

სერვერის მოთხოვნა გაერთიანებულია კლიენტის მოთხოვნასთან და HMAC-MD5 ჰეში გამოითვლება ამ თანმიმდევრობიდან. შემდეგ ამ ჰეშიდან აღებულია კიდევ ერთი HMAC-MD5 ჰეში, გასაღები, რომელშიც არის მომხმარებლის პაროლის NT ჰეში. მიღებულ შედეგს ეწოდება NTLMv2 პასუხი და იგზავნება სერვერზე კლიენტის მოთხოვნასთან ერთად.

ამ ალგორითმის კრიპტოგრაფიული სიძლიერე აქტუალურია და დღეს ცნობილია ამ ჰეშის გატეხვის მხოლოდ ორი შემთხვევა, მათგან ერთი გამოუშვა Symantec-ის მიერ კვლევითი მიზნებისთვის. თამამად შეიძლება ითქვას, რომ ამ დროისთვის არ არსებობს ფართოდ გავრცელებული ინსტრუმენტები NTLMv2-ზე თავდასხმისთვის, განსხვავებით NTLM-ისგან, რომლის გატეხვა შეუძლია ნებისმიერ სკოლის მოსწავლეს, რომელმაც ყურადღებით წაიკითხა ინსტრუქციები.

სერვერი, რომელმაც მიიღო NTLMv2 პასუხი და კლიენტის მოთხოვნა, აერთიანებს ამ უკანასკნელს სერვერის მოთხოვნასთან და ასევე ითვლის HMAC-MD5 ჰეშს, შემდეგ გადასცემს მას პასუხთან ერთად დომენის კონტროლერთან. ის ამოიღებს მომხმარებლის პაროლის შენახულ ჰეშს საცავიდან და ახორციელებს გამოთვლებს სერვერისა და კლიენტის მოთხოვნის HMAC-MD5 ჰეშზე, ადარებს მიღებულ შედეგს მასზე გადაცემულ NTLMv2 პასუხთან. თუ არსებობს დამთხვევა, პასუხი, რომელიც მიუთითებს წარმატებულ ავთენტიფიკაციაზე, უბრუნდება სერვერს.

ამავდროულად, როგორც თქვენ შენიშნეთ, NTLMv2, ისევე როგორც მისი წინამორბედი, არ ახორციელებს ორმხრივ ავთენტიფიკაციას, თუმცა ინტერნეტში არსებული ზოგიერთი მასალა ამაზე მიუთითებს.

უსაფრთხოების პარამეტრები

ახლა, როდესაც თქვენ გაქვთ იდეა, თუ როგორ მუშაობს ავტორიზაციის პროტოკოლები, დროა ვისაუბროთ უსაფრთხოების პარამეტრებზე. NTLMv2 არის სრულიად უსაფრთხო პროტოკოლი, მაგრამ თუ სისტემა არასწორად არის კონფიგურირებული, თავდამსხმელს შეუძლია გაგზავნოს NTLM ან LM მოთხოვნა და მიიღოს შესაბამისი პასუხი, რაც საშუალებას მისცემს წარმატებულ შეტევას.

ავტორიზაციის პროტოკოლის არჩევა არის ადგილობრივი ან ჯგუფის პოლიტიკა. გახსენით პოლიტიკის რედაქტორი და გადადით კომპიუტერის კონფიგურაციაზე - Windows კონფიგურაცია- უსაფრთხოების პოლიტიკა - ადგილობრივი პოლიტიკა- უსაფრთხოების პარამეტრები, ამ განყოფილებაში ვიპოვით პოლიტიკას ქსელის უსაფრთხოება: LAN მენეჯერის ავტორიზაციის დონე.

იმავე განყოფილებაში არის პოლიტიკა ქსელის უსაფრთხოება: არ შეინახოთ LAN მენეჯერის ჰეშები შემდეგ ჯერზე, როდესაც შეცვლით თქვენს პაროლს, რომელიც გამორთავს LM ჰეშის შექმნას, ნაგულისხმევად აქტიურია Vista/Server 2008-ით დაწყებული.

ჩვენს პოლიტიკაში, ჩვენ ვხედავთ ღირებულებების ფართო არჩევანს, აშკარაა, რომ დღეს ჩამონათვალში დაწყებული და ქვემოდან დაწყებული პოლიტიკა შეიძლება უსაფრთხოდ ჩაითვალოს.

იგივე მნიშვნელობები შეიძლება დაწესდეს რეესტრის საშუალებით, რაც მოსახერხებელია დონის ქსელებში სამუშაო ჯგუფი, ამ განყოფილებაში HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lsaთქვენ უნდა შექმნათ პარამეტრი DWORDსახელით LmCompatibilityLevel, რომელსაც შეუძლია მიიღოს მნიშვნელობები 0-დან 5-მდე. მოდით შევხედოთ მათ უფრო დეტალურად:

დაყენების სახელი	კლიენტის კომპიუტერი	დომენის კონტროლერი	Lm თავსებადობის დონე
გაგზავნეთ LM და NTLM პასუხები	კლიენტის კომპიუტერები იყენებენ LM და NTLM ავთენტიფიკაციას და არასოდეს იყენებენ NTLMv2 სესიის უსაფრთხოებას.		0
გაგზავნეთ LM და NTLM - გამოიყენეთ NTLMv2 სესიის უსაფრთხოება	კლიენტის კომპიუტერები იყენებენ LM და NTLM ავთენტიფიკაციას და იყენებენ NTLMv2 სესიის უსაფრთხოებას, თუ სერვერი მხარს უჭერს მას.	დომენის კონტროლერები საშუალებას აძლევს LM, NTLM და NTLMv2 ავთენტიფიკაციას.	1
გაგზავნეთ მხოლოდ NTLM პასუხი	კლიენტის კომპიუტერები იყენებენ NTLMv1 ავთენტიფიკაციას და იყენებენ NTLMv2 სესიის უსაფრთხოებას, თუ სერვერი მხარს უჭერს მას.	დომენის კონტროლერები საშუალებას აძლევს LM, NTLM და NTLMv2 ავთენტიფიკაციას.	2
გაგზავნეთ მხოლოდ NTLMv2 პასუხი		დომენის კონტროლერები საშუალებას აძლევს LM, NTLM და NTLMv2 ავთენტიფიკაციას.	3
გაგზავნეთ მხოლოდ NTLMv2 პასუხი. უარი თქვი LM.	კლიენტის კომპიუტერები იყენებენ NTLMv2 ავთენტიფიკაციას და იყენებენ NTLMv2 სესიის უსაფრთხოებას, თუ სერვერი მხარს უჭერს მას.	დომენის კონტროლერები უარს ამბობენ LM ავთენტიფიკაციის მიღებაზე და მიიღებენ მხოლოდ NTLM და NTLMv2.	4
გაგზავნეთ მხოლოდ NTLMv2 პასუხი. უარი თქვი LM და NTLM.	კლიენტის კომპიუტერები იყენებენ NTLMv2 ავთენტიფიკაციას და იყენებენ NTLMv2 სესიის უსაფრთხოებას, თუ სერვერი მხარს უჭერს მას.	დომენის კონტროლერები უარს ამბობენ LM და NTLM ავთენტიფიკაციის მიღებაზე, და მიიღებს მხოლოდ NTLMv2.	5

ყურადღებიანი მკითხველი, რომელიც სწავლობს ამ ცხრილს, აუცილებლად მიაქცევს ყურადღებას NTLMv2 სესიის უსაფრთხოება. ეს ფუნქცია, ისევე როგორც NTLMv2-ის ყველა ურთიერთქმედება ზოგადად, საკმაოდ ცუდად არის დოკუმენტირებული, ამიტომ ბევრს არასწორად ესმის ამ ფუნქციის მნიშვნელობა. მაგრამ სინამდვილეში ყველაფერი საკმაოდ მარტივია.

მას შემდეგ, რაც კლიენტი გაივლის ავტორიზაციას, იქმნება სესიის გასაღები, რომელიც გამოიყენება შემდგომი ურთიერთქმედების დროს ავთენტურობის დასადასტურებლად. NTLM სესიის გასაღები ეფუძნება მხოლოდ NT ჰეშს და იგივე იქნება მანამ, სანამ კლიენტი არ შეცვლის მომხმარებლის პაროლს. გვეჩვენება, რომ არ არის საჭირო იმის ახსნა, თუ რა საფრთხეს უქმნის ეს უსაფრთხოებას. NTLMv2 სესიის უსაფრთხოება გულისხმობს სესიის გასაღების გამოთვლას არა მხოლოდ NT ჰეშის, არამედ სერვერისა და კლიენტის მოთხოვნის გამოყენებით, რაც გასაღებს უნიკალურს და ბევრად უფრო მდგრადს ხდის შესაძლო შეტევების მიმართ. უფრო მეტიც, ეს ფუნქცია შეიძლება გამოყენებულ იქნას NTLM ან LM ავთენტიფიკაციასთან ერთად.

ვიმედოვნებთ, რომ ეს მასალა დაგეხმარებათ უკეთ გაიგოთ ავტორიზაციის პროცესები ვინდოუსის სისტემები. ამ სტატიაში დეტალურად განვიხილავთ Kerberos პროტოკოლის დიზაინსა და ფუნქციონირებას.

მე წარმატებით დავაყენე ntlm ავთენტიფიკაცია. სამწუხაროდ, კონფიგურაცია იძლევა ნახევრად პირველადი ავტორიზაციის საშუალებას. მაგალითად, როდესაც მე ვიყენებ კუს svn1.8.4 (lib პრივილეგირებული წვდომით), chrome ან IE ვებ ბრაუზერებს, ისინი წარმატებით ასრულებენ NTLM-ს, არაფრის მოთხოვნის გარეშე. ჟურნალის ფაილში მე ვხედავ ავტორიზებულ მომხმარებლებს. სამწუხაროდ, როდესაც ვიყენებ მაგალითად არაკონფიგურირებულ FireFox-ს ან Maxthon-ს, ეს ბრაუზერი მთხოვს რწმუნებათა სიგელებს. მე ეს არ მჭირდება, რადგან იგივე სიტუაცია ხდება, როდესაც ვცდილობ წვდომას არაკომპიუტერიდან.

ვიყენებ Windows სერვერიროგორც დომენის კონტროლერი, windows7/8 როგორც სისტემის კლიენტი, linux/debian როგორც ვებ სერვერი. მე მაქვს კონფიგურირებული კერბეროები Linux do Windows AD-დან, winbind ლოკალური NTLM ავთენტიფიკაციისთვის და apache 2.2 სერიიდან. apache წებოს ავთენტიფიკაციისთვის მე ვიყენებ mod_auth_ntlm_winbind.so მოდულს apache2-ში და config/ntlm კონტექსტში winbind-თან კომუნიკაციის მხარდასაჭერად. ეს მუშაობს სწორად, მაგალითად apache-სთვის:

#defaults მთავარი www კატალოგისთვის ოფციები ინდექსები FollowSymLinks MultiViews AllowOverride None #modified, აკრძალულია ნებისმიერი ip წვდომისთვის, მომავალში დაამატეთ ავტორიზებული წვდომა მითითებული ჰოსტებისგან. შეკვეთა უარყოფა, დაშვება უარყოს ყველა #allow from IP/mask #პარამეტრები NTLM auth-ისთვის winbind helper-ით AuthName "NTLM ავთენტიფიკაცია" NTLMAuth NTLMAuthHelper-ზე "/usr/bin/ntlm_auth --domain=MY.WINDOWS.DOMAIN --helper-protocol=squid-2.5-ntlmssp" NTLMBasicNTLMuthbeuser ნაგულისხმევი არის #Authoritative დააკმაყოფილოს ნებისმიერი

ვიმედოვნებდი, რომ შემეძლო რაიმე გადამისამართების გაკეთება apache authtype ცვლადის გამოყენებით და შემდეგ დავამატე ზემოთ ჩაწერის კონფიგურაციაში:

RewriteEngine RewriteRule-ზე ^ /cgi-bin/TestAuth.pl?DollarOne=1&AUTH_TYPE=%(AUTH_TYPE)&REMOTE_USER=%(REMOTE_USER)

და TestAuth.pl სკრიპტის მაგალითი, როგორც cgi შინაარსი:

#!/usr/bin/perl გამოიყენე მკაცრი; გამოიყენეთ გაფრთხილებები; გამოიყენე მონაცემები::დუმპერი; #easy გზა ბეჭდვის სისტემის ცვლადების დასაბეჭდად ბეჭდვა "Content-type:text/plain\r\n"; #respectint HTML პროტოკოლის ბეჭდვა "\r\n"; ბეჭდვა "გარემო შეიცავს:\r\n"; დაბეჭდეთ "x\r\n"; print Data::Dumper->Dump([\@ARGV,\%ENV],); #ბეჭდავს სკრიპტის ყველა არგუმენტს და დამუშავების ცვლადებს

სამწუხაროდ, ყველა შემთხვევაში, Windows-ზე დაფუძნებული auth ntlm გამოყენებით და სერთიფიკატების მოთხოვნით, ყოველთვის ვხედავ, რომ AUTH_TYPE ყოველთვის არის NTLM. მაშინ არ არსებობს გზა იმის გაგება, თუ რას აკეთებს ბრაუზერი. ამ სიტუაციაში მე შემიძლია მივიღო წვდომა კლიენტებისგან დომენიდან.

ვცადე ntlm hepler strace-ის შეფუთვა. სამწუხაროდ, მე ვერ ვხედავ რაიმე მნიშვნელოვანს ჩემს ნაგავსაყრელში ოთხი მეთოდით, რომლებიც აერთიანებს წარმატებას/მარცხს და IE წვდომას, რომელიც გამოწვეულია ant FF მოთხოვნით. მე ვფიქრობ, რომ იგივე სიტუაცია ხდება, როდესაც ntlm დამხმარე ავთენტიფიკაციას ახდენს ადგილობრივ სამბას სერვერზე, მაგრამ მე არასოდეს გამომიცდია ეს.

ახლა მე ვცდილობ გავაკეთო კონფიგურაცია მრავალი auth ტიპის, Basic და NTLM. ჯერ ვცდილობ გავაკეთო Basic და გავფილტრო, როცა ყოველთვის ვერ ხერხდება და გადამისამართება ინფორმაციის გვერდზე. სამწუხაროდ, ამჟამად წარუმატებლობა არ არის NTLM მიქსით: (NTLM ყოველთვის პირველ რიგში კეთდება.

მერე ვინმეს აქვს იდეა როგორ ავიცილოთ თავიდან სერთიფიკატები? როგორ გავაუქმოთ წვდომა მოწვეულ კლიენტებს? როგორ ამოვიცნოთ რწმუნებათა სიგელები სწრაფი ან api კლიენტის ფანჯრიდან?

0

2 პასუხი

მე ამჟამად გადავწყვიტე ეს პრობლემა NTLM-ის კერბეროს ავთენტიფიკაციაზე გადართვით. Winbind-ის ყველა მზა მოწყობილობა მუშაობს პირდაპირ kerberos-ის ქვეშ, რადგან მე ადრე დავაყენე kerberos winbind-ისთვის AD სერვერის კომუნიკაციისთვის. ვინაიდან kerberos ღიაა, დეველოპერებმა იწინასწარმეტყველეს სხვადასხვა ქვე-ავტენტიფიკატორი მომხმარებლის ბოლო წერტილზე. ძალიან სასარგებლო დროშა apache2.2 kerberos მოდულში არის:

KrbMethodმოლაპარაკება KrbMethodK5Passwd-ზე გამორთულია

ეს არის ის, რაც მე მინდა. ბრაუზერი იღებს krb ფრეიმს ატრიბუტით „ნუ გააფუჭებ მომხმარებლის რწმუნებათა სიგელებს“, შემდეგ კლიენტი ამას უბრალოდ არ აკეთებს. მაგრამ თუ ასეა (ერთგვარი შეუთავსებლობა?), Apache სერვერის მოდულმა უნდა აღმოაჩინოს ეს და უნდა გააუქმოს ავთენტიფიკაცია.

Microsoft-ის NTLM-ის გამოყენებით ეს შეუძლებელია, რადგან პროტოკოლი გატეხილია. პირველ NTLM ჩარჩოს მას შემდეგ, რაც ვებსაიტი დააბრუნებს 201 კოდს, არ აქვს ატრიბუტის „ნუ მოითხოვთ მომხმარებელს რწმუნებათა სიგელების“ დამატებას. ამის შემდეგ შემიძლია გავფილტრო ეს ჩარჩო OS სესიის ღილაკის ამომხტარი ან ხელმოწერის შემდეგ. ეს ბრაუზერი ყოველთვის აჩვენებს ამომხტარ ფანჯარას, როდესაც OS სესიის გასაღები მიუწვდომელია.

ყოველივე ამის შემდეგ, ეს კიდევ ერთი შანსია. მომხმარებელს გარკვეული დრო სჭირდება რწმუნებათა სიგელების შეყვანისთვის ან ეთანხმება, როდესაც რწმუნებათა სიგელები ინახება ბრაუზერში. მე შემიძლია დავთვალო დრო ბრაუზერში ავტორიზაციის ფრეიმის გაგზავნასა და კლიენტისგან ფრეიმის შედგენას შორის. როდესაც დრო ძალიან დიდია, შემიძლია გავაუქმო. სამწუხაროდ, ამან შეიძლება გამოიწვიოს ყალბი არაავტორიზაცია დატვირთულ კომპიუტერებზე ან ქსელებზე.

სამომავლოდ ორივე მეთოდს გამოვიყენებ :) სახალისო იქნება, თუ ყველაფერი შეიძლება გაკეთდეს apach winbind auth მოდულის გამოყენებით. შემდეგ მთელი კონფიგურაცია შეიძლება ჩაიწეროს აპაჩის ქვეშ, ისევე როგორც kerberos auth.

მადლობა ყველას საინტერესო კვლევისა და დახმარებისთვის :)

NTLM ავთენტიფიკაციის გამოყენება არ იძლევა გარანტიას ავტორიზაციის გარეშე. თუ თქვენ გაქვთ მოქმედი რწმუნებათა სიგელები Windows მონაცემებირომ სერვერმა ამოიცნოს, თქვენ არ მიიღებთ პაროლის მოთხოვნას.

თუ მომხმარებელს არ აქვს დაკარგული NTLM სერთიფიკატები, მათ მოგეთხოვებათ მიაწოდოს ისინი. ეს არ არის "ძირითადი" ავთენტიფიკაციისთვის დაბრუნების გზა.

სამწუხაროდ, შეუძლებელია იმის დადგენა, მომხმარებელმა მიაწოდა რწმუნებათა სიგელები თუ გავიდა სისტემაში.

ალბათ იკითხეთ ახალი კითხვაიმის შესახებ, თუ რა გსურთ თქვენს მომხმარებლებს განიცადონ (ანუ სხვადასხვა საიტები შიდა და გარე მომხმარებლებისთვის) და ვინმეს შეუძლია სხვაგვარად დაგეხმაროთ.