Help us understand the problem. What is going on with this article?

Linuxのユーザー管理をActive Directoryでやってみる

LinuxのユーザーをActive Directoryで管理する方法です。
複数台での共通のユーザーを管理したい場合などに使えます。

環境

  • AD (AWS Directory Service for Microsoft Active Directory)
  • AmazonLinux2 on EC2
  • WindowsServer2019 on EC2 (AD管理用)

鍵認証を行うためにはADのスキーマ拡張が必要だったため、SimpleADではなく、Microsoft Active Directoryを使っています。
(SimpleADでも頑張ればできそうな記事もあったけ途中で挫折...)
https://github.com/localytics/chef-sssd/blob/master/GETTING_STARTED.md
https://teratail.com/questions/153872
WindowsServerはADのユーザー作成/削除で利用するので、普段は停止にしておいてOKです。

AWS Directory Service for Microsoft Active Directoryの準備

マネジメントコンソールからADを立てていきます。
スクリーンショット 2019-11-13 12.22.30.png

ADのタイプはAWS Mabager Microsoft ADを選択します。

スクリーンショット 2019-11-13 12.22.37.png

エディションは規模に応じて選択してください。
今回はディレクトリのDNS名はad.localとします。
Adminパスワードは任意のものを入れてください。
スクリーンショット 2019-11-13 12.23.24.png

ADを立てたいVPCとサブネットを選択します。冗長構成となるためサブネットが2つ以上あるVPCが必要です。
スクリーンショット 2019-11-13 12.23.48.png

設定した内容を確認してディレクトリの作成をクリックします。
スクリーンショット 2019-11-13 12.24.13.png

構築が完了するまで待ちます。(30分ほどかかりました)
スクリーンショット 2019-11-13 12.26.31.png

ADがアクティブになったら拡張スキーマを登録します。作成したディレクトリIDをクリックします。
スクリーンショット 2019-11-13 15.41.55.png

メンテナンスタブのスキーマ拡張のアクションからスキーマをアップロードします。
スクリーンショット 2019-11-13 15.49.45.png

アップロードするスキーマは以下です。

ssh_local.ldif
dn: CN=sshPublicKey,CN=Schema,CN=Configuration,DC=ad,DC=local
changetype: add
objectClass: top
objectClass: attributeSchema
attributeID: 1.3.6.1.4.1.1466.115.121.1.40
cn: sshPublicKey
name: sshPublicKey
lDAPDisplayName: sshPublicKey
description: Users public SSH key
attributeSyntax: 2.5.5.5
oMSyntax: 22
isSingleValued: FALSE

dn: CN=ldapPublicKey,CN=Schema,CN=Configuration,DC=ad,DC=local
changetype: add
objectClass: top
objectClass: classSchema
governsID: 1.3.6.1.4.1.24552.500.1.1.2.0
cn: ldapPublicKey
name: ldapPublicKey
description: MANDATORY: OpenSSH LPK objectclass
lDAPDisplayName: ldapPublicKey
subClassOf: top
objectClassCategory: 3
defaultObjectCategory: CN=ldapPublicKey,CN=Schema,CN=Configuration,DC=ad,DC=local
mayContain: sshPublicKey

dn: CN=User,CN=Schema,CN=Configuration,DC=ad,DC=local
changetype: modify
add: auxiliaryClass
auxiliaryClass: ldapPublicKey
-

作成したスキーマをアップロードします。これも反映に30分ほどかかります。
スクリーンショット 2019-11-13 15.41.55.png

これでssh鍵認証に対応したADサーバの準備が完了しました。

ADサーバの詳細画面からIPアドレスを確認しておきます。
スクリーンショット 2019-11-19 17.56.38.png

AD上にユーザーを作成

ADと同一VPC内にユーザー作成用のWindowsServerを起動して、ログインします。
AD関連のツールをインストールします。

スクリーンショット 2019-11-19 14.06.35.png

DNSをADサーバに変更します。
スクリーンショット 2019-11-19 14.06.57.png

WindowsServerをADに参加させます。
スクリーンショット 2019-11-19 14.07.17.png

変更をクリックします。
スクリーンショット 2019-11-19 14.07.28.png

設定したドメインを入力してOKをクリックします。
スクリーンショット 2019-11-19 14.07.41.png

AD構築時に作成したAdminユーザー(Admin@ad.local)のログイン情報を入力します。
スクリーンショット 2019-11-19 14.08.06.png

ADへのログインに成功するとポップアップが表示されますので、一度OSの再起動をします。
スクリーンショット 2019-11-19 14.08.17.png

ADユーザーでRDPでログインを行います。
スクリーンショット 2019-11-19 14.09.21.png

ログイン後「ActiveDirectory ユーザーとコンピューター」を開きます。ADのツリーが表示されるので、 ad.local -> ad -> Usersを開き、ユーザーを追加します。
スクリーンショット 2019-11-19 14.11.40.png

ここではuser01というユーザーを作成します。
スクリーンショット 2019-11-19 14.12.03.png

パスワードを入力します。次回ログイン時のパスワードは無効にしておきます。
スクリーンショット 2019-11-19 14.12.23.png

user01@ad.local というユーザーの作成に成功しました。
スクリーンショット 2019-11-19 14.12.30.png

スクリーンショット 2019-11-19 14.12.42.png

公開鍵を入力するための拡張スキーマの表示を有効にします。
スクリーンショット 2019-11-19 14.12.57.png

作成したユーザーの属性エディタタブから、sshPublicKeyを探して、編集をクリックします。
スクリーンショット 2019-11-19 14.13.22.png

利用する公開鍵を入力して、追加をクリックします。
スクリーンショット 2019-11-19 14.14.38.png

OKを押して保存します。
スクリーンショット 2019-11-19 14.14.47.png

スクリーンショット 2019-11-19 14.14.55.png

これで公開鍵が登録されたユーザーの作成が完了です。

Linux側のAD連携

AmazonLinux2をADに接続できるVPCに起動します。(同一VPCやVPCPeeringなど)

ADの連携をします。

# DNSの書き換えを停止
sed -i 's/PEERDNS=yes/PEERDNS=no/g' /etc/sysconfig/network-scripts/ifcfg-eth0

# DNSをADサーバに変更
vi /etc/resolv.conf
----
nameserver 172.31.22.192
nameserver 172.31.47.137
----

# AD連携に必要なパッケージをインストールします。
yum update
yum -y install samba-common openldap-clients krb5-wokstation adcli sssd realmd  samba-common openldap-clients  adcli samba-client samba-winbind ldb-tools

# ADにログインします。
realm join -U Admin@ad.local ad.local --verbose
-----
 * Resolving: _ldap._tcp.ad.local
 * Performing LDAP DSE lookup on: 172.31.47.137
 * Performing LDAP DSE lookup on: 172.31.22.192
 * Successfully discovered: ad.local
Password for Admin@ad.local:
 * Required files: /usr/sbin/oddjobd, /usr/libexec/oddjob/mkhomedir, /usr/sbin/sssd, /usr/bin/net
 * Joining using a truncated netbios name: IP-172-31-20-17
 * LANG=C LOGNAME=root /usr/bin/net -s /var/cache/realmd/realmd-smb-conf.JZ5OB0 -U Admin@ad.local ads join ad.local
Enter Admin@ad.local's password:DNS update failed: NT_STATUS_INVALID_PARAMETER

Using short domain name -- ad
Joined 'IP-172-31-20-17' to dns domain 'ad.local'
No DNS domain configured for ip-172-31-20-17. Unable to perform DNS Update.
 * LANG=C LOGNAME=root /usr/bin/net -s /var/cache/realmd/realmd-smb-conf.JZ5OB0 -U Admin@ad.local ads keytab create
Enter Admin@ad.local's password:
 * /usr/bin/systemctl enable sssd.service
Created symlink from /etc/systemd/system/multi-user.target.wants/sssd.service to /usr/lib/systemd/system/sssd.service.
 * /usr/bin/systemctl restart sssd.service
 * /usr/bin/sh -c /usr/sbin/authconfig --update --enablesssd --enablesssdauth --enablemkhomedir --nostart && /usr/bin/systemctl enable oddjobd.service && /usr/bin/systemctl start oddjobd.service
 * Successfully enrolled machine in realm
 ----


# sssdの設定(ファイル置き換え)
vi /etc/sssd/sssd.conf
---
[sssd]
domains = ad.local
config_file_version = 2
services = nss, pam, ssh, sudo
[nss]
filter_users = root,named,avahi,haldaemon,dbus,radiusd,news,nscd,centos,ubuntu
[pam]
[ssh]
[sudo]
[domain/ad.local]
ad_domain = ad.local
krb5_realm = AD.LOCAL
realmd_tags = manages-system joined-with-samba
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = True
fallback_homedir = /home/%u@%d
access_provider = ad
ldap_user_ssh_public_key = sshPublicKey
ad_enable_gc = false
----

# sshdの設定(一部書き換え)
vi /etc/ssh/sshd_config
----
#sshはパスワードログイン無効にします。
PasswordAuthentication no

# 公開鍵をADから取得する設定。既存の設定はコメントアウト。
# AuthorizedKeysCommand /opt/aws/bin/eic_run_authorized_keys %u %f
# AuthorizedKeysCommandUser ec2-instance-connect
AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
AuthorizedKeysCommandUser root
----

# ADでログインしたユーザーもsudoできるように設定(必要であれば)
visudo
----
#"%domain users@ad.local" ALL=(ALL) NOPASSWD:ALL
"%domain users@ad.local" ALL=(ALL) ALL
----

# 動作確認用にFTPサーバをインストール(FTPはパスワード認証)
yum install  vsftpd
systemctl enable vsftpd

# 一度OS再起動します(サービス毎の再起動でも多分OK)
reboot

接続確認

SSH

user01@ad.local ユーザーでsshしてみます。ADに登録した公開鍵に対応する秘密鍵を指定します。
sudoもできました。

ssh -i AD-TEST.pem.txt user01@ad.local@13.115.75.104
Last login: Tue Nov 19 05:23:38 2019

       __|  __|_  )
       _|  (     /   Amazon Linux 2 AMI
      ___|\___|___|

https://aws.amazon.com/amazon-linux-2/
[user01@ad.local@ip-172-31-20-172 ~]$ sudo su -

あなたはシステム管理者から通常の講習を受けたはずです。
これは通常、以下の3点に要約されます:

    #1) 他人のプライバシーを尊重すること。
    #2) タイプする前に考えること。
    #3) 大いなる力には大いなる責任が伴うこと。

パスワード:
最終ログイン: 2019/11/19 (火) 06:13:55 UTC日時 pts/0
[root@ip-172-31-20-172 ~]#

FTP

user01@ad.local ユーザーとパスワードでログインができます。

スクリーンショット 2019-11-20 16.40.16.png

スクリーンショット 2019-11-20 16.41.20.png

注意点

sssdはキャッシュが結構効くので間違えて登録した場合などは一度キャッシュを消すとうまくいく場合ありです。

参考
https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/6/html/deployment_guide/sssd-cache

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away