Грешка 691 във VPN на Windows: коя проверка всъщност се провали?

Windows отхвърля парола, която е приел другаде преди минута, затова акаунтът изглежда счупен, а опитът изобщо не е бил оценяван. Грешка 691 означава, че връзката е отказана по време на удостоверяване, а клиентът показва един и същ текст независимо дали тайната е грешна, дали името на акаунта е преведено към неочаквана самоличност, или сървърна политика е отказала връзката. Три различни поправки споделят едно съобщение, затова нулирането понякога помага, а понякога не променя нищо. Започнете с частта, която можете да прегледате сами: точния низ, който клиентът е изпратил, и хранилището на идентификационни данни, от което го е взел. После попитайте сървъра какво решение е записал, защото диалогът е отказ, а не диагноза.

Три начина да получите отказ, един диалог

Грешната тайна е само първият начин да стигнете до този диалог. Името на акаунта може да се преведе към самоличност, която не сте имали предвид, акаунтът може да няма разрешение за комутируем достъп или сървърно условие може да откаже връзката, след като паролата е приета. Всяко от тези дава същия текст в клиента и всяко има своя поправка.

Затова нулирането изглежда работи в понеделник и не прави нищо във вторник. Четете диалога като отказ, а не като диагноза, и запишете името на профила и местното време на неуспеха, преди да пипате акаунта.

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

Какво всъщност изпрати клиентът

Потвърдете приетия формат на акаунта с този, който управлява шлюза, защото голо потребителско име, име с домейн и основно потребителско име могат да сочат към различни контексти на акаунт. Само едно от тях може да е самоличността с разрешението. Питайте кой формат очаква шлюзът преди първия опит, а не след петия, и проверете дали клиентът използва запазени идентификационни данни вместо тези, които сте въвели.

Две заявки само за четене на машината с Windows показват профила и всякакви кеширани идентификационни данни, които биха могли да надделеят над диалога. Нито една от тях не се обажда на сървъра:

Get-VpnConnection -Name 'Corp VPN' | Format-List Name, ServerAddress, TunnelType, AuthenticationMethod
cmdkey /list | Select-String -Pattern 'corp' -SimpleMatch

Отнасяйте се към паролата като към данни, а не като към текст, копиран от документ. Стойност, преминала през скрипт, може да носи екраниращи знаци, които никога не са били част от тайната, а експорт на конфигурация може да я е оградил в кавички. Премахването на всеки специален знак, за да пасне, е друга промяна, различна от намирането на истинската стойност, затова първо установете истинската стойност.

Вземете решението на политиката, не нулиране

При внедряване за отдалечен достъп със сървър за мрежови политики две решения се изпълняват последователно. Удостоверяването установява кой акаунт пита, а оторизацията решава дали този акаунт може да се свързва изобщо. Условията и ограниченията на политиката се оценяват по собствени правила, затова правилната тайна решава само първата половина на въпроса. Името на политиката в събитието на сървъра показва кое решение всъщност се е изпълнило.

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

Превръщането на акаунт в безусловно разрешение прави решението за оторизация постоянно изключение. То премахва и условието, което вършеше полезна работа, а следващият, който прегледа политиката, няма да знае защо е променена. Вместо това помолете собственика да потвърди желаната политика, за да остане приемането съзнателно.

Опитайте още веднъж, после сравнете

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

Устоявайте на изкушението да изключите семейство адреси или да включите подробно проследяване, преди отказът да е обяснен. Проследяването дава обем, а не решение, и първият полезен резултат остава компонентът, отказал опита, и причината, която е записал. Щом това е известно, повторният опит или потвърждава поправката, или дава нов и по-тесен симптом.