IPv6 отключили… опять?


 

 

 

 

 

 

 

 

Пробудили как-то ото сна, с криками “ааааа PDC не работает. Все пропало”. Стали чинить, и вот что открылось взору. На первый взгляд проблемы с паролем компьютера, да.

 

 

 

 

 

 

 

Выяснилось, что на контроллер не попасть никак. Зашли на него из консоли вари, и увидели что профиль сети перекинулся в Public. Начали смотреть, ибо кейс древнючий еще с 2008-го.

Вылечить сразу же на месте можно просто, быстро и с ребутом:

Reset-ComputerMachinePassword -server {name of other domain controller}

Выкл/Вкл сетевой адаптер, перезагрузиться.

Но виновником ситуации как всегда оказались руки админа, который….

“я только снял галочку с IPV6 в настройках адаптера.”

В очередной раз хочется сказать: дети, не трогайте настройки IPv6 , если вы не знаете что с NT 6.0 это часть сетевого стека ОС. Будьте проще, и пользователи к вам потянутся. И проблем таких не будет.

Просто включаем IPv6 на сетевом адаптере

NetAdapterBinding -Name “Name” –ComponentID ms_tcpip6. #enable IPv4

и забываем об этом.

Полезная ссылка пополнилась еще одним кейсом.

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


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

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

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

Я еще два года назад  (или даже больше) честно, четыре года, оказывается как-то пару раз сталкивался и кому-то на форумах даже разжевывал, но все потонуло. Вроде как ресурс блога ну очень известный, да и автор не кто-то там, а 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О радости, терминальные серверы и все-все-все. Предвижу ежедневные взрывы на форумах технет, но следить сейчас времени совсем нет.

Что делать?

Continue reading “Изменения в обработке 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()
}

Add-ADFSAttributeStore и его друзья


Небольшой баг или фича с powershell ADFS.

Если добавить хранилище атрибутов, используя командлет Add-ADFSAttributeStore, оно не будет работать в примере

Add-ADFSAttributeStore -name ‘My Ldap Store’ -StoreType ‘LDAP’ -Configuration @{“Connection” = “LDAP://fab.com/dc=fab,dc=com”}

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

хранилища SQL будут иметь строку, начинающуюся с заглавной буквы, “Connection”, а LDAP  будет со строчной.

Добавим хранилище еще раз, на этот раз используем строчную: Add-ADFSAttributeStore -name ‘My Ldap Store’ -StoreType ‘LDAP’ -Configuration @{“connection” = “LDAP://fab.com/dc=fab,dc=com”}

 

Мы должны принципиально изменить наш подход к безопасности


Давайте на этой неделе попробуем другой, не технический,  стиль статьи. В статье предлагается сделать шаг назад и взглянуть на стратегию ИТ “с высоты птичьего полета”, а не со стороны технических / тактических деталей ИТ-операций. Эта статья является результатом совместных усилий по идентификации и безопасности и была разработана в течение длительного периода времени с участием множества сотрудников MCS, PFE и групп кибер безопасности в Microsoft. Наслаждайтесь!
Michael Hildebrand- MSFT

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

Идентификация должна быть важным направлением для обеспечения безопасности

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

Предлагаемые правила Идентификации:

  1. Если плохой парень сможет убедить сотрудника компании что он это Вы, то он получит доступ ко всем Вашим данным, хранящимся в организации и потенциально любой другой организации, доверяющей Вам.
  2. Если плохой парень может изменить пароль для Вашей учетной записи, то он имеет доступ ко всем данным, доступным для этой учетной записи.
  3. Если плохой парень может украсть (или применить социальную инженерию) пароль Вашей учетной записи, то он имеет доступ ко всем данным, доступным для этой учетной записи (и всех других, использующих тот же пароль) а также потенциально любого другого клиента, который доверяет провайдеру.
  4. Если плохой парень может получить ответы на Ваши вопросы безопасности от социальных медиа, Ваши аккаунты в них больше не Ваши, и, следовательно, он имеет доступ ко всем данным, доступных на аккаунтах, где Вы использовали эти вопросы безопасности.
  5. Если плохой парень может получить доступ к паролю или хэшу пароля, это больше не Ваша учетная запись, и, следовательно, он имеет доступ ко всем данным аккаунта (и всех других, использующих тот же пароль).
  6. Многофакторная  аутентификация (MFA) не является панацеей; она защищает от кражи ПАРОЛЕЙ,  но не кражи УЧЕТНЫХ ДАННЫХ. Если  у плохого парня будут права учетной записи администратора /root доступ на машине, где Вы вошли в систему, используя MFA, то он имеет доступ к Вашей учетной записи (и Вы вернулись к Правилу # 1).
  7. MFA без защиты учетных (например брутфорса, оповещения пользователей, либо активного аудита) означает, что если получен физический доступ, мы вернулись к брутфорсу (перебору) пароля. Если плохой парень подберет пароль, то он имеет доступ к Вашей учетной записи (и Вы вернулись к Правилу # 1).

“Только любители атакуют машины; профессионалы нацелены на людей.”

Шнайер, Брюс (2000-10-15). Семантические атаки: Третья волна Сетевых атак. Шнайер в блоге Безопасности. Continue reading “Мы должны принципиально изменить наш подход к безопасности”