AD環境内でのLinuxユーザーと権限の管理
問題：グループ経由のLinuxサーバー上のリソース（サービス、ホームディレクトリへのアクセス、ローカルユーザーグループへの参加、ファイルシステムのアクセス許可など）に対するユーザーアクセスニーズの一元化されたユーザー管理とユーザーアクセス許可の管理ActiveDirectory内のメンバーシップ。
背景：開発、Webホスティング、データベースホスティング、PXEサービスなどに使用されるLinuxサーバーがいくつかあります。CentOSやUbuntuもあります。また、一元化されたActiveDirectory環境もあります。組織への参加時に、ユーザーが追加され、グループメンバーシップが提供されます。
例：ボブとアリスが組織に参加すると、AD内の適切なグループに追加され、1つ以上のLinuxサーバーでSSHまたはMySQLにアクセスできるようになります。ボブが去ると、ADグループから彼を削除し、SSH、MySQLなどのLinuxサーバーにアクセスできなくなります。
注：このようなタスクにどのようにアプローチしますか？このタイプの操作を可能にするLinux内で利用可能なユーティリティのセットはすでにありますか？ユーザーに付与する必要があるアクセスは、ユーザーがActive Directoryのメンバーであるユーザーグループメンバーシップに依存します。たとえば、AD開発グループ内の全員がSSHアクセス、MySQLアクセス、およびLinuxバージョン管理サーバー1と2のホームディレクトリを持っている必要があります。システム管理者のADグループ内の全員がSSHアクセスを持っている必要があります。すべてのLinuxサーバーなどに対するSUのアクセス許可。serverfaultに関する既存の記事をいくつか調べましたが、ここにリストされているニーズに一致するものは見つかりませんでした。
私が知っている2つの基本的なテクニックがあります-
方法1：Microsoftの NIXのID管理 -これにより、ActiveDirectoryをNISサーバーとして公開できます。
これは、ほとんどすべての* NIXフレーバーで機能し（すべてNISをサポートします）、NISのすべての利点（および欠点）を備えています。また、Microsoftによって正式にサポートされています。つまり、問題が発生した場合に電話をかける人がいます。
方法2：pam_ldap / nss_ldap （または同様の新しいシステム）。
これは、LDAPディレクトリに対して認証できる最新の* NIXフレーバーで機能し、最近ではUbuntuとCentOSにデフォルトで含まれている可能性があります。これは、Method OneのNISのようなハッカーよりも少し堅牢で最新のものですが、Microsoftによって公式にサポートされる可能性は低くなります。
これらの手法はどちらも、ADユーザーとグループをそれぞれPOSIXユーザーとグループに拡張して、* NIXシステムで使用可能なPOSIXUIDとGIDを使用できるようにする必要があります。MicrosoftはActiveDirectoryでこの機能を提供しています。
上記の方法2の追加の利点は、ユーザーをさらに拡張して OpenSSH LDAP Public Key パッチを使用できるようにすることです。これにより、SSHキーをLDAPに保存して、同期のタスクauthorized_keysネットワーク上のファイル。
私がここで読んでいることから、他のすべての典型的なLinuxのものを典型的なlinuxの方法で保存し、グループメンバーシップをADから取得したいですか？
あなたが見つけることができるほとんどの例は、AD/LDAP（おそらくすべてのユーザーに対してkerberos authとLDAP）からプルすることについて話しているでしょう、それはあなたが単にグループのもののためにLDAPが欲しいようです。私が間違っている場合は、PAMの作業も行う必要があります。
正確にどのバージョン（バージョン5と6の間でCentOS/RHELで変更されたか）に応じて、これには「nss_ldap」または「sssd」を使用できます。 sssdは新しいです。さまざまな方法で柔軟性があるように見えるため、どちらがより柔軟であるかを判断するのは困難です。 sssdは、特定のソースから取得するように特定の部分を構成することに関してより柔軟であるように見えますが、nss_ldapは、使用されているLDAPスキーマについてより柔軟であるように見えます。適切なパッケージをインストールする必要があります。 sssd-client、sssd-tools、sssd、libnss-sss、libnss-ldapまたはnss_ldap。 （認証のものはpam_ldapまたはsssdです）
ADのグループには一意の数値IDが必要です。基本的に、グループメンバーシップだけでなく、ADからLDAPを介してグループの定義全体をプルする必要があります（グループ定義全体は、基本的に名前、一意の数値ID、メンバーシップです）。 sssdを使用してこれを回避し、ファイル内のグループIDとLDAPからのグループメンバーシップを検索するように構成できる場合があります。本当に正しいことは、適切なUNIX拡張を使用してADスキーマを拡張し、RFC2307またはRFC2307bisのユーザー/グループデータを持つようにすることです。
/etc/nsswitch.confには、group: files ldapまたはgroup: files sssが必要です。 「ファイル」を最初ではなく2番目に配置することをお勧めします。
nss_ldap（nsswitch.confの「ldap」）は、/ etc/ldap.confを介して構成され、nss_ldapパッケージに記載されています。 uri、binddn、bindpw、nss_base_group、pam_member_attribute、nss_map_objectclass group、nss_map_attributeを設定する必要があります。
sssdは/etc/sssd/sssd.confを介して設定されます。 pamとauth_providerのものではなく、nssとid_providerのものに集中してください。 sssd.conf、sssd-ldap、およびsssdのマンページをお読みください。 「ドメイン」を構成し、基本的なid_providerおよびldap_uriタイプのものと一緒に「ldap_group」のものを構成する必要があります。
注：現在、OpenLDAP環境に対してnss_ldapとsssdの両方を実行しています。 AD環境でnss_ldap/pam_ldapを使用してから何年も経ちました。
また、Sambaで何ができるかを調べる価値があるかもしれません。これは通常、ファイル/印刷の共有に使用されますが、ログオン関連のものとドメインコントローラー関連のものを必要に応じて構成できる場合があります。
Likewise Open（またはPowerBroker Identity Services Open Editionと呼ばれるようになりました） をご覧ください。私は以前の仕事で同様にOpenを使用しており、Sambaと私たちの開発者とうまく連携しました。