投稿

Teams会議ロビーに新しい設定が追加される予定

ロビー設定しないとゲストが好き勝手する可能性がありますよね Microsoft 365ロードマップにTeams会議のロビー設定追加の予定がありました。 https://www.microsoft.com/ja-jp/microsoft-365/roadmap?filters=&searchterms=64343 Teams会議ロビーをバイバスできるユーザーの設定に、 “only me”(私のみ) が追加される予定です。 追加予定日は来月2020年6月 中ですね。 主催者以外全員一旦ロビー待機 この設定を有効化すると主催者以外全員会議参加時はロビーに入る動きになるようです。 Teams会議のロビー機能は、いきなりゲストなどに会議に入られるとセキュリティ上好ましくないため、一旦ロビーという会議のやり取りに参加できない場所に入ってもらい、権限のあるユーザーが個々に承諾することで会議に入れるようになるという機能です。 大人数の会議でロビーなしだと誰が入ってるのか全然分からなくなってくるので危ないというリスクをおさえるためでもありますね。 今回追加される機能は、同一組織内のユーザーも含めて主催者以外は全員ロビーに待機させるという設定です。 同一組織内のユーザーも含めて 、という部分がポイントです。今までこれはできませんでした。 うーん私はあまり使い道ないかなーという感じですが社内の人間も含めて情報の漏洩を厳しく管理し抑制したい場合とかでしょうね。 例えばすごく重要な機密を扱う会議とか、従業員のセンシティブな情報を話すような会議では同じ会社の人であっても聞かれたくないでしょうからそういう時でしょう。 リモートワークが増えると使い道は増えるかも リモートワークが増え、従来は対面で行っていた極秘情報を扱う会議や、上司に非常にプライベートな悩みを相談する場もリモート会議で行うようになってくると思います。そうした際には是非使いたい設定ですね、恐らくそれがこの設定を使うに想定されているピッタリの会議です。 おわり 以上Teamsロビー設定の追加予定のロードマップ情報でした。 ロードマップ関連でいうと、そろそろ “Office 365グループ” が “Microsoft 365グループ” に徐々に名称変更始めてい...

コマンドプロンプトで使うネットワーク系のコマンドをPowerShellコマンドレッ トに置き換えたい

未だにコマンドプロンプト開くのどうかと思うので。あとPowerShellで調査した方がかっこよさげなので。 トラブルシュートの際にネットワーク情報を収集するためにコマンドプロンプトからコマンドを発行することは結構多いと思いますが、さすがにもう2020年なのでPowerShellコマンドレットに置き換えていきたいです。 ただ使い慣れているとcmdからの方が早いので結局いつもどおりで進歩がないので、意識的に変えていかないとダメですね。 Ping command prompt: Ping ping yahoo.co.jp Pinging yahoo.co.jp [182.22.59.229] with 32 bytes of data: Reply from 182.22.59.229: bytes=32 time=12ms TTL=53Reply from 182.22.59.229: bytes=32 time=12ms TTL=53 Reply from 182.22.59.229: bytes=32 time=12ms TTL=53Reply from 182.22.59.229: bytes=32 time=11ms TTL=53 Ping statistics for 182.22.59.229:Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),Approximate round trip times in milli-seconds:Minimum = 11ms, Maximum = 12ms, Average = 11ms PowerShell: Test-NetConnection Test-NetConnection -ComputerName 'yahoo.co.jp'ComputerName : yahoo.co.jpRemoteAddress : 183.79.135.206InterfaceAlias : Wi-FiSourceAddress : PingSucceeded : TruePingReplyDetails (RTT) : 22 ms PowerShell: Test-NetConnection -port Test-NetConnectionはポートクエリーのよ...

Exchange OnlineでReply All Stormへの対処作が実装

全社員宛のメールって大概の人にとってはどうでもよかったりしますよね Exchange Onlineでメンバーが沢山いる配布リスト(DL)へ「全員へ返信」が連続で出されるのを防ぐ機能が実装されたようなのでさらっと見てみましょう。 Reply All Storm Protection in Exchange Online 例えば全社員がメンバーとなっているDL宛にメールを出したとして、そのリアクションとして誰かが全員宛に返信をして、それに対してまた誰かが・・・ 少人数の会社ならまだ良いのですが、何万人もいるような会社でこういう状況が続くと受信者にとってはウザったいですし、Exchange Online全体のパフォーマンス低下に繋がる恐れもあります。 特定条件を満たすとNDRを返すようになる 5000人を超える受信者宛のメールに対して1時間以内に10回の全員へ返信 この条件を満たすと、 4時間の間 次の全員へ返信からは以下のようなNDRが返るようです。 管理者による設定変更も今後実装予定 このReply All Storm Protectionは非常にありがたい機能ではありますが、組織によってはNDRになっては困ることもあるかもしれませんし、逆にもっと早くNDRを返すようにしてほしいというところもあるでしょう。 そういった要望を集めつつ今後管理者側で設定の変更をできるようにしてくれるとのことです。 受信者の人数 全員へ返信の回数 NDRを返すか返さないか NDRを出す期間 この辺りは是非コンフィギュラブルにして頂きたいところです。 おわり 管理者側からの設定変更に加えてReply All Stormのレポート作成機能や通知機能も検討されているようです。 Teamsが今後さらに普及していくとExchange Onlineはだんだん枯れていくような気がしますが、まだまだビジネス上メールは必須のツールですしこういう細かいエンハンスメントはありがたいですね。

EOP/Office 365 ATPの推奨設定

EOP, O365 ATPで組織をサイバー攻撃から守る スパム、フィッシング、マルウェア添付など、メールを起点としたサイバー攻撃は今でも多く、最近では新型コロナウイルスCOVID-19の状況を利用したメール攻撃も増えているそうです。 Microsoft 365ではメールやコラボレーションツールへの攻撃対策としてExchange Online Protection (EOP), Office 365 Advanced Threat Protection (O365 ATP)という2つのセキュリティサービスがあり、使用できるライセンスがあればすぐにMicrosoft 365テナントと連動したセキュリティソリューションとして利用ができます。 これらを有効に利用してリモートワーク環境下でも組織をしっかり守っていきましょうという案内がMicrosoftから出ています。 Get the most out of Office 365 ATP in the shift to remote work It’s never been more critical that employees and the partners they collaborate with can work remotely and stay more secure. In the months leading up to this monumental shift, phishing and malware attacks were at the top of the list of cybersecurity threats. Now, attackers are capitalizing on fear, l… Microsoftの推奨設定 今まで知りませんでしたがEOPとO365 ATPについてはMicrosoftが推奨する設定値が公開されています。 Microsoft recommendations for EOP and Office 365 ATP security settings, recommendations, Sender Policy Framework, Domain-based Message Reporting and Conformance, Domai...

Azure AD条件付きアクセスを迅速に展開するためのヒント集

リモートワーク環境の早急な整備 新型コロナウィルス(COVID-19)の影響が日に日に深刻化していっている中、リモートワーク環境の早急な用意が各企業に求められているように感じます。 既存のVPN設備のみで業務が回ればそのままフルリモートで構わないと個人的には思いますが、VPN設備自体が全社員一斉のリモートワークや、Office 365をはじめとしたクラウドサービスへの接続を考慮に入れた設計になっていないことが多いと思います。 結果、VPNやネットワーク機器のキャパシティ不足、Web会議のようなリアルタイム通信系の通話やビデオのシステムで社内ほどのパフォーマンスが出ない、などのユーザークレームがあがり課題となることも多いかと存じます。 以前紹介したVPN利用時にいくつかのURLやIPレンジ、ポートをスプリットトンネリングすること( こちら )でこれらの問題を解消できる可能性はありますが、そもそもVPNを使わせずに各社員にインターネットを通してクラウドサービスにアクセスさせたい場合はAzure ADの条件付きアクセスを使うことになります。 Azure AD条件付きアクセスをすぐに展開するためのTips集 FAQ形式で、Microsoftが条件付きアクセスを迅速に展開するためのヒント集を公開しました。 Frequent questions about using Conditional Access to secure remote access Industry trends and changes in the way we work usually span years, with organizations evolving at their own pace. But we’re living in unusual times. Organizations asking employees to work from home to slow the spread of COVID-19 are making huge organizational and process changes in a matter of we… 実際に条件付きアクセスのサンプル設定やトラブルシュート方法も併せて記載されているので条件付きアクセスをすぐに展開したい...

Office 365をVPN環境で快適に使うためにはこの4つのURLだけはインターネット 直接アクセスにすること!

クラウドサービスなのにVPNで全部社内ネットワーク通してアクセスするの違和感半端ない・・ Office 365だけでなく、様々なクラウドサービスが基幹システムやアプリケーションとして社内利用されているところが多いと思います。 しかしながら、外出先や自宅などからインターネット上にあるクラウドサービスへアクセスするのに、昔からあるVPNを通して社内ネットワーク経由でアクセスする形態であるところが多いのではないでしょうか。 私もそうなのですが、なんかこの使い方って違和感があるというかなんかもったいない気がしませんか。笑 もちろんそもそもクラウドサービスが業務に欠かせないシステムに採用されることは昔は想定されていなかったでしょうし、インターネット出口を監視、ログするためという理由は理解できますが・・。 VPN環境でも4つのURLをスプリットトンネリングするだけでOffice 365を高速化する! Microsoftが上記のようなVPN環境下でも、特定URL/IPサブネットだけをVPN回線ではなくインターネット直接アクセスするように構成すること(VPNスプリットトンネリング)でパフォーマンスが最大化できるよ、と紹介されています。 How to quickly optimize Office 365 traffic for remote staff & reduce the load on your infrastructure Over the past few weeks, Microsoft, and more specifically the Office 365 Network team have seen a large influx of questions from customers around how best to optimize their Office 365 connectivity as they work diligently to plan for a large amount of their userbase suddenly working from home. We’ve … 具体的にインターネット直接アクセスにすべきURL/IPサブネットが書かれているので非常に分かりやすいですね。 別のサイトで公開さ...

AAD登録、AAD参加、ハイブリッドAAD参加、Intune、条件付きアクセスの関係性

デバイスをAADに登録することとIntuneと条件付きアクセス すごく今更な感はありますがこれらの関係性を少しまとめてみました。言葉として参加と登録ってややこしいですよね。 Azure ADへのWindows 10登録手法 Azure AD参加 感覚的にはAADにマシンをドメイン参加するイメージ。 AADアカウントでPCにログイン。 オンプレミスのADドメインに参加しているとできない。 Azure AD参加可能ユーザーを制限するか事前にデバイス情報を登録することでBYODの参加を防げる。 Intuneにも自動登録される。(自動登録できる) オンプレミスのADに参加していると選択できない方法なので既にADを使って歴史が長い会社がすぐにAAD参加に切り替えるのはハードルが高そうです。逆に既存のオンプレミスAD資産がない組織はこちらが最有力選択肢です。 Hybrid Azure AD参加 オンプレミスADに参加したコンピューターの情報がAADCを通してAADにも参加される。 今まで通りADユーザーアカウントでPCにログインし、オンプレミスADリソースにも今まで通りにアクセス可能。 AADCでユーザーとコンピューター両方同期していないとならない。 Intuneにも自動登録される。(できる) 多分既存オンプレミスのADリソースはそのまま利用したい会社はこちらが検討の筆頭になると思います。 Azure AD登録 オンプレADドメインに参加しててもできる。 マシンの情報をAADに”登録”だけするイメージ。 ローカルアカウントかADアカウントでPCにログインする。 条件付きアクセスでIntune Enrollmentを特定IPから以外ブロックすることである程度はBYODの登録を防げる。 Android, iOS Intuneにも自動登録される。(できる) スマートフォンが主たる対象ですかね。オンプレミスADに参加しているけどAADCで同期していない環境はハイブリッドAAD参加できないのでこちらを選択かな? Intuneに登録されることのメリット 上記いずれの方法でもIntune(クラウド)にもデバイスが自動登録がされます(少し設定は要ります)。 そうすることのメリットはIntuneからデバイスの設定を管理やアプリケーションの配布などを行えることに加え、Intune管理下にあることを...