После применения полного набора исправлений на настольном компьютере Win 7.1 Pro и сервере Windows 2012 R2 Datacenter Azure под управлением SQL 2014 SQL Management Studio (версии 2008 и 2014) не будет подключаться к серверу SQL 2014 Azure. Время ожидания клиентского подключения истекает и завершается ошибкой SQL-сервера 5.
Репликация транзакций SQL-сервера продолжает нормально работать между локальным экземпляром SQL 2008 и удаленным экземпляром SQL 2014. Кроме того, SQL Management Studio 2014 на удаленном (Azure) сервере может без проблем подключаться к локальному (локальному) экземпляру SQL 2008, а также к удаленному (Azure) серверу SQL 2014. Разрешение DNS и IP-соединение в обоих направлениях в норме. Я вижу, что удаленный экземпляр SQL 2014 правильно создает свое имя участника-службы при запуске. В SQL 2014 есть предупреждение о том, что некоторые клиенты используют резервную копию NTLM.
У меня нет ни локального экземпляра SQL 2014, ни удаленного экземпляра SQL 2008. Поэтому я не уверен, имеет ли значение то, что сервер удален, в Azure, через VPN, или я буду видеть то же самое. проблема с исправленным локальным клиентом и исправленным локальным SQL-сервером.
Я заметил, что служба браузера SQL на удаленном сервере SQL 2014 остановлена и отключена. Я не уверен, было ли это до патча. Однако я использую один экземпляр на порту по умолчанию, а не на именованном экземпляре, поэтому я ожидаю, что мне не нужна служба браузера SQL?
Сообщается о проблемах аутентификации с этим вторником исправлений, касающихся общих сетевых папок Server 2003. Я не видел отчетов об общих проблемах аутентификации AD или проблемах аутентификации SQL Server. Есть ли у кого-нибудь еще эта проблема или похожая? Есть предложения по поводу того, какой КБ я должен попытаться откатить? Стоит ли запускать анализатор конфигурации Kerberos? Стоит ли запускать отключенную службу браузера SQL?
Любая помощь приветствуется.
Удаление MS15-027 (KB3002657) с сервера и перезагрузка сервера не решают проблему.
Удаление 3046049 КБ на клиенте и перезагрузка клиента не решают проблему. Удаление 3046049 КБ на сервере и перезагрузка сервера не решают проблему, но код ошибки изменился с 5 на 53 (более распространенный код ошибки).
Изменить: это не та же проблема, что и SQL Server Windows Authentication не работает после сегодняшних обновлений безопасности: логин из ненадежного домена хотя у него может быть та же основная причина. (Похоже, что после патча вторника появляется все больше сообщений о различных проблемах, связанных с аутентификацией.) В частности, в моем случае проверка подлинности Windows работает нормально, я могу использовать RDP на исправленных машинах и между исправленными машинами, и вход на основе AD работает нормально.
Изменить: та же проблема влияет на аутентификацию SQL (не AD). Идентичное сообщение об ошибке. Это говорит о том, что это проблема с подключением, а не с аутентификацией.
У нас нет затронутых серверов Windows 2003. Таким образом, проблема, которую мы наблюдаем, не ограничивается Windows Server 2003 (как сообщается для некоторых других подобных проблем с мартовским патчем).
Среда утром 2015-03-11 после мартовских обновлений Windows у нас начались проблемы с подключением программного обеспечения ODBC и Spotlight к нашим экземплярам SQL 2005, 2008. Они использовали учетные данные домена Windows. Аутентификация SQL все еще работала. Ошибка: не удалось войти в систему для пользователя ''. Пользователь не связан с доверенным соединением SQL Server. (Microsoft SQL Server, ошибка: 18452)
Уровень нашего домена - 2003 на нескольких сайтах серверов Windows 2003 SP2. На наших контроллерах домена Windows 2003 мы отказались от всех обновлений, перечисленных в: https://technet.microsoft.com/library/security/ms15-Mar Это восстановило все подключения к нашей базе данных SQL и позволило оператору успешно завершить обработку Nightly System.
Мы отклонили установку через наш WSUS (сервер обновлений Windows) следующих двух обновлений Windows для всех серверов в нашем домене интрасети: MS15-027 (KB3002657) и MS15-031 (KB3046049)
Прочтите ниже статью о проблемах, о которых сообщают эти обновления: http://www.infoworld.com/article/2895022/security/problems-reported-with-microsoft-patch-kb-3002657-and-a-warning-on-kb-3046049.html#tk.rss_security
support.microsoft.com/en-us/kb/3002657 (прочтите раздел "Известные проблемы")
В настоящее время мы не будем устанавливать никаких обновлений на наши текущие контроллеры домена 2003, так как мы отслеживаем дальнейшие проблемы.
MS15-27 KB3002657 Это не ограничивается Windows 2003 или EMC Epislon, как сообщает Microsoft.
Мой опыт был:
Сопоставление диска или использование пути unc от рабочих станций Windows 7 к нескольким файловым серверам Windows 2008 (не контроллерам домена) приведет к ошибке с неверным именем пользователя.
Проблема заключалась в том, что рабочие станции Windows 7 находятся в другом домене Active Directory, чем файловые серверы Windows 2008. Мы добавили статические записи DNS в зону DNS, к которой были подключены рабочие станции Windows 7, которые разрешают IP-адреса серверов Windows 2008. Таким образом, пользователи могут использовать короткое имя компьютера для доступа к общей папке (Краткое имя = \ servername \ Sharename, полное доменное имя, длинное имя = \ servername.serverdomain.com \ sharename). Этот процесс заставляет рабочую станцию прикреплять DNS-суффикс \ servername к рабочей станции. workstationdomain.com \ sharename. Это заставляет патч полагать, что имя компьютера было подделано из-за неправильного fqdn имени сервера.
Чтобы исправить проблему:
1- Удалите записи DNS для серверов из зоны DNS рабочей станции.
2- Разверните на рабочих станциях с помощью групповой политики список поиска суффиксов dns, содержащий как суффикс dns рабочей станции, так и суффикс dns сервера.
Теперь рабочие станции по-прежнему могут использовать короткое имя пути unc, и оно находит правильное имя fqdn после просмотра списка суффиксов поиска DNS.
Вероятно, мы не единственные, кто так поступал.