先日投稿した、Azure AD の証明書ベースの認証 (CBA) をスマートカードで検証する環境を準備してみる では 証明書失効リストの配布ポイント (CDP) の構成は行っていなかったのですが、CDP を構成してみたので情報を残しておきたいと思います。
Azure AD の証明書ベースの認証 (CBA) をスマートカードで検証する環境を準備してみる
投稿を書いている時点ではプレビュー機能となりますが、Azure AD では証明書ベースの認証 (CBA) を使用するkとができるようになりました。
CBA を使用したログインの基本的な流れについては Azure AD 証明書ベース認証を試してみた がとても参考になり、基本的な作業の流れはこの記事を確認しておけば問題ないのですが、物理デバイスと組み合わせた場合にはどのようになるのかを検証する必要があり、検証環境を作ってみました。
今回使用しているベースの環境は次のようになります。
- 使用している Azure Active Directory
- Microsoft 365 開発者プログラム で作成した Azure AD テナント
- AAD Premium P2 が使用でき、普段使用している AAD を操作しなくて済むので検証に便利
- Azure AD Connect をインストールし、AD と AAD を同期
- AD CS の役割も合わせて導入
- 証明機関の証明書を AAD の CBA の証明書として設定
- T440s が手元にあったので Windows 10 Pro をクリーンインストールして使用
- CPU / TPM が古くて、残念ながら Windows 11 がインストールできない…
Azure AD 証明書ベース認証を試してみた で解説されている証明書を使用した認証については、AD CS を展開して「ユーザー」の証明書テンプレートを使用してドメインユーザーで証明書を作成することで、CBA の認証をすることができますので、その環境を構築してから検証を実施しています。
今回は証明書の失効については検証していないので、証明書失効リスト (CRL) の配布ポイント (CDP) については構築せずに検証しています。(CDP については、Azure BLOB ストレージを匿名アクセス許可でファイルを公開することでもできるのかなと思いつつ検証していません)
2022年8月下旬の Azure SQL Database Update と SQL Server Update
2022 年 8 月下旬の Azure SQL Database Update がアナウンスされ、それ以外にもいくつかのアップデートが発表されましたのでまとめておきたいと思います。
Azure SQL Database に関連するアナウンスは以下を参照してください。
SQL Server Standard Edition のメモリリソースの制限を Express Edition で確認する
SQL Server は SQL Server 2016 SP1 からエディション間の機能差が緩和され、従来までは Enterprise Edition でしか使用できない機能の一部が、空以外のエディションでも利用できるようになりました。
また、SQL Server 2014 / SQL Server 2016 では、Standard Edition で使用可能なハードウェアリソースについても上限が緩和されました。
- SQL Server 2014
- メモリサイズ: 64 GB -> 128 GB
- SQL Server 2016
- CPU コア数: 4 ソケットまたは 16 コアのいずれか小さいほう -> 4 ソケットまたは 24 コアのいずれか小さいほう
- 以降、投稿を書いている時点で GA している最新バージョンの SQL Server 2019 まで同一のリソース上限です
SQL Server 2012 では、次のようになっていました。
- CPU コア数: 4 ソケットまたは 16 コアのいずれか小さいほう
- メモリサイズ: 64 GB
最新の SQL Server にすると、ハードウェアリソースの上限もだいぶ変わりますね。
2012 ～ 2016 までのサポート機能は次の情報から確認することができます。
- SQL Server 2012 の各エディションがサポートする機能
- Features Supported by the Editions of SQL Server 2014
- SQL Server 2016 の各エディションとサポートされている機能
SQL Server 2012 から最新の SQL Server に移行する場合、Standard Edition でも使用可能なリソース / 機能が増えているため、現行は Enterprise を使用していても移行後は Standard を使用するという選択肢をとることもあるのではないでしょうか。
Standard を使用する場合、よく聞かれる質問が「128 GB 以上のメモリを搭載していて意味があるか？」というものです。
SQL Server が使用するメモリと OS / SQL Server 以外のアプリケーションが使用するメモリを考慮すると、128 GB 以上のメモリを踏査することの意義は十分にあるのですが、実際に SQL Server Standard Edition でどの程度メモリが使用できるのかの実際の値をとることについては、128 GB を超えるメモリを搭載している環境の準備が難しいので実施してはいませんでした。
メモリリソースの制限ですが、Express Edition でもサイズは異なりますが、上限が設定されています。
- メモリサイズ: 1,410 MB
Standard Edition の上限を超えるメモリの環境を用意できなくても Express Edition の 1.4 GB のメモリ制限がどのように動作するかを確認することで、Standard Edition のメモリ制限がどのように動作するのか把握することができます。
詳細な情報については、次の技術情報を確認してください。
現在の SQL Server のドキュメンでは最大メモリは「インスタンスごとのバッファプールの最大メモリ」という記載になっており、過去のバージョンの SQL Server では、異なる記載になっていますが、これは、
The memory consumed by caches outside buffer pool is not restricted by above memory limits and can grow up to limits defined by "max server memory". This is not specific to SQL Server 2016 SP1 and is also applicable to earlier releases of SQL Server as well.
となっており、基本的な考え方はそれより前のバージョンの SQL Server も同様となります。(表現方法が変わっただけで動作は同一)
Microsoft.Data.SqlClient 4.0 以降で SQL Server に接続する際の暗号化オプション
先日、Microsoft.Data.SqlClient 5.0 がリリースされました。
新機能については、次の情報からも確認することができます。
4.0 の破壊的変更に含まれるのですが、4.0 以降は接続文字列の「Encrypt」が「true」に設定されることがデフォルトとなりました。
これにより、オンプレミスの SQL Server のような環境では、4.0 より前と同一の接続文字列で接続を行うと「 信頼されていない機関によって証明書チェーンが発行されました。」のエラーが発生する可能性があります。(Azure の PaaS については、信頼されている証明書による接続になっているので、PaaS を使っている場合は、本投稿は意識しないでもよかったはずです)
今回は、Windows PowerShell に Microsoft.Data.SqlClient 5.0 を使用できるようにして、この暗号化接続部分について動作を確認してみました。
Windows PowerShell で Microsoft.Data.SqlClient 5.0 を使えるようにするのは面倒ですが、動かしてみたい方は Microsoft.Data.SqlClient 5.0.0.ps1 を実行してみてください。
Windows Server BMR バックアップでリストアする際のメモ＋α
UEFI 環境の Windows Server バックアップのリストアについて調べることがあったので、その際のメモを残しておきたいと思います。
.NET Data Provider for SQL Server の ConnectRetryCount をサポートする SQL Server のバージョン
.NET Framework 4.6.1 is now available! でアナウンスされた内容となりますが、現在の System.Data.SqlClient や Microsoft.Data.SqlClient には、ConnectRetryCount というオプションが追加されており、接続文字列で再接続の回数を調整することができるようになっています。
サポートされるバージョンについては、
等に記載されているのですが、SQL Server 2014 以降または、Azure の PaaS の SQL Server ベースの環境でサポートされる機能となります。
リトライについては、ライブラリ側で実装されていると思うのですが、SQL Server のバージョンがどのように ConnectRetryCount に再接続と関係しているか、把握できていなかったので、軽く調べてみました。
Azure Policy の評価タイミングの情報について
Azure Arc を導入することで、Azure Policy をオンプレミスの環境でも使用することができるようになります。
Policy の割り当てや解除をすると、次のようなメッセージが表示され、変更が有効になるまで 30 分程度時間がかかることが表示されます。
評価の間隔にはいくつかの待機時間のパターンがあるようなので、情報を残しておきたいと思います。
ドキュメントレベルで確認をしており、Arc エージェントの実際のログからの確認は行っていません。
SQL Server 2022 Release Candidate 0 (製品候補版) がリリースされました
本日、SQl Server 2022 Release Candidate (RC: 製品候補版) 0 (16.0.900.6) がリリースされました。
RC は、製品候補版となり、RTM に向けての対応が着々と進められていますね。
追加された機能については Release candidate に記載されており、大きな機能追加はないのですが、いくつかの機能改善が追加されています。
RC 0 の改善点については、次のドキュメントを参照。
SQL Server on Azure Arc 対応サーバーを Azure Policy で導入する
SQL Server 2022 では、セットアップ時に SQL Server on Azure Arc 対応サーバーをインストールすることができるようになり、セットアップで Azure Arc ならびに SQL Server 向けの拡張機能をインストールした状態でオンボードすることが可能となりました。
SQL Server 2022 より前のバージョンの SQL Server についても Azure Arc に接続がされていれば、Azure Policy 経由で SQL Server on Azure Arc 対応サーバーを導入することができ、導入の自動化につなげることができますので、本投稿では Azure Policy を使用した Windows サーバーへの SQL Server on Azure Arc 対応サーバーの導入を実施してみたいと思います。
作業内容としては、Azure Policy を使用した大規模な接続 になります。