Authority delegation in Cloud Network Automation is the ability to assign full and exclusive control of IP addresses and DNS name spaces to a Cloud Platform Appliance. You can perform authority delegation only through the Grid Master. When you delegate the authority of IP addresses and DNS name spaces to a Cloud Platform Appliance, the Grid Master loses its authority over the scope of delegation for these IP addresses and name spaces as well as any objects within them. Note that authority delegation for an object can be explicitly assigned or inherited from parent objects. For information about how to delegate authority for supported object types, see 21744878 21744878.
NIOS admin users who do not belong to admin groups with cloud API access are not allowed to create new cloud objects, nor can they modify or delete existing cloud objects in delegated spaces; but they can modify the permissions and certain extensible attribute values for these objects. Only admin users with cloud API access and the correct global and object permissions can be used to send cloud API requests to create, modify, and delete objects within the delegated scope.

Note: You can delegate authority only to Cloud Platform Appliances, but not to other Grid members.

Objects that are in queue for scheduled executions or approvals are locked and cannot be delegated. Authority delegation and reclaiming of authority are subject to approval and can be scheduled.

Guidelines for Delegating Authority

You can initiate explicit delegation of authority only through Grid Manager on the Grid Master. The cloud API service can only be used for implicit or automatic delegation of an object such as creating a network under a network container that has been delegated, in which network is implicitly delegated to the member to which the network container is delegated.
The Grid Master can explicitly delegate authority only for the following object types:

Network View
Network Container (both IPv4 and IPv6)
Network (both IPv4 and IPv6)
DHCP Range (IPv4 and IPv6)
DNS Authoritative Zone (Note that zones are implicitly delegated if the assigned name server is a Cloud Platform Appliance.)

Consider the following when you delegate authority for an object:

You can delegate authority for supported objects to one and only one Cloud Platform Appliance, except for DNS zones.
When delegating authority for a parent object, all child objects within the scope of delegation inherit the same authority delegation.
You cannot delegate authority for the following:
- objects whose parents already have a delegation configured
- individual IPAM and DNS records including fixed addresses, host records, A/AAAA/PTR records, etc.
When you use Elastic Scaling to pre-provision an offline Cloud Platform Appliance, any object authority delegated to this offline member does not take effect until the member joins the Grid. Therefore, you can still create child objects through Grid Manager under the delegated objects when the member is offline.
You can override the inheritance of authority delegation at the object level only if the parent object has not been delegated. The Grid Master assumes authority for objects that do not fall within the scope of delegation.
If a supported object has already been delegated, you cannot re-delegate it to another appliance. If you want to re-delegate this object, you must first un-delegate it.
For explicitly delegated objects, you can only modify the permission and extensible attributes from Grid Manager and the Infoblox API other than cloud API requests. For explicitly delegated zones however, you can modify any properties from Grid Manager and the Infoblox API other than cloud API requests.
When you create or delete a delegated object through a cloud API request, the appliance returns an OK message if the operation is successful. It returns an ERROR message if the operation fails. You can then change the options in the request and try again. The appliance sends a WARNING message when certain operations require attention.
You can reclaim the authority that you delegated to a Cloud Platform Appliance. Once the authority is reclaimed, it goes back to the Grid Master. Before you reclaim authority for any object, ensure that the Cloud Platform Appliance is online and properly connected to the Grid Master for the reclaiming process to function properly.
The Cloud Platform Appliance can run discovery on any network containers or networks that are reachable by the appliance. The default discovery settings for network containers and networks are inherited from their parent objects. For information about discovery, see About Discovery.

Note: Any Cloud Platform Appliances that are removed from the Grid automatically lose authority over objects that were delegated to them. The Grid Master becomes authoritative for these objects.

Delegating Authority for Cloud Objects

You can delegate authority when you create a new object that has not been delegated or does not inherit authority delegation from one of its parent object.
See the following sections for detailed information about delegating authority for supported objects.

Network Views

Consider the authority delegation guidelines in 21744878 when you create, modify, or delete a network view. See Sample Cloud API Requests for a sample cloud API request.
For information about how to create network views from the Grid Master, see Adding Network Views.

Table 7.4 Authority Delegation for Network Views

Cloud API Requests	Standard API and WAPI Requests	Comments
You can delegate authority for a network view to only one Cloud Platform Appliance. When you create a new network view, authority is automatically delegated to the Cloud Platform Appliance that processes the request. To balance network views among multiple Cloud Platform Appliances in the Grid, ensure that you configure your cloud adapter accordingly. If you want to share a network view among different Cloud Platform members, you must manually provision it and its child objects and delegate them to the respective Cloud Platform members.	You can delete a network view from the Grid Master only if it has not been delegated to any Cloud Platform Appliance. When you create a network view on the Grid Master, it is shared among all Grid members in the Grid. You can delegate a network view from the Grid Master to a Cloud Platform Appliance only if the child objects within the network view are delegated to the same Cloud Platform Appliance. When you reclaim authority for a network view, any DNS zones in the network view remain assigned to their name servers, including the Cloud Platform Appliance that has lost authority over the network view. In other words, the DNS zone remains under the authority of that Cloud Platform Appliance.	When you create a network view through a cloud API request, you must include the following extensible attributes in the cloud API request: Tenant ID, Cloud API Owned, and CMP Type.

IPv4 and IPv6 Networks and Network Containers

Consider the authority delegation guidelines in 21744878 when you create, modify, or delete a network or network container. See Sample Cloud API Requests for a sample cloud API request. For information about how to create IPv4 and IPv6 networks from the Grid Master, see Adding IPv4 Networks and Adding IPv6Networks.
For information about how to create IPv4 and IPv6 networks using network templates from the Grid Master, see
Adding IPv4 Network Templates and Adding IPv6 Network Templates.

Table7.5 Authority Delegation for Networks and Network Containers

Cloud API Requests	Standard API and WAPI Requests	Comments
You can delegate authority for a network or network container to only one Cloud Platform Appliance, but you can delegate authority of multiple networks and network containers to the same Cloud Platform Appliance. When you create a new network or network container through a cloud API request, authority is automatically delegated to the primary Cloud Platform Appliance that processes the request. When you create a network using a network template, you must provide the name of the template and reference it in the cloud API request. Delegation for a network or network container (except for unmanaged networks) can be done through explicit delegation or inheritance from the parent object. You cannot delete networks and network containers using cloud API requests if they have already been explicitly delegated. You must first un-delegate them before deleting them. Networks and network containers associated with a DNS zone cannot be delegated. You can delegate a network or network container if all the following are true: It has not been delegated to a Cloud Platform Appliance. It is not part of a network or network container that has been delegated to a Cloud Platform Appliance. It does not contain any networks or DHCP ranges that are delegated to a different Cloud Platform Appliance. It does not belong to a delegated network view. All discovery related attributes for a network or network container return the default values. You cannot modify the discovery settings for networks that are in a delegated network container. You cannot create discovered networks in a network container whose authority has been delegated. You also cannot convert unmanaged networks. A discovered unmanaged IP address may co-exist with an IP address created through a cloud API request. Although no DHCP service restart is required, you can perform a DHCP service restart on a Cloud Platform Appliance through a cloud API request.	You cannot create, modify, or delete a network or network container on the Grid Master if the object has been delegated to a Cloud Platform Appliance. You can create a network or network container and delegate it to a Cloud Platform Appliance using a network template. You can delegate a network or network container to a Cloud Platform Appliance only if the child objects within the network or network container are delegated to the same Cloud Platform Appliance. You cannot perform a recursive deletion of a network container if one of the child objects in the container has been delegated. DHCP utilization usage for a network or network container is only updated on the Grid Master. Discovered IP addresses that are within a delegated network are created on the Grid Master and replicated to the Cloud Platform Appliance that is relevant to the IP addresses.	When you create a network or network container through a cloud API request, you must include the following extensible attributes in the request: Tenant ID, Cloud API Owned, and CMP Type. If a network is explicitly delegated (not through inheritance), you can convert a network to a network container only if the size of the network remains the same; the network delegation is transferred to the network container. The Cloud Platform Appliance does not support split network, john networks, and RIR related operations.

DHCP Ranges

Consider the authority delegation guidelines in 21744878 when you create, modify, or delete a DHCP range. See Sample Cloud API Requests for a sample cloud API request.
For information about how to create IPv4 and IPv6 ranges, see Adding IPv4 Address Ranges and Modifying IPv6 Address Ranges.
For information about how to create IPv4 and IPv6 ranges using range templates, see Adding IPv4 Range Templates and Adding IPv6 Range Templates.

Table7.6 Authority Delegation for DHCP Ranges

Cloud API Requests

Standard API and WAPI Requests

Comments

You can delegate authority for a DHCP range to only one Cloud Platform Appliance, but you can delegate authority for multiple DHCP ranges to the same Cloud Platform Appliance.
When you create a new DHCP range, authority is automatically delegated to the Cloud Platform Appliance that processes the request or to the Grid Master if the Grid Master processes the request.
When you create a DHCP range using a range template, you must know the name of the template and reference it in the cloud API request.
You can delegate authority for reserved ranges in a Microsoft synchronized network if:
- It is not included in any exclusions.
- It does not conflict with another reserved range.
You can manage these range addresses through a cloud adapter, such as the IPAM Plug-In for VMware.
Delegation for a DHCP range can be done through explicit delegation or inheritance from the parent object. You cannot override inherited delegation.
Note that you cannot delete DHCP ranges using cloud API requests if they have already been explicitly delegated. You must first un-delegate them before deleting them. However, if the delegation is inherited, you can delete the objects through a cloud API request.
You can delegate a DHCP range to a Cloud Platform Appliance if all the following are true:
- It has not been delegated to a Cloud Platform Appliance.
- It is not part of a delegated network or network container in the same network view.
- It does not belong to a delegated network view.
- It is a reserved range or a range that has been assigned to a DHCP member that is the same Cloud Platform Appliance to which you want to delegate the range.
You cannot delegate a DHCP range that has been assigned to a failover association, nor can you assign a DHCP range that has been delegated to a failover association.
Authority is delegated from the start address to the end address, including exclusions. Note that the exclusions can be used only to restrict IP addresses generated by the next available IP feature.
All discovery related attributes for a DHCP range return the default values.
Although no DHCP service restart is required, you can perform a DHCP service restart on a Cloud Platform Appliance through a cloud API request.

You cannot create, modify, or delete a DHCP range on the Grid Master if it has been delegated to a Cloud Platform Appliance.
You can create a DHCP range and delegate it to a Cloud Platform Appliance using a range template.
You can increase the size of a DHCP range that has been explicitly delegated to a Cloud Platform Appliance. The increased size is available for use by the Cloud Platform Appliance after replication.

When you create a DHCP range through a cloud API request, you must include the following extensible attributes in the request: Tenant ID, Cloud API Owned, and CMP Type.

IPv4 and IPv6 Fixed Addresses

Consider the following authority delegation guidelines when you create, modify, or delete a fixed address:

You can delegate authority for a fixed address only through inheritance from one of its parent objects, such as its associated network view, network container, network, or DHCP reserved range.
When you create or modify an IPv4 or IPv6 fixed address, you must include the following extensible attributes in the cloud API request: Tenant ID, Cloud API Owned, and CMP Type.
You can create a fixed address from the Grid Master using a fixed address template. Note that when you want to reference a template in the cloud API request, you must know the name of the template beforehand.
When performing any operations on a Cloud Platform Appliance, all discovery related attributes for a fixed address return the default values.
No DHCP service restart is required when performing any operations for a fixed address on the Cloud Platform Appliance unless automatic DHCP restart is disabled on the appliance. You can however perform a DHCP service restart on the Cloud Platform Appliance to which authority is delegated for a fixed address through a cloud API request.
You can create, modify, or delete an IPv4 or IPv6 fixed address and reservation on the Grid Master through Grid Manager if the fixed address or reservation is within the scope of a network view, network container, network, or DHCP reserved range whose authority has been delegated to a Cloud Platform Appliance.

See Sample Cloud API Requests for a sample cloud API request.
For information about how to create IPv4 and IPv6 fixed addresses, see Adding IPv4 Fixed Addresses and Adding IPv6 Fixed Addresses.
For information about how to create IPv4 and IPv6 fixed address templates, see Adding IPv4 Fixed Address/Reservation Templates and Adding IPv6 Fixed Address Templates.

DNS Views

Consider the following authority delegation guidelines when you create, modify, or delete a DNS view:

You cannot explicitly delegate authority for a DNS view. The Cloud Platform Appliance automatically gains authority over any DNS view that exists in the network view whose authority is delegated to that appliance.
You cannot create or delete a DNS view from the Cloud Platform Appliance.
Through a cloud API request, you can update DNS views defined in a network view that has been delegated to the Cloud Platform Appliance.
You cannot create, modify, or delete a DNS view in network views that have been delegated to a Cloud Platform Appliance through a standard API request.
You cannot delete a DNS view as long as it contains at least one DNS zone that has been delegated to a Cloud Platform Appliance.

DNS Zones

Consider the following authority delegation guidelines in 21744878 when you create, modify, or delete a DNS zone. See Sample Cloud API Requests for a sample cloud API request.
For information about how to create DNS zones, see About Authoritative Zones.

Table 7.7 Authority Delegation for DNS Zones

Cloud API Requests	Standard API and WAPI Requests	Comments
The Grid primary of a DNS zone automatically gains authority for the zone if the primary is a Cloud Platform Appliance. When there are multiple primaries configured for the zone, multiple delegations to these primaries are allowed as long as they are Cloud Platform Appliances. You cannot assign both a Microsoft server and a Grid member as primaries at the same time, although you can assign a Microsoft server as the Grid primary and a Cloud Platform Appliance as the Grid secondary. This allows the Microsoft server to serve changes sent from the cloud adapter. All resource records in a DNS zone inherit authority delegation from the zone. However, you cannot modify the NS record through a cloud API request. You can modify all the fields for a zone whose authority has been explicitly delegated. The cloud member to which authority for a network view is delegated automatically gains authority for authoritative zones defined in that network view. This Cloud Platform Appliance is the only cloud member that can be the Grid primary for the zones defined in this network view. The Grid Master does not have authority for any zone in this network view unless it is assigned as a Grid primary. The Cloud Platform Appliance can create, modify, and delete a DNS zone in any DNS view defined in a network view whose authority has been delegated to that cloud member. The Cloud Platform Appliance that is authoritative for a DNS zone can perform changes to the assigned Grid primaries, Grid secondaries, and external servers assigned to the zone as long as the Cloud Platform Appliance remains a Grid primary. But it cannot create, modify, or delete the NS record. The Cloud Platform Appliance that is authoritative for a DNS zone can create, modify, and delete DNS delegations that are directly parented to that zone. In particular, it may specify any Grid primary, Grid secondary, or external server for that zone. DNSSEC operations, network associations, and zone locking are not supported if at least one Cloud Platform Appliance is assigned as the Grid primary for any DNS zones. Although no DHCP service restart is required, you can perform a DHCP service restart on a Cloud Platform Appliance through a cloud API request.	You cannot create, modify, or delete a DNS zone in a network view whose authority has been delegated to a Cloud Platform Appliance. You cannot assign a Cloud Platform Appliance as the Grid primary for a zone that is locked or disabled. You can modify extensible attributes of any DNS zone whose authority has been delegated from the Grid Master.	Only authority for authoritative forward-mapping and reverse-mapping zones can be delegated. You cannot delegate authority for forward zones, stub zones, and delegated zones even though they may exist in a delegated network view. When you create a DNS zone using a cloud API request, you must include the following extensible attributes in the request: Tenant ID, Cloud API Owned, and CMP Type.

DNS Resource Records

Consider the following authority delegation guidelines in 21744878 when you create, modify, or delete a resource record, including A, AAAA, CNAME, PTR, MX, SRV, TXT, NAPTR records.
See Sample Cloud API Requests for a sample cloud API request.

Table7.8 Authority Delegation for DNS Resource Records

Cloud API Requests	Standard API and WAPI Requests	Comments
Authority delegation for resource records (A, AAAA, CNAME, PTR, MX, SRV, TXT, and NAPTR) is inherited from their parent zones. You can delegate authority for these records by delegating authority for their respective parent zones. All resource records in a DNS zone inherit authority delegation from their parent zones. However, you cannot modify the NS record through a cloud API request. If the Cloud Platform Appliance is a Grid primary for a zone, requests that include a supported record is processed locally by the Cloud Platform Appliance. Otherwise, the request is proxied to the Cloud Platform Appliance that is assigned as the only Grid primary for the zone. If the DNS resource records belong to a zone that is served only by Cloud Platform Appliances, authority for these records are considered delegated. You must create, modify, or delete these records on one of these Cloud Platform Appliances.	You cannot create, modify, or delete a resource record if it is in a network view whose authority has been delegated to a Cloud Platform Appliance.	When you create a resource record through a cloud API request, you must include the following extensible attributes in the request: Tenant ID, Cloud API Owned, and CMP Type.

Host Records

Consider the following authority delegation guidelines in 21744878 when you create, modify, or delete a host record. See Sample Cloud API Requests for a sample cloud API request.

Table7.9 Authority Delegation for Host Records

Cloud API Requests	Standard API and WAPI Requests	Comments
Authority delegation for a host record is inherited from both the DNS and DHCP portions of the record. For DNS, you can delegate authority for all DNS zones for which the host record is defined. For DHCP, you can delegate authority for the parent network view, network container, network, or DHCP range defined for the host record. You can create, modify, or delete a host record or a host IP address whose authority is delegated to a Cloud Platform Appliance through Grid Manager. Note that when you create a host record, you must enable it for DNS within the delegated network view. Otherwise, you will not be able to save the host record. The Cloud Platform Appliance can process a cloud API request that includes a host record only if it has gained authority for both DNS and DHCP portions of the host record, as follows: All IP addresses enabled for DHCP within one or more delegation scopes are delegated to the same Cloud Platform Appliance. All DNS records defined for one or more DNS zones have the same Cloud Platform Appliance assigned as the Grid primary.	IP addresses defined in the host record that is enabled DHCP follow the same rules for a fixed address. See 21744878 21744878 for more information. Names or aliases defined in the host record follow the same rules set for resource records. See 21744878 21744878 for more information.	When you create a host record through a cloud API request, you must include the following extensible attributes in the request: Tenant ID, Cloud API Owned, and CMP Type.
IP addresses defined in the host record that is enabled for DHCP follow the same rules set for a fixed address. See 21744878 for more information. Names or aliases defined in the host record follow the same rules set for resource records. See 21744878 21744878 for more information. Although no DHCP service restart is required, you can perform a DHCP service restart on a Cloud Platform Appliance through a cloud API request.

NIOS 8.3 EA2

About Authority Delegation