第1章 SSSD を使用して RHEL システムを AD に直接接続

本セクションでは、SSSD (System Security Services Daemon) を使用して、RHEL システムを Active Directory (AD) に接続する方法を説明します。RHEL システムを Active Directory (AD) に接続するには、2 つのコンポーネントが必要です。1 つ目のコンポーネントは SSSD と呼ばれ、中央の ID および認証ソースと相互作用します。2 つ目のコンポーネントは realmd と呼ばれ、利用可能なドメインを検出し、SSSD がドメインに接続するように基盤となる RHEL システムサービスを設定します。

1.1. SSSD を使用した直接統合の概要

オフラインのログインを許可するために、SSSD を使用して、ユーザーキャッシュを備えた共通のフレームワークを介して、ユーザーディレクトリーにアクセスして認証および認可を行います。SSSD は高度な設定が可能で、PAM (Pluggable Authentication Module) と NSS (Name Switch Service) の統合と、ローカルユーザーと、中央サーバーから取得した拡張ユーザーデータを保存するデータベースを提供します。SSSD は、RHEL システムを以下のいずれかの ID サーバーに接続するのに推奨されるコンポーネントです。

  • Active Directory
  • RHEL の ID 管理 (IdM)
  • あらゆる汎用 LDAP または Kerberos サーバー
注記

SSSD との直接統合は、デフォルトで 1 つの AD フォレスト内でのみ機能します。

SSSD が AD と Linux システムを直接統合するように設定する最も便利な方法は、realmd サービスを使用することです。これにより、呼び出し元はネットワーク認証およびドメインメンバーシップを標準的な方法で設定できます。realmd サービスは、アクセス可能なドメインおよびレルムに関する情報を自動的に検出し、ドメインまたはレルムに参加するのに高度な設定を必要としません。

SSSD は、AD との直接統合および間接統合の両方に使用でき、ある統合アプローチから別の統合アプローチに切り替えることができます。直接統合は、RHEL システムを AD 環境に導入する簡単な方法です。ただし、RHEL システムの共有が増えると、デプロイメントは通常、ホストベースのアクセス制御、sudo、SELinux ユーザーマッピングなどの ID 関連のポリシーをより集中管理する必要があります。最初に、ローカル設定ファイルで、RHEL システムのこのような設定を維持できます。ただし、システムの数が増えると、Red Hat Satellite などのプロビジョニングシステムでは、設定ファイルの配布と管理が簡単になります。直接統合がスケーリングされない場合は、間接統合を検討する必要があります。直接統合 (RHEL クライアントは AD ドメインにあります) から間接統合 (AD と信頼関係がある IdM) への移行の詳細は、「Moving RHEL clients from AD domain to IdM Server」を参照してください。

ユースケースに適した統合のタイプは、「間接統合と直接統合のどちらを選択するべきか」を参照してください。

関連情報

  • man ページの realm(8)
  • man ページの sssd-ad(5)
  • man ページの sssd(8)

1.2. 直接統合でサポートされる Windows プラットフォーム

RHEL システムと、以下のフォレストおよびドメインの機能レベルを使用する Active Directory フォレストを直接統合できます。

  • フォレスト機能レベルの範囲 - Windows Server 2008 ~ Windows Server 2016
  • ドメイン機能レベルの範囲 - Windows Server 2008 ~ Windows Server 2016

直接統合は、以下のサポート対象のオペレーティングシステムでテストされています。

  • Windows Server 2019
  • Windows Server 2016
  • Windows Server 2012 R2
注記

Windows Server 2019 では、新しい機能レベルが導入されていません。Windows Server 2019 が使用する機能レベルで最も高いものは Windows Server 2016 です。

1.3. AD および RHEL で一般的な暗号化タイプに対応

デフォルトでは、SSSD は RC4、AES-128、および AES-256 の Kerberos 暗号化タイプに対応します。

RC4 暗号化は、新しい暗号化タイプ AES-128 および AES-256 よりも安全ではないと見なされるため、RHEL 8 ではデフォルトで非推奨となり、無効にされています。一方、Active Directory (AD) ユーザーの認証情報と AD ドメイン間の信頼は RC4 暗号化をサポートしており、AES 暗号化タイプに対応していない可能性があります。

一般的な暗号化タイプがないと、RHEL ホストと AD ドメイン間の通信が機能しないか、一部の AD アカウントが認証できない可能性があります。この状況を修正するには、以下の設定のいずれかを変更します。

  • Active Directory で AES 暗号化サポートを有効にする (推奨オプション) - AD フォレストの AD ドメイン間で信頼されるようにするには、Microsoft の記事 「AD DS: Security: Kerberos "Unsupported etype" error when accessing a resource in a trusted domain」を参照してください。
  • RC4 サポートを RHEL で有効化: AD ドメインコントローラーに対する認証が行われるすべての RHEL ホストで次のコマンドを実行します。

    1. update-crypto-policies コマンドを使用して、DEFAULT 暗号化ポリシーに加え AD-SUPPORT 暗号化サブポリシーを有効にします。

      [root@host ~]# update-crypto-policies --set DEFAULT:AD-SUPPORT
      Setting system policy to DEFAULT:AD-SUPPORT
      Note: System-wide crypto policies are applied on application start-up.
      It is recommended to restart the system for the change of policies
      to fully take place.
    2. ホストを再起動します。
重要

AD-SUPPORT 暗号化サブポリシーは、RHEL 8.3 以降でのみ利用できます。

  • RHEL 8.2 以前は RC4 のサポートを有効にするには、cipher = RC4-128+ でカスタム暗号化モジュールポリシーを作成および有効にします。詳細は、ポリシー修飾子を使用したシステム全体の暗号化ポリシーのカスタマイズを参照してください。
  • RHEL 8.0 および RHEL 8.1 で RC4 のサポートを有効にするには、/etc/crypto-policies/back-ends/krb5.config ファイルの permitted_enctypes オプションに +rc4 を追加します。

    [libdefaults]
    permitted_enctypes = aes256-cts-hmac-sha1-96 aes256-cts-hmac-sha384-192 camellia256-cts-cmac aes128-cts-hmac-sha1-96 aes128-cts-hmac-sha256-128 camellia128-cts-cmac +rc4

関連情報

1.4. AD に直接接続

本セクションでは、ID マッピングまたは POSIX 属性のいずれかを使用して AD と直接統合する方法を説明します。

1.4.1. SSSD を使用した AD ドメインの検出および参加

この手順では、AD ドメインを検出し、SSSD を使用してこのドメインに RHEL システムを接続する方法を説明します。

前提条件

  • RHEL ホストの以下のポートが開き、AD ドメインコントローラーからアクセスできることを確認します。

    表1.1 SSSD を使用した Linux システムの AD への直接統合に必要なポート

    サービスポートプロトコル備考

    DNS

    53

    UDP および TCP

     

    LDAP

    389

    UDP および TCP

     

    Kerberos

    88

    UDP および TCP

     

    Kerberos

    464

    UDP および TCP

    パスワードを設定または変更するために、kadmin により使用されます。

    LDAP グローバルカタログ

    3268

    TCP

    id_provider = ad オプションが使用されている場合

    NTP

    123

    UDP

    任意

  • DNS に AD ドメインコントローラーサーバーが使用されていることを確認します。
  • 両方のシステムのシステム時刻が同期していることを確認します。これにより、Kerberos が正常に機能できるようになります。

手順

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

    # yum install samba-common-tools realmd oddjob oddjob-mkhomedir sssd adcli krb5-workstation
  2. 特定のドメインの情報を表示するには、realm detect を実行して、検出するドメイン名を追加します。

    # realm discover ad.example.com
    ad.example.com
      type: kerberos
      realm-name: AD.EXAMPLE.COM
      domain-name: ad.example.com
      configured: no
      server-software: active-directory
      client-software: sssd
      required-package: oddjob
      required-package: oddjob-mkhomedir
      required-package: sssd
      required-package: adcli
      required-package: samba-common

    realmd システムは DNS SRV ルックアップを使用して、このドメイン内のドメインコントローラーを自動検索します。

    注記

    realmd システムは、Active Directory ドメインと Identity Management ドメインの両方を検出できます。両方のドメインが環境に存在する場合は、特定タイプのサーバーに検出結果を絞り込むには --server-software=active-directory オプションを使用します。

  3. realm join コマンドを使用して、ローカルの RHEL システムを設定します。realmd スイートは、必要なすべての設定ファイルを自動的に編集します。たとえば、ad.example.com ドメインの場合は、次のコマンドを実行します。

    # realm join ad.example.com

検証手順

  • 管理者ユーザーなど、AD ユーザーの詳細を表示します。

    # getent passwd administrator@ad.example.com
    administrator@ad.example.com:*:1450400500:1450400513:Administrator:/home/administrator@ad.example.com:/bin/bash

関連情報

  • man ページの realm(8) を参照してください。
  • man ページの nmcli(1) を参照してください。

1.4.2. AD との統合オプション: ID マッピングまたは POSIX 属性の使用

Linux システムおよび Windows システムは、ユーザーおよびグループに異なる識別子を使用します。

  • Linux では、ユーザー ID (UID) と グループ ID (GID) が使用されます。『基本的なシステム設定の構成』の「ユーザーアカウントおよびグループアカウントの管理」を参照してください。Linux の UID および GID は、POSIX 標準に準拠します。
  • Windows は、セキュリティー ID (SID) を使用します。
重要

RHEL システムを AD に接続すると、AD のユーザー名とパスワードを使用して認証できます。名前の重複が原因で競合が生じ、認証プロセスが中断される可能性があるため、Windows ユーザーと同じ名前の Linux ユーザーを作成しないでください。

RHEL システムに対して AD ユーザーとして認証するには、UID と GID が割り当てられている必要があります。SSSD は、ID マッピングまたは POSIX 属性のいずれかを使用して AD と統合するオプションを提供します。デフォルトでは、ID マッピングを使用します。

1.4.2.1. AD ユーザー用に新規 UID および GID を自動的に生成

SSSD は、AD ユーザーの SID を使用して、ID マッピング と呼ばれるプロセスにおいてアルゴリズムで POSIX ID を生成できます。ID マッピングは、AD の SID と Linux の ID との間にマップを作成します。

  • SSSD が新しい AD ドメインを検出すると、利用可能な ID の範囲を新しいドメインに割り当てます。
  • AD ユーザーが SSSD クライアントマシンに初めてログインすると、SSSD は、ユーザーの SID およびそのドメインの ID 範囲を基にした UID など、SSSD キャッシュにユーザーのエントリーを作成します。
  • AD ユーザーの ID は、同じ SID から一貫した方法で生成されるため、Red Hat Enterprise Linux システムにログインする場合は、そのユーザーに同じ UID と GID が使用されます。

SSSD を使用した AD ドメインの検出および参加」を参照してください。

注記

全クライアントシステムが SSSD を使用して SID を Linux ID にマッピングすると、マッピングは一貫性を維持します。一部のクライアントが別のソフトウェアを使用する場合は、以下のいずれかを選択します。

  • すべてのクライアントで同じマッピングアルゴリズムが使用されていることを確認します。
  • AD に定義されている明示的な POSIX 属性を使用します。

1.4.2.2. AD で定義されている POSIX 属性の使用

AD は、uidNumbergidNumberunixHomeDirectoryloginShell などの POSIX 属性を作成して保存できます。

上記の ID マッピングを使用すると、SSSD は新しい UID と GID を作成し、AD で定義された値を上書きします。AD 定義の値を維持するには、SSSD で ID マッピングを無効にする必要があります。

「Active Directory で定義された POSIX 属性を使用した AD への接続」を参照してください。

1.4.3. Active Directory で定義された POSIX 属性を使用した AD への接続

最適なパフォーマンスを得るには、POSIX 属性を AD グローバルカタログに公開します。POSIX 属性がグローバルカタログにない場合、SSSD は LDAP ポート上の個々のドメインコントローラーに直接接続します。

前提条件

  • RHEL ホストの以下のポートが開き、AD ドメインコントローラーからアクセスできることを確認します。

    表1.2 SSSD を使用した Linux システムの AD への直接統合に必要なポート

    サービスポートプロトコル備考

    DNS

    53

    UDP および TCP

     

    LDAP

    389

    UDP および TCP

     

    Kerberos

    88

    UDP および TCP

     

    Kerberos

    464

    UDP および TCP

    パスワードを設定または変更するために、kadmin により使用されます。

    LDAP グローバルカタログ

    3268

    TCP

    id_provider = ad オプションが使用されている場合

    NTP

    123

    UDP

    任意

  • DNS に AD ドメインコントローラーサーバーが使用されていることを確認します。
  • 両方のシステムのシステム時刻が同期していることを確認します。これにより、Kerberos が正常に機能できるようになります。

手順

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

    # yum install realmd oddjob oddjob-mkhomedir sssd adcli krb5-workstation
  2. realm join コマンドに --automatic-id-mapping=no オプションを付けて実行して、ローカルの RHEL システムで ID マッピングを無効にします。realmd スイートは、必要な設定ファイルをすべて自動的に編集します。たとえば、ad.example.com ドメインの場合は、次のコマンドを実行します。

    # realm join --automatic-id-mapping=no ad.example.com
  3. ドメインに参加している場合は、SSSD で ID マッピングを手動で無効にできます。

    1. /etc/sssd/sssd.conf ファイルを開きます。
    2. AD ドメインセクションで、ldap_id_mapping = false 設定を追加します。
    3. SSSD キャッシュを削除します。

      rm -f /var/lib/sss/db/*
    4. SSSD を再起動します。

      systemctl restart sssd

SSSD は、ローカルで作成するのではなく、AD の POSIX 属性を使用するようになりました。

注記

AD のユーザーに関連する POSIX 属性 (uidNumbergidNumberunixHomeDirectory、および loginShell) を設定する必要があります。

検証手順

  • 管理者ユーザーなど、AD ユーザーの詳細を表示します。

    # getent passwd administrator@ad.example.com
    administrator@ad.example.com:*:10000:10000:Administrator:/home/Administrator:/bin/bash

関連情報

  • ID マッピングおよび ldap_id_mapping パラメーターの詳細は、man ページの sssd-ldap(8) を参照してください。

1.4.4. SSSD を使用したさまざまな AD フォレストでの複数ドメインへの接続

この手順では、異なるフォレストで複数の Active Directory (AD) ドメインに参加して認証する方法を説明します。このドメインには信頼関係がありません。

この例では、addomain1.comaddomain2.com の 2 つのドメインを参加させる方法を説明します。realmd を使用して最初のドメインに参加し、そのドメインの SSSD、Kerberos、およびその他のユーティリティーを自動的に設定します。adcli を使用して追加のドメインに参加し、手動で設定ファイルにそのドメインを追加します。

前提条件

  • RHEL ホストの以下のポートが開き、AD ドメインコントローラーからアクセスできることを確認します。

    表1.3 SSSD を使用した Linux システムの AD への直接統合に必要なポート

    サービスポートプロトコル備考

    DNS

    53

    UDP および TCP

     

    LDAP

    389

    UDP および TCP

     

    Kerberos

    88

    UDP および TCP

     

    Kerberos

    464

    UDP および TCP

    パスワードを設定または変更するために、kadmin により使用されます。

    LDAP グローバルカタログ

    3268

    TCP

    id_provider = ad オプションが使用されている場合

    NTP

    123

    UDP

    任意

  • DNS に AD ドメインコントローラーサーバーが使用されていることを確認します。
  • 両方のシステムのシステム時刻が同期していることを確認します。これにより、Kerberos が正常に機能できるようになります。
  • マシンをそのドメインに参加させる権限を持つ各 AD ドメインに、AD 管理者アカウントの認証情報があることを確認します。

手順

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

    # yum install sssd realmd adcli samba-common-tools oddjob oddjob-mkhomedir
  2. realmd を使用して、最初の AD ドメイン addomain1.com に参加します。

    # realm join ADDOMAIN1.COM
  3. システムの keytab を一意の名前に変更します。

    # mv /etc/krb5.keytab /etc/addomain1.com.krb5.keytab
  4. adcli を使用して、2 番目の AD ドメインと追加のドメインに参加します。-K オプションを使用して、ホストの認証情報が書き込まれる Kerberos キータブの固有のパスを指定します。

    # adcli join -D dc2.addomain2.com -K /etc/addomain2.com.krb5.keytab
  5. /etc/krb5.conf を変更します。

    • includedir オプションを追加して、SSSD 設定ファイルを追加します。
    • dns_lookup_kdc オプションを使用して、AD ドメインコントローラーの DNS ルックアップを有効にします。

      includedir /var/lib/sss/pubconf/krb5.include.d/
      
      [logging]
       default = FILE:/var/log/krb5libs.log
       kdc = FILE:/var/log/krb5kdc.log
       admin_server = FILE:/var/log/kadmind.log
      
      [libdefaults]
       default_realm = ADDOMAIN1.COM
       dns_lookup_realm = false
       dns_lookup_kdc = true
       ticket_lifetime = 24h
       renew_lifetime = 7d
       forwardable = true
      
      ...
  6. /etc/sssd/sssd.conf を変更して、使用中のすべての AD ドメインに関する情報を追加します。

    [sssd]
    services = nss, pam
    config_file_version = 2
    domains = addomain1.com, addomain2.com
    
    [domain/addomain1.com]
    id_provider = ad
    access_provider = ad
    krb5_keytab = /etc/addomain1.com.krb5.keytab
    ldap_krb5_keytab = /etc/addomain1.com.krb5.keytab
    ad_server = dc1.addomain1.com
    ad_maximum_machine_account_password_age = 0
    use_fully_qualified_names = true
    default_shell=/bin/bash
    override_homedir=/home/%d/%u
    
    [domain/addomain2.com]
    id_provider = ad
    access_provider = ad
    krb5_keytab = /etc/addomain2.com.krb5.keytab
    ldap_krb5_keytab = /etc/addomain2.com.krb5.keytab
    ad_server = dc2.addomain2.com
    ad_maximum_machine_account_password_age = 0
    use_fully_qualified_names = true
    default_shell=/bin/bash
    override_homedir=/home/%d/%u
    
    [nss]
    
    [pam]
    • 各ドメインセクションで、krb5_keytab オプションおよび ldap_krb5_keytab オプションで各ドメインに対応する Kerberos キータブへのパスを指定します。
    • ad_maximum_machine_account_password_age = 0 を設定して、ホストの Kerberos キーの更新を無効にします。
    • use_fully_qualified_names = true を設定して、異なるドメインのユーザーを区別します。
    • override_homedir = /home/%d/%u を設定し、異なるドメイン (%d) の各ユーザー (%u) がそれぞれ一意のホームディレクトリーを受け取るようにします。たとえば、ユーザー linuxuser@addomain1.com のホームディレクトリーは、/home/addomain1.com/linuxuser です。
  7. SSH は、システムキータブからホストキーを取得し、GSSAPI/Kerberos を介してシングルサインオン機能を提供します。シングルサインオンを使用する場合は、現在の Kerberos ホストキーをすべてシステムキータブ /etc/KBR5.keytab にコピーします。

    # ktutil
    ktutil:  rkt /etc/addomain1.com.krb5.keytab
    ktutil:  rkt /etc/addomain2.com.krb5.keytab
    ktutil:  wkt /etc/krb5.keytab
  8. SSSD サービスを再起動して有効にします。

    # systemctl restart sssd
    # systemctl enable sssd

検証手順

  1. 各 AD ドメインのユーザーの詳細を表示します。

    # id administrator@addomain1.com
    uid=1240800500(administrator@addomain1.com) gid=1240800513(domain users@addomain1.com) groups=1240800513(domain users@addomain1.com),1240800512(domain admins@addomain1.com),1240800518(schema admins@addomain1.com),1240800520(group policy creator owners@addomain1.com),1240800572(denied rodc password replication group@addomain1.com),1240800519(enterprise admins@addomain1.com)
    
    # id administrator@addomain2.com
    uid=1013800500(administrator@addomain2.com) gid=1013800500(administrator@addomain2.com) groups=1013800500(administrator@addomain2.com),1013800513(domain users@addomain2.com)
  2. 各ドメインのユーザーとしてログインし、ユーザーに正しいホームディレクトリーが作成されていることを確認します。

    # ssh administrator@addomain1.com@localhost
    administrator@addomain1.com@localhost's password:
    Creating directory '/home/addomain1.com/administrator'.
    
    $ pwd
    /home/addomain1.com/administrator
    # ssh administrator@addomain2.com@localhost
    administrator@addomain2.com@localhost's password:
    Creating directory '/home/addomain2.com/administrator'.
    
    $ pwd
    /home/addomain2.com/administrator

1.5. AD プロバイダーが動的 DNS 更新を処理する方法

Active Directory (AD) は、アクティブではないレコードをタイムアウト (aging) および削除 (scavenging) して、DNS レコードをアクティブに管理します。

デフォルトでは、SSSD サービスは、RHEL クライアントの DNS レコードを以下の間隔で更新します。

  • アイデンティティープロバイダーがオンラインになるタイミング。
  • RHEL システムが再起動したタイミング。
  • /etc/sssd/sssd.conf 設定ファイルの dyndns_refresh_interval オプションで指定される間隔。デフォルト値は 86400 秒 (24 時間) です。

    注記

    dyndns_refresh_interval オプションを DHCP リースと同じ間隔に設定すると、IP リースの更新後に DNS レコードを更新できます。

SSSD は、Kerberos/GSSAPI for DNS (GSS-TSIG) を使用して動的 DNS 更新を AD サーバーに送信します。そのため、必要な操作は、AD へのセキュアな接続を有効にするだけです。

関連情報

  • sssd-ad(5) の man ページ

1.6. AD プロバイダーの動的 DNS 設定の変更

以下の手順では、SSSD サービス内の設定を調節して、Active Directory 環境に参加している RHEL ホストの DNS レコードを自動更新する間隔を変化させます。

前提条件

  • RHEL ホストが SSSD サービスを使用して Active Directory 環境に追加している。
  • /etc/sssd/sssd.conf 設定ファイルを編集するには、root パーミッションが必要です。

手順

  1. テキストエディターで /etc/sssd/sssd.conf 設定ファイルを開きます。
  2. AD ドメインの [domain] セクションに以下のオプションを追加して、DNS レコードの更新間隔を 12 時間に設定し、PTR レコードの更新を無効にして DNS レコード Time To Live (TTL)を 1 時間に設定します。

    [domain/ad.example.com]
    id_provider = ad
    ...
    dyndns_refresh_interval = 43200
    dyndns_update_ptr = false
    dyndns_ttl = 3600
  3. /etc/sssd/sssd.conf 設定ファイルを保存して閉じます。
  4. SSSD サービスを再起動して、設定の変更を読み込みます。

    [root@client ~]# systemctl restart sssd
注記

sssd.conf ファイルの dyndns_update オプションを false に設定すると、動的 DNS 更新を無効にできます。

[domain/ad.example.com]
id_provider = ad
...

dyndns_update = false

関連情報

  • の sssd-ad(5) の man ページ

1.7. AD プロバイダーが信頼されるドメインを処理する方法

本セクションでは、/etc/sssd/sssd.conf 設定ファイルで id_provider = ad オプションを設定した場合に、どのように信頼できるドメインを SSSD が処理するかを説明します。

  • SSSD は、AD フォレストのドメインを 1 つだけサポートします。SSSD が複数のフォレストから複数のドメインにアクセスする必要がある場合は、SSSD の代わりに信頼 (推奨) または winbindd サービスで IPA を使用することを検討してください。
  • デフォルトでは、SSSD はフォレスト内のすべてのドメインを検出し、信頼されるドメイン内のオブジェクトの要求が到達すると、SSSD はこれを解決しようとします。

    信頼できるドメインに到達できない、または地理的に離れているために遅くなる場合は、/etc/sssd/sssd.confad_enabled_domains パラメーターを設定して、どの信頼ドメインから SSSD がオブジェクトを解決するかを制限できます。

  • デフォルトでは、完全修飾ユーザー名を使用して信頼されるドメインのユーザーを解決する必要があります。

関連情報

  • sssd.conf(5) の man ページ

1.8. realm コマンド

realmd システムの主要なタスク領域は、以下の 2 つになります。

  • ドメインでのシステム登録の管理
  • ローカルシステムリソースへのアクセスが許可されるドメインユーザーの制御

realmd では、コマンドラインツールの realm を使用してコマンドを実行します。ほとんどの realm コマンドでは、ユーティリティーが実行するアクションと、アクションを実行するドメインやユーザーアカウントなどのエンティティーを指定する必要があります。

表1.4 realmd コマンド

コマンド説明

レルムコマンド

discover

ネットワーク上にあるドメインの検出スキャンを実行します。

join

指定したドメインにシステムを追加します。

leave

指定したドメインからシステムを削除します。

list

システムに設定したすべてのドメイン、または検出され設定されているすべてのドメインを表示します。

ログインコマンド

permit

設定されているドメイン内の特定のユーザーまたはすべてのユーザーによるローカルシステムへのアクセスを有効にします。

deny

設定されているドメイン内の特定のユーザーまたはすべてのユーザーがローカルシステムにアクセスするのを制限します。

realm コマンドの詳細は、man ページの realm(8) を参照してください。