序章：一寸にも足らない戯言
マイクロソフトの策略、というか、RDSCALの管理を厳密にする目的によってRDSを構築する場合は、ADサーバが必須と言うこれまた不可解な状況になってしまっている。これは、ライセンスの不正利用をしていたユーザが後を絶たない事から、マイクロソフトが自衛手段に出たのだろうとは容易に想像が付く。以前にも記事を起こしていたが、ADを構築する必要のない小規模の環境でも、この”たいそう”なADサーバの構築を余儀なくされるといったまったく迷惑極まりない現状に歯ぎしりをしながら耐えている。
ひと昔前、自動車のエンジン修理でも、長距離走ったエンジンのシリンダー摩耗をリカバリする為にボーリングし、メーカーが用意している”オーバーサイズピストン”を組み込む事でまた新車のようにエンジンを再生、利用する事ができていた。だが、どっかの馬鹿チューナーが馬力アップ、ボアアップの為だけにそのオーバーサイズピストンを多用した為、メーカーが供給を停止し、本当にエンジンの再生をしたい業者や長く乗りたいユーザがピストンを仕入れなくなったという大迷惑な話とよく似ている。
今だからSDGsと言う話が出来るが、メーカーもメーカーで、対策といえども供給を停止するという持続可能な製品づくりには程遠い体制を取るのは如何なものかとも思う。このRDS構築も、作業効率や生産性を下げるこの現実を把握できているのだろうかと問いたい。
このサインイン方法は利用できません。
その”たいそう”な施しをサーバに行い、その他色々な設定も済まし、確認の為に再ログオンしようとすると、「このサインイン方法は利用できません。詳しくは、ネットワーク管理者に問い合わせ下さい。」というメッセージ。
他に設定したユーザログインでも同じ症状。ならばと、メンバーサーバーのRDSサーバからリモートでログインしようかと思ったが、それもダメ。
原因調査モードに頭を切り替える。というか、直前に行った設定を思い起こすと、グループポリシーの設定をしたことが思い当たる。何をしたかというと、グループポリシーのローカルログオンを許可の設定だ。
もしやと思い、まだグループポリシーが反映されていないメンバーサーバからrsop.mscコマンドを使って、グループポリシーの結果セットを見てみたら、しっかりローカルログオンを拒否の設定を有効にしてしまっている。
拒否と許可の設定は縦に並んでおり、老眼の私は、よく見ないで下の”拒否”をクリックして設定してしまったのだ。
何という失態。
ドメインのグループポリシー設定
RDSユーザに対して、RDSログインの許可をさせる方法の一つとして、グループポリシーのローカルログオンを許可する設定がある。
ADでなければ、夫々のリモートデスクトップ接続許可を行う所だが、ADのメリットを生かすべく、ADのグループポリシーのローカルログオンを許可設定を利用する。同じく、その設定の真上に逆の意味のローカルログオンを拒否という設定がある。通常は、許可側にDomain Users等、利用するユーザを指定するのだが、衰えた私のこの目の節穴が、間違って拒否側に設定を行ってしまったという訳。
一発アウト
当然、Domain Usersなので管理者どころか、だれもログイン出来ない事になる。しかも、各サーバ個別のリモートデスクトップ利用許可の代わりに施した設定なので、当然個別の利用許可はしていない。だからリモートからのログインもできない。
足掻いてみた事
- dcgpofix /target:ドメイン名
グループポリシーをデフォルトに戻すコマンドだが、そもそもドメインコントローラから行うコマンドなので、メンバーサーバからであれば当然ながら失敗する。 - POWERSHELLでグループポリシーを編集
Add-WindowsFeature GPMCでモジュールをインストール、その後、Import-Module -Name grouppolicyで値を取得しようとするが権限が無いのか失敗する。 - Import-Module GroupPolicyの後、関連コマンド実施
同じく権限がないので失敗する。 - gpedit.msc /gpcomputer:”ADサーバ名”
取得できるが、ローカルのグループポリシーであり、ドメインではない。 - リモートデスクトップ接続
リモートデスクトップ接続許可をしていないので接続不可。 - コンピュータの管理からADサーバに接続してどうにかする。
どうにもならない。 - サーバ筐体に斜め60度の角度で空手チョップをかます。
のび太のママさんがテレビを直している訳じゃない。
ああ無常の再セットアップ
この設定は、例えるなら車のインキーと同じ。車のインキーなら開錠屋さんに頼めば何とかなる場合がある（最近の車は駄目かな？）が、このADサーバでのインキー開錠は100％不可能。設定を行ってから、ご丁寧にgpupdate /forceコマンドまで叩いたもんだから取り返しがつかない。
暫くすると、反映されていなかったグループポリシーも、RDSメンバーサーバに反映されてしまい、ドメインメンバーとして同じくログインできない状況に陥る。
※ローカルユーザは勿論ＯＫだがADサーバに対しては何もできない。
これらのセキュリティーを潜り抜け、所謂セキュリティーホールを見つけログインしてしまう事をハッキング、ハッカーと言うのだが、私には当然無理な訳で。
藁をもつかむ思いでマイクロソフトにも確認してみたが、無常にも方法はないとの回答だった。マイクロソフトも、「実はこうすればログインできます」というような、セキュリティーホールを自ら公表する事はできないだろうし。
この回答を聞いて観念し、あえなくリセットとなった。まだ納品、運用前だったから良かったものの、これが運用後だったと思うとぞっとする。
こんな危ない設定ができるポリシーがあるのであれば、ユーザ削除と同様、設定前にフェールセーフ機能で警告でも出してくれてもいいものなのだが、何もなくあっさり設定できてしまう。サーバ設定は夫々リスクがあり、勿論自己責任ではあるものの、セーフティロックのない地雷のような、あまりにも簡単に爆発する仕掛けがあると思わざるを得ない。
なので、この設定は絶対やっちゃ駄目。
と自分自身に教訓として深く刻み込ませた。
というか、なんの役にも立たない恥さらし記事でした。
コメントを残す