federalcto.com The Blog of a Federal CTO

Token Bloat, AD Bridge and Quest Privilege Manager

If you don't know what "token bloat" is, then I suggest you do some research.  Plenty has been written on it, and while I'll provide a brief description, others do a much better job of covering it.  The short version is that when you log in using your Active Directory credentials you get a Kerberos ticket (which is just your identity - who you are) plus a PAC (Privileged Attribute Certificate - which is a list of all your security group memberships (their UUIDs, actually) - what rights you have).  As a user gets more and more rights (through group membership), the PAC grows.  Eventually, it becomes big enough to affect logins and applications that use the AD Kerberos ticket (often called a token).  The effect is that things slow down, or just flat out break.

But how does this affect AD Bridge products, like Quest Authentication Services?  Unfortunately, in much the same way.  If you're a member of 10,000 security groups, it's going to take some amount of time to get through that list.  That doesn't change just because you've logged into a Unix, Linux or Mac machine.  At best, you can set a flag to ignore the PAC if all you want is authentication, but if you are a member of 10,000 groups, someone probably put you in those groups for a reason (note: 10,000 is hyperbole, and if you really are a member of 10,000 groups, you have some serious AD design problems).

And an increase in the number of groups is often a by-product of deploying an AD bridge solution.  We have other ways to alias out and re-use existing groups, and you can certainly use local groups, which are not in the PAC, but who wants that?  In some cases, you want those added groups.  You need those added groups.  A unix sysadmin is not the same as a Windows administrator.  And an Oracle DBA often has different rights, and requires different groups from your SQL Server admins, so simply generalizing your groups aren't enough, either.

But for customers that have QAS along with Quest Privilege Manager for Unix, there's a better way.  And one that provides a lot more flexibility and configuration options. Plus, you don't have to have QAS.  You can do this with local accounts, LDAP, NIS, and any other users you have on unix. I'll just stick with AD users because the topic of this post does focus on 'token bloat' which is an AD-specific problem.

What is Quest Privilege Manager (QPM4U)?  It is a tool for unix command control, and I/O logging.  There are lots of other descriptions people use - "Tivo for your unix machines," or "sudo on steroids" are often used, though most fall short in a 1 sentence pitch.  QPM4U allows very granular control over what rights users have on a particular machine, and that granularity includes options such as time of day, and day of week, environment variables, and multiple group memberships. In fact, it can use any variable/attribute about the user, the machine and environment.

And the last item I listed (multiple group memberships) is where things get interesting.  You actually write a rule that says, "if a user is a member of OhioUsers, and a member of SalesTeam, then the user can access files in the /SalesDocs/Ohio folder."  This is interesting, because in the Windows world, most people would be added to the SalesTeam group, and the OhioUsers group, and then a third group would get created called 'OhioSalesTeam' just to grant access to a similar folder.  And even with sudo, the same thing would happen.  Sudo can only check for 1 group membership, and you're either in the group, or not.

This is where QPM4U can let you use existing groups, and perhaps other attributes, to determine whether users can access resources or run certain commands.  In fact, you could simply query AD (check out the 'vastool search' command), find out the user's job title (Account Manager), their state (Ohio) and make the determination that way.  Which means that no groups are needed.  This is an extreme example, and not one I'd recommend, but hopefully you see how it could help prevent token bloat.  In addition, you can start adding in other conditions, such as time of day (if the user is a DBA, and it's after 7 PM, then they can run the 'backup database' command), allowing for even more flexibility, and control.

Now, I've been writing all this using pseudo code, and not showing you how simple this config would actually be to put in place.  So what would be needed in the Privilege Manager config file for that initial scenario? Well, thanks to my colleague, Paul Harper, it would look something like:

# check all the arguements to see if the filepath is the one allowed
c = 0;
protected_dir = '/SalesDocs/Ohio/';
prot_dir_len = strlen(protected_dir);

while (c < argc) { 
   if ( (strlen(argv[c]) >= prot_dir_len ) && ( strsub(argv[c], 0, prot_dir_len) == protected_dir )) {
      if (ingroup(user, "SalesTeam")) && (ingroup(user, “OhioUsers”)) {
        accept;
      }
      else {
        reject;
      }
  c = c + 1;
  # do other things here for other conditions.
  }
To be fair, this is a poorly written script, and it has many faults, but it gives you an idea of the types of things that could be done with Privilege Manager, especially when it comes to multiple groups, and the fact that you can check for multiple group memberships, without having to create a brand new group just to manage access to a resource where other conditions already exist to check this.
There you go, Jeff. Hopefully this post helps you - give me a call if you've read this far down.  🙂


Tagged as: active directory, AD Bridge, Privilege Manager, QAS, Token Bloat, VAS
No Comments