・ローカルのAdministrator権限を持つアカウントでログイン
・ADドメインの管理者権限でADドメインに参加
すると、ADの Domain Admins なアカウントがそのまま(別途作業無しに)ローカルの Administrators グループに属する。ドメイン参加(偏向)には管理者権限が必要であってむしろ当然であるので、Domain Admins なアカウントがローカルな管理者権限を持つこともまた然り、ではあるのだが。ま、知らんかったもんは知らんかったあぁ痛ぇ。
というわけで、Samba AD側で管理者権限を持たないユーザを作ってテストしないと。
---> リモートサーバ管理ツールをとっとと使えるように学べと。
途中で放り出したので築城、いや、追記。
実利用に沿って試してみる。
・ドメインユーザでローカルAdminでないアカウントをひとつ作ってみる。
・ドメインにログインするのみの状況でローカルのリソースに対する制約を調べる。
姓(L): Domain User Not Local AdminもじってDunlap
名(F): Bridget
パスワード: DNAEarth-1
とりあえずやってみる。
まずログオンにえらい時間がかかる。あまりに時間がかかるので、Samba側でiptableを外してみたところ、ほどなくWindowsクライアントでデスクトップの準備が始まったので、依然としてiptableの設定が不十分かもしれない。これは、Sambaとクライアント間にパケットキャプチャを突っ込まないと挙動を把握できない(*後日追記)。別途作業。
ドメインユーザはローカルAdmin権限を得られず、システムフォルダや、ユーザ以下の他ユーザフォルダにアクセスするにはローカルの認証が必要。ただし、ドライブ直下に作った任意のフォルダはアクセス可能。今回たまたま、c:\にソフトウェア倉庫のフォルダを作っていたがここへのアクセスは可能だった。また、Adobeのフォルダを削除してみたところ、削除も可能だった。 また、c:\にフォルダの作成は可能だしファイルも作成可能。
他方、program files や windows 以下の多くのフォルダは読み取り可能だが、当然 書き込み変更は不可。
ということで、ファイル管理について基本的な機能は、ドメインユーザを作成する以外にわざわざ準備する労務は必要ない。あくまで基本的な機能だけだが。
いや、チョージョーシキなのかもしれないが、かつてADに初めて触れた当時に、素直で従順に学んでさえいれば、こんな苦労を今さらには。ま、だから今ハンセイしているのだが。おサルの次郎君にも著しく劣ることは言うまでもない。
次に、切り分けのためにもうひとつアカウントを作る。そういえば、先ほどアカウントを作った際にiptableは問題にならなかったと思われるので、iptableに問題があるなら最初のログオン時点のそれ…なんにせよ要調査。
ともあれ。
姓(L): Almeyda
名(F): Tony
パスワード: EcosES31
初回ログイン時に時間を要する現象は発生しなかった。やはりiptablesか。それから、アプリケーションのインストールはもとより、ネットワーク探索の有効化でも管理者アカウントを要求された。なるほど、これら点でも運用上の心配は無用のようだ。
って初歩の初歩やーーー!!でも初歩を越さずに運用もエキスパートもあるかい AWESOME!
嘆きはさておき。次にSamba上のファイル共有の手順と労務の確認。
追記:
iptablesを外さずとも、約1分ほどかかってログインできた。トラフィックについてはまだ取ったばかりで詳しく見ていないが、iptables が start / stop では相応に差異があるようだ。ぱっと目に付くのは、iptables が有効である際に クライアントからADDCに向けてTCPポート1024のSYNを発して直後に ICMP profibit が返っていること。iptables で開けていないので当然なのだが、なんにせよ詳しく見る必要がある。
0 件のコメント:
コメントを投稿