What is the tombstone lifetime ?

This is quite a hot question that I get a lot when delivering trainings or helping customers. While most of them know the value, what actually is they do not know.
The Tombstone Lifetime is an attribute of the Directory Services object which can be found with ADSI Edit here: CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=WindowsRockstar,DC=com.

The attribute by default can have 2 values, depending on the OS version that was used when the forest was initially deployed.
It can have no value – this translates to the fact that the forest was started in Windows Server 2000, Windows Server 2003 or Windows Server 2008. This means the Tombstone Lifetime is 60 days.
Starting with Windows Server 2008 R2 the value of the Tombstone Lifetime attribute is 180 days.

The minimum value that we can set the Tombstone Lifetime to is 2 days. If we set it to less it will default to 60 days ( Windows Server 2000, Windows Server 2003 or Windows Server 2008) or 2 days starting with Windows Server 2008 R2 and later.

Below you have an image with the default value in Windows Server 2022

Tombstone Lifetime

Finding out the tombstone lifetime is easy and I wrote about it here.

The tombstone lifetime will influence how long we can use the Active Directory backup and how long an object will remain in recycled or deleted state. About this in a future article.

Active Directory – finding the tombstone lifetime

One of the things that impact the validity of a backup is the tombstone lifetime.

To find it quickly we can use Powershell and run the below:

 (get-adobject "cn=Directory Service,cn=Windows NT,cn=Services,cn=Configuration,dc=windowsrockstar,DC=com" -properties "tombstonelifetime").tombstonelifetime

This will return the answer in days. By default it will be 180 days if your forest started in Windows Server 2008. It will be 60 days or no result (which means 60 days) if your forest started in Windows 2000 or 2003

tombstone lifetime

There is also a GUI way of doing it by using ADSI Edit.

In the Connection Point section, select the Select a well known Naming Context radio button and select Configuration from the dropdown list.

ADSI Edit configuration naming context

Expand Configuration; CN=Configuration,DC=; CN=Services; and CN=Windows NT. Then right click on CN=Directory Service and select Properties.
In the Attribute Editor tab of the properties window, locate the tombstoneLifetime. The value of this attribute represents the forest’s current tombstone lifetime in days. If the attribute’s value shows <not set>, the tombstone lifetime of the forest is 60 days.

Tombstone lifetime – adsi edit

If you want to change the tombstone lifetime you can edit the attribute and set it to desired value in days.

If you want to change the value of tombstone lifetime with Powershell you can use the below code:

(Set-adobject -Server DCNAME  “cn=Directory Service,cn=Windows NT,cn=Services,cn=Configuration,dc=domainname,dc=domainsuffix” -Replace @{‘tombstonelifetime’=”240″})

Don’t forget that how long you can use your Active Directory backup depends on the tombstone lifetime.

Azure Site to Site VPN without dedicated VPN hardware device

Today I will be writing about creating a Site to Site (S2S) Virtual Private Network from your Azure virtual network to your on-premises network without the need to use a dedicated VPN hardware device.

Requirements:

  • active Azure subscription
  • Azure Resource Group
  • Azure virtual network
  • on-premises VM to install Windows Server 2019
  • proper firewall settings.
  • some networking knowledge

We will start by logging on to https://portal.azure.com.

You can use an existing resource group if you already have networks and VMs in it or create a new resource group.

I will create a new one :

image

After creating the resource group I will go and create a Virtual Network. Go to + Create a resource and search for Virtual Network like below:

image

Then press Create:

image

Give the virtual network a meaningful name, choose the resource group and region in which to deploy, then click Next: IP Addresses

image

Create an IP address space that will be different from your on-premises space:

Create a subnet by pressing Add subnet to which you want your resources (VMs) to connect and to which on premise traffic will be routed.

Define the subnet name and address space:

image

Then press Add:

image

Click on Next: Security:

image

Leave settings as default, and click Review+Create. Make sure Validation passed, then click on Create

image

Wait for the deployment to finish:

image

Click Go to resource:

image

Click Subnets

image

Then click on the + Gateway subnet. You can use the defaults or customize the gateway network (this will be used by the VPN gateway) based on your needs:

image

Click OK and wait for the subnet to be added:

image

The next step is to create the Virtual Network Gateway which is our VPN gateway actually. We will deploy a new one from the Marketplace.

Click on + Create a resource and type in the search box virtual network, then select Virtual Network Gateway:

image 

Then press Create:

image

Select the subscription, the resource group, give it a meaningful name, select the region (make sure it is the same as the virtual network), the Gateway type is VPN and the VPN type is Route Based. Select the SKU based on your bandwidth needs, the Generation and virtual network (the one we just created). Create a new Public IP address as this will be our connection point for the VPN. If you want to create an active-active VPN with BGP you can configured that also ( I will write another article on that). Then click Review + create:

image

Make sure Validation passed, then click on Create

image

Be patient (this will take around 20-30 minutes) and Wait for the deployment to finish:

image

Then click Go to resource

image

Check that is was created and that it has a public IP assigned:

image

The next step is to create a Local Network Gateway. To do this go to + Create a resource and search for local network gateway (this will be the definition for the on premise gateway) and click on it:

image

Click Create

image

Give the Local Network Gateway a meaningful name, your public IP address for your on-premise device or RRAS server, select the on premise address range that you want to route to Azure:

image

Click Create and wait for the deployment to finish:

image

Then click Go to resource

image

The next step is to create the VPN connection. For this we need to go to Connections and click + Add

image

Give it a meaningful name, select the Virtual Network Gateway we created earlier and the Local Network Gateway, add a passphrase for the share key and leave the protocol as IKEv2, then click OK

image

Wait for the connection to get created

image

This finished the Azure part of the configuration.

Now we will need to configure our on premises RRAS server. For this I have created a VM, installed Windows Server 2019 on it and now we will install the needed roles on it, then configure the connection. For the routing to work correctly we will need to give the VM 2 network adapters – 1 connected to the external or DMZ network and the 2nd connected to our internal network.

Below are the configured NICs:

image

Now let’s install the RRAS role. Go to Server manager – Manage – Add Roles and Features. Select Role-Based or feature-based installation.

image

Select the server

image

Select the Remote Access role

image

On features click next, then on the Remote Access click next. On Role Services select DirectAccess and VPN (RAS), then click on Add Features

image

Click Next

image

On the Web Server Role (IIS) click next, same on role services

image

Click Install

image

Wait for the installation to finish.

image

After the installation has finished click Close, then open the Routing and Remote Access console

image

Right Click the server name and then click on Configure and Enable Routing and Remote Access

image

Click Next

image

Select Secure connection between two private networks

image

Select Yes

image

If you have a DHCP server in your environment select Automatically. Else select From a specified range of addresses and define the range. I will select Automatically, then click Next

image

Click Finish and wait for the configuration to finish.

image

On the new wizard for the Demand Dial click next

image

Give the connection a meaningful name and click Next

image

Select Connect using virtual private networking (VPN)

image

For the protocol select IKEv2 (same as we select on the Azure side), click Next

image

Go to the VPN gateway on azure and get the Public IP of the VPN gateway.

image

Enter the Public IP of the gateway

image

Make sure Route IP Packets on this interface is selected and click Next

image

On the Static Router click Add

image

Add the address space you defined on the Azure Virtual Network and on the Subnet you defined for your VMs, add a low metric, then click OK

image

It should look like this, click Next

image

On the credentials page put just Azure, click Next

image

Click Finish

image

After the configuration has been finished expand it then go to Network Interfaces

image

Right click Azure S2S, select Properties

image

Go to Security, select Use preshared key for authentication and add the key that was configured on the Azure VPN gateway, then click OK

image

Right click the connection and select connect

image

And he now have a VPN connection to our Azure VNET

image

Now we need to add the route to our VNET in the configuration. Go to IPv4, right click Static Routes and select New static route

image

Add the address space of your Azure subnet, selecting a low metric, click OK


image

I have quickly deployed a test VM on my subnet and tried to ping it from my RAS gateway machine:

image

Plus I can now RDP on the internal interface so no need for public RDP:


image

This is how you deploy a site to site VPN from on premise to Azure for without the need for expensive hardware.

Thank you for reading it all up.

In a future article I will show you how to be able to use a VPN with a dynamic IP address with minimal downtime.