Linux環境の認証システムをWindows Server 2012に統合する方法を見つけようとしているところ、winbind
を使用する方法を見つけました。
私はGoogleを検索しましたが、時間の同期からいくつかの構成ファイルの構成まで、その方法を紹介するページがいくつかあります。
Linuxでホスト名とホストを以下のように設定しました。
[/ etc/hosts] 192.168.XXX.XX1 test1.example.comの例## Windows IP 192.168.XXX.XX2 test1 ## Linux IP [/ etc/hostname] test1
次のプロパティを持つActive Directoryをセットアップしましたが、2つのアカウントがあります。
コンピューター名:TEST1 ドメイン:example.com アカウント1:管理者 アカウント2:tester1
そこで、Linux環境のDNSをADのIPアドレスに設定しました。 「resolv.conf」の情報を確認できます。
[root〜]#nslookup example.com サーバー:192.168.xxx.xx1 アドレス:192.168.xxx.xx1#53 名前:example.com アドレス:192.168.xxx.xxx
「nsswitch.conf」で、「ファイル」の横にのみ「winbind」という単語を追加しました。
passwd:files winbind shadow:files sss winbind group:files winbind
「krb5.conf」で、ルックアップ部分とデフォルトのレルムを変更しました。
[libdefaults] dns_lookup_realm = true dns_lookup_kdc = true default_realm = EXAMPLE.COM [realms] DOMAIN.COM = { kdc = example.com admin_server = example.com } [domain_realm] 。domain.com = EXAMPLE.COM domain.com = EXAMPLE.COM
そして最後に、smb.conf
を設定しました。ただし、これを設定する方法はたくさんあるので、よくわかりません。 Googleページの1つを選択しました。
「administrator」IDでWindows Serverに接続しようとすると、次のエラーが表示されます。
[root〜]#net ads join -U Administrator gse_get_client_auth_token:gss_init_sec_context failed with [Unspecified GSS failure。マイナーコードにより詳細な情報が提供される場合があります:メッセージストリームが変更されました](2529638953) kinitは成功しましたが、user [Administrator] realm [EXAMPLE.COM]を使用したldap/test1.example.comのads_sasl_spnego_gensec_bind(KRB5)が失敗しました:試行されたログオン無効です。これは不正なユーザー名または認証情報が原因です。 ドメインに参加できませんでした:ADに接続できませんでした:試行されたログオンは無効です。これは不正なユーザー名または認証情報が原因です。
私はこのステップで立ち往生しており、Googleでそれを解決する方法を見つけることができません。 /etc/pam.d
の一部のファイルを編集する必要がありますか?
smb.conf
について 'testparm'ツールを使用した後、最終的に問題は見つかりませんでしたが、「net ads testjoin」を使用すると、次のメッセージが表示されます。
ads_connect:現在、ログオン要求を処理するために使用できるログオンサーバーはありません。
すべての変更を元に戻し、コンピューターアカウントをADから削除します。 winbind
パッケージを削除します。
適切なパッケージをインストールします。 Debianベースのシステムでは、apt-get install samba smbclient sssd realmd dnsutils policykit-1 packagekit sssd-tools sssd libnss-sss libpam-sss adcli
を使用できます。
sssd
が起動に失敗しても、この時点で心配する必要はありません。 realm
コマンドで構成する必要があります。これについては、後で説明します。
ローカルのLinuxベースのシステムのDNSサーバーにDCがあることを確認してください。ActiveDirectory環境の一部でない限り、追加のDNSサーバーを追加しないでください。単に/etc/resolv.conf
を編集して、 「このファイルを編集しないでください」という警告は、変更が上書きされる可能性があります。この時点で、システムは誰かの認証に失敗し、最終的にはドメインから脱落する可能性もあります(この時点でユーザーは不満を感じる傾向があります)。
Kerberosは約5分(300秒)を超えるスキューでは機能しないため、ローカル時刻がActive Directoryの時刻と一致していることを確認してください。
ローカルドメインcontoso.com
の場合、次の3つのコマンドをrootとして実行します。
domain=contoso.com # The FQDN itself. Not machine.FQDN
realm discover "$domain" # If this fails, stop and recheck everything
realm join "$domain" # [--user <ad_username>] [--computer-ou <ou>]
realm join
のADアカウント名を指定する必要がある場合は、realm join --user <ad_username> "$domain"
を使用して指定します。ここで、<ad_username>
は修飾されていないsAMAccountName
を表します。自分のADアカウントは、ドメイン管理者でなくても、最低10クライアントで機能するはずですが、administrator
は、パスワードがわかっている場合に役立ちます。 --computer-ou
オプションを使用すると、アカウントの初期OUを指定できます。正しい値がわからない場合は、空白のままにしてください(推測しないでください)。
sssd.conf
ファイルを修正します。 ad_hostname
は一部のバージョンに必要です バグを回避するには 。 LDAPグループのネストレベルにより、sssd
はネストされたグループのメンバーシップを処理できます。
sed -i "/^ad_domain /s/$/\nad_hostname = $(hostname).$domain/" /etc/sssd/sssd.conf
( echo; echo 'ldap_group_nesting_level = 5'; echo 'ldap_use_tokengroups = false' ) >>/etc/sssd/sssd.conf
service sssd restart