Standards Based Identity and Role Management using PowerShell
A year ago I published an article and PowerShell module to simplify managing Standards-Based devices (specifically CIM and WS-Man). The use cases focused around setting the boot order, changing power state, and getting software (firmware) and hardware inventory information. The module should work against any SMASH or DASH capable hardware that implements the specific Management Profiles used by the module.
DASH (Desktop and Mobile Architecture for System Hardware) specifically has a set of implementation requirements which include management of identities and roles.
The Simple Identity Management Profile (SIMP) allow you to do things such as creating accounts, removing accounts, and updating accounts. The Role Based Authorization Profile (RBAP) is used with SIMP to assign roles (you can think of it loosely as a collection of privileges) to an account. Both of these profiles are complex due to the breadth of capabilities being modeled and flexibility for implementations to be conformant. I’ve updated the Hardware Management module to enable use of some of the top use-cases while removing the complexities of understanding the profiles.
Here I show that I’ve imported the module and have already created CimSession instances to three hardware devices. The first one named BRCM is a HP desktop system that uses Broadcom’s TruManage DASH implementation. The second one is a desktop system using Intel’s vPro (aka AMT) implementation of DASH. The third one is a Dell PowerEdge server rack using Dell’s iDrac7 implementation of SMASH. I save all three sessions to a single $systems variable and get the power-state of all three systems. One thing you may notice is that not each system implements different parts of the same standard Profiles where certain properties and/or methods are optional or conditional. Specifically, you can see that two of the systems don’t return AvailablePowerStates information. So far, I haven’t done anything that uses the new SIMP and RBAP cmdlets. One thing you may notice if you used the previous version of the module is the CIM prefix added to the cmdlets based on feedback from the PowerShell team.
Here I’m enumerating the accounts that exist on the Broadcom TruManage and Intel vPro systems. I’m leaving out the Dell iDrac system only because there are lots of test accounts created on it. I already have an account named Steve on the Intel system, so let’s create one on the Broadcom system.
Account was created, but it’s not associated to any role (nor privileges) and is currently in an offline state.
First, let’s assign a role to the new account. I’ll enumerate all the roles supported by the TruManage system. One thing to note is that the current version of the RBAP doesn’t define a common way to modeling the administrator role. This means that unfortunately today, you’ll have to have specific knowledge about a particular implementation since you can’t simply query for the administrator role. On this particular system, I can see that it’s the first role in my array, so I use the Set-CIMRole to make my new Steve account an administrator.
After we enable the account, we can start using it. Here I create a new CIMSession instance using the newly created account and retrieve some software (firmware) inventory information on that system.
The updated module is available at the same TechNet location.
Principal Test Manager
Windows Server Standards Based Management