AD経由でアクセスするクラウドサービスへのアクセス制御を行う方法について解説しました。具体的にはOS種類に基づいてアクセス制御を行う方法を解説しましたが、そのほかにも様々な条件をもとにアクセス制御ができるので、今回はその中でもニーズが高い、会社支給のデバイスからアクセスしたときだけを許可する、という設定についてみていきます。前回のおさらいですが、条件付きアクセスではユーザー/グループ、クラウドアプリ、条件をそれぞれ設定し、すべての条件に合致した場合に拒否する、または条件付きで許可する、という設定を行うものでした。前回は「WindowsまたはiOS以外のOSからのアクセスを拒否する」という設定を行いましたが、その場合、条件で「WindowsまたはiOS以外のOS」、許可/拒否の項目で「拒否」という設定を行いました。条件付きアクセスのおさらいを踏まえて今回は「会社で支給しているデバイスからアクセスした時だけ許可する」という設定を行います。このような条件を設定する場合、最初に「会社支給のデバイス」を定義しなければなりません。条件付きアクセスでは、次の2つの方法で「会社支給のデバイス」を定義できます。どちらの場合も個人所有のデバイスであれば、これらの条件に当てはまることはないと思います。会社支給のデバイスとしましょう、と定義しています。これらの設定は条件付きアクセスの許可/拒否を設定する画面から[アクセス権の付与]を選択して行います。参加済みのデバイスが必要]を選択します。Directoryデータベース内で管理されるオブジェクトのうち、OUとユーザーという2種類のオブジェクトの管理方法について解説しました。今回は、それ以外の代表的なオブジェクトである、コンピューターとグループについて解説します。コンピューターとは、ドメインに参加しているコンピューター自体を認証するためのオブジェクトで、コンピューターアカウントとも呼ばれます。ドメインに参加するコンピューターは、起動時にコンピューターアカウントを使用して、ログオンをおこなっています。私たちからは見えていませんが、コンピューターを起動してユーザー認証がおこなわれる前に、コンピューター自体の認証がおこなわれているのです。コンピューターアカウントにもパスワードが設定されており、コンピューターアカウントの名前とパスワードを使用した認証がおこなわれています。Directoryによって生成されます。ドメインに参加した時点で、コンピューター名からコンピューターアカウントの作成および関連付けがおこなわれ、パスワードが生成されてドメインコントローラーからそのコンピューターに通知されます。ユーザーアカウントのパスワードと同じように、このパスワードは定期的に変更されます。既定では30日に1度のタイミングで変更され、このような動作をおこなうことで、コンピューター名を偽装してドメインへアクセスがおこなわれることを防いでいます。コンピューターアカウントのプロセスはバックグラウンドでその都度おこなわれているため、そのコンピューターを定期的に起動して使用していれば、特別な管理は必要ありません。長期間使用しないコンピューターがある場合には、不正利用できないようにコンピューターアカウントを無効にして、ドメインの認証を禁止します。Directoryデータベースを復元した場合や、クライアントコンピューターのディスクイメージを復元した場合などでは、クライアントコンピューターとコンピューターアカウントのパスワードの不一致が起き、認証に失敗することがあります。コンピューターアカウントの認証に失敗しても、ユーザーの画面はユーザー認証の画面が表示されますが、ユーザー名とパスワードを正しく入力しても、以下のエラーでサインインできない状況になります。このような状況になった場合は、コンピューターアカウントのリセットが必要です。Directoryユーザーとコンピューターの管理ツールからコンピューターアカウントのリセットをおこなった上で、コンピューターのドメイン参加をやり直す方法です。グループは、リソースへのアクセス許可の管理を効率的におこなうことを目的として使用されるオブジェクトで、グループアカウントとも呼ばれます。同じアクセス許可や権限を複数のユーザーに割り当てたい場合、個々のユーザーに対してその割り当てをおこなうのは非効率であり、後でそれをまとめて変更したい場合も面倒です。グループを作成し、複数のユーザーなどをそのグループのメンバーとして設定すれば、グループの単位でアクセス許可や権限の割り当てがおこなえます。グループ自体に設定するパラメーターの1つに、スコープがあります。スコープは、所属するメンバーとグループの使用範囲を決定するパラメーターであり、スコープの選択肢としては3種類があります。どのスコープでグループを作成するかによって、どのようなものを含められるかが異なるというわけです。3つのスコープのそれぞれに含めることができるオブジェクトは以下の通りです。グループの作成を無計画におこなってしまうと、却って管理が煩雑化してしまいます。マイクロソフトが推奨するグループ作成および管理方針の1つにID-G-DL-A(またはID-G-U-DL-A)があります。Directoryのデータベースやドメインコントローラーについて解説してきました。Directoryデータベース内で管理する「オブジェクト」について解説します。Directoryデータベース内に登録されるアカウントやリソースの総称です。Directoryデータベースには様々な情報を登録し、その情報を利用することができますが、それらは総称してオブジェクトと呼ばれます。Directoryデータベースに登録する代表的なオブジェクトには、以下のようなものがあります。minutesシングルサインオンを利用することでパスワードを1つ1つ管理するという煩雑な作業が必要なくなり、利用者はクラウドサービスに対して、快適にアクセスできるようになります。本記事ではシングルサインオンの特徴や導入可能なツールについてご紹介いたします。「多要素認証」といった言葉を耳にする場面が増えてきたと思います。「スマホを落としただけなのに」という映画&漫画でもなりすましの怖さがよくわかります。セキュリティ侵害は日に日に増加しており、ユーザー名とパスワードのみを利用してユーザーアカウントの安全性を保つことはできなくなりつつあります。パスワードを強固にするだけでなく、より強力なソリューションによって、不正なユーザーを振るい落とすためにセキュリティを向上させる必要があります。?」「なぜ二要素認証が必要なのか」「二要素認証を導入するための製品」についてお話していきます。?」そんな疑問を持っている方も少なくないかと思います。authentication」「tfa」など様々な呼び名がございます。これらは全て2つまたはそれ以上の要素を使用して認証を行うことです。身近なものだとATMやSMSなどのワンタイムパスワードもそこに含まれます。要素とは、以下の3つになります。前回のコラムでは、既定でどのようにレプリケーションが動作するのかについて解説しました。レプリケーションの間隔や頻度などを環境に合わせて変更したい場合もあります。組織の中で「東京」と「大阪」のように物理的に離れた拠点を持っており、その拠点間は低速な回線で接続されている場合などです。Directoryのレプリケーションは夜間におこないたいというニーズや、間隔を調整したいといったニーズが考えられます。Directoryには「サイト」という情報があります。今回は、サイトそのものと、サイトをまたいでおこなうレプリケーションについて解説します。Directoryデータベースの複製には、「サイト」という情報が利用されます。Directoryにおけるサイトとは、高速に通信できる単位となる情報です。組織の拠点が東京と大阪にある場合、各拠点内のドメインコントローラー同士は高速に通信することができます。東京と大阪の間をつなぐネットワークは高速であるとは限りません。WANを介した通信であるため、信頼性が低かったり、速度についてもLANに比べて低速である場合が考えられます。そのような場合には、東京サイト、大阪サイトというように拠点ごとにサイトを分けることが可能です。Directoryに認識させることができるようになっているのです。Directoryの既定の設定では、Default-First-Site-Nameという名前の1つのサイトのみが存在しており、すべてのドメインコントローラーはDefault-First-Site-Nameというサイトに所属します。前回のコラムで解説したレプリケーションは、1つのサイト内でのレプリケーションです。サイト内でのレプリケーションの動作は前回のコラムで解説したように、ほぼリアルタイムに複製をおこないます。複数のサイトを構成し、各サイトにドメインコントローラーを配置することで、どのようなメリットを得られるのでしょうか?そのメリットの1つに、サイト間のレプリケーションをおこなう時間帯や間隔を制御することが可能になることが挙げられます。PowerShellコマンドレットを使って作成する方法をみてきました。ビジネスの収益性に大きく影響するのが従業員の「実務時間」、つまり日々の業務の中で、従業員がどれほどの時間を業務に費やしているかです。勤怠をタイムカードや出勤簿、あるいはエクセルシート等で管理していた場合、その正確性は従業員の裁量にゆだねられるため、提示された情報か正しいかどうかの判断が難しいという面があります。東京都産業労働局が公開した「労働時間管理に関する実態調査(平成29年3月)」によると、以下の調査結果が報告されています。管理職についても「タイムカード・ICカード等」(53.3%)が最も多く、「自己申告」(23.4%)がこれに続いている。この結果からも見てわかる通り、現在でも従業員本人の申告に基づく勤怠管理を行っている企業が過半数を占めており、勤怠のつけ忘れ等といった人的ミスを防ぐための対策が必須となります。集計することで、より正確な実務時間の把握を目指す企業が増加しています。Plusの「ユーザーアテンダンス」レポートでは、収集したイベントログを元に、従業員が実際にコンピューターを操作した時間を算出します。活動時間を算出する際はユーザーのログオン/ログオフ時間を追跡しますが、退勤の都度ログオフやシャットダウンを実施しないというユーザーのため、スクリーンセーバーの起動、画面のロック、リモートセッションの切断などの情報も加味して活動時間を算出します。これにより、従業員が実際に社内PCを操作していた時間を、正確に把握することが可能となります。Directoryのログをリアルタイムで収集して、200以上のレポートで可視化、およびアラート通知などを行うWebベースのオンプレミス型ソフトウェアです。Windowsドメイン上で管理されている、ドメインコントローラー/ファイルサーバー/メンバーサーバー/PCなどのITリソース、およびユーザー/グループ/ポリシーなどのオブジェクト情報から、簡単に監査レポートを作成します。Plusの実際のレポート画面です。[詳細]リンクをクリックすると、以下のようにスクリーンセーバーの起動やロック時間を除いた、実際の勤務時間が一覧で表示されます。レポートはCSV/PDF/XLS/HTML形式でのエクスポートに対応しているため、定期的にローカルへ保存、あるいは担当者へメール送付することが可能です。Directoryで発生した変更を可視化するだけではなく、ログに基づく従業員の勤怠管理にも対応しています。Plusを操作して機能をご確認されたい場合は、30日間無料でフル機能をご利用いただける評価版もございますので、是非一度ご評価いただければと思います。Directoryのコラムを担当している新井です。あり、どの情報がどのパーティションに格納されるが決まっていること、またパーティションによってどの範囲のドメインコントローラーに複製されるかが異なることについて解説しました。今回は、その複製のしくみについて解説します。ドメインコントローラーは、組織内のユーザー認証など重要な役割を持つサーバーです。ドメインコントローラーがダウンしてしまうと、認証ができなくなり、システム全体に大きな影響を及ぼしてしまいます。そこで、一般的な運用ではドメインコントローラーを2台以上用意し、どのドメインコントローラーでも同じ情報を使用して認証でき、いずれかのドメインコントローラーがダウンした場合でも認証を継続できるようにすることが求められます。そのためには、どのドメインコントローラーも同じ内容のデータベースを保有している必要があります。ドメインコントローラー間でデータベースの同期をとるために使われるのが、レプリケーションと呼ばれる複製のしくみです。ドメインコントローラー同士はレプリケーションの処理をおこなうことで、保持しているデータベースの内容を定期的に確認し、それぞれが保有するデータベースの内容が同一となるように同期をとっています。この動作によって、ドメインコントローラーがホストしているデータベースは他のドメインコントローラーに複製されます。DC1でユーザーを作成すれば、その変更内容はほぼリアルタイムにDC2に反映されます。逆もまた然り、DC2でユーザーの部署などのプロパティの変更が行われれば、その変更内容はDC1にほぼリアルタイムで反映されます。RODCを除く、通常のドメインコントローラーであればどのドメインコントローラーでもデータベースに対する変更をおこなうことができるようになっており、その変更内容は他のドメインコントローラーに複製されます。このような動作により、データベースの整合性が保たれているのです。前回のコラムでは、追加のドメインコントローラーを展開することについて解説しましたが、特別な設定をしなくてもレプリケーションは自動的に動作します。2台目以降のドメインコントローラーを追加すると、どのドメインコントローラーとどのドメインコントローラーの間で複製をおこなうかがシステムによって決定され、複製が開始されるようになっているのです。複数のドメインコントローラーを展開するだけで、結果的にドメインコントローラーの負荷分散や障害対策になります。Directoryサイトとサービス」という管理ツールによって確認することができます。この管理ツールはドメインコントローラーに既定でインストールされ、管理ツールを開いてツリーを展開すると、選択したドメインコントローラーの直接の複製相手である「複製パートナー」を確認することができます。既定では自動的に複製パートナーが決定されますが、管理者が手動で複製パートナーを設定することも可能です。2台のドメインコントローラーではお互いが複製パートナーになりますが、3台以上のドメインコントローラーがいるシナリオでは必ずしもレプリケーションが直接的におこなうことが最適とは限らないからです。そのため、DC1の複製パートナーとしてDC2とDC3の両方を設定することもできますし、DC1の複製パートナーはDC2のみに設定し、DC2を介してDC3に伝達されるように構成することも可能です。ドメインコントローラー間でおこなわれるレプリケーションは、変更通知を用いたプルレプリケーションです。複製パートナーが複数存在する場合には、同時にレプリケーションがおこなわれるのではなく、少しだけタイミングをずらして処理がおこなわれるようになっています。あるドメインコントローラーがデータベースに対して変更をおこなった場合、15秒待ってから1つ目の複製パートナーに変更通知を送ります。その変更通知を受け取ったドメインコントローラーは、変更の差分情報を要求し、レプリケートをおこないます。複製パートナーが複数存在する場合には、さらに3秒待ってから次の複製パートナーに変更通知を送ります。このように動作することで、あるタイミングでレプリケーション処理が集中してしまうことを回避しつつ、ほぼリアルタイムに複製をおこなうことでデータベースの内容を同一に保っているのです。Directoryを管理していく上で「キホン」となる概念やキーワードについて解説していきます。前回(第2回)のコラムをご覧いただいてない方は、ぜひ前回のコラムと併せてご覧になってください。今回は、「スキーマ」、「パーティション」、「管理ツール」という3つについてピックアップして解説します。Directoryの「オブジェクトに関する定義情報」となるものです。スキーマでは、どの種類のオブジェクトがどのような属性を使用するのかを関連付けて管理しており、オブジェクトの作成時などにはスキーマの情報が参照されます。Directoryには様々な種類のオブジェクトがありますが、ここではユーザーを例に考えてみましょう。ユーザーの作成そのものについては別のコラムで紹介しますが、ユーザーを作成してプロパティを確認すると、最初から様々な属性の項目が用意されています。これらが用意されているのは、スキーマ内で「ユーザーで使用する属性はコレとコレと...」というように既定で定義されているためなのです。スキーマには、「クラス」と「属性」という2つの情報が存在します。このうち、「クラス」がオブジェクトの種類を表すもので、ユーザー、コンピューター、グループなどの様々なクラスが存在します。メール、などの様々な属性が存在します。スキーマではこの2つの情報を関連付けて、どのクラスでどの属性を使用するかを管理しています。そのため、いつオブジェクトを作成しても同じ属性の項目が使用できるようになっているのです。Directoryデータベース内の論理的な”仕切り”」です。Directoryデータベースはntds.ditという単一のファイルで存在し、ドメインコントローラー上で管理されます。このファイル内には、論理的な仕切りであるいくつかのパーティションを持っており、どの情報がどのパーティション内に格納されるかが決まっています。Directoryデータベースは可用性を高めるために複数のドメインコントローラー間で複製されますが、パーティションによってどの範囲のドメインコントローラーと複製するのかも異なります。