Not using Cisco Intersight to manage Cisco UCS servers and storage yet?  Great. I’ve got some tips you’ll want to read before you start.  And if you are simply monitoring your devices and not configured any yet, you are also in luck. It’s not too late.

UhOh?  You’ve already dived into Intersight Managed Mode (IMM) and found you have 200 Policies and Intersight and User management is just not doing what you expect? Keep reading, there are some things you can do get get your existing install back on track. And I’ll show you how to move forward in the future.

---

TL;DR – User defined Roles are the key to getting Intersight to work nicely

When you add a User to your Intersight account, you assign them to a Role. That Role may be a System defined Role, and have visibility of to ALL your devices, or a Role you have created that has just visibility of  a limited set of your devices (or all of your devices, depending how you set up that Role)

And there is the beginning of the problem.  You can’t set up users to have a limited view of your devices without first setting up some User defined Roles

And you can’t create very meaningful Roles until you’ve set up a least one Organization

---

Let’s Organize a Rock and Role Party

If my horrible pun hasn’t turned you off, I’ll show you in the rest of this article:

• how to set up Organizations to enable separate management views
• how to create Resource Groups and why its a good idea to create these BEFORE claiming devices
• what the most important Privileges are to assign to a User Defined Role
• why it is important to create User Defined Roles  before adding users
• how users can be assigned different Roles for different purposes
• some limitations (lack of foresight?) in the RBAC system, and how to get around at least one of them.

---

Start at looking how Organizations fit into the picture. And to do that, you’ll need to also look at Resource Groups

The story goes a little like this:

• As a device (a Target) is claimed in Intersight, it is assigned to one or more Resource Groups (1)
  • That Resource Group can be allocated to one or more Organizations
• As a User is added to Intersight, that User must be assigned to one or more Roles
  • User defined Roles (2) can be linked to one or more Organizations. (3)
• It is the intersection of the Users/Roles with Resource Groups via the Organizations that gives you very fine control of who can do what in Intersight

Notes:

1. Target devices not assigned to a Resource Group end up in the system default All Resource Group.  There is also a system defined default Resource Group.
2. User defined Roles are created by allocating a collection of Privileges for an Organization. Multiple Organizations can be configured this way within a single Role
3. More precisely, User defined Roles can be linked to one or more Organizations OR given a global scope. But System Defined Roles always have a global scope.

Note: The distinction between user defined Roles and system defined Roles is important. In short, don’t waste your time with system defined roles apart from the Account Administrator role that at least one user must have.

In practice, this means the following:

• It makes sense to start by creating a Resource Group to group pieces of equipment together that you want to be managed by a group of users. If you want, you can split your equipment into multiple Resource Groups to give you finer granularity of control later. But don’t get too carried away – you really don’t want the spider’s web I’ve drawn above.
  • RedNectar‘s recommendation. Start with ONE Resource Group for a particular set of equipment – your new UCSX chassis or HX Cluster for instance.
• Next, create an Organization and link it to the Resource Group you just created.  If you created more than one Resource Group, create the same number of Organizations.
  •  RedNectar‘s recommendation. Keep things simple by linking each Organization to one Resource Group.  The system is very flexible, and you can add extra links later on once you understand the web!

Note: Organizations were designed, as Cisco puts it, “to enables multi-tenancy through separation of resources”.  But the thing that makes Organizations even more useful is that the same piece of equipment can be assigned to multiple Resource Groups and each Resource Group can be linked to multiple Organizations.  A user too can be linked to multiple Organizations if user defined Roles are used.

• Now that you have an Organization ready, it’s time to create one of those User Defined Roles
  • When you create you first User Defined Role, you’ll be greeted with a bewildering array of Privileges that can be assigned to the Role.
  • RedNectar‘s recommendation. As before, create one (administrator) role for each Resource Group, such as HX.Admin_Role or UCSX.Admin_Role.  I’ll explain more later, but for now, assign Server Administrator and UCS Domain Administrator privileges for now.  Add Device Administrator privileges as well if users assigned to this role have to claim devices in Intersight.

Tip: When you create your own roles, make sure you add something distinctive to the name of the Role (I always end the name in _Role). That way when you are presented with a huge list of Roles you can assign to a User, you’ll be able to distinguish your user defined _Roles from the system defined Roles.

• To complete the picture, you’ll need to assign a user to that Role – which you can do by adding a new user or editing an existing user.
  • RedNectar‘s recommendation. To test your new user defined Role, edit your own User settings and add the Role to your list of Roles. Now open a private/incognito window and login to intersight.com again.  As you log in, you’ll be presented with a list of all the roles that have been assigned to you. Choose the Role you just created and see if it has the Privileges you’d hoped for.

An example:

I have a two pairs of Fabric Interconnects – one pair provides connectivity for a UCS-X Chassis with 4 servers and the other for a HyperFlex Cluster (of 3 servers). For this discussion, we don’t care about the Ethernet or Fibre Channel connectivity north of the Fabric Interconnects.

RANT: I had planned to configure both the HX & the UCS-X to a single pair of Fabric Interconnects, but (after ONLY 6 YEARS) Cisco still haven’t figured out how to make an Intersight Managed Mode UCS Domain find HyperFlex nodes.

My requirement is to give access to the UCS-X series Servers and its UCS Domain to one user, and access to the HX Cluster, its servers and Fabric Interconnects to another user.

The UCS-X user should NOT be able to see the HX  Cluster and the HX user should NOT be able to see the UCS-X chassis or servers.

Let’s see if we can set this up using Resource Groups and Organizations.

Here’s my first attempt:  I’ve called my users HX.User and UCSX.User.

Here is how I’ve configured the UCSX.User‘s access to resources:

This user has Server Administrator and UCS Domain Administrator Privileges to the UCSX Organization, which is connected to the UCSX Resource Group to which the UCS-X Chassis (and therein the servers in that Chassis).

The point I wanted to make is that this user sees the UCS-X Servers, but can’t see the HyperFlex Servers. So let’s compare that to the HyperFlex admin User.

Here is how I’ve configured the HX.User‘s access to resources:

This user has the HyperFlex Cluster Administrator Privilege as well as the Server Administrator and UCS Domain Administrator Privileges  to the HX Organization, which is connected to the HyperFlex Resource Group. This is what the HX.User sees in Intersight.

Side Note: Although the UCSM managed HyperFlex Fabric Interconnects are not seen in Intersight as a UCS Domain, the HX.User required UCS Domain Administrator rights to be able to perform a FI upgrade from Intersight.

Here you can see that the HX.User sees only 3 Servers – this time it’s the HX Servers.

Pretty neat huh?

Side Note: I could have configured just one user and assigned that user two different Roles.  That user would then need to choose which Role s/he wished to use when logging in.  In fact, that’s how I managed to do the screendumps from Intersight – the user in each case was actually me but assigned to either the UCSX.Admin_Role or the HX.Admin_Role.

All sorted then? No. Not yet

You see I haven’t mentioned anything about configuring these devices.  And to do that, you’ll need to know about Policies along with Pools, Profiles and Templates as well. So let’s add these to the picture:

Now this is where things get a bit tricky, because each configurable item can be linked with only ONE Organization. Or to put it another way, every Organization has its own collection of Profiles, Pools, Policies and Templates

So if you have defined say an SNMP Policy for one Organization, you can only use it with equipment that is linked to that Organization via its Resource Group(s).

Given that there can be dozens or even hundreds of these Pools, Polices, Profiles and Templates (especially Policies), having a restricted view is actually a good idea – it makes your view of the equipment you want to work with much cleaner.

But it also makes it much harder to share Pools, Polices, Profiles and Templates between Organizations – there is a solution (perhaps kludge is a better word)  for that that I’ll get to later.

Time for a recap

• There are System-defined Roles and User-defined Roles
• Only User-defined Roles can be linked to Organizations, giving you the granularity of linking Users to Organizations
  • Which in turn connect the Users to
    • Resource Groups (where the equipment lives), and
    • The configurable items (Pools, Polices, Profiles and Templates)
• Life will be simpler if:
  • you stick to a new Organization and a new Resource Group for each batch of equipment you have
  • you create at least one User-defined Role for each Organization
  • you only ever assign users to User-defined Roles – lots of different Roles if you want, each linked to an Organization that is linked to a Rescource Group.  That way as a User logs in, they can choose which Role to use to access the equipment they want without too many distractions.

So the key to getting Intersight to work nicely is to use those User Defined Roles to your advantage. From a personal point of view, I’ve assigned myself several roles, and generally only use the system defined account administrator role when adding users.  For normal operations, I find it much cleaner to log in using my UCSX.Admin_Role if I’m working with UCSX, and my HX.Admin_Role if I’m working with HyperFlex.

So instead of the Cat’s Cradle diagram I’ve drawn above, the following is a much more manageable approach, with a user choosing which set of devices they will manage as they log in.  In the diagram below, the user will be presented with a choice of three Roles. Depending which Role is chosen, they will be able to see just the UCSX, UCS or HX equipment.

Drawbacks

Get ready. There’s a few of them!

Policy Isolation

Because each Pool, Policy, Profile or Template is liked to an Organization, these objects can’t be shared between Organizations.  They can’t even be cloned or copied from one Organization to another.  So if you’ve created a policy and put it in the default organization (which happens by default if you have access to the default organization) then later on decide you want to move it, or apply it to a device that’s in a resource pool not linked to the default organization you are stuck.

Now from the point of view of tenant isolation, this is a good thing.  But if you are used to the old UCSM idea of the root Organization or Cisco ACI’s common Tenant – you’ll be familiar with the idea of having a “catch-all” grouping that provides a set of common/default policies that can be used by any sub-organization (in UCSM) or any tenant (in Cisco ACI).

The closest analogy for Intersight is the default Organization, but in practice that usually becomes a “everything goes here” rather than a “catch all”.

But the good new is that you could design your own common organization to hold policies that could be used across multiple  Resource Groups.  This actually gets complicated, and I may tackle that in another post.

Inconsistencies

Why should I be NOT surprised that Cisco has built in numerous inconsistencies in this system.  The one that irks me most is DNS.

There is a Policy called DNS, NTP and Timezone, where I can define these items.

BUT THEY CAN ONLY EVER BE APPLIED TO HyperFlex CLUSTERS!

I can’t apply a DNS, NTP and Timezone Policy to a UCS Server or UCS Domain.  To add DNS configuration to a UCS Server, I need to create a Network Connectivity Policy, [please sack the person who came up with that name] and then an additional NTP Policy for NTP and Timezone configuration.

And similarly, I have already created Network Connectivity Policy and an NTP Policy, I can’t apply them to a HyperFlex Cluster!

Incomplete Parity

Not everything you could do in UCS Manager can be done in Intersight!

I won’t list them all, in fact I don’t know them all, but I know that for a server, the only statistics you can garner from Intersight is Power (status – on/off ).  But using UCS Manager, I can can statistics for Power & Temperature – not just for the server itself, but even down to the component level. Take a look at the difference between the Statistic view in UCS Manager (top) vs Intersight (bottom) for the same server!

On the other hand, there are some tings that can be done in Intersight that can’t be done in UCS Manager, such as the Hardware Compatibility List and the connected TAC.

Wrap Up

The key take-away from this article is that User defined Roles are the key to getting Intersight to work nicely.

The trap most people fall into is using System defined Roles when they add a user, because, well you didn’t know you should have created some User defined Roles to begin with. And to make your User defined Role useful, you’ll need to have created an Organization and a Resource Group already. No wonder users give up before negotiating the maze.

My recommendation is to start by creating a Resource Group to group pieces of equipment together that you want to be managed by a group of users.

Next, create an Organization and link it to the Resource Group you just created.

You are now ready to claim your first target for that Resource Group you created – BUT BE CAREFUL – you need to make sure you associate it with that Resource Group during the claim process.  If you forget, you’ll have to unclaim the device and claim it again.

If you didn’t do things like this on day 1 – don’t worry. Go and create your Resource Group now, then unclaim the devices you’d like to have in that resource group, and claim them again, this time making sure you link them to the Resource Group.

Now you can create a User Defined Role that will be used to allow users to manage this equipment.  Give the role Server Administrator and UCS Domain Administrator privileges for now.  Add Device Administrator privileges as well if users assigned to this role have to claim devices in Intersight. Make the name of the role relate to the equipment, and end in the suffix _Role

And finally, you can add the users that will manage this device.  The first user you should add is yourself, which you can easily do by editing the user and adding a new role.  Next time you log in, you’ll need to select whether you use the Account Administrator role, or the User Defined Role you created.  Note how my naming convention makes it easy to pick the User Defined Roles from the System Defined Role in the list below.

And once again, if you didn’t do this at the start, it is quite easy to add new Roles for users. I suspect that (like me) you’ll soon get used to NOT using the Account Administrator role all the time, and use the role that is most appropriate to do the job at hand. And it is super easy to switch from one role to another for a short time if you wish.

Good luck with your Intersight adventures. Hopefully this has made managing your Intersight resources and users a little easier to manage.

RedNectar