RODC Trick: Remove a User’s Password from a RODC without forcing the user to change her password

TechNet (RODC FAQ) states:

How can you clear a password that is cached on an RODC?

There is no mechanism to erase passwords after they are cached on an RODC. If you want to clear a password that is stored on an RODC, an administrator should reset the password in the hub site. This way, the password that is cached in the branch will no longer be valid for accessing any resources in the hub site or other branches. In the branch that contains the RODC on which the password may have been compromised, the password will still be valid for authentication purposes until the next replication cycle, at which time its value that is stored on the RODC will be changed to Null. The new password will be cached only after the user authenticates with it—or the new password is prepopulated on the RODC—and if the PRP has not been changed.

In the event that an RODC is compromised, you should reset the passwords for all accounts that have cached passwords and then rebuild the RODC.

I disagree.
There is a way to do this. It may not be the officially “supported method”, but there definitely is a way to remove a user’s password from a RODC.

Why would you want to do this? Say that an executive travels to a field site and an admin adds her account to the RODC Password Allow group. This means the executive’s password is cached on the RODC at that site upon successful logon. You realize that the RODC has stored the executive’s password (oops!) and you have the same security concerns about the site that led you to only deploy a RODC there. You want to wipe the password from the RODC, but don’t want the executive to have to change her password. What to do?

Check the RODC computer object and see that the executive (Jane Executive in this example) shows up in the list of security principals with their passwords stored on the RODC (msDS-RevealedList).

The LDAP Modify Operation “RODCPurgeAccount” causes the RODC to NULL the cached secrets of a specified security principal (User or Computer).

Here’s a (likely unsupported) way to do it.

Open LDP on a writable DC and connect to the RODC on port 389 (LDAP) or 636 (LDAPS). Bind to the server (ensure you have Domain Admin credentials). Select Modify (operation) from the drop down and set the following:

DN: [blank]
Edit Entry Attribute: RODCPurgeAccount
Values: CN=Jane Executive,OU=Executives,DC=metcorp,DC=org [Account DN]
Click Replace
Click Enter
Click Run.

You should see the Modify is Successful.

Check the RODC computer object and see that the executive (Jane Executive in this example) is NOT in the list of security principals with their passwords stored on the RODC.

Security concern: the executive’s password was stored on the RODC during some period of time which means it was committed to the AD database (in memory & on disk). The correct way to ensure the executive’s password is not available is to have her change it (when WAS the last time she changed her password?) since this will invalidate any cached passwords floating around the network.

Authentication Problems in an Environment with Windows Server 2003 and Windows Server 2012 R2 Domain Controllers

Why this happens:

The Kerberos client depends on a “salt” from the KDC in order to create the AES keys on the client side. These AES keys are used to hash the password that the user enters on the client, and protect it in transit over the wire so that it can’t be intercepted and decrypted. The “salt” refers to information that is fed into the algorithm used to generate the keys, so that the KDC is able to verify the password hash and issue tickets to the user.

When a Windows 2012 R2 DC is promoted in an environment where Windows 2003 DCs are present, there is a mismatch in the encryption types that are supported on the KDCs and used for salting. Windows Server 2003 DCs do not support AES and Windows Server 2012 R2 DCs don’t support DES for salting.

You might be wondering why these encryption types matter.  As computer hardware gets more powerful, older encryption methods become easier and easier to break.  Thus, we are constantly incorporating newer, more powerful encryption into Windows and Kerberos in order to help protect your user passwords (and your data and your network).

http://blogs.technet.com/b/askds/archive/2014/07/23/it-turns-out-that-weird-things-can-happen-when-you-mix-windows-server-2003-and-windows-server-2012-r2-domain-controllers.aspx

PowerShell: Get all Active Directory Sites based on Domain

Get all Active Directory Sites based on Domain.

 

$DomainSiteFilter = “DomainA”
Write-Output “Get AD Site List `r”
$ADSites = [System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest().Sites
[int]$ADSitesCount = $ADSites.Count
Write-Output “There are $ADSitesCount AD Sites in the forest `r”
$DomainADSites = $ADSites | where {$_.Domains -like “*$DomainSiteFilter*”} | sort-object name
[int]$DomainADSitesCount = $DomainADSites.Count
Write-Output “There are $DomainADSitesCount AD Sites matching the domain site filter: $DomainSiteFilter  `r”

$DomainADSites | select name | ft -auto

Microsoft DirectAccess

Microsoft DirectAcess has made great strides in Windows Server 2012.

Key Points:

  • First available with Windows Server 2008 R2.
  • Built-in client support for Windows 7 and newer.
  • Provides always-connected connection to corporate network (connects before the user logs on).
  • Leverages IPV6 and 6to4 tunneling (additional configuration required when using Windows Server 2008 R2 as the DirectAccess server).
  • Windows Server 2012 simplifies the deployment process.
  • Client authentication can leverage Kerberos or certificates. PKI is not required when the DirectAccess server is running Windows Server 2012.
  • DirectAccess clients can be managed regardless of where they are as long as they have network connectivity (outside of the corporate network, internet connectivity is required).
  • DirectAccess connections are IPSec encrypted.
  • The DirectAccess server and clients must be domain-joined.
  • The Windows Firewall needs to be enabled on the server and clients.
  • DirectAccess is not VPN.
  • “When you use Windows 7 clients with DirectAccess in Server 2012 or Server 2008 R2, you need to install a separate DirectAccess Connectivity Assistant (DCA), which gives a system tray icon that shows the DirectAccess connection state.”

Great article describing DirectAccess as well as 2008R2 and 2012 differences and improvements:
http://windowsitpro.com/windows-server-2012/directaccess-windows-server-2012

PowerShell: Determine PowerShell Version

$PSVersionTable.PSVersion

If the variable doesn’t exist, then the system is running version 1.0.

Real-Time World Hack Map

This is an incredible map of the world that shows real-time network attacks. The animation makes it look like something out of the movie, “WarGames.”

Most impressive.

http://map.ipviking.com/?_ga=1.106938115.1477390587.1388686673#

 

PowerShell: Using Active Directory .Net methods in PowerShell Part 1

There are times you don’t have access to the Active Directory PowerShell cmdlets. One of the great things about PowerShell is the ability to use .Net in PowerShell scripts. For more, check out Part 2.

Here are some alternatives to using Get-ADForest & Get-Domain:

 

# Get Active Directory Forest Information
$ADForestInfo = [System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest()
$ADForestInfo.Name
$ADForestInfo.Sites
$ADForestInfo.Domains
$ADForestInfo.GlobalCatalogs
$ADForestInfo.ApplicationPartitions
$ADForestInfo.ForestMode
$ADForestInfo.RootDomain
$ADForestInfo.Schema
$ADForestInfo.SchemaRoleOwner
$ADForestInfo.NamingRoleOwner
# OR
[System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest().Name
[System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest().Sites
[System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest().Domains
[System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest().GlobalCatalogs
[System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest().ApplicationPartitions
[System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest().ForestMode
[System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest().RootDomain
[System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest().Schema
[System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest().SchemaRoleOwner
[System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest().NamingRoleOwner
###
# Get Active Directory Domain Information
  # Target the current (local) computer’s domain:
  $ADDomainInfo = [System.DirectoryServices.ActiveDirectory.Domain]::GetComputerDomain()
  # Target the current user’s domain:
  $ADDomainName = [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()
$ADDomainInfo.Forest
$ADDomainInfo.DomainControllers
$ADDomainInfo.Children
$ADDomainInfo.DomainMode
$ADDomainInfo.Parent
$ADDomainInfo.PdcRoleOwner
$ADDomainInfo.RidRoleOwner
$ADDomainInfo.DomainControllers
# OR
[System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().Forest
[System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().DomainControllers
[System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().Children
[System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().DomainMode
[System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().Parent
[System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().PdcRoleOwner
[System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().RidRoleOwner
[System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().DomainControllers
# Note: Use [System.DirectoryServices.ActiveDirectory.Domain]::GetCOMPUTERDomain().Attribute for the local computer’s domain info.
# Example: [System.DirectoryServices.ActiveDirectory.Domain]::GetCOMPUTERDomain().Forest
###
# Get the local computer’s site information:
$LocalSiteInfo = [System.DirectoryServices.ActiveDirectory.ActiveDirectorySite]::GetComputerSite()
$LocalSiteInfo.Name
$LocalSiteInfo.Domains
$LocalSiteInfo.Subnets
$LocalSiteInfo.Servers
$LocalSiteInfo.AdjacentSites
$LocalSiteInfo.SiteLinks
$LocalSiteInfo.InterSiteTopologyGenerator
$LocalSiteInfo.Options
$LocalSiteInfo.Location
$LocalSiteInfo.BridgeheadServers
$LocalSiteInfo.PreferredSmtpBridgeheadServers
$LocalSiteInfo.PreferredRpcBridgeheadServers
$LocalSiteInfo.IntraSiteReplicationSchedule
# OR
[System.DirectoryServices.ActiveDirectory.ActiveDirectorySite]::GetComputerSite().Name
[System.DirectoryServices.ActiveDirectory.ActiveDirectorySite]::GetComputerSite().Domains
[System.DirectoryServices.ActiveDirectory.ActiveDirectorySite]::GetComputerSite().Subnets
[System.DirectoryServices.ActiveDirectory.ActiveDirectorySite]::GetComputerSite().Servers
[System.DirectoryServices.ActiveDirectory.ActiveDirectorySite]::GetComputerSite().AdjacentSites
[System.DirectoryServices.ActiveDirectory.ActiveDirectorySite]::GetComputerSite().SiteLinks
[System.DirectoryServices.ActiveDirectory.ActiveDirectorySite]::GetComputerSite().InterSiteTopologyGenerator
[System.DirectoryServices.ActiveDirectory.ActiveDirectorySite]::GetComputerSite().Options
[System.DirectoryServices.ActiveDirectory.ActiveDirectorySite]::GetComputerSite().Location
[System.DirectoryServices.ActiveDirectory.ActiveDirectorySite]::GetComputerSite().BridgeheadServers
[System.DirectoryServices.ActiveDirectory.ActiveDirectorySite]::GetComputerSite().PreferredSmtpBridgeheadServers
[System.DirectoryServices.ActiveDirectory.ActiveDirectorySite]::GetComputerSite().PreferredRpcBridgeheadServers
[System.DirectoryServices.ActiveDirectory.ActiveDirectorySite]::GetComputerSite().IntraSiteReplicationSchedule

PowerShell: Get the Dates When the Active Directory Schema Was Updated

 

The Microsoft Scripting Guys blog has a great article on determining when schema updates were performed along with some information about the schema changes – at least enough to see if it was an Exchange update.

 


###########################
# Get Schema Update Dates #
###########################
# Code from: http://blogs.technet.com/b/heyscriptingguy/archive/2012/01/05/how-to-find-active-directory-schema-update-history-by-using-powershell.aspx
write-output "Reading all schema data... " `r
import-module activedirectory
$schema = Get-ADObject -SearchBase ((Get-ADRootDSE).schemaNamingContext) `
-SearchScope OneLevel -Filter * -Property objectClass, name, whenChanged,`
whenCreated | Select-Object objectClass, name, whenCreated, whenChanged, `
@{name="event";expression={($_.whenCreated).Date.ToShortDateString()}} | `
Sort-Object whenCreated

#"`nDetails of schema objects changed by date:"
#$schema | Format-Table objectClass, name, whenCreated, whenChanged `
#-GroupBy event -AutoSize

write-output "`nCount of schema objects changed by date:" `r
Write-output "This displays the approximate date each each schema update was performed." `r
$schema | Group-Object event | Format-Table Count,Name,Group –AutoSize

LSASS Crashing, CNF Objects May Be the Cause

What Happens and How Do I Know if I’m Affected?

When CNF mangled NTDS settings objects are created, the Lsass.exe process may crash and unexpectedly reboot one or more domain controllers. So there is a pretty good chance you’ll know about it. You may not know the root cause of the crash. More specifically though you’ll see the following events in the Application Log which you can look for.

Log Name: Application
Source: Application Error
Date: DateTime
Event ID: 1000
Task Category: Application Crashing Events
Level: Error
Keywords: Classic
User: N/A
Computer: ComputerName
Description:
Faulting application name: lsass.exe, version: 6.1.7601.17725, time stamp: 0x4ec483fc
Faulting module name: ntdll.dll, version: 6.1.7601.18229, time stamp: 0x51fb164a
Exception code: 0xc0000374
Fault offset: 0x00000000000c4102
Faulting process id: 0x1f4
Faulting application start time: 0x01ceb94c671de3dd
Faulting application path: C:\Windows\system32\lsass.exe
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
Report Id: 80a2cd04-2540-11e3-99e2-441ea1d316a4
Faulting package full name: %14
Faulting package-relative application ID: %15

And

Log Name: Application
Source: Microsoft-Windows-Wininit
Date: DateTime
Event ID: 1015
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: ComputerName
Description:
A critical system process, C:\Windows\system32\lsass.exe, failed with status code 255. The machine must now be restarted.

Read more of the blog post:

http://blogs.technet.com/b/askpfeplat/archive/2014/06/23/lsass-crashing-cnf-objects-may-be-the-cause.aspx

 

PowerShell: Get Active Directory Instantiation Date

 

The Scripting Guys blog posted a very useful script on how to determine when the Active Directory Forest was stood up.

 


#############################
# Get AD Instantiation Date #
#############################
# Code from: http://blogs.technet.com/b/heyscriptingguy/archive/2012/01/05/how-to-find-active-directory-schema-update-history-by-using-powershell.aspx
write-output "Checking Active Directory Creation Date... " `r
write-output "Displaying AD partition creation information " `r

Import-Module ActiveDirectory
Get-ADObject -SearchBase (Get-ADForest).PartitionsContainer `
-LDAPFilter "(&(objectClass=crossRef)(systemFlags=3))" `
-Property dnsRoot,nETBIOSName,whenCreated | Sort-Object whenCreated | Format-Table dnsRoot,nETBIOSName,whenCreated -AutoSize

Load more