Hello there folks, it’s Ned. I’ve been out of pocket for a few weeks and I am moving to a new role here, plus Scott and Jonathan are busy as #$%#^& too, so that all adds up to the blog suffering a bit and the mail sack being pushed a few times. Never fear, we’re back with some goodness and frankness. Heck, Jonathan answered a bunch of these rather than sipping cognac while wearing a smoking jacket, which is his Friday routine. Today we talk certs, group policy, backups, PowerShell, passwords, Uphclean, RODC+FRS+SYSVOL+DFSR, and blog editing. There were a lot of questions in the past few weeks that required some interesting investigations on our part – keep them coming.
Let us adjourn to the conservatory.
- Inactive account password expiration
- DSAMAIN and snapshots
- “Run only specified Windows Applications” broken
- Certificates and TPM storage
- Latest UPHCLEAN
- RODC SYSVOL replication failing
- Our editorial software
Do you know of a way to set user passwords to expire after 30 days of inactivity?
There is no automatic method for this, but with a bit of scripting it would be pretty trivial to implement. Run this sample command as an admin user (in your test environment first!!!):
Dsquery.exe user -inactive 4 | dsmod.exe user –mustchpwd yes
Dsquery will find all users in that domain that have not logged in for 4 weeks or longer, then pipe that list of DN’s into the Dsmod command that sets the “must change password at next logon” (pwdlastset) flag on each of those users.
You can also use AD PowerShell in Win2008 R2/Windows 7 RSAT to do this.
search-adaccount –accountinactive –timespan 30 –usersonly | set-aduser –changepasswordatlogon 1
The PowerShell method works a little differently; Dsquery only considers inactive accounts that have logged on. Search-adaccount also considers users that have never logged on. This means it will find a few “users” that cannot usually have their password change flags enabled, such as Guest, KRBTGT, and TDO accounts that are actually trusts between domains. If someone wants to post a slick example of bypassing those, please send them along (as the clock ran down here).
As it’s stated here: http://technet.microsoft.com/en-us/library/cc753609%28WS.10%29.aspx
“You are not required to run the ntdsutil snapshot operation to use Dsamain.exe. You can instead use a backup of the AD DS or AD LDS database or another domain controller or AD LDS server. The ntdsutil snapshot operation simply provides a convenient data input for Dsamain.exe.”
I should be able to mount snapshot and use dsamain to read AD content, with only full backup of AD. But I can’t. Using ntdsutil I can list and mount snapshot from AD, but I can’t do “dsamain -dbpath full_path_to_ntds.dit”.
You have to extract the .DIT file from the backup.
1. First run wbadmin get versions. In the output, locate your most recent backup and note the Version identifier:
wbadmin get versions
2. Extract the Active Directory files from the backup. Run:
wbadmin start recovery -versions:<version identifier> -itemtype:app -items:AD -recoverytarget:<drive>
3. A folder called Active Directory will be created on the recovery drive. Contained therein you’ll find the NTDS.DIT file. To mount it, run:
dsamain -dbpath <recovery folder>\ntds.dit -ldapPort 4321
4. The .DIT file will be mounted, and you can use LDP or ADSIEDIT to connect to the the directory on port 4321 and browse it.
I has run into the issue described in KB976922 where “Run only specified Windows Applications” or “Run only allowed Windows applications” is blank when you are mixing Windows XP/Windows Server 2003 and Windows Server 2008/R2 Windows 7 computers. Some forum posts on TechNet state that this was being fixed in Win7 and Win2008 R2 though, which appears to be untrue. Is this being fixed in SP1 or later or something?
It’s still broken in Win7/R2 and still broken in SP1. It’s quite likely to remain broken forever as there are so many workarounds and the technology in question actually dates back to before group policy – it was part of Windows 95 (!!!) system policies. Using this policy isn’t very safe. It’s often something that was configured many years ago that lives on through inertia.
Windows 7 and Windows Server 2008 R2 introduced AppLocker to:
- Help prevent malicious software (malware) and unsupported applications from affecting computers in your environment.
- Prevent users from installing and using unauthorized applications.
- Implement application control policy to satisfy security policy or compliance requirements in your organization.
Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008 all support Software Restriction Policies (SAFER) which also control applications similarly to AppLocker. Both AppLocker and SAFER replace that legacy policy setting with something less easily bypassed and limited.
For more information about AppLocker, please review:
For more information about SAFER, please review:
I updated the KB to reflect all this too.
Is it possible to store computer certificates in a Trusted Platform Module (TPM) in Windows 7?
The default Windows Key Storage Provider (KSP) does not use a TPM to store private keys. That doesn’t mean that some third party can’t provide a KSP that implements the Trusted Computer Group (TCG) 1.2 standard to interact with a TPM and use it to store private keys. It just means that Windows 7 doesn’t have such a KSP by default.
It appears that there is a new version of Uphclean available (http://www.microsoft.com/downloads/en/details.aspx?FamilyId=1B286E6D-8912-4E18-B570-42470E2F3582&displaylang=en). What’s new about this version and is it safe to run on Win2003?
The new 1.6 version only fixes a security vulnerability and is definitely recommended if you are using older versions. It has no other announced functionality changes. As Robin has said previously, Uphclean is otherwise deceased and 2.0 beta will not be maintained or updated. Uphclean has never been an officially supported MS tool, so use is always at your own risk.
My RODCs are not replicating SYSVOL even though there are multiple inbound AD connections showing when DSSITE.MSC is pointed to an affected RODC. Examining the DFSR event log shows:
Log Name: DFS Replication
Date: 5/20/2009 10:54:56 AM
Event ID: 6804
Task Category: None
The DFS Replication service has detected that no connections are configured for replication group Domain System Volume. No data is being replicated for this replication group.
New RODCs that are promoted work fine. Demoting and promoting an affected RODC fixes the issue.
Somebody has deleted the automatically generated “RODC Connection (FRS)” objects for these affected RODCs.
- This may have been done because the customer saw that the connections were named “FRS” and they thought that with DFSR replicating SYSVOL that they were no longer required.
- Or they may have created manual connection objects per their own processes and deleted these old ones.
RODCs require a special flag on their connection objects for SYSVOL replication to work. If not present, SYSVOL will not work for FRS or DFSR. To fix these servers:
1. Logon to a writable DC in the affected forest as an Enterprise Admin.
2. Run DSSITE.MSC and navigate to an affected RODC within its site, down to the NTDS Settings object. There may be no connections listed here, or there may be manually created connections.
3. Create a new connection object. Ideally, it will be named the same as the default (ex: “RODC Connection (FRS)”).
4. Edit that connection in ADSIEDIT.MSC or with DSSITE.MSC attribute editor tab. Navigate to the “Options” attribute and add the value of “0x40”.
5. Create more connections using these steps as necessary.
6. Force AD replication outbound from this DC to the RODCs, or wait for convergence. When the DFSR service on the RODC sees these connections, SYSVOL will begin replicating again.
More info about this 0x40 flag: http://msdn.microsoft.com/en-us/library/dd340911(PROT.10).aspx
RT (NTDSCONN_OPT_RODC_TOPOLOGY, 0x00000040): The NTDSCONN_OPT_RODC_TOPOLOGY bit in the options attribute indicates whether the connection can be used for DRS replication [MS-DRDM]. When set, the connection should be ignored by DRS replication and used only by FRS replication.
Despite the mention only of FRS in this article, the 0x40 value is required for both DFSR and FRS. Other connections for AD replication are still separately required and will exist on the RODC locally.
What editor do you use to update and maintain this blog?
Windows Live Writer 2011 (here). Before this version I was hesitant to recommend it, as the older flavors had idiosyncrasies and were irritating. WLW 2011 is a joy, I highly recommend it. The price is right too: free, with no adware. And it makes adding content easy…
Or ovine-related emoticons.
That’s all for this week.
– Ned “Colonel Mustard” Pyle and Jonathan “Professor Plum” Stephens