Point-to-Point GRE VPN Tunnels - Unprotected GRE & Protected GRE over IPSec Tunnels

Configuring Point-to-Point GRE VPN Tunnels - Unprotected GRE & Protected GRE over IPSec Tunnels

Written by Administrator. Posted in Cisco Routers - Configuring Cisco Routers

4.72727272727 1 1 1 1 1 Rating 4.73 (44 Votes)

inShare

Tweet

Generic Routing Encapsulation (GRE) is a tunneling protocol developed by Cisco that allows the encapsulation of a wide variety of network layer protocols inside point-to-point links.

A GRE tunnel is used when packets need to be sent from one network to another over the Internet or an insecure network. With GRE, a virtual tunnel is created between the two endpoints (Cisco routers) and packets are sent through the GRE tunnel.

It is important to note that packets travelling inside a GRE tunnel are not encrypted as GRE does not encrypt the tunnel but encapsulates it with a GRE header. If data protection is required, IPSec must be configured to provide data confidentiality – this is when a GRE tunnel is transformed into a secure VPN GRE tunnel.

The diagram below shows the encapsulation procedure of a simple - unprotected GRE packet as it traversers the router and enters the tunnel interface:

While many might think a GRE IPSec tunnel between two routers is similar to a site to site IPSec VPN (crypto), it is not. A major difference is that GRE tunnels allow multicast packets to traverse the tunnel whereas IPSec VPN does not support multicast packets. In large networks where routing protocols such as OSPF, EIGRP are necessary, GRE tunnels are your best bet. For this reason, plus the fact that GRE tunnels are much easier to configure, engineers prefer to use GRE rather than IPSec VPN.

This article will explain how to create simple (unprotected) and secure (IPSec encrypted) GRE tunnels between endpoints. We explain all the necessary steps to create and verify the GRE tunnel (unprotected and protected) and configure routing between the two networks.

Creating a Cisco GRE Tunnel

GRE tunnel uses a ‘tunnel’ interface – a logical interface configured on the router with an IP address where packets are encapsulated and decapsulated as they enter or exit the GRE tunnel.

First step is to create our tunnel interface on R1:

R1(config)# interface Tunnel0

R1(config-if)# ip address 172.16.0.1 255.255.255.0

R1(config-if)# ip mtu 1400

R1(config-if)# ip tcp adjust-mss 1360

R1(config-if)# tunnel source 1.1.1.10

R1(config-if)# tunnel destination 2.2.2.10

All Tunnel interfaces of participating routers must always be configured with an IP address that is not used anywhere else in the network. Each Tunnel interface is assigned an IP address within the same network as the other Tunnel interfaces.

In our example, both Tunnel interfaces are part of the 172.16.0.0/24 network.

Since GRE is an encapsulating protocol, we adjust the maximum transfer unit (mtu) to 1400 bytes and maximum segment size (mss) to 1360 bytes. Because most transport MTUs are 1500 bytes and we have an added overhead because of GRE, we must reduce the MTU to account for the extra overhead. A setting of 1400 is a common practice and will ensure unnecessary packet fragmentation is kept to a minimum.

Closing, we define the Tunnel source, which is R1’s public IP address, and destination – R2’s public IP address

As soon as we complete R1’s configuration, the router will confirm the creation of the tunnel and inform about its status:

R1#
*May 4 21:30:22.971: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up

Since the Tunnel 0 interface is a logical interface it will remain up even if there is no GRE tunnel configured or connected at the other end.

Next, we must create the Tunnel 0 interface on R2:

R2(config)# interface Tunnel0

R2(config-if)# ip address 172.16.0.2 255.255.255.0

R2(config-if)# ip mtu 1400

R2(config-if)# ip tcp adjust-mss 1360

R2(config-if)# tunnel source 2.2.2.10

R2(config-if)# tunnel destination 1.1.1.10

R2’s Tunnel interface is configured with the appropriate tunnel source and destination IP address. As with R1, R2 router will inform us that the Tunnel0 interface is up:

R2#
*May 4 21:32:54.927: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up

 

Routing Networks Through the GRE Tunnel

At this point, both tunnel endpoints are ready and can ‘see’ each other. An icmp echo from one end will confirm this:

R1# ping 172.16.0.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 172.16.0.2, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

R1#

Again, this result means that the two tunnel endpoints can see each other. Workstations on either network will still not be able to reach the other side unless a static route is placed on each endpoint:

R1(config)# ip route 192.168.2.0 255.255.255.0 172.16.0.2

On R1 we add a static route to the remote network 192.168.2.0/24 via 172.16.0.2 which is the other end of our GRE Tunnel. When R1 receives a packet for 192.168.2.0 network, it now knows the next hop is 172.16.0.2 and therefore will send it through the tunnel.

The same configuration must be repeated for R2:

R2(config)# ip route 192.168.1.0 255.255.255.0 172.16.0.1

Now both networks are able to freely communicate with each over the GRE Tunnel.

Securing the GRE Tunnel with IPSec

As mentioned earlier, GRE is an encapsulation protocol and does not perform any encryption. Creating a point-to-point GRE tunnel without any encryption is extremely risky as sensitive data can easily be extracted from the tunnel and viewed by others.

For this purpose, we use IPSec to add an encryption layer and secure the GRE tunnel. This provides us with the necessary military-grade encryption and peace of mind.  Our example below covers GRE IPSec Tunnel mode.

GRE IPSec modes are covered extensively in our GRE and IPSec – GRE Over IPSec - Selecting and Configuring Gre IPSec Tunnel or Transport Mode.

Configuring IPSec Encryption for GRE Tunnel (GRE over IPSec)

IPSec encryption involves two steps for each router. These steps are:

(1) Configure ISAKMP (ISAKMP Phase 1)

(2) Configure IPSec (ISAKMP Phase 2)

Configure ISAKMP (IKE) - (ISAKMP Phase 1)

IKE exists only to establish SAs (Security Association) for IPsec. Before it can do this, IKE must negotiate an SA (an ISAKMP SA) relationship with the peer.

To begin, we’ll start working on R1.

First step is to configure an ISAKMP Phase 1 policy:

R1(config)# crypto isakmp policy 1

R1(config-isakmp)# encr 3des

R1(config-isakmp)# hash md5

R1(config-isakmp)# authentication pre-share

R1(config-isakmp)# group 2

R1(config-isakmp)# lifetime 86400

The above commands define the following (in listed order):

3DES - The encryption method to be used for Phase 1.

MD5 - The hashing algorithm

Pre-share - Use Pre-shared key as the authentication method

Group 2 - Diffie-Hellman group to be used

86400 – Session key lifetime. Expressed in either kilobytes (after x-amount of traffic, change the key) or seconds. Value set is the default value.

Next we are going to define a pre shared key for authentication with R1's peer, 2.2.2.10:

R1(config)# crypto isakmp key firewallcx address 2.2.2.10

The peer’s pre shared key is set to firewallcx. This key will be used for allISAKMP negotiations with peer 2.2.2.10 (R2).

 

Create IPSec Transform (ISAKMP Phase 2 policy)

Now we need to create the transform set used to protect our data. We’ve named this TS:

R1(config)# crypto ipsec transform-set TS esp-3des esp-md5-hmac
R1(cfg-crypto-trans)# mode transport

The above commands defines the following:

- ESP-3DES - Encryption method

- MD5 - Hashing algorithm

- Set IPSec to transport mode

Finally, we create an IPSec profile to connect the previously defined ISAKMP and IPSec configuration together. We’ve named our IPSec profile protect-gre:

R1(config)# crypto ipsec profile protect-gre

R1(ipsec-profile)# set security-association lifetime seconds 86400

R1(ipsec-profile)# set transform-set TS

We are ready to apply the IPSec encryption to the Tunnel interface:

R1(config)# interface Tunnel 0
R1(config-if)# tunnel protection ipsec profile protect-gre

Now it's time to apply the same configuration on R2:

R2(config)# crypto isakmp policy 1

R2(config-isakmp)# encr 3des

R2(config-isakmp)# hash md5

R2(config-isakmp)# authentication pre-share

R2(config-isakmp)# group 2

R2(config-isakmp)# lifetime 86400

 

R2(config)# crypto isakmp key firewallcx address 1.1.1.10

R2(config)# crypto ipsec transform-set TS esp-3des esp-md5-hmac

R2(cfg-crypto-trans)# mode transport

R2(config)# crypto ipsec profile protect-gre

R2(ipsec-profile)# set security-association lifetime seconds 86400

R2(ipsec-profile)# set transform-set TS

R2(config)# interface Tunnel 0

R2(config-if)# tunnel protection ipsec profile protect-gre

Verifying the GRE over IPSec Tunnel

Finally, our tunnel has been encrypted with IPSec, providing us with the much needed security layer. To test and verify this, all that is required is to ping the other end and force the VPN IPSec tunnel to come up and start encrypting/decrypting our data:

R1# ping 192.168.2.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms

Using the show crypto session command, we can quickly verify the encryption is in place and doing its work:

R1# show crypto session

Crypto session current status

Interface: Tunnel0

Session status: UP-ACTIVE

Peer: 2.2.2.10 port 500

IKE SA: local 1.1.1.10/500 remote 2.2.2.10/500 Active

IPSEC FLOW: permit 47 host 1.1.1.10 host 2.2.2.10

Active SAs: 2, origin: crypto map

Cisco ASA 8.2 and Below – Static Nat

The other day I had to configure a Static nat entry on a 8.2 ASA. It had been a while since I had done this since almost everything I work with is 8.3 and above. I thought I would make an entry for myself and maybe to help someone along the way.
Example – I have public IP 1.1.1.10 and I need to forward in port 443 to my internal server of 192.168.1.10. I have an access-list Outside-IN applied to my outside interface. Note if the 1.1.1.10 is my outside interface IP (lets say I have only one public IP) then we would use the interface key word
ASA config –
config t
static (inside,outside) tcp 1.1.1.10 443 192.168.1.10 443
access-list Outside-IN permit tcp any host 1.1.1.10 eq 443
or
static (inside,outside) tcp interface 443 192.168.1.10 443
access-list Outside-IN permit tcp any host 1.1.1.10 eq 443
That’s it!
Compared to 8.3 and above –
object network 192.168.1.10
host 192.168.1.10
nat (inside,outside) static interface service tcp 443 443
access-list Outside-IN permit tcp any host 192.168.1.10 eq 443 — Notice the internal IP.

Resource:

http://travelingpacket.com/2014/08/04/cisco-asa-8-2-and-below-static-nat/
 

How to configure static NAT on a Cisco ASA security appliance

Two of the most common forms of network address translation (NAT) are dynamic port address translation (PAT) and static NAT.

Network jobs are hot; salaries expected to rise in 2016

Wireless network engineers, network admins, and network security pros can expect above-average pay
Read Now

PAT is the many-to-one form of NAT implemented in many small office and home networks where many internal hosts, typically using RFC 1918 addresses such as 192.168.0.0/24, share a single external address on the public Internet. Static NAT is a one-to-one mapping which is used when an internal host needs to be accessible from the public Internet or some other external network.
RESOURCES: Cisco how-to guides for firewalls, IPv6, contact centers and taking that security exam
In this article I'll explain how to configure static NAT to make an internal Web server accessible from an external network. The same concept applies when you want to make any internal server accessible from an external network, whether it's a Web server, a mail server, an FTP server, or any other type of server or device.

This is based on ASA software Version 9.0(1) and applies to Version 8.3 and later. There is a companion video available here.
Use the following diagram with this documentation. This diagram uses RFC 1918 addresses. In the real world, the outside interface would most likely be configured with a registered, public address.

There are four steps involved in enabling static NAT:

1. Create the network object and static NAT statement. A network object must be created identifying the internal host. Within the network object, you must also create a static NAT statement to identify the outside interface, its IP address, and the type of traffic to be forwarded: object network InternalHost host 192.168.102.5 nat (inside,outside) static interface service tcp 80 80.
2. Create a NAT statement identifying the outside interface. Note that, in the static NAT statement above, the use of the term interface tells NAT to use whatever address is on the outside interface. The first use of 80 identifies the originating port number. The second use of 80 identifies the destination port number.
3. Build the Access-Control List. Build the Access-Control List to permit the traffic flow (this statement goes on a single line): access-list OutsideToWebServer permit tcp any host 192.168.102.5 eq www.
4. Apply the ACL to the outside interface using the Access-Group command: access-group OutsideToWebServer in interface outside. This is the complete configuration:

When successfully implemented, this configuration will permit a host on the outside network, such as the public Internet, to connect to the internal Web server using the address on the ASA's outside interface.

Configuring the ASA with multiple outside interface addresses

It is not possible to assign multiple IP addresses to the outside interface on a Cisco ASA security appliance. It is possible, however, to configure the ASA to forward different outside addresses to different hosts on the inside network.
For example, you have a /29 block of addresses assigned by your ISP. Also, suppose you have a mail server using POP3 and SMTP and a Web server using HTTP and HTTPS on the inside network. You want each of the servers to be reachable via different outside addresses. You can configure static NAT to accomplish this (see diagram, and again, in the real world the outside interface would probably be configured with registered, public addresses instead of the RFC 1918 addresses shown here).

Resources

The steps are similar for single-address static NAT configuration:
1. Configure network objects. Configure a network object for each internal host with a static NAT static statement specifying the outside address to be used and the service types (port numbers) to be forwarded. These identify the internal hosts, the desired outside IP address, and the type of service to be forwarded. (The exclamation marks are for formatting to improve readability and are not required for the configuration.)

object network WebServer-HTTP
host 192.168.102.5
nat (inside,outside) static 192.168.1.194 service tcp 80 80
!
object network WebServer-HTTPS
host 192.168.102.5
nat (inside,outside) static 192.168.1.194 service tcp 443 443
!
object network MailServer-SMTP
host 192.168.102.6
nat (inside,outside) static 192.168.1.195 service tcp 25 25
!
object network MailServer-POP3
host 192.168.102.6
nat (inside,outside) static 192.168.1.195 service tcp 110 110

Note that in the above configurations the host statement identifies the internal server (192.168.102.5 is the Web server and 192.168.102.6 is the mail server). The NAT statement identifies the external address used to forward the specified packets to the internal host.
2. Configure Access-Control Lists to permit the traffic flows. This Access-Control List permits the traffic flows against the security levels (each access-list statement goes on a single line).

access-list OutsideToInside permit tcp any host 192.168.102.5 eq 80
access-list OutsideToInside permit tcp any host 192.168.102.5 eq 443
access-list OutsideToInside permit tcp any host 192.168.102.6 eq 25
access-list OutsideToInside permit tcp any host 192.168.102.6 eq 110

3. Apply the Access-Control List to the outside interface with an access-group statement.

access-group OutsideToInside in interface outside

Here is the complete configuration:


Resource:
http://www.networkworld.com/article/2162844/tech-primers/how-to-configure-static-nat-on-a-cisco-asa-security-appliance.html

Bandwidth (Easy Traffic Shaping in Cisco IOS)

If you followed my recent Cisco Catalyst rate-limiting post, you already know that policing traffic on a Cisco Catalyst switch requires a bit of thought. Mainly, you have to do a bit of calculating to determine the best bucket size for your application. The good news is that achieving the same affect on a Cisco IOS-based router is much easier.
You can enable shaping on an interface (or sub-interface) in three easy steps. Just remember: class, policy, interface.

Class

class-map match-any CLASS_SLAP
 match any 

On the router, we have the ability to tell the class map to match any traffic. This is in contrast to the Catalyst switch where we had to specify an access-list to match on. This saves us a step and achieves the exact same results. In this case, we are going to assign all traffic to the CLASS_SLAP class.

Policy

policy-map POLICY_SLAP
 class CLASS_SLAP
  shape average 8000000

Now it's time to define our policy map. In this case, we're going to take any traffic that matched the CLASS_SLAP class (which, as you remember, is all traffic) and apply a shaping policy to it. We use the shape average 8000000 configuration command to limit our speed (the CIR) to 8 Mbps. Another configuration command available for a policy map is bandwidth, which has a similar effect. Unfortunately, a policy map utilizing the bandwidth configuration command can not be applied to a sub-interface. This limitation may not be a problem for you, though.

Interface

interface GigabitEthernet0/3.429
 encapsulation dot1Q 429
 service-policy output POLICY_SLAP

Finally, we need to apply the policy map to an interface using the service-policy configuration command. In this example, I used a sub-interface to make the example a little more applicable to real word circumstances. I've also applied the policy map in the outbound direction. Thus, the users of VLAN 429 are only allowed to download at an aggregate of 8 Mbps.
Wasn't that easy? How do your own experiences compare?
UPDATE: I recently added a post that discusses rate limiting based on time of day. Check it out!

Exchange 2013 | The WS-Management service cannot process the request. The load quota for the system has been exceeded.

Like in the previous versions of Exchange (like 2010) you may receive the following error when using the Exchange Management Shell on an Exchange 2013 server.

VERBOSE: Connecting to XCH14.DomainX.local.
New-PSSession : [xch14.DomainX.local] Connecting to remote server xch14.DomainX.local failed with the following error message : The WS-Management service cannot process the request. The load quota for the system has been exceeded. Send future requests at a slower rate or raise the system quota. For more information, see the about_Remote_Troubleshooting Help topic.
At line:1 char:1
+ New-PSSession -ConnectionURI “$connectionUri” -ConfigurationName Microsoft.Excha …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : OpenError: (System.Manageme….RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotingTransportException

To resolve this problem you need to go to the Internet Information Services (IIS) Manager.
Go to the Application Pools find the MSExchangePowerShellAppPool. Select this one and use right click to recycle this AppPool.

After you recycled the AppPool you will be able to use the Microsoft Exchange  Management shell again.

How to Export Mailboxes with Exchange Server 2010 SP1

Exchange Server 2010 Service Pack 1 introduced a new method for exporting mailboxes called Mailbox Export Requests.  This new method replaces the previous Export-Mailbox command.
Before we look at how to create a new mailbox export request in Exchange 2010 SP1 there are a few things that you should understand.
Firstly, no accounts are granted the rights to export mailboxes by default.  You need to explicitly grant these rights, even to accounts that are organization administrators.
Secondly, the mailbox export request is processed by the Client Access server role.  Because multiple Client Access servers can exist in a site the request could be processed by any one of them.  To ensure that the path to the export PST file is valid for any Client Access server it has to be a UNC path to network share, not a local path.

Granting User Rights for Mailbox Exports in Exchange 2010 SP1

The first step is to grant the right to export mailboxes to an account in your organization.  In the Exchange Management Shell run the following command.

New-ManagementRoleAssignment –Role "Mailbox Import Export" –User Administrator

If you’re logged with that user already simply restart your Exchange Management Shell session to be granted access to the new cmdlets.

Creating a Network Share for Mailbox Exports in Exchange 2010 SP1

Next we need to create the network share that will be used as the file path for the exported PST files.  All that is required here is a network share that the Exchange Trusted Subsystem group has read/write permission to.

Exporting a Mailbox with an Exchange Server SP1 Mailbox Export Request

With everything configured properly we can now use New-MailboxExportRequest to start the mailbox export.  The only two required parameters for the command are the file path to the export PST file, and the name of the mailbox to export.

[PS] C:\>New-MailboxExportRequest -Mailbox alan.reid -FilePath \\esp-ho-ex2010a\pst\alan.reid.pst

Name                                           Mailbox                                        Status
----                                           -------                                        ------
MailboxExport                                  exchangeserverpro.net/Company/Users/Head Of... Queued

To view the status of the request use the Get-MailboxExportRequest cmdlet.

[PS] C:\>Get-MailboxExportRequest

Name                                           Mailbox                                        Status
----                                           -------                                        ------
MailboxExport                                  exchangeserverpro.net/Company/Users/Head Of... InProgress

You can also see more detail about the mailbox export request with Get-MailboxExportRequest.

[PS] C:\>Get-MailboxExportRequest -Name MailboxExport | fl

RunspaceId     : c48a9069-e572-4c65-80ea-773e61e5337e
FilePath       : \\esp-ho-ex2010a\pst\alan.reid.pst
SourceDatabase : MB-HO-01
Mailbox        : exchangeserverpro.net/Company/Users/Head Office/Alan.Reid
Name           : MailboxExport
RequestGuid    : 9de3a722-0c82-4e34-98bf-0ff624c47c16
RequestQueue   : MB-HO-01
Flags          : IntraOrg, Push
BatchName      :
Status         : InProgress
Protect        : False
Suspend        : False
Direction      : Push
RequestStyle   : IntraOrg
OrganizationId :
Identity       : exchangeserverpro.net/Company/Users/Head Office/Alan.Reid\MailboxExport
IsValid        : True

An easy way to see the progress of all mailbox export requests is to pipe Get-MailboxExportRequest into the Get-MailboxExportRequestStatistics cmdlet.

[PS] C:\>Get-MailboxExportRequest | Get-MailboxExportRequestStatistics

Name                                   Status                    SourceAlias                           PercentComplete
----                                   ------                    -----------                           ---------------
MailboxExport                          InProgress                Alan.Reid                             20

Exporting an Archive Mailbox with Exchange Server SP1 Mailbox Export Request

You can also export a user’s Personal Archive using mailbox export requests simply by adding the -IsArchive parameter to the command.

[PS] C:\>New-MailboxExportRequest -Mailbox alan.reid -FilePath \\esp-ho-ex2010a\pst\alan.reid.pst -IsArchive

Completing the Mailbox Export Request

When a mailbox export request is completed it remains on the server until it is removed by an administrator using Remove-MailboxExportRequest.
To see all of the completed mailbox export requests run this command.

[PS] C:\>Get-MailboxExportRequest | where {$_.status -eq "Completed"}

Name                                           Mailbox                                        Status
----                                           -------                                        ------
MailboxExport                                  exchangeserverpro.net/Company/Users/Head Of... Completed

And to clear all completed mailbox export requests from Exchange run the following command.

[PS] C:\>Get-MailboxExportRequest | where {$_.status -eq "Completed"} | Remove-MailboxExportRequest

Delegating computer object management tasks

December 17, 2013 2 Comments

 

 

 

 

 

 

1 Vote

Introduction

The subject of delegating permissions in Active Directory for management of computer objects has been covered many times in many forums. I wanted to try to collect all that information as well as add some refinements of my own.

Rights vs. permissions

In the olden days, back when I was just a wee lad and Windows NT was new, the ability to join a computer to a domain was controller by a user right called Add workstations to domain. This user right is only valid on domain controllers. Any use who had this right could join computers to a Windows NT domain. The user right still exists and is in use even on Windows Server 2012 R2 Domain Controllers running Active Directory domains. When users join their computers to the domain using their own credentials they do it using this user right. It is, in fact, the only option available to them, since no regular users are granted any permissions over computer objects in Active Directory by default.
Back in the NT era this right was granted to the Users group and there was no limit to how many computers any give user could add to the domain. When Windows 2000 came along and with it Active Directory the user right was changed to apply to the Authenticated Users security principal and any one user could only add 10 computers to a domain by default. But the preferred way for Active Directory was to use permissions in the directory service to control object creation, modification and deletion…
Active Directory has a very fine grained permissions set allowing you to set permissions for objects as well as their properties. These permissions work the same way as the rest of the authorization model in Windows does by using Access Control Lists (ACL) with security principals and their permissions listed in individual Access Control Entries (ACE). Permissions can be granted anywhere in the hierarchy and inherited down to objects and containers. Granting permissions in Active Directory to someone or something is often called delegation. Computer objects are of course also included in these permissions and we can create much better delegation of control than we could with just a global user right.
We’ll cover three delegation of control scenarios regarding computer object management in this post:

1. Allowing a security principal to join (add) a computer to a domain
2. Allowing a security principal to join and re-join a computer to a domain
3. Allowing a security principal to rename a computer in a domain
4. Allowing a security principal to move computer objects in a domain

You can of course combine any of these.
Creating a computer object and changing its properties is what is required to join a computer to the domain. The container could be the Computers container or any other OU or container, including the domain itself but I do not recommend that.
When a computer joins an Active Directory domain without specifying a path, it is placed in the Computers container. The Computers container is not an OU and so it cannot have Group Policy Objects linked to it or have sub containers or OUs. If you are fine with all computer objects being created in this container you can delegate the permissions below to the Computers container

1. Allowing a security principal to join (add) a computer to a domain

First out is the most common scenario; join a computer to an Active Directory domain. As stated earlier it is not necessary to delegate this to regular users since the very few cases where they join their own computers to a domain should be covered by the Add workstation to domain user right. One exception to this is if you want to tighten down security and remove all security principals from this user right. In that case, if you still want to allow regular users to be able to join computers to a domain you have to delegate permissions to them. The more common case is that whatever deployment solution you use adds the computers to the domain. This is by far the best solution since very few users have any idea what a domain is.
A best practice is to create a service account used only for adding computers to the domain. This account should be clearly labeled, have a strong password and not have any other rights or permissions in you directory except the ability to join the domain. That being said the procedure below works for any security principal you want to delegate permissions to join the domain for.

1. Identify the security principal that you want to delegate permissions for
   This can be any security principal; user, group etc.
2. Identify the container or OU where you want to allow users to manipulate computer objects
3. Right click the container or OU you selected and select Delegate Control…
   
4. The Delegation of Control Wizard opens, hit Next
   
5. The Users or Groups window opens:
   Select the security principal you want to grant permissions to, then hit Next again.
   
6. The Tasks to Delegate window opens:
   Select Create a custom task to delegate and hit Next
   
7. The Active Directory Object Type window opens:
   Select Only the following objects in the folder and select Computer objects, select Create selected objects in this folder and finally hit Next
   
8. The Permissions window opens
   Select Property-specific and select Read All Properties. This is actually redundant since this permissions are already granted to the Authenticated Users principal, but the delegation of control wizard will not let you continue without selecting something on this screen.
9. Finally the Completing the Delegation of Control Wizard window opens showing you a summary of your actions. Hit Finish.
   

Delegation of Control Wizard Summary

You chose to delegate control of objects
in the following Active Directory folder:
    saferoad.com/Computers
The groups, users, or computers to which you
have given control are:
    Domain Join Account (SvcJoinComputerToDom@saferoad.com)
They have the following permissions:
    Read All Properties
For the following object types:
    Computer

The selected principals can now join computers to the domain.

2. Allowing a security principal to join and re-join a computer to a domain

The second scenario; allowing a principal to also re-join a computer to a domain requires some additional permissions. This is useful if you want to have a service account that can manage all computer accounts, also existing ones. System Center Configuration Manager for example requires these permissions.

1. Identify the security principal that you want to delegate permissions for
2. Identify the container or OU where you want to allow users to create and configure computer objects
3. Right click the container or OU you selected and select Delegate Control…
   
4. The Delegation of Control Wizard opens, hit Next
   
5. The Users or Groups window opens:
   Select the security principal you want to grant permissions to, then hit Next again.
   
6. The Tasks to Delegate window opens:
   Select Create a custom task to delegate and hit Next
   
7. The Active Directory Object Type window opens:
   Select Only the following objects in the folder and select Computer objects, select Create selected objects in this folder and Delete selected objects in this folder, and finally hit Next
   
8. The Permissions window opens
   Select Property-specific and select these individual permissions:
   - Reset Password
   - Read and write Account Restrictions
   - Validated write to DNS host name
   - Validated write to service principal name 
   
9. Finally the Completing the Delegation of Control Wizard window opens showing you a summary of your actions. Hit Finish.
   

Delegation of Control Wizard Summary

You chose to delegate control of objects
in the following Active Directory folder:

    <domain>/Computers
The groups, users, or computers to which you
have given control are:
    Domain Join Account (SvcJoinComputerToDom@<domain>)
They have the following permissions:
    Reset password
    Read and write account restrictions
    Validated write to DNS host name
    Validated write to service principal name
For the following object types:
    Computer

The selected principals can now join computers to the domain as well as re-join computers when the computer account already exists.

3. Allowing a security principal to rename a computer in a domain

Here goes no. 3…

 

1. Identify the security principal that you want to delegate permissions for
2. Identify the container or OU where you want to allow users to create and configure computer objects
3. Right click the container or OU you selected and select Delegate Control…
   
4. The Delegation of Control Wizard opens, hit Next
   
5. The Users or Groups window opens:
   Select the security principal you want to grant permissions to, then hit Next again.
   
6. The Tasks to Delegate window opens:
   Select Create a custom task to delegate and hit Next
   
7. The Active Directory Object Type window opens:
   Select Only the following objects in the folder and select Computer objects and hit Next 
   
8. The Permissions window opens
   Select Property-specific and select Write All Properties.
   Scroll down an add these individual permissions as well:
   - Validated write to DNS host name
   - Validated write to service principal name 
   
9. Finally the Completing the Delegation of Control Wizard window opens showing you a summary of your actions. Hit Finish.
   

Delegation of Control Wizard Summary


You chose to delegate control of objects
in the following Active Directory folder:
    saferoad.com/Computers
The groups, users, or computers to which you
have given control are:
    Domain Join Account (SvcJoinComputerToDom@saferoad.com)
They have the following permissions:
    Write All Properties
    Validated write to DNS host name
    Validated write to service principal name
For the following object types:
    Computer

The selected principals can now rename a computer in a domain.

4. Allowing a security principal to move computer objects in a domain

The last one is a little more involved as it requires changing permissions on both the source container/OU and the destination. The destination container/OU requires the same permissions as in scenario 1 so set those. Follow these steps to configure the source container/OU:

1. Identify the security principal that you want to delegate permissions for
2. Identify the container or OU where you want to allow users to create and configure computer objects
3. Right click the container or OU you selected and select Delegate Control…
   
4. The Delegation of Control Wizard opens, hit Next
   
5. The Users or Groups window opens:
   Select the security principal you want to grant permissions to, then hit Next again.
   
6. The Tasks to Delegate window opens:
   Select Create a custom task to delegate and hit Next
   
7. The Active Directory Object Type window opens:
   Select Only the following objects in the folder, select Computer objects and , select Delete selected objects in this folders, hit Next 
   
8. The Permissions window opens
   Select Property-specific and select Write All Properties. 
   
9. Finally the Completing the Delegation of Control Wizard window opens showing you a summary of your actions. Hit Finish.
   

Delegation of Control Wizard Summary


You chose to delegate control of objects
in the following Active Directory folder:
    saferoad.com/Computers
The groups, users, or computers to which you
have given control are:
    Domain Join Account (SvcJoinComputerToDom@saferoad.com)
They have the following permissions:
    Write All Properties
For the following object types:
    Computer

More information

There is an interesting distinction between joining a domain by exercising the user right Add workstation to the domain and using delegated permissions. If you join by the user right the owner of the resulting computer object is the Domain Administrators group, but if you join by delegated permissions the owner is the user who actually performed the join. Also if a principal has both the user right and delegated permissions, delegated permissions take precedent and are used to join the computer to the domain. A recommended best practice her would be to remove all principals from the user right and just rely on permissions. You do that by applying a policy to your domain controllers where no principal has the user right:

The location of the user right is:
Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\User Rights Assignment
You could also increase the default quota of 10 computer accounts added to the domain per user, but I do not recommend that. I essence you are copying the settings from Windows NT to your Active Directory domain and do not take advanced of the advanced delegation model in Active Directory. For completion here is how to change the quota:
From any editor capable of displaying and changing individual attributes of Active Directory objects; display the properties of the domain NC. Locate the ms-DS-MachineAccountQuota property and change it to your desired value: