らくだ

とあるWeb会社で情シスやってます

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でオンプレミス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 '<ユーザー名>@<ドメイン名>' ubuntuの場合は上記に--install=/も追記する。
  7. デフォルトだとSSH接続が鍵認証なので、パスワード認証に変更する。
    sudo vi /etc/ssh/sshd_config
    PasswordAuthentication no の箇所を PasswordAuthentication yes に修正
    AuthorizedKeysFile の箇所をコメントアウト
    PubkeyAuthentication の箇所を PubkeyAuthentication no に修正
  8. ADが死んでしまったとき用にec2userだけは証明書認証をできるようにする。
    sudo vi /etc/ssh/sshd_config 下記2行を追記
    Match User ec2-user
    PubkeyAuthentication yes
  9. AmazonLinuxの場合、インスタンス再起動時にsshdが鍵認証に戻されてしまうのでそれを無効化。
    sudo vi /etc/cloud/cloud.cfg.d/00_defaults.cfg
    ssh_pwauth: false の箇所を ssh_pwauth: true に修正。
  10. sshdの再起動
    /etc/init.d/sshd restart
  11. 以上

動作検証

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

その他

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

その他2(2017.6追記)

ログインする際に@<ドメイン名>でログインするのが面倒なときは /etc/sssd/sssd.confに下記修正を加えればOK。

  1. [sssd]セクションに default_domain_suffix = <ドメインサフィックス(@以降のところ)>

  2. use_fully_qualified_names をコメントアウト

  3. systemctl restart sssd でSSSDを再起動。 参考にしたURL:

ubuntu - SSSD Authentication to Windows Domain without @domain.com everywhere - Server Fault

リモートデスクトップ接続で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