私は現在、Linuxユーザーをposixaccountおよびposixgroup要素として次のように管理するOpenLDAPサーバーを実行しています。
dn: cn=shellinger,ou=groups,dc=company,dc=com
cn: shellinger
gidNumber: 5001
objectClass: posixGroup
objectClass: top
dn: cn=shellinger,ou=people,dc=company,dc=com
cn: Simon Hellinger
uid: shellinger
uidNumber: 5001
gidNumber: 5001
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: posixAccount
objectClass: shadowAccount
objectClass: top
...
現在、プライマリグループを除いて、Linuxグループのメンバーシップは各マシンでローカルに管理されています。これは機能しますが、一元化されたユーザー管理の目的に反すると思います。
私が考える私が欲しいのは、ユーザーがログオンするマシンに応じて、ユーザーに異なるグループのセットを割り当てることです。通常、私のユーザーはすべてのマシンで便利なビジネスを行っているため、ログイン制限(ホストまたは特定のグループに基づく)は、私のユースケースには粗すぎると思います。ログインできるかどうかではなく、各マシンで実行できることを制限したいと思います。私の考え方では、それは彼らがどのLinuxグループに属しているかを意味します。
また、これらのグループ(およびそのためのアクセス許可)は、各マシンのユーザーごとに大きく異なる可能性があり、あるマシンでスーパーユーザーのアクセス許可を持つユーザーは、次のマシンでは通常のユーザーになることができます。
私の素人の言葉では、これは役割ベースのグループ割り当てのように聞こえますが、LDAPボキャブラリー全体をGoogleとserverfaultに投げ込んだ後でも、これを回避できないようです。
要約すると、質問は次のとおりです。私のユースケースは有効ですか?私はこれを正しい方法で行っていますか? LDAPでLinuxグループを管理する必要がありますか?
一般に、グループメンバーシップは、ユーザーと同様に一元的に管理する必要があります。
ただし、スーパーユーザーのアクセス許可が必要なユーザーについて話すと、各マシンでwheel
のsu
を個別に管理しているように思われます。これは許容範囲ですが、特に複数のサーバーがすべて同じように動作する必要がある場合は、少し面倒です。
pam_wheel
で使用されるグループを変更するか、複数のpam_wheelエントリを含めることができます(/etc/pam.d/su
で毎回異なるオプションを使用しますが、Sudo
を使用して、それをLDAPと統合することをお勧めします。 Sudoはサーバーごとにきめ細かい制御を提供し、LDAPはそれを適切に配布します。
一部のディストリビューションでは、SudoとSudo-ldapが分離されています。