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О радости, терминальные серверы и все-все-все. Предвижу ежедневные взрывы на форумах технет, но следить сейчас времени совсем нет.

Что делать?

Читать далее

Короткая заметка о 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). Семантические атаки: Третья волна Сетевых атак. Шнайер в блоге Безопасности. Читать далее