1. システム・アカウントおよび認証の設定
  2. 認証構成

1 認証構成

警告:

Oracle Linux 7は現在延長サポート中です。詳細は、Oracle Linux拡張サポートおよびOracleオープン・ソース・サポート・ポリシーを参照してください。

できるだけ早くアプリケーションとデータをOracle Linux 8またはOracle Linux 9に移行してください。

この章では、Oracle Linuxで使用できるNIS、LDAP、Kerberos、Winbindなどの様々な認証方法を構成する方法、およびSystem Security Services Daemon機能を構成してアイデンティティおよび認証を集中管理する方法について説明します。

認証について

認証とは、システムに対してエンティティ(ユーザーなど)のアイデンティティを検証することです。ユーザーはユーザー名とパスワードを入力してログインし、オペレーティング・システムはこの情報とシステムに保存されているデータを比較してユーザーのアイデンティティを認証します。ログイン資格証明が一致し、ユーザー・アカウントがアクティブな場合、ユーザーは認証され、システムに正常にアクセスできます。

ユーザーのアイデンティティを検証する情報は、ローカル・システムの/etc/passwdおよび/etc/shadowファイル、またはIdentity Policy Audit (IPA)、Lightweight Directory Access Protocol (LDAP)、Network Information Service (NIS)またはWinbindを使用してリモート・システムに置くことができます。さらに、IPSv2、LDAPおよびNISデータ・ファイルではKerberos認証プロトコルを使用できるため、セキュアでないネットワーク上で通信しているノードがセキュアな方法で互いにアイデンティティを証明できます。

認証構成GUI (system-config-authentication)を使用して認証メカニズムを選択し、関連する認証オプションを構成できます。authconfigコマンドを使用することもできます。認証構成GUIおよびauthconfigの両方で、/etc/pam.dディレクトリにあるPAM構成ファイルの設定が調整されます。authconfig-gtkパッケージをインストールする場合は、認証構成GUIを使用できます。

図1-1 ローカル・アカウントの認証構成


この図は、ローカル・アカウントのみが選択された認証構成GUIを示しています。

ローカルでのOracle Linux認証について

インストール時に、または認証構成GUIあるいはauthconfigコマンドを使用して、別の認証メカニズムを選択しないかぎり、Oracle Linuxは/etc/passwdおよび/etc/shadowファイルに保存されている情報を使用してユーザーのアイデンティティを検証します。

/etc/passwdファイルには、ユーザーの一意のユーザーID (整数のUID)、ユーザー名、ホーム・ディレクトリ、ログイン・シェルなどの各ユーザーのアカウント情報が格納されます。ユーザーは、ユーザー名を使用してログインしますが、オペレーティング・システムでは、関連付けられているUIDが使用されます。ユーザーがログインすると、ホーム・ディレクトリに移動し、ログイン・シェルが実行されます。

/etc/groupファイルには、ユーザーのグループに関する情報が格納されます。また、ユーザーは1つ以上のグループに属し、各グループには1つ以上のユーザーを含めることができます。グループにアクセス権限を付与できる場合は、そのグループのすべてのメンバーに同じアクセス権限が付与されます。各グループ・アカウントには、一意のグループID (整数のGID)と関連するグループ名を指定します。

Oracle Linuxには、デフォルトでユーザー・プライベート・グループ(UPG)スキームが実装され、ユーザー・アカウントを追加すると、対応するUPGがそのユーザーと同じ名前で作成され、作成されたユーザーがその唯一のメンバーになります。

ユーザー・アカウントおよびグループ・アカウントの追加、変更または削除を実行できるのは、rootユーザーのみです。デフォルトでは、ユーザーとグループの両方に暗号でハッシュされたshadowパスワードが使用され、/etc/shadowと/etc/gshadowにそれぞれ格納されます。これらのshadowパスワード・ファイルを読み取ることができるのは、rootユーザーのみで、rootは、newgrpコマンドを使用して、ユーザーがグループのメンバーになるために入力する必要があるグループ・パスワードを設定できます。グループにパスワードが設定されていない場合は、rootがユーザーをメンバーとして追加する場合にのみ、ユーザーはグループに属することができます。

/etc/login.defsファイルには、パスワードのエージングおよび関連するセキュリティ・ポリシーのパラメータが定義されます。

これらのファイルの内容の詳細は、group(5)、gshadow(5)、login.defs(5)、passwd(5)およびshadow(5)の各マニュアル・ページを参照してください。

ローカル・アクセスの構成

ユーザー・マネージャGUI (system-config-users)を使用すると、ユーザーおよびグループを追加または削除したり、パスワード、ホーム・ディレクトリ、ログイン・シェル、グループ・メンバーシップなどの設定を変更できます。また、useraddやgroupaddなどのコマンドを使用できます。system-config-usersパッケージをインストールする場合は、ユーザー・マネージャGUIを使用できます。

ローカル・アクセス制御を有効にするには、認証構成GUI (system-config-authentication)の「詳細オプション」タブでローカル・アクセス制御の有効化チェック・ボックスを選択します。これによってシステムは、受け入れるか拒否するログインの組合せが指定されたローカル・ユーザー認証ルールに関する/etc/security/access.confファイルを読み取ることができます。

図1-2 認証構成の詳細オプション


この図は、「詳細オプション」タブが選択された認証構成GUIを示しています。

または、次のコマンドを使用します。 

# authconfig --enablepamaccess --update

/etc/security/access.confの各エントリの形式は、次のとおりです。 

permission : users : origins [ except ]

ファイル内の各エントリの説明を次に示します。

permission

ログインをそれぞれ付与または拒否するには、+または-に設定します。

users

ユーザー名またはグループ名のスペースで区切ったリストを指定するか、すべてのユーザーまたはグループの場合はALLを指定します。グループ名は、ユーザー名と区別するためにカッコで囲みます。ルールからユーザーのリストを除外するには、EXCEPT演算子を使用します。

origins

ホスト名のスペースで区切ったリスト、完全修飾ドメイン名、ネットワーク・アドレス、端末デバイス名を指定するか、ALLまたはNONEを指定します。ルールから元のリストを除外するには、EXCEPT演算子を使用します。

たとえば、次のルールでは、ネットワーク192.168.2.0/24のrootを除いたすべてユーザーのログイン・アクセスを拒否します。 

- : ALL except root : 192.168.2.0/24

詳細は、access.conf(5)マニュアル・ページおよびローカル・アカウント構成を参照してください。

指紋リーダー認証の構成

適切なハードウェアがインストールおよびサポートされている場合は、ユーザーの認証に指紋スキャンを使用できます。

指紋リーダー・サポートを有効にするには、認証構成GUI (system-config-authentication)の「詳細オプション」タブで指紋リーダー・サポートの有効化チェック・ボックスを選択します。

または、次のコマンドを使用します。 

# authconfig --enablefingerprint --update

スマート・カード認証の構成

適切なハードウェアがインストールおよびサポートされている場合は、ユーザーの認証にスマート・カードを使用できます。pam_pkcs11パッケージには、X.509証明書ベースのユーザー認証を有効にするPAMログイン・モジュールが用意されています。このモジュールは、ローカルに格納されているルートCA証明書、オンラインまたはローカルでアクセス可能な証明書失効リスト(CRL)、およびオンライン証明書ステータス・プロトコル(OCSP)を使用することで、名前サービス・スイッチ(NSS)を使用し、PKCS #11スマート・カードを管理および検証します。

スマート・カード認証を有効にするには:

  1. pam_pkcs11パッケージをインストールします。 

    # yum install pam_pkcs11

  2. 次のコマンドを使用して、NSSデータベースにルートCA証明書をインストールします。 

    # certutil -A -d /etc/pki/nssdb -t "TC,C,C" -n "Root CA certificates" -i CACert.pem

    前のコマンドで、CACert.pemはbase-64形式のルートCA証明書ファイルです。

  3. 認証構成GUIを実行します。 

    # system-config-authentication

  4. 「詳細オプション」タブで、スマート・カード・サポートの有効化チェック・ボックスを選択します。

  5. 他のすべての認証方法を無効にする場合は、ログインにはスマート・カードが必須チェック・ボックスを選択します。

    注意:

    このオプションは、システムでの認証にスマート・カードを使用できることをテストするまで選択しないでください。

  6. カード取外しアクション・メニューから、ユーザーがセッションへのログイン中にスマート・カードを取り外した場合のシステムの対応を選択します。

    無視

    現在のセッションでのカードの取外しを無視します。

    ロック

    セッションからユーザーをロックします。

次のコマンドを使用して、スマート・カード認証を構成することもできます。 

# authconfig --enablesmartcard --update

ユーザーがセッションへのログイン中にスマート・カードを取り外した場合のシステムの対応を指定するには: 

authconfig --smartcardaction=0|1 --update

カードが取り外された場合にシステムをロックするには、値0を--smartcardactionに指定します。カードの取外しを無視するには、値1を使用します。

システムでの認証にスマート・カードを使用できることをテストした後は、他のすべてのログイン認証方法を無効にできます。 

# authconfig --enablerequiresmartcard --update

IPA認証について

IPAにより、DNS、Kerberosおよび認可ポリシーのドメイン・コントローラをActive Directoryサービスのかわりとして設定できます。クライアント・マシンがシングル・サインオン認証用の情報にアクセスできるように、クライアント・マシンをIPAドメインに登録できます。IPAは、証明書サービス、DNS、LDAP、Kerberos、LDAP、NTPなどのよく知られた既存のテクノロジの機能を統合します。

IPA認証の構成

IPA認証を構成するには、yumを使用してipa-clientおよびipa-admintoolsパッケージをインストールします。ipa-serverパッケージは、システムをIPAサーバーとして構成する場合のみ必要です。

認証構成GUIでは、IPAの2つのバージョンから選択できます。

  • FreeIPA (実際はIPAv1)はユーザーおよびグループのアイデンティティ管理と認証をサポートしており、システムをIPAレルムに参加させる必要はありません。LDAPおよびKerberos構成に関する情報を入力します。

  • IPAv2はマシンのアイデンティティ管理と認証をサポートしており、システムをIPAレルムに参加させる必要があります。IPAドメイン構成を入力、またはNTPを構成し、ドメインに参加をクリックしてIPAサーバーにマシン・アカウントを作成します。IPAレルムに参加する権限がシステムに付与されたら、認証方法を選択して構成します。

認証構成GUIを使用してIPA v2をユーザー・アカウント・データベースとして選択する場合、IPAドメイン、レルムおよびサーバーの名前を入力するよう求められます。NTPを構成して、システム時間をIPAサーバーと一致させることもできます。Kerberosが初期化されている場合は、ドメインに参加をクリックしてIPAサーバー上にマシン・アカウントを作成し、ドメインに参加する権限を付与できます。

IPAの構成の詳細は、http://www.freeipa.org/page/Documentationを参照してください。

LDAP認証について

Lightweight Directory Access Protocol (LDAP)を使用すると、クライアント・システムは、ネットワーク上のLDAPサーバーに格納されている情報にアクセスできます。LDAPディレクトリ・サーバーは、検索および参照用に最適化されたディレクトリベースのデータベースに情報を格納し、そのデータベースのエントリをアクセスして更新するための簡単な機能もサポートしています。

データベース・エントリは階層ツリー構造に配置されており、各ディレクトリには、名前、アドレス、電話番号、ネットワーク・サービス情報、プリンタ情報、その他の様々なタイプの構造化データなどの情報を格納できます。システムで認証用にLDAPを使用すると、ユーザーはネットワーク上のマシンから各自のアカウントにアクセスできます。

LDAPディレクトリの最小単位の情報は、1つ以上の属性を指定できるエントリです。エントリの各属性には、名前(属性タイプまたは属性の説明とも呼ばれる)と1つ以上の値を指定します。タイプの例として、ドメイン・コンポーネント(dc)、共通名(cn)、組織単位(ou)および電子メール・アドレス(mail)があります。objectClass属性を使用すると、属性が必須かオプションかを指定できます。objectClass属性の値は、エントリが従う必要があるスキーマ・ルールを指定します。

識別名(dn)は、LDAPのエントリを一意に識別します。識別名は、エントリ名(相対的識別名(RDN))にLDAPディレクトリ階層内の上位エントリの名前を結合して構成されます。たとえば、RDNがuid=arc815のユーザーの識別名は、uid=arc815,ou=staff,dc=mydom,dc=comです。

次に、LDAPに格納されているユーザーの情報の例を示します。 

# User arc815
dn: uid=arc815,ou=People,dc=mydom,dc=com
cn: John Beck
givenName: John
sn: Beck
uid: arc815
uidNumber: 5159
gidNumber: 626
homeDirectory: /nethome/arc815
loginShell: /bin/bash
mail: johnb@mydom.com
objectClass: top
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
userPassword: {SSHA}QYrFtKkqOrifgk8H4EYf68B0JxIIaLga

グループの場合は、次のとおりです。 

# Group employees
dn: cn=employees,ou=Groups,dc=mydom,dc=com
cn: employees
gidNumber: 626
objectClass: top
objectClass: posixGroup
memberUid: arc815
memberUid: arc891

LDAP Data Interchange Formatについて

LDAPデータ自体は、バイナリ形式で格納されます。LDAP Data Interchange Format (LDIF)はLDAPエントリのプレーン・テキスト表現で、これによって、通常はLDAPデータをインポートおよびエクスポートしてシステム間でデータを転送できますが、テキスト・エディタを使用して内容を変更することもできます。

LDIFファイルのエントリのデータの形式は、次のとおりです。 

[id] dn: distinguished_name
       attribute_type:value | [attribute=]value[, [attribute=] value]...
...
objectClass: value
...

オプションのid番号は、エントリの編集に使用するアプリケーションによって決まります。エントリの各属性タイプには、値、またはLDAPディレクトリ・スキーマで定義された属性と値のペアのカンマ区切りのリストが含まれます。

各dn定義セクション間またはinclude:行間には空白行を含める必要があります。その他の空白行を含めたり、行末に空白を含めたりしないでください。行頭の空白は、前の行から継続していることを示します。

LDAPサーバーの構成

OpenLDAPはLDAPのオープン・ソースの実装であり、これを使用してLDAPディレクトリ・サーバーを構成できます。

システムをLDAPサーバーとして構成するには:

  1. OpenLDAPパッケージをインストールします。 

    # yum install openldap openldap-servers openldap-clients nss-pam-ldapd

    OpenLDAP構成は、/etc/openldapの下の次のファイルに格納されます。

    ldap.conf

    クライアント・アプリケーションの構成ファイル。

    slapd.d/cn=config.ldif

    OpenLDAPのデフォルトのグローバル構成LDIFファイル。

    slapd.d/cn=config/*.ldif

    データベースおよびスキーマの構成LDIFファイル。

    slapd.d/cn=config/cn=schema/*.ldif

    スキーマ構成LDIFファイル。OpenLDAPスキーマの詳細は、OpenLDAP管理者ガイド(https://www.openldap.org/doc/)を参照してください。

    ノート:

    /etc/openldap/slapd.dの下にあるファイルは、slapdサービスの実行時にOpenLDAPを再構成できるため編集する必要はありません。

  2. SSLトンネル(ldaps://)経由の接続をポート636でリスニングするようにslapdを構成する場合は、/etc/sysconfig/slapdを編集し、SLAPD_LDAPSの値をyesに変更します。 

    SLAPD_LDAPS=yes

    必要に応じて、slapdがldap://接続をポート389でリスニングしないようにするには、SLAPD_LDAPの値をnoに変更します。 

    SLAPD_LDAP=no

    有効化されているポートの正しいSLAPD_URLSも定義していることを確認します。たとえば、SSLを使用し、slapdをポート636でリスニングする場合、サポートされているURLSの1つとしてldaps://を指定する必要があります。たとえば: 

    SLAPD_URLS="ldapi:/// ldap:/// ldaps:///"

  3. たとえば、システム・ファイアウォールを構成して、ポート389への着信TCP接続を許可します。 

    # firewall-cmd --zone=zone --add-port=389/tcp
# firewall-cmd --permanent --zone=zone --add-port=389/tcp

    LDAPのプライマリTCPポートは389です。SSLトンネル(ldaps)を使用するようにLDAPを構成する場合は、次のようにトンネルで使用するポート番号(通常、636)に置換します。 

    # firewall-cmd --zone=zone --add-port=636/tcp
# firewall-cmd --permanent --zone=zone --add-port=636/tcp

  4. /var/lib/ldapとそれに含まれるすべてのファイルのユーザー所有権およびグループ所有権をldapに変更します。 

    # cd /var/lib/ldap
# chown ldap:ldap ./*

  5. slapdサービスを開始し、システムの再起動後に開始するように構成します。 

    # systemctl start slapd
# systemctl enable slapd

  6. ドメイン・データベースの構成ファイルにあるolcRootPWエントリで使用するLDAPパスワードのハッシュを生成します。たとえば: 

    # slappasswd -h {SSHA}
New password: password
Re-enter new password: password
{SSHA}lkMShz73MZBic19Q4pfOaXNxpLN3wLRy

  7. ドメイン・データベースの構成エントリを含むconfig-mydom-com.ldifなどの名前のLDIFファイルを、次の例に基づいて作成します。 

    # Load the schema files required for accounts
include file:///etc/openldap/schema/cosine.ldif

include file:///etc/openldap/schema/nis.ldif

include file:///etc/openldap/schema/inetorgperson.ldif

# Load the HDB (hierarchical database) backend modules
dn: cn=module,cn=config
objectClass: olcModuleList
cn: module
olcModulepath: /usr/lib64/openldap
olcModuleload: back_hdb

# Configure the database settings
dn: olcDatabase=hdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {1}hdb
olcSuffix: dc=mydom,dc=com
# The database directory must already exist
# and it should only be owned by ldap:ldap.
# Setting its mode to 0700 is recommended
olcDbDirectory: /var/lib/ldap
olcRootDN: cn=admin,dc=mydom,dc=com
olcRootPW: {SSHA}lkMShz73MZBic19Q4pfOaXNxpLN3wLRy
olcDbConfig: set_cachesize 0 10485760 0
olcDbConfig: set_lk_max_objects 2000
olcDbConfig: set_lk_max_locks 2000
olcDbConfig: set_lk_max_lockers 2000
olcDbIndex: objectClass eq
olcLastMod: TRUE
olcDbCheckpoint: 1024 10
# Set up access control
olcAccess: to attrs=userPassword
  by dn="cn=admin,dc=mydom,dc=com"
  write by anonymous auth
  by self write
  by * none
olcAccess: to attrs=shadowLastChange
  by self write
  by * read
olcAccess: to dn.base=""
  by * read
olcAccess: to *
  by dn="cn=admin,dc=mydom,dc=com"
  write by * read

    ノート:

    この構成ファイルを使用すると、実行時にslapdを再構成できます。slapd.conf構成ファイルを使用する場合は、slapdを動的に更新することもできますが、サーバーを再起動した場合は、それらの変更が維持されません。

    詳細は、slapd-config(5)マニュアル・ページを参照してください。

  8. ldapaddコマンドを使用して、LDIFファイルを追加します。 

    # ldapadd -Y EXTERNAL -H ldapi:/// -f config-mydom-com.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
adding new entry "cn=module,cn=config"

adding new entry "olcDatabase=hdb,cn=config"

OpenLDAPの構成の詳細は、slapadd(8C)、slapd(8C)、slapd-config(5)およびslappasswd(8C)の各マニュアル・ページ、OpenLDAP管理者ガイド(/usr/share/doc/openldap-servers-version/guide.html)、およびhttps://www.openldap.org/doc/にある最新のOpenLDAPドキュメントを参照してください。

デフォルト証明書の置換え

Transport Layer Security (TLS)またはSecure Sockets Layer (SSL)を使用してLDAPサーバーへの接続を保護するようにLDAPを構成する場合は、クライアントがダウンロードできる公開証明書が必要です。証明書は、認証局(CA)から取得することも、opensslコマンドを使用して作成することもできます。自己署名CA証明書の作成および配布を参照してください。

サーバー証明書、対応する秘密キー・ファイルおよびルートCA証明書がある場合は、/etc/openldap/certsにインストールされているデフォルトの証明書を置き換えることができます。

slapdがTLSで使用する既存の証明書のエントリを表示するには、ldapsearchコマンドを使用します。 

# ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b "cn=config" \
  olcTLSCACertificatePath olcTLSCertificateFile olcTLSCertificateKeyFile 
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
dn: cn=config
olcTLSCACertificatePath: /etc/openldap/certs
olcTLSCertificateFile: "OpenLDAP Server"
olcTLSCertificateKeyFile: /etc/openldap/certs/password
...

LDAP構成のTLS属性を置き換えるには:

  1. 属性の変更方法を定義するLDIFファイルを作成します。たとえば: 

    dn: cn=config
changetype: modify
delete: olcTLSCACertificatePath

# Omit the following clause for olcTLSCACertificateFile
# if you do not have a separate root CA certificate
dn: cn=config
changetype: modify
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/certsCAcert.pem

dn: cn=config
changetype: modify
replace: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/server-cert.pem

dn: cn=config
changetype: modify
replace: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/certs/server-key.pem

dn: cn=config
changetype: modify
add: olcTLSCipherSuite
olcTLSCipherSuite: TLSv1+RSA:!NULL

dn: cn=config
changetype: modify
add: olcTLSVerifyClient
olcTLSVerifyClient: never

    自己署名証明書と対応するキー・ファイルのみを生成する場合は、ルートCA証明書を指定する必要はありません。

  2. ldapmodifyコマンドを使用して、LDIFファイルを適用します。 

    # ldapmodify -Y EXTERNAL -H ldapi:/// -f mod-TLS.ldif 
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "cn=config"

modifying entry "cn=config"

modifying entry "cn=config"
...

  3. エントリが変更されたことを確認します。 

    # ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b "cn=config" \
  olcTLSCACertificatePath olcTLSCertificateFile olcTLSCertificateKeyFile 
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
dn: cn=config
olcTLSCACertificateFile: /etc/ssl/certs/CAcert.pem
olcTLSCertificateFile: /etc/ssl/certs/server-cert.pem
olcTLSCertificateKeyFile: /etc/ssl/certs/server-key.pem
olcTLSCipherSuite: TLSv1+RSA:!NULL
olcTLSVerifyClient: never
...

  4. slapdサービスを再起動して、新しい証明書を使用できるようにします。 

    # systemctl restart slapd

詳細は、ldapmodify(1)、ldapsearch(1)およびopenssl(1)の各マニュアル・ページを参照してください。

自己署名CA証明書の作成および配布

LDAPで使用可能な、組織内のみで使用する証明書を作成できます。適切な証明書を作成するには複数の方法があります。たとえば:

  • 自己署名CA証明書とともに、秘密キー・ファイルを作成します。

  • 自己署名ルートCA証明書と秘密キー・ファイルを作成し、そのCA証明書とキー・ファイルを使用して、各サーバーの個々のサーバー証明書に署名します。

次に、opensslを使用して自己署名CA証明書と秘密キー・ファイルを作成し、これらのファイルを使用してサーバー証明書に署名する手順を説明します。

CA証明書を作成し、その証明書を使用してサーバー証明書に署名するには:

  1. ディレクトリをLDAPサーバーの/etc/openldap/certsに変更します。 

    # cd /etc/openldap/certs

  2. CA証明書に対する秘密キー・ファイルCAcert-key.pemを作成します。 

    # openssl genrsa -out CAcert-key.pem 1024
Generating RSA private key, 1024 bit long modulus
......++++++
....++++++
e is 65537 (0x10001)

  3. キー・ファイルのモードを0400に変更します。 

    # chmod 0400 CAcert-key.pem

  4. 証明書リクエストCAcert.csrを作成します。 

    # openssl req -new -key CAcert-key.pem -out CAcert.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:US
State or Province Name (full name) []:California
Locality Name (eg, city) [Default City]:Redwood City
Organization Name (eg, company) [Default Company Ltd]:Mydom Inc
Organizational Unit Name (eg, section) []:Org
Common Name (eg, your name or your server's hostname) []:www.mydom.org
Email Address []:root@mydom.org

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:<Enter>
An optional company name []:<Enter>

  5. 約3年間有効なCA証明書を作成します。 

    # openssl x509 -req -days 1095 -in CAcert.csr -signkey CAcert-key.pem -out CAcert.pem
rt-key.pem -out CAcert.pem
Signature ok
subject=/C=US/ST=California/L=Redwood City/O=Mydom 
Inc/OU=Org/CN=www.mydom.org/emailAddress=root@mydom.org
Getting Private key

  6. 作成するサーバー証明書ごとに、次のようにします。

    1. サーバー証明書に対する秘密キーを作成します。 

      # openssl genrsa -out server-key.pem 1024
Generating RSA private key, 1024 bit long modulus
.............++++++
...........................++++++
e is 65537 (0x10001)

      ノート:

      複数のサーバーのサーバー証明書を生成する場合は、サーバーとサービスを簡単に識別できるように、証明書、そのキー・ファイルおよび証明書リクエストの名前をldap_host02-cert.pem、ldap_host02-key.pem、ldap_host02-cert.csrのように指定します。

    2. キー・ファイルのモードを0400に変更し、そのユーザーおよびグループの所有権をldapに変更します。 

      # chmod 0400 server-key.pem
# chown ldap:ldap server-key.pem

    3. 証明書リクエストserver-cert.csrを作成します。 

      # openssl req -new -key server-key.pem -out server-cert.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:US
State or Province Name (full name) []:California
Locality Name (eg, city) [Default City]:Redwood City
Organization Name (eg, company) [Default Company Ltd]:Mydom Inc
Organizational Unit Name (eg, section) []:Org
Common Name (eg, your name or your server's hostname) []:ldap.mydom.com
Email Address []:root@mydom.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:<Enter>
An optional company name []:<Enter>

      ノート:

      Common Name (共通名)には、サーバーの完全修飾ドメイン名(FQDN)を指定します。サーバーのFQDNが証明書で指定されているCommon Name (共通名)と一致しない場合、クライアントはサーバーへの接続を取得できません。

    4. CA証明書と対応するキー・ファイルを使用して証明書リクエストに署名し、サーバーの証明書を生成します。 

      # openssl x509 -req -days 1095 -CAcreateserial \
  -in server-cert.csr -CA CAcert.pem -CAkey CAcert-key.pem \
  -out server-cert.pem
Signature ok
subject=/C=US/ST=California/L=Redwood City/O=Mydom 
Inc/OU=Org/CN=ldap.mydom.com/emailAddress=root@mydom.com
Getting CA Private Key

  7. 他のLDAPサーバーのサーバー証明書を生成する場合は、適切なサーバー証明書、対応するキー・ファイルおよびCA証明書をサーバーの/etc/openldap/certsにコピーします。

  8. クライアントがアクセスするCA証明書をホストするようにWebサーバーを設定します。次のステップでは、LDAPサーバーでこの機能を実行することを前提としています。かわりに適切な代替サーバーを使用することもできます。

    1. Apache HTTPサーバーをインストールします。 
      # yum install httpd
    2. /var/www/htmlの下に、CA証明書のディレクトリを作成します。たとえば: 
      # mkdir /var/www/html/certs
    3. CA証明書を/var/www/html/certsにコピーします。 
      # cp CAcert.pem /var/www/html/certs

      注意:

      キー・ファイルはコピーしないでください。

    4. HTTPサーバー構成ファイル/etc/httpd/conf/httpd.confを編集して、サーバーの解決可能なドメイン名をServerNameの引数に指定します。 
      ServerName server_addr:80
      サーバーが解決可能なドメイン名を持たない場合、かわりにそのIPアドレスを入力します。
      <Directory "/var/www/html">セクションのOptionsディレクティブの設定で、次のようにIndexesおよびFollowSymLinksを指定し、ディレクトリ階層が参照可能になっていることを確認します。 
      Options Indexes FollowSymLinks
    5. Apache HTTPサーバーを起動して、再起動後に開始するようにそれを構成します。 
      # systemctl start httpd
# systemctl enable httpd

    6. システムでファイアウォールを有効にしている場合、次のようにTCPポート80でHTTP接続リクエストを受信できるようにそれを構成します。 

      # firewall-cmd --zone=zone --add-port=80/tcp
# firewall-cmd --permanent --zone=zone --add-port=80/tcp

LDAPでの組織の初期化

ユーザー、グループ、サーバー、プリンタおよび組織でのその他の権限を定義する前に、最初に組織自体の情報をLDAPに設定する必要があります。

LDAPに組織を定義するには:

  1. 組織を定義するLDIFファイルを作成します。たとえば mydom-com-organization.ldif: 

    # Organization mydom.com
dn: dc=mydom,dc=com
dc: mydom
objectclass: dcObject
objectclass: organizationalUnit
ou: mydom.com

# Users
dn: ou=People,dc=mydom,dc=com
objectClass: organizationalUnit
ou: people

# Groups
dn: ou=Groups,dc=mydom,dc=com
objectClass: organizationalUnit
ou: groups

  2. LDAP認証を構成済の場合は、ldapaddコマンドを使用して、LDAPに組織を追加します。 

    # ldapadd -cxWD "cn=admin,dc=mydom,dc=com" -f mydom-com-organization.ldif
Enter LDAP Password: admin_password
adding new entry "dc=mydom,dc=com"

adding new entry "ou=People,dc=mydom,dc=com"

adding new entry "ou=Groups,dc=mydom,dc=com"

    Kerberos認証を構成済の場合は、kinitを使用してadminプリンシパル用のチケット発行チケット(TGT)を取得し、次の形式のldapaddコマンドを使用します。 

    # ldapadd -f mydom-com-organization.ldif

詳細は、ldapadd(1)マニュアル・ページを参照してください。

LDAPへの自動マウント・マップの追加

auto.homeなどの自動マウント・マップをLDAPで利用して、自動マウンタが要求に応じてユーザーのホーム・ディレクトリをマウントするようにできます。

auto.homeマップをLDAPに追加するには:

  1. マップの名前とその内容のエントリを定義するLDIFファイルを作成します。たとえばauto-home.ldif: 

    dn: nisMapName=auto.home,dc=mydom,dc=com
objectClass: top
objectClass: nisMap
nisMapName: auto.home

dn: cn=*,nisMapName=auto.home,dc=mydom,dc=com
objectClass: nisObject
cn: *
nisMapEntry: -rw,sync nfssvr:/nethome/&
nisMapName: auto.home

    前の例では、nfssvrは、ユーザーのホーム・ディレクトリをエクスポートするNFSサーバーのホスト名またはIPアドレスです。

  2. LDAP認証を構成済の場合は、次のコマンドを使用してマップをLDAPに追加します。 

    # ldapadd -xcWD "cn=admin,dc=mydom,dc=com" \
  -f auto-home.ldif
Enter LDAP Password: user_password
adding new entry "nisMapName=auto.home,dc=mydom,dc=com"

adding new entry "cn=*,nisMapName=auto.home,dc=mydom,dc=com"

    Kerberos認証を構成済の場合は、kinitを使用してadminプリンシパル用のチケット発行チケット(TGT)を取得し、次の形式のコマンドを使用します。 

    # ldapmodify -f auto-home.ldif

  3. マップがLDAPに表示されることを確認します。 

    # ldapsearch -LLL -x -b "dc=mydom,dc=com" nisMapName=auto.home
dn: nisMapName=auto.home,dc=mydom,dc=com
objectClass: top
objectClass: nisMap
nisMapName: auto.home

dn: cn=*,nisMapName=auto.home,dc=mydom,dc=com
objectClass: nisObject
cn: *
nisMapEntry: -rw,sync nfssvr.mydom.com:/nethome/&
nisMapName: auto.home

LDAPへのグループの追加

ユーザー・プライベート・グループ(UPG)でユーザーを構成する場合は、そのグループとともにユーザーを定義します。LDAPへのユーザーの追加を参照してください。

グループをLDAPに追加するには:

  1. グループを定義するLDIFファイルを作成します。たとえば employees-group.ldif: 

    # Group employees
dn: cn=employees,ou=Groups,dc=mydom,dc=com
cn: employees
gidNumber: 626
objectClass: top
objectclass: posixGroup

  2. LDAP認証を構成済の場合は、次のコマンドを使用してグループをLDAPに追加します。 

    # ldapadd -cxWD "cn=admin,dc=mydom,dc=com" -f employees-group.ldif
Enter LDAP Password: admin_password
adding new entry "cn=employees,ou=Groups,dc=mydom,dc=com"

    Kerberos認証を構成済の場合は、kinitを使用してadminプリンシパル用のチケット発行チケット(TGT)を取得し、次の形式のldapaddコマンドを使用します。 

    # ldapadd -f employees-group.ldif

  3. LDAPでこのグループを検索できることを確認します。 

    # ldapsearch -LLL -x -b "dc=mydom,dc=com" gidNumber=626
dn: cn=employees,ou=Groups,dc=mydom,dc=com
cn: employees
gidNumber: 626
objectClass: top
objectClass: posixGroup

詳細は、ldapadd(1)およびldapsearch(1)の各マニュアル・ページを参照してください。

LDAPへのユーザーの追加

ノート:

この手順では、次の項目を前提としています。

  • LDAPによって、ou=People、ou=GroupsおよびnisMapName=auto.homeの情報が提供されます。

  • LDAPサーバーは、NFSを使用してユーザーのホーム・ディレクトリをエクスポートします。Oracle Linux 7: ファイル・システムの管理のNFSファイルシステムのマウントを参照してください。

ユーザーのアカウントをLDAPサーバーに作成するには:

  1. LDAPサーバーによってユーザーのホーム・ディレクトリのベース・ディレクトリがエクスポートされていない場合は、LDAPサーバーで次のステップを実行します。

    1. ユーザーのディレクトリのベース・ディレクトリを作成します。たとえば /nethome: 

      # mkdir /nethome

    2. /etc/exportsに次のようなエントリを追加します。 

      /nethome    *(rw,sync)

      ファイル・システムをマウントできるクライアントを制限することができます。たとえば、次のエントリでは、192.168.1.0/24サブネットのクライアントのみが/nethomeをマウントできます。 

      /nethome    192.168.1.0/24(rw,sync)

    3. 次のコマンドを使用して、ファイル・システムをエクスポートします。 

      # exportfs -i -o ro,sync *:/nethome

  2. ユーザー・アカウントを作成しますが、ローカル・ログインは許可しません。 

    # useradd -b base_dir -s /sbin/nologin -u UID -U username

    たとえば: 

    # useradd -b /nethome -s /sbin/nologin -u 5159 -U arc815

    このコマンドによって、/etc/passwdファイルが更新されて、LDAPサーバーの/nethomeの下にホーム・ディレクトリが作成されます。

    ユーザーのログイン・シェルは、LDAPに設定されているLoginShell値によってオーバーライドされます。

  3. 次の例のように、idコマンドを使用して、ユーザーとそのユーザーに割り当てられているグループIDをリストします。 

    # id arc815
uid=5159(arc815) gid=5159(arc815) groups=5159(arc815)

  4. ユーザーを定義するLDIFファイルを作成します。たとえばarc815-user.ldif: 

    # UPG arc815
dn: cn=arc815,ou=Groups,dc=mydom,dc=com
cn: arc815
gidNumber: 5159
objectclass: top
objectclass: posixGroup

# User arc815
dn: uid=arc815,ou=People,dc=mydom,dc=com
cn: John Beck
givenName: John
sn: Beck
uid: arc815
uidNumber: 5159
gidNumber: 5159
homeDirectory: /nethome/arc815
loginShell: /bin/bash
mail: johnb@mydom.com
objectClass: top
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
userPassword: {SSHA}x

    この例では、ユーザーは、同じファイルに定義されているユーザー・プライベート・グループ(UPG)に属します。ユーザーのログイン・シェル属性LoginShellは、/bin/bashに設定されています。ユーザーのパスワード属性userPasswordは、プレースホルダ値に設定されています。LDAPでKerberos認証を使用する場合、この属性は使用されません。

  5. LDAP認証を構成済の場合は、次のコマンドを使用してユーザーをLDAPに追加します。 

    # ldapadd -cxWD cn=admin,dc=mydom,dc=com -f arc815-user.ldif
Enter LDAP Password: admin_password
adding new entry "cn=arc815,ou=Groups,dc=mydom,dc=com"

adding new entry "uid=arc815,ou=People,dc=mydom,dc=com"

    Kerberos認証を構成済の場合は、kinitを使用してadminプリンシパル用のチケット発行チケット(TGT)を取得し、次の形式のldapaddコマンドを使用します。 

    # ldapadd -f arc815-user.ldif

  6. LDAPでユーザーおよびユーザーのUPGを検索できることを確認します。 

    # ldapsearch -LLL -x -b "dc=mydom,dc=com" '(|(uid=arc815)(cn=arc815))'
dn: cn=arc815,ou=Groups,dc=mydom,dc=com
cn: arc815
gidNumber: 5159
objectClass: top
objectClass: posixGroup

dn: uid=arc815,ou=People,dc=mydom,dc=com
cn: John Beck
givenName: John
sn: Beck
uid: arc815
uidNumber: 5159
gidNumber: 5159
homeDirectory: /home/arc815
loginShell: /bin/bash
mail: johnb@mydom.com
objectClass: top
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount

  7. LDAP認証を構成済の場合は、次のコマンドを使用してユーザー・パスワードをLDAPに設定します。 

    # ldappasswd -xWD "cn=admin,dc=mydom,dc=com" \
  -S "uid=arc815,ou=people,dc=mydom,dc=com"
New password: user_password
Re-enter new password: user_password
Enter LDAP Password: admin_password

    Kerberos認証を構成済の場合は、kinitを使用してadminプリンシパル用のチケット発行チケット(TGT)を取得し、次のようにkadminコマンドを使用してユーザー(プリンシパル)およびパスワードをKerberosドメインのデータベースに追加します。 

    # kadmin -q "addprinc alice@MYDOM.COM"

詳細は、kadmin(1)、ldapadd(1)、ldappasswd(1)およびldapsearch(1)の各マニュアル・ページを参照してください。

LDAPのグループへのユーザーの追加

ユーザーをLDAPの既存のグループに追加するには:

  1. グループのmemberuid属性に追加する必要があるユーザーを定義するLDIFファイルを作成します。たとえば employees-add-users.ldif: 

    dn: cn=employees,ou=Groups,dc=mydom,dc=com
changetype: modify
add: memberUid
memberUid: arc815

dn: cn=employees,ou=Groups,dc=mydom,dc=com
changetype: modify
add: memberUid
memberUid: arc891

...

  2. LDAP認証を構成済の場合は、次のコマンドを使用してグループをLDAPに追加します。 

    # ldapmodify -xcWD "cn=admin,dc=mydom,dc=com" \
  -f employees-add-users.ldif
Enter LDAP Password: user_password
modifying entry "cn=employees,ou=Groups,dc=mydom,dc=com"
...

    Kerberos認証を構成済の場合は、kinitを使用してadminプリンシパル用のチケット発行チケット(TGT)を取得し、次の形式のコマンドを使用します。 

    # ldapmodify -f employees-add-users.ldif

  3. グループがLDAPで更新されていることを確認します。 

    # ldapsearch -LLL -x -b "dc=mydom,dc=com" gidNumber=626
dn: cn=employees,ou=Groups,dc=mydom,dc=com
cn: employees
gidNumber: 626
objectClass: top
objectClass: posixGroup
memberUid: arc815
memberUid: arc891
...

LDAP認証の有効化

認証構成GUIを使用して、LDAPクライアントに対するLDAP認証を有効にするには:

  1. openldap-clientsパッケージをインストールします。 

    # yum install openldap-clients

  2. 認証構成GUIを実行します。 

    # system-config-authentication

  3. ユーザー・アカウント・データベースとして「LDAP」を選択し、次の値を入力します。

    LDAP検索ベースDN

    データベースのLDAP検索ベースDN。たとえば: dc=mydom,dc=com。

    LDAPサーバー

    ポート番号を含むLDAPサーバーのURL。たとえば、ldap://ldap.mydom.com:389またはldaps://ldap.mydom.com:636。

    LDAP認証では、LDAP over SSL (ldaps)またはTransport Layer Security (TLS)を使用してLDAPサーバーへの接続を保護する必要があります。

  4. TLSを使用する場合は、「CA証明書のダウンロード」をクリックし、ドメイン内の認証基準を提供するCA証明書のダウンロード元URLを入力します。

  5. 認証に対して「LDAPパスワード」または「Kerberosパスワード」を選択します。

  6. Kerberos認証を選択した場合は、次の値を入力します。

    レルム

    Kerberosレルムの名前。

    KDC

    Kerberosのチケット発行チケットおよびサービス・チケットを発行できるキー配布センター(KDC)のカンマ区切りリスト。

    管理サーバー

    Kerberos管理サーバーのカンマ区切りリスト。

    また、DNSを使用して次の設定を構成できます。

    • DNSを使用してレルムのホストを解決チェック・ボックスを選択すると、次の例のように、DNSのTXTレコードとして定義されたレルムの名前が検索されます。 

      _kerberos.mydom.com    IN TXT "MYDOM.COM"

    • DNSを使用してレルムのKDCを検索チェック・ボックスを選択すると、次の例のように、DNSのSVRレコードとして定義されたKDCおよび管理サーバーが検索されます。 

      _kerberos._tcp.mydom.com      IN SVR 1  0 88  krbsvr.mydom.com
_kerberos._udp.mydom.com      IN SVR 1  0 88  krbsvr.mydom.com
_kpasswd._udp.mydom.com       IN SVR 1  0 464 krbsvr.mydom.com
_kerberos-adm._tcp.mydom.com  IN SVR 1  0 749 krbsvr.mydom.com

  7. 「適用」をクリックして変更を保存します。

図1-3 LDAPを使用した認証構成


この図は、ユーザー・アカウント・データベースおよび認証としてLDAPが選択された認証構成GUIを示しています。

authconfigコマンドを使用してLDAPを有効化することもできます。

LDAPを認証ソースとして使用するには、ポート番号を含むLDAPサーバーの完全なURLおよびLDAP検索ベースDNとともに--enableldapauthオプションを指定する必要があります。次に例を示します。 

# authconfig --enableldap --enableldapauth \
  --ldapserver=ldaps://ldap.mydom.com:636 \
  --ldapbasedn="ou=people,dc=mydom,dc=com" \
  --update

TLSを使用する場合は、--enableldaptlsオプションおよびCA証明書のダウンロードURLも指定します。次に例を示します。 

# authconfig --enableldap --enableldapauth \
  --ldapserver=ldap://ldap.mydom.com:389 \
  --ldapbasedn="ou=people,dc=mydom,dc=com" \
  --enableldaptls \
  --ldaploadcacert=https://ca-server.mydom.com/CAcert.pem \
  --update

--enableldapオプションにより、システムで情報サービス用にLDAPおよびSSSDが使用できるように/etc/nsswitch.confが構成されます。--enableldapauthオプションで、/etc/pam.dのPAM構成ファイルをpam_ldap.soモジュールを使用するように変更すると、LDAP認証を有効にできます。

詳細は、authconfig(8)、pam_ldap(5)およびnsswitch.conf(5)の各マニュアル・ページを参照してください。

LDAPでのKerberos認証の使用については、Kerberos認証の有効化を参照してください。

ノート:

LDAPの情報にアクセスできるようにSSSDを構成する必要もあります。SSSDを使用するためのLDAPクライアントの構成を参照してください。

LDAPに格納されている自動マウント・マップをクライアントで使用する場合は、LDAPを使用するようにautofsを構成する必要があります。自動マウント・マップを使用するためのLDAPクライアントの構成を参照してください。

 SSSDを使用するためのLDAPクライアントの構成

LDAPクライアントでSystem Security Services Daemon (SSSD)を構成する必要があるため、認証構成GUIおよびauthconfigで、/etc/nsswitch.confのsssエントリを介してLDAPに対するアクセスを構成します。

SSSDを使用するようにLDAPクライアントを構成するには:

  1. sssdおよびsssd-clientパッケージをインストールします。 

    # yum install sssd sssd-client

  2. /etc/sssd/sssd.conf構成ファイルを編集して、必要なサービスをサポートするように各セクションを構成します。たとえば: 

    [sssd]
config_file_version = 2
domains = default
services = nss, pam

[domain/default]
id_provider = ldap
ldap_uri = ldap://ldap.mydom.com
ldap_id_use_start_tls = true
ldap_search_base = dc=mydom,dc=com
ldap_tls_cacertdir = /etc/openldap/cacerts

auth_provider = krb5
chpass_provider = krb5
krb5_realm = MYDOM.COM
krb5_server = krbsvr.mydom.com
krb5_kpasswd = krbsvr.mydom.com
cache_credentials = true

[domain/LDAP]
id_provider = ldap
ldap_uri = ldap://ldap.mydom.com
ldap_search_base = dc=mydom,dc=com

auth_provider = krb5
krb5_realm = MYDOM.COM
krb5_server = kdcsvr.mydom.com
cache_credentials = true

min_id = 5000
max_id = 25000
enumerate = false

[nss]
filter_groups = root
filter_users = root
reconnection_retries = 3
entry_cache_timeout = 300

[pam]
reconnection_retries = 3
offline_credentials_expiration = 2
offline_failed_login_attempts = 3
offline_failed_login_delay = 5

  3. /etc/sssd/sssd.confのモードを0600に変更します。 

    # chmod 0600 /etc/sssd/sssd.conf

  4. SSSDサービスを有効にします。 

    # authconfig --update --enablesssd --enablesssdauth

詳細は、sssd.conf(5)マニュアル・ページおよびSystem Security Services Daemonについてを参照してください。

 自動マウント・マップを使用するためのLDAPクライアントの構成

LDAPのauto.homeに自動マウント・マップを構成済の場合は、ユーザーのログイン時にユーザーのホーム・ディレクトリをマウントするようにLDAPクライアントを構成できます。

ユーザーのホーム・ディレクトリを自動マウントするようにLDAPクライアントを構成するには:

  1. autofsパッケージをインストールします。 

    # yum install autofs

  2. auto.homeマップが使用可能であることを確認します。 

    # ldapsearch -LLL -x -b "dc=mydom,dc=com" nisMapName=auto.home
dn: nisMapName=auto.home,dc=mydom,dc=com
objectClass: top
objectClass: nisMap
nisMapName: auto.home

dn: cn=*,nisMapName=auto.home,dc=mydom,dc=com
objectClass: nisObject
cn: *
nisMapEntry: -rw,sync nfssvr.mydom.com:/nethome/&
nisMapName: auto.home

    この例では、マップが使用可能です。このマップを使用可能にする方法の詳細は、LDAPへの自動マウント・マップの追加を参照してください。

  3. auto.homeマップが使用可能な場合は、/etc/auto.masterを編集して、LDAPのauto.homeマップを検出できる場所をautofsに通知するエントリを作成します。たとえば: 

    /nethome    ldap:nisMapName=auto.home,dc=mydom,dc=com

    LDAP over SSLを使用する場合は、ldap:のかわりにldaps:を指定します。

  4. /etc/autofs_ldap_auth.confを編集して、LDAPでのautofsの設定を構成します。たとえば: 

    <autofs_ldap_sasl_conf
     usetls="yes"
     tlsrequired="no"
     authrequired="autodetect"
     authtype="GSSAPI"
     clientprinc="host/ldapclient.mydom.com@MYDOM.COM" 
     />

    この例では、LDAPサーバーのKerberos認証で接続にTLSが使用されていると仮定します。クライアント・システムのプリンシパルがKerberosデータベースに存在する必要があります。これを検証するには、klist -kコマンドを使用します。クライアントのプリンシパルが存在しない場合は、kadminを使用してプリンシパルを追加します。

  5. Kerberos認証を使用する場合は、次の例のようにkadminを使用して、LDAPサービスのプリンシパルをLDAPサーバーに追加します。 

    # kadmin -q "addprinc ldap/ldap.mydom.com@MYDOM.COM

  6. autofsサービスを再起動し、システムの再起動後にサービスが開始するように構成します。 

    # systemctl restart autofs
# systemctl enable autofs

    autofsサービスによって、ディレクトリ/nethomeが作成されます。ユーザーがログインすると、自動マウンタが/nethomeの下にあるユーザーのホーム・ディレクトリをマウントします。

    ユーザーのファイルの所有者およびグループが匿名ユーザーまたはグループ(nobodyやnogroup)として予期せずにリストされ、all_squashがマウント・オプションとして指定されていない場合は、NFSサーバーの/etc/idmapd.confにあるDomain設定がDNSドメイン名に設定されていることを確認してください。このファイルを変更した場合は、NFSサーバーのNFSサービスを再起動します。

詳細は、auto.master(5)およびautofs_ldap_auth.conf(5)の各マニュアル・ページを参照してください。

NIS認証について

NISでは、ユーザー名、パスワード、ホスト名などの管理情報を集中管理サーバーに格納します。ネットワーク上のクライアント・システムはこの共通データにアクセスできます。この構成により、様々なパスワードを覚えていなくてもマシン間を移動したり、マシン間でデータをコピーできます。管理情報を一元的に格納し、ネットワーク接続システムからこれらの情報にアクセスする方法を提供することで、データの整合性も確保できます。NISにより、各システムで/etc/passwdなどの管理ファイルを保持するオーバーヘッドも削減されます。

NISシステムのネットワークはNISドメインです。ドメイン内の各システムには、DNSドメイン名とは異なる、同じNISドメイン名が付けられます。DNSドメインは、システムのグループを参照するためにインターネット全体で使用されます。NISドメインは、NISサーバーのファイルを使用するシステムを識別するために使用されます。NISドメインには厳密に1つのプライマリ(マスター)サーバーが必要ですが、複数のワーカー・サーバーまたはセカンダリ(スレーブ)サーバーを設定できます。

注意:

NIS認証は、認証データが保護されないなどのセキュリティ上の問題があるため、非推奨です。

NISマップについて

NISドメイン内の管理ファイルは、/etc/passwd、/etc/shadow、/etc/groupsなどの既存の構成ファイルから生成されるdbm形式ファイルであるNISマップです。各マップは1つのフィールドに索引付けされ、そのフィールドの値を指定することでレコードが取得されます。/etc/passwdなどの一部のソース・ファイルには2つのマップがあります。

passwd.byname

ユーザー名に索引付けされます。

passwd.byuid

ユーザーIDに索引付けされます。

/var/yp/nicknamesファイルには、passwd.bynameに対するpasswdやgroup.bynameに対するgroupなど、マップで一般的に使用される短縮名のリストが含まれています。

次の例のように、ypcatコマンドを使用してNISマップの内容を表示できます。 

# ypcat - passwd | grep 1500
guest:$6$gMIxsr3W$LaAo...6EE6sdsFPI2mdm7/NEm0:1500:1500::/nethome/guest:/bin/bash

ノート:

この例では、ypcatコマンドは任意のユーザーにパスワード・ハッシュを表示するため、NIS認証がパスワード・ハッシュ・クラッキング・プログラムに対して本質的には保護されていないことを示しています。Kerberos認証を使用する場合はパスワード・ハッシュがNISマップに表示されないように構成できますが、ypcatで表示されるその他の情報も攻撃者にとって有用になる可能性があります。

詳細は、ypcat(1)マニュアル・ページを参照してください。

NISサーバーの構成

NISプライマリ・サーバーは、NIS情報に関する中央の信頼できるリポジトリとして機能します。NISワーカー・サーバーは、この情報のミラーとして機能します。NISドメインでは、NISプライマリ・サーバーが1つのみ必要です。NISワーカー・サーバーの数はオプションですが、少なくとも1つのワーカー・サーバーを作成すると、プライマリ・サーバーが使用できない場合に一定の冗長性が提供されます。

NISプライマリ・サーバーまたはワーカー・サーバーを構成するには:

  1. ypservパッケージをインストールします。 

    # yum install ypserv

  2. /etc/sysconfig/networkを編集してエントリを追加し、NISドメインを定義します。たとえば: 

    NISDOMAIN=mynisdom

  3. /etc/ypserv.confを編集してNISオプションを構成し、ホストおよびドメインでアクセスできるNISマップに関するルールを追加します。

    たとえば、次のエントリでは、192.168.1サブネットのmynisdomドメインにあるNISクライアントのみにアクセスできます。 

    192.168.1.0/24: mynisdom : * : none
* : * : * : deny

    詳細は、ypserv.conf(5)マニュアル・ページおよび/etc/ypserv.confのコメントを参照してください。

  4. /var/yp/securenetsファイルを作成し、サーバーがリクエストに応答するネットワークのエントリを追加します。たとえば: 

    # cat > /var/yp/securenets <<!
255.255.255.255 127.0.0.1
255.255.255.0   192.168.1.0
!
# cat /var/yp/securenets 
255.255.255.255 127.0.0.1
255.255.255.0   192.168.1.0

    この例では、サーバーはローカル・ループバック・インタフェースおよび192.168.1サブネットからのリクエストを受け入れます。

  5. /var/yp/Makefileを編集します。

    1. 必要なマップ・オプションを設定し、allターゲットを使用して、作成するNISマップを指定します。たとえば: 

      all:
passwd group auto.home
# hosts rpc services netid protocols mail \
# netgrp shadow publickey networks ethers bootparams printcap \
# amd.home auto.local. passwd.adjunct \
# timezone locale netmasks

      この例では、NISは、/etc/passwd、/etc/groupおよび/etc/auto.homeファイルのマップを作成できます。デフォルトでは、/etc/shadowファイルの情報はpasswdマップにマージされ、/etc/gshadowファイルの情報はgroupマップにマージされます。

      詳細は、/var/yp/Makefileのコメントを参照してください。

    2. NIS認証のかわりにKerberos認証を使用する場合は、MERGE_PASSWDおよびMERGE_GROUPの値をfalseに変更します。 

      MERGE_PASSWD=false
MERGE_GROUP=false

      ノート:

      これらの設定によって、パスワード・ハッシュがNISマップに表示されなくなります。

    3. ドメインでNISワーカー・サーバーを構成する場合は、NOPUSHの値をfalseに設定します。 

      NOPUSH=false

      マップを更新する場合、この設定によって、プライマリ・サーバーがワーカー・サーバーに自動的にマップをプッシュできるようになります。

  6. NISサービスを構成します。

    1. ypservサービスを開始し、システムの再起動後に開始するように構成します。 

      # systemctl start ypserv
# systemctl enable ypserv

      ypservサービスは、NISプライマリ・サーバーおよびワーカー・サーバーで実行されます。

    2. サーバーがプライマリNISサーバーとして機能していて、少なくとも1つのワーカーNISサーバーが存在する場合は、ypxfrdサービスを開始し、システムの再起動後に開始するように構成します。 

      # systemctl start ypxfrd
# systemctl enable ypxfrd

      ypxfrdサービスは、NISプライマリからNISワーカー・サーバーへの大規模なNISマップの配布を高速化します。このサービスはプライマリ・サーバーでのみ実行され、ワーカー・サーバーでは実行されません。ワーカー・サーバーが存在しない場合は、このサービスを開始する必要はありません。

    3. yppasswddサービスを開始し、システムの再起動後に開始するように構成します。 

      # systemctl start yppasswdd
# systemctl enable yppasswdd

      NISユーザーは、yppasswddサービスを使用して、shadowマップ内の各自のパスワードを変更できます。このサービスは、NISプライマリ・サーバーおよび任意のワーカー・サーバーで実行されます。

  7. ファイアウォール設定を構成します。

    1. /etc/sysconfig/networkを編集して、ypservおよびypxfrdサービスがリスニングするポートを定義する、次のエントリを追加します。 

      YPSERV_ARGS="-p 834"
YPXFRD_ARGS="-p 835"

      これらのエントリによって、ypservおよびypxfrdがリスニングするポートが確定します。

    2. ポート111および834への着信TCP接続、およびポート111および834での着信UDPデータグラムを許可します。 

      # firewall-cmd --zone=zone --add-port=111/tcp --add-port=111/udp \
  --add-port=834/tcp --add-port=834/udp
# firewall-cmd --permanent --zone=zone --add-port=111/tcp --add-port=111/udp \
  --add-port=834/tcp --add-port=834/udp

      portmapperは、TCPポート111およびUDPポート111でリクエストを処理し、ypservは、TCPポート834およびUDPポート834でリクエストを処理します。

    3. プライマリ・サーバーで、ワーカー・サーバーへの転送をサポートするためにypxfrdサービスを実行する場合は、ポート835への着信TCP接続、およびポート835での着信UDPデータグラムを許可します。 

      # firewall-cmd --zone=zone --add-port=835/tcp --add-port=835/udp
# firewall-cmd --permanent --zone=zone --add-port=835/tcp --add-port=835/udp

    4. yppasswddがリスニングするポートでの着信UDPデータグラムを許可します。 

      # firewall-cmd --zone=zone \
  --add-port=`rpcinfo -p | gawk '/yppasswdd/ {print $4}'`/udp

      ノート:

      このルールは永続的にしないでください。yppasswddで使用するUDPポート番号は、再起動するたびに異なります。

    5. /etc/rc.localを編集し、次の行を追加します。 

      firewall-cmd --zone=zone \
  --add-port=`rpcinfo -p | gawk '/yppasswdd/ {print $4}'`/udp

      このエントリによって、システム再起動時のyppasswddサービスのファイアウォール・ルールが作成されます。yppasswddを再起動する場合は、/etc/init.d/yppasswddスクリプトを変更しないかぎり、ファイアウォール・ルールを手動で修正する必要があります。

  8. すべてのサーバーを起動したら、プライマリNISサーバーにNISマップを作成します。 

    # /usr/lib64/yp/ypinit -m

At this point, we have to construct a list of the hosts which will run NIS
servers.  nisprimary is in the list of NIS server hosts.  Please continue to add
the names for the other hosts, one per line.  When you are done with the
list, type a <control D>."
      next host to add:  nisprimary
      next host to add:  nisworker1
      next host to add:  nisworker2
      next host to add:  ^D

The current list of NIS servers looks like this:

nisprimary nisworker1 nisworker2

Is this correct?  [y/n: y]  y
We need a few minutes to build the databases...
...
localhost has been set up as a NIS master server.

Now you can run ypinit -s nisprimary on all slave server.

    NISワーカー・サーバー(ある場合)のホスト名を入力し、[Ctrl]-[D]を入力して終了し、yを入力してNISサーバーのリストを確認します。ホスト名は、DNSのIPアドレスに、または/etc/hostsのエントリによって解決可能である必要があります。

    ypinitユーティリティは、/var/ypにドメイン・サブディレクトリを作成し、/var/yp/Makefileのallターゲットに関して定義するNISマップを作成します。/var/yp/MakefileにNOPUSH=falseを構成し、/var/yp/ypserversにワーカー・サーバーの名前を構成した場合は、このコマンドによって更新されたマップがワーカー・サーバーにもプッシュされます。

  9. 各NISワーカー・サーバーで、次のコマンドを実行してサーバーを初期化します。 

    # /usr/lib64/yp/ypinit -s nisprimary

    前のコマンドで、nisprimaryはNISプライマリ・サーバーのホスト名またはIPアドレスです。

    詳細は、ypinit(8)マニュアル・ページを参照してください。

ノート:

マップの作成に使用したプライマリNISサーバーのソース・ファイルのいずれかを更新する場合は、プライマリNISサーバーで次のコマンドを使用してマップを再作成し、変更内容をワーカー・サーバーにプッシュします。 

# make -C /var/yp

NISへのユーザー・アカウントの追加

ノート:

この手順では、次の項目を前提としています。

  • NISによって、passwd、groupおよびauto.homeのマップが提供されます。

  • NISプライマリ・サーバーは、NFSを使用してユーザーのホーム・ディレクトリをエクスポートします。Oracle Linux 7: ファイル・システムの管理のNFSファイル・システムのマウントを参照してください。

NISユーザーのアカウントをNISプライマリ・サーバーに作成するには:

  1. NISプライマリ・サーバーによってユーザーのホーム・ディレクトリのベース・ディレクトリがエクスポートされていない場合は、NISプライマリ・サーバーで次のステップを実行します。

    1. ユーザーのディレクトリのベース・ディレクトリを作成します。たとえば /nethome: 

      # mkdir /nethome

    2. /etc/exportsに次のようなエントリを追加します。 

      /nethome    *(rw,sync)

      ファイル・システムをマウントできるクライアントを制限することができます。たとえば、次のエントリでは、192.168.1.0/24サブネットのクライアントのみが/nethomeをマウントできます。 

      /nethome    192.168.1.0/24(rw,sync)

    3. 次のコマンドを使用して、ファイル・システムをエクスポートします。 

      # exportfs -i -o ro,sync *:/nethome

    4. /var/yp/Makfileを構成してNISクライアントがauto.homeマップを使用できる場合は、/etc/auto.homeに次のエントリを作成します。 

      *    -rw,sync    nissvr:/nethome/&

      前の例で、nissvrはNISサーバーのホスト名またはIPアドレスです。

  2. ユーザー・アカウントを作成します。 

    # useradd -b /nethome username

    このコマンドによって、/etc/passwdファイルが更新され、NISサーバーにホーム・ディレクトリが作成されます。

  3. 構成した認証のタイプに基づいて、次のようにします。

    • Kerberos認証の場合は、Kerberosサーバーまたはkadminアクセスを使用するクライアント・システムで、次の例のようにkadminを使用して、Kerberosドメインにユーザーのプリンシパルを作成します。 

      # kadmin -q "addprinc username@KRBDOMAIN"

      このコマンドによって、ユーザーのパスワードを設定して、Kerberosデータベースにプリンシパルを追加するように求められます。

    • NIS認証の場合は、passwdコマンドを使用します。 

      # passwd username

      このコマンドによって、ハッシュ・パスワードで/etc/shadowファイルが更新されます。

  4. NISマップを更新します。 

    # make -C /var/yp

    このコマンドによって、/var/yp/Makefileのallターゲットに関して定義するNISマップが作成されます。/var/yp/MakefileにNOPUSH=falseを構成し、ワーカー・サーバーの名前を/var/yp/ypserversに構成した場合は、このコマンドによって更新されたマップがワーカー・サーバーにもプッシュされます。

ノート:

Kerberos認証ユーザーは、kpasswdまたはpasswdを使用してパスワードを変更できます。NIS認証ユーザーは、passwdではなくyppasswdコマンドを使用してパスワードを変更する必要があります。

NIS認証の有効化

認証構成GUIを使用して、NISクライアントに対するNIS認証を有効にするには:

  1. yp-toolsおよびypbindパッケージをインストールします。 

    # yum install yp-tools ypbind

  2. 認証構成GUIを実行します。 

    # system-config-authentication

  3. ユーザー・アカウント・データベースとして「NIS」を選択し、次の値を入力します。

    NISドメイン

    NISドメインの名前。たとえば: mynisdom。

    NISサーバー

    NISサーバーのドメイン名またはIPアドレス。たとえば、nissvr.mydom.com。

  4. 認証に対して「Kerberosパスワード」または「NISパスワード」を選択します。

  5. Kerberos認証を選択した場合は、次の値を入力します。

    レルム

    Kerberosレルムの名前。

    KDC

    Kerberosのチケット発行チケットおよびサービス・チケットを発行できるキー配布センター(KDC)のカンマ区切りリスト。

    管理サーバー

    Kerberos管理サーバーのカンマ区切りリスト。

    また、DNSを使用して次の設定を構成できます。

    • DNSを使用してレルムのホストを解決チェック・ボックスを選択すると、次の例のように、DNSのTXTレコードとして定義されたレルムの名前が検索されます。 

      _kerberos.mydom.com    IN TXT "MYDOM.COM"

    • DNSを使用してレルムのKDCを検索チェック・ボックスを選択すると、次の例のように、DNSのSVRレコードとして定義されたKDCおよび管理サーバーが検索されます。 

      _kerberos._tcp.mydom.com      IN SVR 1  0 88  krbsvr.mydom.com
_kerberos._udp.mydom.com      IN SVR 1  0 88  krbsvr.mydom.com
_kpasswd._udp.mydom.com       IN SVR 1  0 464 krbsvr.mydom.com
_kerberos-adm._tcp.mydom.com  IN SVR 1  0 749 krbsvr.mydom.com

  6. 「適用」をクリックして変更を保存します。

    注意:

    NIS認証は、認証データが保護されないなどのセキュリティ上の問題があるため、非推奨です。

図1-4 Kerberos認証を使用したNISの認証構成


この図は、ユーザー・アカウント・データベースとしてNISが選択され、認証としてKerberosが選択された認証構成GUIを示しています。

authconfigコマンドを使用して、NISまたはKerberos認証を有効化および構成することもできます。

たとえば、NIS認証を使用するには、次の例に示すように、--enablenisオプションをNISドメイン名およびプライマリ・サーバーのホスト名またはIPアドレスとともに指定します。 

# authconfig --enablenis --nisdomain mynisdom \
  --nisserver nissvr.mydom.com --update

--enablenisオプションにより、システムで情報サービス用にNISを使用できるように/etc/nsswitch.confが構成されます。--nisdomainおよび--nisserver設定が、/etc/yp.confに追加されます。

詳細は、authconfig(8)、nsswitch.conf(5)およびyp.conf(5)の各マニュアル・ページを参照してください。

NISでのKerberos認証の使用については、Kerberos認証の有効化を参照してください。

自動マウント・マップを使用するためのNISクライアントの構成

NISのauto.homeに自動マウント・マップを構成済の場合は、ユーザーのログイン時にユーザーのホーム・ディレクトリをマウントするようにNISクライアントを構成できます。

ユーザーのホーム・ディレクトリを自動マウントするようにNISクライアントを構成するには:

  1. autofsパッケージをインストールします。 

    # yum install autofs

  2. 次のエントリを含む/etc/auto.masterファイルを作成します。 

    /nethome      /etc/auto.home

  3. auto.homeマップが使用可能であることを確認します。 

    # ypcat -k auto.home
*    -rw,sync    nfssvr:/nethome/&

    この例では、マップが使用可能です。このマップを使用可能にする方法の詳細は、NISへのユーザー・アカウントの追加を参照してください。

  4. auto.homeマップが使用可能な場合は、ファイルの/etc/auto.homeを編集して、次のエントリを含めます。 

    +auto.home

    このエントリによって、自動マウンタでauto.homeマップが使用されます。

  5. autofsサービスを再起動し、システムの再起動後にサービスが開始するように構成します。 

    # systemctl restart autofs
# systemctl enable autofs

    autofsサービスによって、ディレクトリ/nethomeが作成されます。ユーザーがログインすると、自動マウンタが/nethomeの下にあるユーザーのホーム・ディレクトリをマウントします。

    ユーザーのファイルの所有者およびグループが匿名ユーザーまたはグループ(nobodyやnogroup)として予期せずにリストされ、all_squashがマウント・オプションとして指定されていない場合は、NFSサーバーの/etc/idmapd.confにあるDomain設定がDNSドメイン名に設定されていることを確認してください。このファイルを変更した場合は、NFSサーバーのNFSサービスを再起動します。

Kerberos認証について

LDAP認証およびNIS認証の両方において、オプションでKerberos認証をサポートしています。IPAの場合、Kerberosは完全に統合されています。Kerberosは標準ポートでセキュアな接続を提供し、SSSDで資格証明キャッシュを有効にした場合はオフライン・ログインも可能になります。

図1-5 Kerberos認証


この図は、Kerberosのキー配布センター(KDC)がプリンシパル(ユーザーまたはホスト)を認証し、プリンシパルがサービスにアクセスするために使用できるチケット発行チケット(TGT)を付与する方法を示しています。

この処理のステップは次のとおりです。

  1. プリンシパル名およびキーがクライアントに対して指定されます。

  2. クライアントは、プリンシパル名およびTGTのリクエストをKDCに送信します。

    KDCは、セッション・キー、およびセッション・キーのコピーが含まれるTGTを生成し、チケット発行サービス(TGS)キーを使用してTGTを暗号化します。次に、プリンシパルのキーを使用して、すでに暗号化されたTGT、およびセッション・キーの別のコピーの両方を暗号化します。

  3. KDCは、セッション・キーと暗号化されたTGTがさらに暗号化された組合せをクライアントに送信します。

    クライアントは、プリンシパルのキーを使用して、セッション・キーと暗号化されたTGTを抽出します。

  4. クライアントは、サービスを使用するときに(通常は、ローカルまたはリモート・ホスト・システムにアクセスするため)、セッション・キーを使用して、暗号化されたTGTのコピー、クライアントのIPアドレス、タイム・スタンプおよびサービス・チケット・リクエストを暗号化し、このアイテムをKDCに送信します。

    KDCは、セッション・キーとTGSキーのコピーを使用してTGT、IPアドレスおよびタイム・スタンプを抽出し、これらを使用してクライアントを検証できます。クライアントとそのサービス・リクエストの両方が有効な場合、KDCはサービス・セッション・キーを生成し、クライアントのIPアドレス、タイム・スタンプ、およびサービス・セッション・キーのコピーが含まれるサービス・チケットを生成し、サービス・キーを使用してこのサービス・チケットを暗号化します。次に、セッション・キーを使用して、サービス・チケット、およびサービス・セッション・キーの別のコピーの両方を暗号化します。

    通常、サービス・キーは、サービス・プロバイダが稼働するシステムでのホスト・プリンシパルのキーです。

  5. KDCは、サービス・セッション・キーと暗号化されたサービス・チケットがさらに暗号化された組合せをクライアントに送信します。

    クライアントは、セッション・キーのコピーを使用して、暗号化されたサービス・チケットおよびサービス・セッション・キーを抽出します。

  6. クライアントは、サービス・セッション・キーを使用して暗号化されたプリンシパル名とタイム・スタンプとともに、暗号化されたサービス・チケットをサービス・プロバイダに送信します。

    サービス・プロバイダは、サービス・キーを使用して、サービス・セッション・チケット内のデータ(サービス・セッション・キーを含む)を抽出します。

  7. サービス・プロバイダはクライアントに対してサービスを有効にします(通常は、そのホスト・システムへのアクセス権を付与します)。

    クライアントとサービス・プロバイダが異なるシステムでホストされている場合は、それぞれサービス・セッション・キーの独自のコピーを使用して、サービス・セッションのネットワーク通信を保護します。

認証ハンドシェイクについて次の点に注意してください。

  • ステップ1から3は、kinitコマンドを使用したTGTの取得とキャッシュに相当します。

  • ステップ4から7は、TGTを使用したKerberos対応サービスへのアクセスに相当します。

  • 認証は事前共有キーに依存します。

  • クライアント、KDCおよびサービス・プロバイダ間の通信チャネル上で、キーがクリアのまま送信されることはありません。

  • 認証プロセスの開始時に、クライアントとKDCはプリンシパルのキーを共有し、KDCとサービス・プロバイダはサービス・キーを共有します。プリンシパルとサービス・プロバイダはTGSキーを把握していません。

  • プロセスの終了時に、クライアントとサービス・プロバイダはサービス・セッション・キーを共有しており、これを使用してサービス・セッションを保護できます。クライアントはサービス・キーを把握しておらず、サービス・プロバイダはプリンシパルのキーを把握していません。

  • クライアントは、チケットの存続期間(通常は1日)内にTGTを使用して、他のサービス・プロバイダへのアクセスをリクエストできます。セッションがアクティブな間にTGTが期限切れになると、セッション・マネージャがTGTを更新します。

Kerberosサーバーの構成

Kerberos認証を使用するようにクライアント・システムを構成する場合は、最初にKerberosサーバーを構成することをお薦めします。その後に、必要なクライアントを構成できます。

ノート:

Kerberosサーバーとして構成するシステムは、厳密にセキュアな状態を保持し、他のサービス機能を実行するように構成しないでください。

キー配布センター(KDC)およびKerberos管理サーバーとして機能できるKerberosサーバーを構成するには:

  1. DNSを使用し、サーバーのドメイン名とIPアドレスの直接および逆引き名前参照が機能するように、サーバーを構成します。

    DNSの構成の詳細は、Oracle Linux 7: ネットワークの設定のネーム・サービスの構成を参照してください。

  2. ネットワーク・タイム・プロトコル(NTP)、高精度時間プロトコル(PTP)、またはchronyなどのネットワーク・タイム同期化方式を使用するように、サーバーを構成します。Kerberosでは、Kerberosサーバーとクライアントのシステム時間が可能なかぎり緊密に同期化される必要があります。サーバーとクライアントのシステム時間の差異が300秒(デフォルト)を超えると、認証が失敗します。

    詳細は、Oracle Linux 7: ネットワークの設定のネットワーク時間の構成を参照してください

  3. krb5-libs、krb5-serverおよびkrb5-workstationパッケージをインストールします。 

    # yum install krb5-libs krb5-server krb5-workstation

  4. /etc/krb5.confを編集してKerberosレルムの設定を構成します。たとえば: 

    [logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 default_realm = MYDOM.COM
 dns_lookup_realm = false
 dns_lookup_kdc = false
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true

[realms]
 MYDOM.COM = {
  kdc = krbsvr.mydom.com
  admin_server = krbsvr.mydom.com
 }

[domain_realm]
 .mydom.com = MYDOM.COM mydom.com = MYDOM.COM

[appdefaults]
 pam = {
   debug = true
   validate = false
 }

    この例では、KerberosレルムはDNSドメインmydom.com内のMYDOM.COMで、krbsvr.mydom.com (ローカル・システム)はKDCおよび管理サーバーの両方として機能します。[appdefaults]セクションでは、pam_krb5.soモジュールのオプションを構成します。

    詳細は、krb5.conf(5)およびpam_krb5(5)の各マニュアル・ページを参照してください。

  5. /var/kerberos/krb5kdc/kdc.confを編集してキー配布センターの設定を構成します。たとえば: 

    kdcdefaults]
 kdc_ports = 88
 kdc_tcp_ports = 88

[realms]
 MYDOM.COM = {
  #master_key_type = aes256-cts
  master_key_type = des-hmac-sha1
  default_principal_flags = +preauth
  acl_file = /var/kerberos/krb5kdc/kadm5.acl
  dict_file = /usr/share/dict/words
  admin_keytab = /etc/kadm5.keytab
  supported_enctypes = aes256-cts:normal aes128-cts:normal des3-hmac-sha1:normal \
  arcfour-hmac:normal des-hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal
 }

    詳細は、kdc.conf(5)マニュアル・ページを参照してください。

  6. Kerberosデータベースを作成し、データベース・パスワードをstashファイルに格納します。 

    # /usr/sbin/kdb5_util create -s

  7. /var/kerberos/krb5kdc/kadm5.aclを編集して、Kerberosデータベースへの管理アクセス権を持つプリンシパルを定義します。たとえば: 

    */admin@EXAMPLE.COM     *

    この例では、adminのインスタンス(例: alice/admin@MYDOM.COM)を使用するプリンシパルが、MYDOM.COMドメインに対してKerberosデータベースの完全な管理統制権限を持ちます。通常、データベース内の一般ユーザーは空のインスタンスを使用します。たとえばbob@MYDOM.COM。このようなユーザーは、データベースに格納された自分のパスワードを変更すること以外、管理統制権限はありません。

  8. adminインスタンスを使用するプリンシパルをユーザーごとに作成します。たとえば: 

    # kadmin.local -q "addprinc alice/admin"

  9. 管理Kerberosチケットを復号化するためにkadmindで使用するキーを/etc/kadm5.keytabにキャッシュします。 

    # kadmin.local -q "ktadd -k /etc/kadm5.keytab kadmin/admin"
# kadmin.local -q "ktadd -k /etc/kadm5.keytab kadmin/changepw"

  10. KDCおよび管理サービスを開始し、システムの再起動後に開始するように構成します。 

    # systemctl start krb5kdc
# systemctl start kadmin
# systemctl enable krb5kdc
# systemctl enable kadmin

  11. 次の例のように、kadmin.localまたはkadminのいずれかを使用して、ユーザーのプリンシパルおよびKerberosサーバーを追加し、サーバーのホスト・プリンシパルのキーを/etc/kadm5.keytabにキャッシュします。 

    # kadmin.local -q "addprinc bob"
# kadmin.local -q "addprinc -randkey host/krbsvr.mydom.com"
# kadmin.local -q "ktadd -k /etc/kadm5.keytab host/krbsvr.mydom.com"

  12. ポート88、464および749への着信TCP接続、およびUDPポート88、464および749でのUDPデータグラムを許可します。 

    # firewall-cmd --zone=zone --add-port=88/tcp --add-port=88/udp \
  --add-port=464/tcp --add-port=464/udp \
  --add-port=749/tcp --add-port=749/udp
# firewall-cmd --permanent --zone=zone --add-port=88/tcp --add-port=88/udp \
  --add-port=464/tcp --add-port=464/udp \
  --add-port=749/tcp --add-port=749/udp

    krb5kdcはTCPポート88およびUDPポート88でリクエストを処理し、kadmindはTCPポート464と749およびUDPポート464と749でリクエストを処理します。

    さらに、他のアプリケーション用に、別のポートでのTCPアクセスやUDPアクセスの許可が必要になる場合があります。

詳細は、kadmin(1)マニュアル・ページを参照してください。

Kerberosクライアントの構成

Kerberosクライアントをシステム上に設定すると、Kerberosを使用して、NISまたはLDAPで定義されたユーザーを認証したり、GSS-APIを有効にしたsshなどのコマンド、またはtelnetのKerberos実装を使用してセキュアなリモート・アクセスが可能になります。

システムをKerberosクライアントとして設定するには:

  1. DNSを使用し、クライアントとKerberosサーバーの両方についてドメイン名とIPアドレスの直接および逆引き名前参照が機能するように、クライアント・システムを構成します。

    DNSの構成の詳細は、Oracle Linux 7: ネットワークの設定のネーム・サービスの構成を参照してください。

  2. ネットワーク・タイム・プロトコル(NTP)などのネットワーク・タイム同期化プロトコルを使用するように、システムを構成します。Kerberosでは、Kerberosサーバーとクライアントのシステム時間が可能なかぎり緊密に同期化される必要があります。サーバーとクライアントのシステム時間の差異が300秒(デフォルト)を超えると、認証が失敗します。

    サーバーをNTPクライアントとして構成するには:

    1. ntpパッケージをインストールします。 

      # yum install ntp

    2. 必要に応じて、/etc/ntp.confを編集して設定を構成します。ntp.conf(5)マニュアル・ページおよびhttp://www.ntp.orgを参照してください。

    3. ntpdサービスを開始し、システムの再起動後に開始するように構成します。 

      # systemctl start ntpd
# systemctl enable ntpd

  3. krb5-libsおよびkrb5-workstationパッケージをインストールします。 

    # yum install krb5-libs krb5-workstation

  4. /etc/krb5.confファイルをKerberosサーバーからシステムにコピーします。

  5. 次の例のように、認証構成GUIまたはauthconfigを使用して、NISまたはLDAPでKerberosを使用するようにシステムを設定します。 

    # authconfig --enablenis --enablekrb5 --krb5realm=MYDOM.COM \
  --krb5adminserver=krbsvr.mydom.com --krb5kdc=krbsvr.mydom.com \
  --update

    Kerberos認証の有効化を参照してください。

  6. 次の例のように、Kerberos KDCで、kadminまたはkadmin.localを使用してクライアントのホスト・プリンシパルを追加します。 

    # kadmin.local -q "addprinc -randkey host/client.mydom.com"

  7. 次の例のように、クライアント・システムでkadminを使用して、ホスト・プリンシパルのキーを/etc/kadm5.keytabにキャッシュします。 

    # kadmin -q "ktadd -k /etc/kadm5.keytab host/client.mydom.com"

  8. sshおよび関連するOpenSSHコマンドを使用して、Kerberosクライアント・システムから別のKerberosクライアント・システムに接続するには:

    1. リモートKerberosクライアント・システムで、GSSAPIAuthenticationが/etc/ssh/sshd_configで有効であることを確認します。 

      GSSAPIAuthentication yes

    2. ローカルKerberosクライアント・システムで、ユーザーの.ssh/configファイル内でGSSAPIAuthenticationおよびGSSAPIDelegateCredentialsを有効にします。 

      GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

      ユーザーは、-Kオプションをsshに指定することもできます。

    3. プリンシパルがチケットを取得し、リモート・システムに接続できることをテストします。たとえば: 

      $ kinit principal_name@MYDOM.COM
                                 
$ ssh username@remote.mydom.com

    krb5-appl-clientsパッケージで提供されるrlogin、rshおよびtelnetのKerberosバージョンを使用可能にするには、リモート・クライアントで対応するサービスを有効にする必要があります。

詳細は、kadmin(1)マニュアル・ページを参照してください。

Kerberos認証の有効化

LDAPまたはNISクライアントでKerberos認証を使用できるようにするには、yumを使用してkrb5-libsおよびkrb5-workstationパッケージをインストールします。

認証構成GUI (system-config-authentication)を使用してLDAPまたはNISをユーザー・アカウント・データベースとして選択する場合は、Kerberosパスワードを認証方法として選択し、次の値を入力します。

レルム

Kerberosレルムの名前。

KDC

Kerberosのチケット発行チケットおよびサービス・チケットを発行できるキー配布センター(KDC)のカンマ区切りリスト。

管理サーバー

Kerberos管理サーバーのカンマ区切りリスト。

また、DNSを使用して次の設定を構成できます。

  • DNSを使用してレルムのホストを解決チェック・ボックスを選択すると、次の例のように、DNSのTXTレコードとして定義されたレルムの名前が検索されます。 

    _kerberos.mydom.com    IN TXT "MYDOM.COM"

  • DNSを使用してレルムのKDCを検索チェック・ボックスを選択すると、次の例のように、DNSのSVRレコードとして定義されたKDCおよび管理サーバーが検索されます。 

    _kerberos._tcp.mydom.com      IN SVR 1  0 88  krbsvr.mydom.com
_kerberos._udp.mydom.com      IN SVR 1  0 88  krbsvr.mydom.com
_kpasswd._udp.mydom.com       IN SVR 1  0 464 krbsvr.mydom.com
_kerberos-adm._tcp.mydom.com  IN SVR 1  0 749 krbsvr.mydom.com

図1-6 Kerberos認証を使用したLDAPの認証構成


この図は、ユーザー・アカウント・データベースとしてLDAPが選択され、認証としてKerberosが選択された認証構成GUIを示しています。

または、次の例のように、authconfigコマンドを使用して、LDAPでのKerberos認証を構成できます。 

# authconfig --enableldap \
  --ldapbasedn="dc=mydom,dc=com" --ldapserver=ldap://ldap.mydom.com:389 \
  [--enableldaptls --ldaploadcacert=https://ca-server.mydom.com/CAcert.pem] \
  --enablekrb5  \
  --krb5realm=MYDOM.COM | --enablekrb5realmdns \
  --krb5kdc=krbsvr.mydom.com --krb5adminserver=krbsvr.mydom.com | --enablekrb5kdcdns \
  --update

NISの場合は次のとおりです。 

# authconfig --enablenis \
  --enablekrb5 \
  --krb5realm=MYDOM.COM | --enablekrb5realmdns \
  --krb5kdc=krbsvr.mydom.com --krb5adminserver=krbsvr.mydom.com | --enablekrb5kdcdns \
  --update

--enablekrb5オプションにより、pam_krb5.soモジュールを使用するように/etc/pam.d内のPAM構成ファイルが変更され、Kerberos認証が有効になります。--enableldapおよび--enablenisオプションにより、システムで情報サービス用にLDAPまたはNISを使用できるように/etc/nsswitch.confが構成されます。

詳細は、authconfig(8)、nsswitch.conf(5)およびpam_krb5(5)の各マニュアル・ページを参照してください。

Pluggable Authentication Moduleについて

Pluggable Authentication Modules (PAM)機能は、アプリケーションで認証を使用してユーザーのアイデンティティを検証する方法を構成するための認証メカニズムです。/etc/pam.dディレクトリにあるPAM構成ファイルには、アプリケーションでの認証手順が記述されています。各構成ファイルの名前は、モジュールが認証を提供するアプリケーションの名前と同じかほぼ同じす。たとえば、passwdおよびsudoの構成ファイルの名前は、passwdおよびsudoです。

各PAM構成ファイルには、認証モジュールに対するコールのリスト(スタック)が含まれます。たとえば、次のリストでは、login構成ファイルのデフォルト・コンテンツを示します。 

#%PAM-1.0
auth [user_unknown=ignore success=ok ignore=ignore default=bad] pam_securetty.so
auth       include      system-auth
auth       include      postlogin
account    required     pam_nologin.so
account    include      system-auth
password   include      system-auth
# pam_selinux.so close should be the first session rule
session    required     pam_selinux.so close
session    required     pam_loginuid.so
session    optional     pam_console.so
# pam_selinux.so open should only be followed by sessions to be executed in the user context
session    required     pam_selinux.so open
session    required     pam_namespace.so
session    optional     pam_keyinit.so force revoke
session    include      system-auth
session    include      postlogin
-session   optional     pam_ck_connector.so

ファイルのコメントは#文字で始まります。残りの各行で、操作タイプ、制御フラグ、pam_rootok.soなどのモジュール名またはsystem-authなどの含まれている構成ファイル名、およびモジュールに対する引数を定義しています。PAMは/usr/lib64/securityの共有ライブラリとしての認証モジュールを提供します。

特定の操作タイプの場合、PAMは上から下にスタックを読み取って、構成ファイルに表示されているモジュールをコールします。各モジュールはコールされると、結果(成功または失敗)を生成します。

使用する操作タイプとして、次のタイプが定義されています。

auth

モジュールは、サービスまたはアプリケーションを使用するために、ユーザーが認証または認可されているかどうかをテストします。たとえば、モジュールはパスワードをリクエストおよび検証できます。こうしたモジュールは、グループ・メンバーシップやKerberosチケットなどの資格証明を設定することもできます。

account

モジュールは、認証されたユーザーがサービスまたはアプリケーションへのアクセスを許可されているかどうかをテストします。たとえば、モジュールはユーザー・アカウントが期限切れかどうか、またはユーザーが指定の時間にサービスの使用を許可されているかどうかを確認できます。

password

モジュールは、認証トークンへの更新を処理します。

session

モジュールは、ユーザーのホーム・ディレクトリのマウントやアンマウントなどの作業を実行して、ユーザー・セッションを構成および管理します。

操作タイプの前にダッシュ(-)が付いていると、そのモジュールがない場合にPAMはシステム・ログ・エントリを作成および追加しません。

include以外の制御フラグは、PAMにモジュールの実行結果に対して行う動作を通知します。使用する制御フラグとして、次のフラグが定義されています。
optional

それがサービスにリストされている唯一のモジュールである場合、認証にはそのモジュールが必要です。

required

アクセスを付与するには、モジュールが成功する必要があります。PAMはモジュールが成功しても失敗しても、スタックの残りのモジュールの実行を継続します。PAMは、失敗をただちにユーザーに通知しません。

requisite

アクセスを付与するには、モジュールが成功する必要があります。モジュールが成功した場合、PAMはスタック内の残りのモジュールの実行を継続します。ただし、モジュールが失敗した場合、PAMはただちにユーザーに通知して、スタック内の残りのモジュールの実行を継続しません。

sufficient

モジュールが成功した場合、PAMは同じ操作タイプの残りのモジュールを処理しません。モジュールが失敗した場合、PAMは同じ操作タイプの残りのモジュールを処理して、全体的な成功または失敗を判断します。

制御フラグ・フィールドでは、モジュールから返された値に応じてPAMが実行すべきアクションを指定する1つ以上のルールも指定できます。各ルールは、value=actionという形式をとり、ルールは大カッコで囲まれます。次に例を示します。 

[user_unknown=ignore success=ok ignore=ignore default=bad]

モジュールから返された結果が値と一致する場合、PAMは対応するアクションを使用し、一致しない場合は、デフォルトのアクションを使用します。

includeフラグは、PAMが引数として指定されたPAM構成ファイルも参照すべきであることを示します。

ほとんどの認証モジュールおよびPAM構成ファイルには、それぞれ独自のマニュアル・ページがあります。また、/usr/share/doc/pam-versionディレクトリには、『PAM System Administrator's Guide』(html/Linux-PAM_SAG.htmlまたはLinux-PAM_SAG.txt)およびPAM標準のコピー(rfc86.0.txt)も含まれています。

詳細は、pam(8)マニュアル・ページを参照してください。また、それぞれのPAMモジュールには、pam_unix(8)、postlogin(5)、system-auth(5)など独自のマニュアル・ページがあります。

System Security Services Daemonについて

System Security Services Daemon (SSSD)機能により、クライアント・システムでリモートのアイデンティティ・プロバイダおよび認証プロバイダにアクセスできます。SSSDは、ローカル・クライアントと、構成したバックエンド・プロバイダの間の仲介として機能します。

SSSDを構成する利点は、次のとおりです。

  • システム負荷の削減

    クライアントは、識別サーバーまたは認証サーバーと直接通信する必要がありません。

  • オフライン認証

    ユーザーIDおよび資格証明のキャッシュを保持するようにSSSDを構成できます。

  • シングル・サインオン・アクセス

    ネットワーク資格証明を格納するようにSSSDを構成すると、ユーザーは、ネットワーク・リソースにアクセスするために、各セッションで1回のみローカル・システムに認証される必要があります。

詳細は、authconfig(8)、pam_sss(8)、sssd(8)およびsssd.conf(5)の各マニュアル・ページを参照してください。

SSSDサーバーの構成

SSSDサーバーを構成するには:

  1. sssdおよびsssd-clientパッケージをインストールします。 

    # yum install sssd sssd-client

  2. /etc/sssd/sssd.conf構成ファイルを編集して、必要なサービスをサポートするように各セクションを構成します。たとえば: 

    [sssd]
config_file_version = 2
domains = LDAP
services = nss, pam

[domain/LDAP]
id_provider = ldap
ldap_uri = ldap://ldap.mydom.com
ldap_search_base = dc=mydom,dc=com

auth_provider = krb5
krb5_server = krbsvr.mydom.com
krb5_realm = MYDOM.COM
cache_credentials = true

min_id = 5000
max_id = 25000
enumerate = false

[nss]
filter_groups = root
filter_users = root
reconnection_retries = 3
entry_cache_timeout = 300

[pam]
reconnection_retries = 3
offline_credentials_expiration = 2
offline_failed_login_attempts = 3
offline_failed_login_delay = 5

    [sssd]セクションには、SSSD監視オプション、ドメインおよびサービスの構成設定が含まれます。SSSD監視サービスは、SSSDで提供されるサービスを管理します。

    servicesエントリではサポート対象のサービスを定義し、nss (名前サービス・スイッチ)およびpam (Pluggable Authentication Module)が含まれます。

    domainsエントリでは、認証ドメインを定義するセクションの名前を指定します。

    [domain/LDAP]セクションでは、Kerberos認証を使用するLDAPアイデンティティ・プロバイダのドメインを定義します。各ドメインでは、ユーザー情報の格納場所、認証方法および構成オプションを定義します。SSSDは、LDAPアイデンティティ・プロバイダ(OpenLDAP、Red Hat Directory Server、IPA、Microsoft Active Directoryなど)とともに使用でき、システム固有のLDAPまたはKerberos認証のいずれかを使用できます。

    id_providerエントリでは、プロバイダのタイプ(この例ではLDAP)を指定します。ldap_uriでは、SSSDが接続可能なLDAPサーバーのUniversal Resource Identifier (URI)がプリファレンス順に並べられたカンマ区切りリストを指定します。ldap_search_baseでは、共通名(cn)などの相対的識別名(RDN)に対してLDAPユーザー操作を実行するときにSSSDで使用する、基本の識別名(dn)を指定します。

    auth_providerエントリでは、認証プロバイダ(この例ではKerberos)を指定します。krb5_serverでは、SSSDが接続可能なKerberosサーバーがプリファレンス順に並べられたカンマ区切りリストを指定します。krb5_realmでは、Kerberosレルムを指定します。cache_credentialsでは、オフライン認証やシングル・サインオンをサポートするためにSSSDがユーザー資格証明(チケット、セッション・キー、その他の識別情報など)をキャッシュするかどうかを指定します。

    ノート:

    SSSDがLDAPサーバーでKerberos認証を使用できるようにするには、Simple Authentication and Security Layer (SASL)およびGeneric Security Services API (GSSAPI)の両方を使用するようにLDAPサーバーを構成する必要があります。OpenLDAPに対するSASLおよびGSSAPIの構成の詳細は、https://www.openldap.org/doc/admin24/sasl.htmlを参照してください。

    min_idおよびmax_idエントリでは、ユーザーおよびグループのID値の上限と下限を指定します。enumerateでは、プロバイダで使用可能なユーザーとグループの完全リストをSSSDがキャッシュするかどうかを指定します。ドメインに含まれるユーザーまたはグループが比較的少数である場合を除き、Falseに設定することをお薦めします。

    [nss]セクションでは、SSSデータベースと名前サービス・スイッチ(NSS)を統合するNSSモジュールを構成します。filter_usersおよびfilter_groupsエントリは、SSSから取得された指定のユーザーやグループに関する情報をNSSが取得しないようにします。reconnection_retriesでは、データ・プロバイダがクラッシュしたときにSSSDが再接続を試行する回数を指定します。enum_cache_timeoutでは、SSSDがユーザー情報リクエストをキャッシュする秒数を指定します。

    [pam]セクションでは、SSSとPAMを統合するPAMモジュールを構成します。offline_credentials_expirationエントリでは、認証プロバイダがオフラインのとき、キャッシュされたログインの有効日数を指定します。offline_failed_login_attemptsでは、認証プロバイダがオフラインのとき、ログイン試行の失敗が何回まで許されるかを指定します。offline_failed_login_delayでは、offline_failed_login_attemptsの回数だけログイン試行に失敗した後、新たにログイン試行が可能になるまでの分数を指定します。

  3. /etc/sssd/sssd.confのモードを0600に変更します。 

    # chmod 0600 /etc/sssd/sssd.conf

  4. SSSDサービスを有効にします。 

    # authconfig --update --enablesssd --enablesssdauth

    ノート:

    /etc/sssd/sssd.confを編集した場合は、このコマンドを使用してサービスを更新してください。

    --enablesssdオプションは、SSSをサポートするように/etc/nsswitch.confを更新します。

    --enablesssdauthオプションは、SSSDのサポートに必要なpam_sss.soエントリを含めるように/etc/pam.d/system-authを更新します。

Winbind認証について

Winbindは、Windowsサーバー上でユーザーおよびグループ情報を解決し、Oracle LinuxがWindowsユーザーおよびグループを把握できるようにするためのクライアント側サービスです。Winbind認証を構成するには、yumを使用してsamba-winbindパッケージをインストールします。このパッケージには、winbindサービスを実装するwinbinddデーモンが含まれます。

Winbind認証の有効化

認証構成GUIを使用してWinbindをユーザー・アカウント・データベースとして選択する場合、Microsoftワークグループ、Active DirectoryまたはWindows NTドメイン・コントローラに接続するための情報を入力するよう求められます。Winbindドメインの名前を入力し、Sambaサーバーのセキュリティ・モデルを選択します。
ads

Activity Directory Server (ADS)セキュリティ・モデルでは、SambaはADSレルムのドメイン・メンバーとして機能し、クライアントはActivity Directory認証にKerberosチケットを使用します。Kerberosを構成してサーバーをドメインに参加させる必要があり、これによって、ドメイン・コントローラでサーバーのマシン・アカウントが作成されます。

domain

ドメイン・セキュリティ・モデルでは、ローカルのSambaサーバーにはマシン・アカウント(ドメイン・セキュリティ・トラスト・アカウント)があり、Windows NT4セキュリティを実装するドメイン内でSambaはドメイン・コントローラを使用してユーザー名とパスワードを認証します。

注意:

ローカル・マシンがプライマリまたはバックアップ・ドメイン・コントローラとして機能する場合は、ドメイン・セキュリティ・モデルを使用しないでください。かわりに、ユーザー・セキュリティ・モデルを使用してください。

server

サーバー・セキュリティ・モデルでは、ローカルのSambaサーバーはWindows NTサーバーなどの別のサーバーでユーザー名とパスワードを認証します。

注意:

セキュリティ上の問題が多数あるため、サーバー・セキュリティ・モデルは非推奨です。

user

ユーザー・セキュリティ・モデルでは、クライアントは有効なユーザー名とパスワードでログインする必要があります。このモデルは、暗号化されたパスワードをサポートしています。サーバーがクライアントのユーザー名とパスワードを正常に検証できた場合、クライアントはパスワードを指定する必要なしに複数の共有をマウントできます。

選択するセキュリティ・モデルによっては、次の情報の指定が必要になることもあります。

  • Sambaサーバーが参加するADSレルムの名前(ADSセキュリティ・モデルのみ)。

  • ドメイン・コントローラの名前。ドメイン・コントローラが複数ある場合は、スペースで名前を区切ります。

  • Windows NTユーザー・アカウントに使用するログイン・テンプレート・シェル(ADSおよびドメイン・セキュリティ・モデルのみ)。

  • ドメイン・コントローラがオフラインの場合に、System Security Services Daemon (SSSD)でキャッシュされた情報を使用したユーザー認証を許可するかどうか。

選択内容によって、/etc/samba/smb.conf構成ファイルの[global]セクションのセキュリティ・ディレクティブが更新されます。

Kerberosが初期化されている場合は、ドメインに参加をクリックしてActive Directoryサーバー上にマシン・アカウントを作成し、Sambaドメイン・メンバー・サーバーにドメインに参加する権限を付与できます。

authconfigコマンドを使用して、Winbind認証を構成することもできます。ユーザーレベル・セキュリティ・モデルを使用するには、ドメインまたはワークグループの名前およびドメイン・コントローラのホスト名を指定します。たとえば: 
# authconfig --enablewinbind --enablewinbindauth --smbsecurity user \
  [--enablewinbindoffline] --smbservers="ad1.mydomain.com ad2.mydomain.com" \
  --smbworkgroup=MYDOMAIN --update

ドメイン・コントローラがオフラインの場合に、System Security Services Daemon (SSSD)でキャッシュされた情報を使用したユーザー認証を許可するには、--enablewinbindofflineオプションを指定します。

ドメイン・セキュリティ・モデルの場合は、追加でテンプレート・シェルを指定します。たとえば: 

# authconfig --enablewinbind --enablewinbindauth --smbsecurity domain \
  [--enablewinbindoffline] --smbservers="ad1.mydomain.com ad2.mydomain.com" \
  --smbworkgroup=MYDOMAIN --update --winbindtemplateshell=/bin/bash --update

ADSセキュリティ・モデルの場合は、追加でADSレルムとテンプレート・シェルを指定します。たとえば: 

# authconfig --enablewinbind --enablewinbindauth --smbsecurity ads \
  [--enablewinbindoffline] --smbservers="ad1.mydomain.com ad2.mydomain.com" \
  --smbworkgroup=MYDOMAIN --update --smbrealm MYDOMAIN.COM \
  --winbindtemplateshell=/bin/bash --update

詳細は、authconfig(8)マニュアル・ページを参照してください。