Archive

Archive for April, 2014

Book review: Learning Veeam® Backup & Replication for VMware vSphere

April 28th, 2014 No comments

A while back I saw the following tweet by Christian Mohn (@h0bbel).

The author describes the intended audience as follows.

This book is aimed at vSphere administrators looking for an introduction to Veeam® Backup & Replication v7 for VMware. If you are interested in learning how you can set up a basic infrastructure, this book is for you

He actually delivers on what he does promise. The book is a nice introduction on how to set up backup and replication jobs, walking you through each step starting from the installation.

The first chapter also gives a short introduction on common backup terms and one commonly used backup concept. This is then applied in the following chapters.

Some of the more advanced features do get their own chapter and are described from a functionality point of view even though with less detail than the actual backup, replication and restore features.

If you are completely new to Veeam Backup this book is an ideal overview to get you started quickly, if you are looking for extrem in depth technology knowledge and behind the curtains information you are not the target group of that book. It can easily be read in 1 evening as it is roughly above 100 pages.

On a final note I would love to see chapter 5 bumped up with as much details as the previous chapter for the advanced features as well in a future edition of this book.

 

Categories: Books Tags:

Changing the IP of a vCenter Server 5.1 system – Part 1 – The easy way

April 13th, 2014 No comments

A couple of weeks back I had a post on changing the hostname of a vCenter server system. Today I am going to look how an IP change will go. The system is very small with a local database installed. VUM is also installed on the same machine. All web based services are working fine.

Capture2

None of my certificates do actually include an IP address, forward and reverse DNS are setup correctly though and my domain controller is multi homed to keep the setup small.

Capture

The domain controller also has the “Routing and Remote Access” role installed and serves as the default router in the setup so I don’t need to do any changes to the connected host.

Capture4

The last thing I checked was that this time we actually do have a hardware status on the virtual ESXi to compare if this is still the same afterwards.

Capture3

Disclaimer: This is not a tested or officially approved procedure by VMware at any means, use at your own risks, don’t come to me complaining if everything breaks, DO A BACKUP! The proper way would be a reinstall of the binary packages against existing databases.

First step is actually stopping all services and changing the IP address of the vCenter server system. We are going from 192.168.0.10 to 172.16.0.10. This is followed by a reboot of the system. The first test we are going to do is a ping from the host which is successful (after turning off the blocking in the Windows Firewall). Even though the host does still have the old vCenter Server IP in the vpxa.cfg it won’t disconnect as we see later on.

Capture5

The system boots up just fine like expected and Windows did accept the IP change without any further issues.

Capture6 Let’s check the services overview next to see if vCenter server was able to start successfully and we are actually looking pretty good there as well.

Capture7

Logging into vCenter server the hardware status looks actually good as well but we can see the Update Manager tab is missing now.

Capture8

So let’s see why the Update Manager plugin won’t connect anymore, which leads us to the vCenter Service Health status and gives us the clue that the addon actually registered with the IP address instead of the host name.

Capture9

This is easily fixed though using the Update Manager Utility.

Capture10

One service restart later we get the following picture which completes our little IP change procedure pretty successfully. And just to prove the point this time we have a look at the service status using the Web Client to demonstrate that it did not brake during the procedure as well.

Capture11

This part was called “easy” because I did not introduce any dependencies on the IP in the certificates which I will do in a later post to see if the procedure is as smooth and easy as this one was.

Categories: SSL Tags:

Where is the keystore for domain controller certificates in Single Sign-On 5.1?

April 8th, 2014 No comments

A couple of weeks ago I got a request from one of our Technical Account Managers that I would have thought to be a rather quick question on how to look at the contents of a java key store.

I recommended Portecle (brilliant tool btw.) but was soon to learn that there was some follow up questions.

What the customer actually wanted to do is to have a peek at the key store of the domain controller certificates which were saved in SSO to remove PoC certificates and move to production.

So there were a couple of follow up questions involved:

1) Where is that key store actually saved on the file system?
2) Is there a direct relationship between the identity source and the SSL certificate?
3) How would we actually remove the certificates from the key store?

Turns out the answer did involve quite a bit of work.

First I tried to find the file on the system by simply starting Process Monitor (another rather awesome tool, go watch the “Case of the Unexplained” presentations of Mark Russinovich if you haven’t done so to see the tool in action) and setting several filters for default SSO directories and key store file extensions but turned out to be unsuccessful.

Only place left to look would therefore be the SSO database and as it turns out this is actually the place where these certificates are persisted after being uploaded via the Web Client or using the ssocli command line tool.

This leads us to question number 2, can we determine a direct relationship between the certificate and any identity source. Short answer is “no”. The longer answer leaves us looking at some SQL Server queries.

By simply browsing through all the tables of the SSO database one quickly jumps out as being called in an interesting way, namely “IMS_CERTIFICATES”.

Let’s take a look at the select statement output for that table.

SELECT TOP 1000  [DESCRIPTION],[PURPOSE],[REF_ID] FROM 
[RSA].[dbo].[IMS_CERTIFICATES]
DESCRIPTION PURPOSE REF_ID
NULL PRINCIPAL_CERT 608458820a00a8c063fe86669f076d35
NULL PRINCIPAL_CERT 7428b6120a00a8c02c3b39beb232ac4b
NULL PRINCIPAL_CERT 832b0ee20a00a8c0059824bccd1998c3
RIAT Root CA Certificate STS_TRUST_CERT NULL
NULL PRINCIPAL_CERT c712638f0a00a8c030bc1236fa24da38
NULL LDAP_TRUSTED_CERT NULL

I have cut unimportant fields here that would contain additional data but not serve the purpose. I did add one single domain controller SSL certificate into the Web Client and we do have one entry with the purpose of “LDAP_TRUSTED_CERT” in our table. Interestingly enough we do not have a REF_ID entry in that row though. So it looks like we actually are not having any binding between a specific identity source and that certificate.

Trying to understand further if anything else was updated in the database I rolled back the backup I made before importing the cert and started again to get an exact timestamp. Afterwards I ran the following SQL query.

SELECT deqs.last_execution_time AS [Time], dest.TEXT AS [Query] FROM 
sys.dm_exec_query_stats AS deqs CROSS APPLY 
sys.dm_exec_sql_text(deqs.sql_handle) AS dest 
ORDER BY deqs.last_execution_time DESC

This gave the following output.

Time        Query
2014-04-08 12:39:47.240        (@P0 nvarchar(4000),@P1 int,@P2 nvarchar(4000),@P3 nvarchar(4000),@P4 nvarchar(4000),@P5 nvarchar(4000),@P6 nvarchar(4000),@P7 nvarchar(4000),@P8 datetime)INSERT INTO IMS_CERTIFICATES (ID, ROW_VERSION, NAME, DESCRIPTION, PURPOSE, DATA, REF_ID, LAST_UPDATED_BY, LAST_UPDATED_ON) VALUES ( @P0 , @P1 , @P2 , @P3 , @P4 , @P5 , @P6 , @P7 , @P8 )

2014-04-08 12:39:47.220        (@1 varchar(8000))SELECT [ID],[ROW_VERSION],[NAME],[DESCRIPTION],[PURPOSE],[DATA],[REF_ID],[LAST_UPDATED_BY],[LAST_UPDATED_ON] FROM [IMS_CERTIFICATES] WHERE [PURPOSE]=@1

So we can actually see that no other table was touched during the transaction and can confidently conclude that we do not have any identity source to certificate mapping within our SSO 5.1 instance.

As for the last question…

DisclaimerThis is not a tested or officially approved procedure by VMware at any means, use at your own risks, don’t come to me complaining if everything breaks, DO A BACKUP!

Well we do know the text that we need to look for within the purpose field of that table to get the proper rows, we then can filter by the date or try to unscramble the data encoding in which I will not go into any further for today. Deleting certificates is as easy as deleting the row but it is playing around with a backend database which could potentially break your most central vSphere component so it is not really recommended to do so.

Categories: SSL, SSO Tags: