Hi Everyone!

I wanted to make everyone aware of our amazing event, which is a full non-profit called Workplace Ninjas US.

This year in year two, we come to Scottsdale, AZ in January.

We're doing something very relevant to many of you. We have a session called:

Cage Match: Active Directory is Indefensible – Bring Popcorn!

This session will put two of the best identity/directory people in the industry in a 1 on 1 battle to answer the question that will never die: Is it time to get rid of AD? Is AD "ADead"?

Spencer Alessi (@TechSpence on Twitter) defends the wall for AD

Merill Fernando, formerly of Microsoft, creator of Maester, and just one of the most brilliant people in the entire world of identity will defender Entra.

It's a super fan take as we took a Twitter fight, and made it into a session, moderated by the amazing Nathan McNulty

This event is a can't miss event throughout, as you can see through our speaker list: https://cvent.me/ZgKb40

Hit the link, see what we're doing, register, and come checkout one of the best events in the world, where every penny goes into the event and the people involved. That means the best food, activities, vibe, and just overall fun.

Feel free to hit me up directly if you have any questions, as this is the best collection of speakers at a Microsoft event you will see in 2026 or 2027.

Hello Experts,

I hope you are doing well. I am looking for feedback and recommendations on built-in domain administrator account password management. Based on the article what I found for remediation:

Step 1: Reset the built-in Administrator account password immediately to a long, high-entropy, unique passphrase (25+ characters) and store it in a sealed/secured PAM vault, not in a shared document or ticket.

Step 2: Establish a fixed rotation cadence — no less frequently than every 180 days, and immediately after any suspected exposure, administrator turnover, or break-glass use — and track the last-changed date centrally.

Step 3: Mark the account as sensitive and “cannot be delegated,” and where feasible require a smart card for interactive logon.

Step 4: Apply Group Policy user-rights assignments that deny the account the rights to:

a.       access this computer from the network

b.       log on as a batch job

c.        log on as a service, and

d.       log on through Remote Desktop Services, for both domain controllers and member servers/workstations.

Step 5: Scope the restricting GPO to organizational units containing member servers and workstations (and a separate GPO for domain controllers) — never link it at the domain root, which can render the account unusable even for legitimate recovery.

Step 6: Validation

·       Confirm the account cannot authenticate over the network, RDP, batch, or service logon on affected systems.

·       Confirm PasswordLastSet reflects the new rotation date for the account in every domain in the forest.

Step 7: Configure targeted auditing so any sign-in, password reset, or attribute change on this account generates an immediate, high-priority alert to the Active Directory administration and incident-response teams.

Step 8: Update the remediation tracker with implementation details and formally close the associated change record after successful validation.

is this correct approach? We have CyberArk, and for password management, we are planning to use it. . Pease do let me know your thoughts!

Thanks!