This will be a step by step process to migrate Active Directory Certificate Services from one server to another in same domain. It is a case when you upgrade or change your server where CA is installed.
You have to know some basic things before you begin to migrate a CA server:
- It is recommended that the new server has the same name as old one – this because we have CRL and other paths in certificates. If this name is not accessible, we can’t control the validity of the certificate.
- This is not a migration from one server to another; we have to export all settings and backups from the old server, demount it and after this install the new one with the same name. Errors and mistakes are not allowed.
- Do the migration slowly, take your time, document everything. You will need all the documentation during the migration and supporting period.
- In this guide, you will find steps to migrate one server. If you have a more complicated environment with more servers and subordinary CAs, then you need plans for migration of the entire migration before you start the migration.
First take full backup of the entire server. This step is non mandatory, but you may need it if something goes wrong.
After this check and write down the server name, IP address (if is static), paths where CA database and CRL are located. You will need this data to restore the same configuration on the new server.
Now, the crucial step is to make a backup of all certificates, certificate templates, settings, databases, root CA and registry settings. Unfortunately, CA backup does not care about all settings – it will backup only the CA database. Steps that are required to be able to transfer the entire configuration are:
- Check all the roles that are installed (CA, CA Web enrolment…) because you will need to install the same roles on the destination server.
- In MMC (mmc.exe) open the Certificate Authority snap in and take a screenshot or write down the names of certificate templates you are using. When you will install the new server, you will have to enable same templates. You can export all certificate template names also with command certutil.exe –catemplates > D:\Backup\catemplates.txt from administrative Command prompt. This step is required only if you are using enterprise CA.
- Now, that we have the CA opened in MMC, we can also use it to backup CA database. To do this right click on CA server name, go to All tasks and select Back up CA. Follow the wizard and be careful that you select Private key and CA certificate and Certificate database and certificate database log check boxes. Only in this way you will backup all data that we need.
- Record your CAs CSP and signature algorithm. This can be done by executing command certutil.exe –getreg ca\csp\* > d:\Backup\csp.txt from administrative Command prompt. There will be nothing to do later if you are using default algorithms, but is always better to check.
- Export the registry keys: on destination server you will need to have the same settings as you had on source, so you need to export registry separately because this is not a part of CA backup procedure. Open Regedit.exe and navigate to HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration. Right click to key and save it to file.
- If you are using custum policy, you should include it into backup. This means that you have to copy the file CAPolicy.inf that is located in C:\Windows (System root folder).
- Review all steps to check if they are done correctly!
- Using server manager remove CA roles from the server and restart the server.
- Remove server from domain, restart it and at the end turn it off. If you have other roles on the same server, you also have to move them on other servers. From this point your old server is down – you don’t need it anymore.
Sometimes you will have to transfer DHCP settings via netsh command. This could be useful for a couple of reasons and it is fine to know how to approach it. Anyway, this is the quickest way to do a DHCP migration.
First you have to login to source server (it could be also a failover clustered DHCP service) and open CMD as Administrator. Then you have to enter in netsh mode with typing:
Now you have to select server with typing:
dns server \\servername
Where servername is the name of the old DHCP server or clustered service name. This will connect you to DHCP server and you are ready to export settings with this command:
export filename all to export the entire configuration or
export filename 192.168.222.0 to export only a scope configuration (in my case 192.168.222.0)
Of course, you have to replace the filename with full path and name of the file where you want to save exported data. This file now must be transferred to target – new server and we are ready to import the configuration. Of course, priory you import the configuration, the new server has to be authorized in AD. To begin an import procedure, we have to do the same steps as on the old server; open command prompt, enter into netsh mode and select DHCP server. After this, we have just a step to import settings with this command:
Import filename all to import all settings or
Import filename 192.168.222.0 to import just a scope
That’s all. Just be sure to double-check if the import did its job, disable and unautorize the old server (you can do it also with netsh: netsh dhcp delete server ServerIP). Of course, don’t forget to uninstall the service on the old computer.
You have finished. Good work!
It is about a year from when Microsoft released LAPS (Local Administrator Password Solution). This is a great tool for keeping your local admins under control and secure.
As we know, a lot of local accounts have weak passwords and we don’t care about this. This’s dangerous! Even if you have a weak local admin password, you can still break a PC with him. If you have the same password for local admins in entire environment, you can have a problem when someone knows this password… Thinking in this way, we have a lot of reasons why to use LAPS. And it is simple to install and use it; it is true that will extend AD schema, but don’t care about this – it is not critical.
LAPS is downloadable from here and it is FREE. Here is also nice post how to install and configure it and this is all you need.
The only problem that I had is enabling and renaming local admin account true GPO, but here is also a very easy trick:
When I install client operating system thru MDT or System Center, I always disable admin account in the last step. It is more secure, but you can have problems if something goes wrong with computer relationship in domain. If you have the same situation, you have to enable Account in Group policy setting Computer Configuration > Polices > Windows Settings > Security Settings > Local Polices > Security Options by enabling setting Accounts: Administrator Account Status. After doing this, it is suggested also to rename Administrator account. This could be done in the same place with setting Account: Rename Administrator account or thru Group policy preferences.
Every administrator is afraid about Ransomware software. We want to protect our systems with so many different approaches and at many layers, but almost always we try to use complicate techniques to archive basic objectives. I found on TechNet
an article, which sounds good for me and I am also confidential using Windows embedded functionalities for trying to prevent an attack.
Are there positive and negative sides? Of course they are, the most important negative thing I recognize is that we are using technology based on file type. Actually we are trying to prevent to write all known file extensions that can be written on our system. This will work if we know the extension and we have to search for new used file extensions and add them as blocked file types. But there are also positive things: we don’t need to buy anything, we have all we need ready on our server – we have just to use it! It is very simple to configure and maintain and it works!
When I read this article, I was surprised why I have to do all those steps thru GUI? We can simply use PowerShell that is quicker and it will do exactly the same things every time we will start it. Well, I made a script that you can run on every server you have to protect and for every share or partition you want to protect. There is only one think that you cannot protect: system drive if you try to prevent whole drive. In this case, the protection will be passive and not active and there is no way to change it (but I hope that you don’t share system drive).
Things that you have to know are basic, just few data:
- Path to protect
- SMTP server for sending mail (and be careful with authentication! Test it!)
- Mail address form which mail will be sent
- Mail address from administrator
- Script that you want to run after detection (if you want)
You can run it as many times you want, on every server you want (version 2008 and newer) and you will be able to protect your data. It is a secure way to do it because you just prevent to change the data transformation and not the malware itself. I recommend also to use a script published on TechNet article for disabling the AD user or deny user access to server (It is also zipped into my file; including subinacl.msi).
To prevent malware, you can use an additional build in function: AppLocker and also this is explained here. And by the way, the approach is tested on Server 2016 TP5 – it’s working!
As I trust and use Kaspersky Antivirus, I had some problems in last month or two. It seems that Kaspersky is not really well integrated with Windows 10 and you have to expect some problems.
In my case, I use Kaspersky Small Office Security and this software prevents me to do a lot of actions. I found the issue when I tried to create External Network Switch in Hyper-V console – the problem is when you create a new network adapter. In this case I received an Error Access Denied – 0x80070005.
I received the same Error also when I tried to install Shrew Soft VPN Client. I was always unable to install network component due to Access Deny. Analyzing the problem, I found that there is a problem accessing to folder INF (Change) and some other system folders, but all permissions were as they should be and there was no way to establish the right permissions to get installers work.
Well, removing Kaspersky I was able to solve the problem. But be careful, just disabling the antivirus will not be enough; you have to completely uninstall the entire antivirus and reboot the computer to correct the issue.
Hope that Kaspersky will correct the issue soon. It is my preferred antivirus program and I like it, but unfortunately it is not well integrated with Windows 10.