I found a service account last month with a password set in 2016. It ran SQL, it had a service principal name registered, and its password was set to never expire. Someone even helpfully wrote the password in a OneNote called "IT Passwords." That account is a loaded gun pointed at the whole domain, and the fix has been sitting in Active Directory for over a decade. Group Managed Service Accounts kill this problem for good.
If you're hardening AD and you already audited who's in Domain Admins, this is the next box to check. Your service accounts are probably worse.
Why an old service account password is a gift to attackers
Any service account with a registered SPN is kerberoastable. Here's the short version of the problem. Any domain user, even a low-privilege one, can request a Kerberos service ticket for that account. The ticket comes back encrypted with the account's password hash. The attacker takes it offline and brute-forces it at their leisure, with no lockout and no alarm.
A short or old or reused password falls in minutes. And once they crack it, they own whatever that service could touch, which for a SQL account is usually a lot. Microsoft's own guidance for stopping kerberoasting says it plainly. Replace the user account with a Group Managed Service Account.
What Group Managed Service Accounts actually do
A gMSA is a domain account where Active Directory owns the password, not you. When you point a service at one, the operating system takes over credential management completely.
The password is 240 bytes of random. No human picks it, and no human ever sees it. It never lands in a OneNote.
It rotates every 30 days on its own. Active Directory changes it automatically, and the member servers pull the new one. Nobody schedules a change or plans an outage.
It works across a server farm. That's the "group" part. Multiple hosts behind a load balancer can share one gMSA identity.
It manages the SPN for you. You set the service principal name when you create the account, and Kerberos just works.
Now run the kerberoasting math again. An attacker can still request that ticket. But a 240-byte random password that rotates every 30 days is not getting cracked offline before it changes again. You didnt hide the account. The loot is just worthless now.
First, find your kerberoastable accounts
You cant fix what you havent found. Start by listing every user account that has an SPN, because those are the roastable ones.
Look at that PasswordLastSet column and prepare to wince. If you run Microsoft Defender for Identity, its Service accounts inventory finds these for you, flags the ones with a password set to never expire, and separates real gMSAs from plain user accounts pretending to be service accounts.
Defender for Identity inventories your service accounts and flags the risky ones. Source: Microsoft Learn.
Setting up a gMSA, step by step
You need a 2012 or later domain functional level, a host running 2012 or later, and the AD PowerShell module. From there its four moves.
Create the KDS root key, once per forest
The Key Distribution Service root key is what AD uses to generate gMSA passwords. You only make it once for the whole forest.
Add-KdsRootKey -EffectiveImmediately
In production that key needs about 10 hours to replicate before it works, so create it early and go do something else. In a lab, there's a flag to make it effective right away, but dont use that shortcut in prod.
Create a group for the hosts
Make a security group and add the computer accounts that are allowed to use the gMSA. Then create the account and point it at that group.
Test should return True. If it doesnt, check that the host is in the group and that the group membership has replicated.
Point the service at it
In the service's Log On settings, enter the account as CONTOSO\svc-sql$ and leave the password blank. That trailing dollar sign matters. Start the service and you're done. You will never type that password, because it doesnt have one you could type.
Before you go all in
A few honest limits, because gMSA isnt a fit for absolutely everything.
Not every app supports it. SQL Server, IIS application pools, and scheduled tasks on modern Windows are fine. Failover clustering isnt, and some third-party apps arent. Test before you commit.
You cant interactively log on with one. A gMSA runs services, it doesnt sit at a desktop.
Mind the 10-hour KDS wait. Plan the root key ahead of your first real deployment so you're not stuck waiting.
Dont put service accounts in Protected Users. That group breaks them. Use a gMSA for the service and Protected Users for your human admins.
Putting it together
Find your SPN user accounts, then replace the important ones with Group Managed Service Accounts. Create the KDS root key once, make a group for the hosts, create the account with New-ADServiceAccount, install and test it on the servers, and repoint the service with a blank password. Active Directory handles a 240-byte password that rotates every month, and the kerberoasting attack that owned your old account just stops working. Start with your SQL accounts, since those are usually the fattest target.
What can we learn as a person
The 2016 password is the thing I cant stop thinking about. It made sense the day someone set it. Then the world kept moving and it never changed, and the exact thing that was supposed to protect the account slowly turned into the easiest way in.
I have passwords like that. Rules I set for myself in a hard year that made total sense then, and I never rotated them. A way of protecting myself that fit who I was at the time, kept unchanged so long that it quietly became the vulnerability instead of the defense. The genius of a gMSA isnt that the password is strong. It's that it never stops changing, so no single old version of it can be used against me forever.
So whats your 2016 password? What defense did you set once, a long time ago, that you've never once rotated since?
A pentest report crossed my desk where the whole domain fell in about twenty minutes. No cracked domain admin password, no phishing, no malware. The attacker asked a forgotten certificate server for a certificate that said "I am the domain admin," and the server politely handed it over. Thats the quiet reality of AD CS attacks. Your certificate authority is a domain admin factory, and almost nobody audits it.
Maybe you've hardened your tier model and locked down who's in Domain Admins. If you never looked at Active Directory Certificate Services, you left the back door wide open.
Why a certificate is as good as a password
Certificates authenticate. A certificate that identifies you as a domain admin logs in exactly like the real one. Worse, it doesnt care if you reset the password afterward. The certificate stays valid until it expires, which might be a year or more.
So a single misconfigured template or CA is enough. An unprivileged user can request a certificate for a privileged account and quietly become them. Security researchers cataloged these escalation paths as ESC1 through ESC8. They sit at Tier 0, right next to your domain controllers, and they rarely get a second look.
The template misconfigs: ESC1 through ESC4
Most AD CS attacks start with a certificate template that trusts the wrong people or asks too few questions.
ESC1, a template lets the enrollee supply their own subject, has a client authentication EKU, and allows unprivileged users to enroll. Any user can request a cert as anyone, including a domain admin. The "Supply in the request" setting is the single most common cause.
ESC2, a template has the Any Purpose EKU or no EKU at all, so an issued cert can be used for almost anything an attacker wants.
ESC3, a template grants the Certificate Request Agent EKU, letting a holder enroll on behalf of other users.
ESC4, the template object's own ACL or owner is weak, so an unprivileged user can rewrite the template into an ESC1 whenever they feel like it.
Defender for Identity flags the ESC1 template misconfiguration. Source: Microsoft Learn.
The fixes rhyme across all four. Turn off "Supply in the request." Strip authentication EKUs from templates that dont need them. Remove enroll rights from groups like Authenticated Users and Everyone. Require CA manager approval. And unpublish any template you dont actually use, because a template nobody can request cant be abused.
The CA and endpoint misconfigs: ESC5 through ESC8
The second half moves from templates to the certificate authority itself and how people reach it.
ESC5, someone has control over the CA's own AD objects, like the CA computer account or the PKI containers in the configuration partition. Control those and you control the whole PKI.
ESC6, the CA has the EDITF_ATTRIBUTESUBJECTALTNAME2 flag turned on, which lets any request specify its own subject alternative name no matter how the template is configured.
ESC7, an unprivileged user holds Manage CA or Manage Certificates rights, so they can approve their own requests or flip on the ESC6 flag themselves.
ESC8, the web enrollment endpoint accepts NTLM over plain HTTP, so an attacker can relay a domain controller's authentication and get a certificate as that DC.
Defender for Identity flags the ESC7 CA ACL misconfiguration. Source: Microsoft Learn.
Remediation here is mostly about access and flags. Pull Manage CA and Manage Certificates rights back to a small, trusted group. Turn off the SAN flag with certutil -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2 and restart the service. And if you dont use web enrollment, disable it. If you do, enforce HTTPS and Extended Protection for Authentication so relays fail.
How to actually audit AD CS attacks
You dont have to check every template by hand. Three approaches cover it.
Microsoft Defender for Identity. If you have it, the security posture assessments flag ESC1, ESC2, ESC3, ESC4, ESC6, ESC7, ESC8, and more in Secure Score, with a remediation path for each. Certificate authority checks need a sensor on the AD CS server.
Community auditors. Defensive PowerShell tools like Locksmith and PSPKIAudit scan your PKI and report the same misconfigurations in plain language, no license required.
By hand. Open the Certificate Templates console (certtmpl.msc), check each template's enrollment permissions and the "Supply in the request" flag, and run certutil -getreg policy\EditFlags on the CA to check for the SAN flag.
The AD CS security posture assessments in Microsoft Secure Score. Source: Microsoft Learn.
Whatever you use, run it now. Most of these misconfigs have been sitting in environments for years. Whoever stood up the CA clicked through the template wizard and never came back.
Putting it together
AD CS attacks all cash out the same way. A misconfigured template or CA lets an unprivileged user mint a certificate for a privileged account. That certificate is a login that survives password resets. Audit your templates for "Supply in the request" and loose enrollment rights, pull dangerous rights off the CA, kill the SAN flag, and lock down web enrollment. Treat your certificate authority like the Tier 0 asset it is, because an attacker already does.
What can we learn as a person
What gets me about this whole class of problem is that the front door was fine. Strong domain admin passwords, MFA, the works. The domain fell through a system nobody thought to look at, because it had been quietly issuing trust the entire time.
I have systems like that in myself. I guard the obvious doors, the big reactions, the habits I know are watching me. Meanwhile some old belief I set up years ago keeps handing out certificates in the background. It tells every new situation "this is who you are," and I never audit it. And like a certificate, it survives the resets. I can change the behavior on the surface and that old thing keeps authenticating as me anyway, because I never revoked it at the source.
So whats your AD CS? What quiet system in you has been issuing trust on your behalf for years, that you've never once stopped to audit?
Ordered a new laptop for a remote hire last month. Dell shipped it straight to her apartment. She opened the box, connected to Wi-Fi, and signed in. I never touched the machine. Nobody on my team ever touched the machine. That whole flow is Intune zero touch deployment, and its worth actually explaining how it works instead of just saying "Autopilot handles it."
What Intune zero touch deployment actually means
Zero touch deployment means nobody in IT ever physically handles the device. No imaging. No unboxing at the office. The manufacturer ships it directly to wherever it needs to go, often straight to the employee's house. Windows Autopilot makes this possible, but Autopilot alone isnt the whole story. The real trick is getting the device pre registered before it ever leaves the warehouse.
The hardware hash is the whole trick
Every Windows device generates a hardware hash, a fingerprint built from its manufacturer, model, and serial number. Intune needs that hash registered to your tenant before Autopilot can recognize the device. Normally someone has to boot the machine and run a PowerShell script to grab it.
OEM registration skips that step entirely. Dell, HP, Lenovo, and most major manufacturers generate the hash at the factory. They register it directly with Microsoft on your behalf, before the box ever ships. Thats the actual mechanism behind zero touch deployment. The hash exists before the device does.
How OEM registration and manual registration both feed into Windows Autopilot. Source: Microsoft Learn.
Setting up drop shipping with Dell
Before Dell can register a single device for you, someone at Dell needs your permission. This step trips people up more than anything else in the whole process.
Granting Dell authorization
Dell emails a unique authorization link to your organization. A Global Administrator signs into the Microsoft 365 admin center using a cloud native account, something like yourcompany.onmicrosoft.com. That admin opens the link, checks a consent box, and selects Accept. Authorization happens instantly once they do.
Accepting the authorization request from an OEM like Dell. Source: Microsoft Learn.
Notice this requires Global Administrator, not just an Intune admin role. Thats a genuinely high privileged role, so dont hand this task to just anyone. Also worth knowing, once you authorize an OEM this way, you cant remove them yourself later. Revoking access means emailing Microsoft's support alias directly.
What happens after authorization
Once authorized, Dell registers every device you order automatically. No CSV files. No PowerShell scripts. No IT person unboxing anything first. The hash gets written to Microsoft's Autopilot database and tied to your tenant, all before the device ships. Dell never gets access to your actual tenant, they're only writing to Microsoft's registration database on your behalf.
What still needs setting up on your end
Registration only gets the device recognized. You still need a deployment profile assigned to whatever group that device lands in, defining things like deployment mode and whether the Enrollment Status Page blocks device use until apps finish installing. Ive covered building that profile in detail elsewhere, so I wont repeat all of it here. Just know registration and the profile are two separate steps, and skipping the profile means the device boots to a normal, unmanaged Windows setup instead of your branded OOBE.
The actual drop ship workflow
Authorize Dell once, using a Global Administrator account
Build your Autopilot deployment profile and Enrollment Status Page ahead of time
Order the laptop through Dell, specifying your tenant during the order
Dell registers the hash and ships straight to the new hire's address
The employee opens the box, connects to Wi-Fi, and signs in
Windows Autopilot takes over from there, joining Entra ID and enrolling in Intune automatically
Nobody on your team touches a single cable in that entire sequence.
Gotchas worth knowing before you rely on this
Confirm your reseller or Dell account rep actually supports OEM registration for your specific device line, not every SKU qualifies
Double check the tenant ID gets attached correctly at order time, a wrong tenant ID means the device registers somewhere other than your organization
Build and test your deployment profile before the first real shipment goes out, dont let a new hire be your test case
Remember you cant self service remove OEM authorization later, so get the right admin to grant it in the first place
Putting it together
Intune zero touch deployment is really two things stacked together. Dell registers the hardware hash before the device ships, and your Autopilot deployment profile tells that device what to do the moment it powers on. Get the authorization done once, get your profile built and tested, and every laptop after that ships straight to whoever needs it without IT ever unboxing a single machine.
What can we learn as a person
What gets me about OEM authorization is that you're trusting a company you'll never actually talk to with a piece of your process. Some person at Dell you'll never meet handles a step that used to require your own hands on the keyboard. And once you grant that trust, you cant even take it back yourself, you have to ask Microsoft to do it for you.
Honestly, a lot of life runs the same way. We hand pieces of our process to people we'll never meet, a pharmacist filling a prescription, an engineer who built the bridge we drive over, a stranger raising our kid's classmate. We dont personally verify most of it. We just trust the registration happened correctly somewhere upstream.
What's a piece of your life running on trust you never actually verified? And has it been working out fine anyway?
I used to work in an environment where the help desk admin spent half their day resetting passwords twice. Once in Active Directory, and then again in Office 365. If they forgot the second reset, the user could not sign in to their email, and the phone would ring. It was a miserable, repetitive cycle that drove everyone crazy. We eventually installed Microsoft Entra Connect to sync the directories, and the help desk team almost cried tears of joy.
Ok, so here is the deal with Microsoft Entra Connect. It is the sync engine that bridges your on-premises Active Directory with Microsoft Entra ID. Today we will build a simple setup guide. We will walk through how to install it, configure permissions, enable writeback, and harden the server so bad actors cannot compromise your domain.
The Microsoft Entra Connect installation welcome screen. Source: Microsoft Learn.
A simple setup guide for Microsoft Entra Connect
To start, download the latest version of the installer from the Microsoft Entra admin center. Before you double-click the file, make sure your server runs TLS 1.2. Microsoft enforces TLS 1.2 for all sync connections now, and the installation will fail if you do not enable this protocol on the server first.
Once you verify your server meets the prerequisites, run the installer:
Accept the license terms on the welcome screen.
Choose the Use express settings option. Express settings configure password hash synchronization by default, which works perfectly for a single Active Directory forest.
Enter your Entra tenant credentials. You must use an account with the Hybrid Identity Administrator or Global Administrator role.
Enter your on-premises Active Directory Enterprise Admin credentials. The installer needs this level of access to create the dedicated sync account in your domain.
Review the configuration on the ready screen, check the box to start synchronization, and click Install.
Select Express settings to automate the setup process. Source: Microsoft Learn.
Minimum permissions for the Entra Connect user
During the express installation, the wizard automatically creates a user account starting with MSOL_ in your on-premises Active Directory. Microsoft configures this account with the exact permissions needed to read your directory. If you want to use custom settings or pre-create this account, you must configure the permissions yourself.
The sync account needs these minimum permissions at the root of your domain directory:
Replicating Directory Changes. This permission allows the sync service to read changes from your Active Directory domain.
Replicating Directory Changes All. The service account needs this permission to sync password hashes from your domain controllers.
If you enable writeback features later, you must grant write permissions to this account. For example, password writeback requires the account to have Reset Password, Change Password, and Write permissions on the lockoutTime and pwdLastSet attributes for all user objects in your sync scope. You can read the official Microsoft Entra Connect permission guide on Microsoft Learn to see the full list of attribute requirements.
Hardening the Entra Connect server and user access
Microsoft Entra Connect holds the keys to your entire hybrid identity kingdom. If an attacker compromises this server, they can sync malicious changes to the cloud or extract password hashes from your on-premises domain. Hardening this server is not optional.
First, install Entra Connect on a dedicated member server. You must never install this software on a Domain Controller. Installing it on a member server reduces the attack surface and prevents easy privilege escalation if someone gains local admin access to the sync box.
Second, restrict local administrative access. Only allow trusted domain administrators to log in to the sync server. The installer creates a local group called ADSyncAdmins on the server. Make sure you only place authorized users in this group, as anyone in it can modify the synchronization rules and configurations.
Third, secure the synchronization user account. The MSOL_ account does not need domain administrator rights. Do not add this account to the Domain Admins or Enterprise Admins groups. Microsoft restricts access to the sync credentials by default, but you should also monitor the account logs for any unexpected sign-in attempts. You can learn more about securing these configurations in the Microsoft Entra Connect sync hardening guide on Microsoft Learn.
Enabling writeback features
A simple setup guide usually stops at one-way synchronization, where changes only flow from AD to the cloud. But you will want to enable writeback features to make the system truly useful. The most popular option is Password Writeback, which works with Self-Service Password Reset.
To enable Password Writeback:
Launch the Microsoft Entra Connect wizard from your server desktop.
Click Configure and select Customize synchronization options.
Enter your Hybrid Identity Administrator credentials to authenticate.
Proceed through the screens to the Optional Features page.
Check the box for Password writeback and click Next to apply the change.
You must enter your hybrid administrator credentials in the wizard to configure writeback. Source: Microsoft Learn.
Once you turn on this setting in the wizard, go to the Microsoft Entra admin center. Navigate to Protection, click Password reset, and select On-premises integration. Make sure you enable the option to write back passwords to your on-premises directory. This setup allows users to reset their own passwords in Microsoft 365, and the service will update their Active Directory password in real time.
What can we learn as a person
Managing a network without synchronization is exhausting. You push changes to one database, then copy them manually to another, hoping the two systems stay in alignment. If you do not set up writeback, information only flows one way, and the cloud never talks back to your local server. Honestly, our personal lives run into the same problem when we isolate ourselves. We try to handle every project, stress, and anxiety in our own heads without letting anyone else in. Operating in a one-way sync means you carry the entire load alone, and eventually, the systems fall out of alignment.
But the thing is, we need writeback. We must escrow our keys. A few trusted relationships can act as our on-premises integration, allowing support to flow back into our lives when the pressure builds up in our heads. Trying to run everything yourself only leads to a crash. Who acts as your writeback connection? Which person do you allow to push support and feedback back into your life when things get heavy?
I once had a user call me at 8:00 AM on a Monday in a complete panic. Their screen was bright blue, asking for a 48-digit number they did not know. That was my introduction to the joy of troubleshooting BitLocker keys. They did not have the key. I did not have the key yet. We had to spend an hour digging through old documentation to find the key. It turned out the previous admin wrote it on a sticky note and stuck it under a keyboard in the server closet. Not ideal.
Ok, so here is the deal with BitLocker. If you do not know where your recovery keys are, you do not actually have a backup. We must store those keys in a safe place so we can access them when a user locks themselves out. First, we will look at where the keys live in Active Directory, Microsoft Entra ID, and Intune. Then we will configure the policies to back up the keys automatically.
The dreaded BitLocker recovery screen. Source: Microsoft Learn.
Where to find BitLocker keys
If a machine locks a user out, you need to find the key fast. Depending on how you enrolled and encrypted the device, you can find the key in one of three places. Let's look at how to grab them.
Finding keys in Microsoft Intune
If you manage your devices with Intune, this is the easiest place to look. You need the right permissions, like Help Desk Operator or Endpoint Security Administrator. If your role does not have the Rotate BitLockerKeys permission, you wont see them. You can check the official Intune encryption docs on Microsoft Learn to verify the required roles.
To find the key in the admin center:
Go to the Microsoft Intune admin center.
Select Devices, then click All devices.
Find and click on the locked-out device.
Look under the Monitor section on the left menu and click Recovery keys.
Review the list of key IDs and click Show Recovery Key to view the actual 48-digit key.
You can also rotate the BitLocker keys directly from the device action menu. Source: Microsoft Learn.
Intune also offers a self-service option. If your users lock themselves out and you do not want them calling the help desk, they can go to the Company Portal website at portal.manage.microsoft.com. Once they sign in, they can select their device and click Get recovery key to retrieve it. This saves a lot of time when dealing with remote users in different time zones.
Finding keys in Microsoft Entra ID
Sometimes you join a device to Entra ID without managing it in Intune. Other times, you might just prefer the Entra portal. Entra ID stores the keys directly on the device object.
Here is how to find them in the Entra portal:
Open the Microsoft Entra admin center.
Navigate to Identity, then Devices, and click All devices.
Search for your device and click on its name.
Look for the BitLocker keys link under the general properties section.
Click the link to view the list of keys and copy the 48-digit recovery password.
Finding keys in Active Directory
Classic domain-joined computers send their keys to your local Active Directory domain controllers. You cannot see them out of the box, however. You must install a special administrative tool to view the keys.
First, make sure you have the BitLocker Recovery Password Viewer installed. It belongs to the Remote Server Administration Tools, which we call RSAT. You can read the Microsoft Learn recovery process guide to see how to install it. On Windows 10 or 11, you go to Settings, then Apps, then Optional features, search for RSAT BitLocker Drive Encryption Administration Utilities, and install it.
Once you install the tool:
Open Active Directory Users and Computers. We call this ADUC.
Find the computer object for the locked machine.
Right-click the computer and select Properties.
Click the BitLocker Recovery tab. If you do not see this tab, you probably forgot to install the RSAT utility, or you lack the required permissions because Microsoft restricts key access to Domain Admins by default.
Review the recovery passwords list, which shows the Backup Date and Password ID for each key.
How to setup BitLocker backups in Entra ID and Intune
Now that we know how to find the keys, let's talk about how to configure automatic backups. If you do not configure your policies to back up the keys, Windows will encrypt the drive but will not save the key anywhere. This is a disaster waiting to happen.
In Intune, you should use the Endpoint Security disk encryption policy for this configuration. It is much cleaner than the old Device Configuration profiles. Microsoft explains this setup in their Intune BitLocker policy guide on Microsoft Learn.
Go to the Microsoft Intune admin center.
Select **Endpoint security**, then click **Disk encryption**.
Click **Create Policy** and select **Windows 10 and later** as the platform and **BitLocker** as the profile type.
Select the BitLocker profile under Endpoint Security. Source: Microsoft Learn.
In the configuration settings, you want to focus on these critical knobs:
Set **Base Settings > Enable BitLocker** to **Yes**.
Configure the encryption settings under **BitLocker - OS Drive Settings**. If you want silent encryption, set **Compatible TPM Startup** to **Required** and set **Compatible TPM Startup PIN** to **Blocked**. This configuration ensures that the user does not see prompts or need to click buttons during setup.
Turn on **Save BitLocker recovery information to Microsoft Entra ID** by setting it to **Enabled**.
Set **Require device to back up recovery information to Microsoft Entra ID** to **Yes**. This is the most important switch. It prevents Windows from encrypting the drive if it cannot write the key to Entra ID first. If a user is offline, Windows waits for an internet connection and a successful backup before starting the encryption.
Make sure you require the backup to succeed before encryption begins. Source: Microsoft Learn.
How to setup BitLocker backups in Active Directory
For domain-joined environments without Intune, you must use Group Policy. The concept matches the Intune setup, but the menus look different. You can read more about how Active Directory handles this on the Microsoft Learn BitLocker recovery overview.
Open your Group Policy Management Console and edit or create a GPO that applies to your computers. Navigate to this path:
Double-click **Store BitLocker recovery information in Active Directory Domain Services** under the main BitLocker folder and set it to **Enabled**. Check the boxes to store both recovery passwords and key packages.
Navigate to the **Operating System Drives** subfolder.
Double-click **Choose how BitLocker-protected operating system drives can be recovered** and set it to **Enabled**.
Check the box to **Save BitLocker recovery information to AD DS for operating system drives**.
Check the setting that prevents BitLocker from enabling until Active Directory successfully stores the recovery information. If you do not check this, a machine might encrypt itself before it establishes a connection to the domain controller, which will cause you to lose the key.
Once the GPOs apply, domain computers will automatically push new recovery keys to Active Directory. If you already encrypted existing machines before deploying this policy, they will not push their keys automatically. You must run a script on those devices using a tool like PDQ Deploy or a startup script that runs a manage-bde command to force the backup. The command to run is manage-bde -protectors -backup c: -id {your-key-id} to push the key up.
What can we learn as a person
As sysadmins, we spend a lot of time building secure systems. We wrap everything in encryption, hide things behind firewalls, and lock down access. Doing this protects our servers and data from trouble. Honestly, we do the same thing in our personal lives. We encrypt our thoughts, secrets, or struggles to keep them completely to ourselves. This is a good self-defense mechanism. Not everyone deserves access to the inner workings of our brain, and keeping some boundaries is actually healthy for our mental health.
But the thing is, if you encrypt a drive and never back up the key, you are one bad boot away from losing everything. If you lock your thoughts and feelings down so tight that nobody has a copy of the key, what happens when you hit a crisis? What happens when you crash? You lock yourself inside your own head, and nobody can help you get out. We must escrow our keys. A few trusted people in our lives can act as our personal domain admins, holding the recovery keys for when we hit a wall. Who holds your recovery keys? Who do you trust enough to share the things you keep locked away?
We use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it.
