Детальная проверка kerberos от начала логирования
Давайте еще в картинках я расскажу более детально как происходит проверка подлинности kerberos, от момента ввода пароля пользователем. И так:
Распространенный симптом при сбое Kerberos
Вы пытаетесь получить доступ к веб-сайту, на котором Windows была настроена интегрированная проверка подлинности, и вы ожидаете использовать протокол проверки подлинности Kerberos. В этой ситуации браузер немедленно запросит учетные данные:
На сервере Microsoft IIS (IIS) журналы веб-сайтов содержат запросы, которые заканчиваются кодом состояния 401.2, например следующим журналом:
Или на экране отображается код состояния 401.1, например следующий журнал:
Симптомы
Рассмотрим следующий сценарий:
Имеются два компьютера под управлением Windows Server 2008 или Windows Vista. Один компьютер отправляет сообщение проверки подлинности Kerberos на другой компьютер.
Проверка подлинности Kerberos использует алгоритм улучшенный стандарт шифрования (AES) для шифрования и расшифровки данных проверки подлинности.
В этом случае сбой проверки подлинности Kerberos с кодом ошибки 0X80090302 или 0x8009030f, и появляется сообщение об ошибке. Однако, вы получаете сообщение об ошибке могут различаться для разных приложений. Например при попытке подключиться к SQL Server 2005 или SQL Server 2008 Analysis Services с помощью Excel появляется одно из следующих сообщений об ошибке:
Указанная функция не поддерживается
Сообщение или подпись, предоставленные для проверки, были изменены
Измените подход – WorkFlow, заменяете на Invoke-Command, выполняющиеся на стороне клиента:
какие то ошибки, разобрать не могу по каждому компу так, как понял данные считывает какие пк какие расширения и все, скрипт завершается, ошибок нет, кроме тех компов к которым не смог подключиться,
Кликните здесь для просмотра всего текста
019/04/17 13:18:04 Ћ˜€ЃЉЂ 5 (0x00000005) ‘®§¤**ЁҐ Ї*ЇЄЁ **§**зҐ*Ёп t2000bk17.04.2019-(02-18-02)TCM014
ЋвЄ*§**® ў ¤®бвгЇҐ.
——————————————————————————-
ROBOCOPY :: Robust File Copy for Windows
——————————————————————————-
€бв®з*ЁЄ = E:
Ќ*§**зҐ*ЁҐ – t2000bk17.04.2019-(02-18-02)TCM014
€бЄ«озҐ**лҐ Ї*ЇЄЁ: AppData
Џ*а*¬Ґвал: /S /DCOPY
AT /XJD /XA:SH /R:0 /W:0
2019/04/17 13:18:04 Ћ˜€ЃЉЂ 5 (0x00000005) ‘®§¤**ЁҐ Ї*ЇЄЁ **§**зҐ*Ёп t2000bk17.04.2019-(02-18-02)TCM014
ЋвЄ*§**® ў ¤®бвгЇҐ.
€бв®з*ЁЄ – F:
Ќ*§**зҐ*ЁҐ – t2000bk17.04.2019-(02-18-02)TCM014
Recently I was having troubles Remoting to servers in another forest. The thing worked on certain computers but not on others. No mather what I did I was constantly getting error:
This is what I have tried..
I found article which instructed me to clear DNS and Kerberos tickets cache. Unfortunately it did not solve my problem. Here is a link to article.
Then I started capturing and analysing traffic. Here is what I have got..
DNS Query looked like this:
Standard query SRV _kerberos._tcp.Site-N._sites.dc._msdcs.northwindtraders.contoso.com
No such Name
Standard query SRV _kerberos._tcp.Site-N._sites.dc._msdcs.northwindtraders.northwindtraders.com
No such Name
Standard query SRV _kerberos._tcp.dc._msdcs.northwindtraders.com.contoso.com
No such Name
Standard query SRV _kerberos._tcp.dc._msdcs.northwindtraders.northwindtraders.com
No such Name
Obviously this will not work. But how to persuade client to ask DNS differently. You can say pleassse, but this will not help.. OR:
The DNS Query looked like this:
Standard query SRV _kerberos._tcp.Site-N._sites.dc._msdcs.northwindtraders.com
No such Name
Standard query SRV _kerberos._tcp.dc._msdcs.northwindtraders.com
Standard query response SRV 0 100 88 NW-DC02.northwindtraders.com SRV NW-DC01.northwindtraders.com
Standard query A NW-DC02.northwindtraders.com
Standard query response A 10.20.1.11
Standard query A NW-Remote01.contoso.com
No such name
Standard query 0xba0c A NW-Remote01.northwindtraders.com
Standard query response A 10.20.1.21
If you are having problems with PS Remote:
1.) Check if remoting is enabled
test-wsman -computername server01 -authentication default
2.) Check Firewall
3.) Check Trusted hosts
Get-Item wsman:localhostclienttrustedhosts
4.) Use UPN name instead of Down-Level Logon Name
5.) Clear caches on both servers:
To clear DNS name cache you type in: IPConfig /FlushDNS
To clear NetBIOS name cache you type in: NBTStat –R
To clear Kerberos tickets will need KList.exe: KList purge
Hope this helps You
Jure
У меня есть 2 системы (SR01 и SR02) с учетной записью локальных администраторов. Обе системы находятся в одном домене. Учетные записи локального администратора одинаковы с другим паролем. Эти машины принадлежат виртуальным машинам.
Когда я запускаю enter-pssession от SR01 до SR02, он выдает следующую ошибку.
$ cred = Get-Credential
Enter-PSSession -ComputerName “SR02” -Credential $ cred
Устранение сбоев Kerberos в Internet Explorer
Эта статья помогает изолировать и устранить причины различных ошибок при доступе к веб-сайтам, настроенным для использования проверки подлинности Kerberos в Internet Explorer. Количество потенциальных проблем почти такое же большое, как и количество доступных средств для их решения.
Клавиши функций Internet Explorer
Эти клавиши являются ключами реестра, которые включат или выключают некоторые функции браузера. Ключи расположены в следующих расположениях реестра:
Клавиши функций должны создаваться в одном из этих местоположений в зависимости от того, хотите ли вы включить или отключить эту функцию:
Проверка сбоя проверки подлинности Kerberos
В следующих разделах описываются вещи, которые можно использовать для проверки сбоя проверки подлинности Kerberos.
Клиент и сервер в одном домене
Использование Kerberos требует домена, так как билет Kerberos доставляется контроллером домена (DC). Кроме того, возможны дополнительные сценарии, в которых:
Эти возможные сценарии обсуждаются в разделе Почему не удается делегирования Kerberos между двумя моими лесами, хотя он использовался для работы в разделе этой статьи.
Настроен ли IIS для использования интегрированной проверки подлинности
Включена ли интегрированная проверка подлинности в Internet Explorer
Используется ли URL-адрес, используемый для разрешения в зону безопасности, для которой можно отправить учетные данные
Всегда запустите эту проверку для следующих сайтов:
Вы можете проверить, в какой зоне браузер решает включить сайт. Для этого откройте меню File internet Explorer и выберите Свойства. В окне Properties будет отображаться зона, в которой браузер решил включить веб-сайт, на который вы просматриваете.
Вы можете проверить, позволяет ли зона, в которую включен сайт, автоматический логотип. Для этого откройте меню internet options internet Explorer и выберите вкладку Security. После выбора нужной зоны выберите кнопку Настраиваемый уровень для отображения параметров и убедитесь, что выбран автоматический логотип. (Как правило, эта функция включена по умолчанию для зон Интрасети и доверенных сайтов).
Даже при такой конфигурации не часто (так как для клиента требуется доступ к DC), Kerberos можно использовать для URL-адреса в интернет-зоне. В этом случае, если параметры по умолчанию не будут изменены, браузер всегда будет подсказок пользователю для учетных данных. Делегация Kerberos не будет работать в зоне Интернета. Это потому, что Internet Explorer позволяет делегирования Kerberos только для URL-адресов в зонах Интрасети и Доверенные сайты.
Настроен ли сервер IIS для отправки www-authenticate
Если IIS не отправляет этот заголовок, используйте консоль IIS Manager для настройки заголовка Negotiate через свойство конфигурации NTAuthenticationProviders. Дополнительные сведения см. в Windows поставщиков проверки подлинности.
Доступ к консоли можно получить с помощью параметра Providers Windows проверки подлинности в диспетчере IIS.
По умолчанию свойство NTAuthenticationProviders не установлено. Это приводит к отправке iiS как заглавных Windows NT, так и lan-менеджеров (NTLM).
Установлен ли клиент и сервер на одном компьютере
По умолчанию Kerberos не включен в этой конфигурации. Чтобы изменить это поведение, необходимо установить ключ DisableLoopBackCheck реестра. Дополнительные сведения см. в 926642.
Может ли клиент получить билет Kerberos
KLIST является родным Windows с Windows Server 2008 для серверных операционных систем и Windows 7 Пакет обновления 1 для клиентских операционных систем.
При сбое запроса на билет Kerberos проверка подлинности Kerberos не используется. Может произойти откат NTLM, так как запрашиваемая SPN неизвестна dc. Если dc недостижим, не происходит откат NTLM.
Чтобы объявить SPN, см. следующую статью:
Использование spNs при настройкевеб-приложений, которые находятся на службы IIS.
Использует ли веб-сервер порт по умолчанию (80)
По умолчанию Internet Explorer не включает сведения о номере порта в SPN, который используется для запроса билета Kerberos. Это может быть проблемой, если вы используете IIS для пользования несколькими сайтами в разных портах и удостоверениях. В этой конфигурации проверка подлинности Kerberos может работать только для определенных сайтов, даже если все spNs были правильно объявлены в Active Directory. Чтобы устранить эту проблему, необходимо установить FEATURE_INCLUDE_PORT_IN_SPN_KB908209 значение реестра. (Сведения о том, как объявить ключ, см. в разделе Ключи функций Internet Explorer.) Этот параметр заставляет Internet Explorer включить номер порта в SPN, который используется для запроса билета Kerberos.
Использует ли Internet Explorer ожидаемый SPN
Трассировка сетевого монитора — это хороший метод проверки SPN, связанного с билетом Kerberos, как в следующем примере:
Соответствует ли удостоверение пула приложений учетной записи, связанной с SPN
Когда билет Kerberos отправляется из Internet Explorer на сервер IIS, он шифруется с помощью закрытого ключа. Закрытый ключ — это хаш пароля, используемого для учетной записи пользователя, связанной с SPN. Таким образом, расшифровать билет может только приложение, которое работает под этой учетной записью.
Ниже приводится сводка алгоритма проверки подлинности Kerberos:
Internet Explorer определяет SPN с помощью URL-адреса, вступив в адресную планку.
SpN передается через API интерфейса поставщика службы поддержки безопасности (SSPI) (InitializeSecurityContext) в системный компонент, отвечающий за безопасность Windows безопасности (процесс службы подсистем местного органа безопасности (LSASS). На данном этапе можно увидеть, что код Internet Explorer не реализует код для построения билета Kerberos. Internet Explorer вызывает только API SSPI.
LSASS использует СНО, переданный для запроса билета Kerberos в DC. Если dc может обслуживать запрос (известный SPN), он создает билет Kerberos. Затем он шифрует билет с помощью ключа, построенного из хаши пароля учетной записи пользователя для учетной записи, связанной с SPN. Затем LSASS отправляет билет клиенту. Что касается Internet Explorer, то билет является непрозрачной blob.
Internet Explorer инкапсулирует билет Kerberos, предоставленный LSASS в загонке, а затем отправляет его на Authorization: Negotiate сервер IIS.
IIS обрабатывает запрос и передает его в правильный пул приложений с помощью указанного загона хоста.
Пул приложений пытается расшифровать билет с помощью API SSPI/LSASS и следуя следующим условиям:
Если билет можно расшифровать, проверка подлинности Kerberos будет успешной. Доступны все службы, связанные с билетом (вымысление, делегирование, если позволяет билет и так далее).
Если расшифровать билет нельзя, возвращается ошибка Kerberos (KRB_AP_ERR_MODIFIED). Эта ошибка является общей ошибкой, которая указывает, что билет был изменен каким-либо образом во время его транспортировки. Так что расшифровать билет не получается. Эта ошибка также регистрируется в журналах Windows событий.
Если вы явно не объявляете SPN, проверка подлинности Kerberos работает только в соответствии с одним из следующих удостоверений пула приложений:
Но эти удостоверения не рекомендуется, так как они являются угрозой безопасности. В этом случае билет Kerberos создается с помощью spN по умолчанию, созданного в Active Directory при добавлении в домен компьютера (в этом случае запущенного сервера IIS). Этот SPN по умолчанию связан с учетной записью компьютера. В соответствии с IIS учетная запись компьютера сопопосается с сетевой службой или объектом ApplicationPoolIdentity.
Если в пуле приложений необходимо использовать удостоверение, помимо перечисленных удостоверений, объявите SPN (с помощью SETSPN). Затем связать его с учетной записью, используемой для удостоверения пула приложений. Обычной ошибкой является создание аналогичных СНО, которые имеют различные учетные записи. Например,
Начиная с Windows Server 2008, вы также можете использовать обновленную версию SETSPN для Windows, которая позволяет обнаруживать дублирующиеся spNs с помощью команды при объявлении нового SPN для целевой учетной setspn –X записи. Дополнительные сведения см. в setspn.
Кроме того, рекомендуется просмотреть следующие статьи:
Не удается ли проверка подлинности Kerberos в версиях IIS 7 и более поздних версий, даже если она работает в IIS 6
Проверка подлинности режима ядра — это функция, представленная в IIS 7. Он предоставляет следующие преимущества:
Если spN объявлен для определенной учетной записи пользователя (также используемой в качестве удостоверения пула приложений), проверка подлинности режима ядра не может расшифровать билет Kerberos, так как она использует учетную запись машины. Эта проблема типична для сценариев веб-фермы. В этом сценарии обычно объявляется spN для (виртуального) имени хост-имени NLB. Чтобы предотвратить эту проблему, используйте один из следующих методов:
Почему не удается делегирование, хотя проверка подлинности Kerberos работает
В этом сценарии проверьте следующие элементы:
Зона Internet Explorer, используемая для URL-адреса. Делегирования Kerberos разрешено только для зон Интрасети и доверенных сайтов. (Другими словами, Internet Explorer задает флаг при вызове ISC_REQ_DELEGATE InitializeSecurityContext только в том случае, если определяемая зона — это интрасеть или доверенные сайты.)
Учетная запись пользователя пула приложений IIS, на который размещен ваш сайт, должна иметь флажок Доверенный для делегирования в Active Directory.
Почему я получаю плохую производительность при использовании проверки подлинности Kerberos
Kerberos — это протокол проверки подлинности на основе запросов в более старых версиях Windows Server, таких как Windows Server 2008 SP2 и Windows Server 2008 R2. Это означает, что клиент должен отправить билет Kerberos (который может быть довольно большой blob) с каждым запросом, который сделан на сервер. Это противоречит методам проверки подлинности, которые используют NTLM. По умолчанию NTLM основан на сеансах. Это означает, что браузер будет проверить подлинность только одного запроса, когда откроет подключение TCP к серверу. Каждый последующий запрос на одно и то же подключение TCP больше не требует проверки подлинности для того, чтобы запрос был принят. В более новых версиях IIS с Windows R2 начиная с 2012 года Kerberos также основан на сеансах. Только первый запрос на новое подключение TCP должен быть аутентификацией на сервере. Последующие запросы не должны включать билет Kerberos.
Это поведение можно изменить с помощью свойства authPersistNonNTLM, если вы работаете в версиях IIS 7 и более поздних версий. Если свойство настроено на верное, Kerberos станет сеансом на основе. В противном случае он будет основан на запросе. Это будет иметь более плохую производительность, так как каждый раз необходимо включать больший объем данных для отправки на сервер. Дополнительные сведения см. в рублях Запрос на основе сеанса проверки подлинности Kerberos (или параметр AuthPersistNonNTLM).
Почему не удается делегирования Kerberos между двумя лесами, хотя раньше он работал
Рассмотрим следующий сценарий.
В этом сценарии делегирования Kerberos может перестать работать, даже если раньше она работала, и вы не вносили изменений ни в леса, ни в домены. Проверка подлинности Kerberos по-прежнему работает в этом сценарии. Не удается только делегирования.
Эта проблема может возникнуть из-за обновлений Windows Server, выпущенных Корпорацией Майкрософт в марте 2019 г. и июле 2019 г. Эти обновления отключили неподготовленную делегирование Kerberos (возможность делегирования маркера Kerberos из приложения в службу back-end) через границы леса для всех новых и существующих трастов. Дополнительные сведения см. в статью Updates to TGT delegation across incoming trusts in Windows Server.
При использовании проверки подлинности kerberos возникла следующая ошибка с кодом ошибки 0x80090311
Добрый день уважаемые читатели, не так давно у меня на работе была задача по настройке групп доступности SQL на Windows кластере, там клиентам сделали красивый веб-инструментарий, все замечательно, теперь клиент ждет следующего развития ситуации, а именно настройка и внедрение механизма Single Sign-On (SSO) или по русски единая точка аутентификация, мы с вами уже с ней знакомились при настройке Vmware vCenter Server. Данный механизм работает на протоколе шифрования kerberos, о котором мы и поговорим. Мы рассмотрим как происходит проверка подлинности kerberos в Active Directory, так как понимание принципов работы, поможет вам в реализации единой точки аутентификации.
Как безопасно подключаться с контроллера домена к рабочим станциям через Powershell?
Но это никуда не годится с точки зрения безопасности, поэтому пробуем использовать учётку локального администратора рабочей станции:
Чтобы устранить ошибку 0x80090311, добавляем рабочую станцию в список доверенных хостов:
И пытаемся снова, но получаем другую ошибку:
Как решить проблему, коллеги, подскажите?
если в удалённой сессии попытаться прочитать какую-нибудь сетевую папку, то мы получим ошибку.
Это не «проверка в лоб», а обычный «double hop» про который не писал только ленивый
и при определённых условиях это double hop обходится на 2012+.
Григорий Бондаренко, тут вопрос сильно глубже. Ваш первоначальный вопрос о том, «как подключиться к рабочей станции под недоменной учёткой», ответ о том «насколько страшно подключаться к раб. станциям под доменным админом.»
Керберос при работе паролей не использует, только для получения первоначального тикета от DC, причём тикеты там нескольких видов.
Так что на самом деле вас должен волновать вопрос, какие следы остаются на раб. станции после подключения к ней под доменным админом (тикеты kerberos, например, или открытые сессии) и может ли хакер, перехватив их, использовать для дальнейшего проникновения куда-либо. Скорее всего нет, так как по умолчанию тикеты там на соединение хост-хост. Но бывает всякое, о чём и ссылка. Что там в этом случае я не знаю, так что в общем, я бы повторил рекомендацию Mnemonic0, не подключаться никуда с DC. И вообще не заходить туда. Так, на всякий случай. всё администрирование можно вести удалённо
Причина
Функции SpSealMessage и SpUnsealMessage не шифрования и расшифровки сообщения проверки подлинности правильно, когда не делится на размер блока ожидаемый размер сообщения.
Идентификация и доступ в Active Directory
Доменные службы Active Directory (Active Directory Domain Services, AD DS ) обеспечивают идентификацию и доступ (Identity and Access, IDA ) для корпоративных сетей. Давайте посмотрим каким требованиям и критериям должна соответствовать структура IDA:
Протокол аутентификации kerberos
Именно за счет провайдеров Security Support Provider (SSP) сделан механизм аутентификации. Операционная система Windows уже имеет встроенные модули, но никто не мешает программистам, взять и написать свой и подключить его к SSPI
Протокол аутентификации kerberos пришел на смену устаревшему и уже с точки зрения не безопасному, протоколу NTLM, он был основным до Windows 2000. Протокол Kerberos всегда используется в построении механизмов Single Sign-On. В его основе лежит такой принцип, что если двум участникам известен некий ключ и у них есть возможность подтвердить это, то они смогут однозначно идентифицировать друг друга.
Междоменный ключ (inter-realm key). Этот ключ обеспечивает междоменную аутентификацию и используется для обеспечения доверительных отношений в среде Aсtive Directory.
Ticket (билет) является зашифрованным пакетом данных, который выдается доверенным центром аутентификации, в терминах протокола Kerberos — Key Distribution Center (KDC, центр распределения ключей). TGT шифруется при помощи ключа, общего для служб KDC, то есть клиент не может прочитать информацию из своего билета. Этот билет используется клиентом для получения других билетов.
Сам Ticket-Granting Service состоит из двух вещей, первая это копия сессионного ключа и информация о клиенте. Все эти данные зашифрованы ключом, общим между сервисом к которому идет обращение и KDC. Это означает, что пользователь не сможет посмотреть эти данные, а вот служба или сервер к которому идет обращение да.
Еще очень важным моментом, является тот фактор, что служба KDC, должна точно знать к какому именно сервису идет обращение и каким ключом шифрования производить обработку. Для этого есть такой механизм, как Service Principal Names, по сути это уникальный идентификатор службы, который будет прописан в вашей базе Active Directory. Из требований к нему, он должен быть уникален в рамках леса. Каждая служба, которая будет использовать Kerberos, должна иметь зарегистрированный SPN. Без правильно настроенного идентификатора протокол для этой службы или сервера работать не будет.
Сам SPN будет хранится в атрибуте Service-Principal-Name, у той учетной записи к которой он привязан и под которым стартует служба. Таким образом, SPN связывает воедино все части процесса. Клиент знает, к какой службе он хочет получить доступ. И при запросе ключа он строит строку SPN, к примеру, при помощи функции DsMakeSpn. Сервер KDC, получив эти данные, может найти учетную запись, под которой стартует эта служба, и, используя ключ этой учетной записи из Active Directory, создать билет доступа к службе и зашифровать его этим ключом.
Как производится настройка SPN мною уже была описана в одной из статей.
Определите, используется ли Kerberos
При устранении неполадок с проверкой подлинности Kerberos рекомендуется упростить настройку до минимума. То есть один клиент, один сервер и один сайт IIS, работающий в порту по умолчанию. Кроме того, можно выполнять некоторые основные действия по устранению неполадок. Например, используйте тестовую страницу для проверки используемого метода проверки подлинности. Если вы используете ASP.NET, вы можете создать ASP.NET тестовую страницу проверки подлинности.
Если вы используете классический ASP, вы можете использовать следующую страницу Testkerb.asp:
Вы также можете использовать следующие средства, чтобы определить, используется ли Kerberos:
Дополнительные сведения о том, как можно сгенерить такие следы, см. в статью отслеживание на стороне клиента.
Если используется рукопожатие NTLM, запрос будет значительно меньше. В следующем захвате клиента показан запрос на проверку подлинности NTLM. Запрос GET гораздо меньше (менее 1400 bytes).
После определения сбоя проверки подлинности Kerberos проверьте каждый из следующих элементов в заданного порядке.
Решение
Существует исправление от корпорации Майкрософт. Однако данное исправление предназначено для устранения только проблемы, описанной в этой статье. Применяйте это исправление только в тех случаях, когда наблюдается проблема, описанная в данной статье. Это исправление может проходить дополнительное тестирование. Таким образом если вы не подвержены серьезно этой проблеме, рекомендуется дождаться следующего пакета обновления, содержащего это исправление.
Если исправление доступно для скачивания, имеется раздел «Пакет исправлений доступен для скачивания» в верхней части этой статьи базы знаний. Если этот раздел не отображается, обратитесь в службу поддержки для получения исправления.
Примечание. Если наблюдаются другие проблемы или необходимо устранить неполадки, вам может понадобиться создать отдельный запрос на обслуживание. Стандартная оплата за поддержку будет взиматься только за дополнительные вопросы и проблемы, которые не соответствуют требованиям конкретного исправления. Чтобы получить полный список телефонов поддержки и обслуживания клиентов корпорации Майкрософт или создать отдельный запрос на обслуживание, посетите следующий веб-сайт корпорации Майкрософт:
Примечание. В форме «Пакет исправлений доступен для скачивания» отображаются языки, для которых доступно исправление. Если нужный язык не отображается, значит исправление для данного языка отсутствует.
В те же пакеты включены важные исправления для Windows Vista и Windows Server 2008. Однако только один из этих продуктов могут быть указаны на странице «Запрос исправления». Чтобы запросить пакет исправлений, который применяется в Windows Vista и Windows Server 2008, просто выберите продукт, который указан на странице.
Предварительные условия
Данное исправление на компьютере должна быть установлена одна из следующих операционных систем:
Пакет обновления 1 (SP1) для Windows Vista
Пакет обновления 2 (SP2) для Windows Vista
Пакет обновления 2 (SP2) для Windows Server 2008
Необходимость перезагрузки
После установки исправления компьютер необходимо перезагрузить.
Область исправления установки
Исправление должно быть установлено на стороне клиента и стороне сервера для подключения. Если будут затронуты многие клиенты могут смысла распространяют исправление ко всем системам Server 2008 и Windows Vista на предприятии.
Сведения о файлах
Английская версия данного исправления содержит атрибуты файла (или более поздние атрибуты файлов), приведенные в следующей таблице. Дата и время для этих файлов указаны в формате общего скоординированного времени (UTC). При просмотре сведений о файле, он преобразуется в локальное время. Чтобы узнать разницу между временем по Гринвичу и местным временем, откройте вкладку Часовой пояс элемента Дата и время в панели управления.
Для всех поддерживаемых 32-разрядных версий операционной системы Windows Vista и Windows Server 2008