I seem to get all the PKI/Certificate services problems! Yesterday I was trying to use the web enrolment portal on a certificate services server, and could not get in locally, (or remotely) via http, (or https) it simply showed me a 403.14 error.
HTTP Error 403.14 Forbidden
Solution
This was an odd one, in IIS Manager select the ‘Certsrv’ virtual directory > Advanced Options > And look at the ‘Path’.
Mine was missing the ‘en-us‘ folder from the end of the path!
Note: You will need to open an administrative command window, and then execute an iisreset command, before the change will take effect.
Related Articles, References, Credits, or External Links
I was trying to deploy some client AV packages today, there was an x86 version (x32 Bit) and a x64 bit version of the client software. As I was deploying the software via Group Policy I needed to write a different policy for each package. Then I needed to make sure the x32 bit client only deployed to x32 bit machines, and the 64 bit client only deployed to x64 bit machines.
To do that you need a simple WMI filter.
Create an x86 (32 Bit) WMI Filter
Open the Group Policy Management Console (gpmc.msc) on a domain controller > Drill down to your domain > WMI Filter > New > Give it a sensible name (you will be picking it from a list) > Add > Paste in the following;
[box]SELECT AddressWidth FROM Win32_Processor WHERE AddressWidth =’32′[/box]
Click OK > Accept the warning > OK.
Create a 64 Bit WMI Filter
Open the Group Policy Management Console (gpmc.msc) on a domain controller > Drill down to your domain > WMI Filter > New > Give it a sensible name (you will be picking it from a list) > Add > Paste in the following;
[box]SELECT AddressWidth FROM Win32_Processor WHERE AddressWidth =’64′[/box]
Click OK > Accept the warning > OK.
Applying a WMI Filter to a GPO
With the group policy selected > Scope Tab > WMI Filtering > Select the appropriate filter.
Related Articles, References, Credits, or External Links
I can’t really take the credit for this, I was at a client’s site a few weeks ago, and they were doing this. I thought ‘That’s cool, I’ll have a play with that when I get the chance”.
Essentially, you update the description of the Computer object(s) in AD so that they list;
The last user who logged on.
What time they logged on.
What AD ‘Site’ the machine is in.
Model of the PC/Laptop.
Serial Number of the machine.
Operating System.
32 or 64 bit.
I tested it in VMware so my machine type and serial number are a little misleading but this is what it looks like.
Now I can think of loads of situations when that information would be very helpful?
Solution : Last User
So how do you do it? Well to make a change to a computer’s ‘Description’ filed in AD, requires some rights, locate the OU (or OUs) that contain your computers/servers and open the advanced properties on their security tab.
You can either ‘Add’ (as shown), or select the existing ‘Authenticated Users’ object from the list.
Change the ‘Applies to’ section to ‘Descendant Computer Objects’.
Scroll down and tick, ‘Write Description’
Isn’t that dangerous? Well not really, it gives users the right to change a computer objects description field, they would need to have the technical ability to do so. And if they did it would get overwritten the next time a user logged onto that machine anyway.
Download the ComputerDescriptionLogonStamp.zip file, and extract the two files you find inside it, into your domain netlogon share (\\{your-domain-name}\netlogon). Edit the domain name in the ComputerDescriptionLogonStamp.bat file so it matches YOUR domain name not mine!
Now create a new Group Policy Object, linked to your USERS.
Edit the policy, and navigate to;
[box]User Configuration > Windows Settings > Scripts > Logon[/box]
Add in the UNC path to the ComputerDescriptionLogonStamp.bat file (Note: Make sure you use a UNC path, to your Netlogon folder, and you do NOT browse locally to the file, if the path looks like; C:\windows\sysvol\pnl.con\sysvol\ComputerDescriptionLogonStamp.batIT WON’T WORK.)
Close the Group policy editor, then either wait, or force a group policy update.
In vSphere 5 and earlier versions this was not a ‘fun’ job at all, many times I sat down to do it, and lost the will to live. Now there’s a nice new tool built into vCenter that does ‘most’ of the hard work for you. Here I’m using the vCenter appliance but the tool is also available on the Windows version.
For my certificates I’m using Microsoft Certificate Services. I’m going to issue a ‘Subordinate CA’ certificate to my vCenter Appliance, then it can issue signed certificates to each of its services.
Solution
Make sure you have published a ‘Subordinate Certification Authority’ certificate template.
Connect the the vCenter appliance using SSH and enable ‘shell’
[box]
shell.set --enabled True
shell
[/box]
Create a directory to store our certificates and requests in, then launch the certification-manager tool.
The app will launch, and present you with a bunch of options.
Select option 2 > No we don’t want to use the configuration file > enter your logon information, (administrator@vsphere.local and password) > Enter all the items required for the certificate request.
Choose option 1 (Generate Certificate signing request) > Specify the folder you created above, (/root/SSLCerts) > Two files will be generated > Enter ‘2’ to exit.
The files;
vCenter 6.5
vmca_issued_key.key (the private key)
vmca_issued_csr.csr (the request)
vCenter 6.0.0
root_signing_cert.key (the private key)
root_signing_cert.csr (the request)
Now we need to get the CSR (signing request).
[box]
cat /root/SSLCerts/vmca_issued_csr.csr
OR
cat /root/SSLCerts/root_signing_cert.csr
[/box]
Copy the certificate PEM file.
Open the web enrolment portal of your certificate services server, (https://server.domain.com/certsrv) > Request a certificate > Advanced Certificate Request > Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file > Paste in the PEM text > Remember to use the Subordinate Certificate Authority template > Submit.
Base 64 Encoded > Download Certificate > Save it somewhere you can find it, and give it a sensible name!
Now download the Base 64 version of your CA certificate from the main page of your certificate services website, (press ‘back’ a few times).
Now back in your SSH session, change to your SSLCerts directory, and create an ’empty’ file to paste our certificate information into.
[box]
cd /root/SSLCerts/
touch vmca_signing_cert.cer
vi vmca_signing_cert.cer
[/box]
Open the certificate for the vCenter Appliance in a text editor, and PASTE INBELOW it, the text from the Root-CA certificate. Then copy ALL the text to the clipboard, and go back to the SSH session.
Paste the text you have coped into the open ‘vi editor’ page (Press I, then P) > Save and Exit (Press Esc > :wq {enter})
If you ‘ls’ (thats list short, or dir if you are a Windows type), you will see you now have a .CSR, a .KEY and a .CER file. (the names of which vary between version 6 and 6.5).
Version 6.5
Version 6.0
Launch the certificate-manager application again > Option 2 again > No (again) > Login (again) > ‘N’ > Option 2 (Import custom certificate(s)) > Give it the path to the certificate file > Then the path to the key file.
This is pretty much part two of the last article I wrote, so make sure you have the vCenter CA setup as a Sub CA of your Microsoft Certificate Services Deployment. See the following article;
Now we take the next step, and replace the certificates on the ESXi hosts.
Solution
Note: Joining the ESXi Hosts to the domain is not essential, it just makes things a little smoother. Ensure the host is set with the correct hostname and DNS settings.
Join the host to your domain.
vCenter 6.5
vCenter 6.0
Supply the domain name and suitable credentials.
Set the domain members to trust the vCenter CA Certificate. Back in part one we issued a SUB CA cert to the vCenter. Now I’m going to get a copy of this certificate, and get all my domain members to trust it, (and by definition all the certificates it issues). Browse to the vCenter https address > And open the certificate properties (click the padlock) > Certificate path > CA > View Certificate > Install Certificate.
Local machine.
I’m going to put it in Intermediate Certificate Authorities.
Then open an MMC console, and add in the certificate snap-in for Local Computer > Intermediate Certification Authorities > Certificates > Locate the ‘CA’ Certificate.
Export the certificate.
DER encoded is fine.
Save it on the root off the C: drive with a sensible name.
Open an administrative command window, and issue the following commands;
Now you will see the domain members start to get the CA certificate, (either in Intermediate or Root, depending on the command you issued above).
Meanwhile back in vCenter Web Client > Right click each host > Certificates > Refresh CA Certificates > Then Refresh Certificate.
WARNING: You may see the error below; if you do, it’s a bug don’t panic, there is a fix published on VMware Support. But if you wait 24 hours and attempt to renew the certificates it will work without an error.
A general system error occurred: Unable to get signed certificate for host: esx-host.your-domain.pri. Error: Start Time Error (70034).
You should see something like this;
If you browse to each ESXi host on https it should connect without errors or warnings.
Related Articles, References, Credits, or External Links
The vCenter Appliance used to be a simple to deploy from OVA, but now you need to deploy it from another machine, (and it has to be a Windows machine).
Solution
Before you attempt to deploy the appliance, ‘pre-create’ its host records in your DNS.
Download the vCenter Appliance .ISO file and mount it on your Windows machine, navigate to the vcsa-iu-installer directory, and run the installer.exe file.
Install > Next > Accept the EULA > Next > Select Embedded Platform Services Controller* > Next.
*Note: For larger environments you can install the PSC on a separate appliance, and it handles things like single sign on, provisioning and certification etc.
Enter the details for the ESX server the appliance is getting deployed on > Next > Enter the name for the VC and its root password > Next > Select the deployment type > Next > Select the storage you want to deploy to, and whether you want to use thin provisioning > Next.
Fill in the IP details for the new appliance, and its DNS settings > Next > Finish.
The appliance will deploy > When completed, you can further configure the appliance > Next > Enter your NTP settings > Next.
Set the SSO configuration* > username = administrator@vsphere.local > Password = {something complex}, (you will need it in a minute! (DON’T EVER LOOSE THESE CREDENTIALS!!)) > Next > I usually untick CIEP > Next > Finish
*Note: We will configure domain authentication later.
It will take while to reconfigure, when complete click the hyperlink > vSphere Web Client > Log on with the credentials you entered above.
Join the vCenter Appliance to a Domain
You cannot perform domain authentication unless the appliance is a domain member, so first you need to join a domain.
Provide the domain name and an account, (with rights to add machines to the domain) > OK.
Nothing happens! This is normal don’t worry, you need to reboot the appliance, this can take a while (actually it reboots quite quickly, but it will be a while before you can login to the web console) > OK.
Over in Active directory you will see a new computer object.
The only indication you will see on the appliance, is now you have a domain name, and the ability to ‘Leave’.
Enable Domain Authentication
Note: If you have a separate Platform Services Controller, use the following article instead;
I’m simply going to add my Domain Admins group to the the administrators group on the Virtual Center, there are a number of different roles on ESX you can map to whatever domain groups you want to create.
Administration > Single Sign On > Configuration > Identity Sources > Add.
Active Directory (Integrated Windows Authentication) > Next > You domain should be shown > Next > Finish.
Select you domain and set is as the default identity source.
Users and Groups > Groups > Administrators > Add.
Change the domain to yours, and add in the Domain Admins group > OK
In ‘Hosts and Clusters‘ view > Select the Virtual Center > Permissions > Add.
Select the Administrators ‘role’ > Then add the Domain Admins group in the same way you did above.
Add your licence code(s) > Next > Give them a sensible name > Next > Finish.
Assets Tab > Select the Virtual Center > Assign Licences > Select the appropriate licence > OK.
Deployment, > System Configuration >Nodes > Manage > Advanced > Active Directory > Join.
Note: If you have already added hosts you can assign their licences here also, I will assign the host licences when I add the hosts to the cluster.
Create a vSphere DataCenter
In hosts and Clusters view > Right click the vCenter > New DataCenter > Give it a name > OK
Create a vSphere Cluster
Right click the DataCenter you have just created > New Cluster > Give it a name > OK
Note: You can enable licensed features here, like DRS, HA, EVC etc. Bur I prefer to do this later.
Adding ESX Hosts to your vSphere Cluster
Right click you cluster > Add Host.
Enter the name or IP > Next > Enter the root account and password > Next (If you get a certificate warning click OK > Next.
Select an appropriate licence, (or select the evaluation licence if you have not yet added any licences) > Next > I always disable lockdown mode > Next > Finish.
Related Articles, References, Credits, or External Links
FirePOWER Management Center, will give you a wealth of information on traffic/threats etc. Usually it will tell you what IP the offenders are on, but if you want to know what a USER is doing, then that means you have to look though logs see who had what IP, at what time etc.
So you can install the FirePOWER User Agent on a machine, (this can be a client machine, though I usually put it on a member server). You then tell the the user agent to monitor your active directory server(s) and it keeps a record of which user is where, which it reports back to the FMC for its dashboards and logs.
Note: This is for Version 6.0.0
You will need to create a user in your domain to query AD with, (just a member of domain users is fine). I typically use svc_firepower as the username.
Solution
Your first challenge is to find the software, you would think it would be with the firewalls or the appliance but no!
In the FMC > System > Integration >Identity Sources > User Agent > New Agent > Supply the IP of the server that you are going to install the agent on > OK > Save.
On the DOMAIN CONTROLLER(S) that you will point the agent at, make sure WMI is open on the firewall
On the DOMAIN CONTROLLER(S) that you will point the agent at, run wmimgmt.msc > WMI Control Local > Properties > Security > Root > cimv2 > Security.
Grant your firepower user Remote Enable > Apply > OK.
On the DOMAIN CONTROLLER(S) that you will point the agent at, run comexp.msc > Console root > Computers > My Computer > Properties > COM Security > ‘Launch and Activation Permissions’ Section > Edit Limits.
Grant your FirePOWER account the Remote Launch and Remote Activation permissions > Apply > OK.
On the Default Domain Controllers Group Policy > Computer configuration >Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment > Manage Auditing and security log >Add in your FirePOWER user.
Note: Allow time for the policy to apply, (or run ‘gpupdate /force‘, or simply force the policy from the GPMC.msc console, (if your domain is 2012)).
On the server/machine that you want to install the agent on, run setup.exe (1), if you run setup.msi (2) then only the agent is installed and it will error if you try and launch it.
Open the agent and add in your domain controllers.
Note: Sometimes, you may have the following problem;
I needed to add .Net 3.5 to a Windows Server for an application install, but when I added it as a ‘feature’ it failed.
Server 2016
The request to add or remove features on the specified server failed. The source files could not be found. Use the “Source” option to specify the location of the files that are required to restore the feature. For more information on specifying a source location, see http://go.microsoft.com/fwlink/?LinkId=243077. Error: 0x800f08081f
Server 2012
Installation of one or more roles, role services, or features failed.
The source files cannot be found. Try installing the roles, role services, or features again in a new Add Roles and Features Wizard session, and on the Confirmation page of the wizard, click “Specify an alternate source path” to specify a valid location of the source files that are required for the installation. The location must be accessible by the computer account of the destination server.
Solution
1. Open an Administrative Command Window.
2. Insert the Server 2012 Install DVD (or present the .ISO if its a virtual machine) >Execute the following command;
[box]
Dism /online /enable-feature /featurename:NetFx3 /All /Source:D:\sources\sxs /LimitAccess
Where D: is the DVD Drive Letter
[/box]
That Didn’t Work?
I had this problem again this week at a clients site. They were running Server 2012 R2 and needed .Net 2.0 for an application they used. However, when I tried to install it (as above) this happened;
[box]
Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.
C:\Windows\system32>dism /online /enable-feature /featurename:NetFx3 /ALL /Source:D:\sources\sxs /LimitAccess
Deployment Image Servicing and Management tool
Version: 6.3.9600.17031
Image Version: 6.3.9600.17031
Enabling feature(s)
[===========================66.2%====== ]
Error: 0x800f081f
The source files could not be found.
Use the "Source" option to specify the location of the files that are required to restore the feature. For more information
on specifying a source location, see
http://go.microsoft.com/fwlink/?LinkId=243077.
The DISM log file can be found at C:\Windows\Logs\DISM\dism.log
C:\Windows\system32>
[/box]
Error: 0x800f081f
So I tried via PowerShell and got this;
[box]
Windows PowerShell
Copyright (C) 2014 Microsoft Corporation. All rights reserved.
PS C:\Windows\system32> Install-WindowsFeature -name NET-Framework-Core -source D:\sources\sxs
Install-WindowsFeature : The request to add or remove features on the specified server failed.
Installation of one or more roles, role services, or features failed.
The source files could not be downloaded.
Use the "source" option to specify the location of the files that are required to restore the feature. For more
information on specifying a source location, see http://go.microsoft.com/fwlink/?LinkId=243077. Error: 0x800f0906
At line:1 char:1
+ Install-WindowsFeature -name NET-Framework-Core -source D:\sources\sxs
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (@{Vhd=; Credent...Name=localhost}:PSObject) [Install-WindowsFeature],
Exception
+ FullyQualifiedErrorId : DISMAPI_Error__Cbs_Download_Failure,Microsoft.Windows.ServerManager.Commands.AddWindowsF
eatureCommand
Success Restart Needed Exit Code Feature Result
------- -------------- --------- --------------
False No Failed {}
PS C:\Windows\system32>
[/box]
Error: 0x800f0906
If you are having similar problems, try running the install from Server Manager > Manage > Add/Remote Roles and features, then specify a different source;
Or you can try using the Microsoft .Net Framework Repair Tool;
There is a ‘known problem’ That is caused by Window update 2966828.
To see if you have it installed, run the following command;
[box]
Get-Hotfix | Where HotfixID -match "2966828"
[/box]
Above you can see I DON’T have it installed, if you do, then remove it.
Another ‘known problem’ is, if your server has multiple language packs installed, run ‘lpksetup’ and remove any other language packs, (you can add them back afterwards.) So it looks like this;
None of the above worked for me, what I did was download a new ISO image for Server 2012 R2, then I copied the ‘sources’ directory from the ISO to the servers C: drive, then ran the following command;
We have had ADMX files for group policies for ages now, they are the successor to the older ADM files. They only really trip you up if you have something unusual to do, (likeroll out LAPS, or Forefront, or Customising Office Deployments.)
In most cases you will want to have a central store in your Windows domain, so the clients can see the ADMX files, (and ultimately enforce the policies within them).
Solution
You probably already have ADMX files on your windows clients/servers, look in C:\Windows\PolicyDefinisions. So if you have installed any new ADMX files, they will get put in this folder on your local machine, (or domain controller).
Do you already have a central PolicyDefinitions store? It’s easy to find out, from any domain joined machine, run the following command;
If theres a PolicyDefinitions folder already there, half your work has been done for you!
Copying Files to the Central PolicyDefinitions Store
ADMX Files are usually accompanied by an ADML file, while the ADMX files live in the PolicyDefinitions folder, the ADML files are ‘location specific’, if you look in your PolicyDefinitions folder you will see another sub folder for your ‘locale’. Below you can see mine is en-US (English US) your ADML files will live in here.
IMPORTANT: As you can see, (below). I’ve navigated to the PolicyDefinitions folder ON A DOMAIN CONTROLLER, at the following path;
DON’T Try and copy the folder, (or ADMX and ADML) files to the network path of SYSVOL, or you ‘may’ get permission errors, (see error below).
You can simply copy the entire PolicyDefitions folder across if it does not already exist, or copy individual ADMX/ADML files (to the folder locations outlined above).
Now on your domain controller, Administrative tools > Group Policy Management console, create (or edit and existing policy). If you are setup correctly you should see this;
If something is wrong you will see this;
Copying PolicyDefinisions and ADMX/ADML Files: Access Denied
If this happens, you need to ensure you are NOT trying to copy folders or files to the network path of the SYSVOL folder, Open the LOCAL path to the SYSVOL folder directly on a domain controller.
Related Articles, References, Credits, or External Links
