Removing an Orphan (inactive) Active Directory Domain

Removing an Orphan (inactive) Active Directory Domain

One of my customers has a forest with several domains, one of which hasn’t been used in a while (call it domain “RedShirt”). The 2 Domain Controllers in the domain, “RedShirt” both tombstoned. Yes, I know, how does that happen? ALWAYS monitor your environment. Since the domain hasn’t been used in a while, it was decided to clean up the domain (remove it).  However, with both DCs tombstoned, one can’t just DCPromo down a domain DC and select “last DC in the domain”.

Microsoft provided information on how to “metadata cleanup” the dead “RedShirt” domain, though the process was not performed 100% properly (always connect to the Domain Naming Master for this process). This process is documented in KB 230306  (How to remove orphaned domains from Active Directory); however, this doesn’t work on a 2008 R2 DC.

Confirm the domain is still listed in the forest by listing the Naming Contexts using Powershell:

Import-Module activedirectory ; (Get-ADRootDSE).namingContexts 

Here’s the correct process to clean-up an orphan domain on a 2008 R2 Domain Controller:

  1. Log onto the Domain Naming Master for the forest
  2. Open a command prompt as Administrator
  3. run ntdsutil
  4. activate instance ntds
  5. partition management
  6. connections
  7. connect to server <DOMAIN NAMING MASTER>
  8. q
  9. List
  10. Note the number & DN of the Domain DNS zone for the orphan domain (in this instance it is #6). The Domain DNS zone needs to be removed first.
  11. Delete NC DC=DomainDNSZones,DC=RedShirt,DC=Metcorp,DC=Org
  12. List
  13. Note the number of the Domain partition for the orphan domain (in this instance it is #5)
  14. Delete NC DC=RedShirt,DC=Metcorp,DC=org
  15. qqq
  16. Force replication by running “repadmin /syncall”

Apple iOS Security Whitepaper

In February of this year, 2014, Apple released an updated whitepaper describing Apple iOS Security. Overall, the operating system and its components are very securely designed.

The Table of Contents:

Introduction
System Security
Secure Boot Chain
System Software Authorization
Secure Enclave
Touch ID
Encryption and Data Protection
Hardware Security Features
File Data Protection
Passcodes
Data Protection Classes
Keychain Data Protection
Keybags
FIPS 140-2
App Security
App Code Signing
Runtime Process Security
Data Protection in Apps
Accessories
Network Security
SSL, TLS
VPN
Wi-Fi
Bluetooth
Single Sign-on
AirDrop Security
Internet Services
iMessage
FaceTime
Siri
iCloud
iCloud Keychain
Device Controls
Passcode Protection
Configuration Enforcement
Mobile Device Management (MDM)
Apple Configurator
Device Restrictions
Supervised Only Restrictions
Remote Wipe

Download and read the PDF Document

 

PowerShell: One-liners to Get You Started

Some of the scenarios covered in the blog post:

  • The server rebooted recently – who did it and when exactly?
  • Is there an easy way to see if KB2862152 is installed?
  • I need to backup all of the GPOs in the domain every day
  • What are the IP settings on my system(s)?
  • What are the BIOS versions on my systems?
  • Are all of my DCs GCs?
  • Which accounts in my domain are enabled and set to never expire the password?
  • How can I parse an input file of some AD attribute for users (SAM Account name in this case) and map those entries to another attribute for those users (the DN in this case)?
  • What is the OS version and Service Pack level for all of my Windows systems in a certain OU?
  • Stop and/or Start all of your lab (Hyper-V) VMs

http://blogs.technet.com/b/askpfeplat/archive/2014/06/16/powershell-one-liners-to-get-you-started.aspx

 

New 2012 SIDs cause lookup issues for older clients

The crux of the issue is that Windows Server 2012 (and above) introduce two new SIDs. The problem is that Windows 7 and Windows Server 2008 R2 clients do not know about these SIDs because when they (Windows 7 and 2008 R2) were written these particular SIDs didn’t exist.

References:

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#

 

Load more