Azure AD ハイブリッドAD joinとSSOの実装

■目的
AADjoinデバイス、HybridADjoinデバイスにてsSSO(シームレスSSO)を有効にする

■必要設定
ユーザプロビジョニング等の初期設定は実装済の想定

・AADC
 -デバイスオプションにてHybrid AD join有効化
 -同期オプションにてデバイスのをjoin有効化
 -ユーザサインインオプションにてSSO有効化
・GPOでMSwebサイトをイントラネット判定に
・FW設定
 -AADC→オンプレAD
 -AADC→AAD
 -クライアント→AAD
※プロキシ環境の場合は、イントラゾーン登録Webサイトのみ許可
 
■FWルール設定詳細
・AADC→オンプレAD
・AADC→AAD
https://learn.microsoft.com/ja-jp/azure/active-directory/hybrid/reference-connect-ports

・クライアント→AAD
https://learn.microsoft.com/ja-jp/azure/active-directory/devices/howto-hybrid-azure-ad-join

https://learn.microsoft.com/ja-jp/azure/active-directory/hybrid/tshoot-connect-connectivity

■イントラ判定
https://learn.microsoft.com/ja-jp/azure/active-directory/devices/howto-hybrid-join-downlevel

ここに記載のURLに加えてonmicrosoft等のSWGベンダー指定のバイパス除外ドメインも?
これらはプロキシバイパスされる

Azure ADの種類

■Azure ADとは
クラウドベースのディレクトリサービス
オンプレミスADとの連携が取れるのが特徴

■Azure ADを利用するケース
・Azure AD registered:AADにユーザが登録されている、端末はドメイン参加していない
・Azure AD joined:AADにユーザが登録されている、端末はドメイン参加している
・Hybrid Azure AD joined:AAD/オンプレADに共通のユーザが登録されている、端末は両方のドメインに参加している

■各ケースの特徴
・Azure AD registered
-○メリット
IDaaSとしてAzure AD使うだけなので、端末がドメイン参加する形ではなく端末側設定が不要
Windows以外のデバイスでも利用可能

-●デメリット
オンプレミス側のユーザ管理は別途AD等(ディレクトリサービス)が必要となる
※ユーザ情報自体はオンプレADからプロビジョニング可能

個人利用等でオンプレにADが必要ない場合はこれでも十分

・Azure AD joined
-○メリット
オンプレADを持たない企業でもディレクトリサービスとして利用できる
SSOができる(クラウドサービスのみ)

-●デメリット
インターネット接続がない環境では利用不可
オンプレAD等と併用する場合はIDが二重管理になる

オンプレにADが無くディレクトリサービスを利用したい場合はこの選択肢おあり

・Hybrid Azure AD joined
-○メリット
オンプレADのユーザでAzure ADの機能も使えるようになる
SSOができる(クラウドサービス/オンプレリソース両方)

-●デメリット
オンプレおよびAzure AD Connect + 各種設定が必要

環境構築の手間はあるが、利便性では圧倒的にこれ

RIPv2の自動経路集約(Auto Summary)について

RIPv2の動作検証をしていた際に想定と違う動作をしたため
その時に調べた内容や検証した内容についてのメモです。

概要

RIPv2はデフォルトで自動経路集約(Auto Summary)が有効になっているが、
ある条件の経路については集約されなかった。

ざっくり構成図

各機器Config

router1

router2#sh run
interface GigabitEthernet0
ip address 172.16.1.1 255.255.255.0

interface Vlan11
ip address 10.1.1.254 255.255.255.0
!
interface Vlan12
ip address 10.1.2.254 255.255.255.0
!
interface Vlan172
ip address 172.16.2.254 255.255.255.0
!
interface Vlan173
ip address 172.16.3.254 255.255.255.0
!
interface Vlan191
ip address 192.168.1.254 255.255.255.240

router rip
version 2
redistribute connected
network 172.16.0.0

router2

router2#sh run
interface GigabitEthernet0
ip address 172.16.1.2 255.255.255.0

router rip
version 2
network 172.16.0.0

各機器ルーティングテーブル

router1

router1#sh ip route
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C 10.1.1.0/24 is directly connected, Vlan11
L 10.1.1.254/32 is directly connected, Vlan11
C 10.1.2.0/24 is directly connected, Vlan12
L 10.1.2.254/32 is directly connected, Vlan12
172.16.0.0/16 is variably subnetted, 6 subnets, 2 masks
C 172.16.1.0/24 is directly connected, GigabitEthernet0
L 172.16.1.1/32 is directly connected, GigabitEthernet0
C 172.16.2.0/24 is directly connected, Vlan172
L 172.16.2.254/32 is directly connected, Vlan172
C 172.16.3.0/24 is directly connected, Vlan173
L 172.16.3.254/32 is directly connected, Vlan173
192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.1.240/28 is directly connected, Vlan191
L 192.168.1.254/32 is directly connected, Vlan191

router2

router2#sh ip route
R 10.0.0.0/8 [120/1] via 172.16.1.1, 00:00:04, GigabitEthernet0
172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks
C 172.16.1.0/24 is directly connected, GigabitEthernet0
L 172.16.1.2/32 is directly connected, GigabitEthernet0
R 172.16.2.0/24 [120/1] via 172.16.1.1, 00:00:04, GigabitEthernet0
R 172.16.3.0/24 [120/1] via 172.16.1.1, 00:00:04, GigabitEthernet0
R 192.168.1.0/24 [120/1] via 172.16.1.1, 00:00:04, GigabitEthernet0

10.x.x.xと192.168.1.xについては経路集約されているが、
172.16.2.0と172.16.3.0は経路集約がされなかった。
この動作についてはCiscoのドキュメントにて説明されている
https://www.cisco.com/c/dam/global/ja_jp/td/docs/ios-xml/ios/iproute_rip/configuration/xe-16/irr-xe-16-book.pdf

RIP Version 2 は、デフォルトで自動ルート集約をサポートしています。クラスフル ネットワーク
境界を越えるとき、サブプレフィックスはクラスフル ネットワーク境界に集約されます。

クラスレス、クラスフルとは

クラスレスネットワーク:先頭3ビットでネットワーク部とホスト部を区別する
クラスフルネットワーク:CIDR表記(IPアドレス/サブネットマスクの1個数)でネットワーク部とホスト部を区別する

debugログ

debugログを見ても172.16.2.0と172.16.3.0は経路集約されずに広告/学習されています。
広告学習するI/Fと同一クラスフルネットワーク内のルートについては
経路集約されていないことがわかりました。
router1#
*May 4 10:44:53.699: RIP: sending v2 update to 224.0.0.9 via GigabitEthernet0 (172.16.1.1)
*May 4 10:44:53.699: RIP: build update entries
*May 4 10:44:53.699: 10.0.0.0/8 via 0.0.0.0, metric 1, tag 0
*May 4 10:44:53.699: 172.16.2.0/24 via 0.0.0.0, metric 1, tag 0
*May 4 10:44:53.699: 172.16.3.0/24 via 0.0.0.0, metric 1, tag 0
*May 4 10:44:53.699: 192.168.1.0/24 via 0.0.0.0, metric 1, tag 0
router2#
*May 4 08:54:47.099: RIP: received v2 update from 172.16.1.1 on GigabitEthernet0
*May 4 08:54:47.099: 10.0.0.0/8 via 0.0.0.0 in 1 hops
*May 4 08:54:47.099: 172.16.2.0/24 via 0.0.0.0 in 1 hops
*May 4 08:54:47.099: 172.16.3.0/24 via 0.0.0.0 in 1 hops
*May 4 08:54:47.099: 192.168.1.0/24 via 0.0.0.0 in 1 hops

結論

RIPv2がRIPデータベースのクラスフル境界内に複数のサブプレフィックスを持ち、
同じクラスフル境界内のサブプレフィックスを所有するインターフェイスからアップデートを送信する場合、
RIPv2は自動経路集約(Auto Summary)を実行しません。

無線用語(EIRP、RSSI、SNR)と電波強度の目安

概要

無線用語(EIRP、RSSI、SNR)の説明と快適な無線利用環境の目安の数値について

各用語

dbm(デシベルミリワット)
信号強度の単位
0dBmに近いほど(数値が高いほど)優れた信号

EIRP(Equivalent Isotropic Radiated Power)
実効等方輻射電力、簡単に言うと電波集力機器側の送信信号強度
Arubaの無線コントローラの場合はdbm単位で設定が可能
APごとのMAX値はAP135は21.5、AP325は27.0、AP515は30.0。

EIRP27だと建物Aの無線APへ建物Bで接続できることを確認できた。
※2.4GHzで直線距離は60m程

EIRP6でも同一フロアの壁に設置してあるAPから反対側の壁側で接続できることを確認できた。
※5GHzで直線距離は20m程

RSSI(Received Signal Strength Indicator)
受信信号強度、クライアント側のWi-Fiアナライザ等で確認できる。
——————————————————————————————————————————-
-67 dBm Very Good Minimum signal strength for applications that require very reliable, timely delivery of data packets. VoIP/VoWi-Fi, streaming video
-70 dBm Okay Minimum signal strength for reliable packet delivery. Email, web
———————————————————————————————————–
※下記サイトより引用、metageek社はサイトサーベイなどで使うスペクトラムアナライザのメーカ
https://www.metageek.com/training/resources/understanding-rssi/#:~:text=RSSI%20vs%20dBm,levels%20in%20mW%20(milliwatts).

SNR(Signal-to-Noise Ratio)
信号対雑音比 (RSSI – ノイズ他電波の信号強度) ※同一帯域のSSIDごとにSNRは計算できる
そのAPからみたときに同一チャネルを使ってる他電波との雑音比、大きい方が干渉が少ない
——————————————————————————-
25dB to 40dB SNR = Very good signal (3 – 4 bars); always associated; very fast.
——————————————————————————-
※下記サイトより引用、Ciscoが買収したNW機器メーカ(meraki)が引用している記事
http://www.wireless-nets.com/resources/tutorials/define_SNR_values.html

結論

ビデオストリーミング等を快適に見るためには、無線利用場所において下記2つの条件を満たしていること
・「利用するSSIDから受信する電波(RSSI)が強い」
RSSI:利用するSSIDのRSSIが-67 dBm 以上
・「同一周波数を利用する強い電波(SNRが低い)SSIDが存在しない」
SNR :同じ周波数を使用するSSID(特に同一チャネル)で25 dB 以下のSSIDが存在しない

※利用する電波や付近の電波の強度(RSSI)を計算するにはスマホは「Wi-Fi Analyzer」PCは「inSSIDer」等のフリーソフトで確認可能
SNRはRSSIを元に計算可能

letsencryptの更新メモ

/opt/bitnami/ctlscript.sh stop apache
rm -R /tmp/letsencrypt/
mkdir /tmp/letsencrypt/
cd /tmp/letsencrypt/
git clone https://github.com/letsencrypt/letsencrypt
cd /tmp/letsencrypt/letsencrypt
/opt/bitnami/ctlscript.sh start apache
./letsencrypt-auto renew
cp /etc/letsencrypt/live/wannabe-engineer.com/privkey.pem /opt/bitnami/apache2/conf/server.key
cp /etc/letsencrypt/live/wannabe-engineer.com/fullchain.pem /opt/bitnami/apache2/conf/server.crt
/opt/bitnami/ctlscript.sh restart apache

OpenVPNを使ってクライアントVPNを構築

何をするか

外出先のインターネットからクライアントVPNを使って自宅NWに接続する。

OpenVPNサーバの構築

必要なパッケージをインストール

作業ディレクトリを作成してコピーして移動。

CA(認証局)の初期化。

CA(認証局)を作成。

CA秘密鍵のパスワードが聞かれるので任意のパスワードを入力。

処理が完了すると以下のファイルが作成される。

DH(Diffie-Hellman)パラメータの生成。

サーバ用秘密鍵、証明書の作成
※nonpassオプションをつけるとパスフレーズを省略できる。

クライアント用証明書、秘密鍵の作成
※nonpassオプションをつけるとパスフレーズを省略できる。

CA秘密鍵のパスワードが聞かれるのでパスワードを入力

処理が完了すると以下のファイルが作成される。
サーバ用証明書:client_1.crt
サーバ用秘密鍵:client_1.key

OpenVPNのテンプレコンフィグをコピー。

メインの設定ファイルを編集。

vpnux Clientの設定

vpnux Clientを起動して「プロファイル」→「追加」を押下する。
■一般設定
プロファイル名:任意
VPNサーバ:OpenVPNサーバのグローバルIP
デバイス:TUN
拡張設定:[LZO圧縮を有効にする]をチェック
CA証明書:「ca.crt」を選択
認証:「証明書認証(PKI)を使用」を選択
証明書認証(PKI)/証明書:「client1.crt」を選択
証明書認証(PKI)/秘密鍵:「client1.key」を選択
■詳細設定
追加セキュリティ設定:「TSL-Auth HMAC署名を使用」をチェック
追加セキュリティ設定/共有鍵:「ta.key」を選択

ログからのトラシュー

暗号方式を大文字で記載していた。
cipher AES-256-CBC → cipher aes-256-cbc
Fri May 15 10:44:27 2020 TLS Error: cannot locate HMAC in incoming packet from [AF_INET]61.86.178.47:1194

プロトコルのipv4の指定が抜けていた。
udp → udp4
Fri May 15 10:37:02 2020 Could not determine IPv4/IPv6 protocol. Using AF_INET

CentOS7のサーバ構築でうまくいかない時の共通確認事項

サーバを構築する際にいつも忘れてしまうところ。

・SELINUXの無効化
状態確認
getenforce

永久的に無効化
vi /etc/selinux/config
—-
SELINUX=enforcing
—-

・FWの無効化
状態確認
systemctl status iptables
systemctl status firewalld

停止(再起動すると復活する)
/etc/init.d/iptables stop
systemctl stop firewalld

・それでも無理な場合
サービスの状態確認、エラーの場合は問題箇所も表示される
systemctl status [サービス名]

エラーログ確認
vi /var/log/[ログファイル]
jounalctl

(zabbix)Template OS Linux内のデフォルトのアイテムとその表示例

zabbixサーバって構築した後も監視項目のチューニングとか大変そう、と思っていたのですがデフォルトで存在するテンプレート「Template OS Linux」で一般的な監視項目(アイテム)は既に入っていたので「Template OS Linux」内の監視項目を整理します。

zabbixサーバ、エージェントのバージョンは「3.4.15」

※右側は監視している値の表示例
■General セクション
Host boot time : 2020/4/11 7:21:16
Host local time : 2020/5/13 15:14:21
Host name : ip-172-131-49-55
System information : Linux ip-172-131-49-55 4.4.0-1105-aws #112-Ubuntu SMP Wed Mar 18 05:11:57 UTC 2020 x86_64
System uptime : 32 days, 07:50:10

■Memory セクション
Available memory : 488.09 MB
Free swap space : 436.63 MB
Free swap space in % : 68.79%
Total memory : 990.65 MB
Total swap space : 634.76 MB

■Network interfaces セクション
Incoming network traffic on eth0 : 1.46 Kbps
Outgoing network traffic on eth0 : 2.51 Kbps

■OS セクション
Host boot time : 2020/4/11 7:21:16
Host local time : 2020/5/13 15:19:21
Host name : ip-172-131-49-55
Maximum number of opened files : 99246
Maximum number of processes : 32768
Number of logged in users : 1
System information : Linux ip-172-131-49-55 4.4.0-1105-aws #112-Ubuntu SMP Wed Mar 18 05:11:57 UTC 2020 x86_64
System uptime : 32 days, 07:50:10

■Performance セクション
Context switches per second : 86 sps
CPU idle time : 99.9%
CPU interrupt time : 0%
CPU iowait time : 0%
CPU nice time : 0%
CPU softirq time : 0%
CPU steal time : 0.02%
CPU system time : 0.02%
CPU user time : 0.07%
Interrupts per second : 47 ips
Processor load (1 min average per core) : 0
Processor load (5 min average per core) : 0
Processor load (15 min average per core) : 0

■Processes セクション
Number of processes : 129
Number of running processes :  1

■Security セクション
Checksum of /etc/passwd : 4980275739
Number of logged in users : 1

■Zabbix agent セクション
Agent ping : Up (1)
Host name of zabbix_agentd running : WebServer
Version of zabbix_agent(d) running : 3.4.15

KVMからVMwareWorkstationに移行する

何をするか

KVM上で動かしている仮想マシンのイメージファイルをWindowsマシン上のVMwareWorkstationで使えるように変換して使用する。

qemuマシン側

qemu-imgをインストールする。

qemuの仮想マシンのイメージがある場所に移動する

イメージの変換を行う。

上記のコマンドで出来たvmdkファイルをWinSCPなどで取り出す。

Windowsマシン側

VMwareWorkstation上で仮想マシンを動かすには「vmdkファイル」と「vmxファイル」が必要なので、フリーツールの「vmxMaker」をダウンロードする。

仮想マシンのディスク(vmdk)やメモリ容量、OSの種類等を選択して「vmxファイル」を作成する。

VMwareWorkstationの仮想マシンを開くから「vmxファイル」を選択して仮想マシンを起動する。