This might be an unpopular take but I very much dislike the way Microsoft uses its Authenticator app for personal accounts. Seriously, it sucks.
If you have a personal account with Microsoft and turn off passwordless authentication in your account but enable two factor with the Microsoft Authenticator, it turns on passwordless authentication in the app for you and you can’t disable it. (Queue up the MFA fatigue).
The way to fix this is to setup another authenticator that’s not the Microsoft one. Save your sanity and stop being MFA bombed by threat actors trying to break into your accounts.
Right-Click your cluster in Server Manager and select “Cluster-Aware Updating”
On the Cluster-Aware Updating Dialog Box, click “Configure Cluster Self-Updating Options” on the right-hand side.
Click “Next” when the wizard opens
On the next screen, make sure you go pre-stage a computer object and put that info here. Note: After creating the new computer object, do the following: 1. Edit the Security Properties of that computer object and give the cluster computer object FULL CONTROLof the new computer object you just created. 2. Protect the new computer object from accidental deletion 3. Disable the newly created computer object
Choose the schedule
Review Advanced Options
Leave defaults on the next screen
Review before clicking Apply:
Wait for the Cluster Role to complete
Once Successfully setup, click “Configure Cluster Self-Updating Options” again, Click Next
This blog is not going to go through the details get the initial ADFS setup. I’m using ADFS on Server 2019 for this demo though. Bring up a Windows Server 2019 and install the ADFS role. This will require a valid SSL certificate. I did not bring up a web proxy as this ADFS server’s only function is to serve authentication for vCenter so we can put DUO behind ADFS.
Add ADFS Certificate(s) Chain to vCenter:
Add the Root & Intermediate CA certificates to vcenter. This can be done under Administration in vCenter at the bottom under Certificates click “Certificate Management”.
Then next to Trusted Root Certificates, click Add and Add Root and/or Intermediate CA certificates here. I added just regular .CRT files that you could open with notepad and show the certificate text.
While here in vCenter Administration, navigate to Single Sign On -> Configuration
Over on the right hand side click on the “i” next to “Change Identity Provider”
Make note of these Redirect URIs you will need them when you configure ADFS.
Configure ADFS for vCenter:
You should now have a brand new install of ADFS with the most basic things configured to make it happy including your SSL certificate. Launch the ADFS Management tool and right click “Application Groups” and click “Add Application Group”.
In the wizard that appears, give your Application a Name and Description that means something to you and select “Server application accessing a web API” and click “Next”.
Make note of the Client Identifier. This will be needed later in vCenter configuration. Also input the two redirect URLs you noted earlier in vCenter. Click “Next”.
Check the box to Generate a shared secret and copy this down as it will be needed later in vCenter configuration. Click “Next”.
Input the Client Identifier from earlier in this wizard in the Identifier box and click “Add” and then Click “Next”.
On the next screen for now click “Permit everyone” we can revisit this later after everything is setup. Click “Next”.
On the next screen make sure “openid” and “allatclaims” are both checked, you will probably have to check “allatclaims”. Click “Next”.
Review and make sure everything looks good. Your Server Application Identifier, and Web API Identifiers should be the same GUID. Click “Next”, and “Close”.
We now need to configure the claims before we can attempt to configure vCenter and attempt a login.
Right-Click the newly created Application Group and select “Properties”
Select the item under Web API and click “Edit”
Click on Issuance Transform Rules. Here we will create three rules. Click Add Rule three times and make your rules look like the following: (Note: All Rules will use the default “Send LDAP Attributes as Claims”)
LDAP Attribute: Token-Groups Qualified by Long Domain Name
Outgoing Claim Type: Group
LDAP Attribute: User-Principal-Name
Outgoing Claim Type: Name ID
LDAP Attribute: User-Principal-Name
Outgoing Claim Type: UPN
Click “OK” to close the dialog box after all three rules have been configured. Click “OK” again to close the Authentication Properties box.
Before we switch over to vCenter configuration we need to snag one more thing from our ADFS server, it is our OpenID Address. To obtain this launch a PowerShell window as Administrator on your ADFS server and type in the following:
You should receive something like the following (save this URL you will need it for vCenter configuration):
vCenter ADFS Configuration:
We are now ready to setup the Identity Provider in vCenter. Navigate back to Administration -> Single Sign On -> Configuration.
This time click the “Change Identity Provider” link instead of the “i” next to it.
Click “Microsoft ADFS” and click “Next”.
On the next screen, you want to copy the Client Identifier and Shared Secret from ADFS that you set aside during setup. The OpenID address also that we just snagged from ADFS.
On the next page fill out the base DN for Users and Groups, I’m using the root because this is just a lab setup. I’m using a service account (only requires read access to AD), and I’m only using ldap:// again because this is a home lab. If you are setting this up in Production make sure you are using ldaps://.
Click “Next”, review and click “Finish”.
You should now be able to add an Admin group in vCenter from your Active Directory source. At this point you should be able to logout and log back in to test out authentication to ADFS.
———–YOU SHOULD NOW HAVE vCENTER & ADFS SETUP————
Proceed forward for the DUO configuration and setup.
Login to your DUO Administration Portal and Click “Applications” and then “Protect and Application” and then locate the entry for “Microsoft ADFS” and click “Protect”
Take note of your “Client ID”, “Client Secret” and “API Hostname”. You will need this information to complete setup on your ADFS server.
After messing with using .htaccess files to lock down my blog I decided to try Cloudflare’s free offering for a simple WAF to protect my blog as well as get some more detail as far as who is talking to it.
I’m still working on configuring Cloudflare and I may have more to say after I get more time to get used to the interface and make some more tweaks.
One of the most important things I wanted to do was be able to lockdown /wp-login.php, /wp-admin, and /xmlrpc.php like I was doing with .htaccess.
I was able to get the same lock down functionality done relatively quickly, using the WAF security rules.
Over on the left-hand side if you navigate to Security -> WAF
I used their template for Zone lockdown, and blocked access to those things from everyone except my IP, which can obviously be edited later if it ever changes or I’m out traveling and want to update my blog.
Of course another lesson learned is you can’t use your domain anymore to SSH to your server. Cloudflare will not allow it. So I created a SSH sub-domain on my domainname in Cloudflare and set it to DNS only.
You might say this defeats the whole purpose of cloudflare because now somebody knows your IP address, and to a certain extent that is true. However, I have apache configured so if someone tries to browse by IP address they get a 403 from .htaccess in a different web directory.
As I get more familiar with WordPress I keep making tweaks to my blog to lock things down more. I thought I would share some of the things I have put in place to help others.
One of the first things I did was monitor the Apache access.log (/var/log/apache2/access.log) to see what kind of traffic was hitting my site.
Here is a summary of web calls I found interesting:
With the REST API on later versions of WordPress the /xmlrpc.php is no longer needed and is therefore a security risk that can allow login attempts to the website. Please read up on it before you disable it if you don’t know what it is.
/wp-admin & /wp-login.php are of course the login page for the site and if we can limit who can access this, this would also drastically increase security
The last one was I was noticing a lot of browsing happening in the /wp-content folder which by default has directory browsing turned on, so anyone can browse any of the files there. We can add a little more security here by turning off directory browsing.
Edit Root .htaccess file
Open up your .htaccess file in the root directory of your WordPress web site. This will already have some WordPress specific items in it.
This is what I added onto the file:
# Make Sure Hidden Files Are Not Accessible (dot files)
RedirectMatch 403 /\..*$
# Block WordPress xmlrpc.php requests
<Files ~ "xmlrpc\.php">
Require all denied
# Block WordPress login page requests unless from certain IP
<Files ~ "wp-login\.php">
Require ip xxx.xxx.xxx.xxx #Put IPs you want to allow here can space separate them
#Disable Directory Browsing
This makes sense for me because I am the only one accessing the administration of this website so it does not need to be open to the world.
The last change I made was I created a .htaccess file in the /wp-admin folder.
/wp-admin .htaccess file
This is what the .htaccess file looks like that I created in the /wp-admin folder
# Block WordPress Requests to /wp-admin
<Limit GET POST PUT>
Require ip xxx.xxx.xxx.xxx #Replace with your IP
These security settings make sense for me as this is a simple blog with one user but they may not make sense for you. I also run no plugins on the site to lower my risk threshold.
Of course the one downside to doing things this way, is if my IP at home changes or I’m out traveling I’ll have to SSH in to the server to allow myself to login, but I’m ok with this. As far as SSH goes I would also strongly suggest key authentication instead of username/password.
I attended a talk last night regarding web application security and the speaker was presenting about OWASP JuiceShop which I had played with very little in the past. I have since started to bring this application back up to play with locally.
I will be writing up tutorials as I go through them.
To “install” OWASP JuiceShop on Kali Linux using docker do the following:
Install Docker: sudo apt install docker.io
Run: sudo docker pull bkimminich/juice-shop
Run: sudo docker run -d -p 3000:3000 bkimminich/juice-shop
Quick Docker Commands To View/Stop Containers:
To view what docker containers are running: sudo docker container ls
To stop a docker container: sudo docker stop 5698ef8694e5 (Using the ContainerID from above, use your own Container ID here)
Performing another sudo docker container ls shows that there are now no containers running.
Note: ipport, appid will be given to you with the first command to look at the certs, use the values of the current cert that is/was working. Make sure the certhash is the new certificate you want to be used here.
This blog is a work in progress but I will be keeping track of things to check when taking over an Active Directory Domain. This is not an all inclusive list but a list of common things to check.
By default in Active Directory this value is set to “10” which allows ANY user in Active Directory to bind ten machines to the domain. In the beginning stages of Active Directory maybe there was a need for this but now its just a big security risk.
Recommendation: Set this to zero
Protected Users Group
Look at highly privileged accounts and add them to the Protected Users Group if they are compatible with the protections that this group provides.
Recommendation: Add any real user accounts that are at Domain Admin or higher. (Enterprise Admins, Schema Admins, etc.)
krbtgt Account Password
Check the last time this password was changed and if it wasn’t changed in the last 180 days, change it.
Recommendation: Make sure you setup a schedule to recycle this password twice a year. This account holds two passwords so when you change the password you should change it twice, ideally 24 hours apart. That is a total of four password changes a year.
Verify SSL Certificates Exist on the Domain Controllers
Verify that valid certificates are in place for LDAPS calls over port 636. As part of this process investigate and try to remove any traffic that is talking on LDAP port 389.
Recommendation: Use either an internal PKI or public facing certificates to make sure all ldaps traffic is talking Active Directory over a secure connection.
Check if Exchange ExtensionAttributes were installed
If “ExtensionAttribute1” -> “ExtensionAttribute15” are in the schema of User/Computer/Group objects, check to see if any of them are in use.
Recommendation: If they are try to document what they are being used for and which ones are free and able to be used.
Check the Default Computer/User Bind OU
The default container for computer objects is (CN=Computers,DC=DOMAIN,DC=COM). This container cannot have group policy applied to it and objects should be set to write to another OU that can be better managed.
“In a default installation of an Active Directory domain, user, computer, and group accounts are put in CN=objectclass containers instead of a more desirable OU class container. Similarly, the accounts that were created by using earlier-version APIs are put in the CN=Users and CN=computers containers.”
“Some applications require specific security principals to be located in default containers like CN=Users or CN=Computers. Verify that your applications have such dependencies before you move them out of the CN=users and CN=computes containers.”
Recommendation: If these items can be re-directed, redirect them to a different OU and make sure proper OU security is set.
Check Tombstone Lifetime / AD Recycle Bin
If the Active Directory Recycle Bin is not enabled, enable it!
The following PowerShell code can be used to see what the current Tombstone Lifetime is:
Write-Output “Active Directory’s Tombstone Lifetime is set to $TombstoneLifetime days `r “
Note that no value returned means the tombstone lifetime setting is set to 60 days (default for AD forests installed with Windows 2003 or older).
Recommendation: If it is not set to 180 days, set it to 180 days. If the AD recycle bin is not enabled, enable it!
Check to see if Sysmon is installed on the Domain Controllers
Recommendation: If Sysmon is not installed, work on getting it installed and configured on the Domain Controllers at a bare minimum
Check Domain Controller Firewall Settings
This may require a conversation with your Information Security team to understand how the Firewalls are configured that sit in front of the Domain Controllers. You want to make sure the bare minimum number of ports are enabled for client traffic and that admin ports are only able to be accessed by admins.
Recommendation: Review security with Information Security Team, and enable the Windows Firewall on all Domain Controllers and manage it with Group Policy. This also acts as an East/West traffic block so if someone gets into one server on the prod network they don’t automatically have RDP access per say to another DC on the same network segment. Setup monitoring for any RDP sessions, successful ones, and failures (including firewall logs). This will verify anyone RDP’ing to the DCs is legit, and will also help track down threat actors on the network. One of the first things threat actors will try to do is see if they have RDP access to the Domain Controllers, this is good information to send to the SOC or InfoSec.
Check to see if RPC Ports are restricted
Recommendation: If RPC Ports have not been limited on the Domain Controllers, limit them to a few ports, say 100, or 1,000, and then make the associated changes to firewall rules.
Check Time Settings on the Domain Controller running PDC Emulator
Many people know that the clients that talk to the Domain Controllers have to have the correct time, but it is super important that you are pulling a correct time source for your Domain Controllers.
Recommendation: Make sure the Domain Controllers, more specifically the Domain Controller with the PDC FSMO role is pulling its time from a trusted source. It might also be worth writing a script to monitor this as well.
Verify FSMO Role Holder(s), Global Catalog Servers, & Backups
Verify who is running the FSMO roles for your Domain(s). Make all DCs a Global Catalog if you have a single-domain forest. Verify how AD is being backed up.
Recommendation: Depending on your specific situation you may not be able to run all FSMO roles on one DC. In my jobs I have been able to. This allows you to target this DC as the DC to be backed up, snapshotted, etc. If you are running a single-domain forest, make sure all DCs are a global catalog.
Check to see if there are any trusts configured for the domain.
Recommendation: If there are any trusts, figure out if they are still needed, and make sure there is documentation on why these trusts are setup and when they can be unconfigured.
Check Sites & Services for IP Configuration
Check AD Sites & Services for configuration of IP ranges. Make yourself familiar with how this setup and why it is setup the way it is.
Recommendation: Take notes on if Sites & Services is being used. If it is being used understand the network ranges and why it is configured the way it is. If priority is being given, understand why.