読者です 読者をやめる 読者になる 読者になる

らくだ

[こころに贅沢させよう]をモットーの会社で情シスやってます

Office365のライセンス割り当てがグループ単位でできるようになったらしい

https://blogs.technet.microsoft.com/enterprisemobility/2017/02/22/announcing-the-public-preview-of-azure-ad-group-based-license-management-for-office-365-and-more/

 

これは朗報。

今まで、Powershellで自動的に割り当て、割り当て解除なんてやってたけどそんなことが不要になるー!

 

Amazon LinuxでAzure Active DirecoryのMFAを使った多要素認証を実装

参考にしたサイト

ご参考までに

下記サイトのようにお手軽にMFA認証を実装する方法もありますが、接続元ユーザを細かく指定できなかったりしますし、AzureADのログインページの認証方法が変わったときに対応できるのか不安なところがあります。

前提

基本的には前回の記事の応用です。

おおまかな構成

登場人物は3つ。

1)Linuxインスタンス(RADIUSクライアント)
2)NPSサーバ(RADIUSサーバ)
3)Active Directoryサーバ

  • LinuxインスタンスがNPSにRADIUS認証をしにいく。
  • NPSの許可ポリシーに合致したID/PASS(AD認証)の場合は、AzureADに認証要求を投げる。
  • 認証要求を受け取ったAzureADは事前に登録されたMFA設定にもとづき、モバイルデバイスなどにMFA認証要求を投げる。
  • 全ての認証が通れば、SSHログイン可。

おおまかな流れ

  1. NPSサーバの設定。(RADIUSサーバとして構築)
  2. LinuxインスタンスRADIUSクライアントとして動作するように設定。
  3. AzureADのMFA導入前に、認証ができるかテスト。
  4. NPSサーバにAzureADのMFA導入するためにNPS拡張エクステンションをインストール
  5. MFAが動作することをテスト

手順

今回の構成でMFAを構成した事例が他になさそうなので詳細に記載します。

NPSの設定

  1. RADIUSクライアントの設定
    f:id:atsuokun:20170222171138p:plain
    f:id:atsuokun:20170222172733p:plain
  2. RADIUSサーバーの設定(負荷分散タブはデフォルトのままなので割愛)
    f:id:atsuokun:20170222172248p:plain
    f:id:atsuokun:20170222172501p:plain
    f:id:atsuokun:20170222172906p:plain
    f:id:atsuokun:20170222173016p:plain
  3. 接続要求ポリシーの設定
    f:id:atsuokun:20170222174715p:plain
    f:id:atsuokun:20170222173418p:plain
    f:id:atsuokun:20170222173511p:plain
    f:id:atsuokun:20170222173620p:plain
    f:id:atsuokun:20170222173727p:plain
    f:id:atsuokun:20170222173815p:plain
    f:id:atsuokun:20170222173933p:plain
    f:id:atsuokun:20170222174015p:plain
    f:id:atsuokun:20170222174135p:plain
    f:id:atsuokun:20170222174224p:plain
  4. 下記状態になっていればOK。処理順序は1番目にする(認証を無視する/OKは表示されていてもされていなくてもOK)
    f:id:atsuokun:20170222174436p:plain
  5. もう一つ接続要求ポリシーを設定
    f:id:atsuokun:20170222174715p:plain
    f:id:atsuokun:20170222174900p:plain
    f:id:atsuokun:20170222174940p:plain
    f:id:atsuokun:20170222175024p:plain
    f:id:atsuokun:20170222175103p:plain
    f:id:atsuokun:20170222175130p:plain
    f:id:atsuokun:20170222175232p:plain
  6. 下記状態になっていればOK。処理順序は2番目にする。
    f:id:atsuokun:20170222175315p:plain
  7. ネットワークポリシーの設定
    f:id:atsuokun:20170222175418p:plain
    f:id:atsuokun:20170222175520p:plain
    f:id:atsuokun:20170222184526p:plain
    f:id:atsuokun:20170222175739p:plain
    f:id:atsuokun:20170222175850p:plain
    f:id:atsuokun:20170222175937p:plain
    f:id:atsuokun:20170222180041p:plain
    f:id:atsuokun:20170222180139p:plain
  8. 下記のような状態になっていればOK。処理順序は1番目にする。
    f:id:atsuokun:20170222180346p:plain

Linuxインスタンスの設定。

  1. 下記パッケージをダウンロード。 yum -y install gcc pam pam-devel make
  2. pam_radius_authモジュール(RADIUSクライアント化するためのモジュール)をwget
    wget ftp://ftp.freeradius.org/pub/freeradius/old/pam_radius-1.3.17.tar.gz
  3. ダウンロードしたモジュールを展開して、make。
    tar xvzf pam_radius-1.3.17.tar.gz
    cd pam_radius-1.3.17
    make
  4. makeが完了するとカレントディレクトリに「pam_radius_auth.so」が出来上がっているので、「 /lib64/security」配下にコピー。
    cp -p ./pam_radius_auth.so /lib64/security/
  5. /etc/pam.d/sshdを開き、authで始まるところをすべてコメントアウトする。
  6. 2行目(#%PAM-1.0と書いてあるところの次の行)に「auth sufficient pam_radius_auth.so」と追記する。
  7. /etc/raddb/serverに下記内容を記載する。
    <NPSサーバのIPアドレス> <NPSサーバで設定した共有シークレット> 60
    例:192.168.150.150 sharedkey 60
  8. sshdの再起動
    /etc/init.d/sshd restart

接続テスト

ターミナルをもう一つ立ち上げて、Linuxインスタンスに接続し、下記内容を確認。

  • NPSサーバで許可されたユーザだけがログインできている。
  • NPSサーバのイベントログ(セキュリティ)に認証拒否のログが出ていないこと。

NPS拡張モジュールのインストール

前回の記事の「NPS拡張モジュールのインストール」と同じなので割愛。

接続テスト

Linuxインスタンスに接続し、MFA認証が走ればOK!

最後に

意外なことに、LinuxRADIUSクライアントとして登録する手順があまり無いためそこに手間取りました。 今回はLinuxでしたがRADIUSが喋れる機器なら全てAzureのMFA認証が上記手順で実装できるかと思われます。

Amazon LinuxでオンプレミスADのユーザ情報を使ってログインする

AWS上のLinuxインスタンスでオンプレのAD認証をする必要に迫られたのでそのメモ。

参考にしたサイト

https://docs.microsoft.com/en-us/azure/active-directory-domain-services/active-directory-ds-admin-guide-join-rhel-linux-vm

http://jshimazu.hatenablog.com/entry/2014/02/05/165058

前提

LinuxインスタンスVPN接続でオンプレのADと接続可能な状態になっていること

手順

  1. Linuxインスタンスにログイン
  2. 必要なパッケージをインストール
    sudo yum -y install realmd sssd krb5-workstation krb5-libs
  3. DNS参照でオンプレADが見つからないといけないので、resolv.confを修正。(普通はADサーバのIPアドレスを指定すれば良いと思います。)
    vi /etc/resolv.conf
    nameserver <参照先DNSサーバ名> ※既存のnameserverの箇所はコメントアウトしておく
  4. AD参照できるか確認
    sudo realm discover <ドメイン名>
  5. kerberosの初期化
    kinit <ユーザー名>@<ドメイン名>
  6. ドメイン参加
    sudo realm join --verbose <ドメイン名> -U '<ユーザー名>@<ドメイン名>'
  7. デフォルトだとSSH接続が鍵認証なので、パスワード認証に変更する。
    sudo vi /etc/ssh/sshd_config
    PasswordAuthentication no の箇所を PasswordAuthentication yes に修正
  8. sshdの再起動
    /etc/init.d/sshd restart
  9. 以上

動作検証

対象のLinuxインスタンスSSH接続。そのとき、ユーザ名はUPN(‘<ユーザー名>@<ドメイン名>’)で、パスワードはADのものを使ってアクセス。 ログインできれば成功。

その他

管理者権限を与えたいユーザには/etc/sudoersを編集し、よしなにやってください。 グループに与える場合は「%<ドメイン名>\<グループ名> ALL=(ALL) ALL」とかすればOK

リモートデスクトップ接続でMFA認証(多要素認証)を実装。しかもクラウドベース(Azure Active Directory)のMFAで。

2/6にクラウドベースのMFA認証ができるようになったので試してみる。 #いままではAzure Multi-Factor Authentication Serverなるものをオンプレに構築する必要があった。かつ、その場合、Azure ADのMFAとは別ユーザ(オンプレ側のみ有効なユーザ)を作る必要があったので不便でした。

はじめに

参考にさせて頂いたサイトです。(感謝)

前提

接続に使用するユーザはAzure ADでMFA設定が済んでいるものとします。

構成

下記サーバが必要になります。

おおまかな手順

  1. Remote Desktop Gateway(便宜上、以降はRDPGWsvと記載します)の構築 & Let’s Encryptで証明書の作成(任意)
  2. Network Policy Server(便宜上、以降はNPSsvと記載します)の構築
  3. クラウドベースのAzure MFA認証を実装するまえに、オンプレだけで接続テスト
  4. NPS拡張モジュールのインストール(クラウドベースのAzure MFA認証に必要)
  5. 接続テスト

RDPGWsv(Remote Desktop Gateway)の用意

  1. 機能と追加からリモートデスクトップゲートウェイリモートデスクトップWebアクセスを選択。勝手にNPSとIISもインストールされるがそれも必要なのでインストール。(リモートデスクトップWebアクセスは要らないかも) f:id:atsuokun:20170214222711p:plain
  2. Let’s Encryptで証明書を作成。
    参考: http://atsuokun.hatenablog.com/archive/2017/02/12
  3. インストールが完了したらリモートデスクトップゲートウェイマネージャを起動。サーバ名を右クリックして「プロパティ」を表示。事前に作成した証明書をインポート(証明書を用意していない場合は自己証明書でもOK) f:id:atsuokun:20170214223924p:plain
  4. [RD CAPストア]にNPSsvのIPアドレスorホスト名を指定(NPSsvのIPアドレスを振っていない場合は振っておいてください。) f:id:atsuokun:20170214224152p:plain
  5. [SSLブリッジ]は下記図の通り。 f:id:atsuokun:20170214224220p:plain
  6. プロパティから抜けて、[リソース承認ポリシー]の編集。許可設定なのでよしなにやってください。下記はサンプル。 f:id:atsuokun:20170214224640p:plain
  7. 次はネットワークポリシーサーバの設定。※RDPGWsv側の設定です。NPSsv設定では無いので間違えないように。
  8. [RADIUSクライアント]は下記図のように設定。フレンドリ名/共有シークレットは任意。IPアドレスはNPSsvのものを指定。 f:id:atsuokun:20170215024607p:plain
  9. [リモートRADIUSサーバ]はデフォルトの設定から下記の赤枠の箇所を60秒に設定。(デフォルトだと短すぎてMFA応答が間に合わないため) f:id:atsuokun:20170215024811p:plain
  10. [接続要求ポリシー]は元々設定されている「TS GATEWAY AUTHORIZED POLICY」を2つ複製し、元々の「TS GATEWAY AUTHORIZED POLICY」自体は無効化する。 f:id:atsuokun:20170215025108p:plain
  11. 複製したポリシーのうち、一つを下記図のように設定する。ポリシー名は任意。クライアントのフレンドリ名は[RADIUSクライアント]で設定したものと同じにしください。※処理順序は1番目にしてください。 f:id:atsuokun:20170215025341p:plain
  12. 複製したポリシーのうち、もう片方を下記図のように設定する。こちらもポリシー名は任意。※処理順序は2番目にしてください。 f:id:atsuokun:20170215025544p:plain
  13. 最後に「NPS(ローカル)」を右クリックして、「Active Directoryにサーバーを登録を選択」 f:id:atsuokun:20170221223404p:plain

NPSsv(Network Policy Server)の用意

  1. 役割と機能の追加からネットワークポリシーサーバを選択。 f:id:atsuokun:20170215025721p:plain
  2. [RADIUSクライアント]は下記図のように設定。IPアドレスはRDPsrv。こちらもフレンドリ名/共有シークレットは任意。 f:id:atsuokun:20170215025927p:plain
  3. [リモートRADIUSサーバ]の設定を新規に作成。設定は下記図のように設定。グループ名は任意。 f:id:atsuokun:20170215030152p:plain
  4. [接続要求ポリシー]で設定を新規に作成。設定は下記図のように設定。ポリシー名は任意。クライアントのフレンドリ名は[RADIUSクライアント]で設定したものと同じにしください。※処理順序は1番目にしてください。 f:id:atsuokun:20170215030317p:plain
  5. [接続要求ポリシー]で設定をもう一つ新規に作成。こちらもポリシー名は任意。※処理順序は2番目にしてください。 f:id:atsuokun:20170215030424p:plain
  6. [ネットワークポリシー]の設定も必要なので設定。こちらも全体的に任意なのですが私が設定した内容をサンプルで下記図に貼ります。(制約タブは認証方法以外はデフォルトなので割愛。設定タブは全てデフォルトのままだったのでそこも割愛。) f:id:atsuokun:20170215030540p:plain f:id:atsuokun:20170215030619p:plain f:id:atsuokun:20170215030645p:plain
  7. 最後に「NPS(ローカル)」を右クリックして、「Active Directoryにサーバーを登録を選択」 f:id:atsuokun:20170221223404p:plain

Remote Desktop Gatewayが機能するかテスト

以上で、MFAしない状態の環境が構築できたのでMFAを実装する前に動作テスト。 ※この状態で動作しないとMFAも動作しないので必ずテストしてください。

  1. mstsc.exeを起動し、[任意の場所から接続する]の[設定]を選択。 f:id:atsuokun:20170215031025p:plain
  2. サーバー名にRDPGWsvのFQDNを入力、[ローカルアドレスにはRDゲートウェイサーバを使用しない]のチェックをはずす。
    f:id:atsuokun:20170215031224p:plain
  3. 以上の状態で任意の接続先に接続し、接続できることを確認。※もちろん接続先側でリモートデスクトップの設定が許可されていることが必要です。

NPS拡張モジュールのインストール

ここまできたらいよいよクラウドベースのAzure MFA認証の実装です。

  1. 下記3つをNPSsvで、上から順番にインストールする。
  2. 管理者権限でPowershellを起動。下記コマンドを入力。
    • cd “C:\Program Files\Microsoft\AzureMfa\Config”
    • .\AzureMfaNpsExtnConfigSetup.ps1
    • Directory IDを聞かれるのでAzure新ポータルを起動し、[Active Directory] - [Propertys] - [Directory ID]から値を取得し、入力。
    • 認証ダイアログがポップアップされるのでAzure ADの全体管理者のユーザID/パスワードを入力。

接続テスト

以上で構築完了なので、前述した手順と同じ通り、Remote Desktop Gateway経由でmstsc.exeから接続する。今度はAzure ADで設定されたMFA認証が走り、それを許可しないかぎり、リモートデスクトップ接続ができないことを確認する。

最後に

とても簡単にリモートデスクトップ接続にMFA認証を追加することができました。AzureAD最高! そしてAzureサポートの方が親切に教えてくれたのでそこまで困らずに構築できました。

ちなみにNPSが2つあるのは、NPS拡張モジュールをインストールしたサーバ側が強制的にAzure ADに認証をかけにいくようになってしまうので、オンプレ側の認証とクラウド側の認証を分ける必要があるためです。

あと、IISの設定が素のままなので、セキュリティが気になる方はよしなにいじってください。 (IISで頑張るんじゃなく、外部ファイアウォールかなんかで許可されたIP以外は接続しない、とかが無難なんじゃないかと。)

IISでLet's Encryptを使うときにどうやっても「The ACME server was probably unable to~」となってしまう場合

下記サイトのようにわかりやすい手順まで公開してくれているのに、ものすごく簡単なところではまったのでメモ。

IISでLet's Encrypt を利用してSSLサイトを構築する (letsencrypt-win-simple クライアントを利用)

Let's EncryptでIIS上にSSLサイトを導入する方法(無料) | Web備忘録

web.configの内容も正しくて、チャレンジファイル(Let’s Encryptがドキュメントルート配下に自動的に生成するファイル)にもURL直指定でも開ける、でもLet’s Encryptでは「The ACME server was probably unable to~」ってな感じでエラーになってしまう。

原因はHTTPSポートしか開けておらず、HTTPポートしか開けていなかったから。 下記URLが参考になりました。 The ACME server was probably unable to reach - Answer file is correctly rendered. · Issue #302 · Lone-Coder/letsencrypt-win-simple · GitHub

Let’s Encryptの公式サイトでも80/443ポート開けなさいって書いてあるのに、無視して進んだのではまりましたorz 書いてあることには素直に従いましょうorz

直近で使用しているユーザに対して、リモートデスクトップ接続を許可する

サポート対応するために、PCを使用しているユーザの権限でリモデすることがあるのですが、いちいち 各PCのリモートデスクトップ接続を許可するユーザ一覧に「ドメイン名\ユーザ名」を入力するのが面倒だったのでスクリプト化。 下記をグループポリシーにでもつっこめば、直近で使用したユーザ名をひろって、リモートデスクトップ接続を許可するユーザ一覧に追加してくれる。

# C:\usersから、更新日付が一番新しいユーザ名を取得。
$getLastUsedUserProperty = Get-ChildItem C:\Users | Sort-Object -Property LastWriteTime -Descending | Select-Object -First 1
# ドメイン名\ユーザ名の形式に変換。
$getLastUsedUserDomainName = "<ドメイン名>\" + $getLastUsedUserProperty.Name

# リモートデスクトップ接続を許可する一覧に追加。
net localgroup "Remote Desktop Users" $getLastUsedUserDomainName /add

ADFS構築時のメモ

Windows Server 2012 R2でADFSの構築試験をしたときに参照したURLのメモ(自分用)

Windows Server 2012 R2を使ってiOSだけがOffice365にアクセスできるようにする(1) | Always on the clock →サービスアカウントはEnterpriseAdminユーザで登録した。

Windows Server 2012 R2によるADFS構築 | 日々徒然

Windows Server 2012 R2を使ってiOSだけがOffice365にアクセスできるようにする(2) | Always on the clock

Windows Server 2012 R2を使ってiOSだけがOffice365にアクセスできるようにする(3) | Always on the clock