Пять минут, пять минут…


так сколько это все-таки, много или мало?

Посмотрел в черновик — лежит заметка два года уже, я про нее забыл. Надо в черновики ходить чаще, а не размениваться на хайп 🙂 Буду работать над собой, хотя это и не просто.

Заметка была про то, много пять минут это или мало.

Я еще два года назад  (или даже больше) честно, четыре года, оказывается как-то пару раз сталкивался и кому-то на форумах даже разжевывал, но все потонуло. Вроде как ресурс блога ну очень известный, да и автор не кто-то там, а Ned Pyle, вот и думаешь, что все вокруг про это знают. Ан нет.

Спросишь кого встречного — будут кричать, что разница во времени в домене критична, и все взорвется. Вот прям туши свет. Сильная разница действительно критична (вот еще одна заметка на эту тему, о ней как-нибудь в другой раз, раз уж пошла мода выкапывать годноту 5-летней выдержки), это уж точно не секрет Полишинеля. Но поскольку с 2000 года нам постоянно на курсах, лекциях, старшие товарищи на партсобраниях и много где еще повторяют, что нет, нет, нельзя- все и как-то пребывают в уверенности что нельзя. И многие на интервью даже спрашивают друг друга об этом. И тоже думают, что нельзя. Но с сегодняшнего дня даже последнему вовнею должно быть известно, что можно.

Итак, если время в у клиента убежало на 5 минут и более, то сервер ему пришлет метку коррекции в ответе, и ничего страшного не случится!

If the server clock and the client clock are off by more than the policy-determined clock skew limit (usually 5 minutes), the server MUST return a KRB_AP_ERR_SKEW. The optional client’s time in the KRB-ERROR SHOULD be filled out.

Статья-первоисточник, собственно здесь.

Первопричина, ставшая поводом к заметке, здесь.

Увидев эту заметку, прочитайте ее, и перескажите коллегам. Пишите в комментариях, давайте бороться с безграмотностью вместе.

Если вы до этого не знали про эти блоги и интересуетесь темой, настоятельно рекомендую к прочтению- информации просто бездонное море. И актуальности, как видим, она вовсе не теряет.

Реклама

TLS 1.2 Вы готовы?


Старый добрый блог разразился двумя толковыми статьями, которые рекомендую пробежать, чтобы освежить в памяти разное про хэши, алгоритмы и их друзей.

https://blogs.technet.microsoft.com/askpfeplat/2017/11/13/demystifying-schannel/

https://blogs.technet.microsoft.com/askpfeplat/2017/12/26/cipher-suite-breakdown/

Не могу не отметить, что качество информационных статей такого рода чрезвычайно высокое, а самих их крайне мало. Из последнего вспоминается разве что похожая вещь про RDP,

про которую недавно настрочил Илья.

Ну и рядом музыкой навеяло вот это:

To provide best-in-class encryption, and to ensure our service is more secure by default, we are moving all of our online services to Transport Layer Security (TLS) 1.2+. As a result, we will be removing support for TLS versions less than 1.2 from our online services, beginning March 1, 2018.
How does this affect me?
Starting on March 1, 2018, all client-server and browser-server combinations must use TLS 1.2 or later protocol versions to be able to connect without issues to Office 365 services. This may require certain client-server and browser-server combinations to be updated. Although current analysis of connections to Microsoft Online services shows that very few customers still use TLS 1.0 and 1.1, we are providing notice of this change so that you can update any affected clients or servers as necessary before support for TLS 1.0 and 1.1 is disabled. If you are using any on-premises infrastructure for hybrid scenarios or Active Directory Federation Services, make sure that these infrastructures can support both inbound and outbound connections that use TLS 1.2.
What do I need to do to prepare for this change?
We recommend you proactively address weak TLS usage by removing TLS 1.0/1.1 dependencies in your environments and disabling TLS 1.0/1.1 at the operating system level where possible. Begin planning your migration to TLS 1.2+, today.
Вспомнил еще один не имеющих аналогов труд по теме, перекликается с первым ответом из опроса.
Ну и по традиции, мини опрос:

 

Active Directory в Windows Server 2016


Значительным изменениям в Windows Server 2016 подверглась служба времени. Хитрый Майкрософт это изменение коварно скрывал, рассказывая всем про контейнеры, докеры и прочее виртуальное строительсво. Видеоблоггеры не подвели, и тоже замалчивали эту тему, как могли, отвлекая народ нано серверами и всякими S2D.

Но нас не проведёшь, недавно была таки опубликована официальная документация по этому вопросу. Рекомендую всем к ней обратиться, написано хорошо.

На Игнайте коротко по теме рассказывали тут:

Windows Server 2016

Июньские обновления…


OhNoNotYouAgain

такие обновления. Призываю очень внимательно протестировать еще одно свежее обновление безопасности, закручивающее гайки NetBIOS. Могт быть проблемы с чем угодно, где фигурируют короткие имена, поэтому среды, где парни используют FQDN, застрахованы от неожиданностей. Будьте осторожны, тщательно тестируйте обновления перед применением их в производственной среде. Если вы столкнулись с проблемами, то выполняйте рекомендации статьи:

https://support.microsoft.com/en-us/kb/3161949. Добавьте ключ

KEY: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters
Value Name: AllowNBToInternet
Type: Dword
Value: 1

P.S. Пока столкнулись с поведением в одной среде с SAMBA серверами. Использовали ключ реестра + перезагрузка обязательна.

Изменения в обработке GPO, или Patch Tuesday


broken

Все течёт, все меняется. И знания тоже нужно всё время актуализировать.

Интереснейшее обновление, вышедшее во вторник, https://support.microsoft.com/en-us/kb/3163622

изменяет обработку политик. Если раньше она обрабатывалась в контексте пользователя, то теперь (с примененным обновлением) она будет обрабатываться в контексте компьютера. Иными словами, если вы использовали Security filtering для применения пользовательских политик, работать такой фильтр больше не будет.

Именно поэтому я всегда рекомендовал очень крепко подумать, прежде чем использовать такую фильтрацию без крайней необходимости.

Итак, что же мы получим в итоге обновления?

Скорее всего, все взорвется- ярлыки, диски, прочие GPО радости, терминальные серверы и все-все-все. Предвижу ежедневные взрывы на форумах технет, но следить сейчас времени совсем нет.

Что делать?

Читать «Изменения в обработке GPO, или Patch Tuesday» далее

Короткая заметка о TLS


Все думал, стоит ли собрать список ресурсов. дабы их можно было найти, и, как оказалось- стоит. В нашем уютном чатике даже собрались и сели вспоминать, кто какие ссылки знает, и у кого рейтинг по ним толще.

Поэтому, коротко приведу тестеры TLS возможностей для проверки ваших серверов.

http://checktls.com/

https://sslanalyzer.comodoca.com

https://www.ssllabs.com

Еще год назад команда Exchnage в блоге писала о том, что, мол, переходите уже на TLS. Правильные парни, разумеется, перешли еще в 13-м году, поскольку еще тогда не переходить на TLS 1.2 было очень не модно.

Если вам до сих пор страшно, то скажу честно, TLS 1.2 прекрасно работает что в  2010, что в 2013-м Exchange. В 2016 и подавно. Не оставляйте дырки в безопасности серверов. Если вам не нужна совместимость со старыми крипто алгоритмами (а она вряд ли вам нужна)- уберите ее. Нехитрыми и простыми действиями можно доставить очень много неприятностей атакующим, которые только и рассчитывают на бездействие администраторов и их неосведомлённость в вопросах безопасности.

Can’t remove move request


— Failed to communicate with the mailbox database, говорит нам консоль при попытке удалить запрос на перемещение ящика в Office 365, да и «на земле» такое случается. А удалить, допустим, очень надо- ведь иначе никак не начать новый, ибо старый пока еще висит, пусть даже и выполненный.

Темные личности любят в этот момент  с торжествующим криком доставать ADSI и мужественно выпиливать атрибут msExchMailboxMoveRemoteHostName через него. Таким товарищам сразу становится грустно, если ящиков, скажем, 50 :). Облегчим им жизнь пятистопным ямбом:

Get-Mailbox | ft name,MailboxMoveRemoteHostName  #выловим тех, у кого атрибут не очищен, и очистим его.

#Командлеты не могут менять многие свойства ящика пользователя, но я уже обращал внимание читателей блога, что это не должно их расстраивать- задача совсем не сложная.

$ou = «LDAP://OU=Users,OU=CA,OU=@To Cloud,DC=source,DC=com»
$filter = «(msExchMailboxMoveRemoteHostName=*)»
$searcher = New-Object adsisearcher([adsi]$ou , $filter)
$searcher.FindAll() | Foreach {
$user = $_.GetDirectoryEntry()
$user.’msExchMailboxMoveRemoteHostName’ = «$null»
$user.SetInfo()
}