IPAM – Part 2

So, what IS new in IPAM in Windows Server 2012 R2?

There is quite a long list here.

One of the big additions is that IPAM now supports RBAC – Role Based Access Control, this now enables you to customise access and operations permissions for users and groups of users with granular control of IPAM objects.

The second really big new feature, especially for a Virtualisation IT Pro is the ability to manage the Virtualisation Address Space. So in addition to your physical device IP address space IPAM now manages the IP space created and managed by System Center Virtual Machine Manager (SCVMM.)

Other cool new facilities include additional DHCP server management capabilities, IPAM also now supports a full SQL Server database rather than just the WID (Windows Internal Database).

The final two bonus items are that

  1.  When you upgrade a Windows Server 2012 IPAM deployment to Windows Server 2012 R2, all current data is migrated for you.
  2. PowerShell support is now greatly enhanced. Improving automation, extensibility and integration. (Regular Blogg(Ed) readers will know this excites me greatly as PowerShell is the future.)

First things first then, let’s assume I have an IPAM deployment as described in Part 1, and I have upgraded my infrastructure to Windows Server 2012 R2 and have deployed System Center 2012 R2 VMM. How do I take advantage of the new goodness?

I would recommend reading my fellow Microsoft Evangelist Simon May’s blog article on installation of IPAM HERE , there are some tricky GPO and other IPAM provisioning gotchas.

I am going to split the series into three with this post covering the RBAC, post 2 being the SCVMM integration and post 3 being the rest!

RBAC has been around for many years and most vendors are slowly integrating full granular control directly into their products.  The initial release of IPAM did have a cut down version limiting administrators and users access based on five different security groups (similar to roles).

  • IPAM Users: Members of this group can view all information in server discovery, IP address space, and server management. They can view IPAM and DHCP server operational events, but cannot view IP address tracking information.
  • IPAM MSM Administrators: IPAM multi-server management (MSM) administrators have IPAM Users privileges and can perform IPAM common management tasks and server management tasks.
  • IPAM ASM Administrators: IPAM address space management (ASM) administrators have IPAM Users privileges and can perform IPAM common management tasks and IP address space tasks.
  • IPAM IP Audit Administrators: Members of this group have IPAM Users privileges and can perform IPAM common management tasks and can view IP address tracking information.
  • IPAM Administrators: IPAM Administrators have the privileges to view all IPAM data and perform all IPAM tasks.

Now whilst this was a good idea to ensure some separation of responsibilities and duties, it was not granular enough to be described as proper RBAC.

RBAC requires three components to be fully functional.

Roles, Access scopes and Access Policies. These are described below

A Role is simply a collection of IPAM operations. A role can be associated with a user or a group (best practice is by group rather than individuals). This association is carried out suing an access policy. IPAM now provides 8 built in administrator roles but more can be created to cater for all your own requirements.

An Access Scope defines the objects that a user has access to. The default scope is Global, meaning that all objects in IPAM are covered. Any new scopes are subsets of this. An organisation may choose to assign scopes by geography or function. In the case of the Global scope, a user or group would have access to all objects that the assigned role allows.

Access Policies match up an Access Scope and a Role to assign a user or group the necessary permissions. As an example a user who has the Role of IP Block administrator and the scope of UK/Eire would have permissions to edit and delete IP Address blocks but only in the area under the scope of UK/Eire. That user would not be granted permission to edit IP Address blocks in the USA.

The table below shows the default roles and scope.

Type Name Description
Role DNS record administrator Manages DNS resource records
Role IP address record administrator Manages IP addresses but not IP address spaces, ranges, blocks, or subnets.
Role IPAM administrator Manages all settings and objects in IPAM
Role IPAM ASM administrator Completely manages IP addresses
Role IPAM DHCP administrator Completely manages DHCP servers
Role IPAM DHCP reservations administrator Manages DHCP reservations
Role IPAM DHCP scope administrator Manages DHCP scopes
Role IPAM MSM administrator Completely manages DHCP and DNS servers
Access scope Global By default, all objects in IPAM are included in the global access scope. All additional scopes that are configured are subsets of the global access scope.

Lets walk through a quick creation of a role, scope and policy.

Below is the IPAM client console with the new Access Control pane selected. You can see the Role, Access Scopes and Access Policies settings available for selection on the left hand side. Each section shows the roles / details so that all can be seen at a glance.

ip1

 

Below are shown smaller images (click for full size) of the Scope and Policies sections.

 

ip2ip3

 

 

 

 

 

 

 

 

 

 

 

 

By Right Clicking the role title, you can create a new role as shown below

ip4

 

 

 

 

 

 

 

 

 

 

 

 

 

 

It is a simple matter of selecting the IPAM operations you want the role to be able to perform. The next step is to right click the Access scope title and add a new scope. (This will automatically become a sub scope of the Global access scope)

ip5

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Having created the Role and the scope, the next step is to connect them within an Access policy, simply right click on the Access policies title and create a new policy

ip6

This dialog allows the user to select a policy name and then to match any of the roles to any of the scopes in the IPAM database. So one policy can control more than one role and one scope.

Don,t forget you still have access to the five local security groups on the IPAM server to control a user or administrators access to the console and its tasks.

In the next post I shall cover the newly added Virtualisation IP Address space features.

Meanwhile if you haven’t tried Windows Server 2012 R2 and IPAM, evaluate it now – HERE!

The post IPAM – Part 2 appeared first on Blogg(Ed).