Credit where it is due, I got most of this from Jonathan Conway's blog post at https://jonconwayuk.wordpress.com/2022/08/11/intune-proactive-remediation-bitlocker-key-escrow-to-azure-ad-after-mecm-osd-task-sequence
Detection Script:
Credit where it is due, I got most of this from Jonathan Conway's blog post at https://jonconwayuk.wordpress.com/2022/08/11/intune-proactive-remediation-bitlocker-key-escrow-to-azure-ad-after-mecm-osd-task-sequence
Detection Script:
I have run across many "MFA" implementations that are only providing a false sense of security because they aren't actually MFA at all. After the most recent one, which had to do with income and financial documents I decided to write up a blog post so that I can share it with people to help them understand. Even though I am writing this to help people fix bad MFA implementation, hopefully at least a few readers will find this useful to set up MFA properly in the first place.
First, what is MFA? MFA stands for multi-factor authentication. The consensus is that there are only three possible factors that you can work with, so you MFA means that you MUST use at least two of these factors to access whatever it is that you are attempting to access. The three possible factors are:
If you have more than just a few boundary groups you have probably wanted a way to quickly set these options across all of them. I suggest setting the options for your VPN boundary group(s) first. For VPN you probably want to prefer cloud based sources and not use peer downloads at all (to prevent peering with internal computers). Once you have that set then you can run this little gem to set all of the others for what I believe is the best settings. Of course you can modify it if you think other settings are best.
Here you go:
<#
.Synopsis
Set SCCM Boundary Group Peer Cache options to Allow peer cache downloads within this Boundary Group but restrict downloads to peers within the same subnet.
.DESCRIPTION
Use this in order to quickly change the peer cache options for a set of boundary groups. The more boundary groups you have
in your organization, the more beneficial this becomes.
The flags (at time of writing) that you will see in the boundary groups are:
0 - Allow peer downloads in this boundary group (only first check box is checked)
1 - Do not allow peer downloads in this boundary group (no check boxes are checked)
2 - Allow peer downloads in this boundary group but During peer downloads only use peers within the same subnet (first two check boxes are checked)
9 - Prefer cloud based sources over on-premises sources and Do not allow peer downloads in this boundary group (only last check box is checked)
I have not experimented to find out what results come from other combinations of check-boxes.
#>
#Change testmode to false to save the changes
$testmode=$false
#The Configuration Manager site code
$sitecode="ABC"
#The Configuration Manager Primary Server
$SMSProvider="SCCMserver.domain.com"
#the flag you want to set
$newflag=2
$BoundaryGroups = (get-wmiobject -Namespace root\sms\site_$sitecode -Class SMS_BoundaryGroup -computername $SMSProvider) | Where-Object {($_.Flags -NE 2) -and ($_.Flags -le 2)}
Foreach ($BoundaryGroup in $BoundaryGroups) {
write-host "Setting $($BoundaryGroup.name) flags to $newflag (previously $($BoundaryGroup.flags))"
$BoundaryGroup.Flags = $newflag
Try {
If (-not $testmode) {
$result=$BoundaryGroup.Put()
write-host "saved" -ForegroundColor green
}
} Catch {
write-host "failed to set flag" -ForegroundColor red
}
}
There are four items that control network bandwidth utilization within SCCM:
Unfortunately I've not yet figured out how to export the schedule itself, but for everything else run an elevated Powershell and:
$outcsv = "C:\Users\$env:USERNAME\desktop\taskdef.csv"
Get-ScheduledTask |
ForEach-Object { [pscustomobject]@{
Name = $_.TaskName
Path = $_.TaskPath
User = $_.Principal.UserID
LastResult = $(($_ | Get-ScheduledTaskInfo).LastTaskResult)
NextRun = $(($_ | Get-ScheduledTaskInfo).NextRunTime)
Status = $_.State
Command = $_.Actions.execute
Arguments = $_.Actions.Arguments }} |
Export-Csv -Path $outcsv -NoTypeInformation
In order to pre-emptively identify computers that are not getting software updates you might want to know how long it has been since they last applied a Windows Update. Here you go:
$TimeNow = Get-Date
$LastSUInstall = ((Get-WmiObject -Class win32_quickfixengineering -Namespace root\cimv2).InstalledOn | sort -Descending)[0]
[Int]$OutputInt = ($TimeNow.Subtract($LastSUInstall)).Days
Write-Output $OutputInt
Let's try a thought experiment...
You are guarding the gate of a castle. That gate is the only way into the castle. In order to enter via the gate a password is required. When someone comes up to the gate, you challenge them, "PASSWORD!" and they respond either with the correct password or not. Based on their response you either allow them entry or you don't. The password to every royal estate is the same, so any noble-person that knows the password can enter every royal estate.
Some bandits got ahold of the password and began raiding the royal estates. In response the king changed the password and then in order to increase security even further he had his masons put a hole in the castle wall and install another gate. He placed another guard at the new gate and this guard was told to require a slip of paper, signed by the king, be presented to allow entry... a "certificate of entry". The certificate only works at the one castle/computer, unlike the password which the king uses at every one of his estates.
The king did not get rid of your gate, people can still enter using the (now changed) password but they can also enter through the other gate by presenting their certificate of entry.
Now... was the castle more secure when it only had one entry point or is it more secure now that it has two? Obviously one entry point is more secure than two, but the king is hoping that using the certificates of entry will keep the bandits from plundering his other holdings as well. If the bandits got ahold of a certificate of entry they can enter the castle and plunder it, but they cannot enter other royal estates. That's good, it is keeping the other estates secure.
So, soon the bandits did just that. They intercepted a nobleman, stole his certificate of entry into the castle. Once inside the castle, being smarter than the king had given them credit for, the bandits hid out near your gate and listened for the password. They then ran amock plundering all of the estates again AND stealing more certificates of entry to those other locations as well.
Just like the second gate at our imaginary castle, Windows Hello opens up a second gate to any computer upon which it is used. So, each and every one of those computers is less secure. Just like the certificate of entry to our castle once Windows Hello is breached it can be reused to access that computer.
Now, unlike our imaginary castle, Windows Hello actually presents two gates itself; the PIN, or click-on-pic, or biometric that is used for the user interface and the certificate that is actually passed from the computer to the network. This allows for two distinct avenues of attack. If an attacker gets that certificate then they can replay it infinitely (because you cannot change it as the user) to access the network from that computer (not from just any computer, but who cares at that point). The attacker could obviously get ahold of the PIN or Click-On-Pic combination just like normal shoulder surfing for passwords. But the scariest of all is if the attacker subverts the biometrics. Good luck changing your fingerprints or IR signature should an attacker be able to duplicate them.
Your password can always be used as a back up to Windows Hello. So, Windows Hello is really just opening another hole in the wall. If the attacker does get inside through Windows Hello, it is much easier to get the password from the inside than it is from outside. Your password is stored (encrypted) on the device even if you are using Windows Hello and there is also a high probability that you will need to provide your password at some other gate and it can be intercepted when you do so.
That, my friends, is why using Windows Hello is less secure than not using Windows Hello.