ADに基づくWindowsドメインのGNU / Linuxファイルサーバーの認証。 パート2

1.構成ファイル。


Sambaを使用してGNU / Linuxサーバーへのアクセスのみを構成します。 ユーザー認証は、/ etc / passwdを使用してローカルのままになります。

新しいサーバーに静的IPアドレスを割り当てます。 192.168.7.9とします。

最初に、DNSとして使用するサーバーを確認する必要があります。 ネットワーク内のドメインコントローラーである必要があります。 サーバーアドレスは192.168.7.2として定義されています。 ファイル/etc/resolv.confを編集します。 次のようになります。

search lab.local nameserver 192.168.7.2
      
      





すべてが機能するかどうかを確認します。

 #host 192.168.7.2 2.7.168.192.in-addr.arpa domain name pointer lab-dc1.lab.local. #
      
      





当然、あなたの場合、名前は異なります。 新しいサーバーを参照するlab.localドメインにDNSエントリを作成してください。 DNSの記録は、GNU / Linuxサーバーがドメインに含まれていることを意味するものではありません。 チェック:

 linux-test:~ # host 192.168.7.9 9.7.168.192.in-addr.arpa domain name pointer test-linux.lab.local. linux-test:~ # host test-linux test-linux.lab.local has address 192.168.7.9 linux-test:~ #
      
      





Windowsドメインで正常に動作するには、Kerberos、LDAP、およびSambaのいくつかのサービスが必要です。 一般に、Sambaを構成するだけでよく、他のサービスはオプションです。 しかし、それらを設定する方が良いでしょう-それらは将来便利になるかもしれません。

Kerberosは、単一の/etc/krb5.confファイルを使用して簡単に構成できます。 主なパラメーターはREALMであり、ドメインを指し、Kerberosサーバーのアドレスはドメインコントローラーのアドレスです。 ファイル/etc/krb5.confは次のようになります。

 linux-test:~ # more /etc/krb5.conf [libdefaults] default_realm = LAB.LOCAL clockskew = 300 # default_realm = EXAMPLE.COM [realms] LAB.LOCAL = { kdc = 192.168.7.2 default_domain = lab.local admin_server = 192.168.7.2 } # EXAMPLE.COM = { # kdc = kerberos.example.com # admin_server = kerberos.example.com # } [logging] kdc = FILE:/var/log/krb5/krb5kdc.log admin_server = FILE:/var/log/krb5/kadmind.log default = SYSLOG:NOTICE:DAEMON [domain_realm] .lab.local = LAB.LOCAL [appdefaults] pam = { ticket_lifetime = 1d renew_lifetime = 1d forwardable = true proxiable = false minimum_uid = 1 external = sshd use_shmem = sshd clockskew = 300 }
      
      





[libdefaults]セクションは、デフォルトドメインを指します。 LAB.LOCALがあります。 次に、[realms]セクションで、LAB.LOCALのパラメーター(Kerberosサーバーのドメイン名とアドレス)を指定します。 この場合、ドメインコントローラーはKerbeorsサーバーとして機能します。 [logging]セクションは、ログファイルの場所を示します。 これらのファイルは、何か問題が発生した場合のトラブルシューティングに役立ちます。

Kerberosの動作を確認します。

 linux-test:~ # kinit Administrator@LAB.LOCAL Password for Administrator@LAB.LOCAL: linux-test:~ # klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: Administrator@LAB.LOCAL Valid starting Expires Service principal 04/05/12 11:22:23 04/05/12 21:22:35 krbtgt/LAB.LOCAL@LAB.LOCAL renew until 04/06/12 11:22:23 linux-test:~ #
      
      





kinitコマンドはサーバーからチケットを受信し、klistはサーバーから受信したチケットを表示します。 kinitの実行はオプションですが、どういうわけかKerberosを確認する必要がありますか?

LDAPの構成もオプションです。Sambaは必要なファイルを作成し、必要なクエリを作成します。 ただし、後でLDAPが役立つ場合があります。 OpenLDAPの構成は、/ etc / openldap / ldap.confファイルに保存されます。 システム上に2つのldap.confファイルがある場合があることに注意してください。 それらは異なる目的を持ち、わずかに異なる構文さえあります。 / etc / openldapディレクトリにはOpenLDAP(およびSamba)のldap.confファイルが含まれ、/ etc / ldap.confファイルには(nss_ldapの)LDAPを介して名前を解決するための設定が含まれます。 他の記事の/etc/ldap.confファイルに戻りますが、今度は/etc/openldap/ldap.confを構成します

 linux-test:~ # cat /etc/openldap/ldap.conf # # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. #BASE dc=example,dc=com #URI ldap://ldap.example.com ldap://ldap-master.example.com:666 #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never uri ldap://192.168.7.2 base DC=lab,DC=local linux-test:~ #
      
      





ご覧のとおり、すべてが非常に簡単です。LDAPサーバーURI(これはドメインコントローラーです)と検索のベースを指定する必要があります。

それでは、最も難しい部分であるSambaのセットアップに移りましょう。

Sambaには、smbd、nmbd、winbindの3つのデーモンが含まれています。 これらはすべて、/ etc / samba / smb.confファイルから設定を取得します。

Smbdは、SMB / CIFSサービス(これは実際にはSambaサーバーです)へのクライアントアクセスを担当します。 Nmbdは、Netbiosの名前解決サービスです。 Winbindは、Windowsドメインサービスを介した(コンピューターとユーザーの両方の)名前解決サービスです。

多くのマニュアルでは、Sambaに加えて、GNU / LinuxとWindowsドメインコントローラーとの関係を担当するサービスであるwinbindを構成する必要があることにも言及しています。 Sambaのみを構成する必要がある特定のケースでは、winbind設定を省略できます。 Winbindは、Windowsドメインでさまざまなサービスの承認を提供し、PAMモジュールとWindowsドメインコントローラー間のインターフェイスを提供します。 winbindが機能しない場合でも、Sambaは動作し続けます。 しかし、winbindをセットアップすることにより、ドメインコントローラーを介して承認されるさまざまなサービスを追加することで、サーバーをさらに拡張することができます。

すべてのユーザーが共有ファイルディレクトリとユーザーホームディレクトリにアクセスできるようにすることで、最も単純なサーバーを作成します。 Sambaサーバーへのアクセスの構成については、他の記事で詳しく説明します。

/etc/samba/smb.confファイルで、次の行を指定する必要があります。

 [global] workgroup = LAB passdb backend = ldapsam:ldap://192.168.7.2 printing = cups printcap name = cups printcap cache time = 750 cups options = raw map to guest = Bad User logon path = \\%L\profiles\.msprofile logon home = \\%L\%U\.9xprofile logon drive = P: usershare allow guests = Yes
      
      





ここでは、ドメインの短縮名(LAB)とパスワードが保存される場所を示します。passdbバックエンドパラメーターは、パスワードがドメインコントローラーであるLDAPサーバー上にあることを示します。 ところで、複数のサーバーをスペースでリストすることで指定できます。 これは、複数のドメインコントローラーがある場合に便利です。 usershare allow guest = Yesの行により、ユーザーはゲスト用にフォルダを開くことでフォルダへのアクセスを制御できます。 残りの行は、印刷管理と登録プロセスに関連しています。 私たちの場合、これらはオプションであり、Sambaディストリビューションの構成ファイルから移行されます。

smb.confの[global]セクションの編集を続けます。

  domain logons = No domain master = No security = ADS encrypt passwords = yes
      
      





ドメインログオンとドメインマスター文字列により、Sambaをドメインコントローラーとして使用できます。 これは私たちの場合ではないため、いいえ。

文字列security = ADSはキーです。 したがって、サーバーがWindowsドメインのメンバーであり、ADが承認を担当していることをSambaに示します。 文字列encrypt passwords = yesは、暗号化されたパスワードが使用されることを意味します。

同じ[global]セクションの編集を続けます。

  ldap admin dn = Administrator@lab.local ldap delete dn = No ldap group suffix = ou=Groups ldap idmap suffix = ou=Idmap ldap machine suffix = ou=Computers ldap passwd sync = Yes ldap ssl = No ldap suffix = DC=lab,DC=local ldap timeout = 5 ldap user suffix = ou=Users
      
      





これらの行は、LDAPサーバーへの接続の管理に関連しています。 管理者DNレコードフォームにはuser @ domainフォームがあることに注意してください-Kerberosをテストするときに指定したものと一致する必要があります。 残りの行は、ADのさまざまな場所のサフィックスを示します。

次の行がKerberosに適用されます。

  realm = LAB.LOCAL template homedir = /home/%D/%U winbind refresh tickets = yes kerberos method = system keytab
      
      





ここでは、KerberosでREALMと認証方法を指定します。

これで、winbind構成に関連する行は次のとおりです。

  winbind separator = / winbind enum users = yes winbind enum groups = yes winbind nested groups = yes winbind use default domain = No winbind nss info = rfc2307 winbind offline logon = yes
      
      





ここでは、Winbind操作のさまざまなパラメーターを示します。ドメイン名とユーザー名を分離するためのフォーム、ユーザー名とグループ名をリストするためのwinbindの許可、オフライン認証の許可などです。 これらの設定は、Samba開発者によって推奨されています。

グローバル設定セクションが完了しました。 他のマニュアルにあるパスワードサーバーとidmapバックエンドの行がないことに注意してください。 Sambaは、パスワードの出所を把握する必要があります。

ディレクトリの設定に移りましょう。 ここではすべてが簡単です:

 [homes] comment = Home Directories valid users = %S, %D%w%S browseable = No read only = No inherit acls = Yes available = Yes [profiles] comment = Network Profiles Service path = %H read only = No store dos attributes = Yes create mask = 0600 directory mask = 0700 [users] comment = All users path = /home read only = No inherit acls = Yes veto files = /aquota.user/groups/shares/ [groups] comment = All groups path = /home/groups read only = No inherit acls = Yes [SRV] comment = Common files path = /local write list = Administrator guest ok = Yes hosts allow = 192.168.7.
      
      





Sambaディストリビューションで配布される共有ディレクトリの標準リストに、[SRV]セクションのみを追加しました-パブリックディレクトリ。

すべての必要なファイルの構成が完了し、サーバーの操作性のチェックを開始します。



2.ヘルスチェック。


ここで、設定の正確さを確認し、新しいサーバーをWindowsドメインに含めます。 最初に、Samba構成の正確さを確認します。

l
 inux-test:~ # testparm Load smb config files from /etc/samba/smb.conf rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384) Processing section "[homes]" Processing section "[profiles]" Processing section "[users]" Processing section "[groups]" Processing section "[SRV]" Loaded services file OK. Server role: ROLE_DOMAIN_MEMBER Press enter to see a dump of your service definitions
      
      





ご覧のとおり、重大な警告や構成エラーはありません。

次に、smbd、nmbd、およびwinbinddデーモンを順番に実行します。 これは、ファイル/etc/init.d/smb、/etc/init.d/nmb、および/etc/init.d/winbindを使用して行います。 これを手動で行うこともできます。これは、さまざまな追加情報を取得するのに役立つ場合があります。 これを行う方法は、smbd、nmbd、winbinddの組み込みマニュアル(man)に記載されています。

ドメインとドメイン内のサーバーのステータスを確認します。 ドメインステータスはnet ads infoコマンドで取得できます

 linux-test:~ # net ads info LDAP server: 192.168.7.2 LDAP server name: LAB-DC1.lab.local Realm: LAB.LOCAL Bind Path: dc=LAB,dc=LOCAL LDAP port: 389 Server time: Thu, 05 Apr 2012 13:03:47 MSK KDC server: 192.168.7.2 Server time offset: 4 linux-test:~ #
      
      





どうやら、すべてが順調です。 コマンドによって表示されるパラメーターが計画と一致しない場合は、理由を調べる必要があります。 ドメイン内のサーバーのステータスを確認します。

l
 inux-test:~ # net ads status -U Administrator Enter Administrator's password: No machine account for 'LINUX-TEST' found linux-test:~ #
      
      





したがって、サーバーはドメインに含まれていません。 ドメインコントローラーへの要求は管理者に代わって行われ、パスワードはWindowsドメイン管理者アカウントから指定する必要があります。

次に、サーバーをドメインに含める必要があります。

l
 inux-test:~ # net ads join -U Administrator Enter Administrator's password: Using short domain name -- LAB Joined 'LINUX-TEST' to realm 'lab.local' DNS Update for linux-test.lab.local failed: ERROR_DNS_UPDATE_FAILED DNS update failed! linux-test:~ #
      
      





したがって、次の行から明らかなように、新しいサーバーはドメインに含まれています。

 Using short domain name -- LAB Joined 'LINUX-TEST' to realm 'lab.local'
      
      





動的DNSの変更、我々は合格しませんでした。 計画されていなかったので、これは怖くないです。 ここで、すべてのプロセス(smbd、nmbd、winbindd)を再起動することをお勧めします。 再起動後、さらに確認するまで数分かかることに注意してください。

ドメイン内のサーバーのステータスを確認します。

 linux-test:~ # net ads status -U Administrator Enter Administrator's password:
      
      





応答として、ドメイン内の新しいサーバーのステータスの印刷物を取得します。 サーバーに関連するさまざまなADフィールドがそこにリストされます。 また、ドメインコントローラーでAD管理ツールを実行することにより、コンピュータータブにGNU / Linuxサーバーが表示されます。



ドメインユーザーのリストを確認できます。

l
 inux-test:~ # net ads user -U Administrator Enter Administrator's password: Administrator Guest krbtgt usertest linux-test:~ #
      
      





そして、winbindの動作を確認します。

 linux-test:~ # wbinfo -t checking the trust secret for domain LAB via RPC calls succeeded linux-test:~ #
      
      





そして、ドメイン内のユーザーのリストを取得します。

l
 inux-test:~ # wbinfo -u LAB/administrator LAB/guest LAB/krbtgt LAB/usertest linux-test:~ #
      
      





wbinfoを介してドメインのステータスを確認できます。

l
 inux-test:~ # wbinfo -D LAB Name : LAB Alt_Name : lab.local SID : S-1-5-21-3914562201-450990341-53424453 Active Directory : Yes Native : Yes Primary : Yes linux-test:~ # wbinfo -P checking the NETLOGON dc connection succeeded linux-test:~ #
      
      





すべてが順調です。 ここで最も重要なチェックは、Windows 7を実行しているワークステーションを使用して新しいサーバーのディレクトリを開くことです。このワークステーションはドメインに含まれています。 名前またはIPアドレスを指定して、Windowsブラウザーの[ネットワーク]タブに新しいサーバーが表示されます。







これで、サーバーをセットアップするためのさらなる手順に進むことができます。 将来的には、GNU / Linuxディストリビューションに応じて、説明したプロセスの微妙な違いを考慮し、Sambaサーバーへのアクセス権の設定について詳しく調べます。

この作業は、情報コンピューティングセンターMPEIに基づいて実行されました。



All Articles