The Care and Feeding of Herds

In order to understand herds, you first must understand roles. For this you need to understand a little bit about the PDB. The PDB contains demographic information about people associated with the university. There is a need to categorize this association at some basic level intrinsic to the PDB. This basic level of description is called  a ROLE. The current list of roles (which may change without warning by the whim of those running the PDB) is as follows:
 
 


A person may have many roles if you look in the database, but the only ones RATS recognizes are the ACTIVE roles. Active simply means that we have not reached the roles end date. Something that should be noted here is that unless you have requested the person's addition under one of the above roles through the add a person tool, you have no control over the end date of that role. Even with the tool, once the PDB gets a feed from the source that should be giving them the role you gave them with the tool, you lose control of that end date.

As you can see, the roles the PDB give you are fairly broad, and outside of your control. Although you can restrict them with other criteria explained in other RATS documentation, you still basically only get a reasonable amount of control over students. And when you start blurring the line between student, staff, and faculty, you can find yourself in a real pinch security wise if you only use roles. We won't even bother listing the ways the guest role could mess up your security. In order to fill this obvious need, we created herds.

Within the RATS software, herds  are just like roles. You put them in the same place, and they restrict the same way. The useful part is that you can get a herd created for your specific purposes. On top of that, you can add and remove people from the herd, and set their expiration date without worrying about what the university thinks their official status is. This lets you allow people to create their own accounts for a number of account types that this service was not previously available for. For example, if you have a group of student workers who are allowed access to a machine that is normally a staff only machine, you can just add them to a herd describing their employment role (an example would be NB_CCF_STUDENT). Now you only have to add them to a herd and setup an account type for that herd rather than create their account and get their password all straightened out with them. You can also set their expiration date in advance. You could even write a script around your RATS admin tools, and stick it in a cron job so that you can dump them from the system at a predetermined time in the future, and they would not be able to just recreate their accounts.

The brief example above illustrates how if you are creative you can use herds to make your life easier. However, if you are lazy, trying to be tricky with herds will make your maintenance and possibly security a nightmare. First, if you don't set herd expirations up front, and you make account types that require only a herd, you can leave the door open to nuisance users you want off your system. If you are not planning on implementing a maintenance process up front, please tie your herd roles to some real PDB role so that the users access criteria will expire without your input at some point. When talking about security, it is also important to realize that you should consider your herd choices carefully. Most of the time, if you need a herd, you are going to need a new herd of your own. If you do decide to share a herd, you are committing to security policies on user access (for account creation anyway) that is only as stringent as theirs. They are also committing to trusting you to not let everyone into their system. Although rats_support will not give you access to someone else's herds without their consent, this also illustrates how you should take care of who you give herd management access to.

Now that you have an idea about what herds are, we'll explain what you need to do to get a herd. You need to mail rats_support@email and tell us a few things. We need a herd name from you first of all. This is limited to 20 characters in length, and at least within RUCS, must start with NB_, NK_, or CM_ to indicate which campus the herd is for. This isn't necessary for those services which are not duplicated on multiple campuses, but is probably a good idea anyway. You will also need to give a description of what the herd represents. You may have chosen a different name for something that already exists. Although this probably won't occur much at first, we see this as a possible problem with turnover of headcount and sysadmin duties changing hands. So basically rats_support will do it's best to keep a list of herd meanings.  You also need to give us the usernames of all the people you want to manage the herd. If you want to avoid e-mail tag, you should probably include some alternate choices for the herd name.

Now lets give an example of how you could use some herds if you were creative. Lets say you have a machine that you have a few staff on, but is mostly to support job tasks for some student workers, but not all student workers, and has a handful of real staff on it to oversee the student workers. You can create an account type staff that has no web display, and create the small group of staff accounts by hand with the ratsadmin tool. Then you could request either one herd you assign to all those student workers, or multiple herds. Now, you pick NB_XX_SWRKR. XX here is a descriptor to make it a meaningful name. Perhaps when you get new hires, you put them in the group, but force an expire in two weeks to deal with new hires who flake out and don't show up. You also write a script to pull all the IIDs out of the password/shadow file on your system, and build a bulk herd management file after two weeks. Then you run this against the herd tool to set all the users who are good with an expiration date of the end of the year. However, you know you always get a number of students leaving mid year who graduate in winter. So in November, you whip up a list of those students, and set their expiration date to the end of the semester. You also know some of your students don't let you know when they are leaving, so you also require they have the role STUDENT. You write a script around the check tool from rats to push your list of users through the rats check to see if they are eligible for an account based on your account types (off hours of course). Now you have a list of usernames you can purge from your system because they are really not eligible for your system even though they may have a valid herd setting, they stopped being students. As you can see there are lots of ways RATS lets you help manage your userbase. If you happen to have a pretty cut and dry definition of a valid user, you can do a lot to automate the account maintenance process. If not you can at least generate meaningful lists a little easier.

Herds can be used to replace a lot of the hacks (system, code, policy and otherwise) that had been built up around the old makeacct system of doing things. Those of you who were using makeclass to allow lots of people to mangle your group file, can now probably relegate them to herds and get them out of important system files. Procedures that involved people doing all sorts of special things only they knew how to do can now probably be turned into a documentable process so that more than one person can do it safely.

I would also like to reiterate that hers can be dangerous as well. If you configure your RATS setup to do so, it will respect herds above all other roles. This means a person may have no more meaningful ties to the university and only remain in the PDB for historical purposes, but you can still put them in a herd. You can also make having this herd the only requirement for an account on your system. This is great for people who want to do this, but you are now completely in charge of making sure that herd contains an accurate list of people.

Basically, most people are going to use herds to allow guest account creation by requiring a GUEST/HERDNAME pair in the roles ALL array. Some other people may find herds much more useful though. Hopefully this document gives you an idea of where you can go with herds if you rethink your procedures and policies to work with them.