０．前書き
今回はMicrosoftのディレクトリサービスであるActive Directoryと
Sambaを利用して、移動ユーザープロファイルを構築します。
ADにドメイン参加したPCであれば、どのPCからでも
同一のユーザープロファイルを参照できるようにユーザープロファイルは
Sambaのファイルサーバに保存するというわけです。
うちの環境では40Gのネットワークを構築しているため、
あまり気になる速度ではないかもしれませんが起動時間短縮のために
フォルダリダイレクトの設定も行う予定です。
いざいざ、環境説明から始めていきましょう。
１．環境説明
①ドメインコントローラー
構築システム：Active Directory
ホスト名：ADServer
OS：Windows Server 2022 Standard Evaluation(評価版)
IPアドレス：172.16.1.5
備考：DNSサーバも同居
②ファイルサーバ
構築システム：Samba 4.10.16
ホスト名：File Server
OS：CentOS 7 (3.10.0-1160.49.1.el7.x86_64)
IPアドレス：172.16.1.1
③ドメイン環境
DNSドメイン名：home.miyamo83.com
NetBIOSドメイン名：AD
管理者ユーザー：administrator
テストユーザー：testuser
こんな感じでどのご家庭にもあるごく自然な環境となっています。
２．構築の流れ
構築は大まかに以下の流れで進めていきます。
①ファイルサーバのDNS設定変更
②Active Directory(以降ADとする)サーバのDNSサーバサービスに
ファイルサーバの情報を登録
③ファイルサーバのNTP設定変更
④ファイルサーバのドメイン参加準備
⑤ファイルサーバのsmb.conf設定変更
⑥ファイルサーバにディレクトリ作成
⑦ファイルサーバをドメイン参加
⑧ADサーバ上でファイルサーバのドメイン参加を確認
⑨ADサーバ上でグループポリシーの作成
⑩テストユーザーでログイン
ちなみに①～⑧までは以下のサイトの手順を丸パクリさせてもらいました。
先人の知恵を借りて、高みを目指すことも大事なので。大事なので…
３．構築手順
①ファイルサーバのDNS設定変更
ファイルサーバをドメイン参加するためには、
ファイルサーバ側でADサーバのホスト名を引ける状態であることが
必須となります。
また、ADサーバ側でファイルサーバのホスト名を
引ける状態であることも必須なのでここでは、
以下の２つ名前解決が行えることをもって次の手順にすすめることとします。
■ADサーバのホスト名
■ファイルサーバのホスト名
まず、ファイルサーバにSSHログインしてから、
以下のコマンドを実行します。
以後、黄色のマーカーで塗った部分は環境に合わせて変更してください。
# sudo nmcli connection modify ens192 ipv4.dns “172.16.1.5” ipv4.dns-search home.miyamo83.com
エラーなどがなく、「すんっ」て感じでコマンドが通ったら成功です。
続いて設定されているかの確認コマンドを実行します。
# sudo nmcli connection show ens192 | grep ipv4.dns
以下が実行結果です。
ipv4.dns: 172.16.1.5
ipv4.dns-search: home.miyamo83.com
ipv4.dns-options: “”
ipv4.dns-priority: 0
設定変更を反映させるためにネットワークサービスの再駆動を行います。
# sudo systemctl restart network
設定繁栄を確認するために以下のコマンドを実行します。
# cat /etc/resolv.conf
以下が実行結果です。
search home.miyamo83.com
nameserver 172.16.1.5
ちなみにDNSの設定を変えるには、
ifcfgファイル変更する方法もあります。
ドメイン参加する上で、FQDNだけでなく
ホスト名のみの名前解決を可能にするため、「resolv.conf」への
「search home.miyamo83.com」が必須です。
ifcfgファイルを編集する際は以下を追記するように編集してください。
DNS1=172.16.1.5
DOMAIN=home.miyamo83.com
②Active Directory(以降ADとする)サーバのDNSサーバサービスに
ファイルサーバの情報を登録
つづいて、ADサーバに入り
DNSサーバにファイルサーバのホスト名の
AレコードおよびPTRレコード登録します。
登録した名前が引けているかの確認をするための「host」コマンド利用するため、
ファイルサーバに戻り、以下のコマンドを実行します。
# sudo yum -y install bind-utils
「bind-utils」のインストールが完了したら、
以下のコマンドでADサーバの名前解決(FQDN)の確認をします。
# sudo host ADServer.home.miyamo83.com
以下が実行結果です。
ADServer.home.miyamo83.com has address 172.16.1.5
続いて、以下のコマンドでADサーバの名前解決(ホスト名)の確認をします。
# sudo host ADServer
以下が実行結果です。
ADServer.home.miyamo83.com has address 172.16.1.5
最後に以下のコマンドでファイルサーバの名前解決(ホスト名)の確認をします。
# sudo host fileserver
以下が実行結果です。
fileserver.home.miyamo83.com has address 172.16.1.1
FQDNで名前解決ができるのに、ホスト名で名前解決ができない場合は
「resolv.conf」に「search home.miyamo83.com」がない可能性があります。
③ファイルサーバのNTP設定変更
端末をADサーバのドメインに参加させると、
認証や認可などのサービスが受けられるようになります。
この仕組みにより、何度も認証が必要な部分を
１度の認証で可能にする所謂SSOが実現されています。
この仕組みを使う上で、SSO用のチケットが払い出されるのですが、
このチケットにはセキュリティを担保するために発行時刻を
記録するタイムスタンプがあります。
チケットを発行した側と受け取った側のタイムスタンプの時刻が
５分以上乖離していると、SSOでの認可が下りなくなります。
つまり、チケットを受け取った側のPCとチケットを発行したADサーバとの時刻差が
５分以上あってはいけないのです。
参考サイト：https://www.infraexpert.com/study/security18.html
そこで、ファイルサーバのNTPの確認先をADサーバに向けて時刻差をなくします。
基本的にWindows PCの場合はドメイン参加した時点で自動的に
NTPの設定がADサーバに向きますが、今回はCentOSなので手動で変更する感じです。
NTPの設定変更を行うべく、以下のコマンドを実行します。
# sudo vi /etc/chrony.conf
編集箇所は以下です。
#server 0.centos.pool.ntp.org iburst
#server 1.centos.pool.ntp.org iburst
#server 2.centos.pool.ntp.org iburst
#server 3.centos.pool.ntp.org iburst
server ADServer.home.miyamo83.com iburst
内容を書き換えたら、次のコマンドを実行し、
NTPクライアントを再起動します。
# sudo systemctl restart chronyd
設定内容を確認するコマンドを実行します。
# sudo chronyc sources
以下が実行結果です。
210 Number of sources = 1
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^* ADServer.home.miyamo83.c> 2 6 17 6 -45us[ -243us] +/- 46ms
④ファイルサーバのドメイン参加準備
Sambaで構築したサーバのドメイン参加は、
サーバ自体のドメイン参加をした後に、Samba側でもドメイン参加用の設定を行う
２段階構成となっています。
そこでまずはSamba用追加パッケージをインストールします。
# sudo yum -y install krb5-workstation oddjob-mkhomedir samba-winbind samba-winbind-clients samba-winbind-krb5-locator pam_krb5
インストールが完了したら、「krb5.conf」を編集する前にバックアップを取ります。
# sudo cp -p /etc/krb5.conf /etc/krb5.conf.old
「krb5.conf」を編集します。
# sudo vi /etc/krb5.conf
変更後の内容は以下です。
# Configuration snippets may be placed in this directory as well
includedir /etc/krb5.conf.d/
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
dns_lookup_realm = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
rdns = false
default_realm = HOME.MIYAMO83.COM
# pkinit_anchors = FILE:/etc/pki/tls/certs/ca-bundle.crt
# default_realm = EXAMPLE.COM
default_ccache_name = KEYRING:persistent:%{uid}
[realms]
HOME.MIYAMO83.COM = {
kdc = home.miyamo83.com
admin_server = adsever.home.miyamo83.com
}
# EXAMPLE.COM = {
# kdc = kerberos.example.com
# admin_server = kerberos.example.com
# }
[domain_realm]
.home.miyamo83.com = HOME.MIYAMO83.COM
home.miyamo83.com = HOME.MIYAMO83.COM
# .example.com = EXAMPLE.COM
# example.com = EXAMPLE.COM
⑤ファイルサーバのsmb.conf設定変更
「smb.conf」の編集を行う前に、Sambaのサービスを止めます。
# sudo systemctl stop smb nmb
「smb.conf」を編集する前にバックアップを取ります。
# sudo cp -p /etc/samba/smb.conf /etc/samba/smb.conf.old
「smb.conf」を編集します。
# sudo vi /etc/samba/smb.conf
変更後の内容は以下です。
# See smb.conf.example for a more detailed config file or
# read the smb.conf manpage.
# Run ‘testparm’ to verify the config is correct after
# you modified it.
[global]
workgroup = AD
realm = HOME.MIYAMO83.COM
security = ads
# server role = AUTO
server string = SAMBA SERVER Version %v
netbios name = fileserver
idmap config * : range = 16777216-33554431
idmap config HOME.MIYAMO83:backend = rid
idmap config HOME.MIYAMO83:range = 10000-15000
# ホームディレクトリの自動作成に必要
obey pam restrictions = yes
template homedir = /home/%D/%U
template shell = /bin/bash
kerberos method = secrets only
winbind use default domain = true
winbind offline logon = false
unix charset = UTF-8
# passdb backend = tdbsam
dos charset = CP932
wins support = yes
# printing = cups
# printcap name = cups
load printers = no
disable spoolss = yes
# cups options = raw
# 共有定義
# globalセクションの設定を上書きする
[homes] # ユーザの各ホームディレクトリの共有設定
comment = Home Directories
valid users = %S, %D%w%S
browseable = No
read only = No
inherit acls = Yes
[share]
comment = Share Folder for All Users
path = /home/share/
browseable = yes
read only = no
create mask = 0777
directory mask = 0777
#[printers] #共有プリンタに関する設定
# comment = All Printers
# path = /var/tmp
# printable = Yes
# create mask = 0600
# browseable = No
#[print$] # $をつけると隠し共有となる（browseable=No とするのと同じ）
# comment = Printer Drivers
# path = /var/lib/samba/drivers
# write list = @printadmin root
# force group = @printadmin
# create mask = 0664
# directory mask = 0775
上記設定をそのまま行うと、共有フォルダである「share」も設定されるため注意
編集が終わったら、以下のコマンドで構文チェックを行う
# sudo testparm
エラーがなく、設定内容が表示されれば成功です。
⑥ファイルサーバにディレクトリ作成
次に「template homedir = /home/%D/%U」で
記載した％Dのフォルダを作成しに行きます。
％DはNetBIOSドメイン名です。
# sudo mkdir /home/AD
権限を変更します。
# sudo chmod 1777 /home/AD
⑦ファイルサーバをドメイン参加
まず、ドメイン参加に必要なKerberosm認証のチケットを取得します。
ドメイン参加に必要な管理者権限のあるユーザーを指定します。
# sudo kinit administrator
エラーがなければ成功です。
例のごとく、確認コマンドを実行します。
# sudo klist
以下実行結果です。
Ticket cache: KEYRING:persistent:0:0
Default principal: administrator@HOME.MIYAMO83.COM
Valid starting Expires Service principal
2022-09-18T23:03:35 2022-09-19T09:03:35 krbtgt/HOME.MIYAMO83.COM@HOME.MIYAMO83.COM
renew until 2022-09-25T23:03:23
このようにチケット情報が表示されれば成功です。
いよいよ管理者ユーザーでドメイン参加を行います。
# sudo net ads join -U administrator
以下実行結果です。
Using short domain name — AD
Joined ‘FILESERVER’ to dns domain ‘home.miyamo83.com‘
ドメイン名がショートとか言われていますが気にしません。
次にドメイン参加したかどうかの確認コマンドです。
# sudo net ads info
以下実行結果です。
LDAP server: 172.16.1.5
LDAP server name: ADServer.home.miyamo83.com
Realm: HOME.MIYAMO83.COM
Bind Path: dc=HOME,dc=MIYAMO83,dc=COM
LDAP port: 389
Server time: 月, 19 9月 2022 02:18:36 JST
KDC server: 172.16.1.5
Server time offset: 0
Last machine account password change: 月, 19 9月 2022 02:16:22 JST
この時点で、ADサーバの「Computers」にファイルサーバのホスト名
が出てくるはずです。
これでドメイン参加は終わりではありません。
Sambaの設定を変更する必要があります。
これまでローカルユーザでSambaの認証をしてきましたが、
winbaindと呼ばれるADサーバとの懸け橋になるサービスを使って、
ADサーバに登録されたユーザでの認証を行うように変更します。
変更コマンドは以下のコマンドです。
# sudo authconfig –enablekrb5 –enablewinbind –enablewinbindauth –enablemkhomedir –update
エラーがなく、終われば成功です。
これでようやくSambaの設定変更は完了ですので、
Sambaとnmbに加えて、winbindサービスを起動させます。
# sudo systemctl start smb nmb winbind
続いてwinbindの自動実行を有効にします。
もし、Sambaやnmbが自動実行されていないのであれば、ここで有効にしてください。
# sudo systemctl enable winbind
以下実行結果です。
reated symlink from /etc/systemd/system/multi-user.target.wants/winbind.service to /usr/lib/systemd/system/winbind.service.
自動実行が有効になっているか確認します。
# sudo systemctl is-enabled winbind
以下実行結果です。
enabled
では最後に、ADで作成したユーザーの情報を
ファイルサーバで取得してみましょう。
# sudo id administrator
以下実行結果です。
uid=16777217(administrator) gid=16777223(domain users) groups=16777223(domain users),16777224(denied rodc password replication group),16777225(schema admins),16777226(enterprise admins),16777227(domain admins),16777228(group policy creator owners),16777217(BUILTIN\users),16777216(BUILTIN\administrators)
# sudo id testuser
以下実行結果です。
uid=16777216(testuser) gid=16777223(domain users) groups=16777223(domain users),16777217(BUILTIN\users)
もしここで何も表示されない場合、再度以下のコマンドを試してください。
筆者もうまくいかないことがありましたが、やり直したらできました。
# sudo authconfig –enablekrb5 –enablewinbind –enablewinbindauth –enablemkhomedir –update
ここまでの手順がすべてうまくいっている場合、
ファイルサーバでドメインユーザーでのログインができたり、
Windowsクライアントにドメインユーザーでログインした場合、
以下のホームディレクトリにアクセスできるはずです。
「\\fileserver\%username%」
※%username%はWindowsの環境変数でその時ログインしている
ユーザーを指しています。
⑧ADサーバ上でファイルサーバのドメイン参加を確認
ではADサーバに入って、「Active Directory ユーザーとコンピュータ」の
「Computers」に「FILESERVER」が登録されているか確認しましょう。
登録されている場合こんな感じです。
あとはどのOUに置くかはそれぞれの環境にお任せします。
⑨ADサーバ上でグループポリシーの作成
続いて、本題の移動ユーザープロファイルを構築していきます。
先ほど作成したホームディレクトリ「\\fileserver\%username%」のは以下に
プロファイルを置きます。
加えて、以下四つのフォルダに関してはフォルダリダイレクトを行い、
PC上にデータを残させません。
■Desktop
■AppData(Roaming)
■Favorites
■Downloads
つまり、シンクライアントのような形になります。
また、ホームディレクトリへのアクセスの利便性を考えて、
各ユーザーにはドライブ割り当てを自動で行います。
この要件をすべて満たすためにグループポリシーでは以下を設定します。
■移動ユーザープロファイル
■ユーザーグループポリシーループバックの処理モードを構成する
■フォルダリダイレクト用のレジストリキー書き換え
■ドライブマッピング
まず、グループポリシーの作成方法です。
ADサーバに入り、「グループポリシーの管理」を開きます。
自ドメインの配下に「グループポリシーオブジェクト」があるので、
右クリックし、「新規」をクリックします。
名前を付けて、「OK」を押します。
「グループポリシーオブジェクト」内に作成したグループポリシーが
出てくるので、右クリックし「編集」をクリックします。
この「グループポリシー管理エディター」で設定をしていきます。
■移動ユーザープロファイル
パス：「コンピューターの構成 > 管理用テンプレート > システム > ユーザープロファイル」
ポリシー名「このコンピューターにログオンしているすべてのユーザーの移動プロファイルパスを設定する」
設定：有効
オプション：\\fileserver\%username%\profile
■ユーザーグループポリシーループバックの処理モードを構成する
パス：「コンピューターの構成 > 管理用テンプレート > システム > グループポリシー」
ポリシー名「ユーザーグループポリシーループバックの処理モードを構成する」
設定：有効
オプション：統合
ループバック設定に関しては以下のサイトを参照してください。
■フォルダリダイレクト用のレジストリキー書き換え
パス：「ユーザーの構成 > 基本設定 > Windowsの設定 > レジストリ」
右クリックし「新規作成 > レジストリ項目」をクリックしてレジストリの新規作成を４つ行う
１つ目：Desktop
ハイブ：「HKEY_CURRENT_USER」
キーのパス：「Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders」
値の名前：Desktop
値の種類：REG_EXPAND_SZ
値のデータ：\\fileserver\%logonuser%\profile.V6\Desktop
２つ目：AppData
ハイブ：「HKEY_CURRENT_USER」
キーのパス：「Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders」
値の名前：AppData
値の種類：REG_EXPAND_SZ
値のデータ：\\fileserver\%logonuser%\profile.V6\AppData
３つ目：Favorites
ハイブ：「HKEY_CURRENT_USER」
キーのパス：「Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders」
値の名前：Favorites
値の種類：REG_EXPAND_SZ
値のデータ：\\fileserver\%logonuser%\profile.V6\Favorites
４つ目：Downloads
ハイブ：「HKEY_CURRENT_USER」
キーのパス：「Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders」
値の名前：{374DE290-123F-4565-9164-39C4925E467B}
値の種類：REG_EXPAND_SZ
値のデータ：\\fileserver\%logonuser%\profile.V6\Downloads
フォルダリダイレクトは、ポリシーでも存在しているが
ポリシーで設定してしまうと環境変数が使用できないため、
今回のようにファイルサーバ上にログインユーザー名で作成されたフォルダの配下に
プロファイルを置くことができない。
レジストリであれば、「%logonuser%」でログインユーザー名を
環境変数で設定可能なため、今回この手段を取りました。
すべてのユーザー共通のリダイレクト専用のフォルダを作るのは妙な気がしたので…
■ドライブマッピング
パス：「ユーザーの構成 > 基本設定 > Windowsの設定 > ドライブ マップ」
右クリックし「新規作成 > マップされたドライブ」をクリックする
アクション：作成
場所：\\fileserver\%username%
ラベル：個人フォルダ
ドライブ文字：次の文字を使用：Z
以上でグループポリシーの作成は完了なので、
「グループポリシー管理エディター」は閉じて大丈夫です。
グループポリシーを適用したいPCがぶら下がっているOUに
グループポリシーをリンクしましょう。
OUを右クリックし「既存のGPOのリンク」をクリック
先ほど作成したグループポリシーオブジェクトを選択し、リンクさせます。
成功するとこんな感じ。
私は「メイン」のOUにPCを１台ぶら下げていますので、
このグループポリシーオブジェクトはそのPCにのみ適用されます。
これですべての設定が完了しました。
いざいざ、最後の確認と行きましょう。
⑩テストユーザーでログイン
検証の前にコマンドで以下のコマンドを実行してください。
gpupdate /force
今回検証ユーザーとして用意した「testuser」でログインした結果です。
ちゃんとドライブ割り当てされています。
ドライブ先は個人フォルダで中には「profile.V6」が格納されています。
中身はフォルダリダイレクト設定を行った４つのフォルダです。
デスクトップに「新しいフォルダー」を作成すると
プロファイルにもきちんと反映されました。
ダウンロードフォルダもきちんと機能しています。
「\\fileserver」でアクセスした際の表示はこんな感じ
フォルダリダイレクトを設定していないプロファイルに関しては、
移動ユーザープロファイルが有効になるため、
一度サインアウトすると保存されます。
これで作業はすべて完了になります。
ドメインユーザーでログインした際に、
プロファイルの挙動がおかしかったり、エラーになる場合
ファイルサーバごと再起動してみてください。
実は筆者もこの手順を追って、再度構築しなおした際に
プロファイルのエラーになりましたが、ファイルサーバの再起動で治りました。
それでもうまくいかない場合は、原因切り分けのために一度グループポリシーのリンクを切って、
ファイルサーバの設定変更だけが有効になっている状態で
想定通りの結果であるか確認してみてください。
グループポリシーのリンクを切っても挙動がおかしいのであれば確実にファイルサーバの
構築に原因があることがわかります。
４．後書き
さて…とんでもなく長い手順になってしまいましたが、
これが実現できれば統合認証基盤とPCのシンクライアント化につながるので、
ぜひ取り入れてみてください。
本編からはそれますが、
かれこれ自宅でサーバを飼い始めてから、半年が経ちましたが
相変わらずうるさいですね、慣れません。
そういえば。夏の暑さにサーバが耐えられないと思い、
SwichBotの温度計とリモコンハブを購入しました。
サーバラック内の温度が37℃を超えると自動でエアコンが作動します。
5000円くらいで二つ揃えられるので、
サーバの温度管理に困っている方は試してみてはいかがでしょうか。
５．参考サイト
コメント