Отстраняване на неизправности при удостоверяване на Active Directory / влизане в AD ...

„Помощ! Потребителите ми не могат да влязат в потребителския уеб интерфейс на PaperCut, клиента или Mobility Print, като използват своите идентификационни данни за домейн на Active Directory, но вътрешните потребителски акаунти могат да влизат добре. Какво става?"

Забележка: за по-общи ЧЗВ относно PaperCut и Active Directory, преминете към Active Directory Considerations KB.

Това може да е проблем, ако сте свързали вашия сървър за приложения PaperCut, за да използвате Active Directory като източник на потребителска директория (вижте Как да синхронизирате потребители и групи с подробности за Active Directory)…. и по някаква причина App Server вече не може да „говори“ с вашата Active Directory (AD).

Всички вътрешни потребителски акаунти, които използвате, няма да бъдат засегнати, тъй като удостоверяването (и паролата) се управляват изцяло от PaperCut. По същата причина вграденият „администраторски“ акаунт също няма да бъде повлиян от никакви проблеми с AD комуникацията.

Проверете очевидните неща

Включен ли е numlock или caps lock? (Трябва да попитаме). Потвърдете, че проблемът засяга само акаунти, синхронизирани с домейн. Вижте дали някой може да се удостовери с вътрешен потребителски акаунт, като вградения администратор (чрез влизане в потребителския уеб интерфейс или отпечатване чрез Mobility). Ако е така, тогава проблемът може да засяга само акаунти в Windows Active Directory. Уверете се, че паролата за акаунта, с който тествате, е абсолютно правилна. Какво се случва, когато нулирате паролата на потребителя в Active Directory и след това я копирате/поставите в страницата за вход в потребителския уеб интерфейс?

Допълнително отстраняване на неизправности

Уверете се, че услугата Netlogon работи на сървъра PaperCut< /h3>

Поне един клиент ни уведоми, че потребителите на домейн са спрели да могат да се удостоверяват, след като са надстроили своя Windows сървър за печат от 2012 г. до 2016 г. Те успяха да разрешат проблема, като следваха стъпките в тази статия на Microsoft относно услуга netlogon (вижте раздела „Разрешение“, който подчертава как да промените типа стартиране на услугата Netlogon на Автоматично и се уверете, че след това услугата е стартирана).

След това статията препоръчва рестартиране на сървъра, въпреки че не е строго задължително.

Проверете регистрационните файлове за сигурност на Windows

Проверете дали Windows изобщо обработва заявките за удостоверяване. Отворете редактора на локални групови правила: натиснете „Старт“, въведете „gpedit.msc“ и след това изберете получения запис.

Отидете на Правила за локален компютър > Компютърна конфигурация > Настройки на Windows > Настройки за сигурност > Местни правила > Политика за одит. В десния панел щракнете двукратно върху „Одит на събития при влизане“, след това проверете Успех и Неуспех, след което натиснете OK.

За да видите тези събития, отидете на Event Viewer и след това на Windows Logs > Сигурност. Успешният опит за влизане в услугите на PaperCut трябва да има четири събития в дневника:

Ако опитите за удостоверяване не влязат в регистрационния файл за защита, вашата клиентска система вероятно е насочена към грешния домейн контролер.

Проверете настройките на IP протокола на сървъра за приложения:

Изпълнете ipconfig /all на сървъра за приложения, за да определите дали е насочен към DNS IP адреса на организацията. Ако DNS IP адресът на домейна липсва, тогава ще имате лошо време за установяване на връзки към домейн контролера, което ще повлияе на способността ви да удостоверявате потребителите чрез сървъра за приложения.

Опитайте да стартирате „nltest“

Изпълнете C:\Windows> nltest /sc_query:DOMAINNAME.COM

Успешната защитена канална връзка с домейн контролера трябва да изглежда така:

Ако нямате никакви резултати за защитения канал, започнете отстраняването на неизправности с основите:

свързан ли е моят NIC? Имам ли валиден IP? Мога ли да пингвам нещо извън App Server? Имам ли конфигурирани IP адреси на DNS сървър? DNS сървърите отговарят ли? (тествайте с: nslookup -type=soa test.com, замествайки test.com с dns името на вашия домейн в Active Directory, което вероятно е това, което е посочено в реда за първичен Dns суфикс на ipconfig /all)

Поправете връзката ако е необходимо

Можете да поправите връзката на домейна на App Server без рестартиране: използвайте командата PowerShell Test-ComputerSecureChannel с опциите –credential –Repair. Разгледайте документацията на Test-ComputerSecureChannel от Microsoft.

Изпълнете командата, излезте и след това влезте отново с идентификационните данни на домейна.

Например, за да поправите връзката с домейна test.paper.com, подайте командата:@@Test-ComputerSecureChannel –credential test.paper.com\Administrator –Repair

Имайте предвид, че само Powershell 3.0 и по-нови версии имат опцията -credential за Test-ComputerSecureChannel.

Ако всичко останало се провали…

Опитайте да присъедините отново App Server към домейна. Това е по-болезнен вариант, но когато изглежда, че нещата просто не работят правилно, понякога може да спаси положението.

Как работи удостоверяването на потребителя на PaperCut с източника за синхронизиране на Windows Active Directory

Удостоверяването на потребителя на приложението зависи от протокола Microsoft NTLM, известен също като Windows Challenge/Response. Работният процес за удостоверяване по-долу е адаптиран от статията в БЗ Microsoft NTLM.

NTLM използва криптиран протокол за предизвикателство/отговор за удостоверяване на потребител, без да изпраща паролата на потребителя по кабела. Вместо това сървърът на приложения, искащ удостоверяване, трябва да извърши изчисление, което доказва, че има достъп до защитените NTLM идентификационни данни.

Интерактивното NTLM удостоверяване с PaperCut включва три системи: потребителска клиентска система (вградено устройство, клиент за мобилност, софтуерен клиент PaperCut, потребителски уеб страници), App Server, към който потребителят иска удостоверяване, и домейн контролер, където информация свързани с паролата на потребителя се запазват. Работният процес за удостоверяване на PaperCut е известен иначе като неинтерактивно удостоверяване.

Първата стъпка предоставя NTLM идентификационните данни на потребителя

Потребителят осъществява достъп до клиентска система (както е описано по-горе) и предоставя потребителско име и парола. Клиентската система изпраща потребителското име към App Server в обикновен текст. Имайте предвид обаче, че клиентските системи на PaperCut автоматично надстройват своите връзки за удостоверяване към сървъра на приложения от HTTP на HTTPS, така че паролите няма да преминат през мрежата нешифровани с едно изключение: опити за удостоверяване през потребителски или администраторски уеб страници, използващи HTTP:// URL адрес вместо HTTPS://. Във всеки случай App Server изчислява криптографски хеш на паролата и отхвърля действителната парола. Домейн контролерът генерира 16-байтово произволно число, наречено предизвикателство или nonce, и го изпраща на App Server. App Server криптира това предизвиква с хеша на паролата на потребителя и връща резултата на контролера на домейна. Това се нарича отговор. Сървърът на приложения изпраща следните три елемента до домейн контролера: Потребителско име, предизвикателство и отговор. Домейн контролерът използва потребителското име, за да извлече хеша на паролата на потребителя от базата данни на Security Account Manager. Той използва този хеш на паролата, за да шифрова предизвикателството. Домейн контролерът сравнява изчисленото от него шифровано предизвикателство (в стъпка 5) с отговора, изчислен от App Server (в стъпка 3). Ако са идентични, удостоверяването е успешно.

Имате още въпроси?

Уведомете ни! Обичаме да си говорим какво се случва под капака. Чувствайте се свободни да оставите коментар по-долу или посетете нашия портал за поддръжка за допълнителна помощ.

Категории: Статии за отстраняване на проблеми, Удостоверяване

Ключови думи: грешка при влизане, грешка при удостоверяване, влизане, реклама, реклама, активна директория