Про коварный Microsoft


MS с каждым годом становится все коварней. Сегодня например последний день работы TLS 1.1 и 1.0, не удивляйтесь, всех предупреждали годы назад ещё. Ну и не стесняемся, репостим и расшариваем ссылки на стать, авось это поднимет кредит доверия как к доставлятелю годных ссылок в интернете:

Final Notice for disabling of TLS1.0 and TLS 1.1 Support for Exchange Online Mail Flow

MC229914 · Published Dec 14, 2020 Message Summary

We will no longer support TLS 1.0 and TLS 1.1 from Exchange Online mail flow endpoints beginning January 11th 2021. As those versions of TLS are already retired (most recently communicated in MC218794, July ’20), Exchange Online customers and their partners should already be using TLS1.2 to protect SMTP connections between their email servers or devices and Exchange Online.

Key Points:

  • Major: Retirement
  • Timing: January 11th, 2021
  • Action: Review and assess impact for your organization

Не так давно выключали Outlook 2013, чтобы он не мог подключаться к Office 365. Про это тоже писали в оповещениях, но их мало кто читает. Советуют, кстати завести оповещения себе в Planner, чтобы лихо назначать оповещения. как скажем выше сразу на ответственных или не очень работников. Здорово придумано надо сказать. раньше для этого приходилось хитрить и автоматизировать при помощи палки и верёвки, а тут поди-ка, сделано из коробки, только учётную запись подключи.

Но обрадовало сегодня ещё и вот такое: в новомодном Admin Сenter просто нет возможности вернуть ящик обратно на землю! Кнопка, как говорят пользователе “засерена”. В старом, понятно есть, но на него давно махнули рукой и того и гляди переименуют и снесут. Так что надежды нет. Остался конечно ещё старый способ мигрировать ящик взад используя PowerShell, и про него лучше помнить, т.к. скорее всего этот способ оставят единственным. Если оставят 🙂

История чатов в MS Teams



MS Teams справил на днях трехлетний юбилей, а некоторые возможности как были недоделаны, так пока и остались. Один из таких примеров- история. Нужно, положим взять всю историю секретного чатика, да и вывалить куда-то, чтобы неповадно было. Или сохранить на диск, чтобы интернет стал чище. Или еще что. Раньше вариантов решения проблемы было не так уж и много:

 Хитрецы открывали в барузере нужный чатик и сохраняли в pdf. Или Word, OneNote -как вариант.

Другой способ: использовался eDiscovery и экспортировались сообщения. Тоже вариант дрянь, как понятно. И MS еще чтобы было веселее передвигал историю в другую папку ящика, расположенную в Non-IPM subtree.

Недавно добавился способ использования API, а если совсем нет времени и хочется однокнопочного решения, то можно использовать вот такой метод с гитхаба.

Вкус и цвет у решений, как мне кажется все равно далек от совершенства. Делитесь в комментариях, что вы думаете по этому поводу.

Тефаль, ты всегда думаешь о нас!


 

 

 

 

 

 

Проблема: EOP в Office 365 не соблюдает политику отклонения писем DMARC “p=reject”, а применяет действие p=quarantine.

Решение: Транспортное правило!

Добрая забота иногда выливается в абсолютное игнорирование вендором RFC, просто потому что “мы лучше знаем, что вам нужно”. Логика здесь проста и понятна, как все с тем же игнорированием Ms-Exch-SMTP-Accept-Authoritative-Domain-Sender: МС предосталяет сервис, и это подразумевает что письма должны доставляться с большим приоритетом, нежели чем отклоняться.
Следуя этой логике, если политика выставлена со значением “отклонить” решения отклонить письмо не принимается, что противоречит стандарту DMARC. Таким образом, и “отклонить” и “карантин” будут означать здесь одно и тоже: решение будет принято в пользу последнего. На практиве это будет выглядеть так, CIO компании получит письмо от себя же самого (или от финдиректора) в папку нежелательная почта. Дальше действия пользователя просты и понятны, и комментариемв не требуют. (Приглашаю кстати тех, у кого стоят последние версии Exchange на земле потестировать описанное поведение: ставлю доллар, что все будет тоже самое.  Выстраиваемся в комментарии, ниже будет веселая ссылка  со свежим примером спама из чатика.)

Повлиять на это мы можем только транспортным правилом, поскольку политика DMARC прописанная в DNS будет попросту игнорироваться. Печально, но мы не будем терять присутствия духа, а правило может выглядеть например вот так:

New-TransportRule -Name “DMARC Reject” -HeaderContainsMessageHeader 'Authentication-Results'
-HeaderContainsWords ‘dmarc=fail action=oreject’

-RejectMessageEnhancedStatusCode '5.7.1'
-RejectMessageReasonText “Rejected by DMARC policy”`
-Comments “RFC 7489, 6.3.”

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

Полезная ссылка:

https://security.stackexchange.com/questions/226270/enforcing-dmarc-policy-reject-on-an-office-365-tenant

LDAP Channel Binding and LDAP Signing Requirements 2020


Все бегают и дергаются в припадках, завидев ссылку

https://support.microsoft.com/en-us/help/4520412/2020-ldap-channel-binding-and-ldap-signing-requirement-for-windows

и никто в общем-то не понимает что делать. (Обновление кстати уже перенесли с января на март, чтобы ну уж точно никто не бугуртил).

Что делать давным-давно написал Алан в официальном блоге, так что подписываемся на рсс, дабы сохранить спокойствие и душевное равновесие.

https://techcommunity.microsoft.com/t5/Core-Infrastructure-and-Security/LDAP-Channel-Binding-and-LDAP-Signing-Requirements-Update-now/ba-p/921536

Алгоритм простой. Continue reading “LDAP Channel Binding and LDAP Signing Requirements 2020”

Про обучение


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

С формальной частью покончено, перейдем к теме.

Я еще по теплой осени познакомился с такой крутейшей штукой как linuxacademy.com, и понял что до этого времени учился неправильно.

Continue reading “Про обучение”

Накопившееся


Читатели блога время от времени писали мне и спрашивали а чо,чо там, и вообще где разоблачения.  Докладываю- разоблачения возвращаются.

Первый номер в нашем сегодняшнем выпуске займут новые возможности Azure AD Connect.

Вот уже более пяти лет атрибут UserAccountControl  не реплицировался в облако ни под каким видом, причиняя адскую боль тем парням, кто поскупился или доверчиво послушав фетвы вендора, мол ADFS не нужен, ставьте себе PTA и все будет круто и таки не ставил ADFS  как первичный контур аутентификации. Ну не ставил и не ставил, не все же замечали что если учетка включена но истекла (account expired), то облако плевать хотело на это и все равно пропускало аутентифицироваться пользователя. Можете сами взглянуть какие лучи добра в комментариях сваливаются на голову МС за этот прекрасный дизайн. Предлагаются варианты, пробегаться самолично скриптом по таким гражданам и принимать меры (писать ТП письмо с отчетом, блокировать такие объекты и так далее). Будем надеяться что проблему как-нибудь да поправят, но для успокоения тех, кто заволновался и уже не может спать, можно напилить правило, которое будет отключать истекшие учетки.

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

Continue reading “Накопившееся”

Troubleshooting Azure AD Connect sync


В позапрошлом выпуске мы вместе видели, как сперва найти притаившийся сервер Azure AD Connect и что потом с ним можно после этого сделать. PowerShell не дает большой гибкости по отчетам и настройкам, поэтому если хочется узнать, как добрые дяди (или злые коллеги) настроили сервер, правильно ли и  вся ли политическая обстановка была учтена, то придется прибегать к инструментам, имеющимся у нас из коробки.

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

 

 

 

 

 

 

 

 

https://docs.microsoft.com/en-us/azure/active-directory/hybrid/tshoot-connect-objectsync

Azure Site Recovery Deployment Planner report


Часто администратор вляпывается в облако без малейшего понятия как начинать, кто виноват и что делать. Ну, с Exchange’ом то у нас есть помощник по развертыванию и Калькулятор и это более менее спасает, даже если вы спросили в тележном чате об этом в первый раз это не страшно, ценный совет потратить на получение навыков по работе с инструментами как можно больше времени всегда будет получен.

А что делать с цифровизацией, ускорением и перестройкой?

А если завтра -того?

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

https://docs.microsoft.com/en-us/azure/site-recovery/hyper-v-deployment-planner-analyze-report