-
Notifications
You must be signed in to change notification settings - Fork 3
Attributes in LDAP
Return to main: Kerberos
Our LDAP setup is mostly standard. However we have to keep track of multiple clusters. I'm using the "host" attribute to do that.
Users:
user is a member of the group login-ilab -- user can login to the ilab cluster
Groups
host = ilab - users in this group are authorized to activate in ilab, but also requires businesscategory=login to be set businesscategory = login - group used to authorize users
If a user tries to activate in cluster ilab, the activator looks at all groups with businesscategory=login and host=ilab. If the user is in any of those groups, it adds them to login-ilab. Login-ilab itself shouldn't have businesscategory and host set, or we'll never remove anyone.
Note that the actual group file presented by Linux will show only groups with GID's. Many of our groups are used to keep track of people to document that they are authorized to use a cluster. Most of those groups don't have GIDs and so are invisible to normal LInux group commands.
ipausers is special. All users are a member of it. We don't want Linux to see this group, or it will cause performance problems. So it doesn't have a gid. (For current versions of IPA this is the default. If ipausers has a GID in your installation, kill the GID.)
Our default groups is 1234. It has an IPA group entry with no members. But because all users are created with GID 1234, they'll in it even though they aren't in the list of members.
You must create a group login-NN for each cluster. I'm using GID's starting with 3000. It must not have host=NN or businesscategory=login or we'll never be able to get rid of any users.
You must also create a group disabled-NN for each cluster, same GID range. This is for users who are administratively disabled. We could just remove them from login-NN, but the activator script would put them back.