The Case Of The IBM Systems Director And RBAC
February 26, 2014 Jeff Waldbillig
|
It was a dark night on a network that knew how to keep its secrets. Actually, that was last night. Today was going to be a busy day working on the network that knew how to keep its secrets. I’d been temporarily moved from my nightshift role at the help desk to the daylight hours to cover for a coworker who was out with an extended illness, but I was beginning to wonder if my late-night auction surfing had attracted some attention I did not need. My phone rang, and I paused for a moment as I considered that this might be the one. The case that would launch me from the doldrums at the help desk to the big time, dare I say it, perhaps even into development? The phone rang a second time, and I touched the connect button. “Chuck Temple, private ey. . . .” My manager, Marge Stetson, was stalking by my desk at that moment, and she threw a scowl at me that would make longshoremen with 30 years under their belts and a strong union behind them burst into tears. For her benefit, I decided to rephrase my opening. “Ahem. . . This is Chuck Temple at the help desk. How may I help you?” There was a long pause at the other end of the line, and as I waited for the voice that would announce my next case, Marge continued her procession down the hall. She gave me one backward glance before turning that glare on her next victim. I waited a moment longer to see if there was someone at the end of the phone line other than that faint hiss of static, then reached for the disconnect. At that moment, I heard him speak. I really couldn’t tell the kid’s age from his voice, but there was something in his pitch, something in the way his words tumbled out like autumn leaves from a maple tree in a stiff fall breeze, there was something there that made me believe that adulthood was still a pretty recent thing for him. “Yeah, this is David. I, um, I really don’t know if you can help me with this or not, but I figured I’d give you a try. You see, I’ve been using IBM Systems Director to manage the systems in our network for a few weeks now. And there’s these guys who need to sign-in to do stuff, but they keep trashing things, you know? They’re sticking their noses where they shouldn’t be, and they even restarted one of our boxes. They said it was just an accident, but I’m the one getting flack, you know? And with our fourth quarter security audits coming up, I don’t know how we’re going to pass, and. . . “ As David stopped to inhale, I interrupted. “Hold on a minute, David. Slow down.” The kid sounded out of breath and harried, as though he’d spent too many days managing the users of his systems instead of the systems themselves. I knew how he felt. I have been there myself on more than one occasion. “David, I know what you’re going through. And as it happens, IBM Systems Director has some pretty decent tools in place to help you control the access your users have to the Systems Director environment. You’ve heard of RBAC, right? That is, Role Based Access Control. It’s used by IBM Systems Director to control what actions users are authorized to perform, and against what resources.” There was another long pause, and I could tell David was putting two plus two together. “That sounds like just what I need!” I could tell I’d piqued his interest. Already I could sense his breathing was a bit easier. “You know, David, I have a couple of minutes. Do you want me to give you a little overview of how you can set up your environment to protect your users from themselves, as well as pass that security audit?” “You’d do that for me? Let me start Systems Director.” As David got things running, I continued speaking. “Any user on your server who needs to perform functions within Systems Director must be assigned a role that provides the authority or permission to perform those functions. Systems Director makes it easy for you to get started by creating a set of default roles you can begin with. The SMUser role provides authority to only the most basic functions within IBM Systems Director. The SMMonitor and SMManager roles each provide greater levels of authority, with the SMAdministrator role providing authority to all functions within Systems Director.” As I paused to let that sink in, David piped up. “Well, that’s it, then. When I’ve been creating my users, I’ve just been making them all SMAdministrator users. I’ll just switch ’em all to SMUsers, and my problems will be solved! Geez, thanks Chuck!” “Wait, David! Sure you can lock down everything to make sure your users aren’t able to get into trouble. But you’ve got to give them some permissions, or they won’t be able to do their jobs! For the greatest level of security, end-users should be authorized to an SM role that includes permission to the minimum set of Systems Director functions that most closely aligns with the activities the user needs to perform. Users can then be assigned custom roles for authority to other functions that the assigned base role might not cover. This is the basics of the Role Based Access Control.” “Hmmm. Just how do I know what permission those SM roles have? And those custom roles sound pretty cool, but how do I get one?” I could hear the wind being let out of David’s sails, like someone had just dangled a six terabyte portable hard drive in front of him, then yanked it away. “Now, don’t worry. It’s really pretty easy to see the permissions each SM role has. Just sign in to Director as an SMAdministrator, expand the Security section of the main navigation tree, and click on ‘Roles’. A new tab will open containing all the roles that are defined for Director, including those SM roles. If you click on the SMUser role, you can see all of the different permissions that SMUser provides. The permissions are grouped–as in permission groups–according to those with a similar focus. For example, if you expand the “Task Management” permission group, you can see all the permissions that are related to managing tasks that are available from the SMUser role.”
Click graphic to enlarge. “So there are a few steps to set things up if you have a user who only needs permission to the inventory related tasks for only a few of the systems in your network. That user doesn’t need all the permissions possible from the SMAdministrator role. If you start looking, you’ll see that the permission to view and collect inventory is first provided by the SMMonitor role. But what if even that role contains more authority than you want this particular user to have? In that case, you’d assign the SMUser role to the user, and then define a custom role that only gives permission to those inventory-related tasks you want the user to be able to perform. When you assign that custom role to the user, you also specify the specific groups of resources the user should be allowed to perform those tasks against. Make sense?” David was quiet for a moment, and I figured his wheels were turning, trying to process what I’d said. After a few moments, he finally said, “Ummmm. . . .” David was not, as we like to say in the business, verbose. “Would you like for me to walk you through the steps of doing this, David? It shouldn’t take more than five minutes.” “Yes,” he said, almost pleadingly. I could picture David nodding his head at the other end of the line. “Okay, it’s really just a couple of steps. First, let’s create that custom role using the Create Role Wizard. If you’re still listing all the existing roles that can be assigned to users, you’ll notice the “Create” button at the top of the list. Click on that button to launch the Create Role wizard. Give your role a name and a description that is appropriate for the functions the role is providing.” I could hear David clicking through the wizard. The kid was fast, alright. I’ll give him that. But there are times when fast will only get you so far. “David, David. Slow down. It’s on the next page. The permissions page, that’s the meat of the wizard. You’ll notice the list of permission groups. For example, Security, Release Management, or the one that we’re interested in, Inventory. You can expand those permission groups to see the individual permissions that make up that permission group. Notice there is fly-over help for the permissions if you’re unsure as to the nature of each one. So, expand Inventory permission group to see what permissions make up that permission group. You can pick and choose which permission you want to provide in this role, or just go ahead and select the entire permission group. After you’ve added the permissions you want your role to contain, click next and verify your selections. Finally, you can go ahead and click finish.”
Click graphic to enlarge. “Hey, I see the new role. That was easy enough. Now how do I assign that role to my user? I don’t want him messing around with the inventory for everything in the network!” I could tell that David was still pretty unsure about what we were doing. I’d gotten him this far, I wasn’t going to leave him hanging in the wind. “Not to worry, David. We’re just about there. First, you have to switch over to view your Systems Director users. Remember you had to expand Security in the main navigation tree to get to the Roles task? In that same Security section, you will also find the Users task. Click that to see all the users who are able to sign in to Systems Director.” I heard a few clicks, and David said, “Yep! There they are. I’m on the Users and Groups display, and I can see the profiles of those guys who are causing me all that trouble. They are listed there, and I can see they have SMAdministrator role! How can I fix that?”
Click graphic to enlarge. “We’ll work on the users one at a time. Just select the first user you want to change, and then click ‘Assign Role.’ The Assign Role wizard is displayed. This wizard allows you to add or remove the roles assigned to the user. On the ‘Assign Access’ page of the wizard, you define the specific groups of systems and the roles the user should have to those systems. In your case, you should first select the SMAdministrator role, and then click the remove button. The page should update to remove the role that is no longer needed.”
Click graphic to enlarge. Now you can assign the role your user really needs and apply that role to the group the user is working on. Click on the “Selected resource groups” radio button, and then select the group the user should have permission to. Next, click the User Role drop down, and find the new role you just created. Finally, click the Add button to add that role to the user for the resource group selected.
Click graphic to enlarge. It was time for me to wrap up. “Now click Next, and then Finish, and your user should now have just the permissions you have defined for him.”
Click graphic to enlarge. “Wow!” marveled David. “That was awesome! This is exactly what I needed to know! You have been so helpful! I really appreciate it!” I wasn’t really used to the adulation of my clients. Generally, I get an indifferent “Well, thanks” and then a dial tone. I was going to ask David to fill out a customer survey when he chimed in and said, “Well, thanks,” and hung up on me. You get used to that sort of thing where I work. Sometimes, at the end of the day, you just gotta hang on to those “Well, thanks” as the only markers you have as you plod along. And that’s where I was. Plodding along on a network that knew how to keep its secrets. Because I was Chuck Temple, private eye. Jeff Waldbillig is a staff software engineer at IBM’s Rochester, Minnesota, labs. He has held positions as a technical writer, host programmer, and has written client software for iSeries Navigator, IBM Systems Director, and IBM FSM Explorer. Send your questions or comments for Jeff to Ted Holt via the IT Jungle Contact page. RELATED STORY The Case Of The Late Night FSM Explorer
|
