If anyone tries to install the new Microsoft ADK (for Windows 10 Version 1703 – 10.1.15063) on Windows server 2016, you receive the error that a driver is not digitally signed. Well, Microsoft drivers are not signed? Something is wrong…
Actually, according to this post, they really have a problem and there is a workaround with disabling the secure boot. But this is not recommended and is not aligned with best practices – so you don’t want to do it.
Anyway, this is the only way you can install ADK on server 2016 and I did it. I have removed the previous (broken) installation, disabled Secure boot and reinstalled ADK. After a successful installation, I reenabled Secure boot and things still went wrong. I was unable to mount ADK boot image (to use in SCCM or MDT). Well, in this post it is explained another workaround (yes, I know…). Set the registry as is explained and it should work. I just hope that all other functionalities in ADK now are working OK.
DFS still not replicating Sysvol
In addition to my previous post on reestablishing synchronization of SYSVOL folders between DCs, I received some comments that going true steps in the posts is not possible to reestablish sync. After this I diagnosed some situations when friends allowed me to connect and there was always a similar situation: DFS replication stops to work after dirty shutdown (event 2212 and 2213) and nobody saw it for a long time – more than 60 days. This will cause an Error 4012 where you can see that the server was “disconnected” for a time, which is longer than the time allowed by the MaxOfflineTimeInDays parameter (60 days by default).
To verify how long are DCs not synced, use this command line (execute from elevated command prompt):
For /f %i IN (‘dsquery server -o rdn’) do @echo %i && @wmic /node:”%i” /namespace:\\root\microsoftdfs path DfsrMachineConfig get MaxOfflineTimeInDays
If the result is more than 60 days, you have to extend MaxOfflineTimeInDays parameter on all servers where you have DFS replication in error (State = 5) and where MaxOfflineTimeInDays parameter is greater than 60. Use this command line on any DCs that are in error:
wmic /namespace:\\root\microsoftdfs path DfsrMachineConfig set MaxOfflineTimeInDays=365
Of course you can replace the number 365 with any number you want, but it has to be greater than the displayed MaxOfflineTimeInDays value.
Wait for few minutes and resume replication as is described in the previous post. It should work.
I suggest also to put back the value MaxOfflineTimeInDays parameter to previous value:
wmic /namespace:\\root\microsoftdfs path DfsrMachineConfig set MaxOfflineTimeInDays=60
WannaCrypt Malware
Of course you have heard about the new malware, which yesterday created a lot of problems in industry. Unfortunately it is not an unknown problem.
Microsoft released a patch for this type of vulnerability already in March, but it seems once again that administrators are not patching their systems.
So, if you haven’t patched your systems at least every month, if you haven’t patched your system from March, is time to do it. And don’t forget to have a good defense system (antivirus and other prevention mechanisms). Update them to!
You can find additional information in this link.
Here is a link to post how was neutralized and who did this.
Anyway, we have already a version 2.0; you can read about this version here.
Again, please patch your systems! This update will solve a vulnerability. And don’t forget: this is not the first malware who was written on known vulnerability – patch your systems constantly!
Additionally, please disable SMB1 protocol – it is not new that it is not secure. Here and here are some guidelines how to do it via GPO.
Migrating Enterprise CA to new server (Part 1)
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.
Source server
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.
Have your forgotten your Local Administrator password?
Well, if the computer is yours and you have physical access to it, than you can solve it.
This procedure will work with Windows 8.x and newer and Windows server 2012 and newer. It is not a real hacking technology, but we will use a hole of the operating system.
All we need in this case is to open a shell with enough high privileges before we are asked for the password. Impossible? Not really.
We will do it in a simple way:
- Insert installation media to your computer and start it from installation media
- In installation process select Repair your computer
- In Choose your option select Troubleshoot and then Command prompt
- Find the partition where Windows are installed (default is C:) and change directory to Windows\System32 (cd \\Windows\\System32)
- For server systems you have to rename file “UserInit.exe” to something else, using command Ren UserInit.exe Userinit.Old and replace the missing file with cmd by copying a file with command copy cmd.exe userinit.exe
- For windows systems you have to rename the file “Utilman.exe” to something else, using the command Ren Utilman.exe Utilman.Old and replace the missing file with cmd by copying a file with command copy cmd.exe Utilman.exe
- Restart the computer to boot into normal operating system (where you forgot the password)
- Click on Easy of Access icon and a Command prompt window will open. To clarify, this Command shell is opened as system, so you can do a lot of things here.
- If Administrator account is disabled (Windows 8.x or 10), first you need to enable it with command Net user Administrator /enable:yes
- Reset password of Administrator account with command Net user Administrator MyPassword, where MyPassword is your new password
- Close command prompt and login to your System.
Do not use this procedure for hacking. This article is meant for recovering your passwords and passwords for your clients and will not recover domain passwords.
