ゼロトラスト時代のMacServer(Profile Manager)とJamf proとMS(AD)との関係

 とりあえずは、これの通りだと感じた。

https://blog.animereview.jp/macos_in_to_the_azuread/

そして、

私的な推奨構成

＜オンプレミス＞

ADDS－ Jamf Proー　Mac

＜クラウド＞

Azure　－　Mac

若しくは

Azure　－　Jamf Connect　－　Mac

 さて、MacServer(Profile Manager)とJamf proの関係ですが

MacServer(Profile Manager)ではダメなのか？というと

MacServer(Profile Manager)はAD連携(参照)はMacの認証とログインのみとして利用できる。

 Jamf proはMDMまでできる。

また、Appleはサーバーについては他で統合していきたいと考えているようだ。

証拠にappleではHWとしてのサーバーは消え、Jamf proがさもApple製品のようにappleのページに記載されている。

そして、いつMacServer(Profile Manager)は消えるか分からないからMSやJamf proを使用していく方がハシゴを外されずに済むとみんなは考えているようだ。

海外の方々もそう考えているようだ。

https://www.jamf.com/jamf-nation/discussions/26975/opinion-mac-os-server

Windows7でTLS1.3を有効？にする

 メールサーバーの更新によりメールがTLS1.3でしか送受信できなくなった。

 Windows10ではできるがWindows7では送受信できなくなった。

最初はメーラーのバージョンが古いのが問題かと思ったが根本原因は違った。

 https://docs.microsoft.com/ja-jp/windows/win32/secauthn/protocols-in-tls-ssl--schannel-ssp-

現時点でWindowsOSはTSL1.2まで対応

ただ、TSL1.3でwindows10では送受信できてるということは、設定として1.2でできるように定義するとWindows7でもできるはず？

 ＿＿＿＿＿＿＿＿＿

Windows7のレジストリの設定でTLS1.2を定義してみた。

https://docs.microsoft.com/ja-jp/windows-server/security/tls/tls-registry-settings

 まだ、送受信できない。

アプリ側＝メーラー側でTSL1.2を指定すると送受信できた。

アプリーOSは1.2でしかできなくて

OS－インタネットは1.3でも通信できる仕様にTLS1.2を定義するとなっていると推測。

VMware ESXi上のWindows10のスリープ設定

 通常スリープの設定は、

１、スタート

２、設定

３、システム

４、電源とスリープ

 

ここで、電源という項目とスリープという項目が左にでてくるのだが

スリープが出てこない。

どうも、WMToolsをインストールしないとスリープの項目が出てこないようだ。

 

 

 

SLAによるクラウド比較 Azure AWS GCP

 SLA

Azure　＞　GCP　＞　AWS

 

Azure　「保証」している　返金あり

GCP 　　「提供」している　金融債権で返す

AWS　　「努力」している　チケットで返す

Azureは日本語訳も常に最新

AWSは英語版より何年か遅れている。。　英語みろ

 

https://cloud-textbook.com/86/

 

正常にドメインコントローラを消せない時の原因の1つ

 正常な手順でドメインコントローラを削除したはずなのに、

オブジェクトが残っている。

サイトとサービスに残っているオブジェクトを消そうとするとこんなエラーが出てた

ADSIエディターで確認してみたら、赤枠のオブジェクトが削除されなかったドメインコントローラのオブジェクトにぶら下がっている。

 

調査するとこんなのが見つかる

https://docs.microsoft.com/en-us/windows/win32/ad/creating-a-service-connection-point

ホストにサービスをインストールすると追加されるみたい

 何かインストールしたのかと聞いたらバックアップを取るためになんぞかインストールしたらしい。

 あとは、SYSVOL 以外の DFS 共有を FRS レプリケーションしているような場合も残るらしい。

https://social.technet.microsoft.com/Forums/windowsserver/ja-JP/0d93d14c-9c36-439d-abc8-10c488b0c360/dc123631242538477266841237512383124671253112500125171254012479?forum=activedirectoryja

 

ADのディレクトリ サービス復元モードのパスワードを忘れた時

 探さないとムリだと思い込んでいましたが、

ADのディレクトリ サービス復元モードのパスワードを忘れた時リセットできました。

 2008R2でも2016でもできたので2008R2以降はできると考えられます。

コマンドラインで

C:\>ntdsutil

ntdsutil: set dsrm password

Reset DSRM Administrator Password: reset password on server null

DS 復元モードの管理者アカウントのパスワードを入力してください: ***********

新しいパスワードの確認入力をしてください: ***********

パスワードは正しく設定されました。

・nullは対象がローカルの場合＝ローカルのホスト名を指定しても可能

・新しいDSRM用のパスワードを2回入力します。現在のパスワードは入力する必要はありません。

なお、GPOを設定変更すればパスワード無しにも変更可能です。

   https://news.mynavi.jp/itsearch/article/hardware/890

   ↑これを読んでできないと思い込んでた。

　　思い込み、良くない。

 

Windows10、2016のログオンの監査のイベントID

https://docs.microsoft.com/ja-jp/windows/security/threat-protection/auditing/basic-audit-logon-events

528 ユーザーがコンピューターに正常にログオンしました。

529 ログオンに失敗します。 不明なユーザー名または既知のユーザー名を使ってログオンしようとしたときに、パスワードが正しくありません。

530 ログオンに失敗します。 ユーザーアカウントが許可されている時間外にログオンしようとした。

531 ログオンに失敗します。 無効なアカウントを使用してログオンが試みられました。

532 ログオンに失敗します。 有効期限が切れたアカウントを使用してログオンしようとした。

533 ログオンに失敗します。 このコンピューターではログオンが許可されていないユーザーによってログオンが試行されました。

534 ログオンに失敗します。 ユーザーが、許可されていない種類でログオンしようとしました。

535 ログオンに失敗します。 指定されたアカウントのパスワードの有効期限が切れています。

539 ログオンに失敗します。 ログオンしようとしたときに、アカウントがロックされました。

538 ユーザーのログオフプロセスが完了しました。

540 ユーザーがネットワークに正常にログオンしました。

551 ユーザーがログオフプロセスを開始しました。

548 ログオンに失敗します。 信頼されたドメインのセキュリティ ID (SID) が、クライアントのアカウントドメイン SID と一致しません。

552 ユーザーが別のユーザーとして既にログオンしているときに、明示的な資格情報を使用してコンピューターに正常にログオンしました。

Windows10、2016のアカウント、グループの監査のイベントID

https://docs.microsoft.com/ja-jp/windows/security/threat-protection/auditing/event-4782


4720: ユーザーアカウントが作成されました。

4722: ユーザーアカウントが有効にされました。

4723 (S, F): アカウントのパスワードを変更しようとしました。

4724 (S, F): アカウントのパスワードのリセットが試みられました。

4725: ユーザーアカウントが無効にされました。

4726: ユーザーアカウントが削除されました。

4738: ユーザーアカウントが変更されました。

4740: ユーザーアカウントがロックアウトされました。

4765: SID 履歴がアカウントに追加されました。

4766 (F): アカウントに SID 履歴を追加しようとして失敗しました。

4767: ユーザーアカウントのロックが解除されました。

4780: ACL は、管理者グループのメンバーであるアカウントに設定されました。

4781: アカウントの名前が変更されました。

4794 (S, F): ディレクトリサービス復元モードの管理者パスワードを設定しようとしました。

4798: ユーザーのローカルグループメンバーシップが列挙されました。

5376: 資格情報マネージャーの資格情報がバックアップされました。

5377: 資格情報マネージャーの資格情報がバックアップから復元されました。

4782: アカウントのパスワードハッシュがアクセスされました。

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

4731: セキュリティ対応のローカルグループが作成されました。

4732: セキュリティが有効なローカルグループにメンバーが追加されました。

4733: セキュリティが有効なローカルグループからメンバーが削除されました。

4734: セキュリティ対応のローカルグループが削除されました。

4735: セキュリティが有効なローカルグループが変更されました。

4764: グループの種類が変更されました。

4799: セキュリティ対応のローカルグループメンバーシップが列挙されました。

ADFSの証明書はオレオレ証明書で良いのか？

結論から言うと検証としては大丈夫でしょうね。

ADFS上では証明書は4種類ある
・署名証明書-トークン
・サービス通信証明書
・SSL証明書 　(Secure Sockets Layer)
・トークン-暗号化解除証明書
  
んで、オレオレ証明書で大丈夫なのかというと、、

”運用環境で自己-署名された SSL 証明書を使用すると、アカウントパートナー組織の悪意のあるユーザーがリソースパートナー組織のフェデレーションサーバーを制御できるようになります。 このセキュリティリスクは、自己-署名入り証明書がルート証明書であることが原因で発生します”

とある。

https://docs.microsoft.com/ja-jp/windows-server/identity/ad-fs/design/certificate-requirements-for-federation-servers

機能としてできるけど、、
セキュリティリスクあるってことね。  

ActiveDirectoryでの現在のディレクトリーサーバーが「利用不可」表示になる

ユーザーとコンピューター等でドメインコントローラの変更をしようとすると、
現在ログオンしているのがWIN03ですが見事に使用不可となっている。
その他はオンライン。

ログオンしているサーバーでみると自サーバーが利用不可となる。

原因は、自サーバーのTCPIPのプロパティのTCP/IPｖ6のチェックが入れるかどうか
入っていると自サーバーもオンラインになる。

なんで？

WindowsServer2016ドメイン環境下の時刻同期

今までの時刻同期

https://www.atmarkit.co.jp/ait/articles/1205/17/news135.html


時刻同期については、ずっと、こんな感じだと思っていましたが2016で変更がありました。

https://docs.microsoft.com/ja-jp/windows-server/networking/windows-time-service/accurate-time

ドメイン環境下ではPDCエミュレーターがTOPだが例外的に
「ドメインの適切なタイム サーバーを示す GTIMESERV ドメイン フラグを持つ DC」
にすることができるようだ。

＊以下、DC＝ドメインコントローラ

GTIMESERV ドメイン フラグを持つ DC＞PDC

ドメインの適切なタイム サーバーを示す GTIMESERV ドメイン フラグを持つ DC 
とはなんぞや？
と読んでいくと、、

 GPS ハードウェアが搭載されている サーバーでフラグを立てた(設定した)DCらしい。

完全にデータセンター規模を想定していますな。。。 

ちなみにMS推奨構成は、
Hyper-Vのホストが GTIMESERVを参照
PDCエミュレーターが Hyper-Vのホストを参照
 配下は今まで通り

 らしい。

ActiveDirectoryのDNS致命的なエラー

よく訳の分からん大手Sierに頼むとこうなってて呼ばれる。 という愚痴

https://social.technet.microsoft.com/Forums/ja-JP/bcab5a0f-6af7-411f-8e37-37022cd9ebd1/ad-dns-eventid4015-33268216293034012394124561252112540?forum=activedirectoryja

凄く強く断言して127.0.0.1をプライマリDNSに指定しろって言ってくることが多い。。

Symantec Endpoint Protection Ver14.2 環境で「も」Google Chrome 78~以降が利用できない問題

https://forest.watch.impress.co.jp/docs/news/1226294.html

と記載がありますが
環境によってはSEP　Ver14.2でも起こります。

対処法は一緒でこれでした。

https://support.symantec.com/jp/ja/article.tech256047.html

Microsoft　Egdeもなんだ。
といまさら気づく。