前回までの不具合(ソフトウェアの問題か使い手の問題かは不明)
http://e4776m4mg.blogspot.jp/2016/03/samba.html
の続き。ADで作成したはずのユーザアカウントについて、ファイルサーバ側であたかも存在するように見える(Windows側でエクスプローラでネットワークをブラウズな分にはそう見える)にも関わらず、CentOS上では /home にこれらのアカウントのホームディレクトリが存在しない問題。
その後、ファイルサーバであるCentoOS7を載せているVirtualBoxのシャットダウン中にVDIのエラー。
ここで「嫌気がさし」エラー詳細についてプリントスクリーンボタンひとつ押しやしないアタマの弱さを露呈。深刻に反省しなくてはならない。
VirtualBoxのエラーはその後再現しないが、OSのシャットダウン中には、
nel arming
winbind
な段で最大90秒枠で何やら時間を要している様子。前者はどうも、kernel arming であるようで、正常な動作ではなさそうだ。
そこで、"レンタルサーバー・自宅サーバー設定・構築のヒント" さんのこちらを参考に。
http://server-setting.info/blog/kdump-no-memory-reserved-for-crash-kernel.html
# systemctl status kdump.service
内容がまったくわからない。ただ、winbindの文字は無い。再現性を確認すると
[FAILED] Failed to start Crash recovery kernel arming.
kdump.service を見ろやの一行をはさんで
[ **] A stop job is running for Samba Winbind Daemon (37s / 1min 31s)
である。またこの事象は
CentOS Linux (3.10.0-327.10.1.el7.x86_64) 7 (Core)
CentOS Linux (3.10.0-327.el7.x86_64) 7 (Core)
CentOS Linux (0-rescue-英数字30桁ほど) 7 (Core)
レスキューモードでは発生するはずもないのだろうが、アップデート前後?は両方で発生する。
となると。ファイルサーバに障害があった台本のつもりで、ファイルを拾い出してファイルサーバを立て直すか。計画性を欠いたので整合性はアレだが現状確認すると、
・ADはそのまま
・リモートサーバ管理ツール環境はすでに白紙にしてしまった
・ファイルサーバもそのまま
なので、管理ツール環境の入れ直しから復旧できるかどうか、次に、ファイルサーバの回復、最悪ADから作り直し--->障害復旧作業の第一段階終了、になるか。あまりにも前提の知識がないので第2段階以降、そもそもの解明がどこまでできることやら情けないが。
[リモートサーバ管理ツール環境の白紙再作業で考慮すべき点]
・管理PC Win7側のアカウント
特定の担当者依存を避けるため管理者共有アカウントがのぞましい
--->サーバツールはWindows管理ツールの中の位置づけなので
主担当者のPCでローカルAdministratorを有効化(二次被害防止)
同PCの主担当者アカウント=ローカルAdminでワークグループ-->ドメインへの変更
ドメインAdminで当該PCからログイン
ドメインAdminでサーバツールのインストール
副担当者のPCでも同様に
・AD側
本番ではありえないのだろうが今のテストではDCのブート時に
SElinuxやiptablesを有効にしてしまっている場合があるので
(いずれもゆくゆくは有効にするのだがトラフィックを調べ切れてないので仮無効)
この確認。
・管理PCのDNS設定
これもテスト下でいじっているので、DCに向いているかどうか要確認。
これでいいか? また、前回はドメイン管理者をAdministratorそのまんまで使っていたので、これも別途アカウントを用意しなくてはならないが、そんなん当面のトラブル片づけで整理して原因突き止めて反省してからや。
[付随作業メモ]
・スタートメニューの入力ボックスにcmdでCtrl+Shift+Enter-->管理者として実行。
・Windows機能の有効かまたは無効化でリモートサーバ管理ツールを一式チェックしてみたところ5分ほども構成待ち時間が。
・サーバ管理ツールを使おうとしてまたしてもDNSサーバ設定変更忘れ
・DNSサーバ設定を戻した後もDCのドメイン付きホスト名、ホスト名をすぐには解決できず若干時間を要した。
・非ドメインな無印8.1をネットワークで検出できなかった。NetBIOS over TCP/IPをでふぉにしていたためか、ブロードキャストやマルチキャストを撒き散らかしたりしていなかったが、これを有効にしたところ検出した。
ファイルサーバについてはしばらくしてからネットワークに現れた。「最新の情報に更新」の効果か、何らか登場までのステップがあるかどうかは今の時点では知識が無い。
・ドメインadminでFS上のadminディレクトリにアクセス可能
シェル関連のファイルが見える-->読み書き可能
・ドメインadminでankoやdangoアクセスはユーザ名パスワードが必要
・同じくshareについてはもとより制限なしであるので読み書き可能
次に、ユーザ管理ツール(ActiveDirectoryユーザとコンピュータ)を確認する。
・ツールを起動するだけで所属ドメインが左ペインに現れる
・ユーザについては先のテストで作成した和菓子系アカウントが存在する
・ファイルサーバ側の/homeには存在しない
--->再度ユーザアカウントの作成テスト rollcake fruits--Jadou
・DC側でユーザを作成しただけでFS側は同期しない
・net ads join -U Administrator でも/homeに新ユーザのホームディレクトリは作成されない。
・しかし以前に作成した日本の草系ユーザのホームディレクトリは存在するしこのために何ら作業は行っていない
<---行き倒れバッタリ無計画アタマ弱エンジニアまるだしでなく、考える。
ファイルサーバ側でログインすれば、ディレクトリは作成される。そういうこと!?
昨日作ったアカウント(fs側にアクセス不可)でADにログイン、エクスプローラ～ネットワークなブラウズでは、
・所属するグループの共有は見えるが要ユーザー名&パスワード
・ホームディレクトリは存在する
という状況。このアカウントはファイルサーバ側/CentOS上で一度もログインしていないので、CentOS上でホームディレクトリは存在しない。そこで、CentOS側でログインしてみる。
Warning: Your password will expire in 41 days on Wed Apr 12 04:14:45 2016
Creating directory '/home/ユーザ名.
これで直ちに、当該ユーザのホームディレクトリにアクセス、読み書き可能。そして...グループ毎の共有には、要ユーザ名・パスワード。smb.confにおいて当該フォルダは、
valid users = @ドメイン名+グループ名
を設定しているが、これが誤っているということか。
wbinfo -g
でAD側のグループを認識していることを確認。
wbinfoコマンドの書式については、MIRACLE LinuxさんのSamba が動作する Linux マシンを Windows ドメインに参加させる方法― MIRACLE LINUX V2.1 における Samba Winbind 利用方法 ―から。
次に、smb.conf内で当該共有フォルダに対して valid users を指定しているがこの書式が @ドメイン名+グループ名 であるので、ここで+を\に変更してみる。セパレータと呼ぶらしく、Samba4ではなくずっと以前のバージョンだが、これが問題になったこともあったようなので。
--->応答が変わって、ユーザ名パスワードを問われることなくアクセス不可となった。Windows側のメッセージとしては「\\なになに￥どこ共有 に対するアクセス許可がありません。ネットワーク管理者にアクセス許可を要求してください。」ありがちな、その管理者がオレや！オチ。
valid users の書式は、
http://net-newbie.com/samba/smb.conf.5.html#INVALIDUSERS
http://net-newbie.com/samba/smb.conf.5.html#VALIDUSERS
であるようでこれは UnixPower on Networkingさんのコンテンツと変わらないのだが、であれば valid users を機能させるための前提で私が何か誤ったということだ。
ここで、環境は少々古いが dialy dayflower さんが
2007-12-19 Samba & winbindd での valid users の指定方法
http://d.hatena.ne.jp/dayflower/20071219/1198047039
なる記述法について公開されていたので、真似てみる。マネるだけでなく winbind separator 有り無し を踏まえ、+""、@""、それから@グループ名もついでに試してはみた。無根拠で試すなど愚か極まりないが。
samba-tool での確認をしようとも思ったのだが、winbind+ファイルサーバ導入のこちらには samba-toolそのものが無い。
そこで、先人のみなさんにとってはあまりにも常識で誰も書かないようなところが!?
もう、パーミッションが根本的に。そもそも共有フォルダはrootで作っている。所有者は当然rootで、 グループもroot扱い。ドメインユーザのホームディレクトリはこれと異なり、ユーザ自身が所有者でグループはドメインユーザ。
これを一時的に 777 にしてしまい、再度 smb.conf の valid users を変更したところ、@グループ名でアクセス可能となった。この時点では書き込み不可であったので、write list で同様に@グループ名を指定したところ書き込み可能となった。また、グループ外のユーザについては、ドメインadminは 閲覧不可。ユーザ名・パスワードを要求されるためグループに属するユーザ+パスワードを入力してみたがNG、一度アクセスが失敗すると次はネットワークエラー扱いとなった。
次に、dangoグループの別ユーザでADにログイン、ネットワークからファイルサーバへアクセスしたところ、グループ共有のみならずホームディレクトリがNG、ユーザ制限なしの共有はOK。このユーザは、CentOS側でのログインを実施していなかった。ログイン後はホームディレクトリにOKとなったが、今度はグループ共有にアクセス不可。これは、777 を「777気持ち悪いから、776でよくね!?」などと変更したからだった。
次に、ドメインAdminでない他グループのユーザでの確認。当然、アクセスしようとするとユーザ名パスワードが要求される。ここで、アクセス権のある別ユーザとパスワードを入力すると何と！！ファイルサーバ上では別ユーザに成り代わってしまう。Windows側でのユーザアカウントはもちろん変わらないが、ファイルサーバでは別ユーザのホームディレクトリが見え、それまでのホームディレクトリは見えなくなる。アクセス権限も、新たに入力したユーザのそれだ。
ということは!?
行き倒れバッタリで設定したsmb.confやパーミッションは、やはり行き倒れバッタリだったということだ。
尚、ドメインにログインせずとも、ファイルサーバアクセス時にドメインユーザ・パスワードを入力すれば、当該ユーザに成りすましてアクセス可能。
# smbstatus
はリアルタイムのアクセス状況を確認できるようだが、ここでも当然、成りすましたユーザとして見える。アクセス元のIPアドレスは分かるが、手掛かりには乏しすぎる。
0 件のコメント:
コメントを投稿