Stanimir Stoyanov has been awarded the Microsoft MVP (Most Valuable Professional) title in Visual C#, Stanimir Stoyanov is a programmer, Software beta tester, and Windows enthusiast and also a very good friend of mine, he has been helping out in the development of the Fine Grain Password Policy Tool and other upcoming tools. Congratulations Stanimir you have made a great contribution to the community. Read more about him at his blog here

It's been a very busy month, I've been traveling a lot and been speaking at a few different seminars and conferences. First of was the Windows 7 Summit held here in Sweden by ourselves TrueSec,

Windows 7 Summit

I did two sessions together with Mikael Nyström, first session was an introduction to the Windows 7 Client, covering some UI changes and the approach Microsoft has taken with Multi-Touch and the other was about new technologies and features in Windows Server 2008 R2, it was a great time and I had lots of fun on the stage, I'm sorry that I misspelled my own sisters name during the Recycle-Bin demo J

Microsoft decided to record the sessions, so if anyone is interested to see the sessions (In Swedish), here you go!

An introduction to the Windows 7 Client.
http://mediadl.microsoft.com/mediadl/www/s/sverige/technettv/2009/Win7Summit/Windows7Summit-090226-pass1.wmv

New Technologies and Features in Windows Server 2008 R2
http://mediadl.microsoft.com/mediadl/www/s/sverige/technettv/2009/Win7Summit/Windows7Summit-090226-pass2.wmv

Redmond
Directly after the Windows 7 summit it was time to fly over to Seattle/Redmond for the Microsoft MVP Summit. A big thanks to the entire Directory Service Team at Microsoft for the amazing week we had in Redmond at the Microsoft Campus working with them, and all other DS MVPs that attended the Microsoft MVP Summit, also thanks to my friend Eddy for inviting me to his new house, you got a nice place J

Microsoft TechDays in Västerås

At Microsoft TechDays in Västerås (Sweden) I attended as a speaker and presented on how to Incorporate RODCs (Read Only Domain Controllers) to your existing Active Directory, this was a 400 level sessions where I decided to give a deep-dive on how RODCs really works (and doesn't work) in detail and how it effects an already existing Active Directory and related components. Unfortunately time didn't allow me to show the FAS (Filter Attribute Set) Demo, I'm sorry for that, but I'm planning a detail article on FAS works, the basic idea is that you can flag attributes with sensitive/confidential information to never replicate to RODCs, in case of an RODC compromise, this information isn't reveled.

You can download the slide deck from the session here: tech_days09_sweden_ds_final.zip

I've got many questions about RODCs and DNS after my sessions, I've blogged about that topic a while ago, you can find the article here: How Read-Only Domain Controllers and DNS works.

Thanks to Microsoft for putting together the TechDays Conference, this was the first time the concept of "TechDays" where used in Sweden, the idea is to have a sort of local TechED event, and I must said everything did work very well, hopefully there will be a TechDays next year as well.

It's been yet another sleepless night working, actually I have a lot of stuff going on right now, I guess I don't will feel too well when this week is over, anyway some interesting facts about the Enterprise Read-Only Domain Controllers group (Yes the _real_ one this time, with RID 498 that's not an FSP), have you ever look thru the members of that group? Why would you ever do that, isn't it obvious that it's going to contain the RODC accounts in the enterprise? Nope, in fact it won't, it will always be empty J

So how does this really work? Adprep /rodcprep stamps each NC head with an ACE (in order to allow RODCs replicate changes from the NC), NDNCs are stamped with an ACE for the Read-Only Enterprise Domain Controllers group (Note that the group doesn't exist at this stage, but always has a well-known RID of 498, so that's how adprep dose it)

But won't replication of NDNCs fail as Enterprise Read-Only Domain Controllers is granted extended-right Replicate Changes but the group is empty? Nope RODCs will always include the RID 498 in its token J

So what do we really need the group for? It's there for display purposes, so you don't have to see something like (Unknown Account) if you look at the ACL.

I was working late tonight to finish my session "Incorporate RODCs (Read Only Domain Controllers) to your existing Active Directory" that I'm going to present at Microsoft TechDays 17-18 mars in Västerås. If you're interested in a deep dive session (level 400+) about Read-Only Domain Controllers, then my session is for you, read more at: http://www.microsoft.com/sverige/techdays09/sv/about.aspx

However, I was about to reproduce a bug that we have found with "adprep /rodcprep" to include it in the session, and how to correct and avoid it to happen, when I was reviewing the security of my NCs I noticed a strange group: NT AUTHORITY\ENTERPRISE READ-ONLY DOMAIN CONTROLLERS BETA. It's a part of the NT AUTHORITY and my guess is that this group was introduced in my forest in the early days of Longhorn Server when there was still a requirement to have the PDC running Longhorn Server in order to incorporate RODCs to your forest. Now days (Post Beta 3) Enterprise Read-Only Domain Controllers and Read-Only Domain Controllers (Domain specific) is created in your domain using a trigger that happens on the promotion of the first RODC or the first Pre-Stage of an RODC.

I was recently asked by a friend of mine how Read-Only Domain Controllers (RODCs) works with DNS, since they can host DNS for Active Directory, so I think it was a good idea with a blog post on how it really works. First of all Windows Server 2008 bring new capabilities to both Active Directory and DNS and many of them are related.

Read-Only Domain Controllers (RODCs) and the Primary Read-Only Zone

When you promote a Read-Only Domain Controller (RODC) and also select it to be a DNS server, it will perform inbound replication of the DNS Zones (Either stored in the applications or domain NCs) as any Writeable Domain Controller. But if you're familiar with RODC basics you know they never perform outbound replication and the database is mostly read-only (including the DNS records), Windows Server 2008 DNS Introduce a new zone type called the Primary Read-Only Zone. The Administrator of RODC can view contents of DNS but will unable to change it from a RODC.

Read-Only Domain Controllers (RODCs) are not pointing the SOA to them self unlike Writable Domain Controllers

Writable Domain Controllers are always pointing the SOA to them self, because they all host writable copies of Active Directory-Integrated Zones, How ever RODCs doesn't host writable copies of those and therefore points the SOA to an Writable Domain Controller using the following SOA selection model.

1. Trying to select a writable domain controller that is running Windows Server 2008 and is published as a NS for the zone
2. If there are no Windows Server 2008 writable domain controllers that publish a NS for the zone a randomly domain controller will be picked from the NS list.

   Note: The current SOA target DC is maintained separately for each zone and re-selected every 20 minutes (not configurable). The selection algorithm contains a random component to try to spread load between writable domain controllers.

[2] Needs a clarification to another difference, RODCs doesn't register NS records, so it makes [2] safe from picking any RODC.

DNS Updates for clients having a Read-Only Domain Controller (RODC) as preferred DNS server

When a client attempts a dynamic update, it sends SOA query to its preferred DNS server. Typically, clients are configured to use the DNS server in their branch site as their preferred DNS server. The RODC should read its SOA record and at best effort return a writable Windows Server 2008 domain controller to the client (Using the SOA selection model above), the RODC waits a certain amount of time, as explained below, and then it attempts to replicate the updated DNS record object in Active Directory from the DNS server that it referred the client to through an RSO operation back to the RODC, an RSO operation is an operational attribute named replicateSingleObject that has existed in Active Directory since Windows 2000 and allows replication of a single object by using a LDAP modify operation of the replicateSingleObject attribute, However the replicateSingleObject has been updated in Windows Server 2008 to support replication of secrets to RODCs, More information about the attribute and it's syntax can be found here: http://msdn.microsoft.com/en-us/library/cc223306(PROT.13).aspx

How Read-Only Domain Controllers perform RSO operations of DNS record updates

For the DNS server on the RODC to perform an RSO operation of the DNS record update, a DNS server that runs Windows Server 2008 must host writeable copies of the zone that contains the record. That Windows Server 2008 DNS server must register a name server (NS) resource record for the zone, with other words [1] must be used in the SOA selection model above.

Note: The Windows Server 2003 Branch Office Guide recommended restricting name server (NS) record registration to a subset of the available DNS servers. If you followed those guidelines and you do not register at least one writable Windows Server 2008 DNS server as a name server for the zone, the DNS server on the RODC attempts to perform the RSO operation with a DNS server that runs Windows Server 2003 using [2] in the SOA selection model. That operation fails and generates a 4015 Error in the DNS event log of the RODC, and replication of the DNS record update will be delayed until the next scheduled replication cycle and RSO operation cannot be made by the RODC DNS against a Windows Server 2003 Domain Controller.

More specifically how the RSO operation really works, the SOA query triggers the DNS server on the RODC to put an entry in remotePollList, which is an internal queue on each DNS server. The entry includes the following:

• The object to be replicated
• The source domain controller to replicate from
• A time stamp

The time stamp is set to a time in the future that is equal to the current time plus a replication delay. The replication delay is controlled by a registry setting named DsRemoteReplicationDelay. By default, the value of this setting is 30 seconds.

The internal queue (remotePollList) is processed at regular intervals. The queue-processing interval is controlled by a registry setting named DSPollingInterval. By default, the value of the interval is three minutes.

When the DNS server processes the queue, it attempts to replicate only objects whose time stamp is less than current time. Therefore, the delay between the time that the RODC refers the client to an authoritative DNS server and then attempts to replicate in is determined by the following:

• The next time that the DNS server processes the queue
• Whether the remote replication delay that is set on the entry in the queue has elapsed

If you use the default values for the registry settings, the amount of time before the RODC attempts to replicate the DNS update is a minimum of 30 seconds and a maximum of 210 seconds.

You can modify the values of these registry settings to reduce the amount of time before the RODC attempts to replicate the DNS update. The minimum value for the DsRemoteReplicationDelay setting is 5 seconds. The minimum value for the DSPollingInterval setting is 30 seconds. If you use the minimum values, the amount of time before the RODC attempts to replicate the DNS update is a minimum of 5 seconds and a maximum of 35 seconds.

Note: Max number of RSO requests per 5 minutes cycle is 300 to prevent Denial of Service attacks

Note: DsPollingInterval controls all Active Directory polling, not just RODC RSO handling. If you change this value, be aware that this change will affect more than just RODC RSO operations. For example, this setting will affect how often the DNS server polls Active Directory for new or updated resource records or DNS zones.

The following table lists some additional registry entries that are related to the RSO operations that are performed for DNS updates on an RODC. These registry entries are stored in the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters

To modify any of the registry entries that are related to the RSO operations for DNS updates on an RODC, use the Dnscmd.exe command-line tool to set the appropriate parameter.
Example: "dnscmd <server>.<domain>.<com> /Config /DsRemoteReplicationDelay 10"

I think that's all I can think of for now.

When using tokeGroups attribute to retrieve group membership fails, well more optionally would of course be to use the attribute tokenGroupsNoGCAcceptable as it will return a value on "best effort" even if there isn't a GC around, but that's not the issue here, and the issue actually applies to tokenGroupsNoGCAcceptable as well.

If we assume that all DCs in the forest are also made GCs, what will cause the code below to break? It contains an interesting bug actually, and a scenario that the developers of this app failed to take care of, Note this application is actually a Microsoft app. I will be interesting to see if anyone else can identify the issue J btw; it caused the entire app to crash.

internal class Program

{

internal static void Main(string[] args)

{

Console.WriteLine("BREUtils:checkDomainUseRoles.");

ArrayList tokenGroups = new ArrayList();

tokenGroups = checkDomainUserRoles("internal\\ADCH");

}

public static ArrayList checkDomainUserRoles(string user)

{

ArrayList list = new ArrayList();

DirectoryEntry entry = null;

DirectoryEntry searchRoot = null;

DirectorySearcher searcher = null;

SearchResultCollection results = null;

try

{

//ZeroTouchServiceUtil.LogDebugEvent(string.Format("Entering BREUtilities::checkDomainUserRoles called with parameters user: {0} ", user));

string str = user.Split(new char[] { '\\' })[1];

string str2 = user.Split(new char[] { '\\' })[0];

entry = new DirectoryEntry("LDAP://rootDSE");

string str3 = (string)entry.Properties["DefaultNamingContext"][0];

searchRoot = new DirectoryEntry("GC://" + str3);

searcher = new DirectorySearcher(searchRoot);

string str4 = "(&(objectClass=user)(samaccountname=" + str + "))";

searcher.Filter = str4;

searcher.SearchRoot = new DirectoryEntry("LDAP://" + str2);

searcher.PropertiesToLoad.Add("CN");

results = searcher.FindAll();

if (results.Count != 1)

{

//ZeroTouchServiceUtil.LogDebugEvent(string.Format("BREUtilities::checkDomainUserRoles: User Account {0} found {1} times.", user, results.Count));

return list;

}

DirectoryEntry entry3 = null;

try

{

entry3 = new DirectoryEntry(results[0].Path.Replace("GC://", "LDAP://"));

entry3.RefreshCache(new string[] { "CN", "tokenGroups" });

PropertyValueCollection c = entry3.Properties["tokenGroups"];

ArrayList list2 = new ArrayList(c.Count);

list2.AddRange(c);

for (int i = 0; i < list2.Count; i++)

{

byte[] sid = (byte[])list2[i];

string str5 = ConvertSidToStringSid(sid);

DirectoryEntry entry4 = new DirectoryEntry(string.Format("LDAP://<SID={0}>", str5));

try

{

string str7 = entry4.Properties["samAccountName"].Value.ToString();

list.Add(str7);

}

catch (Exception exception)

{

Console.WriteLine("Error: " + exception.Message);

}

finally

{

DisposeDirectoryObject(entry4);

}

}

return list;

}

catch (Exception exception2)

{

Console.WriteLine("Error in BREUtilities::checkDomainUserRoles: " + exception2.Message);

return list;

}

finally

{

DisposeDirectoryObject(entry3);

}

}

catch (Exception exception3)

{

Console.WriteLine("Error in BREUtilities::checkDomainUserRoles. " + exception3.Message);

}

finally

{

DisposeDirectoryObject(searcher);

DisposeDirectoryObject(searchRoot);

DisposeDirectoryObject(entry);

DisposeDirectoryObject(results);

}

return list;

}

public static void DisposeDirectoryObject(object obj)

{

try

{

if (obj != null)

{

if (obj is DirectorySearcher)

{

((DirectorySearcher)obj).Dispose();

}

else if (obj is DirectoryEntry)

{

((DirectoryEntry)obj).Dispose();

}

else if (obj is SearchResultCollection)

{

((SearchResultCollection)obj).Dispose();

}

}

}

catch (Exception exception)

{

//ZeroTouchServiceUtil.LogErrorEvent(string.Format("Exception in BREUtilities:DisposeDirectoryObjects. Error: {0}", exception.ToString()));

}

}

private static string ConvertSidToStringSid(byte[] sid)

{

IntPtr destination = new IntPtr();

IntPtr pSidString = new IntPtr();

destination = Marshal.AllocHGlobal(sid.Length);

Marshal.Copy(sid, 0, destination, sid.Length);

ConvertSidToStringSid(destination, ref pSidString);

string str = Marshal.PtrToStringAuto(pSidString);

Marshal.FreeHGlobal(destination);

Marshal.FreeHGlobal(pSidString);

return str;

}

private static string ConvertToOctetString(byte[] val)

{

StringBuilder builder = new StringBuilder((val.GetUpperBound(0) + 1) * 2);

for (int i = 0; i < val.GetUpperBound(0); i++)

{

builder.Append(val[i].ToString("x2"));

}

return builder.ToString();

}

[DllImport("advapi32.dll", CharSet = CharSet.Auto, SetLastError = true)]

private static extern int ConvertSidToStringSid(IntPtr pSID, ref IntPtr pSidString);

[DllImport("advapi32.dll", CharSet = CharSet.Auto)]

private static extern bool ConvertSidToStringSid(IntPtr pSID, [In, Out, MarshalAs(UnmanagedType.LPTStr)] ref string pStringSid);

[DllImport("advapi32.dll", CharSet = CharSet.Auto)]

private static extern bool ConvertStringSidToSid(string pStringSid, ref IntPtr pSID);

}

Build: FGPP RTM_2300-20081223.0
Branch: FGPP-RTM-branch.
Usage: Production Usage.

General Information

This build is the final RTM build of the Fine Grain Password Policy Tool. (FGPP RTM_2300-20081223.0) For full release notes see the document “Release notes for Fine Grain Password Policy Tool” included in the package, as well to be released on the website later today, other documentation available with this release are.

·         Quick Start Guide for Fine Grain Password Policy Tool

·         Windows PowerShell Usage for Fine Grain Password Policy Tool

·         Password Policy Samples for Fine Grain Password Policy Tool

Acknowledgements

Stanimir Stoyanov, thanks for providing the incredible support and your ideas while this piece of software was being written. Especially for the work that was done with the Native Methods. Please have a look at this blog for other projects he has been released http://www.stoyanoff.info

Björn Österman, thanks for your help and support with the initial design of the Password Policy class.

TrueSec Team, thanks for providing support while this piece of software was being written.

Overview of Fine Grain Password Policies in Windows Server 2008:
http://technet2.microsoft.com/windowsserver2008/en/library/056a73ef-5c9e-44d7-acc1-4f0bade6cd751033.mspx

Download

Download Fine Grain Password Policy Tool (x86) 1.0.
http://blogs.chrisse.se/files/folders/fgpp/entry51.aspx

Download Fine Grain Password Policy Tool (x64) 1.0.
http://blogs.chrisse.se/files/folders/fgpp/entry50.aspx

Quick Start Guide.
http://blogs.chrisse.se/blogs/chrisse/pages/fine-grain-password-policy-tool.aspx

System Requirements

Fine Grain Password Policy Tool 1.0 are “Supported” on the following platforms

·         Windows Server 2008

·         Windows Server 2008 R2 Beta 1 (Build 7000) or later

·         Windows Vista, Windows Vista with Service Pack 1 or later

·         Windows 7 Beta (Build 7000) or later

·         Windows Server 2003 with Service Pack 1 or later and Windows Server 2003 R2

·         Windows XP Service Pack 2 or later

Prerequisites

Before installing this build, you must have:

Windows Server 2008, Windows Server 2008 R2 and Windows Vista, Windows 7

·         Windows Server 2008 Active Directory Domain.

·         Windows PowerShell installed (for command-line and scripting support)
Windows Server 2003 and Windows XP

·         Microsoft .NET Framework 2.0.

·         Microsoft Management Console 3.0

·         Windows Server 2008 Active Directory Domain.

·         Windows PowerShell installed (for command-line and scripting support)

Usage information 

Fine Grain Password Policy Tool Core PowerShell Samples.

FGPP RC0 Milestone (Build 2270-2292) supports the following PowerShell Commands.
Create new Password Policies

New-PasswordPolicy <Name> [-domain <FQDNDomainName>] >] [–server <DCFQDN>] -MaximumPasswordAge <timespan> -MinimumPasswordAge <timespan> -MinimumPasswordLength <PassswordMinLenght> -PasswordComplexityEnabled <$True/$False> -PasswordReversibleEncryptionEnabled <$True/$False> -PasswordSettingsPrecendence <PrecendenceOrder> -PasswordHistoryLength <NumberOfPasswords> -LockoutDuration <timespan> -LockoutObservationWindow <timespan> -LockoutThreshold <int> -AppliesTo *SupportedNameFormats

Modify existing Password Policies
Modify-PasswordPolicy <name> [-domain <FQDNDomainName>] >] [–server <DCFQDN>] [-MaximumPasswordAge <timespan>] [-MinimumPasswordAge <timespan>] [-MinimumPasswordLength <PassswordMinLenght>] [-PasswordComplexityEnabled <$True/$False>] [-PasswordReversibleEncryptionEnabled <$True/$False>] [-PasswordSettingsPrecendence <PrecendenceOrder>] [-PasswordHistoryLength <NumberOfPasswords>] [-LockoutDuration <timespan>] [-LockoutObservationWindow <timespan>] [-LockoutThreshold <int>] -AppliesToAdd *SupportedNameFormats -AppliesToRemove *SupportedNameFormats

Delete Password Policies
Delete-PasswordPolicy <name> [-domain <FQDNDomainName>] [–server <DCFQDN>] [-all]

Reame Password Policies
Rename-PasswordPolicy <name> [-domain <FQDNDomainName>] -NewName <name>

Add users and global groups to an existing Password Policy
Add-PasswordPolicy -Name <name> [-domain <FQDNDomainName>] [–server <DCFQDN>] -AppliesTo *SupportedNameFormats

Remove users and global groups to an existing Password Policy

Remove-PasswordPolicy -Name <name> [-domain <FQDNDomainName>] [–server <DCFQDN>] -AppliesTo *SupportedNameFormats [-all]

Get the Effective PasswordPolicy for one or more users objects

Get-PasswordPolicyEffective <name> [-domain <FQDNDomainName>] [–server <DCFQDN>]

Export Password Policies

Export-PasswordPolicy <name> <path> [-domain <FQDNDomainName>] [–server <DCFQDN>]

Import Password Policies

Import-PasswordPolicy <name> <path> [-domain <FQDNDomainName>] [–server <DCFQDN>]

--------------------------------------------------------------------------------------------------------------------------------------------------------------

*SupportedNameFormats: [Domain\UserN, "First LastName", {4fa050f0-f561-11cf-bdd9-00aa003a77b6}, example.microsoft.com/software/user name, usern@example.microsoft.com, S-1-5-21-397955417-626881126-188441444-501]

Fine Grain Password Policy Tool Additional PowerShell Samples.

.

--------------------------------------------------------------------------------------------------------------------------------------------------------------

How to use the Get-PasswordPolicy and New-PasswordPolicy to copy an existing PasswordPolicy

Note: Any parameter can be used with New-PasswordPolicy override settings from the existing policy.

Get-PasswordPolicy <name> [-domain <FQDNDomainName>] | New-PasswordPolicy <Name> [-domain <FQDNDomainName>] [-MaximumPasswordAge <timespan>] [-MinimumPasswordAge <timespan>] [-MinimumPasswordLength <PassswordMinLenght>] [-PasswordComplexityEnabled <$True/$False>] [-PasswordReversibleEncryptionEnabled <$True/$False>] [-PasswordSettingsPrecendence <PrecendenceOrder>] [-PasswordHistoryLength <NumberOfPasswords>] [-LockoutDuration <timespan>] [-LockoutObservationWindow <timespan>] [-LockoutThreshold <int> -AppliesTo * SupportedNameFormats]

--------------------------------------------------------------------------------------------------------------------------------------------------------------

How to check policy compliance for linked users for a one or more Password Policies

foreach ($Policy in Get-PasswordPolicy [<Name>]) { foreach ($Applied in $Policy.AppliesTo) { Get-PasswordPo

licyEffective $Applied } }

In an earlier blog post I did promise you to talk a little bit about what's next, I did then already reveled that I did start playing with what's going to be next (Post-Windows Vista and Windows Server 2008). So I did start to play with "what's next" in November last year, and in fact - Yes Windows Server 2008 wasn't even RTM at that time. Now one year later, me and my team at TrueSec has been working very close around this release with Microsoft and is a part of the Windows 7 and Windows Server 2008 R2 Technology Adoption Program (TAP). So what does this mean? Well it's been a lot of sleepless nights of testing and verification that has been going on, around 35% of my Domain Controllers are already running on Pre-Beta/Alpha code for the Windows Server 2008 R2 release. There is a lot of interesting and cool features in this release, which I can't talk about in detail yet. I know there will be a lot of sessions on the topics that are new in this release in PDC2008 that did start yesterday, I except today’s keynote to have its focus on Windows 7 and Windows Server 2008 R2, also next week I’m attending TechEd Europe 2008 in Barcelona and I will be working as ATE (Ask the Experts) there. If you attend please come by the Active Directory (Identity and Access) both and say hello. I know there is going to be event’s that will talk about new features in the next release "Windows Server 2008 R2" that's related to Active Directory.

So what can I mention about this release so far? It’s actually surprising fast and stable and most features planned for this release is already in, and works as you can except them to work at this stage, I'm looking forward to see how the world will adopt this release.

General Information

This build is very close to RTM quality and is “feature complete” we have resolved many bugs and issues in this release, please report any issues or bugs.

Note: The PasswordPolicy Cmd'let now has built-in help for all available commannds. I.e: get-help New-PasswordPolicy -full

As usual many thanks to Stanimir Stoyanov for helping me solving some issues in this release. (http://www.stoyanoff.info)

Overview of Fine Grain Password Policies in Windows Server 2008:
http://technet2.microsoft.com/windowsserver2008/en/library/056a73ef-5c9e-44d7-acc1-4f0bade6cd751033.mspx

Note: Domain controllers running Windows Server 2003 do not consider RODCs when they evaluate site coverage requirements and may register its Domain Name System (DNS) service (SRV) resource records for a site that contains an RODC. As a result, they perform automatic site coverage for any site regardless of the presence of an RODC for the same domain. Consequently, client computers that attempt to discover a domain controller in the RODC site can also find the domain controller that is running Windows Server 2003 and may not authenticate to the RODC.

There are a few possible solutions for this problem:

1. Apply the Windows Server 2008 read-only domain controller compatibility pack for Windows Server 2003 clients and for Windows XP clients (http://support.microsoft.com/kb/944043/en-us)
   (This hotfix has to be applied to all Windows Server 2003 DCs that may perform automatic site Coverage)
   
2. Ensure that only domain controllers running Windows Server 2008 are present in the site closest to the RODC site.
   
3. Configure the weight or the priority of the DNS SRV records so that clients are more likely to authenticate with the RODC than with a remote Windows Server 2003 domain controller.
   
4. Disable automatic site coverage on domain controllers running Windows Server 2003 present in the site closest to the RODC site.

How to disable automatic site coverage:

1. Click Start, click Run, type regedit, and then click OK.
2. Navigate to the following registry subkey HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
3. Click Edit, point to New, and then click DWORD Value.
4. Type AutoSiteCoverage as the name of the new entry, and then press ENTER.
5. Double-click the new AutoSiteCoverage registry entry
6. Under Value data, type 0 to disable automatic site coverage. 1 = to enable it.
7. Click Start, Click Run, type cmd and then click OK.
8. In the Command Prompt, type the following command:
   nltest /dsregdns or restart the netlogon service

I've received a package from Microsoft to the office yesterday with some stuff as thanks for the work we did put into the Windows Server 2008 release, thank you Microsoft this is the best DVD I've got so far of Windows Server 2008 J But I have moved on to something different to play with these days J

This is a frequently asked question the Active Directory newsgroups, so I thought it was worth a blog post.

To determine if adprep successfully have prepared the forsest and the domain (/forestPrep and /domainPrep) look for the objects below:

CN=Windows2003Update,CN=ForestUpdates,CN=Configuration,DC=X (Should exist if the forest has been successfully prepared)

CN=Windows2003Update,CN=DomainUpdates,CN=System,DC=X (Should exist in each domain that has been successfully prepared)

If you know/have the DC that adprep was executed on left, You can check those log files, they give a more detailed explanation of the adprep process. C:\Windows\debug\adprep.

In fact running adprep again can be used as a verification process, as the tool itself will notify you that the process has only been run once and doesn't need to be rerun.

By the way, it's about time to move away from Windows 2000 DCs these days J

I'm back on track in Sweden after being in the US for about a month; actually I have been working a month here already, so we continue the "Windows Vista Enterprise Project" that I'm currently completely busy with (see previous post). There still remains very much work to do, and trying to catch up with all different kind of dependences this project has to other teams inside the company i.e. DNS Team, Active Directory Team, PKI Team, Storage Team, Network Team, etc takes a lot of time.

Yesterday we did ship a first release of our Windows Vista image supporting 5 different hardware models, both x86 and x64 (that actually makes it 10) and a customized installation of Microsoft Office 2007. To certify a specific hardware model, takes about 8 hours (both x86 and x64) and then we use an 'own' developed method for certify our hardware. This is basically it (a bit simplified)

• Download all drivers for the specific model from the hardware vendor's web site.
• Create a folder structure for the specific hardware model in the central storage repository that looks something like:
  • HP nc6010p x64
    • 6010p
      • Network
      • Chipset
      • Storage
      • And so on…
    • Swsetup
      • App0Driver1
      • And so on.
• Extract the content by lunching a custom tool (wrapping around winrar.exe)
  • Identify driver type. (Core Driver) or (App0): The difference between those is that Core Driver is a REAL driver and App0 is a "BAD" driver that needs to execute some kind of setup package, i.e. .exe or .msi package.
• Check in the "REAL" drivers into the System Center Configuration Manager (Our main deployment tool) into the "All Drivers" driver package.
• Create Application Packages for all App0 Drivers.
• Create a task sequencer for the specific hardware, It will be something like "Install Vista Core-VBL-Hardware-HP6910p X86" The HW model is automatically detected by using a simple WMI query.
• Adding the App0 packages, and configures the task sequencer to use "Auto Apply Drivers" that means that Windows Vista during the deployment will do a PNP detection and by its own chose the best drivers from the "All-Drivers" driver package. We have to watch out for compatibility issues here between x86/x64 and storage drivers, It can cause Windows to never boot.
• Once the computer has finished it's deployment, We use a custom made report in System Center Configuration Manager that tells us the best matching drivers that was picked up by Windows during the install, the best matching drivers in the "All-Drivers" driver package, as well all drivers that for some reason failed to install (if any) or if a device is completely missing a driver.
• Based on this information, the drivers for the specific model is locked and the model us getting its own Driver Package, based on the report generated above, the deployment starts all over again but now with its own driver package instead of "Auto Apply Drivers",
• The process is repeated until all devices have a working driver.

It's been a very long time since I did the last blog post here. So what did happen, did I just disappeared a few weeks before Windows Server 2008 RTM. Oh no, But Windows Server 2008 RTM has been a lot of work to me and the entire company, as you may been aware of I have been responsible for putting Windows Server 2008 Pre-release code out in production at a bunch of customers, It's definitely been a lot of challenges and a lots of fun to driving this program, as well it did put a lot of value both to the customers that participated and to Microsoft – for all the great feedback we did give them, and all the bugs we did found and got resolved before the product did hit RTM. I will quote a line for the RTM announcement I received from Microsoft. "When you look at Windows Server 2008, you should think there is a little price of you in that product – thanks for helping us making this product" and I would say thanks for letting me having the opportunity to be a part of the Longhorn project. It is a few days now since I've installed the first Windows Longhorn DC back in early 2005. I would like to thank many people at Microsoft and at last, but not least Mikael Nyström (TrueSec Employee) and Anders Jansson (former TrueSec Employee) for running this program with me.

So what are I'm up to know? Did I move straight on to the next Windows version? Well in fact I did, I went on to early builds on what's next after Windows Vista/Windows Server 2008 even before Windows Server 2008 did hit RTM, but that's another story.

Let's stay with Windows Vista for a while, okay wait a sec, aren't I'm supposed to be a server guy, or more specific AD guy? O Yes I'm, don't get me wrong there. But I got very bored of all noises about Windows Vista like "There is no way you can migrate an enterprise company over to that crapy platform". Eh, if you know me you know that I'm totally are in love with large enterprise environment, the complexity, scalability issues, communication, and working across different countries, working with multiple teams. So I did decided to join and drive one of the most interesting and challenging projects I've come across so far, I happen to be in Team Platform Core:

Deploying and migrating over 60 000 clients from a mixture of Windows XP and Windows 2000 Professional with a time line of only 3 years, reaching out to 95% of all internal business units with Windows Vista SP1 and Office 2007 SP1 using System Center Configuration Manager 2007. This customer dose currently has around 10000 + applications. Oh yes they have to remain working once we switched every PC into Windows Vista form now and the coming two years. It gets even more complicated, they happen to have an industrial line that runs 24/5 around the globe.

I think we have so far done a lot of right decision in this project, and it's the best team I ever been working with, both internal and external people in this project is very skilled and professional in what they do, we definitely have the right people here. The most challenge part so far has been time, but there is no way to delay the final results of this project, you may ask why? The answer is pretty simple: End of support for Windows 2000 Professional by year 210 (most of the workstations are running at this platform today) not receiving security updates nor there is going to be any support beyond that date isn't an option for an enterprise customer like this. So we have about 2 years left, we haven't deployed a single Windows Vista PC in production yet. So if our calculations are made right. (Yes our team did get the statistics of the network performance at over 640 sites, did put together I formula for when to use a SCCM DP, SCCM Branch Office DP, SCCM Secondary Site Server, when to create an AD site, did calculate with the size of the Windows Vista Image to go over the wire (approximately 3GB) plus Office 2007 (approximately 1GB), and what we refer to as app0 (HW based apps) and app1 (core apps) as well USMT data during migration (approximately 20GB) going upstream and downstream.) Our rollout team has to migrate around 100 PCs each day in two years to be able to successfully accomplish the goal. I will report more from this project and what it is like to be in the middle of it, next post will probably be about application compatibility, what strategy we did choose, why Microsoft ACT wasn't enough, what custom tools our team did put together to in order for making it all possible for Team Application.

Fine Grain Password Policy Tool Beta 2 is ready!

Build: FGPP Beta 2_2256-20080120.1
Branch: FGPP-Beta2-branch.
Usage: In a Windows Server 2008 Test environment.

General Information

Overview of Fine Grain Password Policies in Windows Server 2008:
http://technet2.microsoft.com/windowsserver2008/en/library/056a73ef-5c9e-44d7-acc1-4f0bade6cd751033.mspx

Download

Download Fine Grain Password Policy Tool (x86) Beta 2.
http://blogs.chrisse.se/files/folders/32/download.aspx

Download Fine Grain Password Policy Tool (x64) Beta 2.
http://blogs.chrisse.se/files/folders/33/download.aspx

Quick Start Guide
http://blogs.chrisse.se/blogs/chrisse/pages/fine-grain-password-policy-tool.aspx

System Requirements

Fine Grain Password Policy Tool (FGPP) Beta 2 are “Supported” on the following platforms

·         Windows Server 2008

·         Windows Vista and Windows Vista Service Pack 1

·         Windows Server 2003 Service Pack 1 and Windows Server 2003 R2

·         Windows XP Service Pack 2

Prerequisites

Before installing this build, you must have:

Windows Server 2008 and Windows Vista

·         Windows Server 2008 Active Directory Domain.

·         Windows PowerShell installed (for command-line and scripting support)

Windows Server 2003 and Windows XP

·         Microsoft .NET Framework 2.0.

·         Microsoft Management Console 3.0

·         Windows Server 2008 Active Directory Domain,

·         Windows PowerShell installed (for command-line and scripting support)

Microsoft Managemnt Console for Fine Grain Password Polices: (Click for full size)



Usage information 

Note: Use Fine Grain Password Policy at your own risk.

Note: The Fine Grain Password Policy Tool will currently only work from a domain joined computer.

Fine Grain Password Policy Tool Core PowerShell Samples.

FGPP Beta 2 Milestone (Build 2230-2258) supports the following PowerShell Commands.

Create new Password Policies
New-PasswordPolicy <Name> [-domain <FQDNDomainName>] -MaximumPasswordAge <DD.HH:MM> -MinimumPasswordAge <DD.HH:MM> -MinimumPasswordLength <PassswordMinLenght> -PasswordComplexityEnabled <$True/$False> -PasswordReversibleEncryptionEnabled <$True/$False> -PasswordSettingsPrecendence <PrecendenceOrder> -PasswordHistoryLength <NumberOfPasswords> -LockoutDuration <DD.HH:MM> -LockoutObservationWindow <DD.HH:MM> -LockoutThreshold <int> -AppliesTo *SupportedNameFormats

Modify existing Password Policies
Modify-PasswordPolicy <name> [-domain <FQDNDomainName>] [-MaximumPasswordAge <DD.HH:MM>] [-MinimumPasswordAge <DD.HH:MM>] [-MinimumPasswordLength <PassswordMinLenght>] [-PasswordComplexityEnabled <$True/$False>] [-PasswordReversibleEncryptionEnabled <$True/$False>] [-PasswordSettingsPrecendence <PrecendenceOrder>] [-PasswordHistoryLength <NumberOfPasswords>] [-LockoutDuration <DD.HH:MM>] [-LockoutObservationWindow <DD.HH:MM>] [-LockoutThreshold <int>] -AppliesToAdd *SupportedNameFormats -AppliesToRemove *SupportedNameFormats

Delete Password Policies
Delete-PasswordPolicy <name> [-domain <FQDNDomainName>] [-all]

Reame Password Policies
Rename-PasswordPolicy <name> [-domain <FQDNDomainName>] -NewName <name>

Add users and global groups to an existing Password Policy
Add-PasswordPolicy -Name <name> [-domain <FQDNDomainName>] -AppliesTo *SupportedNameFormats

Remove users and global groups to an existing Password Policy
Remove-PasswordPolicy -Name <name> [-domain <FQDNDomainName>] -AppliesTo *SupportedNameFormats [-all]

Get the Effective PasswordPolicy for one or more users objects
Get-PasswordPolicyEffective <name> [-domain <FQDNDomainName>]

------------------------------------------------------------------------------------------------------------------------------------

*SupportedNameFormats: [Domain\UserN, "First LastName", {4fa050f0-f561-11cf-bdd9-00aa003a77b6}, example.microsoft.com/software/user name, usern@example.microsoft.com, S-1-5-21-397955417-626881126-188441444-501]

Fine Grain Password Policy Tool Additional PowerShell Samples.

FGPP Beta 2 Milestone (Build 2230-2258) supports the following PowerShell Commands.

------------------------------------------------------------------------------------------------------------------------------------

How to use the Get-PasswordPolicy and New-PasswordPolicy to copy an existing PasswordPolicy

Note: Any parameter can be used with New-PasswordPolicy override settings from the existing policy.

Get-PasswordPolicy <name> [-domain <FQDNDomainName>] | New-PasswordPolicy <Name> [-domain <FQDNDomainName>] [-MaximumPasswordAge <DD.HH:MM>] [-MinimumPasswordAge <DD.HH:MM>] [-MinimumPasswordLength <PassswordMinLenght>] [-PasswordComplexityEnabled <$True/$False>] [-PasswordReversibleEncryptionEnabled <$True/$False>] [-PasswordSettingsPrecendence <PrecendenceOrder>] [-PasswordHistoryLength <NumberOfPasswords>] [-LockoutDuration <DD.HH:MM>] [-LockoutObservationWindow <DD.HH:MM>] [-LockoutThreshold <int> -AppliesTo * SupportedNameFormats]

------------------------------------------------------------------------------------------------------------------------------------

How to check policy compliance for linked users for a one or more Password Policies

foreach ($Policy in Get-PasswordPolicy [<Name>]) { foreach ($Applied in $Policy.AppliesTo) { Get-PasswordPolicyEffective $Applied } }