Ubuntu Server の管理でよく使うコマンドや設定のメモ


<a id="TOP"></a>
Ubuntu Server 22.04での管理でよく使う設定やコマンドです。途中で24.04に変わっています。
[1. キーボードの変更](#1キーボードの変更)
[2. DNSサーバの設定/確認](#2dnsサーバの設定確認)
[3. 固定IPの設定](#3固定ipの設定)
[4. SSH Serverの有効化](#4ssh-serverの有効化)
[5. sshの公開鍵認証の設定](#5sshの公開鍵認証の設定)
[6. Timezoneの設定](#6timezoneの設定)
[7. NTPの設定](#7ntpの設定)
[8. ホスト名について](#8ホスト名について)
[9. bashプロンプトの設定](#9bashプロンプトの設定)
[10. rootのパスワード](#10rootのパスワード)
[11.Active Directory ユーザとの連携](#11active-directory-ユーザとの連携)
[12.Desktop環境とXRDPのインストール](#12desktop環境とxrdpのインストール)

# 1.キーボードの変更
```shell:
$ sudo dpkg-reconfigure keyboard-configuration
```
# 2.DNSサーバの設定/確認
Ubuntu 22.04 では、ローカル(127.0.0.53)のポート53(DNS)をsystemd-resolved.service がフックしています。
```conf: $ systemctl status systemd-resolved
● systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: enabled)
     Active: active (running) since Wed 2024-06-26 05:38:01 UTC; 1h 6min ago
       Docs: man:systemd-resolved.service(8)
             man:org.freedesktop.resolve1(5)
             https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
             https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
   Main PID: 837 (systemd-resolve)
     Status: "Processing requests..."
      Tasks: 1 (limit: 2220)
     Memory: 8.9M
        CPU: 158ms
     CGroup: /system.slice/systemd-resolved.service
             └─837 /lib/systemd/systemd-resolved

Jun 26 05:38:01 ubuntu systemd[1]: Starting Network Name Resolution...
Jun 26 05:38:01 ubuntu systemd-resolved[837]: Positive Trust Anchors:
Jun 26 05:38:01 ubuntu systemd-resolved[837]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
Jun 26 05:38:01 ubuntu systemd-resolved[837]: Negative trust anchors: home.arpa 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa>
Jun 26 05:38:01 ubuntu systemd-resolved[837]: Using system hostname 'ubuntu'.
Jun 26 05:38:01 ubuntu systemd[1]: Started Network Name Resolution.
Jun 26 05:37:40 ubuntu systemd-resolved[837]: Clock change detected. Flushing caches.

```
また昔ながらの、/etc/resolver.conf では以下の通り、nsameserverとしてローカルの127.0.0.53を指しています。
```Ruby: $ more /etc/resolv.conf 
# This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0 trust-ad
search example.com

```
それではsystemd-resolvedはがDNS query行うサーバのアドレスはどこで設定されているのでしょうか？
それは、/run/systemd/resolve/resolv.conf です。
```ruby: $ more /run/systemd/resolve/resolv.conf
# This is /run/systemd/resolve/resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known uplink DNS servers. This file lists all configured search domains.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 172.24.0.11
search example.com
```
この例では、``172.24.0.11``がName Server として指定されています。このサーバでは、この段階で DHCPサーバからIPアドレスを取得する設定になっており``nameserver 172.24.0.11`` はDHCPサーバのDNS情報から設定されています。
Serverなので、基本は固定IPになるので、固定IPの場合のDNSサーバの設定は、次の固定IPの設定で説明します。
[<一番上>](#TOP)
# 3.固定IPの設定
まず現在のIPアドレス設定を確認します。``ifconfig``はサポートしていません。
かわりに`ip addr`を使用します。
```Ruby: $ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:0c:29:95:9f:63 brd ff:ff:ff:ff:ff:ff
    altname enp3s0
    inet 172.24.201.1/16 metric 100 brd 172.24.255.255 scope global dynamic ens160
       valid_lft 2762sec preferred_lft 2762sec
```
``ip``コマンドは他に``ip route``などでルーティング情報の設定なども可能ですのでぜひ覚えましょう。
まずは、``/etc/netplan/99_config.yaml`` を作成して設定を書き込みます。
```Ruby: $ sudo vi /etc/netplan/99_config.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    ens160:                              ← インターフェース名
      dhcp4: false
      dhcp6: false
      addresses: [172.24.35.16/16]      ← 固定したいIPアドレス
      routes:                            
        - to: default
          via: 172.24.1.1               ← デフォルトゲートウェイのアドレス
      nameservers:
        addresses: [172.24.0.11, 172.24.0.10]    ← DNSサーバー
        search: [share.example.com, lab.example.com, example.com]
                                                 ← DNSサーチリスト

```
この設定を適用するのですが、間違えていると、ネットワーク経由でアクセスできなくなったりして不都合があるので、``sudo netplan try``で必ず設定を確認します。
```shell: $ sudo netplan try

** (process:13354): WARNING **: 07:50:37.690: Permissions for /etc/netplan/99_config.yaml are too open. Netplan configuration should NOT be accessible by others.

** (generate:13356): WARNING **: 07:50:37.696: Permissions for /etc/netplan/99_config.yaml are too open. Netplan configuration should NOT be accessible by others.
WARNING:root:Cannot call Open vSwitch: ovsdb-server.service is not running.

** (process:13354): WARNING **: 07:50:38.148: Permissions for /etc/netplan/99_config.yaml are too open. Netplan configuration should NOT be accessible by others.

** (process:13354): WARNING **: 07:50:38.478: Permissions for /etc/netplan/99_config.yaml are too open. Netplan configuration should NOT be accessible by others.

** (process:13354): WARNING **: 07:50:38.479: Permissions for /etc/netplan/99_config.yaml are too open. Netplan configuration should NOT be accessible by others.
Do you want to keep these settings?


Press ENTER before the timeout to accept the new configuration


Changes will revert in  71 seconds
Configuration accepted.
```
この例では、Changes will revert in が表示されている時にエンターキーをおすと``Configuration accepted.`` となって設定を完了しています。
`/etc/netplan/99_config.yaml are too open. Netplan configuration should NOT be accessible by others.` の警告が出ていますのでこれを解決します。
``` 
sudo chmod 600 /etc/netplan/99_config.yaml
```
``WARNING:root:Cannot call Open vSwitch: ovsdb-server.service is not running.`` ←この警告は無視して構いません。
無視するのは気持ち悪いという場合は、``sudo apt install openvswitch-switch``で、(使用しない)Open vSwitchをインストールしてください。

```Ruby: $ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:0c:29:95:9f:63 brd ff:ff:ff:ff:ff:ff
    altname enp3s0
    inet 172.24.35.16/16 brd 172.24.255.255 scope global ens160
       valid_lft forever preferred_lft forever
```
DNSの設定も確認します。
```sh
```
[<一番上>](#TOP)
# 4.SSH Serverの有効化
Ubuntu Server なので不要ですが、Ubuntu Desktopの場合、OSインストール後の既定ではsshdは起動していません。これを有効にします。
```console:
$ sudo systemctl enable sshd
$ sudo systemctl start sshd
```
[<一番上>](#TOP)
# 5.sshの公開鍵認証の設定
ここでは、UbuntuのOpenSSHでの設定を説明します。
## sshクライアントの設定
ユーザ毎に実行します。ここでは、userというユーザ名で実行しています。
```shell
$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase):   # パスフレーズを入力 
Enter same passphrase again:                  # もう一度パスフレーズを入力 
Your identification has been saved in /home/user/.ssh/id_rsa
Your public key has been saved in /home/user/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:iLe4NIBlxVpnevX5QVBId2JpT/H167msiWDQ/Ecl55c user@ubuntu
The key's randomart image is:
+---[RSA 3072]----+
|   ..    .o+=.o..|
|   .o o . .o+o..o|
|  oo + . . + + oo|
| +. ....o o . * o|
|. . ..o.So . o E.|
|   . o .. . o . o|
|    + .  o . . o |
|   . o  . . o o .|
|    .      . o.o |
+----[SHA256]-----+
```
ユーザのホームディレクトリ(/home/user)の.sshディレクトリに`id_rsa`(秘密鍵）と`id_rsa.pub`（公開鍵）が作成されます。
サーバの同じユーザ(ここではuser)の`~/.ssh/`にクライアントで作成した公開鍵をコピーします。
```shell: クライアントからサーバにコピーする場合
$ scp ~/.ssh/id_rsa.pub serveｒ:~/.ssh/   #serverはサーバのIPもしくは名前
```
## サーバ(sshd)側の設定
サーバ側は、クライアントで作成した公開鍵（`.pub`)をサーバの`~/.ssh/authorized_keys`に追加する作業が必要です。`~/.ssh/authorized_keys`は既定で存在しない（もしくは空）ファイルなのでパーミッションも適切に設定する必要があります。以前は、[手動でのサーバ側設定](#手動でのサーバ側設定)に書いた通り一つひとつ手入力でやる方法が色々な解説で扱われていますが、今は、クライアントがopensshの場合、`ssh-copy-id`コマンド一発で完了します。
### `ssh-copy-id`でのサーバ設定
クライアント上で作業します。繰り返しになりますが、クライアントがopensshの場合の方法です。
```sh
% ssh-copy-id  user@host01.example.com
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/Users/user/.ssh/id_rsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
user@host01.example.com's password: 

Number of key(s) added:        1

Now try logging into the machine, with:   "ssh 'user@host01.example.com'"
and check to make sure that only the key(s) you wanted were added.

```
コマンドの結果に記載された、 `ssh user@host01.example.com`で結果を確認して下さい。パスワードなしで、ログインが完了すれば成功です。[手動でのサーバ側設定](#手動でのサーバ側設定)は読み飛ばして構いません。
[<一番上>](#TOP)
### 手動でのサーバ側設定
(1) 公開鍵(`.pub`)をサーバにコピー
サーバの同じユーザ(ここではuser)の`~/.ssh/`にクライアントで作成した公開鍵をコピーします。
```shell: クライアントからサーバにコピーする場合
$ scp ~/.ssh/id_rsa.pub serveｒ:~/.ssh/   #serverはサーバのIPもしくは名前
```
(2) authorized_keyに公開鍵をコピー
クライアントからコピーした、`id_rsa.pub`を`authorized_keys`に追加します。
```
cd ~/.ssh
cat ./id_rsa.pub >>./authorized_keys 
```
元々、`authorized_keys` は空のファイルですので、単純にコピーでもいいのですが、他のクライアントでも同じようにキーを作成して公開鍵認証をする場合には、公開鍵がそれぞれ違いますので、`authorized_keys`に追加していきます。
(3) authrized_keyの権限の設定
念の為、以下のとおりauthorized_keysのパーミッションを設定します。
```
$ chown user ~/.ssh/authorized_keys
$ chmod 600 ~/.ssh/authorized_keys
```
これで用意は完了したので、公開鍵認証でクライアントからサーバにsshで接続します

全てのユーザ全てのクライアントで、公開鍵認証が完了したら`/etc/ssh/sshd_config.d/50-cloud-init.conf`で`PasswordAuthentication yes`を`PasswordAuthentication no`に変更してパスワードでのｓｓｈ禁止した方がセキュリティ的には良いとされています。
[<一番上>](#TOP)
# 6.Timezoneの設定
```shell
$ date
Thu Jul  4 08:06:36 AM UTC 2024
$ sudo timedatectl set-timezone Asia/Tokyo
$ date
Thu Jul  4 05:07:56 PM JST 2024
```
## トラブルシューティング
TBD
[<一番上>](#TOP)
# 7.NTPの設定
既定で、systemd-timesyncd.service が動作しています。
```
$ sudo systemctl status systemd-timesyncd.service
● systemd-timesyncd.service - Network Time Synchronization
     Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
     Active: active (running) since Thu 2024-07-04 10:53:58 JST; 6h ago
       Docs: man:systemd-timesyncd.service(8)
   Main PID: 16736 (systemd-timesyn)
     Status: "Initial synchronization to time server [2620:2d:4000:1::41]:123 (ntp.ubuntu.com)."
      Tasks: 2 (limit: 2219)
     Memory: 1.3M
        CPU: 187ms
     CGroup: /system.slice/systemd-timesyncd.service
             └─16736 /lib/systemd/systemd-timesyncd

Jul 04 10:53:58 ubuntu systemd[1]: Started Network Time Synchronization.
Jul 04 10:54:56 ubuntu systemd-timesyncd[16736]: Network configuration changed, trying to establish connection.
Jul 04 10:54:56 ubuntu systemd-timesyncd[16736]: Network configuration changed, trying to establish connection.
Jul 04 10:54:56 ubuntu systemd-timesyncd[16736]: Network configuration changed, trying to establish connection.
Jul 04 10:54:56 ubuntu systemd-timesyncd[16736]: Network configuration changed, trying to establish connection.
Jul 04 10:54:56 ubuntu systemd-timesyncd[16736]: Network configuration changed, trying to establish connection.
Jul 04 10:54:56 ubuntu systemd-timesyncd[16736]: Network configuration changed, trying to establish connection.
Jul 04 10:54:56 ubuntu systemd-timesyncd[16736]: Network configuration changed, trying to establish connection.
Jul 04 10:54:58 ubuntu systemd-timesyncd[16736]: Network configuration changed, trying to establish connection.
Jul 04 10:54:32 ubuntu systemd-timesyncd[16736]: Initial synchronization to time server [2620:2d:4000:1::41]:123 (ntp.ubuntu.com).
```
設定ファイルは、`/etc/systemd/timesyncd.conf`です。ntp.nict.jpを指定します。
```config:/etc/systemd/timesyncd
[Time]
NTP=ntp.nict.jp
```
`sudo systemctl restart systemd-timesyncd.service`で再起動します。
`timedatectl timesync-status`で確認します。
```
$ timedatectl timesync-status
       Server: 2001:df0:232:eea0::fff3 (ntp.nict.jp)
Poll interval: 2min 8s (min: 32s; max 34min 8s)
         Leap: normal
      Version: 4
      Stratum: 1
    Reference: NICT
    Precision: 1us (-20)
Root distance: 0 (max: 5s)
       Offset: -17.548ms
        Delay: 5.724ms
       Jitter: 6.632ms
 Packet count: 2
    Frequency: +174.869ppm
```
[<一番上>](#TOP)
# 8.ホスト名について
Ubuntuのホスト名の設定や確認方法について説明します。
インタネットで検索すると、`hostname` コマンドや、/etc/hostname、/etc/hosts などの情報が出てきますが、私はインストールが終わって最初にログインした時に`hostnamectl  set-hostname fqdn`でホスト名＋ドメイン名の名前を設定することをお勧めします。
```shell:例: ホスト名がhost01、ドメインがexample.comとします。
$ sudo hostnamectl set-hostname host01.example.com
$
```
尚、OSインストール時に、ホスト名を設定する画面が出てきたと思います。そこでは、ドット(.)の入力ができないのでホスト名だけ入れたと思います。

ホスト名を確認するときには、`hostname`コマンドを実行します。
```shell:
$ hostname
host０１.example.com
$ hostname -s
host０１
$ hostname -f 
host０１.example.com
$ hostname -d
example.com
$ echo $HOSTNAME
host01.example.com
$ cat /etc/hostname
host01.example.com
$ cat /etc/hosts | grep 127.0.1.1
127.0.1.1 host01
```
`hostnamectl`で変更した内容は、`/etc/hostname`に書き込まれています。このファイルを、OS起動時に読み込んで、各種設定をしているようです。
尚、`/etc/hostname`は以前はホスト名だけを書くルールでしたが、現在は、FQDNで設定して構わないそうです。（`man hostname`を参照）
`domainname`というコマンドもありますが、NISのDomainのコマンドなので使用しないでください。
[<一番上>](#TOP)
# 9.bashプロンプトの設定
Ubuntuのデフォルトshellはbashです。
```shell
$ echo $SHELL
/bin/bash
$ printenv |grep SHELL
SHELL=/bin/bash
```
BashではPromptはPS1という環境変数で指定されています。
```shell:$ echo $PS1
\[\e]0;\u@\h: \w\a\]${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$
```
環境変数:PS1を各ユーザの`~/.bashrc`で設定すれば、ログインするたびに設定されます。
```shell: vi .bashrc
（略）
if [ "$color_prompt" = yes ]; then
        PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h: \[\033[00m\](\[\033[01;34m\]\w\[\033[00m\]\$ '　　　　←カラー端末のプロンプト
else
        PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '　　　←モノクロ用。
fi
unset color_prompt force_color_prompt

# If this is an xterm set the title to user@host:dir
case "$TERM" in
xterm*|rxvt*)
    PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a\]$PS1"   ←xterm用のプロンプト。
（略）

```

いくつか、設定を説明します。
`\u` - 現在のユーザ名
`\H` - ホスト名(FQDN)を表示する。
`\$` - UID:0 (root) の場合＃、それ以外の場合は＄
`\W` - 現在の作業ディレクトリ
`\\` -　バックスラッシュ

私は、基本的にプロンプトを`user@host.example.com:/home/user`に統一していますので、それに変更する方法を説明します。ポイントはホスト名がFQDNで現在のディレクトリがフルパスという点です。
```shell:
user@host01:~$ export PS1="\[\e]0;\u@\H: \W\a\]${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\H: \[\033[00m\]\[\033[01;34m\]$PWD\[\033[00m\] \$"
user@host01.example.com: /home/user$
```
`\h`(ホスト名） を`\H`(FQDN)に変更します。
`\w`(ホームディレクトリからのパス) を＄PWD（現在のディレクトリのフルパスの環境変数）に変更します。

`\H` が意図した通りにならない場合は、`\H`を`$(hostname -f)`に変更して下さい。
# 新しいユーザにも同じポリシーを設定する
`adduser`で作ったユーザにも同じプロンプトにしたい場合は、`/etc/skel/.bashrc` をコピーしてくるのでこのファイルを変更すれば、新しく作成したユーザにも同じプロンプトが適用されます。

[<一番上>](#TOP)
# 10. rootのパスワード
rootのパスワードは既定で設定されていません。
そのため、rootでログインはできません。
rootでログインしたい場合は、sudo権限を持つユーザでログインした後に`sudo su`を実行しましょう。
```sh:
user01@ubuntu:~$ sudo su       ←現在のユーザ(user01)の環境変数でログイン(su)
root@ubuntu:~# exit
exit
user01@ubuntu:~$ sudo su -      ←rootの環境変数でログイン(su)
root@ubuntu:~# exit
logout
user01@ubuntu:~$ 
```
お勧めしませんが、以下の方法でrootのパスワードの設定が可能です
```sh:
$ sudo passwd root
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
$ su -
root@ubuntu:~#
```
[<一番上>](#TOP)
# 11.Active Directory ユーザとの連携
構成:
1. Active Drectory ドメイン： example.com
1. ドメインコントローラ(DNSサーバ）: dc.example.com(172.24.0.11)
1. ユーザのプライマリグループ: Domain Users
1. AD管理者ユーザ: admin
1. 一般ユーザ: user

事前の確認事項
1. ***ドメインコントローラの名前の逆引きが正しくできること。` dig -x 172.24.0.11`***
1. [Timezone](#6timezoneの設定) と[NTPの設定](#7ntpの設定)を確認します。
1. [ホスト名](#8ホスト名について)の設定を行って下さい。
1. このUbuntuのホスト名（`hostname -s`の結果）のコンピュータアカウントがAD上に存在しないことを確認します。存在する場合は、削除して下さい。
1. `dig -t NS example.exe`が成功すること


## パッケージをインストールします。
```
$ sudo apt update
$ sudo apt upgrade
$ sudo apt install sssd-ad sssd-tools realmd adcli samba-common-bin
```
## ADドメインがDiscoverできるか確認
```sh:
$ sudo realm -v discover example.com
 * Resolving: _ldap._tcp.snwltac.com
 * Performing LDAP DSE lookup on: 172.24.0.11
 * Successfully discovered: example.com
example.com
  type: kerberos
  realm-name: EXAMPLE.COM
  domain-name: example.com
  configured: no
  server-software: active-directory
  client-software: sssd
  required-package: sssd-tools
  required-package: sssd
  required-package: libnss-sss
  required-package: libpam-sss
  required-package: adcli
  required-package: samba-common-bin
```
## ADにjoinします。
```sh: ADにjoinする
$ sudo realm join --user=admin example.com
Password for admin: 
＄　
```
## SSSDの構成情報
構成情報は、`/etc/sssd/sssd.conf`です。
```conf: sudo vi /etc/sssd/sssd.conf
[sssd]
domains = example.com
config_file_version = 2
services = nss, pam

[domain/example.com]
default_shell = /bin/bash
krb5_store_password_if_offline = True
cache_credentials = True
krb5_realm = EXAMPLE.COM
realmd_tags = manages-system joined-with-adcli
id_provider = ad
fallback_homedir = /home/%u@%d
ad_domain = example.com
use_fully_qualified_names = True
ldap_id_mapping = True
access_provider = ad
```
既定のホームディレクトリは`fallback_homedir = /home/%u@%d`でuser@example.comになっています。
'realm list' を確認します。
```sh:
$ sudo realm list
snwltac.com
  type: kerberos
  realm-name: SNWLTAC.COM
  domain-name: snwltac.com
  configured: kerberos-member
  server-software: active-directory
  client-software: sssd
  required-package: sssd-tools
  required-package: sssd
  required-package: libnss-sss
  required-package: libpam-sss
  required-package: adcli
  required-package: samba-common-bin
  login-formats: %U@%D
  login-policy: allow-realm-logins
```
'login-formats: %U@%D'となっていますので、既定でADユーザの場合、`user@example.com`と指定します。
## ホームディレクトリの作成
ログインしてテストする前に、もう一つ、設定を行います。ローカルにユーザを作成しないので、ホームディレクトリを作成する機会がありません。そのため、はじめてログインする時に自動でホームディレクトリを作成するように設定します。
```sh:
$ sudo pam-auth-update --enable mkhomedir
$ 
```
## 接続試験
それでは実際にクライアントからsshでログインしてみます。
```
$ ssh -l user01@example.com host01.example.com
user01@example.com@host01.example.com's password:  
$ user01@example.com@host01:~$ pwd
/home/user01@example.com
$ 
```
プロンプトからユーザ名:`user01@example.com` でログインしていることがわかります。またホームディレクトリが`/home/user01@example.com` になっています。
id コマンドも確認してみます。
```
$ id user01@example.com
uid=635401603(user01@example.com) gid=635400513(domain users@example.com) groups=635400513(domain users@example.com),635400512(domain admins@example.com)
```
このユーザ：`user01@example.com`のプライマリグループは`domain users@example.com`（ADではDomain Users)で、他に`domain admins@example.com`(ADではDomain Admins)のグループのメンバーであることがわかります。
## ユーザの指定とホームディレクトリの変更
毎回、ユーザ名を`user01@example.com`の形式で指定するのは煩雑です。`user01`だけで済むようにします。またホームディレクトリも`/home/user01`にします。`/etc/sssd/sssd.conf`を２箇所変更します。
`fallback_homedir = /home/%u@%d` > `fallback_homedir = /home/%u`
`use_fully_qualified_names = True` > `use_fully_qualified_names = False`
変更の後、`sudo systemctl restart sssd` でSSSDをリスタートします。
## sudoersの設定
最後に、Domain Adminsのメンバが`sudo`ができるように`/etc/sudoers`に以下の1行を追加します。
```vim: visudo
%domain\ admins ALL=(ALL) ALL
```
ユーザ名の形式が、`user01@example.com`の場合、`domain\ admins`は`domain\ admins@example.com`と指定します。
## もう一度試験
最後に変更を確認するためにもう一度sshを行います。
```shell:
$ ssh -l user01 host01.example.com      <-ユーザとしてuser01を指定します。
user01@host01.example.com's password:  
$ user01@host01:~$ pwd　　　　　　　　　　　　<- ホームディレクトリの確認
/home/user01
$ 
$ id user01　　　　　　　　　<- idもシンプルになりました。
uid=635401603(user01) gid=635400513(domain users) groups=635400513(domain users),635400512(domain admins)
$ 
$ sudo su    <-sudo できることを確認します。
Password:
#
```
[<一番上>](#TOP)
# 12.Desktop環境とXRDPのインストール
Serverなので不要ではありますが、Desktop 環境をインストールして、xRDPもインストールすれば、WindowsやMac からリモートデスクトップでアクセスできます。
デスクトップ環境に好みはあるかもしれませんが、ここでは、GNOMEをインストールします。
## Wbuntu ServerへDesktop環境をインストールする
```sh:
$ sudo apt install ubuntu-desktop task-gnome-desktop
```
結構時間がかかります。
## xRDPのインストール
xRDPのインストールは[Easy install xRDP on Ubuntu](https://c-nergy.be/blog/?cat=79) をお勧めします。
ダウンロードの仕方から使用方法までホームページに記載されています。ここでは、バージョン1.5.2の場合で説明します。

:::note warn
このシェルスクリプトは、デスクトップ環境がインストールされていることが前提で、~/Downloads/で実行されていることが前提です。また、ユーザはsuperuserではない、通常のユーザーで実行することが重要です。なお実行時にaptなどですどが必要なので、パスワードの入力を求められます。
:::

### Step 1 – Download the script
```sh:
cd ~/Downloads/
wget https://www.c-nergy.be/downloads/xRDP/xrdp-installer-1.5.2.zip
```
### Step 2 – unzip the file 
```sh:
unzip xrdp-installer-1.5.2.zip 
chmod +x  ~/Downloads/xrdp-installer-1.5.2.sh
```
### Step 3 – Perform xRDP installation using the script
スクリプト実行時のオプション等は、ホームページで確認してください。ここではもっともシンプルな方法で説明します。
```sh:
./xrdp-installer-1.5.2.sh
```
sudoのパスワードや、複数デスクトップマネージャが入っている場合はどれを使うかなど聞かれます。

これで、WindowsやMacのRDPクライアントからログインできるようになります。
## ADユーザでのログイン
ADユーザでログインする場合は、`/etc/sssd/sssd.conf` に以下の２行を追加し、`sudo systemctl restart sssd`でsssdをリスタートします。
```sh: vi /etc/sssd/sssd.conf
ad_gpo_access_control = enforcing
ad_gpo_map_remote_interactive=+xrdp-sesman
```
[<一番上>](#TOP)