Group Policy
GPO notes are incomplete. Check the Module 11 slides. GPOs or Group Policy Objects are files that specify settings
Precedence, inheritance, filtering
Remember LSDOU. First Local GPOs are applied, then GPOs linked to a Site, then to the Domain, then to parent OUs, then to child OUs.
If two GPOs change a setting, the last one to run wins. For example, if you have a GPO linked to the domain saying “hide the Restart option” and another one saying “Show the Restart option”, the last GPO to flip that switch wins.
Block Inheritance
- is set on containers
- keeps policies from higher sites/domains/OUs from being applied to objects in this OU
Enforce
- is set on GPOs
- overrides ‘Block Inheritance’
- makes the GPO run last
GPOs cannot be linked directly to a group, computer account, or user account. However, you can link a GPO to an OU and then use security filtering to deny certain groups the Apply Group Policy permission. By default, security filtering is set to the Authenticated Users group.
Security filtering lets you set the GPO to only apply to a certain user, computer, or group. LSDOU and the rules of inheritance still apply.
WMI filtering lets you limit where a GPO is applied based on hardware characteristics (does the computer have Windows 8 installed, is it a laptop, does it have a 64 bit processor, etc).
Software installation
There’s three possible ways to deploy software with Group Policy.
- Published: the user has open Programs and Features, then find and manually choose to install the published app.
- Assigned in User Configuration: adds a link to the software in the Start Menu. The app is installed when a user clicks that link or double-clicks a file that app opens by default.
- Assigned in Computer Configuration: the app is installed the next time the computer reboots.
Because a computer has no way of knowing what users will log in later, it can’t automatically install software assigned in User Config. It has to wait until the user logs in and tries to use the app.
Certificates
Symmetric encryption uses the same key to encrypt data and decrypt it. It’s fast, easy, and fairly simple.
Asymmetric encryption uses two related keys called a public and private key. Anything encrypted with one key can be decrypted with the other. The downside of asymmetric encryption is that it’s slower and more complicated.
A certificate is a combination of a public key and a digital signature.
Certificate Authorities and PKI
Public Key Infrastructure is a generic term for everything you need to be able to use asymmetric encryption on a large scale. You need a way to share public keys, a way to sign those keys, and a root of trust.
Certificate Authorities are the root of trust in PKI. In order to be able to trust that you’re not being lied to or MITMed, you need a trusted public key already on your hard drive that you can use to verify everything else. You can’t just grab a root certificate over the Internet because someone might be intercepting that traffic and handing you a fake certificate. This problem is called Key Exchange and is the reason we use asymmetric encryption even though symmetric is technically better.
A certificate authority generates a public/private key pair that will be the root of trust for everything else they do. This key pair has to be kept perfectly secure or the entire security model doesn’t work.
They then use that private key to sign the certificate of a second “intermediary” public/private key pair that they will use to sign all other certificates they generate.
With that done, the CA will give the public key to companies like Microsoft to bake into the Windows installer and put the private key in offline cold storage hoping they’ll never need to use it again.
When you go to microsoft.com, the first thing you get is a signed certificate from the web server hosting microsoft.com. That certificate contains information saying “I’ve been signed by Microsoft Azure RSA TLS Issuing CA”. That certificate then says “I’ve been signed by DigiCert Global Root G2”.
That DigiCert Global Root G2 certificate was included in the Windows ISO someone used to install Windows. Because it’s already on your hard drive, you can use it to verify the identity of a server you’re talking to over the Internet.
For this to work, DigiCert has to verify that Microsoft really does own microsoft.com before giving them a certificate that says “I’m microsoft.com”.
Key revocation
I won’t get into the technical details but basically a certificate higher in the chain of trust can invalidate or “revoke” a certificate below it. A company might do this if they think the private key for that certificate has been stolen by a hacker.
The reason the CA in the earlier example generated an intermediary key pair is so they can easily invalidate it and publish a new intermediary key pair if it’s ever compromised.
If they used their root key to sign requests, and that key was stolen, they would have to start from scratch and go through the extremely expensive process of having a new root certificate pushed out to every PC that needs it.